Overview
Some notes on installing Pulse Storm Commerce Bug 3.
Installation log
1. "Extract the Magento 2 archive (tar) into the root folder of your system"
Personally, I'm not about to just blindly untar a bunch of stuff into an existing root folder. Instead, I want to see what untaring will unleash, and then apply those changes in a non-destructive way.
- The tar file contains a directory tree:
- app/code/[my name]/Commercebug/
- containing the files for a Magento module.
- So I extracted to a safe directory, then copied the [myname] directory under app/code folder of the actual Magento installation.
2. "Remove cache and generated files"
Remove:
- var/generation/*
- var/cache/*
- var/di/
Done.
3. Enable and setup the Commerce Bug Module
- Enable the new module:
- magento module:enable [my name]_Commercebug
- Refresh the setup upgrade database tables:
- magento setup:upgrade
- Ran, says to "Please re-run Magento compile command"
- ... which is... what? Grrrr.
- https://github.com/magento/magento2/issues/2457
- https://github.com/magento/magento2/issues/5488
- No instructions in Commerce Bug README
- I ran ./magento setup:di:compile, though according to the referenced github issues it's probably not needed.
- Took a few minutes, but completed OK.
Commerce Bug README says that at this stage:
- you should see Commerce Bug at the bottom of every Magento page.
- Commerce Bug 3 for Magento 2 now obeys settings in:
- Stores -> Configuration -> Advanced -> Developer -> Developer Client Restrictions
Additional README notes
- Commerce Bug 3 for Magento 2 will log the last 10 requests. You can find and review all the details of these requests at
- System -> Other Settings -> Commerce Bug Logs
- This feature is perfect for debugging AJAX, API, Mobile, or any other requests that don't render in a personal computer web browser UI.
- Commerce Bug 3's "Class Lookup" tab will allow you to lookup information (file location, ancestry chain, etc) on any PHP class/Magento object manager type in the system.
- Commerce Bug 3's Layout tab will now render a graph of the layout that includes color coding container, blocks, and UI components.
Initial results... disaster!
- Both the off-the-shelf Luma site, and also my test site, lost their CSS and possibly javascript.
- The Commerce Bug panel did not appear at the bottom of the page
- Back-end admin UI superficially appears to work.
- Notified to flush caches, which I did.
- Stores > Configuration: The accordion functionality doesn't work, so no way to get to the settings for Commerce Bug. Apparently the page is not loading its javascript
Troubleshooting
Trying to load a normal store home page, while observing the Firefox dev tools network panel, it appears that a bunch of css and js files are being requested from:
- /pub/static/frontend/Magento/luma/en_US/[my name]_Commercebug/css/ (example: commercebug-bug-frontend.css, style.css, jstree.js etc)
... but not found (404 error).
- The first problem is that there's no directory /pub/static/frontend.
- Checking the file system of the snapshot I took. Hmmm, it has:
- /pub/static/adminhtml
- /pub/static/frontend
- Magento/blank and luma, etc
- /pub/static/frontend/Magento/luma/en_US/ contains huge amount of content
- Looks like there's something broken in the compile process
- Maybe this is salient: http://magento.stackexchange.com/questions/102230/magento2-regenerate-full-static-content
- php bin/magento setup:static-content:deploy ...or...
- php bin/magento -vvv setup:static-content:deploy (Verbose, shows better errors.)
- OK! That seems to have done the trick.
- Sites functioning
- Commerce Bug panel appears at the bottom of each page.
- Root cause for the "disaster": Site was in production mode rather than developer mode. If it had been in developer mode, it presumably have performed the extra steps that I had to do manually in the troubleshooting above.
Not quite working -- no products showing in store view!
- I reindexed: bin/magento indexer:reindex
- Flushed caches
- But still on one store, products only appear in one store view, and not the other.
- I noticed that reindex showed "Catalog Search index is locked by another reindex process. Skipping."
- So perhaps the reindex is stuck.
- Try: http://magento.stackexchange.com/questions/126067/magento-2-how-to-unlock-reindex-process
- bin/magento indexer:info
- bin/magento indexer:status
- php bin/magento indexer:reset
- Reindex proceeded up to end of EAV, but then....
- "Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 77 bytes) in /home/[site]/public_html/vendor/magento/framework/DB/Adapter/Pdo/Mysql.php on line 2778 Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors."
- Second attempt failed at exactly the same place.
- This is the Catalog Search index, and status shows that it's "Processing" (so crashed, presumably).
- How is it possible that creating a search for ~4000 products exhausted 805 MB???
- Seem like it must be a bug in the indexing, that's ridiculous.
- How about reindex one index at a time?
- Catalog Search = catalogsearch_fulltext
- bin/magento indexer:reindex catalogsearch_fulltext
- Fatal error: Allowed memory size of 805306368 bytes exhausted (tried to allocate 72 bytes) in /home/grahamw2/public_html/vendor/magento/zendframework1/library/Zend/Db/Select.php on line 955
- http://www.inmotionhosting.com/support/website/php-troubleshooting/allowed-memory-size-exausted
- No option to increase PHP memory beyond the already-set 768Meg.
- Several rounds with siteground about this, given that I have an account supposedly optimized for Magento.
Solution
I ended up:
- Deleting all the Luma sample data
- Visiting many of the custom attributes I'd added and disabling their use in the index
- This allowed bin/magento indexer:reindex catalogsearch_fulltext to complete.
This memory issue probably was not associated with Commerce Bug, not sure why it cropped up during this exercise.
Uploading ....