In Magento updates often new queue consumers are added. In common server setups there is no automatic run for all consumers, so each needs to be configured separately. So its vital to detect new introduced consumers. This PR introduces this Feature.

@convenient I gave my best in understanding the code and contributing, but if you see a way to improve the PR, feel free to do so :)

Checklist

• [x] Pull request has a meaningful description of its purpose
• [x] All commits are accompanied by meaningful commit messages
• [x] Tests have been ran / updated

Fix issue #5

Adds ability to use this when upgrading any dependency. In the test process I have added a module AmpersandVendorTest and have added a preference and an override for a template to it within AmpersandTest and the theme.

This has had the effect that we can see the test module being flagged at https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/pull/50/files?w=1#diff-133b164f15b2fb0ce3b815c485e7c74f359bffb1d7409f7f1969fed6060b94ea (best to avoid whitespace)

This has had the following effect and we can see the test module overrides being flagged.

A bit of a clearer example, I temporarily spoofed in some adyen overrides and got the following.

The process is exactly the same, i did it this way in case a magento module requires a magento module to function. The best guarantee is to diff the whole vendor before and after, rather than trying to be too clever.

+--------------------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------+
| Type                     | Core                                                                                   | To Check                                                                                         |
+--------------------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------+
| Override (phtml/js/html) | vendor/adyen/module-payment/view/frontend/templates/checkout/success.phtml             | app/design/frontend/Ampersand/theme/Adyen_Payment/templates/checkout/success.phtml               |
| Preference               | vendor/adyen/module-payment/AdminMessage/APIKeyMessage.php                             | Ampersand\Test\Model\AdyenAPIKeyMessage                                                          |
+--------------------------+----------------------------------------------------------------------------------------+--------------------------------------------------------------------------------------------------+

Checklist

• [x] Pull request has a meaningful description of its purpose
• [x] All commits are accompanied by meaningful commit messages
• [x] Tests have been ran / updated

Hi

Big thanks for open sourcing this tool!

If I compare it with the output of my own crappy script to detect changes between 2 different versions of Magento, I notice one difference when doing a diff in between Magento 2.2.6 and 2.2.7 for frontend overridden files.

My script detects this file as overwritten in one of our projects, but this tool doesn't seem to support this yet: Magento_Checkout/web/template/summary/item/details.html (2.2.6 version vs 2.2.7 version)

Would be nice if this tool could also detect such files.

Thanks again! :)

Firstly: Thanks a lot for developing this awesome helper. We use it for every Magento update, and it makes our live so much easier! When I now have the output of which files I shall check, I get through them one by one and open the diff viewer between the override / preference and the Magento Core file. Sometimes, if I'm still not sure, if the changes are needed, I open the Core file in the vendor_orig folder and check out the three-file-diff. Do you see any good way of having that directly as a possibility? Maybe with a clickable link, which opens that view? I saw, that PHPStorm offers some CLI approach: https://www.jetbrains.com/help/phpstorm/command-line-differences-viewer.html For this, we would need the paths of all three files, which might be a bit difficult. What do you think?

We're currently exploring whether we can run this tool in a scheduled pipeline to automate these steps;

    - composer install
    - mv vendor vendor_orig
    - composer require magento/product-community-edition 2.4.1 --no-update
    - composer --profile update
    - bin/magento set:up
    - diff -ur vendor_orig/ vendor/ > vendor.patch
    - cd ampersand-magento2-upgrade-patch-helper
    - php bin/patch-helper.php analyse ../ --auto-theme-update 0 --sort-by-type ../patch-helper-output.txt

This way, we could let our pipeline do the heavy lifting and commit the result to a separate branch, from where a developer can walk through the patch-helper-output.txt file. One of the things we're running into is that we need a database because the upgrade patch helper assumes a running Magento install. This isn't an issue per se, but we'd rather not. Is there any way we could make the patch helper run on just code, and no db?

When updating to 2.4.3p-2 and above, we noticed that the the tool did not show email template changes.

For example, a change in vendor/magento/module-customer/view/frontend/email/password_reset_confirmation.html did not come up when using the tool. We have an overwrite on this template file and noticed we were missing a parameter only after we got an issue with the emails.

Does this tool support email templates? If not, is the a plan to add it in the near future?

…f Hyvä themes.

This is a very hacky way of adding support for Hyvä themes as a base theme.

Currently this tool does not support detecting changes in custom themes build on top of Hyvä themes. For example, I was trying to upgrade Hyvä from one version to another and was hoping that this tool would help me figure out which overwritten files in our custom theme needed to be looked at. But currently the tool doesn't support this.

The PR is in WIP status, because I'm like 99% sure this isn't the correct way of adding support for this.

In fact, I believe there might be a bug in the tool which does currently not support base themes at all. Magento adds almost all their frontend files (xml, phtml, html, js) through modules and not through their blank or luma themes.

There are currently only a few limited files that are interesting to this tool in their base themes and I think the tool currently is not able to analyse change in those files (not tested though), some numbers to demonstrate how few files are in those themes (the majority of files in those themes are less files):

• 0 phtml files in Magento/blank
• 0 html files in Magento/blank
• 3 js files in Magento/blank
• 5 xml files in Magento/blank
• 2 phtml files in Magento/luma
• 18 html files in Magento/luma
• 0 js files in Magento/luma
• 9 xml files in Magento/luma

This is probably also why Hyvä themes aren't working out of the box since the 2 Hyvä themes (reset & default) do put all their frontend files inside the theme.

I'm not sure what the best way would be to support this in a more generic way that can work with all themes and random file structures, and have not a lot of time to investigate this properly unfortunately.

Checklist

• [x] Pull request has a meaningful description of its purpose
• [x] All commits are accompanied by meaningful commit messages
• [ ] Tests have been ran / updated

Hi!

Detected just now when analysing Magento 2.3.5-p2 upgrade (from 2.3.5-p1). Regarding the file vendor/magento/module-wishlist/view/frontend/templates/sidebar.phtml

We have a particular project where the following theme inheritance is active:

• Magento/blank
  • Vendor/blank (installed in vendor)
    • Vendor/custom (installed in app/design)

The sidebar.phtml file is being overwritten in both Vendor themes:

• vendor/vendor/blank/Magento_Wishlist/templates/sidebar.phtml
• app/design/frontend/Vendor/custom/Magento_Wishlist/templates/sidebar.phtml

When I run the analyse command, it only outputs:

• app/design/frontend/Vendor/custom/Magento_Wishlist/templates/sidebar.phtml

Is this expected? I think it should output both files?

There is a possibility that one storeview uses one theme and another storeview uses the other theme and then we could have troubles if only one of both was patched.

Thanks again for the awesome tool which I'm using all the time! :)

I've seen on slack chats and have it mentioned to me a few times (most recently @pocallaghan) ) that it would be good to have this as a magento2 module.

My initial thoughts on this were summarised here but I'll quote it for posterity

I did previously think of making this a module that you install within Magento, but then dependencies with things like symfony/console which can vary between 2.1 and 2.3 quite drastically can cause problems.

So i figured it would be less disruptive and more likely to work across wide version gaps it it was isolated.

Basically, we have enough dependencies to work with when upgrading magento so I didn't want to have to worry about one more. Also we usually have multiple magento versions to support (for example now its 2.3.x and 2.4.x)

In that issue @hostep identified that workarounds are possible

As a developer I am pretty risk averse which is why I have never really pushed forward on this. But if there's an appetite for it and people think it would be useful I'm open for discussion and PRs :)

I was snooping about in the github insights feature and found this in which a @AW3i started work on this last year https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/compare/master...AW3i:check-custom-modules

This was a pretty large refactor for #6

• This required changes in how the warnings were handled as now we needed to detect both preferences, and plugins for a php class.
  • I've amalgamated the output together as one large table to keep the code clean as additional checks are added in the future.
  • This required the magento2 specific dependencies to be better encapsulated to prevent instantiation.
• This required that the patch entry could be consumable and parsable, so that we could understand where in the original/new files php changes occurred, and what function they belonged to.
• To aid the manual review of the patchfile with the values output in the table a subsection of the patchfile is written to vendor_files_to_check.patch, otherwise the massive vendor.patch would have to be inspected by the developer during the upgrade manually.
• Unit tests and functional tests have been split out.

This outputs information in the table like follows

+--------------------------+-------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------+
| Type                     | Core                                                                                                  | To Check                                                                                                       |
+--------------------------+-------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------+
| Plugin                   | vendor/magento/module-catalog-search/Controller/Result/Index.php                                      | Smile\ElasticsuiteCatalog\Plugin\CatalogSearch\ResultPlugin::aroundExecute                                     |
| Preference               | vendor/magento/module-catalog-search/Model/ResourceModel/Fulltext/Collection.php                      | Smile\ElasticsuiteCatalog\Model\ResourceModel\Product\Fulltext\Collection                                      |
+--------------------------+-------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------+
You should review the above 2 items alongside /Users/lukerodgers/src/example/vendor_files_to_check.patch

TODO

• [x] Tidy spaghetti code 🍝
• [x] --sort-by-type
• [x] Test

Checklist

• [x] Pull request has a meaningful description of its purpose
• [x] All commits are accompanied by meaningful commit messages
• [x] Tests have been ran / updated

Hiya

When trying to run this tool when analysing an upgrade from Magento 2.3.6 to 2.3.6-p1, I'm getting the following error:

$ bin/patch-helper.php analyse /some-project -vvv

In PhpCookieManager.php line 397:

  [Magento\Framework\Stdlib\Cookie\FailureToSendException]
  The cookie with "private_content_version" cookieName couldn't be sent. Please try again later.


Exception trace:
 () at /some-project/vendor/magento/framework/Stdlib/Cookie/PhpCookieManager.php:397
 Magento\Framework\Stdlib\Cookie\PhpCookieManager->setCookieSameSite() at /some-project/vendor/magento/framework/Stdlib/Cookie/PhpCookieManager.php:183
 Magento\Framework\Stdlib\Cookie\PhpCookieManager->setCookie() at /some-project/vendor/magento/framework/Stdlib/Cookie/PhpCookieManager.php:135
 Magento\Framework\Stdlib\Cookie\PhpCookieManager->setPublicCookie() at /some-project/vendor/magento/framework/App/PageCache/Version.php:87
 Magento\Framework\App\PageCache\Version->process() at /some-project/vendor/magento/module-page-cache/Model/App/FrontController/BuiltinPlugin.php:67
 Magento\PageCache\Model\App\FrontController\BuiltinPlugin->aroundDispatch() at /some-project/vendor/magento/framework/Interception/Interceptor.php:135
 Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception\{closure}() at /some-project/vendor/magento/framework/Interception/Interceptor.php:153
 Magento\Framework\App\FrontController\Interceptor->___callPlugins() at /some-project/generated/code/Magento/Framework/App/FrontController/Interceptor.php:26
 Magento\Framework\App\FrontController\Interceptor->dispatch() at /some-project/vendor/magento/framework/App/Http.php:116
 Magento\Framework\App\Http->launch() at src/Ampersand/PatchHelper/Helper/Magento2Instance.php:74
 Ampersand\PatchHelper\Helper\Magento2Instance->__construct() at src/Ampersand/PatchHelper/Command/AnalyseCommand.php:54
 Ampersand\PatchHelper\Command\AnalyseCommand->execute() at vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at vendor/symfony/console/Application.php:953
 Symfony\Component\Console\Application->doRunCommand() at vendor/symfony/console/Application.php:248
 Symfony\Component\Console\Application->doRun() at vendor/symfony/console/Application.php:148
 Symfony\Component\Console\Application->run() at bin/patch-helper.php:10

analyse [-a|--auto-theme-update [AUTO-THEME-UPDATE]] [--sort-by-type] [--vendor-namespaces [VENDOR-NAMESPACES]] [--php-strict-errors] [--] <project>

If you haven't got access yet to Magento 2.3.6-p1, it will be released to the public on 9 February.

It looks like Magento gets bootstrapped in a http context by this tool and Magento 2.3.6-p1 comes with support for SameSite cookies and while it tries to set it, it causes an error because it's not an actually http request, if I understand it correctly.

Not sure if the error is in this tool or a new bug in Magento 2.3.6-p1

First change is to ensure that themes are properly checkable, not sure exactly when this regressed but likely https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/pull/50/files#diff-1677a5ff5bacd5ace1e65ee7fb17d5a6875c82d8f0e747f0df8cde8e80cc0050R508

I've captured test cases to ensure that core magento theme files are handled, as well as custom themes residing in vendor are checked.

+ | WARN  | Override (phtml/js/html) | vendor/ampersand/upgrade-patch-helper-test-module/src/theme/Magento_Checkout/templates/cart/form.phtml | app/design/frontend/Ampersand/theme/Magento_Checkout/templates/cart/form.phtml                 |
+ | WARN  | Override (phtml/js/html) | vendor/magento/module-sales/view/frontend/email/order_new.html                                         | vendor/ampersand/upgrade-patch-helper-test-module/src/theme/Magento_Sales/email/order_new.html |
+ | WARN  | Override (phtml/js/html) | vendor/magento/theme-frontend-luma/Magento_Sales/email/order_new.html                                  | vendor/ampersand/upgrade-patch-helper-test-module/src/theme/Magento_Sales/email/order_new.html |

The second change is to improve output for hyva themes.

If a template is a "hyva owned" template (it is defined in a theme with Hyva/ in the name) then we do not care that Magento had modified a template of the same path structure for any of the hyva themes or children themes. By checking if the template is defined in one of the base hyva themes, we roughly handle the case where theme fallback is in play as if a vendor/magento/some/template.phtml file is scanned and does not exist in the hyva themes, but exists in a child theme, it will still be reported.

We only need to see the hyva children themes being reported, when changes to the hyva base themes themselves occur. So we filter output, and ensure reporting is a bit like below.

- | WARN  | Override (phtml/js/html) | vendor/magento/module-customer/view/frontend/templates/address/edit.phtml                              | vendor/hyva-themes/magento2-default-theme/Magento_Customer/templates/address/edit.phtml       | 
- | WARN  | Override (phtml/js/html) | vendor/magento/module-customer/view/frontend/templates/address/edit.phtml                              | app/design/frontend/OurCustomer/Hyvaaaaa/Magento_Customer/templates/address/edit.phtml        | 
+ | WARN  | Override (phtml/js/html) | vendor/hyva-themes/magento2-default-theme/Magento_Customer/templates/address/edit.phtml                | app/design/frontend/OurCustomer/Hyvaaaaa/Magento_Customer/templates/address/edit.phtml        | 

This works inversely also, changes in hyva themes in vendor will not be reported in non-hyva based app/code themes.

This filtering in its total form removes these kinds of entries which I believe makes sense

-| WARN  | Override (phtml/js/html) | vendor/ampersand/upgrade-patch-helper-test-hyva-theme-stub/theme/Magento_Checkout/templates/cart/form.phtml | app/design/frontend/Ampersand/theme/Magento_Checkout/templates/cart/form.phtml                                  |
-| WARN  | Override (phtml/js/html) | vendor/ampersand/upgrade-patch-helper-test-hyva-theme-stub/theme/Magento_Checkout/templates/cart/form.phtml | vendor/ampersand/upgrade-patch-helper-test-module/src/theme/Magento_Checkout/templates/cart/form.phtml          |
-| WARN  | Override (phtml/js/html) | vendor/ampersand/upgrade-patch-helper-test-module/src/theme/Magento_Checkout/templates/cart/form.phtml      | vendor/ampersand/upgrade-patch-helper-test-hyva-theme-extended/theme/Magento_Checkout/templates/cart/form.phtml |
-| WARN  | Override (phtml/js/html) | vendor/ampersand/upgrade-patch-helper-test-module/src/theme/Magento_Checkout/templates/cart/form.phtml      | vendor/ampersand/upgrade-patch-helper-test-hyva-theme-stub/theme/Magento_Checkout/templates/cart/form.phtml     |

TODO

• [x] Add hyva test cases

Checklist

• [x] Pull request has a meaningful description of its purpose
• [x] All commits are accompanied by meaningful commit messages
• [x] Tests have been ran / updated

        $configLoader = $objectManager->get(\Magento\Framework\ObjectManager\ConfigLoaderInterface::class);
        $this->areaConfig['adminhtml'] = $configLoader->load('adminhtml');
        $this->areaConfig['frontend'] = $configLoader->load('frontend');
        $this->areaConfig['global'] = $configLoader->load('global');

Not sure what i was originally thinking, but we should verify if we're missing out on preferences in other areas pretty easily.

For a while now, https://hyva.io/ is used more and more, and we use it in some projects as well. There it would be awesome, if some parts could be improved:

• Ignore overrides in hyva modules as these are maintained by hyva itself anyway and we don't want to adapt them in an update
• Check also custom fallback themes: In hyva it is possible to define a fallback theme for specific URLs. For that, there is a config setting, where you provide a full path of a fallback theme. This theme is currently not taken into account as far as I see, as it is not defined as a "normal" theme and so ignored. Would be awesome, if this could be checked as well.

Do you see any way of approaching this?

Work similar to https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/pull/67 could be done to actually analyse when config values are added or deleted to magento.

Might be useful information although it may be a deluge to have by default, so maybe hidden behind a flag would be useful

Context

Maybe similar logic can be used for discovering changes in other type of xml files (like adminhtml/system.xml to see if configuration settings were added/removed). Just an idea, not sure if really helpful https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/pull/67#issuecomment-1234667780

neat idea @hostep this kind of thing is definitely now possible, but I wonder how much noise we'd get for how much value? I fear the payment methods and third party modules magento bundles / unbundles would cause this to be loud? 🤔 https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/pull/67#issuecomment-1235230159

True, but the behavior could maybe be hidden behind a flag? --also-show-config-changes (I'm bad at naming things, so this is probably not the best option) https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/pull/67#issuecomment-1235316206

according this report https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper/issues/59#issuecomment-926707217

matching against the module correctly for this override, but matching the end of default.xml when i should be looking for /default.xml very likely.

For some reasons I couldn't get it working

• At first, I wanted to make a quick check on report of preference, plugin, PHTML/HTML/JS but an empty vendor.patch doesn't work so I have made a test modification and generate a non-empty vendor.patch so it can pass the validation for vendor.patch
• Now I get the empty report You should review the above 0 items alongside /path/to/magento/vendor_files_to_check.patch (the Magento installation is a fully working test site and has database connection)

Where should I look at? My site is 2.4.3 and I have the magefan conflict detector working well.