xhtml

One of the indispensable functions of a Web Development and code authoring tool is the ability to undo code modifications during a session, or even over the entire editing lifespan of a document within the tool. Previously, within HTML-Kit 292 one had to be content with unlimited undo-redo steps within a given editing session. This led to many developers keeping documents open for a long time because once a document was closed, then the facility to revert to a previous version was lost.

More advanced code editing environments like Microsoft Visual Studio and the like that cost significantly more money have for a long time provided a version management feature that enables one to revert to an older version of a document beyond the length of any given editing session.

HTML-Kit tools for Windows/Linux now offers this useful feature that enables you (the code author) to brose through the various iterations and versions of any given document over time, and beyond the length of the editing session. Although the application is in closed Alpha testing, I am impressed with this feature and it has contributed to my preference to use the Alpha version (that is incomplete and may lack other useful features) over the more stable and plugin-rich HTML-Kit Version 292. Although Version Control can and should be managed by a CVS (Concurrent Versions System) Application, one cannot create enough restore-points in a CVS application to bridge the gap between undo-redo, and session-based CVS archives.

In addition to the HTML-Kit Tools for Windows/Linux providing a version management tool, it also has the ability to DIFF/highlight the differences between any previous version, and the current state of the document in question.

It is anticipated that the HTML-Kit Tools for Windows/Linux version management tool with be more robust in when the application moves to beta testing and to the Release candidate, but it is promising as it is, and I am eager to review and use any other new features of this application.

Similar to the above online tool provided by Chami.com especially for users familiar with the UI (User Interface) and functionality of HTML-Kit, Chami.com's new application (currently in Alpha version) HTML-Kit Tools for Windows/Linux has a similar feature for general web documents.

The document information window provides a progressively expandable and dynamic visual representation of the current document's DOM. This feature is useful in quickly understanding the DOM structure of a document to aid in scripting, or writing meaningful CSS with selectors of varying specificity (By understanding the DOM ancestry of a given element within the document tree, it is easy to write selectors of increased or reduced specificity).

CSS Poster for your stylesheets - This new online tool makes it possible to create quick reference posters for your CSS files.

Without a proper understanding of CSS selector specificity, the basic approach to managing the override of one CSS is to have a single selector/declaration pair for every element, and then employ the !important switch/declaration to override pre-existing declarations.

The above approach works, but is severely limited in the flexibility, versatility and the interchangeable presentation format intended of CSS/XHTML. The use of !important declarations divides declarations into only two groups: Those that are !important, and the rest of them. Without regard to specificity, and if one focuses too much on the use of !important to override other declarations, the problem of two or more !important declarations comes into play. In the practical sense, the more specific of the two or more !important declarations will win and override the rest, but if the CSS author is not aware of which and how many !important declarations exist, this can lead to very lengthy debugging sessions. NB: The last statement calls for proper organisation and a planned approach to XHTML markup and CSS authoring to properly manage and locate CSS declarations.

Neither, but !important is harder to find/track and control. Since inline CSS is and will always be found next or on the same page as the markup that it is attempting to control, it is relatively easier to control.

Based on my experience and opinion, !important CSS declarations should only be used in troubleshooting situations where the author would like to test a layout, or override CSS declarations in an emergency without having to access and hard-code inline CSS. This is especially important and useful in dynamic web content generations situations such as CMS where the presentation team may/should not constantly access and edit markup. Inn addition, if @include CSS files are used, all !important declarations can be grouped in an emergency/patches/troubleshooting/temporaty CSS include file where they can be located and adjusted or eliminated as necessary.

In the absence of !important declarations, specificity is a powerful tool and approach to creating multiple and progressively overriding declarations if the XHTML markup used is well thought-out and hierarchical. Also, the proper use of IDs and CLASSES to define the mark-up makes it possible to target and style any section or individual element of an XHTML document. I would recommend using an onion ring approach to marking-up content and marking it with IDs and CLASSES so that CSS selectors of varying specificity can be employed.

An ideal application for this markup and styling approach; that is not well exploited at the moment is the ability to enable skinning of content to enable different layout and presentation schemes to be applied to content. Having several regimes of CSS declarations of different specificity in place enables one to use client--side or server-side scripting to switch themes on the fly. This can be used for accessibility (large text, or narrow hand-held screen users being able to change layouts), or it cab be part of a theming approach such as the Mclayout.

Drupal 5 is now available for general installation, and to respond to this important and long-awaited news, we have decided to embark on upgrading our main website that is currently using Drupal 4.7x to use the new version so that we can reap the benefits of the many new functions of the popular and even more powerful CMS infrastructure/application.

Although many modules that are currently in use are not yet ported to Drupal 5, the above-mentioned benefits of upgrading, as well as the ability to document all possible challenges, errors, and other notable experiences for our customers, or just as testimony to our confidence in the new version is reason enough to upgrade.

This is not our case, but you may opt not to upgrade from your current version of Drupal if you have so heavily invested in custom modules and forked Drupal core code to a point where you may not want to compromise existing functionality. Or you may be so far off from the standard Drupal code that you will need time to develop and port your custom functions to be compatible with Drupal 5.

Like any site/life changing website modifications, you should or rather, you must make a backup of the sites database and codebase (files) before you embark on upgrading and replacing things. This is because if the upgrade process fails in any way, you will be unable to get back the old website if you do not have backups.

The necessary steps to this are fewer than what I will outline in this section. The minimum requirements are for you to make one backup of the database and keep it in a 'safe' place while you upgrade the installed/live database.

• My choice is to make a backup of the site as it is/was before you even thought about upgrading Drupal (together with all your modules in place and working). Since it is advisable to turn-off all your modules and themes before upgrading, this first backup will enable you to rebuild your site as it is/was running the old version of Drupal without worrying about re-enabling themes, and modules
• The second database backup should be done after you have disabled all your non-core modules, and changed your default module to one of the out-of-the-box modules that come with Drupal. These two steps will enable the post-upgrade relaunch of the site to be smooth as there will be no theme and module settings to generate error messages. In particular, as of this upgrade, there is no Drupal 5 compatible version of the module node_privacy_by_role.module which I am running on the 4.7x site. It is crucial to turn this module and other modules OFF from their respective settings' section before upgrading. In particular, since this module controls who/what content is visible to the various roles on your website, leaving it active will switch off all your content from display to anonymous users once you upgrade/delete the modules files.
• Instead of upgrading the live database that is left on the server, another level of security for me is to leave it intact just in case the SQL database backup was not clean and create a new database to use in the upgrade. I therefore imported the above exported SQL code into a new MYSQL database.

Copy all the files and folders in your Drupal program folder on the server and keep them in a safe place for use just in case the upgrade process fails or if you would like to re-install the soon-to-be previous version Drupal on a different server to be able to test the old version or use it for other research purposes such as supporting your customers who may choose to maintain their sites on Drupal 4.7x (It is assumed that you will have by now upgraded all your sites to Drupal 4.7x as all older versions will not be supported by the core developers).

Reliability of service is key in maintaining and increasing the user-base of your website. You should therefore notify your visitors that you are in the process of upgrading your CMS application or will be otherwise off-line for maintenance so that they can understand if they experience limited or no content delivery. There is functionality within Drupal to handle the display of the maintenance message. NB: In addition to that, I also create a message in an index.html file that will be served when I delete or rename the old Drupal versions pages including the index.php that would otherwise serve the site maintenance message.

• Rename all the pre-existing (4.7) folders to enable the creation of new Drupal 5 folders. In my case, I decided to add an underscore "_" to the file and folder names from Drupla 4.7 so that I can be able to go back to the 4.7 site to tweak things in the configuration if need be (I had forgotten to turn off some modules, and would prefer to do so from within Drupal as opposed to tinkering with the database especially since I would like to begin with a clean set of tables without potential errors).
• Download a fresh copy of Drupal 5 code and upload it to your server in the pace where you would like to have your permanent website. NB: Previously I used a temporary folder and this was included in the node page for some pages in the upgrade from Drupal 4.6x to Drupal 4.7 , and I had to spend a lot of time cleaning up the paths physically and in the database. This is unnecessary and should be avoided.
• Copy the contents of your "/sites" folder to the live (Drupal 5) site folder, as well as other items that you would like to reuse such as the "/files" folder.
• So as not to modify the Drupal 4.7x database that is live on the server, we will upgrade the database that we created in the last step of the Database backup process above. We MUST therefore modify the "/sites" configuration so that the settings.php file points to the copy of the database that we created for upgrade. NB: If you at this point attempt to access your website, you will see the below error message "Fatal error", but fear not as this is normal being that the database tables have not been updates to Drupal 5.
• Run the /update.php file and you will go through the update process; if you are luckier than me, especially if you followed all the steps, you will get a confirmation screen informaing you that the upgrade is complete.

  
  
  
  

• I was not as lucky, maybe because the database import I performed to safeguard the live/working database took more than 30 minutes to export and completed with an error.
• My upgrade process resulted in an error message that

  user warning: Can't DROP 'vid'; check that column/key exists query: ALTER TABLE node DROP INDEX vid in /home/cmsprodu/public_html/includes/database.mysql.inc on line 167.

  I ignored the error and I was able to access the website to update the theme and other modules for the website.