I customize template overrides like:

templates/xero/html/com_content/category/blog_item.php

But it appears that when updating the template to v1.3.2, that file was over-written. Even though it does not state that blog_item.php was changed: docs.joomlabamboo.com/joomla-templates/xero-changelog

Is this true?

If so how should I go about customizing the overrides that come with the template so not to loose it upon updating?

Hi Jeff,

Yes thats a Joomla wide issue actually. If you change any file that is int he template package it will get overwritten. It's annoying but it's why I add the changed files list so to ensure folks who have overridden can be sure not not overwrite their customisation.

Thanks

Anthony,

I suspected that, and of course why I run a backup before any updates, but I am bringing it to your attention that the files that were overwritten were not listed in the changelog.

Here is what is listed:
Changed Files

templateDetails.xml
Added css/frontend-edit.css
added html/com_config/modules/default_options.php
tpls/blocks/social/facebook.php
html/mod_finder/default.php
less/mediaqueries.less
less/menu.less
less/modules.less

But after the update, I had to restore, from backup, the files like this one:
templates/xero/html/com_content/category/blog_item.php

Hi Jeff,

Yes thats correct.

Any file in the package gets overridden on the server. Thats how Joomla works. When you install the latest template it doesn't patch the changed files it overwrites all files from the package.

So if you have made any changes then they will be overwritten.

We provide the list of changed files so that you can manually change the files and not lose any changes.

So bottom line is that even though that file didn't get changed in the template it still gets overwritten on the server when you install the zip.

Thanks

Anthony,

So if I want/need to update xero then I should download the latest and the copy just those changed files listed via ftp?

You know I'm trying to help too. So I am also asking this because that doesn't seem very user friendly. It would not be an issue if xero/ZF4 didn't have an entire template/html folder full of overrides. To me that means that you are betting that your customers do not want to create their own overrides.

Is there another way for you to package the updates?

Or is there another way for you to create the template style you like without 270+/- overrides items in the html folder?

Kind regards as always
Jeff

Hi Jeff/Anthony

Our workflow is a little different working with the zgf4 and managing essential updates, when we have modified the template in any way.

We package the whole template, original and all mods/additions and then upload the custom zip as a new template. This allows us to merge the jb template files and any of our customisation/overrides locally. I find it easier than ftp to replace files.

We compare the jb template versions (v1.3.1 to v1.3.2) to ensure we don't miss any modifications (just in case all the changes are not in the changelog or we misread it) then either transfer the files to our master template for a site, or add our modified files depending on how much customisation we have on a particular site. I use creaking version of winmerge currently. We then zip the files/folder and upload to the site.

All our modification are kept in separate files, so overrides in the normal Joomla manner, we create .json files for layout and theme (naming these to reference the site), then customise style in .less files.

If there are small amounts of style changes we add these to custom.less directly otherwise we add in separate .less files and reference them from a master .less file to ensure they are compiled. This allows us to reuse styles we apply to third-party components or modules etc. without repeating code.

You need to ensure everything is compiled in the normal way. For us we usually compile locally rather than via the template admin, just a preference in workflow. We also tend to update the .json files locally via an editor to provide the style/layout rather than the template admin. Either way works fine of course, just personal preference and depends on how much fiddling you do!

Finally we add comments to explain everything in the code, this ensure we have some idea what this great new sparkly mod or style does in the future, and should allow another developer or the site owner to work it out should they take over the site later. We then track all file changes in spreadsheet which we keep with the template files.

For us, this workflow is logical and allows us to track, and debug our modifications whilst keeping the strong basic core in place. It keeps the core code relatively clean rather than adding on complexity to the framework. It may not be particularly user friendly but is fairly developer friendly, and I suspect most users are not writing overrides or making major mods outside of the template admin.

Happy to explain more if this does not make sense or needs clarification. I hope it gives you some food for thought.

Regards Ian

Thanks a lot Ian for taking the time to post your work flow

Very useful to hear how people use our stuff - I know I learnt something from your post

Cheers and thanks again

Paul

Hi Ian,

Thanks a lot for sharing your workflow! I would really appreciate learning more details about these points:Can you give a simple example of how you implement adding separate .less files that are referenced by a master .less file that the template will check for?

PS to the JB team - I think it would be great to consider having a "ZGF4 Power User" blog or guest blog series, to highlight best practices and share knowledge from folks like Ian!

For minor changes we add to the custom.less file in the standard template package.

For example:
/* Header titles in bottom row wrap

---

*/
#bottomwrap h3, #bottomwrap h2 {
background: darken(@secondary2,10%);
padding: 8px 10px;
font-size: 1.2em;
}
#bottomwrap {
border-top:8px solid darken(@secondary2,10%);
}
This css (less) makes some minor changes to the bottom section of our website.

This is simple and small amount of code, easy to read through and understand, so we would just place that in the custom.less file with some comments. When you compile to less from either the template admin or locally it will be added to css code used by the website. The jb code imports the file custom.less and includes it.

If the code block was length and specific to an area of the website we would take this and place it in separate less file. In the example above we would create a new less file say our-website-bottom.less and put the code into that file.

We would then call that file using @import pointing to that file, in the same why as jb call the less files from template.less. You can add the import to custom file or directly to the template.less, personal preference. Remembers to get the path correct to point the were you create the new less file.

This enables us to keep blocks of style code and reuse them. A real example is for Hikashop - we have some specific style we apply to Hikashop, so all this code is its own less file. Another is we are currently working on an events system and all the styling for this is kept in a separate less folder and then further into less files that target particular areas of the website. Doing it this way enables us to compile all the less into a css file whilst remain organised in the structure.

Finally using less, rather than creating direct css allows us to use the variables (and style) in the main standard jb template, so would for example reference @primary to grab that colour knowing if it changes it will update.

Let me know if you further explanation.

Regards Ian

Thanks Ian, that is a great explanation!

This will be a big help for my workflow, and I think also to anyone else who wants to move beyond adding all customizations into custom.css.

Thanks again and best regards,

paul

I'm glad to see this post sparked some great replies about css.

Does anyone have any workflows to retain their own html overrides that will get overwritten upon updating the template?

Hi Jeff

Our workflow for this is:

Unzip the jb template package
Add the html overrides (plus any other customisation)
Zip all the template files including the html overrides to make a template package
Upload the updated template zip file from Joomla extension install in the normal manner

Regards
Ian

Ian,

So you keep a local copy of your html override folder for each client? Or do you download a backup and pull out the html folder and repackage the template? I guess its just a matter of organization....

I agree folks this is great - keep it coming

What other stuff do you do in your workflow when working with our themes?

Hi Jeff

Yes we keep a local copy of the html overrides for each client.

The html overrides are usually similar or the same from client to client, so we have many common files and modifications that we use regularly, sort of code snippets. This is true for both overrides and styling.

We create a template package for each site, built usually on a jb core template. This serves as a master for the site/client that we then add version numbers to and will zip then upload.

Of course if you or the client is adding overrides dynamically on the live site this may not work for you. Our workflow is initial design is done locally, we then move to local dev box before going to a remote development server for testing, it is then moved to a live server. We try not to work on design directly on the live server once a site is in the wild, other than of course content.

We use incremental numbers on packages, a speadsheet and onenote to keep track of things.

I hope that explains.
Cheers Ian

Thanks again Ian for the great insights