blogZero

Last week, while researching and evaluating open-source software packages written in PHP, I naturally took the time to install some of them to see how difficult it was and note any problems I might encounter. One of these was of particular interest. MediaWiki is the software that drives Wikipedia and the rest of the projects under the Wikimedia Foundation umbrella.

Goals

Some of the goals I had in mind when I set out on this little project were:

• Follow best practices.
• Virtualize the install so PHP scripts and other resources visitors should not have access to are hidden.
• Friendly URLs—I don't want to see any .php extensions while browsing.
• Customize the install for my particular needs.

Root

For security reasons, and the threat of downtime from customers who don't know what they're doing, most hosting companies severely limit what you're capable of doing in a shared environment—and of all things they're not going to give you root access or sudo(8) privileges. Even on a dedicated server this can be a sticky situation. In order to follow the instructions below, at some point you're going to need that capability to, for example, restart you're Web server daemon. If you're running Ubuntu or another Linux distribution, or Mac OS X, on a local development box, you should be all set. You should also be comfortable using a shell and know how to edit text files.

Download

First you need to grab the source code from the MediaWiki Web site. You'll find it on the Downloading MediaWiki page. It comes in a tarball—make sure you get the latest stable version. Also make sure you meet all the requirements before attempting the install. It helps to know which versions of PHP and MySQL you're running beforehand.

Upload and unpack

After you download the file, upload it to your Web server into the docroot of your site. At the time I did this the MediaWiki latest stable version was 1.13.2 (released 10-2-2008), and the name of the compressed archive reflects this: mediawiki-1.13.2.tar.gz.

Fire-up your shell client and visit docroot. You can decompress and extract the source in one command:

$ tar xzvf mediawiki-1.13.2.tar.gz

You'll see a whole flurry of activity as the package is creating its source tree and populating the directories with files. You'll be left with a directory, just off docroot, with the same basename as the archive. The first thing I did was rename it to something more manageable:

$ mv mediawiki-1.13.2 w

There's no need for the archive any longer so get rid of it.

$ rm mediawiki-1.13.2.tar.gz

Then change into the w directory.

$ cd w

Configuration

The browser-based installer will want to write out a file called LocalSettings.php in the config directory. To forestall any permission problems make that directory world writable:

$ chmod a+w config

Now point your browser at the directory off docroot you just created: example.com/w/ and follow the instructions to set some basic options and create the database. In a bit you won't access the w folder directly, since we are going to virtualize it and create friendly URLs. Two things to keep in mind: the virtual directory does not really exist in the sense you create it in your filesystem, and (this is important), do not use the same name for both. By MediaWiki convention this virtual directory is called "wiki," which you should be familiar with from browsing around Wikipedia.

When the installation is complete, copy the config file down to the w directory and add a few lines.

$ cp config/LocalSettings.php .

// docroot/w/LocalSettings.php

$wgScriptPath  = '/w';        // real path
$wgArticlePath = '/wiki/$1';  // virtual path
$wgUsePathInfo = true;

These settings, and one more task with your Apache config file, will take care of ever having to access the w path directly, and will give you the nice URLs we're after.

Apache

You're going to need to be root on the box to do at least one of the following steps. Since I have a virtual.conf file for this site there was no need to edit httpd.conf directly. Your mileage may vary. Either way, in the <VirtualHost> container for your site you need to add an Alias to finish this job:

Alias /wiki /real/path/on/your/server/docroot/w/index.php

It's probably a good idea to make sure your config file(s) have no errors, then restart Apache:

$ apachectl configtest
Syntax OK
$ sudo apachectl graceful
Apache gracefully restarted

Then point your browser at: example.com/wiki/ and if everything went well you'll see the MediaWiki "Installed successfully" message on the Main_Page. An even cleaner set-up would be to create a sub-domain of your site, say: wiki.example.com, and install everything in the docroot. But I'm not going to get into that here.

mod_rewrite

There are a number of other solutions out there, many of them involving mod_rewrite. Unless you understand regular expressions and have some experience using mod_rewrite, or enjoy pain of the voodoo variety, I recommend going the Alias route. Why hit a tack with a sledgehammer?

Conclusion

MediaWiki is a large program and it uses lots of system resources. If you're in the market for a simple Wiki and one only you will be using then consider shopping around for something less complicated. I went for Big Daddy for a couple of reasons. One, I wanted to gain the experience of installing it, and two, I wanted to have my own sandbox, so to speak, to better understand the system, and in particular, to improve my skills editing Wiki documents using their markup language. With that said, it was worth the effort.

Although there is little to see or do, you can visit wikiZero to see the results of a fairly fresh install. Also, if you're really planning on diving into this, and you're a dead-tree fan like me, O'Reilly published MediaWiki just last month. I took a look at it and read some third-party reviews. It's a keeper if you plan on using this software to any great extent.

Prototype version 1.5 has just been released and includes many enhancements and bug fixes. Best of all, excellent online API documentation. For more information on the latest version, visit the Prototype blog.

Joe Hewitt has announced the final release of FireBug 1.0. Rather than go into all the details about new features and enhancements here, I'm going to refer you to the Yahoo! User Interface Blog where you can view a lengthy video featuring Joe as he demos the new version. Joe has put an enormous amount of work into this extension, if you use it regularly and it saves you time and frustration, then consider helping out with a donation.

JavaScript development just keeps getting more efficient and powerful!

I was way overdue and finally made it down to the National Press Building (map) for my first DC PHP Developers group meeting, and I was pleasantly surprised by the turnout. The conference room (#495) was close to standing room only and additional chairs had to be brought down so everyone had a seat. I'm not sure if this was atypical, maybe it had something to do with the presentation. This, in contrast to the Washington Web Standards group meetings, which are very informal and only a handful of people (at best) regularly show up.

I suspect the reason for the strong showing was Keith Casey's presentation on the Smarty templating engine. He was obviously enthusiastic about his recent experiences working with it, and went beyond simple include/if/foreach constructs in your markup, or the "view" side of separating your application into data/code and presentation. Smarty also allows you to create custom filters, or plugins, which boil down to PHP functions that can be used in your templates to deal with special situations.

As ever, I will not mince words. I still cannot see how a "designer" would be any less intimidated by editing templates over markup embedded in a PHP module using here document syntax. I had the same impression I've been seeing for years, being this separation of the "progammer" camp and the frontend designer. To me, Web development is the whole ball of wax. You should understand everything from Internet protocols, server configuration, valid and semantic markup, CSS/presentation, database design, efficiency, security, and so on, or you pigeonhole yourself into one role.

And I didn't even mention client-side stuff like JavaScript/DOM scripting, or XHR.

Another thing that puzzles me are constant references to the MVC paradigm. "This is not a new idea," one that predates the Mac and DOS/Windows, not to mention Linux, by a long shot. MVC is rooted in the research done on GUI design at Xerox/PARC. For a generic overview, MVC is composed of:

• Model — Data and the logic to access it (the backend).
• View — Presentation or user interface (the frontend).
• Controller — Event handlers (most of which is already done by the browser unless you are using scripting).

I admit the latter isn't quite that simple. Server-side code (other than preemptive client-side validation) would include such things as processing form inputs and the security baggage that goes along with it.

My design and development philosophy has always been deeply rooted in the original principles of Unix and KISS. How many layers of abstraction are necessary? Or worse, layer after layer after layer...when does the developer lose all sense of the underlying system? I'm not advocating coding server-side HTTP responses in assembler or C/C++ (which I have done), but when I see programmers writing classes using methods that are nothing but wrappers around PHP functions, which are themselves wrappers around library calls that then make system calls...I hope you see the point of this rant.

However, it was a good presentation and Keith's strongest assertion, one I happen to agree with, is this: If you are going to use a templating engine Smarty is worth considering. It is mature, has a strong and loyal userbase, and is well maintained and documented.

Related reading: PHP Templating Engines.

Okay, my April Fools jokes are terrible, it's really only been one year since I completed the first version of the software that drives Web Developer Resource Index and started adding reviews. And what a year. I was hoping to make it to 1000 resources today, but fell a little short. There are 955 as of this post. Too many irons in the fire I suppose.

Like most software, the system evolved. One of the first features I added were RSS feeds for every category. This was quickly followed by an OPML of the whole directory. You can even extract the data as RDF if you want to. Initially, each resource was marked up with valid XHTML 1.1 (like the rest of loadaverageZero). Later, I adopted the hReview Microformat, which, to the best of my knowledge, makes DRX one of the largest examples of such reviews on the Web. Every resource is tagged with one or more keywords, so a tag cloud provides another interesting point of view.

Today I thought I'd take the opportunity to look back at that first week, and list 20 selections. I guess you could call this the polar opposite of Recent Additions.

• XHTML 1.0 The Extensible Hypertext Markup Language
• NYPL Online Style Guide: XHTML
• The Emperor has New Clothes
• XHTML 1.0: Marking up a New Dawn
• The Perils of using XHTML Properly
• HTML 4.01 Specification
• HTML Advanced Guide
• HTMLSource: HTML Tutorials
• Cascading Style Sheets
• Eric Meyer: CSS Work
• Learn CSS: Complete CSS Guide
• Maxdesign: CSS Tutorials
• Resource Description Framework
• RSS at Harvard Law
• RSS Tutorial
• OWL: Web Ontology Language Overview
• Semantic Web
• MySQL Reference Manual
• The C Programming Language
• PHP Manual

I started with fundamentals, you should too.

A few days ago an informal poll appeared on the Digital Web news page asking visitors if they are Formally Educated or Self-Taught? I was surprised by the large number of respondants (many of them highly influential developers) stating they are mostly self-taught.

Another prevalent thread running through the comments is the concept of learning by observation, or what I like to call "how'd they do that?" In order to understand a technique, one of the best methods is to study source code. This is easy enough to do with any browser, and Firefox has some extensions that make it even easier. On my own Web site I try to expose as much as possible, including the markup, PHP source code, I also list my CSS and JavaScript files in the sitemap, and so on. These are just niceties, because other than code originating on the server-side (PHP for example), anything delivered to the user-agent is viewable in source form. Unless you're in the obfuscation camp, which I'm not here to discuss (shame on you if you are).

By now you may have heard of Ajax, and the booming trend in dynamic or DOM or client-side scripting that goes along with it. In other words, JavaScript is red-hot right now. If you're just getting into scripting, then this is a damn fine time to be learning by studying the code that drives all this stuff. It's also a fine time to be learning JavaScript because its reputation as a toy language with many poor examples is quickly being replaced by a new-found respect and clean, structured code.

As far as JavaScript code goes, there are a couple of different sources you're likely to run into. Embedded JavaScript can be found right in the markup. This is still almost as common as it is a bad practice. So there you are, back to viewing the page markup. Often this practice is made even worse by code that is disorganized and dispersed all over the place. There is also inline JavaScript, most often used to fire on certain events such as onclick, but I'm not going to get into that here. Likewise for so-called "javascript:" protocol URLs, such as those used by bookmarklets.

A better solution is to use the src attribute of the <script> element to include external libraries of code. Some developers claim this can cause the page to load more slowly since it involves an extra HTTP GET request for each included JavaScript source file. In my opinion modularity, code maintenance and browser caching of the external scripts easily trumps these concerns.

So once you land on that page with the fancy JavaScript effects, what is the best way to study the techniques being used? One method is to open the source of the page, locate the code embedded in it, or in the case of external source, copy the URL to the file and make a separate request with your browser. Using this rather tedious method for external code with Firefox and most other browsers will result in the code being displayed in a window as plain text, although IE has a nasty habit of prompting you to download the file rather than simply displaying it.

A more elegant solution is to use JSView, a Firefox extension which will open up separate view-source windows for any or all external JavaScript files referenced by the current page (it will do the same thing for external CSS). I find this method acceptable if I only want to look at a particular file, and it sure beats hunting through the markup, copying (and possibly having to modify "../.." paths) then pasting the URL into the address bar of a another tab or window so you can continue to view and test the rendered page.

But this method only works for external source code. Some pages use a mixture of external files and embedded code. In these cases, the all-powerful Web Developer extension really shines. From the Information menu, select "View Javascript" and the extension opens a new tab with all the JavaScript from the current page concatenated into one view. Code from external files are labeled as such with links to the files, and embedded JavaScript is labeled as "Inline Script" referencing the document that defined it. The code appears in source-order, or in other words in exactly the same sequence as it is appears in the markup.

But source order is not important to the JavaScript interpreter embedded in your Web browser. It simply builds a collection of objects after receiving and parsing each form of source code, and then waits for some event to fire that will trigger the intended behavior. If you think in these terms, which I recommend, then Steve Chipman's JavaScript Object Tree favelet/bookmarket is the way to go. To use it, simply drag a copy of the link to your bookmarks toolbar, then on the page you want to study click the link. A new <div> element appears overlaying the top portion of the document and in it you will find a collapsed tree-view of every object type defined by that page. Object types include functions, objects (arrays, dates, etc.), strings, numbers, and so on. To expand an object type into a list of its members, just click on it. To view the value of an object, which in the case of a function is its source code, just click on the item by name. You can easily collapse parts of the tree in the same manner.

Another really handy favelet is Shaun Inman's View Rendered Source, which also overlays the current document with source code, but not JavaScript code. Rather, it displays the browser's internal view of the markup after any changes are made to the DOM. For example, if a script is using Ajax to insert new elements into the document tree and you want to observe the results, then the script will give you a before and after snapshot of the markup.

Remember that observation and studying working examples are powerful ways to learn how Web software is built, and a great way to improve your skills. Whether you are a new or a seasoned JavaScript developer, if you plan on studying code in the wild then Firefox and its many extensions, and any number of other tools (I'm just scratching the surface here) are the way to go.

On a tip from Krista at Digital Web Magazine, I learned that O'Reilly's seminal Web Design in a Nutshell by Jennifer Niederst was recently released in a 3rd edition. This is good news since the 2nd one was getting a little dog-eared and needed to play catch-up with the latest trends and techniques. I hope O'Reilly is planning on doing the same for Webmaster in a Nutshell.

Acclaimed accessibility advocate Derek Featherstone and Digital Web contributing author Aaron Gustafson both invested some of their time in the Nutshell project, and today A List Apart has published an excerpt from Aaron's work titled Getting Started with Ajax. The article does a good job of introducing Ajax concepts, including the JavaScript XMLHttpRequest object, various data formats that can be returned from such calls, and how to update the DOM of the page with the requested data. Aaron uses the simple XHConn interface library in his examples, and provides sample code, both markup and JavaScript. Keep in mind that ALA is not a programmer's magazine (any more than Digital Web is), so do not expect gory details here. But it is important for designers to understand Ajax development since it is a client-side technology. Or at least the designer's half of the equation.

And this leads to my point, something I plan on asking as many designers as I can corner at SXSW—in this day of Rich Internet/Web applications and Ajax (I really hate to mention Web 2.0), do you see the line between designer and programmer blurring a bit more? If you're not able to make it to the convention, feel free to post your viewpoints here, regardless of whether your area of expertise is design or code.

Google Page Creator — Or, return of the lame homepage builder. The builder isn't so lame (but the geocities concept is). The results? The DOCTYPE says XHTML Strict, the markup is so like 199x. See also all in the <head>.

Wufoo — A Flash-based form builder, with the eventual service of hosted surveys and the like. Slick interface with lots of pre-built patterns—see the demo. More at Particletree.

EvokeTV — Beats the stuffing out of the commercial TV Guide (and friends) services. For once, you won't be bombarded with ads just to find out what's on the telly. Caution: digg effect. Via ajaxian.

vood2do — Watch out 37signals. Similar to Ta-da list, and it's free. You might also want to take a look at Remember The Milk. voo2do is reviewed at Lifehacker.

Is there a common theme here? You betcha, pick your favorite buzz: Ajax, Web 2.0, RIA.

There's lots more where these came from, and lots more coming to be sure. Stay tuned.

Question: Which of the following DTDs allow target attributes with anchor elements?

• HTML 4.01 Strict
• XHTML 1.0 Strict
• XHTML 1.1

Answer: None of them.

The target attribute is designed for frames (who uses frames?)—if you want to use targets, use a Frameset or Transitional DOCTYPE.

Sadly, I am witnessing an ever growing trend with sites that serve strict document types (XHTML in particular) and insist on opening new windows from external links. Yet they still want to sport the "Valid" XHTML W3C badge on their sites.

The trick? Simple, just use a rel attribute of "external" on those anchor elements, and then dynamically alter the DOM using JavaScript to add a "_blank" target attribute.

It took me all of 5 minutes to write this little function and test it with an XHTML 1.1 document:

/* give anchors with attribute rel="external" a target attribute of "_blank" */

function external() {
 if (document.getElementsByTagName) {
  var i, a;
  a = document.getElementsByTagName('a');
  for (i in a) {
   if (a[i].getAttribute('href') && 
       a[i].getAttribute('rel') == 'external') a[i].target = '_blank';
  }
 }
}

window.onload = external;

/* external.js */

The results? The W3C Validator happily reported "This Page Is Valid XHTML 1.1!" Why? Because of course it doesn't know anything about what happens to the DOM after you've altered it with client-side scripting.

Is this old news? Probably. Do I intensely dislike people who insist on opening new browser windows just because they are under the (false) impression they will somehow retain the visitor by doing so? Yes, very much. And I happen to the think this point of view is ass backwards. Thankfully, I can use a browser like Firefox that allows me to at least redirect these links to a tab—and when I notice it happening, it usually only takes me one more visit before I mentally blacklist that site forever.

Are there times when opening a new window is warranted? Occasionally, if done with care and for the right reasons. I'm not going to get into that. Argue amongst yourselves.

Google has the mother of all datasets when it comes to a repository of Web page markup. Recently, the Google Code project released a set of stats on authoring techniques, sampled from over a billion documents. To view the results you will need a browser that supports both CSS and SVG. Firefox 1.5 is a good choice.

The overview cites both John Allsopp's study of semantics and François Briatte's design survey. Interestingly, it also mentions microformats.org and even a study done by Mozilla completed using their JavaScript Web Spider. Also noteworthy: Google admits they are “not leading the way in terms of validation.”

There is a lot of material to go over here, and among the most interesting bits are the frequency (popularity) charts that describe the distribution of class names used by developers. It turns out the most popular map consistently to the elements that are being proposed by the WHAT Working Group's so-called HTML5:

• header
• menu
• nav
• article (content, main, text...)
• footer

This list happens to be in structural order, as it turns out footer is the most popular class name. I use all of them, as do many people (my ego informs me perhaps I contributed to these stats). I can't help thinking of this as a sort of social tagging system, in which popular class names define semantics and drive the design of markup languages by consensus.

We are the Web—good stuff.

For many years I dismissed JavaScript as a toy language, something that was only used to perform cute Web tricks (who can forget mouseovers?). Worse (as is often the case), because folks quickly realized you could use it to open new windows, it was exploited (and still is to some extent) for advertising purposes. It also suffers from (perhaps even more so than HTML) the "how'd they do that?" copy-and-paste mentality that still pervades the Web to this day. The so-called browser wars certainly didn't help much, with Netscape and Microsoft going in different, proprietary directions with their implementations of the language.

I am not alone in these sentiments.

However, since the standardization of markup languages, JavaScript (ECMAScript), the DOM and, more importantly, the DOM Event Model (since JavaScript is most often used for creating "behavior" or interactive features), the language has really matured and is finally receiving the recognition that is long overdue.

Does your Web project require remote scripting (AJAX)? Then you will need to understand how to code in JavaScript. How about creating something using Greasemonkey? Or authoring a Firefox extension? Guess what—JavaScript is a key ingredient in Mozilla's powerful cross-platform development framework. If you want to get really fancy and add desktop features like animation, drag-and-drop, and so on, JavaScript is the method of choice.

Many of these examples ring true for me, and delving deeper into the language I found to my surprise that JavaScript is an elegant, deceptively simple, and powerful programming language. A new wave of frameworks and code libraries are paving the way out of the old days of HTML bulging with snippets of poorly written, embedded code. Another frequent complaint are the lack of tools necessary to ease the development of JavaScript code. Admittedly, the Venkman JavaScript debugger has been around for a while, but new tools such as the DOM Inspector, Console² and the MochiKit JavaScript Interactive Interpreter are changing all of that.

So, love it or hate it, even us old server-side developers must embrace this new JavaScript, and add it as a permanent member of our toolkits.