-
Notifications
You must be signed in to change notification settings - Fork 9.4k
#7065 Allow page.main.title block to decide if title should be translated #11709
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
Conversation
*/ | ||
public function __construct(Template\Context $context, array $data = []) | ||
{ | ||
$this->translateTitle = isset($data['translate_title']) ? (bool) $data['translate_title'] : true; |
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.
Having flags in code to switch its behavior is almost never a good idea.
category and product pages get their titles translated when they shouldn't
Why not simply introduce another title block implementation, RawTitle
or something, and use it on mentioned pages?
General note: please always start contribution from 2.2-develop
branch, a default one in this repo.
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.
Noted
86d39c5
to
a04ac2f
Compare
@orlangur Updated with suggested changes |
</arguments> | ||
<block class="Magento\Catalog\Block\Category\Rss\Link" name="rss.link" template="Magento_Catalog::category/rss.phtml"/> | ||
</referenceBlock> | ||
<referenceBlock name="page.main.title" remove="true"/> |
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 believe I read somewhere that changing block name is backward-incompatible change but http://devdocs.magento.com/guides/v2.2/contributor-guide/backward-compatible-development/index.html#magento-apis is quite vague about it.
Can we preserve page.main.title
name but just change block type on needed places?
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 have thought the same thing, I had problems in the past removing blocks and trying to re-add them with the same name. I'm trying now to override block class definition by setting the same block name, so full block node gets overriden during merge, I keep you updated.
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.
Probably it can be done via reference: http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/layouts/xml-manage.html#set_template
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 think this is for defining / changing arguments for a given block, like the template, but for a given (already instantiated) block. I've achieved changing block without changing name redefining the block, see 584cfd3
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.
Good! But, will replacing class
using referenceBlock
work? It would allow to not add additional referenceContainer
and generally referencing is safer that redeclaring.
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 don't think this is possible without rewriting xml node block redefining it with the same name, I've been investigating this possibility, and this is what I found.
Here is the xsd definition for referenceBlock
, from Magento/Framework/View/Layout/etc/elements.xsd
:
<xs:complexType name="blockReferenceType" mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="action" type="actionType" minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>
Argument name must be unique in scope of action.
</xs:documentation>
</xs:annotation>
<xs:key name="blockReferenceActionArgumentName">
<xs:selector xpath="argument"></xs:selector>
<xs:field xpath="@name"></xs:field>
</xs:key>
</xs:element>
<xs:element ref="arguments" minOccurs="0" maxOccurs="1"/>
<xs:element ref="block" minOccurs="0"/>
<xs:element name="container" type="containerType" minOccurs="0"/>
<xs:element ref="referenceBlock" minOccurs="0" />
<xs:element ref="referenceContainer" minOccurs="0"/>
<xs:element ref="uiComponent" minOccurs="0" />
</xs:choice>
<xs:attribute type="elementNameType" name="name" use="required"/>
<xs:attribute type="xs:string" name="template" use="optional"/>
<xs:attribute type="xs:boolean" name="display" default="true" use="optional"/>
<xs:attribute type="xs:boolean" name="remove" use="optional"/>
</xs:complexType>
To change the class, I think it should be done redefining class as a referenceBlock
attribute: <referenceBlock name="page.main.title" class="Magento\Theme\Block\Html\RawTitle">
, thing that is not allowed by xsd definition (it only allows name, template, display and remove attributes for referenceBlock
).
The rest of the xsd declaration are arguments for the already defined block class, or actions over it, or declaring children blocks, or referencing other blocks, containers or uiComponents.
I have even tried to find any example of any layout xml file trying to perform an action like this with no success. No clue of this kind of usage even in layout directives tests under Magento/Framework/View/_files/layout_directives_test.
If you still don't like the idea of doing this task the way it is done, I could still use $this->eventManager->dispatch('layout_render_before_' . $this->request->getFullActionName());
event placed in \Magento\Framework\View\Result\Layout::renderResult
, or tweak it in some way in \Magento\Catalog\Block\Category\View::_prepareLayout
and \Magento\Catalog\Block\Product\View::_prepareLayout
, but this way I think you may lose some control about this, control that you may have per theme editing layout xml 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.
thing that is not allowed by xsd definition
Thanks, that's pretty answers my question. Current implementation with declarative approach instead of some PHP code seems best to me. Will check if there was some intentional decision to disallow class overriding.
Did class overwriting work properly by the way if you expand XSD?
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.
Surprisingly, yes, it does, this way:
- At Magento/Framework/View/Layout/etc/elements.xsd:
- At Magento/Catalog/view/frontend/layout/catalog_product_view.xml:
So yes, it works. Have you found any intentional decision for this not being allowed by xsd?
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.
Nah, didn't ask yet. Asking now. Big thanks for checking!
… RawTitle block, to avoid category and product names being translated Unit tests for new RawTitle block
667a892
to
584cfd3
Compare
@orlangur I'm facing this issue with static tests, new block is expected to be marked as @api if referenced in default layouts: I thought I wasn't supposed to add @api annotation for any added class, what should I do? |
Yeah-yeah, I noticed it on Bamboo as well, forgot we already run all static tests on Travis :) No need to do anything from your side, I'll ask if architect approval is required and add |
Hi @orlangur , |
@super-user-test-tool unfortunately, only members of the maintainers team are allowed to assign developers to the pull request |
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.
Hi there @adrian-martinez-interactiv4, the time has come to rework implementation considering #18933 😎
@adrian-martinez-interactiv4 , @orlangur hey guys, any progress on this? |
@sidolov I've reached Adrian in Slack yesterday, he is now aware of this PR and there are high chances to update it :) |
@adrian-martinez-interactiv4 , @orlangur any updates? |
@adrian-martinez-interactiv4 , I am closing this PR now due to inactivity. |
Hi @adrian-martinez-interactiv4, thank you for your contribution! |
Related to #7065.
Layout block with name 'page.main.title', related with block
\Magento\Theme\Block\Html\Title
, always translates title before being returned. Unfortunately, category and product pages get their titles translated when they shouldn't (if wanted so, a different value should be defined for category / product at store view level in admin).Description
This may be the desired behaviour for most parts of the system, but 'page.main.title' always translates the title. Because of that, that block is now capable to handle the boolean argument
translate_title
, injected in constructor and defined via layout xml, to decide whether it has to translate the title or not.As it used to translate all titles before, impact has been minified making
\Magento\Theme\Block\Html\Title
translate all titles by default, unless it has been told to do the opposite. This is the case of category and product pages by now, but there could be other pages interested in title not being translated.I'm aware that arguments translation and be done via
translate
attribute, like inMagento/Catalog/view/frontend/layout/catalog_product_compare_index.xml
:But this only works for static values, that get translated when layout files are parsed and layout is generated. For products and categories, this value is set afterwards in _prepareLayout method.
Fixed Issues (if relevant)
Manual testing scenarios
Also checked home page, and it still gets it title translated.
Contribution checklist