-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove all marketing get parameters to minimize the cache #39099
base: 2.4-develop
Are you sure you want to change the base?
Conversation
Hi @rogerdz. Thank you for your contribution! Add the comment under your pull request to deploy test or vanilla Magento instance:
❗ Automated tests can be triggered manually with an appropriate comment:
Allowed build names are:
You can find more information about the builds here For more details, review the Code Contributions documentation. |
@magento run all tests |
@magento run all tests |
Nice. Maybe you want to update the parameters based on https://github.com/magento/magento2/pull/39188/files#diff-40e00b332f8dd95fbf48a312b9b8cfeee0d4e70bd7528c0e794c84c9e00c113fR85. |
@magento create issue |
@magento run all tests |
@magento run Database Compare, Functional Tests B2B, Functional Tests CE |
@sprankhub, I think you got confused and meant to comment on #35228 Ideally we should have one place where the entire list is defined and can be used both by the Varnish VCL file generator and the non-Varnish based FPC solution. Maybe using a backoffice configuration field? We have a new request for that since today BTW: #39268 (even though the example given there is a very bad idea) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I got right, you’re removing cache parameters on Magento (php) side.
for that purpose, Varnish does way better job, since it works way better and uses resources more efficiently.
I don’t see how someone would use built in full page cache in production, so I don’t think we should update it
Example use case:
you added a new service, let’s say Klaviyo, that adds a dynamic value for each client.
Marketing team has sent an email to all subscribers and they starting clicking on link that goes to a single product page.
What we have right now is - the dynamic get parameter will be removed by Varnish, and after the first request - it will put the result in cache. all next requests will not get to Magento/php - so they will be delivered to clients waaaay faster and won’t create load to web servers, database and redis.
if we accept your changes - this would mean that this dynamic get parameter will be removed on php side, which will result in additional slower responses, additional load to web servers, database and redis.
Having all that in mind, I don’t think we can accept this pull request, but instead, we should actualize the list in Varnish config.
Please correct me if I’m wrong
Sorry, looks like I got confused a bit. |
Yes, people use Magento shops without Varnish in production as Varnish requires a big amount of memory and certain shops have soo little traffic it's not worth paying the extra cash for extra resources. In that case the built-in FPC using filesystem as storage is more then adequate enough. Some of our clients use this sort of setup. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please cover your changes with unit tests?
@magento run all tests |
I updated unit test + marketing parameters |
* Pattern detect marketing parameters | ||
*/ | ||
public const PATTERN_MARKETING_PARAMETERS = [ | ||
'/&?gad_source\=[^&]+/', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest to extract this list to method that can be later pluginized. Or use dedicated class where those patterns can be injected via DI. Or even better to allow editing this list via admin panel.
If merchant uses some local marketing tools that are not part of this list then - hardcoded public const PATTERN_MARKETING_PARAMETERS
cannot be easily overridden to remove custom tracking params.
As someone in CR suggested this service can also be used to generate Varnish config.
@@ -38,9 +48,11 @@ public function __construct( | |||
*/ | |||
public function getValue() | |||
{ | |||
$pattern = Identifier::PATTERN_MARKETING_PARAMETERS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is not extendable to append custom patterns. Dedicated service or public method visible to plugins would work better.
* property laws, including trade secret and copyright laws. | ||
* Dissemination of this information or reproduction of this material | ||
* is strictly forbidden unless prior written permission is obtained from | ||
* Adobe. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This copyright header is too big.
Also the year should be the year the file was created, not when it was last updated.
So in this case the copyright header should be:
* Copyright 2023 Adobe
* All Rights Reserved.
Nothing else is needed. Not sure where you got that other paragraph from?
Same remark goes for the other files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's better to be moved to separate file COPYING.txt or LICENSE.txt for better opportunity for update the policies.
It's takes years to remove @author tag (comments block) from files, what will happens if all files requires updated license ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please do not use any year dates, just use the default magento header here:
<?php
/**
* Copyright © Magento, Inc. All rights reserved.
* See COPYING.txt for license details.
*/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new rule from magento coding standard (https://github.com/magento/magento-coding-standard/blob/develop/Magento2Framework/Sniffs/Header/CopyrightValidation.php)
I'm copy from core
Have 94 file same format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It couldn't have been made any longer lol but thanks, I hadn't thought of that either
Description (*)
Same logic when use varnish (https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/PageCache/etc/varnish7.vcl#L84) but for build-in fpc
Related Pull Requests
Fixed Issues (if relevant)
Manual testing scenarios (*)
Questions or comments
Contribution checklist (*)
Resolved issues: