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

Add option to disable layout update handle per product #1105

Closed
tmotyl opened this issue Jul 11, 2020 · 5 comments
Closed

Add option to disable layout update handle per product #1105

tmotyl opened this issue Jul 11, 2020 · 5 comments
Labels
new feature performance Performance related

Comments

@tmotyl
Copy link
Contributor

tmotyl commented Jul 11, 2020

Description (*)

By default Magento adds update layout handle with product ID for each product like: PRODUCT_1234
see:

$update->addHandle('PRODUCT_' . $product->getId());

This on one hand allows to add custom layout update handles through DB for each product through "Custom Layout Update"
However this feature is rarely used and has a performance penalty that for each product Magento generates separate layout cache entry spamming the cache storage with thousands of identical cache entries (one for each product).

Expected behavior (*)

Add configuration option which allows to disable PRODUCT_ layout update handle for shops who don't use it.

Benefits

Improve performance by caching the same value once and lower memory usage on cache backend.

Additional information

Some years ago, I've created an extension for this purposes:
https://github.com/macopedia/Aoe_ProductLayoutHandle

If there is an agreement that this feature could land in the core, then I will prepare a Merge request.

@tmotyl tmotyl added new feature performance Performance related labels Jul 11, 2020
@sreichel
Copy link
Contributor

sreichel commented Jul 11, 2020

Nice. Same for CATEGORY_ handle?

Btw ... we need some DOCs for added features ...

@tmotyl
Copy link
Contributor Author

tmotyl commented Jul 23, 2020

note:
to check if products have custom layout configred in db:

SELECT attribute_id, attribute_code, backend_type
FROM eav_attribute t
WHERE attribute_code in ('custom_layout_update', 'custom_design', 'page_layout', 'options_container') and entity_type_id = 4

This gave me result like:

103,custom_design,varchar
106,custom_layout_update,text
109,options_container,varchar
107,page_layout,varchar

Then I can query tables:

select * from catalog_product_entity_text where attribute_id in (106) and value is not null

and

select * from catalog_product_entity_varchar where attribute_id in (103,109,107) and value is not null

@sreichel the category handle have a similar case, but I would rather have a separate issue for it, as the impact for categories is much smaller then for products and also it's more common to have custom layout for some categories.

One thing to note is that if yoy have some values set in attributes like custom_layout_update, then they should be cleared before enabling this feature (as layout will be cached for the first product rendered).

Also it would be nice to have a warning in the product edit form in "Design" tab that these fields will not have effect (when the feature is enabled).

@kiatng
Copy link
Contributor

kiatng commented Jul 24, 2020

+1 for

Also it would be nice to have a warning in the product edit form in "Design" tab that these fields will not have effect (when the feature is enabled).

I happen to use custom layout update in products a lot. My use cases:

  1. Add custom left or right column.
  2. Change form action URL to custom controller for custom processing.
  3. Set custom button text for the Add to Cart button.

@colinmollenhour
Copy link
Member

has a performance penalty that for each product Magento generates separate layout cache entry spamming the cache storage with thousands of identical cache entries (one for each product)

I don't think the performance penalty is as bad as it used to be before #104 which causes the duplicate layouts to only be stored once. However, I agree that this is very rarely used in my experience.

@fballiano
Copy link
Contributor

I'd leave it as an external module for the ones that need it, please @tmotyl feel free to add your module to https://openmage.readthedocs.io/en/latest/modules/more.html

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature performance Performance related
Projects
None yet
Development

No branches or pull requests

5 participants