Skip to content

Move custom layout updates #187

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

Merged
merged 6 commits into from
Jul 9, 2019
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added design-documents/img/custom_alyout_updates.PNG
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added design-documents/img/custom_layout_select.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
49 changes: 49 additions & 0 deletions design-documents/move-specific-layout-edit.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
### Move category, product and page specific layout updates
Custom layout updates can be provided for specific categories, products and CMS pages via respective forms in the admin
panel - this is how Merchants can customize entity-specific pages to include additional design and functionality.

![alt text](img/custom_alyout_updates.PNG "Layout updates form")
### The problem
Layout updates are defined using XML and certain instructions often using PHP classes. Only developers can
posses knowledge required to create a layout update yet the only way to provide these updates
is via user forms more commonly used by content managers. That's the __1st problem__ - content managers don't

Choose a reason for hiding this comment

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

Are you sure that no one from content managers are using this functionality? Removing it will be backward incompatible change. Not sure that’s good idea at all.
Also removing this functionality will lead to inability to apply some layout update without development teams —> will be more expensive from merchant perspective and will not allow to do quick fixes where it’s needed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

a merchant can just put those files to certain folders themselves, it is slightly harder but definitely more secure

Copy link
Member

Choose a reason for hiding this comment

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

@AlexMaxHorkun Many merchants don't have write access to the filesystem themselves if working with an agency.

need that functionality and it is better to hide it from them to avoid them from executing PHP code on the server.

__2nd problem__ is that we do not allow developers to work with entity-specific layout updates in a developer way.
Copy link
Member

Choose a reason for hiding this comment

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

I think, this is possible currently, we add dynamic layout handle that contain entity identifiers. But it's hard to manage because in the code you depend on dynamic identifiers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But then it's impossible for content managers to control these updates, with the proposed approach content managers will still be able to create staging updates using layout updates prepared by developers.

Copy link
Contributor

Choose a reason for hiding this comment

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

The statement is incorrect, it doesn't say anything about content managers.

Meaning that there is no way to use version control while editing these layout updates.

### Solution
Read custom layout updates from physical files on the server. Convert existing textarea _custom_layout_update_ field
in category/product/cms page forms into a _select_ field where existing custom layout update files could be selected.

To provide layout updates for admin users to select developers will create layout files following existing naming conventions for per-entity layouts
\([page layout handles](https://devdocs.magento.com/guides/v2.3/frontend-dev-guide/layouts/layout-overview.html)\)
like _\<Magento_Theme_module_dir\>/view/frontend/layout/\(catalog\_product\_view\|catalog\_category\_view\|cms\_index\_index\)\_id\_\<entity ID\>\_selectable\_\<Layout update name\>.xml_.
Special _selectable_ handle will be added for category/product/cms pages to pick up these files based on the selected by an admin
update.

Example: a file with the name _app/code/MyCompany/MyExtension/view/frontend/layout/cms_index_index_id_2_selectable_store1update.xml_ is created,
then the select on the home page's edit form (home page has ID = 2) will look like this:

![alt text](img/custom_layout_select.png "Layout updates form")

This way merchants will still be able to manage different layouts for different stores or staging updates. In case
of the example above the developer could also create _cms_index_index_id_2_selectable_anotherstoreupdate.xml_ and
_cms_index_index_id_2_selectable_myjune2019update.xml_ to use for another store or for staging.

This way only developers will be able to change layouts for specific entity pages and be able to use
VCS while creating the layouts.

### Availability to merchants without dedicated teams
The described way to create these selectable updates requires creating a module/theme for a Magento installation which
may make things a bit more difficult for merchants without dedicated teams comparing to being able to just copy-paste
layout XML into the forms. However we could provide a detailed instruction with the link to it thoughtfully provided
near the new selector to guide merchants on how to create these layout files step by step.

### Backward compatibility
In order to preserve backward compatibility existing layout updates will work but users will not be able to create new ones.
When an entity already had a layout update provided via the text area the select will show _'\*Existing layout update\*'_.

This proposals allows to remove the 'Custom layout XML' textarea from admin pages in the next patch release -
existing custom layouts will remain and content managers will still be able to change layouts for specific entities by
creating files on their server and selecting a desired layout even without a development team.