phpUnit

1. Setup

Install phpUnit using pear:

pear install phpunit

(See the PEAR site for how to install PEAR.)
Get the Kohana unittest module from http://github.com/kohana/unittest. If you aren’t using git for your repo, just clone the files (git clone http://github.com/kohana/unittest.git), get rid of the .git subdirectories and copy the module to your modules/ directory.

Follow the setup instructions on GitHub. Some tips:

It may be easiest to define an alternative default database configuration, since currently unittest does not automatically change any of the database configurations (ex. in models). Since I use a Fedora VM for development but prefer to run tests on Windows, I added the following logic to config/database.php:

if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
return array('default' => ..test config..);
} else {
return array('default' => ..normal config..);
}

I did the same thing in bootstrap.php, selectively enabling the unittest module and changing the cache dir based on the OS. You can probably think of some way to do the same in your setup even if you aren’t using a different OS for serving HTTP requests.

2. Creating tests

Tests for application files go into the application/tests/ folder you create.

Tests for any module (inc. application, database, unittest etc.) go in the ‘tests’ folder in the module.

Tests extend Kohana_Unittest_TestCase, not PHPUnit_Framework_TestCase.

To group individual tests into modules you need to add the tests to a group for that module. The convention for group names is modules.{module_name}. This is done using the docblock @group specification (can have multiple group specifications). See Writing Tests in the repo on GitHub.

3. Fixtures

The easiest way to create fixtures is to use setUp() to set the DB, then tearDown() to clean up. You can just use the DB class, or use ORM to add the records. Example:

class WhateverTest extends Kohana_Unittest_TestCase {
   function setUp() {
      // setup the DB
      DB::query(NULL, "TRUNCATE `kohana_test`.`whatever`;")->execute();
      $fixture_rows = array(
          array(
            'key' => 'billing_key',
            'value' => '0',
          ),
      );
      // add the necessary items
      foreach($fixture_rows as $row) {
         DB::insert('whatever', array_keys($row))->values(array_values($row))->execute();
      }
   }
   function tearDown() {
   }

There is probably a better way using a proper fixture class, but I haven’t seen one for Kohana yet.

4. Execution

You will need to specify the path to the KO3 webroot index.php as the bootstrap for phpUnit. This is because the dependencies which your code has need to be loaded by Kohana.

By default, all tests in application/tests/ will be run.

phpunit --bootstrap=index.php ./modules/unittest/tests.php

To run a specific group of tests on the cli add –group {groupname.in.testfile} between the –bootstrap switch and the path to the tests folder.

phpunit --bootstrap=index.php --group groupname.in.testfile ./modules/unittest/tests.php

phpDocumentor

Install phpDocumentor using PEAR: pear install phpDocumentor.

On Windows, if you use paths with spaces in them it is easiest to make sure that phpDocumentor is in the php include path (edit php.ini if necessary), and invoke php while passing the phpdoc file directly (see below for example).

You will probably only want to generate API docs for application/, perhaps selectively adding a few modules. And you probably want to exclude: application/vendor/, application/logs/, application/views/, application/bootstrap.php and application/config/ from the API documentation.

Remember that phpDocumentor does not support multiple option specifications: you have to join the paths with a comma. Furthermore, remember to have the directory separator character at the end of directories to trigger the correct interpretation.

Kohana3 uses a number of custom tags, so you will want to exclude those. Here is a sample run:

php "c:\Program Files (x86)\PEAR\phpdoc" --directory application/
--ignore application/vendor/,application/logs/,application/views/,application/bootstrap.php,application/config/ --target doc/api
--customtags type,default,constructor,chainable,class,namespace,module,group

There are a few options that may also prove useful:
–parseprivate causes private methods to be shown
–output HTML:frames:earthli changes the output to earthli, which I like.
–undocumentedelements Adds warnings to errors.html for undocumented elements.

Recently, I did a project using the Thematic theme framework for WordPress, and that got me thinking about how custom web applications interfaces could be improved. As an individual developer, I rarely have the luxury of focusing on the details of the layout. In contrast, the developers building theme frameworks have spent years thinking about how to create a generic, extensible structure for web application interfaces.

I had a look at Thematic, WP-Framework and Theme Hybrid (see more frameworks in this Smashing Magazine article). I used Thematic, since I ended up using it in the WordPress project I did. Here is how Thematic does it’s HTML layout:

An overview of the HTML code (based on Thematic)

I think the most interest parts of Thematic for web application design are the HTML structure, use of ids and classes and the CSS files. The hook-and-filter system (overview here) is less interesting from the web application point of view, since you will most likely be writing all of the code from scratch for your own web applications.

<body class="wordpress y2010 m06 d02 h03 home blog not-singular windows firefox ff3">
<div id="wrapper">
   <!-- Header -->
   <div id="header">
      <div id="branding">
         <div id="blog-title"><span>...</span></div>
         ...
      </div>
      <div id="access">
         <div class="menu"><ul>...</ul></div>          
      </div>
   </div>
   <!-- Main -->
   <div id="main">
       <div id="container">
          <div id="content"><div>...</div></div>
       </div>
       <div id="primary"><ul>...</ul></div>
   </div>
   <!-- Footer -->
   <div id="footer">
      <div id="siteinfo">...</div>
   </div>
</div>
</body>

1. Body and wrapper

In all of the frameworks, the body classes contain various information such as the platform (windows) and the browser (firefox, ff3).

Benefits:
Easier to specify per-browser css fixes (if needed). This makes it easier to make adjustments based on the browser or OS used in CSS, eg. “.windows xxx.yyy { … }”.

Separation between body and content wrapper. In the framework, the content is wrapped in a wrapper layer (id=wrapper), so that the body has only one child element. I would imagine this is to make it easier to use CSS to adjust the padding and background of the pages.

2. Heading

The heading consists of two sub-divs, as shown below:

There are only three subelements to the content wrapper: heading, main and footer. Each of these divs is full-size and positioned relatively.

Benefits:
Easy to add repeating backgrounds. One can easily apply a CSS background-image to create a repeating and consistent heading.

Easy positioning of the elements. The heading consist of the branding and access divs. This makes it easy to add new heading elements in the branding, while keeping the menu (=access div) separate, with it’s own background.

Standard menu HTML. All of the frameworks appear to be using the Superfish menu by default, which is based on jQuery.

3. Main content

The main content consists of a container with a content-sub-div and a primary sidebar:

The main content div has a fixed size. This is then subdivided into two divs, container (for the content) and primary (for the primary menu block).

Benefits:
Semantic markup; floats to reposition Having these separate divs means that switching from “menu on the right” to menu on the left is simple, since one can change the CSS float directions to reverse the positions of the subcontainers.
Easy to add new content areas One could also add more subdiv for additional content areas, and create multiple columns relatively easily by positioning the subdivs within the main content div.
Easy to add sub-items The primary menu is a div, with each block having its own unordered list (ul). In practice, this leads to two levels of lists – one for the item blocks themselves, the other for the sub-items (e.g. the links in a Archives block).

4. Footer

The footer consists of a single subdiv:

Again, the top-level div only specifies the margin, while the inner divs are positioned within it. This makes it easy to add a background to the footer div.

Does this work?

I’m currently using this approach in recent two web applications I built. The markup seems a lot cleaner, more standard and I have found that re-theming the same basic HTML is much nicer than reinventing the wheel. In short, I think this is a good approach. Let me know if you have improvements via a comment.

Somewhat related: What about other techniques, such as CSS Grid frameworks or Haml/Sass?

I’m not yet convinced that I need to use a CSS Grid framework (e.g. Stackoverflow discussion).

As for Haml, I’m pretty sure that I am fine with regular HTML without any syntactic sugar.

Sass seems to be a real improvement over CSS (variables, nesting, mixins etc.), but on the other hand I haven’t had the time to set it up with my non-Ruby environment.

Check for whether there is a another repo, e.g. a .svn directory somewhere in your path. Netbeans seems to allow “stacking” source control systems, and will unsuccessfully try to load this versioning data instead of whatever you are using in your repository. This means that you won’t get those pretty markers for modified lines and won’t be able to view history for those files or perform a diff from the Netbeans GUI.

See ~/.netbeans/$version/var/log/messages.log for debugging information. Look for messages related to source control loading failures.

Get rid of the extra directories (e.g. .svn in each directory) in your repo, and delete ~/.netbeans/$version/var/cache/svncache to avoid conflicts with cached incorrect versioning data.

Warning: mysql_connect(): OK packet 6 bytes shorter than expected in ...
Warning: mysql_connect(): mysqlnd cannot connect to MySQL 4.1+ using old authentication in ... 

I run my Linux servers on VMWare when I do development, so the MySQL database itself was from quite a while ago. As you will see, the core issue here is that MySQL can have passwords with hashes stored in the old 16-character format, which is not supported by PHP 5.3′s new mysqlnd library.

Since I couldn’t find a good solution with a quick Google, here is how I solved this without having to downgrade PHP or MySQL (as some of the solutions suggested):

1. Change MySQL to NOT to use old_passwords

It seems that even MySQL 5.x versions still default to the old password hashes. You need to change this in “my.cnf” (e.g. /etc/my.cnf): remove or comment out the line that says

old_passwords = 1

Restart MySQL. If you don’t, MySQL will keep using the old password format, which will mean that you cannot upgrade the passwords using the builtin PASSWORD() hashing function. You can test this by running:

 SELECT Length(PASSWORD('xyz'));  
+-------------------------+
| Length(PASSWORD('xyz')) |
+-------------------------+
|                      16 | 
+-------------------------+
1 row IN SET (0.00 sec)

The old password hashes are 16 characters, the new ones are 41 characters.

2. Change the format of all the passwords in the database to the new format

Connect to the database, and run the following query:

SELECT user,  Length(`Password`) FROM   `mysql`.`user`;

This will show you which passwords are in the old format, ex:

+----------+--------------------+
| user     | Length(`Password`) |
+----------+--------------------+
| root     |                 41 | 
| root     |                 16 | 
| user2    |                 16 | 
| user2    |                 16 | 
+----------+--------------------+

Notice here that each user can have multiple rows (one for each different host specification).

To update the password for each user, run the following:

UPDATE mysql.user SET Password = PASSWORD('password') WHERE user = 'username';

Finally, flush privileges:

FLUSH PRIVILEGES;

What this code does

What the code below does is it checks whether the translation string exists, if not then it saves it into the translation file with the English equivalent. This updated version of the translation string file is saved into /application/i18n/languagename.php, and the old file is saved with a new name containing the current date and time.

Hope this helps!

How to set it up

First set the language using i18n::lang(‘xy-xx’) in bootstrap.php.

Also, add the following as the last line in bootstrap.php:

// Write the updated language file, if necessary
i18n::write();

Finally, add the file /application/classes/i18n.php which overrides i18n::get():

<?php
/**
 * A patch for the Internationalization (i18n) class.
 *
 * @package    I18n
 * @author Mikito Takada
 */
class I18n extends Kohana_I18n {
   // Cache of missing strings
   protected static $_cache_missing = array();
   /**
    * Returns translation of a string. If no translation exists, the original
    * string will be returned.
    *
    * @param   string   text to translate
    * @return  string
    */
   public static function get($string)
   {
      if ( ! isset(I18n::$_cache[I18n::$lang]))
      {
         // Load the translation table
         I18n::load(I18n::$lang);
      }
      // Return the translated string if it exists
      if(isset(I18n::$_cache[I18n::$lang][$string]))
      {         
         return I18n::$_cache[I18n::$lang][$string];
      } else {
         // Translated string does not exist
         // Store the original string as missing - still makes sense to store the English string so that loading the untranslated file will work.
         I18n::$_cache_missing[I18n::$lang][$string] = $string;
         return $string;
      }
   }
 
   public static function write()
   {
      // something new must be added for anything to happen
      if(!empty(I18n::$_cache_missing)) {
         $contents = '<?php defined(\'SYSPATH\') or die(\'No direct script access.\');
/**
 * Translation file in language: '.I18n::$lang.'
 * Automatically generated from previous translation file.
 */
return '.var_export(array_merge(I18n::$_cache_missing[I18n::$lang], I18n::$_cache[I18n::$lang]), true).';';
 
         // save string to file
         $savepath = APPPATH.'/i18n/';
         $filename = I18n::$lang.'.php';
         // check that the path exists
         if(!file_exists($savepath)) {
            // if not, create directory
            mkdir($savepath, 0777, true);
         }
         // rename the old file - if the file size is different.
         if(file_exists($savepath.$filename) && ( filesize($savepath.$filename) != strlen($contents) ) ) {
            $result = rename($savepath.$filename, $savepath.I18n::$lang.'_'.date('Y_m_d_H_i_s').'.php');
            if(!$result) {
               // Rename failed! Don't write the file.
               return;
            }
         }
         // save the file
         file_put_contents($savepath.$filename, $contents);
      }
   }
}

Caveats and notes

There are two things that have to be taken into account:

• First, this is would obviously be inefficient for a production site, since actual files are being rewritten on each request that finds new translation strings.
• Why this is not a problem: My recommendation is that you shouldn’t run this code in production mode, since there is no point and it is very easy to remove the code after developement is completed.
• Second, this approach is less comprehensive than using something like the gettext tools that are available – those tools scan all of the source code, while my approach depends on run-time detection of new strings. This means that a small percentage of strings will not be found automatically (ex. rare errors that never get triggered).
• Why this is not a problem: This approach will still get the vast majority of the strings without requiring any manual hunting for strings, so I think it’ll save you quite a bit of time.

Problem 1: I can’t load page URLs except when using ?p=xyz permalinks

If you are having problems with page URLs not working on multisite domains, make sure you have:

    AllowOverride FileInfo Options

defined in your httpd.conf for the directory the Virtual host is in.

Problem 2: The new themes I installed and activated on the main WP 3.0 site do not show up on separate domains

The permissions for separate domains do not get automatically updated when you activate themes on the main site.

In MySQL, copy the value for “allowedthemes” in the wp_sitemeta table. This will enable themes on separate domains. Example:

INSERT INTO `wordpress_database`.`wp_sitemeta` (`meta_id`, `site_id`, `meta_key`, `meta_value`) VALUES (NULL, '2', 'allowedthemes', 'a:2:{s:9:"it-oikeus";b:1;s:9:"twentyten";b:1;}');

where the site_id is the site ID for the separate domain, and meta_value is copied from the first site.

Problem 3: I cannot access Plugins on separate domains

In MySQL, copy the value for “menu_items” in the wp_sitemeta table. This will enable plugins on separate domains. Example:

INSERT INTO `wordpress_database`.`wp_sitemeta` (`meta_id`, `site_id`, `meta_key`, `meta_value`) VALUES (NULL, '2', 'menu_items', 'a:1:{s:7:"plugins";s:1:"1";}');

where the site_id is the site ID for the separate domain, and menu_items is copied from the first site.

Problem 4: New users are not visible on separate domains

in wp_usermeta, set:

wp_2_capabilities = a:1:{s:13:”administrator”;s:1:”1″;}
wp_2_user_level = 10

(NEW June/2010) Problem 5: Upload files not working on separate domains

Replace site_id (2) with your site id in the query below:

INSERT INTO `wordpress_database`.`wp_sitemeta` (`meta_id`, `site_id`, `meta_key`, `meta_value`) VALUES (NULL, '2', 'upload_filetypes', 'jpg jpeg png gif midi mid aac ac3 aif aiff m3a m4a m4b mka mp1 mp2 mp3 ogg oga ram wav wma asf avi divx dv flv m4v mkv mov mp4 mpeg mpg mpv ogm ogv qt rm vob wmv doc docx docm dotm odt pages pdf rtf wp wpd numbers ods xls xlsx xlsb xlsm key ppt pptx pptm odp swf asc csv tsv txt bz2 cab dmg gz rar sea sit sqx tar tgz zip css htm html php js
');

The basic steps are:

1. Move posts
2. Move attached files
3. Fix URLs in posts
4. Move/recreate users

1. Moving the posts from WP 2.9 to 3.0

Moving the posts, links, comments and terms to WP 3.0 is quite easy. A table-by-table comparison shows that the main tables have identical structures (comparison between a 2.9.2 site and 3.0 beta 2). This means that we can use SQL for the migration. Alternatively, you could export and import (see the functionality under Tools -> Export / Import).

In WP 3.0, the tables are sharded – each blog has it’s own set of tables, and the id of the blog is used as a part of the table name: for example, wp_2_commentmeta is the wp_commentmeta table for the multisite blog with id=2. Find out what the blog_id for your blog is, and use it in the SQL queries below.

I performed the following queries, which move all the tables EXCEPT the options table. Moving the options table seems to result in a broken blog, since the themes, settings and plugins referenced by WordPress will not exist in the new environment.

TRUNCATE newblog.wp_2_commentmeta;
INSERT INTO newblog.wp_2_commentmeta SELECT * FROM oldblog.wp_commentmeta;
 
TRUNCATE newblog.wp_2_comments;
INSERT INTO newblog.wp_2_comments SELECT * FROM oldblog.wp_comments;
 
TRUNCATE newblog.wp_2_links;
INSERT INTO newblog.wp_2_links SELECT * FROM oldblog.wp_links;
 
TRUNCATE newblog.wp_2_postmeta;
INSERT INTO newblog.wp_2_postmeta SELECT * FROM oldblog.wp_postmeta;
 
TRUNCATE newblog.wp_2_posts;
INSERT INTO newblog.wp_2_posts SELECT * FROM oldblog.wp_posts;
 
TRUNCATE newblog.wp_2_terms;
INSERT INTO newblog.wp_2_terms SELECT * FROM oldblog.wp_terms;
 
TRUNCATE newblog.wp_2_term_relationships;
INSERT INTO newblog.wp_2_term_relationships SELECT * FROM oldblog.wp_term_relationships;
 
TRUNCATE newblog.wp_2_term_taxonomy;
INSERT INTO newblog.wp_2_term_taxonomy SELECT * FROM oldblog.wp_term_taxonomy;

What if these queries fail?

Some WordPress plugins modify the default tables – which means there are extra fields that need to be ignored. If the INSERT INTO statements below don’t work for you, you need to explicitly state the names of the source and destination fields instead of using *. This means losing the added fields, so you need to think about it on a case-by-case basis. See the MySQL docs for INSERT INTO … SELECT syntax.

2. Moving attached files

WP 3.0 uses a slightly different directory structure for multisite. The files for each blog are under blogs.dir/[blog_id]/, and use the same substructure as before. Hence, the new directory structure is like this:

/wp-content/blogs.dir/[blog_id]/files/...

and if you keep using the same structure (ex. “year/month/filename”) you can just copy the files:

mkdir -p ./wp-content/blogs.dir/[blog_id]/files/

cp -R ./oldblog/wp-content/uploads/* ./newblog/wp-content/blogs.dir/[blog_id]/files/

3. Fixing URLs in posts

Try loading a post with images. The URLs (may) change from:

http://blog.domain.com/wp-content/uploads/2010/04/image.png

to:

http://blog.domain.com/files/2010/04/image.png

You can fix this by performing a replace on the wp_[blog_id]_posts table:

UPDATE wp_2_posts SET guid = REPLACE(guid, "http://oldblog.domain.com/wp-content/uploads", "http://blog.domain.com/files");
UPDATE wp_2_posts SET post_content_filtered = REPLACE(post_content_filtered, "http://oldblog.domain.com/wp-content/uploads", "http://blog.domain.com/files");
UPDATE wp_2_posts SET pinged = REPLACE(pinged, "http://oldblog.domain.com/wp-content/uploads", "http://blog.domain.com/files");
UPDATE wp_2_posts SET post_excerpt = REPLACE(post_excerpt, "http://oldblog.domain.com/wp-content/uploads", "http://blog.domain.com/files");
UPDATE wp_2_posts SET post_content = REPLACE(post_content, "http://oldblog.domain.com/wp-content/uploads", "http://blog.domain.com/files");

If you also changed the domain, you need to fix the links (do this after you fix the file upload paths):

UPDATE wp_2_posts SET guid = REPLACE(guid, "http://oldblog.domain.com", "http://blog.domain.com");
UPDATE wp_2_posts SET post_content_filtered = REPLACE(post_content_filtered, "http://oldblog.domain.com", "http://blog.domain.com");
UPDATE wp_2_posts SET pinged = REPLACE(pinged, "http://oldblog.domain.com", "http://blog.domain.com");
UPDATE wp_2_posts SET post_excerpt = REPLACE(post_excerpt, "http://oldblog.domain.com", "http://blog.domain.com");
UPDATE wp_2_posts SET post_content = REPLACE(post_content, "http://oldblog.domain.com", "http://blog.domain.com");

4. Moving the users

You can either 1) manually create new user accounts for your users, or 2) try to move the user accounts. Most blogs don’t really have many users beyond the admin, since commenting doesn’t need a user account. My recommendation would be to manually add the very few users you have.

If you want to move the users in bulk using SQL, then you will need to take into account that:

1. In WP 3.0, the wp_users table is shared among all the sites.
2. The wp_users table in WP 3.0 has two extra fields: spam and deleted.
3. Each blog site has its own wp_capabilities, wp_user-settings and wp_user-settings_time fields (e.g. wp_2_capabilities) in the wp_users table. The format (serialized PHP arrays) appears to be the same, so you will need to create one user with the rights you want manually, then these three keys for each of the blogs you want to user to be able to access.

I didn’t try this out, since the blogs I have only use a small number of users. I just created individual admin accounts for those blogs that I am not administering personally.

Here is my guide to setting up WordPress 3.0 with multiple different domains and subdomains – based on the experience I got from moving my own blogs to WP 3.0 beta 2 (still waiting for the final release before moving clients as well).

Installing WordPress 3.0

The basic installation process is the same as that of WP 2.9. Download, unzip, set up the database and the set up wp-config.php. If you aren’t going to use the multi-site support, then not much will change. Brief instructions below.

Multi-site mode with Apache

You will need to separately enable the multi-site mode, as well as take care of your Apache settings. WP 3.0 will handle all the requests it gets from a single directory, which means that all your subdomains must use that directory as their DocumentRoot/VirtualDocumentRoot.

Furthermore, WP 3.0 will assume that if you are using multi-site mode with subdomains, you want the subdomains under the first site’s URL – ex. if your first WP 3.0 install is under www.domain.com, then WP 3.0 will set up subdomains in the format subdomain1.www.domain.com.

That means that if you want to use first-level subdomains (ex. blog.domain.com, subdomain2.domain.com etc.), you have to set up WP 3.0 so that your first blog is using the bare domain (ex. domain.com) and not on the www.domain.com subdomain.

0. (Optional) Bare domain setup for Apache

The way in which you setup your bare domain (and forward from the www -subdomain to the bare domain) depends a lot on how you have set up your domain originally in Apache.

I have been using virtual hosts to host multiple sites, with each subdomain having its own directory. This means that I had to add an additional Vhost directive before my original Vhost directive in httpd.conf. Here is how I did it:

    ServerName domain.com
    ServerAlias domain.com blog.domain.com subdomain1.domain.com
    DocumentRoot /var/www/domain.com/www

As you can see in the first Vhosts directive, I have used the ServerAlias directive to specify domain.com, blog.domain.com and subdomain1.domain.com to be served from the DocumentRoot /var/www/domain.com/www (which is where I have installed WP 3.0).

In addition, I still have the rest of my subdomains served from a VirtualDocumentRoot, and have a forward from the www.domain.com -subdomain to the domain.com bare domain.

    ServerName domain.com
    ServerAlias *.domain.com
    VirtualDocumentRoot /var/www/domain.com/%1
    # rewrite www to bare domain
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^www\.domain\.com$ [NC]
    RewriteRule (.*) http://domain.com$1 [R=301,L]

Apache will use the first matching VirtualHost directive (see “An in-depth discussion of Virtual Host Matching” for more details).

If you want to test your setup – remember to restart Apache – you can use an online redirect checker such as: http://www.internetofficer.com/seo-tool/redirect-check/

1. Get the files and unzip them

2. Edit wp_config_sample.php

You can use https://api.wordpress.org/secret-key/1.1/salt/ to generate the secret keys

3. Enable multisite

Add:

 define(’WP_ALLOW_MULTISITE’, true);

to wp-config.php after the secret keys

4. Log in, go to Tools/Network

Select either the blogs-as-subdomains or blogs-as-directories option and install.

5. Make the changes detailed on the post-install page

WP 3.0 gives you a number of changes you will need to make manually to .htaccess and wp-config.php.

Adding a new subdomain

You have now set up the multisite functionality. Next, add a subdomain (see below for how to add a different domain).

1. Login in on your main site

2. Go to Super Admin (new menu at the top)

3. Use the add site form to add a new subdomain

4. Configure your DNS and add a Vhost for the subdomain

Make sure there is a DNS entry for your subdomain – if you don’t have a wildcard redirect for your domain to your server. If you did the Apache configuration, all you need to do now is to set up your DNS so that the subdomains you want are mapped to your server.

Quick tip for Windows: edit C:\Windows\System32\drivers\etc\hosts and add a temporary hosts entry for your new subdomain, such as:

123.14.15.16 subdomain.domain.com

This will allow you to test the subdomain without having to wait for DNS to propagate. Under Win7, you need to start Notepad as an Administrator (right-click) to edit the file.

5. All done!

Try navigating to your new subdomain. It should be set up now!

Adding a new (different) domain

1. Use the add site form to add a new subdomain

You will use the default tools to create all the tables, then you will make a small number of changes to make WordPress accept a different domain. All credit for this method goes InterconnectIt – see their writeup here.

2. Configure your DNS and add a Vhost for the subdomain

The easiest way is to add another ServerAlias domain to the original domain’s VirtualHost -> ServerAlias directive.

If you try to access the site now, you will get a “Registration” page. This means the Vhost is working.

3. Edit the wp_site table to include your new domain

This table stores all the domains that can be used in WP 3.0.

Leave “id” empty (it is an autoincrement field), set “domain” to the domain name, “path” should be /.

Make a note of the id your newly inserted row gets after saving, since you will need it in the next step.

4. Edit the wp_blogs table to use the new domain

Find the row for the subdomain you added earlier. Change “site_id” to the id given to the new row in the wp_site table. Change “domain” to the domain name you want to use.

5. Edit wp_[blog_id]_options to use the new domain name

The WP 3.0 multisite database schema is sharded by having the blog id in the table names. By default these are in the form wp_[blog_id]_*, so you will need to find which set of tables contains your new blog.

Each WordPress blog stores a small number of settings which need be changed to use the new domain name. You can use the query below to find the mentions of the domain in the options table:

SELECT * FROM `wp_[blog_id]_options` WHERE `option_value` LIKE "%subdomain.domain.com%";

For me these are: siteurl, home, fileupload_url. Change them to use the new domain.

6. Done!

Do you need to move an existing WP 2.9 to WP3.0 multisite? If you are moving an existing site to the WP multisite you’ve set up, check out my second tutorial on the topic.

Did you run into problems enabling themes or plugins on your separate domains? Have a look at how I solved a number of issues related to the separate domains setup.

References

1. http://www.interconnectit.com/840/wordpress-3-0-multisite-with-multiple-domains-setup/

Choice of font

My font of choice is Consolas (included in Vista/Win7 and available for download). It looks awesome with ClearType and the zero character is different from the letter O. My second choice is Bitstream Vera Sans Mono, which is free and widely available.

The Code Project has a great compilation of the 42 best programming fonts.

Choice of color

The basic choice is between a dark background and a light background. Full contrast schemes are considered more hard to read, which means that slightly off-white or off-black backgrounds are easier to read.

Personally, I prefer white or off-white with dark text. Jeff Atwood did some background reading into this and quotes from a study that “When light text is placed on a dark background the text may seem to glow and become blurred; this is referred to as halation, and it may make the text harder to read.” Subjectively, I find white text on dark backgrounds to be a bit uncomfortable.

“If everything is important, then nothing is important”. This was mentioned in Garret Dimon’s Application Interface Design presentation, and I think it is a good point: Don’t highlight every syntactically different part of the code with sharp colors, just the stuff that matters the most. For me, these would be the keywords, variables and class names.

Hence I changed comments to be de-emphasized (gray) as well as any HTML tags (which are less important than the code in views). I am experimenting with a off-white background to slightly reduce contrast and eyestrain.

My color scheme:

See what my color scheme looks like at the bottom of the post. You can download it for NetBeans here.

More color schemes:

Whether or not you use Visual Studio (I use Netbeans), go check out the great gallery of syntax coloring schemes at studiostyles. They have dozens of user-submitted color schemes and alternatives which you can use as a basis for configuring your own IDE.

Make a test page that has:

1. All of the common HTML elements
2. All of your widgets and inline elements

… on one page. This allows you to make and preview changes quickly.

Snippllr.com has a couple of test pages containing the major HTML elements:

http://snipplr.com/view/8121/html-test-page-for-css-style-guide/
http://snipplr.com/view/12564/css-test-page/

2. Start with a CSS reset

Using a CSS reset helps because it eliminates the inconsistencies between browsers and forces you to specify all of the styles you want. It makes CSS stylesheets more explicit, which is a good thing for maintainability.

http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/

http://developer.yahoo.com/yui/reset/

3.Order your rulesets into sections – generic to specific

Use stylesheet rule order to define “base” and “special case” tags. First, organize your CSS rules into sections so that the most generic rules (e.g. typography) come first before specific rules such as widgets. This is useful because it makes it easier to locate rules within the file and to make modifications.

For example, I have used the following sections:

4. Order your widget rules from “base” to “special case”

Organize the rules into “base” widgets and “special case” if necessary. Have the “base” widget specify the most important rules, and then override for the “special case”.

5. Indent your CSS files!

Use indentation to organize the code – the first level of indentation is for sections, the second for widgets and the third for special cases of widgets or sub-widgets. (If you are concerned about bandwidth, use a CSS minifier afterwards – don’t sacrifice understandability just to try to save a few characters).

For example:

/** Css reset **/
/** Base styles **/
   ...
/** Typography styles **/
   ...
/** Layout styles **/
   /** Containers **/
   ...
/** Widgets **/
   /** Information messages **/
   ...
   /** Tabs widget **/
   div.tabs {
      ...
   }
   div.tabs ul {
      ...
   }
   div.tabs ul li {
      ...
   }
   div.tabs ul a:link, div.tabs ul a:visited {
      ...
   }
   div.tabs ul li.selected a, div.tabs ul a:hover {
      ...
   }

6. Keep the dependency chains as short as possible

Avoid modifying the HTML element styles without specifying a class. Adding styles to tags without a class -attribute is problematic because it makes the dependencies much more complex.

By keeping dependency chains short – so that the base CSS is unmodified and all necessary styles are defined on a class-specific level –  you keep the dependencies reasonably simple.

7. Never rely on coincidental nesting & avoid “class-itis”

“Class-itis” is the disease that causes CSS files to have too many classes. Instead, use tag nesting to create widgets.

Have single base element with a simple but descriptive class name, and then specify the sub-elements.

For example:

• Instead of “div.content-title” use “#content h1″ (e.g. div#content with a h1 tag inside it)
• Instead of “div.form-label” use “#form label” (e.g. form#form with a label tag inside it)