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

• How to determine Maximum Stack Storage

• Installing or Upgrading Latest AWS CLI

• How to Clear the Cache and Cookies in Your Web Browser

Steps 

Confirm site health

1. Confirm stack not out of storage

2. Run purge caches

3. Run upgrade cli

4. Enable debugging in config.php

5. Look at logs in: 

   1. /mnt/data/site/[Site_Name]/var/web

   2. /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)

6. 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

1. Access the client's stack via ssh login

2. Change to site folder: cd /mnt/data/site/[SiteName]

3. Make a copy of the http folder with today's date appended

4. Note sudo is needed to preserve apache group ownerships: sudo cp -arv http http-09202020

5. Confirm copy

6. Look for preserved permissions and common Moodle files / folders: Is -l http-09202020

7. Change directory to http folder cd http

8. Confirm modifications to moodle source folder

9. Look for uncommitted changes git status

10. Look for core changes (not covered in this process, but a possible source of site issues) 

11. Output should be empty if no core changes (at least in non-ignored files): git diff

12.  Dry run of plugins removal command: -n flag for dry run

13. Look for anything unusual in output before doing the real command: git clean -d -f -n

14. Remove uncommitted changes (ie added plugins)

15.  -f remove files

16. -d remove directories: git clean -d -f

17. Confirm removal

18. No uncommitted code should show now: git status

19. Upgrade step to make sure Moodle is functioning as expected: sudo -u apache php-7.2 admin/cli/upgrade.php

20. Purge caches: sudo -u apache php-7.2 admin/cli/purge_caches.php

21. Test the site

Revert site back to original

1. Move the clean copy of the site to temp location: mv http http-clean

2. 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)

3. 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

4. Upgrade step to make sure Moodle is functioning as expected: sudo -u apache php-7.2 admin/cli/upgrade.php

5. 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)

1. Move the local kaltura folder into the site root folder renaming with preceding local_ for future

2. mv local/yukaltura ../local_yukaltura

Option 2: Move plugins into a clean copy of http folder

1. 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:

1. Root cause analyzed and plugin issue fixed and plugins re-installed on site

2. 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:

1. Remove any unneeded folders: rm http-09202020 -rf, rm http-clean -rf

2. 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: 

1. cd /mnt/data/sites/SiteName

2. mv http http-20201120

3. git clone /mnt/data/repos/apps/workplace.mirror http

4. Copy in config.php config-custom.php, sideloaded plugins and perhaps other plugins managed by UHCP

5. 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