Please refer to the following notes with regard to the process to follow when making updates to an existing Toshiba page. This applies to the Client Services, Digital and Websupport teams.

When there is a request to amend an existing generic page, a Mantis call should be set up and the latest files be requested from websupport for the EU layer (assuming it’s not a local, non-EU change only). The websupport team might have made amends to the html and css (rare) since the last time the Digital team became involved.

If the change is just to a single country or not all of the localised versions, then these individual HTML files should be supplied, along with any .CSS files which are local variants. 

The above files should be added to the job bag and referenced in the future Vault task.

It is not your job to check HTML assets etc.

The task should detail if the request is an amend to the existing page. For an amend request, a referenced HTML file should be supplied in the job bag. If no files are provided, please query the AM and do not start the job.

Assuming you have the files required to start the job, first download and check the supplied HTML/CSS files into the repo as the most recent version and work from these. Existing JS files are unaffected so these can be ignored.

It is important that any CSS and/or JS files are renamed when supplying a change to these files. This prevents issues affecting live content while a page update is still under review in the Toshiba staging environment. More information on this can be found in the TWMC File Deployment section below.

The naming convention should follow a _v2, _v3 structure. For example, a file originally named “app.css” should be renamed as “app_v2.css” and so forth.

These pages are often translated a number of times and so applying the changes to all layers can be problematic. Try to output work which is neat and tidy but also concise and avoiding, if possible, the need to break up existing code drastically.

If you are making changes which need to target just one language page, make a delta CSS file rather than creating a completely new one. This aids future updates to these files.

For instance, you could create a file named “app.local.css” which is supplied only to the DE layer - making sure that you store this file in the repository under the correct relevant folder structure for DE files. A minor HTML change is then necessary to reference this new file via a

<link>

element.

To aid clarity, you will need to add comments to your markup to ensure that the Websupport team can easily apply the amends. Use a datestamp to indicate the round of amends applied, ensuring that these end up being the same date when supplying the files even if you have worked on the project across a number of days.

<!-- START - 20160909 update -->

<div class="foo">This text has recently been changed.</div>

<!-- END - 20160909 update -->

Once complete, you must commit and push your changes to the relevant repository. In order to reduce confusion in version control, it is preferable if all old versions of your files could be cleaned up before pushing to the repository in Mercurial. For example, app.css and app.js would be deleted once app_v2.css and app_v2.js are created - they still exist in the repository revision history so there is no need to worry about losing any data.

An important thing to note about TWMC - the underlying platform running the localised Toshiba websites - is the way that uploaded files are handled when a page is approved and published on the system.

The FTP areas for stage and live exist as 2 separate entities; yet files are automatically deployed from the stage FTP area to live when a page is published in TWMC referencing the associated content.

For example, you have created a generic page entitled “Toshiba Satellite Foobar”. Within this, you have created the following files:

• app.css
• app.js

These have been uploaded to the folder “ToshibaSatelliteFoobar” on the stage FTP server. These files will remain exclusively on the stage server as long as the “Toshiba Satellite Foobar” page remains unapproved in TWMC.

When “Toshiba Satellite Foobar” is approved and published, the page itself along with the above files will be copied over to the live environment in a nightly job.

Now that those files exist on the live environment, a watch is performed on the stage versions of app.css and app.js; meaning that any changes to these are picked up automatically overnight. This happens as the parent page remains approved in TWMC.

This poses a potential issue, as we might want to make changes to an existing page but keep the alterations on stage for a few days before deploying the files. If we simply update app.css and app.js, the live versions of these files will update overnight and potentially cause styling and functionality issues due to a mismatch between the HTML (which is not automatically deployed) and the CSS & JavaScript.

This can be mitigated by providing new versions of your files, such as app.css and app.js, appended with a version number before the file extension.

Therefore, taking the example above, your HTML file references would be updated. Your files would be renamed as follows:

• app_v2.css
• app_v2.js

As the live HTML makes no reference to these files, they will not be deployed automatically and will not affect the live environment adversely.

You will need to supply the most recent HTML and CSS files to the Digital Services team. You should have a Mantis task for this.

This needs to be supplied in a timely manner, as the Digital team task might be following on relatively quickly

Please do not amend any JS files on any job. Ordinarily all CSS amends should be done by the Digital team but on occasion tweaks or new classes might be added by you. These files must be supplied to the Digital team.

To avoid issues with page updates feeding through to an already published page before client approval is granted, it is suggested that a “WIP” version of the page is created for this purpose. This, in line with the fact that the Digital team should have supplied CSS and JS files under a new name (app_v2.css, for example), mitigates any issues with content being pulled across before ready on the TWMC environment.