WHMCS v7.1.2 upgrade bug

[brian!]

i've just upgraded a v7.1.1 dev to v7.1.2 (using the automatic updater) and something strange happened during the process - I was greeted with the following screen...

forget about the other files it mentions, why is it even checking custom.css at all? I thought the whole point of using custom.css was that WHMCS wouldn't overwrite it??

 

http://docs.whmcs.com/Customising_the_Six_Theme

 

If you want to make changes to any of the CSS that is applied by default, we recommend making those customisations inside of the /css/custom.css file.

 

This file is included after styles.css allowing you to override any of the CSS defined within it, and will not be affected by future updates to the WHMCS software and therefore will help ensure that any customisations you have made do not get overwritten or lost while still allowing you to keep the styles.css file up-to-date and current.

I had already created a backup before the upgrade, so I let the upgrade continue to see what would happen - and it totally wiped custom.css and returned it to it's default blank file with just the header in it.

 

/* *****************************************************

   ** Custom Stylesheet **

   Any custom styling you want to apply should be
   defined here.

***************************************************** */

now for me, it was only a dev and I had a backup - but if this was a live site and I had updated without making a backup first, that could have been a lot of customisation needlessly lost.

 

so this is just a heads up for everyone to take care when upgrading.

[WHMCS John]

Hi brian,

Thanks for taking the time to report your findings. We have opened case CORE-10932 internally to investigate this situation and look at ways of potentially avoiding this in future.

 

Once we resolve cases and push features they are available at our change log, so keep an eye out for case CORE-10932 here:

 

http://changelog.whmcs.com/

[WHMCS Nate]

Hello Brian,

 

Having reviewed this case, I wanted to reach out and explain why we have decided to close it without product changes. The documentation you cite opens with a section "Before you begin" which starts by either using git to make a separate theme or copying the six folder to your own theme name. We continued that pattern in our developer documentation, which also removed much of the language you cited. The first section is "Getting Started" which walks you through the change.

 

The intent of the custom.css and what we were pointing to in our documentation was to allow you separate your customizations from the base css styles to make it easier to update the styles we ship without having to extract changes. This is even more important as we have moved from a number of css files to a single minified css file in WHMCS 7.1.

 

I have opened a case to review the documentation and refine it to ensure that this confusion is clear.

 

Fundamentally with the updater (or if you are manually updating via full downloads w/o adding extra steps to hand filter things) WHMCS owns every file we ship, which means we update all of them during the automatic update. During the 7.0 release we refactored some subsystems to follow this core assumption. Any files WHMCS did not ship, we leave alone.

 

As you noted in your post, for this to overwrite a customers custom.css modifications, the customer has to ignore the recommendation to take a backup before proceeding and has to ignore a special warning page that details exactly what is going to be modified.

 

We considered not shipping the custom.css file in new versions, but we concluded two things:

 

1) We think most customers that need to modify the css file will also modify at least one client area template and this means they would need to make a copy of the template directly in any case. I would note that your error message shows you had modified template files as well.

 

2) We did not want to introduce trouble for customers that are maintaining custom themes via git when our commit removes the file. This is something that can be corrected but its not an impact we want to cause for these customers who are following our recommendations to maintain templates.

 

Have a great day,

 

Nate C

[brian!]

Hi Nate,

 

I appreciate the response.

 

As you noted in your post, for this to overwrite a customers custom.css modifications, the customer has to ignore the recommendation to take a backup before proceeding and has to ignore a special warning page that details exactly what is going to be modified.

 

We considered not shipping the custom.css file in new versions, but we concluded two things:

 

1) We think most customers that need to modify the css file will also modify at least one client area template and this means they would need to make a copy of the template directly in any case. I would note that your error message shows you had modified template files as well.

well it's used as a dev, so it's just for playing with...

 

you make a fair point that most customers will have modified at least one file - though just off the top of my head, I can think of at least three users who haven't renamed "Six"; haven't modified any non-cart templates - but are using hooks to change the navigation etc and custom.css for their styling changes.

 

to be honest, I can't think of a valid reason why, if six/custom.css exists, the updater should ever need to replace the file ? if it's missing, fine... but if it's there, why replace it?