Design Manager files in VSC and why I bumb autoincrements

For discussion and questions related to CMS Specific templates and stylesheets (CSS), and themes. or layout issues. This is not a place for generic "I don't know CSS issues"
Locked
deactivated010521

Design Manager files in VSC and why I bumb autoincrements

Post by deactivated010521 »

The primary keys in the cms_layout_templates.id and cms_layouts_stylesheets.id do autoincrement. As soon as you add a new template or stylesheet in the Design Manager the id of one of these tables is incremented by 1.

When importing a new theme (Design Manager -> [Designs] -> Import Design) the import scripts adds new templates and stylesheets and is using the last autoincrement value +1.

Having templates and stylesheets in a version control system and sharing these between different CMSMS installations, can give a mismatch after you have completed a theme.xml import and file export. When this occurs you have a hard time to follow changes, this sucks.

Sadly I can not change the way the CMSMS theme system works.

I am a fan of a pure file based theme system. When you can store themes in a seperate folder and don't have to rely on filenames with id's chosen by CMSMS changing and updating themes is trouble-free.

CMSMS started with database based theming and adapted to a hybrid solution (database based with filebased import/export). This is a huge improvement for developer workflow, but it lacks version control as soon as themes are imported across many installations with different autoincrement values.

By bumping the auto increment values to 1000 before the theme.xml import and 2000 after it is **a bit** easier to keep numbers insync.

Bumping is not a **perfect** solution for all exchanges: When renaming or deleting items from the Design Manager or having templates with dito names as in the theme.xml, it still can get messy.

For who is intrested to start a discussion:

- What would be the perfect theme setup for you?
- Do you use a Version Control System for your themes?
- Are you sharing the same theme across different domains and installations?
- How do you track back changes to the original theme, when doing and how?
- Do you have a development workflow or special way of working on themes?
- Do you have any theming troubles or satisfied theming works now?
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Re: Design Manager files in VSC and why I bumb autoincrement

Post by calguy1000 »

As we finally learn that we don't make 'websites' we build applications (the application just happens to be built with CMSMS), we also learn that putting as many things in files as possible is the best way to go. I have been doing this for the last year or two and it works great. I much prefer ssh-ing into a remote host, or using sshfs and using my favorite editor to edit templates and stylesheets. And all files can be committed to svn or git... so I can track all of my changes over time.

Most modules (including core modules) allow using a template resource string instead of a CMSLayoutTemplate template name. i.e: {news detailtemplate='file:news-detail.tpl'}. The only thing that you cannot specify a template file for is content pages.

With CGSmartNav I can custom build my navigation and restrict my use of content pages to a 'default page', and to a few pages (like help, and about, and the team page) that may be editable by an editor, and a few utility pages like a 403 and 404 handler.

The latest app I have been working on uses FEU, Selfreg, CGBetterForms, and a few custom modules... has dozens of actions, and only about 6 content pages. most of which are special purpose pages (multi-language app help, 403 handler, 404 handler, etc). CGSmartNav allows me to build the navigation in a template file exactly the way I want it. (As an added bonus, CGml allows me to make that navigation multi-language).

My template actually makes use of a custom plugin, and good old fashioned 'make' files to concatenate stylesheets and templates scripts (correction). I could of course use lesscss/sass, and other tools to combine this stuff... but for the most part concatenation works fine for what I need.

CMSMS 2.3 gets rid of UDT's in the database (they just become PHP files). And puts third party stuff into the /assets directory so that we can hopefully limit what is committed to svn/git to that directory instead of all of CMSMS.

The last hurdle is of course content pages. In version 2.3 I've been playing with the ability to specify a template filename instead of a template id in content pages. The functionality is not finished yet. But when it is, all of the theme stuff (css, templates, fonts, images, ancillary plugins) can be, and will be in files. And then most applications using files will be able to actually disable the DesignManager module, and maybe even un-install it.

Ideally, I think we should generally move away from storing theme and app functionality stuff in the database. UDT's, CSS, templates, should be stored as files. But I am certain that I'll receive some blowback for that thought (already have).
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Re: Design Manager files in VSC and why I bumb autoincrement

Post by calguy1000 »

Ooh, here's a tip I have been using that really helps me put most things into files.

In my page template (which is still in DesignManager, but exported to a file in /assets/templates) I include another template that i called 'app_settings'. i.e: {include file='file:app_settings.tpl'}

In app_settings.tpl I do a bunch of things mostly related to setting the correct language, translating the page title, etc. But I also use {cms_module_hint} to pre-set parameters for certain module calls. i.e.:

Code: Select all

{cms_module_hint module=FrontEndUsers logintemplate='file:feu_login_form.tpl'}
{cms_module_hint module=FrontEndUsers changesettingstemplate='file:feu_changesettings_form.tpl'}
Then... my CGSmartNav Navigation looks something like:

Code: Select all

{nav_create name='Nav'}
{cgml_setrealm realm='Nav'}

{* a whole bunch of items similar to this *}
{cms_action_url module=FrontEndusers action=login assign='url'}
{cg__ k='login' assign=txt}
{nav_add_item nav=Nav name=login url=$url text=$text}

{* render the nav we just built, using a file template in the same directory *}
{* could have done this template arg with cms_module_hint too but, meh *}
{CGSmartNav nav=Nav template='file:UserNav.tpl'}
--
Now my URL's in my nav are pretty (there is no logintemplate=something} on the urls, but I can still use a custom template FILE. and with CGml, the navigation is mult-language capable.
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Re: Design Manager files in VSC and why I bumb autoincrement

Post by calguy1000 »

My assets directory currently looks like:

/assets
-- /templates (* file templates for frontend stuff, including page templates, general use (generic) templates, and module templates for frontend actions. Module templates are converted to use {CGml} instead of {$mod->Lang()}. *)
-- /css
-- /plugins (* custom plugins I have written for my app *)
-- /images
-- /CGml (* translations for frontend stuff *)
-- /js
-- /module_custom
-- -- /FrontEndusers
-- -- -- /lang (* overridden lang strings for the admin panel *}
-- -- -- /templates (* overridden templates for the admin panel *}
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Re: Design Manager files in VSC and why I bumb autoincrement

Post by calguy1000 »

So... with this setup, I have:
- All templates in files
(page templates are still tied to DesignManager, but at least I can edit and manipulate them as files).
- All CSS in files
- Custom built, multi-language navigation
- Pretty URLS (as long as modules export pretty urls to the actions I am calling)
- Very few content pages (No duplicated content trees)
- The ability for editors to edit content on the subset of pages I create for them
* OR the ability for editors to add content pages below a section header at will.
- Everything but the actual content or data is stored in files so I can save the app to SVN/Git.
(application data, and content is still in the database)
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
deactivated010521

Re: Design Manager files in VSC and why I bumb autoincrement

Post by deactivated010521 »

Thank you for your comprehensive explanation. Answer like this bring new ideas and give a good insight on ways to structure out templates.

As said I already try to do as much as possible in .tpl files, pushing this further till there are only "Core::Page / Content Pages" left in the Design Manager is something I can improve on.

A combination of template inheritance, include file and {module template=’file:name.tpl’} are key techniques, and easy to implement.

For most sites a fixed set of layouts, is provided. (nav left, content right | content left, nav right | full widht | some 2,3,4 column), 6 to 8 pages per site max.

Making a split in “pure text” content pages and app like pages with CGSmartNav and {ModuleTags} is a good takeaway.

I have never touched the CGSmartNav module. I can imagine that this module can handle generate navigation menus, and stops putting {ModuleTags} in Content Manager/Content fields. Till now I have only touched {cms_module_hint} lightly, exploiting this functionality for template.tpl inclusion is a good use case.

It is obvious that putting {ModuleTags} in the Content Manager is a big no-no, as quick fix I have been quilty of this, it can be done better.

I understand that you have settled on ‘make’ files for stylesheet and script building. I have implemented Bower/Gulp/Grunt and Webpack setups these tools are powerful but constantly changing and not always enjoyable.

But for tracking .js and .css libary and framework versions npm / packages.json is something I like much. In a ES6 setup (with transpiling to ES5) you can load .css dependencies as: import style from './file.css'

Webpack has different loader modules that can track dependencies. When you import a .css file that has references to webfonts / images or other static assets these can be tracked down and bundled when running the build script. This is something that is pretty hard to do in an own written "make" file.

For UDTś I stick .php files in a seperated folder a small .php utility script I have wirtten is able to add these automatically to Extentsion → User Defined Tags ($include_file = "$root_path/assets/udt/name.php).

Love the fact that CMSMS 2.3 is moving away from UDT’s in the database. If specifying template filenames instead of template idś for content pages is a hurdle you can take this would be a great breakthrough.

In the meantime I repeat to myself: How can I solve this with files only, what if there was no Design Manager and Content Manager module.
calguy1000
Support Guru
Support Guru
Posts: 8169
Joined: Tue Oct 19, 2004 6:44 pm
Location: Fernie British Columbia, Canada

Re: Design Manager files in VSC and why I bumb autoincrement

Post by calguy1000 »

To more directly answer your question:

- On my apps that we are working on, we do not manage multiple themes on one installation. Only one at a time.
- All files are committed to SVN (everything from the root directory down). This is because of the various config files needed, the modules, various javascript files, and the fact that service workers and other files need to be in the root directory of the installation.
- We have 'development', 'staging' and 'rollout' versions of the applications so that we can work on theming and development etc. without affecting the live application.

So in essence we are doing things this way because we are working on an 'app' not merely a theme. Our app has one look and feel. We have no need to re-use our theme on different installations.

if we were to treat a theme as a package, for use on multiple installations. then I guess I would commit it to a different svn/git location and manage it as an 'external project' to the main app.. so that I could change things in the main repository and then just do an 'update' in each location.

I would want everything to be in one folder, including the page templates (which is difficult right now). so I may try to use a symbolic link from the exported DesignManager file to the proper page template file. Other than that one limitation with page templates I think CMSMS handles themes well.

I was discussing this yesterday in the cmsms dev channel. IF you were in a situation where your entire was contained in a folder below /assets then it maybe nice and useful to have a simple module to allow working with themes easier. with utilities like:

- A smarty resource like: theme:ThemeName;template.tpl
- A smarty plugin like {set_theme}
- plugins like {theme_url} and {theme_path} etc. So your template files could be self contained, and you could easily {include} sub templates for your theme. And perhaps they could be in another location other than /assets

These tools are easy to develop, but are just 'nice-to-haves' . CMSMS theming is pretty powerful as it is.
Follow me on twitter
Please post system information from "Extensions >> System Information" (there is a bbcode option) on all posts asking for assistance.
--------------------
If you can't bother explaining your problem well, you shouldn't expect much in the way of assistance.
deactivated010521

Re: Design Manager files in VSC and why I bumb autoincrement

Post by deactivated010521 »

For themes as package in a separate repository git has submodules, something inline with svn external projects.

Since I already use npm for thirth party CSS and JS projects I see possiblities to use that for CMSMS theme (.tpl) files aswell.

Code: Select all

~ npm install https://gitrepoaddress/mycms_theme#commit
Npm can work on git tags or branches, a package.json file the standard for npm can be the medium for distribution and version tracking.

As far as I know git submodules do only work on branches not on tags. Eitherway a seperate repo is a good call.

A Theme Utility module where you can pass in a configuration object with themename, paths, settings and such sounds like a good idea.

Thinking out loud

For CMSMS version < 2.3 I vaguely remember "security" restrictions from what path you can include templates are in place. If your templates lives outside a modules or templates directory and CMSMS core 2.3 does not allow to call these: A Theme Utility module can provide a mechanism to support that:

Code: Select all

{$theme_config =[
['path'=>'custom_path', 'theme_name'=>'MyTheme']
]}

{theme_utilty config=$theme_config}

{include file=./custom_path/template.tpl}
For app development perhaps you need a themed controlpanel (seperated from the CMSMS /admin area).

Spliting out themes in public, authorized and admin layouts can be something you like to support.

eg.

Code: Select all

{$theme_config.area='authorized'}
{$theme_config.path='custom_path/authorized'}
deactivated010521

Re: Design Manager files in VSC and why I bumb autoincrement

Post by deactivated010521 »

By extending CMS_Fixed_Resource_Custom I have created a $smarty resource that can load .tpl files from a directory I have configured.

{include file='my_file:MyTemplate.tpl'}

The only problem when I export a design using this tag [Design Manager → Designs (Export)] I get: Only templates that use {include} with cms_template resources can be exported

I do not want to export my_file:MyTemplate.tpl it self but the page template making that include.

Did I extend the wrong "resource" class or do I have to do something different to make exports from the design manager work?
deactivated010521

Re: Design Manager files in VSC and why I bumb autoincrement

Post by deactivated010521 »

A side-note: There is nothing wrong with the custom Smarty resource that I have created.

The Design Manager "export design to .xml" does only allow includes in the format of:

Code: Select all

{include file='cms_template:tplName'}
As implemented in:

Code: Select all

modules/DesignManager/lib/class.dm_design_exporter.php
I am not that concerned about exporting Designs from the DesignManager, it is just the way it works.

Ofcourse also the same "Only templates that use {include} with cms_template resources can be exported" warnings appear: if you stick one of the following fragments in a page template and try to do a .xml export:

Code: Select all

{include file='file:app_settings.tpl'}
{include file='module_file_tpl:ModuleName;template_name.tpl'}
deactivated010521

Re: Design Manager files in VSC and why I bumb autoincrement

Post by deactivated010521 »

calguy1000 wrote: I was discussing this yesterday in the cmsms dev channel. IF you were in a situation where your entire was contained in a folder below /assets then it maybe nice and useful to have a simple module to allow working with themes easier. with utilities like:

- A smarty resource like: theme:ThemeName;template.tpl
- A smarty plugin like {set_theme}
- plugins like {theme_url} and {theme_path} etc. So your template files could be self contained, and you could easily {include} sub templates for your theme. And perhaps they could be in another location other than /assets

These tools are easy to develop, but are just 'nice-to-haves' . CMSMS theming is pretty powerful as it is.
I came up with a solution where I have made a Smarty resource and introduced a configuration file.

/assets/configs/theme.conf

Code: Select all

themePath = "themes/bootstrap/" # load .tpl files relative to assets/templates
or

Code: Select all

themePath = "yourcustom_smarty_resource:" # load .tpl files relative to the directory that you allow in your smarty resource
From your templates you can call generic blocks like:

Code: Select all

{config_load file='theme.conf'}
{include file="{#themePath#}partial.tpl"}
if you like to switch themes you can play with the themePath config eg.

Code: Select all

themePath = "themes/foundation/"
If you need other configurations for assets directories you can add these to /assets/configs/theme.conf

Code: Select all

jsPath = "" 
imagePath = "" 
...
deactivated010521

[Solved] Design Manager files in VSC and why I bumb autoincr

Post by deactivated010521 »

My themes are now running on "files" only. The only thing I stick into the Design Manager are page templates (Core::Page) only.

From the page templates I make an {include} where I add the actual {content} blocks and markup.

Working with assets/configs/theme.ini to specify where my theme templates are was not completely free. For some reason CMSMS uses the ./admin/configs/ directory when inside the back-end and the /assets/configs/ directory when on the front-end. I have heard the "security reasons" but it is a weird twist from Smarty defaults.

https://www.smarty.net/docs/en/language ... g.load.tpl

After all:

- I only had to create a custom Smarty resource by extending CMS_Fixed_Resource_Custom
- Add /assets/configs/theme.ini
- Tweak my themes and move all templates to: ./assets/themes/THEME_NAME/templates/
- Modify my build tool so it can read theme.ini and knows where all resources are.

The themes/THEME_NAME/ directory is now standalone and does contain all sources to build a website themes/THEME_NAME/{css,js,images,svg,webfonts...}.

Version control can now be managed with: svn external projects, git submodules
or npm or composer over svn or git.

The good news:

With this setup I barely have to touch the design manager. When a websites needs a new theme I only have to create a new folder to: ./assets/themes/NEW_THEME and switch some variables inside /assets/configs/theme.ini

I can distribute my themes trouble free everything is now self-contained.
Locked

Return to “Layout and Design (CSS & HTML)”