Today’s nugget:
In reference to the bug that causes default text served to an input to populate again if a user types too fast.

"Oh great, when we fix it, it will be reused by all of our apps – it’s a polyfill fix!"

I thought a polyfill was when you apply color to polygon. Is my front-end background obvious now?

Bo heard it from Paul Irish, the more commonly known gold-nugget dropping web dev.

No need to recreate the wheel, just read this: What is a polyfill?.

Embed code for the map above:
[walk-score-map address="1450 Pennsylvania Avenue Northwest, Washington DC" format="vertical" size="small"]

Now the Sydney Opera House, following the embed code used to create it:

[walk-score-map address="Macquarie St, Sydney New South Wales 2000, Australia" format="horizontal" size="small"]

Local Apache web server with PHP & Mysql.

If you don’t already have your local dev environment set up, consider installing MAMP or MAMP Pro. MAMP is a one-click install which will provide you with a clean, isolated stack for local development that has Mysql and PHP pre-configured. Another benefit of MAMP is that it is very popular so there are countless tutorials and examples to follow.

If for some reason you don’t want to use MAMP or you’ve already configured your local enviro somewhat but you still need PHP and/or MySQL, check out this article: Install and Configure WordPress on Mac OS X Snow Leopard Step-By-Step by awilliams of Thermal Exposure. It takes you from zero to WordPress using Leopard’s built-in Apache server, although I do recommend you supplement these instructions with these tips and my other article Install Mysql for Local Dev on Mac OSX 10.6

Download WordPress

Download and extract the latest WordPress package.

Move it somewhere good like in your /Sites/ folder (most usual place but depends on your config, it can go anywhere you desire so long as your local web server is configured to look there).

I moved mine to /users/me/Sites/wordpress and renamed ‘wordpress’ to ‘wptest.loc’ resulting in: /users/me/Sites/wptest.loc. You can rename it whatever you want – probably the name of your project or client’s site is a good idea.

WordPress needs permission to modify files during installation and runs as user “_www” so make sure it can do this.

cd /Users/me/Sites/
sudo chown -R _www wptest.loc
sudo chmod -R g+w wptest.loc

Create a Database

Now we need a database, a database user and a password. Technically you can use any user or add WordPress tables to an existing database but I like to keep things separate so it’s easy to port elsewhere or start over without worrying about wrecking other things. I’m going to create a database called wptest, database user named wptest_user. You can do this using a GUI (phpMyAdmin, etc.) but I guarantee you cannot do that faster than I can type this ;)

bash > mysql -u root -p
mysql > create database wptest;
mysql > GRANT ALL ON wptest.* TO wptest_user@localhost IDENTIFIED BY "secretpassword";
mysql > exit

Configure Site Address

Remember how I renamed the wordpress folder to wptest.loc? This is because I plan on accessing it in the browser via http://wptest.loc instead of http://127.0.0.1/ or http://localhost.

To do this I use Virtual Hosts in my environment and point the virtual domains to my local IP address in my hosts file. It’s confusing at first but once you do it a time or two it will be second nature. It’s important if you’d like to work on multiple sites on your local environment concurrently and don’t want to rely on weird subdirectories or other work-arounds that wouldn’t easily port to a live web server.

Setting Up Virtual Hosts on MAMP explains how to set this system up. I provide only abbreviated steps below (MAMP not assumed).

Setting up Virtual Hosts (in short)

• In your httpd.conf file there should lines like this:
  

  # Virtual Hosts
  Include /path/to/your/httpd-vhosts.conf

• In your httpd-vhosts.conf file there should be a line like this:
  

  NameVirtualHost *:80
  Include /path/to/your/httpd-vhosts.conf

Create A Virtual Host

Now, whenever you want to create a new virtual (local only) site:

• In your httpd-vhosts.conf file add an entry like this:
  

  <VirtualHost *>
      ServerName wptest.loc
      DocumentRoot "/Users/me/Sites/wptest.loc"
    <Directory "/Users/me/Sites/wptest.loc">
      Order allow,deny
      Allow from all
      DirectoryIndex index.php index.html
    </Directory>
  </VirtualHost>

• In your hosts file (mine is /etc/hosts) add another entry for your local IP:
  

  127.0.0.1    wptest.loc

Install WordPress

Point your browser to http://wptest.loc

If no config file is found you can edit it yourself, wp-config-sample.php as wp-config.php and adding the correct information for the database you created. Try using 172.0.0.1 as the Dataase Host if localhost doesn’t work.

I am using the EEDocs wiki theme to provide documentation for my users. Here are very quick and dirty instructions to add TinyMCE to your EE Wiki which basically follows the default instructions provided by the TinyMCE Wiki.

• Download TinyMCE, extract it.

• Upload the TinyMCE to your webserver, note the path.

• Find the default PHP file for the EE wiki theme you are using. Mine was in my siteroot/themes/wiki_themes/eedocs/ folder and is called eedocs.php. The default them would be in the themes folder under wiki_themes/default/default.php. Open this in the editor of your choice. You may want to create a backup copy in case you need to revert later.

• Add the following code to the <head> area:

  <script type="text/javascript" src="http://yoursite.com/yourpathto/tinymce/jscripts/tiny_mce/tiny_mce.js"></script>

  Note you may want to test that path in your browser and make sure it is linking to the tiny_mce.js path as intended.

• Add the following inline script to the <head> area :

  <script type="text/javascript">
tinyMCE.init({
mode : "textareas"
});
</script>

This will turn all of your textareas into TinyMCE editor fields. There are many other ways to configure this, you could specify exactly which textareas to use TinyMCE, for example. For all your TinyMCE customization options, see the TinyMCE wiki and for help knowing where to put what, check out the ExpressionEngine User Guide section on the Wiki Theme Template.

I can’t say I’ve done extensive testing yet, but the default TinyMCE install has not (so far) interfered with wiki markup at all, which is to say that [[Category:Foo::Bar]] and regular [[wiki links]] seem to be working happily.

Screenshot:

Update: Installed the MarkItUp editor in a similar fashion, I like it a lot more than TinyMCE out of the box. May be looking at Textile Editor Helper (TEH) and CKEditor as well, so check back for a WYSIWYG / markup editor showdown. In the meantime, consider what you need a WYSIWYG for and what markup under the hood you’re willing to live with in the long-term before settling on a solution for your site – here’s a good article that sums up that issue: WYSI-dangerous: Why WYSIWYG editors are bad for your website on redcloth.org.

If you want to skip the wheres and whys, I've posted the the updated (fixed) and improved RSS templates on Snipplr.com and in their entirety at the end of this article.

Existing RSS templates for ExpressionEngine

• ExpressionEngine > Downloads > Template Library > Feeds - this template will be the basis of my recommendations, most other templates I've found seem to be derivative of this one.
• Customizing ExpressionEngine RSS 2.0 Template - an oft-referred to article at 'A Blog Not Limited' which provides some good updates and tweaks but that still keeps a lot of the original template intact.

Resources

• RSS 2.0 Specification
• Feed Validator
• ExpressionEngine User Guide
  • RSS Module Tags
  • Date Variable Formatting
• EE XML Encode Plugin Information

Methodology

I'm not going for a PHD in online syndication, I just wanted my RSS feeds to be error-free, work as expected in major aggregators and to use best-practices which could be determined within a somewhat low threshold of research pain. In addition to referring first to the RSS 2.0 specifications, I used the RSS feeds of some really large websites to serve as examples, making the assumption (I know) that these sites have probably done thorough research on this topic. Often my choices were the result of seeing if these "big players" were all doing the same thing. All the feeds are major sites with the exception of the Flickr blog. The Flickr blog is using WordPress.com. I figured with their huge user-base not only would the feeds have been thoroughly vetted, most aggregators will be able to read them due to the sheer volume of WordPress-powered sites out there. Also I chose a WordPress.com feed instead of a self-hosted installation of WP to make sure it was the well-tested standard feed. The feeds I used are:

• The New York Times Home Page Feed
• BBC News | News Front Page | World Edition Feed
• CNN.com Top Stories Feed
• MSNBC.com Women's Helath Feed
• Flickr Blog Feed

RSS Feed Breakdown

Feed Format: RSS vs. Atom

As of mid-2005, the two most likely candidates are RSS 2.0 and Atom 1.0. Google reader supports either fully and they suggest choosing one or the other (not both) because most RSS readers support all major formats and offering both can confuse users. The Atom syndication format, whose creation was in part motivated by a desire to get a clean start free of the issues surrounding RSS, has been adopted as IETF Proposed Standard RFC 4287 and is used by Google. However, RSS 2.0 was the first to support enclosures and has captured the podcasting audience and is the recommended format in the iTunes podcasts specs.

I generally do as Google does when it comes to web optimization, and I am a big fan of standards. In some regards I would call Atom "the higher path". That said, I am also a big fan of simplicity and ease-of-use so I'm going with RSS 2.0 because:

• I already hand-built an RSS 2.0 feed for podcasting (well, for iTunes) so would rather learn one standard / keep all feeds similarly formatted.
• One less term that could potentially confuse end-users and "web lite" folk who might inherit my work later on.
• A lot of really big sites that have probably carefully considered this topic went with RSS 2.0, including NYTimes.com, AListApart.com, Ebay.com, news.BBC.co.uk, and CNN.com.

RSS XML Namespaces

Before

After

Even Better

The namespaces sy and content aren't used at all and can just be removed. Optional: I chose to remove xmlns:admin="http://webns.net/mvcb/" and the only tag that used it, <admin:generatorAgent rdf:resource="http://expressionengine.com/" /> - removing the admin namespace also eliminated rdf, which admin namespace depends on.

I'm not saying any of the removed namespaces are bad, just unnecessary. For example, admin is a very common namespace, but if you leave it in you should update the URI to include the EE version number (dynamically) and add the <admin:errorReportsTo rdf:resource="URI"/> pointing to a valid email address for errors. It may be beneficial to aggregators in reporting statistical reporting of web frameworks and content management systems delivering aggregated RSS feeds.

I rather admire the efficency and simplicity of the namespace declarations used by NYTimes.com, CNN.com and others - so again, this is personal choice.

The third option (even better) adds the atom namespace. The default EE RSS feed will not validate because it lacks the required atom:link tag containing the URI of the feed itself. There is some debate on whether this is actually necessary (some say the validator is wrong, not the lack of the atom tag)- read the article Adding Atom:Link to Your RSS Feed for background on this.

Depending on your site's content, your SEO practices and target audience, it is likely that you may need additional namespaces. A media-rich site, for example, would benefit from the media namespace. The media namespace is used to syndicate video, images and other media and can open up your feed to consumption by media-rich aggregators and services like Cooliris and Yahoo Video Search.

Channel Area

Most of the default template makes perfect sense - just make sure to take a look at your feed output to make sure all the EE fields used have valid values. Also, make sure you want to the {weblog_foo} tags - if you are providing a site feed that combines multiple sections you will probably want to hand-edit many of the tags in the channel area.

Dates

Important tip: make sure your feed is correctly reporting the timestamp of your entry date. If the seconds are changing on an item whenever you make an update this will cause many aggregators, including Google Reader, to repost the entry to your RSS feed. Either take the seconds off the time or replace '%s' with an arbitrary static value like '15'.

A search for 'RSS Updates' in the EE Forums will reveal that many people have had this problem. I tested all the date fields in my feeds (see this thread for details) and found that although the entry date day, hour and minute doesn't change on update (as expected), the seconds do! This weird behavior has something to do with how the dates are stored in the database and/or how the date is interpreted by EEs date tags. What it means is that if you go back and edit a post from three years ago, some aggregators will repost the item to your RSS feed even though you did not change the entry date. This can be especially troubling if you like to go back and tweak a post a lot right after publishing - you may go to your feed reader to see it reposted several times in a row.

pubDate vs. dc:date

<pubDate> is part of the RSS 2.0 spec. A lot of feeds out there still use <dc:date> and this either because they kept it from their RSS 1.0 template (for which dc:date was the only option) or they really like the very popular Dublin Core namespace or they prefer it because of the ISO 8601 date format which is much more prevalent than the (really old, as in ARPANET old!) RFC 822 date format that <pubDate> uses. On one hand it makes sense to stay with the spec and pull in namespace elements only as required. On the other hand, it makes sense to provide output in the most reusable way (updated date format). Feed readers parse either just fine, so this is judgment call on your part. Here's an agrument for each:

• bradchoate.com/weblog/2003/06/21/rss
• diveintomark.org/archives/2003/06/21/history_of_rss_date_formats

Based on my own survey of the feeds referenced above, I opted to switch to <pubDate>, replacing <dc:date /> in the channel with:

<pubDate>{gmt_date format="%D, %d %M %Y %H:%i:%s %T"}</pubDate>

<pubDate>{gmt_entry_date format=&qout;%D, %d %M %Y %H:%i %T"}</pubDate>

Item <title ... />

The default tag is fine, but if your content people keep putting special characters in their titles (like mine do) then you might want to add the protect_entities="yes" attribute to the {exp:xml_encode} tag. For example the main EE site I work on uses &#187; (») and &amp; (&) a lot in titles.

Even after protecting entities I was still having a heck of a time getting a trademark (™) symbol that is used on a site in many post titles and in a category to consistently display on both the webpage and in RSS feed aggregators - after some digging I realized the character entity that was being used (&#x2122;) for it was not the UTF-8 reference (&#8482;) specified as the encoding for both the RSS and XHTML. So, make sure you (or your content editors) use the correct character encoding entities for special characters!

Item <guid ... />

As formated in the official EE RSS template the <guid> is not a permalink, and therefore should have isPermaLink="false" attribute added to it. Of course you could use your actual permalink and then you could leave that off or change it to "true".

"We recommend the use of the Atom and RSS 2.0 elements to unambiguously identify items. An item that is updated should keep its original ID, and a new item should never reuse an older item's ID. Changing IDs unnecessarily may result in duplicate items, and reusing IDs may cause some items to be hidden. "Tag URIs" make good IDs, since they don't change even when you need to reorganize your links." - Google Reader Tips for Publishers > Implementing Feeds

The above recommendatio explains the multi-posting of an entry on update issue I referred to earlier. Because of this, you will probably want to remove the '%s' from the formatting attribute as well. So, change the gmt_entry_date format string in the <guid> line to "%H:%iZ".

Optionally, you could just use the actual URI of your article and change the isPermalink attribute to true. EE won't let you post two items with the same URL title within a weblog/channel, so you are pretty safe there (EE adds a number to the end of URL title if one already exists).

Item <description.../>

This line is technically fine, but most people will change this to allow HTML formatting of their entries: <description><![CDATA[{summary}{body}]]></description>. This is what displays the bulk of your entry item and where most of your site-specific customization will happen, Customizing ExpressionEngine RSS 2.0 Template on 'A Blog Not Limited' is a great resource for this.

Categories

Original Template

Code:

<dc:subject>{exp:xml_encode}{categories backspace="1"}{category_name}, {/categories}{/exp:xml_encode}</dc:subject>

Result:

<dc:subject>Architecture, Science, Workplace</dc:subject>

Separate using <dc:subject>

Code:

{categories}<dc:subject>{exp:xml_encode}{category_name}{/exp:xml_encode}</dc:subject>{/categories}

Result:

<dc:subject>Architecture</dc:subject>
<dc:subject>Science</dc:subject>
<dc:subject>Workplace</dc:subject>

Separate using <category>

Code:

{categories}<category>{exp:xml_encode}{category_name}{/exp:xml_encode}</category>{/categories}

Result:

<category>Architecture</category>
<category>Science</category>
<category>Workplace</category>

Updated EE RSS 2.0 Template

This includes what I consider minimal mandatory fixes to ensure error-free code and to prevent (re)posting problems.

{assign_variable:master_weblog_name="blog"}
{assign_variable:master_weblog_status="open"}
{exp:rss:feed weblog="{master_weblog_name}" status="{master_weblog_status}"}

<?xml version="1.0" encoding="{encoding}"?>
<rss version="2.0"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:admin="http://webns.net/mvcb/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <channel>
    <title>{exp:xml_encode}{weblog_name}{/exp:xml_encode}</title>
    <link>{weblog_url}</link>
    <description>{weblog_description}</description>
    <dc:language>{weblog_language}</dc:language>
    <dc:creator>{email}</dc:creator>
    <dc:rights>Copyright {gmt_date format="%Y"}</dc:rights>
    <dc:date>{gmt_date format="%Y-%m-%dT%H:%i:%s%Q"}</dc:date>
    <admin:generatorAgent rdf:resource="http://expressionengine.com/" />
{exp:weblog:entries weblog="{master_weblog_name}" limit="10" rdf="off" dynamic_start="on" disable="member_data|trackbacks" status="{master_weblog_status}"}
    <item>
      <title>{exp:xml_encode}{title}{/exp:xml_encode}</title>
      <link>{title_permalink=site/index}</link>
      <guid isPermaLink="false">{title_permalink=site/index}#When:{gmt_entry_date format="%H:%iZ"}</guid>
      <description>{exp:xml_encode}{summary}{body}{/exp:xml_encode}</description>
      <dc:subject>{exp:xml_encode}{categories backspace="1"}{category_name}, {/categories}{/exp:xml_encode}</dc:subject>
      <dc:date>{gmt_entry_date format="%Y-%m-%dT%H:%i%Q"}</dc:date>
    </item>
{/exp:weblog:entries}
    </channel>
</rss>
{/exp:rss:feed}

Improved EE RSS 2.0 Template

This includes optional changes that I added as a result of various articles, the RSS 2.0 spec and by examining the feeds of major professional news sites.

{assign_variable:master_weblog_name="BLOG"}
{assign_variable:master_weblog_status="OPEN"}
{assign_variable:master_rss_uri="http://PATH/TO/THIS/RSS/FEED"}

{exp:rss:feed weblog="{master_weblog_name}" status="{master_weblog_status}"}
<?xml version="1.0" encoding="{encoding}"?>
<rss version="2.0"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
    <title>{exp:xml_encode}{weblog_name}{/exp:xml_encode}</title>
    <link>{weblog_url}</link>
    <description>{weblog_description}</description>
    <dc:language>{weblog_language}</dc:language>
    <dc:creator>{email}</dc:creator>
    <dc:rights>Copyright {gmt_date format="%Y"}</dc:rights>
    <pubDate>{gmt_date format="%D, %d %M %Y %H:%i:%s %T"}</pubDate>
    <atom:link href="{master_rss_uri}" rel="self" type="application/rss+xml" />   
{exp:weblog:entries weblog="{master_weblog_name}" limit="10" rdf="off" dynamic_start="on" disable="member_data|trackbacks" status="{master_weblog_status}"}
    <item>
      <title>{exp:xml_encode protect_entities="yes"}{title}{/exp:xml_encode}</title>
      <link>{title_permalink=site/index}</link>
      <guid isPermaLink="false">{title_permalink="site/index"}#id:{entry_id}#date:{gmt_entry_date format="%H:%i"}</guid>
      <description><![CDATA[{summary}{body}]]></description>
      {categories}<category>{exp:xml_encode protect_entities="yes"}{category_name}{/exp:xml_encode}</category>
      {/categories}
      <pubDate>{gmt_entry_date format="%D, %d %M %Y %H:%i %T"}</pubDate>
    </item>
{/exp:weblog:entries}
    </channel>
</rss>
{/exp:rss:feed}						

Feedback

Please let me know if you have any suggestions for improvements on the basic template. I have already submitted these suggestions (as have others) on the EE Forums and I hope this article will soon be out-dated. For further information on customizing your RSS feed including adding Google Analytics tracking and additional fields such as author name, see Customizing ExpressionEngine RSS 2.0 Template at 'A Blog Not Limited' (if you use their updated template don't forget to remove the seconds from date fields in the item section).

Any spambot worth its salt spawned by evil genius could "guess" email addresses by skimming for all 'alias@'s and automatically concatenate them with the site's url base and any other domains found on the page, so in the javascript I separate the '@' from the alias.

Enough about the wheres and whys, here's some cut n' paste fun for your use. This code will use javascript to display a normal, clickable mailto: link on your page and if javascript is turned off you still get a screen-readable, selectable email address displayed using a CSS trick.

<style type="text/css">
.backwards {
unicode-bidi:bidi-override; direction: rtl;font-weight:bold;
}
</style>
<script type="text/javascript">
<!--
linkAddy=('alias' + '@' + 'yourdomain.com')
document.write('<a href="mailto:' + linkAddy + '">' + linkAddy + '</a>')
//-->
</script>

<noscript>
<p>Please email me at
<strong><span class="backwards">moc.niamodruoy@saila</span>
</strong>.<br /></p>
</noscript>

Here's a version for you really paranoid folks that don't want live links at all (or maybe you just want a tiny user obstacle to ensure necessity of correspondence), but you do want your email address to appear correctly if possible but with better protection, plus insurance if javascript is turned off:

<style type="text/css">
.backwards {
unicode-bidi:bidi-override; direction: rtl;font-weight:bold;
}
</style>
Please email me at
<span class="backwards"><script type="text/javascript">
<!--
backAddy=('moc.niamodruoy' + '@' + 'saila')
document.write(backAddy)
//-->
</script></span>
<noscript><strong>alias at
yourdomain dot com</strong></noscript>

Here's a working example:

Please email me at

Here's a few other ways to protect email addresses from spam bots. If you have a preferred method not listed here, please let me know in the comments.

• Graceful Email Obfuscation article from A List Apart takes it up a notch, with an htaccess rewrite and redirect. Could be worth setting up for a large site where you need to add email links quickly and easy.
• Hivelogic Enkoder Form - use their form to generate some javascript. Works great but relies on javascript to work.
• Addressmunger.com - uses ASCII, JavaScript, and scrambling of letters in your email address.
• K'nechtology Email Encryption - encodes email addresses in to hexadecimal values. This isn't very secure as it would be extremely easy for a bot to decode hex.

Using Drupal, 1st Edition by O'Reilly

So far the book is great, but the instructions on setting up a dev environment aren’t exactly crystal clear for those completely new to Drupal. I thought I’d help out the next geek that bothers to GTS to find pitfalls before starting.

First review the preface section 2.7 ‘Downloading Drupal’. If you’ve never installed Drupal before, or any web application on a web server before, it’s a good idea to check out Lullabot Addison Berry’s very easy to follow video, Installing Drupal 6.

These instructions are specific to the context of a shared hosting account on Dreamhost, but may work for your environment as well. Be sure to review the book’s errata – the ‘confirmed errata’ will let you know about any code mistakes or problems with source discovered since the book was published. For troubleshooting help related to the books exercises and installation issues, review the Using Drupal book forum.

THESE INSTRUCTIONS MAY CAUSE YOUR DATAZ TO BE LOST. In addition to setting up things quickly, these steps include how to quickly delete all the stuff in your database, without bothersome ‘back up your data first’ steps. The idea is you are just creating a sandbox and nuking your install is no big deal.

Enough blab, let’s do this:

• Create a subdomain for your dev environment like drupal.yourdomain.com
  • Dreamhost panel > Domains > Mandage Domains > Add New Domain / Sub-Domain
• Create a new database (on a new or existing subdomain)
  • Goodies > Manage MySQL, scroll to the bottom where it says ‘Create a new MySQL database:’
  • Enter something in all the fields:database name must be unique system wide so get creative, create a new hostname like mysql.drupal.yourdomain.com, you can use your own username but I created a special username and password that I’ll also be using for the admin user in the Drupal install (note: dev enviro, not recc’d for production), you might want to put something to remind you what this is later in the comment field like “Sandbox for Using Drupal Book”.
  • Write down all that DB stuff so you can use it later.
  • Wait a while for new database host name and/or new subdomain to propagate.
• Download the latest source from the book site.
  • Extract the zip somewhere you can find it, like your desktop.
• Change the database connection string in using_drupal_source\drupal\sites\default\default.settings.php
  • Open default.settings.php with your favorite text editor
  • change connection string stored in $db_url (line 92 at TOW) from mysql://username:password@localhost/databasename to something like mysql://name:psswd@mysql.drupal.yourdomain.com/dbname
• Copy default.settings.php in the same folder and call it settings.php
  • There should now be 2 files in the default folder
• Save a backup copy of your default folder somewhere
  • I just copied the default folder and renamed it ‘_default’, or save somewhere on your hard drive, thumb drive, whatever…the point is, settings.php and default.settings.php that will soon live on your web server are going to change and you’re going to want these files again someday.
• Upload the contents of using_drupal_source\drupal to the root of your new subdomain
• chmod /sites/default to 777
  • On you web server (via your FTP client) navigate to /drupal/sites/default
  • If you’re using FileZilla, right click (ctrl+click for macs) the default folder and select file permissions, this will allow you to enter the numeric value 777 or just check read/write/execute for all roles
• Open http://drupal.yourdomain.com

Installation profile options on successful install

You’ll be prompted to select an ‘Installation Profile’. The book source code includes scripts to automatically install a site with assets and modules used in their examples for you. If you are just starting Chapter 2. where they send you off to the Appendix for installation instruction, chose the last option – the generic/basic Drupal install.

Here’s how to “start over” so you can use a different installation profile. These steps will cause you to lose any data you entered in Drupal – you will end up with a brand new install and a chance to chose a diferent installation profile:

• Nuke all your database tables
  • Note I said ‘tables’, not the database.
  • Go to http://mysql.drupal.yourdomain.com (phpMyAdmin screen) and login
  • Select you Drupal database from the databases list at left (e.g. NOT information_schema)
  • Scroll to the bottom of tables listing page and select ‘Check All’, change the ‘With selected:’ drop down to ‘Drop’.
  • You will see a screen asking if you really want to execute this command. Click ‘Yes’.
• CHMOD /sites/default to 777 again
  • On your web server, go to /sites/default
  • CHMOD default to 777 (again, because the previous install process modified the permissions) and be sure to check ‘recursive’ (or use -R on commandline) because there’s new files in there and we need to blow everything in the default folder away.
• Delete everything in /sites/default
• Put a clean copy of default.settings.php and settings.php in /sites/default
  • Remember that saved copy of default.settings.php and settings.php?
• Go to http://drupal.yourdomain.com/install.php and start all over again :)

Bold moves in phpMyAdmin. Select all > drop.

I hope that was helpful for someone. I remember all to well not even knowing what chmod was and trying to write perl scripts, ouch! As you might guess, with as much time as I spend documenting when I should be doing book exercises I don’t really have time to offer support, but please let me know if anything I’ve written here needs to be corrected or elaborated on. Have fun in Drupal land!

Nothing amazing going on, just a few tips that might save you some time:

• You need java runtime installed and working, prolly apt-cache search to make
  sure you’re putting in the most recent version (6 as of this writing)
  • sudo apt-get update
  • sudo apt-get install sun-java6-jre sun-java6-plugin sun-java6-font
• The netbeans in the repo is for the Java IDE, so don’t bother with apt-get
• Download the install file here: http://www.netbeans.org/downloads/index.html
  • Be sure to pick the PHP bundle
• If clicking on the netbeans-x.x-ml-php-linux.sh file gives you an error or tries to open in gedit or something, right-click > properties > permissions and check ‘allow executing file as a program’
• Select Run (not ‘Run in Terminal’), running in terminal will throw some GTK errors

Next you might want to head over to the Netbeans website and watch the intro vid and orient yourself to the plethora of PHP-centric features.

As fair newb to programming in PHP I can’t say I’m qualified to suggest an IDE. So why Netbeans? It’s free. It porvides syntactic and semantic code highlighting for PHP and debugging through Xdebug. Folks in my Seattle PHP meetup group who know a lot more about programming than I do seem to really like it, every time I go to install Eclipse I am daunted by the website, instructions and innumerable options. Finally, it was recommended in the recent Smashing Magazine article The Big PHP IDE Test: Why Use One And Which To Choose (2009.02.11) so I stopped resisting.

Do you like it, recommend others over it?

The Good

My own private wiki, largely comprised of web development documentation for my own projects, code snippits and links to online resources, is invaluable to me – so the potential benefits of an open wiki of this nature is obvious and I’ve often wondered why there isn’t one (with critical mass) out there already. Certainly this project, or at least the idea of it, could be an invaluable tool to professional web designers and client-side developers. Some take-aways:

• “Written by web developers, for web developers” and by that they mean client-side developers…most of the current content is specific to JavaScript DOM stuff and cross-browser CSS considerations. I think this fills a knowledge gap as a lot of CSS and even Ajax resources are designer-oriented (lacking meaty technical details) and many developer resources gloss over or ignore web standards or a lot of the details professional programmers take for granted (like finding a viewport or using javascript to manipulate classes)
• It’s built on the Google Project framework so you can download the whole thing via SVN.
• The licensing is pretty unrestrictive, so you could SVN everything and put it up on an intranet statically or keep an off line copy, as was mentioned in the intro video.
• Discrete code snippets. Rather than a long tutorial with examples that are specific to a given situation, many of the HOWTOs are broken down into more abstracted uses. This style of documentation will help a lot when your stuck on specific area of a bigger project. Personally, I learn more this way – I like the big step-by-step tutorials but when I cut and paste a lot I don’t retain very much.

The Ugly

Google suffers from chronic ugliness (IMHO) and this project is no exception. Don’t get me wrong, I’m GOOG fangirl all the way, but there always seems to be some basic user interface and user experience problems with their apps/portals/projects/whatever. And here’s where I think Google Doctype has need of improvement:

• No indication of off-site links. Not only does a link to MSDN look just like the internal links, there are links to other Google Code project without any indications that you’re leaving Google Doctype, in fact, the logo is still Google Code. Navigation is a little confusing in general.
• Lack of Style Guidelines. There is something to “just putting it out there” and I’m glad they did, but if a lot of people do start adding to this resource it could turn into quite a mess. It would have been ideal to have a written style established that would make sense for an open wiki. For example, statements like “generally, we recommend the following…” and “I’m not sure if this works on IE”. This type of thing would never fly on Wikipedia – now that the docs are open to the whole internets, such statements are ambiguous, lack authority and create a bad example that others are sure to follow.
• Not really a wiki. First there’s the linear tree/node navigation pane (which seems to collapse by itself and disappear or reappear for no apparent reason) . There is no discussion page (although there are comments, sort of like PHP.net), no page history (but you can manually add a free-form line to a log file, if you notice the option), there’s no obvious way to check to see what links to a page, the list goes on.
• Screaming “Fork Me”. A fork may be inevitable, and if a fork emerges using MediaWiki or any of a myriad of much more robust wiki platforms, I would be more likely to invest my time in that in spite of the Google mind share.

A Web Reference To Rule Them All

When I first read that Google published a web design wiki I was thrilled. I tried to think of other, similar resources. There are some great blogs, lists and forums out there but I’ve yet to find the one web reference to rule them all. If you know of one, please let me know! In the meantime I’m looking for domains…webwiki.com is just a db error, webwiki.net is a half-baked attempt at a wiki version of the Million Dollar Homepage. Hrm. If I come up with a load of extra time and a brilliant idea I will let you know. In the mean time, here are a few of my favorite web coder sites:

• W3C.org – start at the top, right?
• HTML Dog – very well organized reference and tutorials for CSS and (x)HTML
• A List Apart – high quality articles published by those web standards freaks at Happy Cog.

Oh the contact page. So boring, so obligatory. And not as simple as it may seem. I was hoping to jazz up the contact page at BuildCarbonNeutral.org with some sort of slick Ajax contact form. You see, I built the site in a really big hurry could spare not time for extras like protecting raw email addresses. By the way, email address protection is not an extra, usually! It’s something I meant to rectify as soon as possible and sure enough, our general contact alias is already receiving spam. I thought I might take the email address off completely and post a contact form instead.

The Problem with Contact Forms

Even the best form is an obstacle. Users don’t like filling out forms and what’s more, you introduce an opportunity for error. Everyone commits a typo now and again, and what if someone sends you information you’d really like to follow up on but lo and behold, their email address bounces. Even if you add the extra email confirmation input (make the user enter it twice), there’s still the case of people using an incorrect email address just to harass you. But really it all comes down to user experience. Don’t make your user fill out a form if they don’t have to.

The Simple and Sincere Mailto Link

So it’s back to the good ‘ol mailto link for me. The added benefit is people can save the email address in their contact list of choice and can format the email and send attachments if they choose. An email link is more personal, less corporate. Of course you all know that any email address present in the code of a public website is crawlable by spambots. Therefore be sure to put measures in place to protect all email addresses!

There’s Always an Exception

Sometimes you really should use a form. A common use for them is on high-traffic sites where they actually want to make it a little harder for users to get in contact. This approach is especially prevalent on sites that offer a product or service that results in a lot of support email and they want to encourage users to troubleshoot their own problem using existing documentation (FAQs, support forums, etc) before contacting the company/authors directly. Some sites don’t provide contact info at all for this reason. Chances are though, if your site is for a small business or is personal, you want to make it easier for people to contact you.