Difference between revisions of "Legacy Module Removal"
m |
m (→Deletion & Notification Process) |
||
| Line 14: | Line 14: | ||
# A legacy module is found to be unused and is successfully deleted. A log entry starting with "Unused legacy modules were deleted" will be created, and will contain a comma separated list of the modules that were deleted. An email message will be sent to notify system administrators of the modules that were deleted. | # A legacy module is found to be unused and is successfully deleted. A log entry starting with "Unused legacy modules were deleted" will be created, and will contain a comma separated list of the modules that were deleted. An email message will be sent to notify system administrators of the modules that were deleted. | ||
# A legacy module is found to be in use and is not attempted for deletion. A log entry starting with "One or more legacy modules were found to be in use and were not attempted to be deleted" will be created, and will contain a comma separated list of the modules that were unable to be deleted. An email message will be sent to notify system administrators of this condition. | # A legacy module is found to be in use and is not attempted for deletion. A log entry starting with "One or more legacy modules were found to be in use and were not attempted to be deleted" will be created, and will contain a comma separated list of the modules that were unable to be deleted. An email message will be sent to notify system administrators of this condition. | ||
| − | # A legacy module is found to be unused and deletion is attempted, but the deletion fails (e.g. due to insufficient permissions or a filesystem issue). A log entry starting with "One or more legacy modules could not be deleted" will be created, and will contain a comma separated list of the modules that were unable to be deleted | + | # A legacy module is found to be unused and deletion is attempted, but the deletion fails (e.g. due to insufficient permissions or a filesystem issue). A log entry starting with "One or more legacy modules could not be deleted" will be created, and will contain a comma separated list of the modules that were unable to be deleted. An email message will be sent to notify system administrators of this condition. |
== Handling Notifications == | == Handling Notifications == | ||
Revision as of 13:24, 15 December 2020
Old PHP code may introduce breakage on newer versions of PHP runtime. In order to protect your system from unexpected downtime, WHMCS 7.5 and newer will perform an inspection for any unused legacy modules. Legacy modules are modules that are no longer maintained or distributed and are typically for older and often discontinued services.
Contents
Inspection Process
During updates, WHMCS will check for modules that are no longer officially maintained or supported. If a module is activated and configured then that module will be considered to be in use, and WHMCS will not attempt to delete that module.
Deletion & Notification Process
Following the inspection WHMCS will attempt to perform outdated module deletion. There may be three possible outcomes:
- A legacy module is found to be unused and is successfully deleted. A log entry starting with "Unused legacy modules were deleted" will be created, and will contain a comma separated list of the modules that were deleted. An email message will be sent to notify system administrators of the modules that were deleted.
- A legacy module is found to be in use and is not attempted for deletion. A log entry starting with "One or more legacy modules were found to be in use and were not attempted to be deleted" will be created, and will contain a comma separated list of the modules that were unable to be deleted. An email message will be sent to notify system administrators of this condition.
- A legacy module is found to be unused and deletion is attempted, but the deletion fails (e.g. due to insufficient permissions or a filesystem issue). A log entry starting with "One or more legacy modules could not be deleted" will be created, and will contain a comma separated list of the modules that were unable to be deleted. An email message will be sent to notify system administrators of this condition.
Handling Notifications
Should you receive an email concerning legacy modules found to be in use, then the recommended action is to contact the module author and determine if there is an update available for the module in question.
Should you receive an email concerning unused legacy modules that were not able to be deleted, then it is recommended to investigate and finalize module removal manually as the module state may be inconsistent due to potentially partial deletion.
Once all modules in the received email have been addressed, either by manual deletion or by contacting the module author, then we would recommend using the PHP Version Compatibility Assessment utility to help locate any other files that may negatively affect WHMCS.
Handling a Failed Removal
Should a module be unable to be removed, the first step would be to determine why that occurred. If i was due to the module being in use, deactivating and deleting it may be necessary. The process of doing this depends on the type of module in question. For example: for a provisioning module, any servers and products set to it would need to be changed to a different module, and then the module could be manually deleted from the /modules/servers folder. If there's any doubt, it is best to contact the author of the module for assistance with the removal process.