<referenceBlock name="product.info.options.configurable">
<action method="setTemplate">
<argument name='template' xsi:type="string">Namespace_ModuleName::product/view/type/options/configurable.phtml</argument>
</action>
</referenceBlock>
3 After lot of struggling i was not able to override template file because of below code in
Magento\Swatches\Block\Product\Renderer\Configurable
class Configurable extends \Magento\ConfigurableProduct\Block\Product\View\Type\Configurable
{
/**
* Path to template file with Swatch renderer.
*/
const SWATCH_RENDERER_TEMPLATE = "Magento_Swatches::product/view/renderer.phtml";
/**
* Path to default template file with standard Configurable renderer.
*/
const CONFIGURABLE_RENDERER_TEMPLATE = "Magento_ConfigurableProduct::product/view/type/options/configurable.phtml";
/**
* @codeCoverageIgnore
* @return string
*/
protected function getRendererTemplate()
{
return $this->isProductHasSwatchAttribute ?
self::SWATCH_RENDERER_TEMPLATE : self::CONFIGURABLE_RENDERER_TEMPLATE;
}
Above constant doesn't allow me to override template how should i do that ?
Override Magento\Swatches\Block\Product\Renderer\Configurable via plugin. Use method beforeSetTemplate.
http://magento.stackexchange.com/questions/98636/update-const-template-at-magento-2-class
Thank you for the updates, Yes, i already did that.
Look at the below code written in xml, Below code is of no use. It should allow to override template using xml as template path is defined in xml. don't you think so ?
vendor/magento/module-configurable-product/view/frontend/layout/catalog_product_view_type_configurable.xml
<referenceBlock name="product.info.options.wrapper">
<block class="Magento\ConfigurableProduct\Block\Product\View\Type\Configurable" name="product.info.options.configurable" as="options_configurable" before="-" template="product/view/type/options/configurable.phtml"/>
</referenceBlock>
Correct, since the template filename is harcoded as a class property, it seems to override any xml update. I do think hardcoding that into core files is not the best practice, however, plugins certainly give the ability to modify that behavior with no major issues.
This should be either well documented or removed because what if a front-end developer comes up with this issue ? his gonna have a hard time on this one. Overriding templates should be always possible via XML I agree with you.
Good luck !
Thanks, Can we expect these changes in upcoming release ?
Hello @mkastaneda
I've got a similar problem in vendor\magento\module-catalog\view\adminhtml\layout\CATALOG_PRODUCT_COMPOSITE_CONFIGURE.xml
where someone forgot to add the name for the block:-
<block class="Magento\Catalog\Block\Adminhtml\Product\Composite\Fieldset\Options" template="catalog/product/composite/fieldset/options.phtml">
.....
</block>
and I can't reference it in my extension's layout.
Can someone please add a name.
Same issue can't override:
catalog\view\adminhtml\layout\CATALOG_PRODUCT_COMPOSITE_CONFIGURE.xml
Please fix this issue, it's super quick to fix and causes big problems. Now as a work around I have to write ugly overrides to have my changes.
@yagupatel, thank you for your report.
We were not able to reproduce this issue by following the steps you provided. If you'd like to update it, please reopen the issue.
We tested the issue on 2.3.0-dev, 2.2.0, 2.1.9
@magento-engcom-team I reproduced the issue using CE edition version 2.1.10
Due to the hard coded template path here
\Magento\Swatches\Block\Product\Renderer\Configurable class - line 41
you can't override the Magento_ConfigurableProduct::product/view/type/options/configurable.phtml
template in custom modules using the typical layout/template override mechanism.
I had to create a Plugin class as indicated by @mkastaneda
Why does this Magento module use hard coded template paths?
Will this be changed in future releases?
These hard coded paths are annoying to deal with for developers.
Confirmed this is still an issue on Magento 2 CE 2.2.3
@magento-engcom-team How can I reopen this issue? The problem is still there in Magento Open Source 2.3.3.
Most helpful comment
@magento-engcom-team How can I reopen this issue? The problem is still there in Magento Open Source 2.3.3.