Friday, 3rd June 2005
Road to The New Revamped Website
Today as i am on the verge of finishing off the revamp process of the site, i am going to take you through a behind-the-scenes look at how the entire process unfolded.
First i'm going to start by illustrating the flawed design of my earlier version of the site. The previous version was my first attempt at serious website development and was a good learning experience. I used Macromedia Dreamweaver MX 2004. One of the nice features about it is the ability to create a template for your site and then have updates to the template mapped to all webpages created using that template. Voila !!!, solution to my problem i thought at the time. Every time i needed to add a new link or update the site, all i needed to do was update the template and Dreamweaver would do the rest. My eagerness to have my own personal website (which at the time sounded cool) up and running as quick as possible didnt help me in figuring the fallacy of this approach. I didnt take into account that maintaining a local copy of the site, making updates against it and then replacing the files on the server wasnt all that sensible. Doesnt sound all too hard, but not an ideal situation. Last i counted i had about 42 PHP web pages that needed to be updated everytime an update was done.
Most of the site was static HTML, off the dynamic content were the Feedback, Guestbook pages. Certainly not rocket science to implement given the number of freely available scripts available on sites such as www.hotscripts.com. But even before i had uploaded my sites, i had already implemented the dynamic part using perl (which was the only scripting language i knew at the time) and wasn't too keen on implementing them in another language. You might have observed that the entire site has the same layout, even the dynamic pages. The perl scripts had to generate the HTML content of the commong layout and the little dynamic content. Herein lay another problem, when the layout was changed (new link added etc), the code in the perl script needed to generate this extra HTML also needed to be updated. So the hack i employed was to read the template file, spewing back content to the browser and the placeholder placed for the editable region by Dreamweaver was substituted for by the dynamic content required. Both guestbook.pl and feedback.pl employed similar approaches. Seems like a neat hack, well it worked and i was content with that. However the hidden problem is that since the file is a perl script and .pl files were configured in Apache to be handled by perl interpreter rather than PHP interpreter, the PHP content (Whatever minute amount of code there was) was not interpreted. As a result the code was the counter was never executed. You might have noticed that the counter never shows up after the .pl script executes.
Additional problems were with my hosting server. First of all space was limited. My package was for a meagre 20 MB and the package including domian registration cost me around Rs 1000. 20MB was barely enough to host content for my project work. Let alone picture galleries etc. Visitors to my site must have despaired at the poor quality of the gallery images. But given storage limitations, that was the best i could do. The server was a linux box somewhere in delhi i think ... the hosting company is www.webcomindia.net, their domain registration is not bad in terms of price, but their hosting packages are non competative and lacks features which i need such as PHP5 support etc.
Here is the old website in Internet Explorer 6(Click on the image to enlarge)
Another admission from my part is that the site was 99.99% pure static HTML. The .php extension on the files is really deceptive. The only bit of PHP content is 3 lines of code for the counter which was a variable stored in mySQL database (overkill i know). Even that code was incompetent in that it didnt track sessions (and/or use cokkie) and so a user refreshing the page would cause the counter to increment. Atleast this was resticted to the main 'index.php' page and refreshes to other pages had no effect to the count. I roll over laughing when i think back to the implementation of the counter script.
The biggest embarresment was the fact that the site template was a rip off from a e-commerce web-template or website (i dont remember where i got it from) and wasnt even producing proper valid HTML code (let alone XHTML code). As a result browsers such as Firefox doesnt render it correctly. I had tested my site for compatibility only on IE and was satisfied that it worked. For some reason, Dreamweaver didnt pick up on this and would render the template and pages created off it perfectly. I can now proudly state that the new site conforms to W3C standrards and is valid XHTML and CSS !!!.
Here is the embarrassing screenshot of how Mozilla FireFox renders the site . Being a fan of the browser, this was especially dissappointing and made me all the more eager to fix the problem. However all half hearted attempts to fix this ripped off template proved futile.
Faced with this myraid of problems especially when it comes to updating the site, i was left with no other option but to forget the site for present and do a revamp when i managed to find the time. Well that time had arrived after i finished with spring semester and had summer semester ahead of me. I'm not taking any classes in summer, so i should be able to dedicate time towards the site. Besides re-doing the website would be a good excercise in stretching my know-how of XML related technologies.
One of the key goals of my new site was have what i refer to as data-portability. By data portability, i mean that the site can be ported with absolutley no changes (to code, configuration etc) from one platform to another. The idea is that it should run on any web server with PHP5 support out of the box. This expectation is slightly off the mark, since it cant always be expected that all modules will be installed out of the box for a PHP5 installation. But for my requirements, XML/DOM enabling is all that i require apart from session tracking. Rest is our simple PHP code.
It is this data portability goal which made me opt for XML based data storage. The language and platform independence of XML is well known and would be an ideal solution to data storage needs for a weblog rather than a relational (platform dependent) database. Not that i dislike databses etc, but for my simple web application, it is probably overkill and the troubles encounterd when ported data from one platform to another conflicted with my design goals. Yes there do exist databases which work on several platform which i could use (such as mySQL etc), but they still need some amount of grassroot work to port data between platforms. With my data stored as XML data within the root folder of my web directory, i could merely compress the entire folder into an archive file, take it to a different platform, decompress it and have it work out of the box. Thus achieving what i call complete data portability.
One of the factors to consider with XML and the language you are using is the strength of the API. In this regard, PHP4 pales over PHP5. (Read my initial rant about PHP4 vs PHP5) PHP5 has much better object oriented support, exception handling, SQLite support etc. But the biggest catching feature for me was the XML support. Their new simpleXML and DOM/XML API are very easy to use and this made my task so much easier.
As for the XML design of the site, well XML is omni-present. All data (excluding the irritating site meter counter) is stored in XML files. Every article is stored in an XML File under a hierarchy of folders of the form /year/month/day. The number of PHP files needed by the site are very few. Infact there are only 3 main files (a far cry from the 42 files i had for the previous site)
index.php -> Homepage, displays the recent few articlesarticles.php -> Displays the article as requested in URLcategories.php -> Displays the listing of articles by category
As you can see it is the articles.php which does the main work. The article to display is determined using the URL. Ideally i would have had a URL of the form http://www.nikhilzkingdom.com/articles/year/month/day/ and then have Apache's Lookback Feature to find the articles.php as the closest path and pass /year/month/day/ to $_SERVER['PATH_INFO'] variable. However this requires a change to httpd.conf file and three configuration directives. Howver since i will be hosting my website on a third part host and cannot depend on them to provide adequate privileges to manipulate Apache's configuration. This wasnt a viable solution and conflicted with my design requirements for easy portability and independence. Thus i had to make do with http://www.nikhilzkingdom.com/articles.php/year/month/day (Not the .php in there). The /year/month/day is still available to me the script and can be easily retireved using the code snippet
list($blank,$year,$month,$day) = explode("/",$_SERVER['PATH_INFO']);
Another possible optimization was to use XSLT to transform the XML to XHTML. This was a very inviting solution since it would allow two things to happen.
Different stylesheets can be applied. A style sheet to produce markup content (WML) for mobile devices can now become a possibilityFurthur decoupling of data from presentation
Seperation of data content from presentation is one of the important leasons i learnt from web-design. My current solution doesnt completely adhere to this principle since there is code for performing the transformation which has embedded HTML in it. XSLT would be the ideal solution, and to enable the XSLT module that PHP5 comes with. To function, this module makes use of the open-source Sablotron XSLT processor. Sablotron, in turn, relies on the open-source XML parser, Expat. Here is a wonderfully simple guide on using XSLT with PHP5. But once again this is against my design goals of not relying on many particular features being enabled in the third party web hosting company. The one remaining important part of the website was how i would be adding new content to the site i.e. new articles. I certainly didnt want to be hand writing and editing XML files and placing them in their needed directory. Rather i designed a web interface which does this for me. This is the price i needed to pay for opting to have my own weblog, as opposed to using a weblog hosted somewhere else where wonderful tools and user interfaces are available to publish new articles, besides a tirade of management console and admin interfaces are available. My management console is hard coded and is bare minimal to meet my requirements. The remainder of the site, guestbook and feedback were simple PHP scripts that any "script-kiddie" can throw up in a couple of minutes.
Thats that for the web design of my new site. i am always open towards solutions towards improving it. A plug and play weblog script (based on data storage as XML files) would be a good excercise for an academic assignment i might think. I'm not sure if one already exists, most likely there are several, thought it wouldnt have kept me from custom doing mine. Next task apart from publishing the site is to secure the site. I have tried to making the site as secure as possible by tying up odds and ends and validating user form input, but i'm sure there are security holes aplenty, that i would have missed or am unaware off. Hoefully the information security course i take in fall semester would be of help.
Talking of publishing the site, i can't wait for that to happen. However now that my new site used PHP5, i now was struck without a webhost, since my earlier site is being hosted with only PHP 4.3 support. This also narrowed my options in terms of a new hosting service since not all web hosting companies have migrated to PHP5 (i suggest they do at the earliest before they reach the stage where they invariably need to). This is the main cause of daly of the launch of the revamped version of the site. As i write, i am on the lookout for decent deals to meet my requirements for a web host. I would definitely be looking for more web space. As luck would have it, my options for a PHP5 enabled, large webspace, moderately expensive web hosts are limited and making my choice difficult. I will however hope to find one as soon as possible, atleast before the old site domain registration and web site host expires on July 5th.Till then http://localhost will be all i work with. This makes XHTML validation harder, but i can live with that for a while longer.
And thats how the road to revamp of nikhilzkingdom went.
Posted by Nikhil on Friday, 3rd June 2005 in TechnoBabble | Life in General | Humour | Fun | Nonsense
Comments
Lookup the use of .htaccess, this enables you to have www.nihilzkingdom.com/year/month/day/ pretty easily. But it is not platform independent, AFAIK, it is present only in apache. -Rajesh
Posted by: Rajesh Goli on Thursday 30th of June 2005 06:21:16 AM
Isnt it a good idea to obfuscate the e-mail IDs of the people who post comments? Spambots would relish this site otherwise, wouldnt they? -Rajesh
Posted by: Rajesh Goli on Thursday 30th of June 2005 06:23:03 AM