Refactored MageRun plugin; added frontname route checking for unknown modules. #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Per #11 (comment) and #20 (comment): Checking frontnames against those on installed modules would be useful in cases where we don't know what module a given frontname actually corresponds to. This will let us add suspicious routes from probes (#8, #20), and detect on those routes, without knowing further information on the modules in advance. In many cases the modules in question will be significantly out of date or used on a relatively small number of stores. It may also help with data collection by encouraging anyone running them to get in touch.
The original magerun script was pretty small and clean, but adding this code made it the opposite of small and clean, so I significantly refactored it in the process.
The previous module check is now contained within
checkIsInstalledModule()
, and the new check is withincheckIsInstalledRoute()
.The route check will run only for modules that are not directly known.
It uses the existing 'Relevant URI' data; no further normalizing needed. It does assume that the frontname is the first element, with or without a leading slash. It ignores anything after. It would be theoretically possible to check for a full controller/action match when the data is available, but that would be much more involved and also much more likely to produce false negatives.
There is a risk of false positives, especially for certain common keywords (EG
ajax
,vendor
). This is unavoidable. In the event of a route match, I have it output:I did not make any changes to the standalone execution script. Adding the same feature there would easily quadruple its size.
Also have not made any changes to the readme. I don't think any are necessary.