Overview
This document will guide you through the process of how to quickly determine if a community plugin is causing issues within a site.
Before You Begin
Steps
Confirm site health
Confirm stack not out of storage
Run purge caches
Run upgrade cli
Enable debugging in config.php
Look at logs in:
/mnt/data/site/[Site_Name]/var/web
/var/log/php-fpm/7.2/www-error.log (where 7.2 is the version of php for this version of Moodle, currently 7.2 for recent Moodle versions)
If problem persists, try ruling out plugins by following the next set of steps
Temporarily remove community plugins
Note: This method will also remove side loaded plugins
Access the client's stack via ssh login
Change to site folder: cd /mnt/data/site/[SiteName]
Make a copy of the http folder with today's date appended
Note sudo is needed to preserve apache group ownerships: sudo cp -arv http http-09202020
Confirm copy
Look for preserved permissions and common Moodle files / folders: Is -l http-09202020
Change directory to http folder cd http
Confirm modifications to moodle source folder
Look for uncommitted changes git status
Look for core changes (not covered in this process, but a possible source of site issues)
Output should be empty if no core changes (at least in non-ignored files): git diff
Dry run of plugins removal command: -n flag for dry run
Look for anything unusual in output before doing the real command: git clean -d -f -n
Remove uncommitted changes (ie added plugins)
-f remove files
-d remove directories: git clean -d -f
Confirm removal
No uncommitted code should show now: git status
Upgrade step to make sure Moodle is functioning as expected: sudo -u apache php-7.2 admin/cli/upgrade.php
Purge caches: sudo -u apache php-7.2 admin/cli/purge_caches.php
Test the site
Revert site back to original
Move the clean copy of the site to temp location: mv http http-clean
Make a copy of original site back in place
(Note: You can alternatively use mv instead if you don't need to preserve a copy of the original)
Copy is a good idea if you need to do further testing to find which plugin without changing the original: cp -avr http-09202020 http
Upgrade step to make sure Moodle is functioning as expected: sudo -u apache php-7.2 admin/cli/upgrade.php
Purge caches: sudo -u apache php-7.2 admin/cli/purge_caches.php
Finding the specific plugin
If working from the original folder with all plugins installed, use mv to move out individual plugin sets (be aware of dependencies between plugins provided by the same vendor or otherwise related plugins).
Option 1: Move plugins out of copy of original http folder
Example (from http folder)
Move the local kaltura folder into the site root folder renaming with preceding local_ for future
mv local/yukaltura ../local_yukaltura
Option 2: Move plugins into a clean copy of http folder
From a clean folder copy in plugins one at a time to: cp -avr http-09202020/local/yukaltura http/local/
Considerations
This process is meant as a rapid troubleshooting process to get a site back online with the least time delay. It should not be considered a fix! To finalize, one of two things must happen:
Root cause analyzed and plugin issue fixed and plugins re-installed on site
Problem plugin removed from (unHosting Control Panel) UHCP side in site configuration
Plugins May Re-install on Future Site Deployments
This procedure manually removes the source code of plugins from the http (webroot) folder of a Moodle site. It does not remove them from the unHosting plugin list for the site. This is done so that the plugin's data is not deleted from the site while trying to identify the issue. Because of this, the plugins may get re-installed later since unHosting is not aware of the manually changes made at the cli.
Plugin Dependencies / Event Monitors
This process works if all dependent plugins are removed together, but it can cause debug errors and/or moosh error output for plugins which have register event hooks or similar configuration settings. This can lead to the temporary login feature to break or errors in the cron.php or other unexpected results.
Final File Cleanup
This step may need to be done later after the true cause is identified and the site's setup is resolved in a clean / maintainable deployment:
Remove any unneeded folders: rm http-09202020 -rf, rm http-clean -rf
Cleanup temp moved plugins (from option 1): rm /mnt/data/site/[SiteName]/local_yukaltura -rf
Extra Troubleshooting
We have seen instances where the site's git repository is damaged. In one case this caused the git clean step to not remove all non-core plugins and even the use of git reset did not work correctly. Cloning the repository may fix this. The steps are:
cd /mnt/data/sites/SiteName
mv http http-20201120
git clone /mnt/data/repos/apps/workplace.mirror http
Copy in config.php config-custom.php, sideloaded plugins and perhaps other plugins managed by UHCP
Run permissions set on it
Now you can thoroughly run through the quick way to determine if a community plugin is the source of site trouble.
*Add important callouts here