Testing Changes
With the new template, it became a relatively easy matter to push changes to the production websites. This made it tempting to pursue more than one change at the same time, something that the testing process made very difficult at the time. In testing, we had generally created test files, worked on them independently, and then tried to hack that test file functionality into the production file. We needed a new system where it was easy to start testing with current files instead of generating new ones and to save files back to the live site with minimal effort.
The new more maintainable templates also require many more files than the pre-master page system where most code was in a single file. In order to test manageably with these files we needed to recreate the testing section with the same structure as the production site. We had a general "Page template" which we even transferred to master pages. It was only later that the full implications of the core vs. testing pages became clear to us and we realized the revolutionary nature of what we had done - at least if we were going to take full advantage of the power of this structure.
Dividing Core vs. Testing Pages
Almost the first thing we did once the master pages were in place was divide the pages into groups. Previously, I had decided which files should be kept current and updated them manually. Nowhere was there a definitive list of which files were for testing and which not, nor was there any established procedure for updating them other than, “Oh, wow, this is cool. I want this on all the important pages.” In many cases it was obvious (like the homepage), but there were a few pages that were updated sometimes and not others. With the new template we had to choose nested master pages for each page to call; that process formally codified the core pages, by calling a master page which was updated. The core pages were forever after distinguished from the testing pages which were frozen and no longer updated in order to preserve each stage of development. This was something that occured organically, it took us a little time to realize the implications. Hence the two fundamental page types, core vs. testing were born; the new "workingLink" class was invented to make it easy for visitors to identify usable links and for developers to locate critical links in the test pages for updating when absolutely necessary.
The next thing we did was organize the Earth Chronicle Beta file structure. With a core template and a site that had grown too large for one folder, not least of which because of the new Master Page Development section, it was time to systematize our resources: a CSS folder for stylesheets, a Master folder for master pages, Scripts folder for Javascript files, etc. Master Pages also benefited from having a more logical, object-oriented architecture. Core pages referenced files in these folders or master files in similar folders devoted to all Earth Chronicle websites. Testing pages were a little more complicated. Annual folders were inserted into each of the Beta website folders and testing resources were created inside. This should prevent folders becoming too bulky over the years, as all development will be sectioned off year by year.
Dated Test Pages vs. Active Test Pages
A BetaMainMaster.master file is used to run core pages; it's present in a Master folder. However, inside the annual folder are two different Testing versions of the page, active testing files and frozen dated files, e.g. in the Master/2009 folder you'll find BetaMainMasterTesting.master and BetaMainMaster20090406.master. The Testing file is the only version of BetaMainMaster.master which is opened and modified during testing. The dated file was frozen in April 6, 2009 so that the test pages completed at that time have a reliable, unchanging resource and will continue to provide the same functions as when testing was complete. For more details on our testing procedures or to see demos of our content pages historically, check out our ongoing testing.
Skip to Main Points