View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005767 | OXID eShop (all versions) | 2.3. Extensions (modules, themes) | public | 2014-05-20 10:45 | 2022-02-01 16:56 |
| Reporter | smxsm | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Summary | 0005767: More flexible handling for module templates and blocks | ||||
| Description | It's nice that templates and blocks for modules can be placed inside the module directory and referenced in metadata.php. However, template overriding and individual templates and blocks for different EE subshops aren't supported with the current logic - you only have one fixed template set for all subshops and they can't really be changed by module users / shop owners without the danger of losing the changes with the next module update. The easiest way would be to use "convention over configuration" here and e.g. automatically check for subfolders in the module's tpl directory. So each module could e.g. have a "tpl" and a "blocks" subfolder. Inside those, the module vendor could provide subfolders for subshops, e.g. - tpl/ - 1/ - my_search.tpl - 2/ - my_search.tpl That would solve the problem of using different templates for different subshops. For the second problem, there could e.g. "custom" folders, so below the main "tpl" folder (if there are no subshops, e.g. in the CE version) or below the subshop-folders (for EE with more than one subshop), there could be "custom" folders where the shop owner could place templates or blocks he wants to override, e.g. (inside the module folder): - tpl/ - 1/ - my_search.tpl - custom/ - my_search.tpl - 2/ - my_search.tpl - custom/ - my_search.tpl Same goes for blocks: - blocks/ - 1/ - my_list_block.tpl - custom/ - my_list_block.tpl - 2/ - my_list_block.tpl - custom/ - my_list_block.tpl And the metadata.php should probably only define the block filename. | ||||
| Additional Information | What we are doing right now to at least solve the subshop problem is this: <?php $sMetadataVersion = '1.1'; $shopId = oxRegistry::getConfig()->getShopId(); if($shopId == "oxbaseshop") { $shopId = "1"; } ... 'templates' => array( "page/search/shoptifind_search.tpl" => "shoptimax/shoptifind/out/azure/{$shopId}/tpl/page/search/shoptifind_search.tpl", ... | ||||
| Tags | No tags attached. | ||||
| Theme | All | ||||
| Browser | All | ||||
| PHP Version | any | ||||
| Database Version | any | ||||
|
|
Waiting for PO decision on it. |
|
|
still waiting? :) |
|
|
Actually that was supported back in the Basic theme and still works (at least in 6.1 it still did). We should probably make this more convenient and put it onto a new basis. On the other hand you could just create a subtheme for each subshop and make that a child theme of some of the themes that fits your need most. For a module configuration that really only makes sense for a project module, not for one that is used across projects. |
