5,838
edits
Updating MX to new version: Difference between revisions
m
→The customised approach
m (cut) |
|||
|
If you won't listen to best practice advice, and have decided to for example modify the provided Cumulus web templates without allocating new names, then installing the whole release distribution will overwrite your edited file(s) with the standard file content provided by the developer. Therefore you need to do a customised approach where you select which files from the distribution to copy into your installation. If you have changed one or more web templates, you might think it safe just to omit the relevant files in the zip within folder '''web''', but some builds change the files in the '''webfiles''' folder too, and you need to retain consistency.
==== Updating when files within release might overwrite your own edits ====
To further explain the customised approach, here are some more examples.
===== web site files =====
If you have edited any files that sit on your '''web site''', then these can remain on your web site. However, if those web pages are generated from templates that you expect MX to process and upload for you, you do need to take special action. Maybe you edited a template to give the look you desire, or the content you want (e.g. adding rain this month to this month page, or combining this month and this year page).
The first step is to see if the release notice says that file has been revised, if it has not then it is easy to keep your edited file by not copying in the replacement file from within the zip. If the release revises any file you previously edited, take a backup of your edited file, before you copy the new file into your folder. You can then use a file comparing tool to see what has changed in the release and what you changed and hopefully manage to merge to a new file that keeps any functionality change in a new release and keeps your customisation. Do think about changing name of the template file, or placing it in a different folder, and using the '''Extra Files''' settings. That will make it easier for you next time you do an upgrade to a new MX build.
If you have done major customisation to the standard website then you probably have followed the guidance and stored your new web page templates in a different directory and you use '''Extra Files''' to specify where they are, so they cannot be overwritten, and the new MX will still find them. It might be that new web tags have been added since whatever build you were running before, and that you decide to edit your customised template file, but that can be done any time after you install the new MX build.
===== admin interface files =====
If you have done any customisation to the '''interface''' (perhaps you don't like seeing solar in the tables when you don't measure that) then again you can skip over these files when copying. Hopefully you will have copies of the files that you have customised of the ''interface folder'' so you have ability to copy them back into installation if you do overwrite with the release version.
'''You do have to be careful''', as many releases change the interface in some way, even if the change is not in the file you have customised, it might be in an asociated file, and all the various components of the interface have to work together as a coherent unit. For instance when feels like was added to MX, the api used for sending data from the MX engine to the admin interface was updated. In some releases, a new web page is added to the admin interface, with the consequence that all the navigation menus were adjusted in all web pages. Any HTML page in the admin interface may be edited to refer to a different styling page (so it, and the .css file, must be updated together) or to a different script (so the .HTML, and the .js file, must be updated together). The settings pages in the admin interface are dependent on the correct pair of json files to define the options or values that appear on that web page, so again all must be consistent.
To sum up, admin interface files are interdependent, and you cannot always update some, but not all, of the admin interface pages.
Be prepared to go back to the standard file for whatever you customised if something it depends upon has changed, after all you must not lose any vital functionality.
On my site, my own versions of interface files have a "_" (underline character) added to the start of the standard MX file name. This applies to both HTML pages, and JavaScript files that I have edited. I edit the menu items within my edited pages so those all go to my versions where I have a HTML customised page, leaving unchanged the menu items that can still go to a standard MX web page where I don't have my own version of the .HTML page. This makes it easy for me to navigate between my pages, as all of them link to my other pages. If I am on a standard MX page and want to go to one of my customised pages, I select the equivalent standard page, then edit the URL to add the underline and get easily to my page. This naming means I can always use a standard page instead of my customised page when I need to, and I never miss out on any new features.
== After an update if you use the standard web template files ==
| |||