A little (Technical) info behind the Ynui site

Location: Forum - Wainuiomata.com Website - A little (Technical) info behind the Ynui site

New Comment

  1. Author: robvdl
    User type: Administrator
    Posts: 122
    Date: June 16, 2006, 12:22 a.m.

    Ynui Website: Under the hood

    The Ynui website is written in the PHP programming language. It runs on our very own Content Management System (CMS), which we have built ourselves from ground up. Our CMS makes it really easy to maintain the website, edit and insert pages. The pages and other data the site uses is stored in a MySQL database on the server.

    The CMS engine on which our site runs, generates 100% standards compliant XHTML 1.1 markup and makes use of CSS for the design. This makes the pages a lot smaller in size, benefiting modem users as the pages load much faster. Standard compliant websites also work much better across different platforms, Firefox, IE, Opera, Safari, even Cell Phones.

    Additionally pages on the Ynui site are GZIP compressed on the server before sent out, this makes the pages around 1 fifth of their original size, benefiting modem users even more. The browser transparently decompresses the page as it loads, you don't even know it's happening.

    Dynamic pages in our CMS are handled by our own plugins. We have developed this plugin system ourselves. Pages like the Ynui News, Guestbook, Chat room, Forum, Gallery and Business Directory are all plugins for our CMS.

    The site also has a user control system, there are 5 different user levels + the Guest user. If users create their own account, they become a Standard User, which gives them slightly more options than a Guest. We can upgrade users to different user levels too. Different pages can be shown only if a user with a certain user level is logged in. User levels are also used by plugins, such as the Forums and Gallery, which can only show certain areas when a user with the correct user privileges is logged in.

    The CMS itself is written in around 1500 lines of PHP code, but some of the plugins itself are even bigger. For example the Gallery (which automatically builds a browsable gallery from photos placed in directories on the server, and even automatically resizes the images and creates thumbnails), is 1800 lines long. The Forum is the biggest and is a massive 3500 lines long. All up, the Ynui website runs on around 10000 lines of PHP code. 😎

    All up, it has taken us just over a year of work to get our CMS engine to this point.

    The CMS can also be used for creating other sites, we create a template and CSS file for each site, select the plugins we wish to use, or even write new plugins for the clients that need something different.

    Here is a list of some of the websites that run on our CMS:

    We are currently helping a few clubs around Wainuiomata, by creating them a professional website, based on our powerful CMS engine. I will add each one to this list when they are done.

    What's Next?

    In the mean time, we have already started writing our new CMS engine version 2. This system will be even more powerful and have even more features than the current one. The new engine will be written specifically to make use of PHP 5's new Object Oriented features. Legacy PHP 4 support will be dropped.

    The new engine will make use of the new PDO (PHP Data Objects) database abstraction layer that comes with PHP 5.1. This means that the new engine can work with any database: MySQL, PostgreSQL, or SQLite. PDO Comes with PHP 5.1 by default (which runs on our server), but can quite easily be installed on a PHP 5.0 installation.

    The new engine will also include an even easier to use control panel (which only the site administrator uses). The new control panel will be written as a Java applet, and can be run either directly in the browser, or as a desktop application. The new control panel will make page editing easier, it will be easier to move pages around, install and configure plugins, and give the administrator the ability to create backup 'snapshots' of their site.

    Work on this system is still in early stages and is expected to take around a year or even longer, as the project is quite ambitious. We have already planned out exactly how we are going to write the system and how it will work internally.


  2. Author: Winston
    User type: Standard User
    Posts: 24
    Date: June 22, 2006, 11:41 p.m.

    I had no idea you could zip the pages and have the browser unzip and display them. Is that handled completely by the browser? What about fairly old browsers?

    Looked at this site in IE5/Mac and the pages still showed, albeit a bit weird. I can understand not worrying about ie5 mac, not too many people still use it, just me, becuase we're too budget to upgrade to OS X yet! 😉

    I do run OS X at home though. For me its hard enough trying to get things to show right in IE6 when everythings great in a standards compliant browser.


  3. Author: robvdl
    User type: Administrator
    Posts: 122
    Date: June 23, 2006, 12:25 a.m.

    Winston Said:

    I had no idea you could zip the pages and have the browser unzip and display them. Is that handled completely by the browser? What about fairly old browsers?

    Yes, the GZIP decompression is handled completely by the browser, pretty cool, huh? Don't worry it's 100% safe with old browsers, this is because when a browser asks for a page to be displayed, it will give the server certain information on what features it supports through the HTTP headers. The specific field that we're after is called HTTP_ACCEPT_ENCODING. In PHP, this can be read through the variable $_SERVER["HTTP_ACCEPT_ENCODING"]; and in the case of a modern browser contains the string "gzip,deflate". All we have to do is check if the string contains the word "gzip". If it doesn't the page is not compressed.

    Winston Said:

    Looked at this site in IE5/Mac and the pages still showed, albeit a bit weird. I can understand not worrying about ie5 mac, not too many people still use it

    Yep, that's unfortunately a sacrifice I chose to make. I am now only making standards compliant sites these days, because I want to keep with the times, and make a better, smaller/more efficient website for everyone. When you make a standards compliant website, it will work properly with all Mozilla based browsers (Firefox, Camino, etc), Konqueror, Opera, not to forget Safari which is based on Konqueror.

    The only browser that struggles with standards compliant sites is actually IE. Many CSS web designers absolutely hate this browser, because of the hacks they have to apply to work around it's issues. And even IE6 and IE7 still contain bugs... IE5 is really bad, and IE5 for mac is probably the worst browser ever made, but it sounds like you are already aware of this.

    So what do I normally do about this... Well, first I make the whole site work on all standards compliance browsers, usually I only have to test in Firefox, and Opera, that's usually enough. Then I make a 'hack' stylesheet for IE6, it contains all of the hacks you have to apply on IE6, to make the page show correctly, I use positioniseverything.net as a guide.

    I then use a neat little feature that is built into all versions of IE called "conditional comments", with conditional comments, you can execute bits of code, only on IE, or only on a specific version of IE. I use it to load the additional IE6 'hack' stylesheet that fixes these bugs, just on IE6 (Select view, source on this page and see how I load the additional CSS file in IE6 😉)

    If you were to not load that hack stylesheet on IE6, for example if I was to delete it of the server, it would look just as bad as it does on your IE5. The only difference is I actually created a hack stylesheet for IE6, and let me tell you this is a mission, as the browser really misbehaves sometimes!

    Unfortunately IE5 was just too broken, I tried fixing it for around a week, but couldn't and just ended up getting a sore head :roll:. This is when I decided that I was going to drop IE5 support from the site.