Skip to content
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

Fix loss of page_cache cache_dir setting from di.xml #22228

Merged
merged 3 commits into from
Oct 1, 2019

Conversation

Vinai
Copy link
Contributor

@Vinai Vinai commented Apr 8, 2019

Description

In a native Magento 2 installation both the page_cache and the default cache is stored in the var/cache directory. The var/page_cache directory is not used, even, though it is configured in di.xml.

This makes it impossible to use bin/magento cache:flush full_page to only clear the FPC, as it will also flush the cache directory.

The reason is any cache options configured in di.xml are lost if any configuration for a cache frontend is present in app/etc/env.php.

During the Magento installation a cache id_prefix for both the default and the page_cache frontends are written to the app/etc/env.php.

The bug was introduced by the PR: #18641
(note: the issue that was solved by that PR is also relevant for non-filesystem cache backends.)

In the method body of \Magento\Framework\App\Cache\Frontend\Pool::_getCacheSettings the original comment read:

Merging is intentionally implemented through array_merge() instead of array_replace_recursive()
to avoid "inheritance" of the default settings that become irrelevant as soon as cache storage type changes

This reasoning of the original comment applies only if the backend type is changed, but not if an option is added to be used with the default.

Fixed Issues

This PR will merge the deployment configuration and the di.xml configuration using array_replace_recursive instead of array_merge, as cache settings that are not used by other cache backends don't do any harm, and still can be changed by overwriting them when needed.

An alternative implementation of the solution checked if the page_cache backend was set to a different value of the default cache frontend, but that added a lot of additional coupling and in favor of simplicity I believe the solution in this PR is better.

The above fix revealed a bug that was masked before, namely that the when the built in page cache was is used, moving a category does not clean the appropriate cache records.
With varnish this issue does not occur because there the category top navigation is rendered as an ESI block, which is associated with all category ID cache tags (cat_c_<ID>).
The page cache records however are only associated with the generic category cache tag (cat_c).
Moving a category only cleans records that are associated with the category ID cache tag.
The solution is implemented as an event observer for the category_move event, which cleans the generic category cache tag if the built in page cache is used.

Manual testing scenarios

  1. download source Magento (tarball or composer or github clone)
  2. install Magento (ui or cli)
  3. access a frontend or adminhtml page in the browser
  4. With the bug: var/page_cache is empty and var/cache is not empty
  5. Run bin/magento cache:flush full_page
  6. Check var/cache is empty

After the patch is applied var/page_cache will no longer be empty after a page is accessed and bin/magento cache:flush full_page will only flush var/page_cache

Contribution checklist

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds on Travis CI are green)

@m2-assistant
Copy link

m2-assistant bot commented Apr 8, 2019

Hi @Vinai. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento-engcom-team give me test instance - deploy test instance based on PR changes
  • @magento-engcom-team give me 2.3-develop instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

Copy link
Member

@larsroettig larsroettig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Steps for quality:

  • ✅ Review please see comments
  • ❗️ Travis build
  • ❗️ Manual Testing


$this->assertSame($testData, $pageCache->load($testKey));
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Empty Line missing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. But I'm curious what is the reason for this rule? It seems very arbitrary and useless to me...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@larsroettig didn't get which line you talked about...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before I changed the commit line 59 was missing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Vinai I don't think it's needed. Basically any missing line is not worth commenting - phpcs should catch all needed.

@Vinai
Copy link
Contributor Author

Vinai commented Apr 9, 2019

Thanks for the review @larsroettig, sorry for being a little bitter sometimes. I really do appreciate you taking the time to look it over 👍

@Vinai
Copy link
Contributor Author

Vinai commented Apr 9, 2019

The Codacy warnings are related only to outdated rule names in the ruleset:

  • The "WordPress.XSS.EscapeOutput" sniff has been renamed to "WordPress.Security.EscapeOutput". Please update your custom ruleset.
  • The "WordPress.CSRF.NonceVerification" sniff has been renamed to "WordPress.Security.NonceVerification". Please update your custom ruleset.
  • The "WordPress.WP.PreparedSQL" sniff has been renamed to "WordPress.DB.PreparedSQL". Please update your custom ruleset.

Bildschirmfoto 2019-04-09 um 04 50 49

Copy link
Contributor

@orlangur orlangur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Vinai!

Codacy can be completely ignored, I heard about plans to turn it off but not sure why it's still here.

use PHPUnit\Framework\TestCase;

/**
* This is prime example for a senseless comment that only exists to satisfy the coding standard.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel your pain, this is one of mine top priorities in phpcs-related stuff, annoys me since @return void was introduced.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unfortunately Magento code is there for everybody to see and interpret and we have to do yet better, meaningful, rhetorical comments

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thankfully it's no longer necessary to add useless comments due to the updated phpdoc coding style guide!
I'll remove the docblock.


$this->assertSame($testData, $pageCache->load($testKey));
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@larsroettig didn't get which line you talked about...

*/
$cacheInfo = $this->deploymentConfig->getConfigData(FrontendPool::KEY_CACHE);
if (null !== $cacheInfo) {
return array_merge($this->_frontendSettings, $cacheInfo[FrontendPool::KEY_FRONTEND_CACHE]);
return array_replace_recursive($this->_frontendSettings, $cacheInfo[FrontendPool::KEY_FRONTEND_CACHE]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's see if it won't break anything else.

@magento-engcom-team
Copy link
Contributor

Hi @orlangur, thank you for the review.
ENGCOM-4717 has been created to process this Pull Request

@VasylShvorak
Copy link
Contributor

✔️ QA passed

@nmalevanec
Copy link
Contributor

nmalevanec commented Apr 15, 2019

@Vinai, could you please check the following failures in unit tests?
https://travis-ci.org/magento/magento2/jobs/517594558#L1195

@Vinai
Copy link
Contributor Author

Vinai commented Apr 15, 2019

@nmalevanec Thank you for notifying me - I fixed and expanded the unit test cases.

@nmalevanec
Copy link
Contributor

@Vinai, unfortunately we've encountered some problem after your fix. Could you please take a look at such scenario:

  1. Navigate to admin area
  2. Create two categories with structure like:

image

  1. Observe storefront index page

image

  1. Move cat2 to the same level as cat1

image

  1. Observe storefront index page

Expected result

image

Actual result

image

@Vinai
Copy link
Contributor Author

Vinai commented Apr 16, 2019

Good catch! My guess is the fix uncovered another bug that was masked by the regular cache and the page cache sharing the storage folder. I'll check what is causing the issue.

@magento-engcom-team
Copy link
Contributor

Hi @sivaschenko, thank you for the review.
ENGCOM-4717 has been created to process this Pull Request
✳️ @sivaschenko, could you please add one of the following labels to the Pull Request?

Label Description
Auto-Tests: Covered All changes in Pull Request is covered by auto-tests
Auto-Tests: Not Covered Changes in Pull Request requires coverage by auto-tests
Auto-Tests: Not Required Changes in Pull Request does not require coverage by auto-tests

@engcom-Delta
Copy link
Contributor

✔️ QA passed

@ihor-sviziev
Copy link
Contributor

ihor-sviziev commented Sep 16, 2019

Hi @sidolov,
Is there any updates since August 9? Why it's still not merged?

@ihor-sviziev ihor-sviziev added the Auto-Tests: Covered All changes in Pull Request is covered by auto-tests label Sep 16, 2019
@sidolov
Copy link
Contributor

sidolov commented Sep 16, 2019

Hi @ihor-sviziev , we faced the build failures with provided changes. I'll add more info about failures as soon as possible

@Vinai
Copy link
Contributor Author

Vinai commented Sep 17, 2019

@ihor-sviziev @sidolov Thanks for the follow up! I'm quite curious hear what issues occurred during the build and am happy to help fixing them if I can.

@magento-engcom-team magento-engcom-team merged commit 989058c into magento:2.3-develop Oct 1, 2019
@m2-assistant
Copy link

m2-assistant bot commented Oct 1, 2019

Hi @Vinai, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.