EclipseGc: GaborHojtsy: I'd be happy to write beginnings of a layout module that had this basic approach in it taken care of EclipseGc: GaborHojtsy: so we have a default class in like… the "layout" module and then if we end up with a complex layout system (like say responsive) then the class just needs to be included in a proper PSR-0 namespace and documented in the metadata for it EclipseGc: GaborHojtsy: so a discovery class like so, and processDefinition() in the LayoutManager class that adds a default class to any metadata we return from that discovery EclipseGc: GaborHojtsy: what I was thinking is a discovery class that looks in /templates/ GaborHojtsy: EclipseGc: I've been reading up on Had a good discussion about this with EclipseGC:
#Hotswitch into core Patch#
The patch includes a couple static layouts for demonstration as well.
#Hotswitch into core install#
Which lets us make modules and install profiles even provide layouts either as static pre-built layouts (using the same file structure as themes) or dynamic layouts by implementing the plugin interface provided by the layout system. This file defines the layout, its name, regions, etc. Example file contents:įooter_firstcolumn: 'Footer first column'įooter_secondcolumn: 'Footer second column'įooter_thirdcolumn: 'Footer third column'įooter_fourthcolumn: 'Footer fourth column' yml) would be located in the same directory.
A file named page.yml (again the name is arbitrary for the developer, but this defines the layout as bartik_page - the first part being the theme name, the second being the layout name, and the template file being looked for is derived from the.There would optionally be an icon for the layout in the same directory.yml file below, the important piece is that it is co-located with the layout definition) Instead of bartik/css/layout.css, the layout style becomes bartik/layout/page/layout.css (or bartik/layout/page/page.css), again the file name is declared in the.Instead of bartik/templates/, the template would be at bartik/layout/page/ (where the layout subdirectory name "page" is arbitrarily picked by the theme and the tpl.php name consists of the theme name and the filename for the.For one layout, the corresponding CSS styles, tpl.php template and possibly an icon for the layout would be contained in this directory as well as a simple. Themes should explicitly declare their page layouts, so instead (, etc) type of files among other templates, themes would have a layouts subdirectory, which would contain directories for each layout defined.
This issue is about defining the list of layouts provided. If we don't want to sidestep theme page templates, making it possible to switch between (potentially exclusively theme provided) layouts requires the theme to provide a list of the layouts included within and Drupal to provide a user interface to switch between them. It is not currently possible to switch page layouts by any other means such as making it configurable as to which page layouts are used for which paths / path patterns or other conditions, unless there is a module altering ( $variables) overriding what the theme provided entirely or sidestepping page themeing altogether. As well as theme(), where the template is chosen based on these suggestions. As can be seen in template_proprocess_page() where page template file suggestions such as page_node, page_node_%, page_node_1, and page_node_edit are produced (for a page like node/1/edit.
It is already possible to have different page layouts/templates for pages with an existing discovery mechanism for templates.
0 kommentar(er)
