Tips and Tutorials Archives

Webstandards, SEO, and CSS in 3 minutes 22 seconds.

If you are getting this error on your local WordPress installation using Mac OS X Leopard, there is a simple fix. You might be seeing this error even though PHP is working fine, and MySQL is working fine. In order to get WordPress to work create a php.ini file.

sudo cp /private/etc/php.ini.default /private/etc/php.ini

Change permissions and edit the file

sudo chmod 777 /private/etc/php.ini
vi php.ini

Change mysql.default_socket = [blank] to

mysql.default_socket = /private/tmp/mysql.sock

Restart Apache and you should be good to go!

My previous posting regarding local web development on Mac OS X was geared towards those running OS X Tiger and Apache 1.3. The new Mac OS X Leopard comes with the 2.2 version of Apache, and with it some tweaks to the way things are set up.

PHP comes pre-installed, giving Marc Liyanage a lot more free time and making your life much nicer. First thing to do is to activate PHP5 by opening up the httpd.conf file.

sudo vi /etc/apache2/httpd.conf

To include PHP5, simply uncomment the following line:

# LoadModule php5_module libexec/apache2/libphp5.so

In order to develop multiple sites locally, use virtual hosts. I had trouble using the default httpd-vhosts.conf file, so I added my own sites.conf file. Add this line to the bottom of your httpd.conf file:

Include /etc/apache2/other/sites.conf

Next, create the actual conf file you just referred to.

vi /etc/apache2/other/sites.conf

Create a new virtual host for MySite by adding a record to the sites.conf file

# Enable named virtual hosts
NameVirtualHost *:80
# Override the default httpd.conf directives.  Make sure to
# use 'Allow from all' to prevent 403 Forbidden message.

	Options ExecCGI FollowSymLinks
	AllowOverride all
	Allow from all

# A basic virtual host config

	ServerName yoursite
	DocumentRoot /Users/username/Sites/yoursite

Edit the hosts file…

sudo vi /etc/hosts

… and add a line with your new site

127.0.0.1       yoursite

You should create a folder called “yoursite” in the default Sites folder. At this point you will need to restart Apache to pick up the changes.

sudo apachectl restart

You should now be able to view your site locally at http://yoursite/. In order to maintain multiple virtual hosts, simply add another record to your sites.conf file.

	ServerName yoursite2
	DocumentRoot /Users/username/Sites/yoursite2

and add the corresponding record to the /etc/hosts file.

127.0.0.1       yoursite2

The DataMapper ORM framework is forging ahead and is now on version 0.2.3. In my previous DataMapper post I wrote about how to get started using the 0.1 release of DataMapper in Rails. Today, let’s look at some of what’s new installation-wise, as well as how well DataMapper is handling relationships between our model objects.

First of all, the DataMapper crew has changed to using DataObjects.rb for its database driver stuff. If you’re running OSX Leopard and MySQL as we are here at Bust Out, then you’ll want to visit this excellent post to help you get up and running.

Two addendums to the above. The first is that I needed to install the json_pure gem as well in order to get DataMapper running correctly:

    sudo gem install json_pure
 

Secondly, if you happen to encounter something like this little gem when firing up your Rails console:

dyld: NSLinkModule() error
dyld: Library not loaded: /usr/local/mysql/lib/mysql/libmysqlclient.
15.dylib
Referenced from: /usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/lib/
mysql.bundle
Reason: image not found
Trace/BPT trap

you can fix it using the following suggestion from the DataMapper mailing list.

Now that we hopefully have our new version of DataMapper correctly installed, lets take a look at it in action. Last time around, I made myself a drink to celebrate the successful install of DataMapper. This time, let’s continue building our restaurant by including a bar and then invite some people over to discuss the relative merits of ORM design patterns (or not):

>> r = Restaurant.new
=> #
>> r.name = “Hawaiian BBQ”
=> “Hawaiian BBQ”
>> r.save
=> true
>> b = Bar.new
=> #
>> b.name = ‘Hula Lounge’
=> “Hula Lounge”
>> b.restaurant = r
=> #
>> b.save
=> true
>> b.restaurant
=> #
>> p = Patron.new
=> #
>> p.first_name = “jeff”
=> “jeff”
>> p.last_name = “lin”
=> “lin”
>> p.save
=> true
>> r.patrons << p
=> [#]
>> r.save
=> nil
>> r.patrons
=> [#]
>> p = Patron.find 1
=> #
>> p.restaurant
=> #
>> d = Drink.new
=> #
>> d.name = “Trumer Pils”
=> “Trumer Pils”
>> b.drinks << d
=> [#]
>> b.save

Hopefully at this point you get the idea that associations are working quite nicely in DataMapper (assuming any of the above is remotely helpful…wasn’t the most fun to type). So, rather than show you the model classes and keep typing along in the console, I suggest that DataMapper users read the specs that are bundled with the source. They’re quite informative and a good example of how to write specs as well.
Be sure to check out the DataMapper site as well and look for ways to contribute.
Cheers!

One of the most common features of an Ajax-enabled application is a “loading” animated image. You know, like a spinny thing that tells the user that “something is happening so wait for a server response.” Creating animated GIFs is not hard, especially when using web imaging software like Adobe Fireworks. But it is time consuming and generally annoying. Enter ajaxload.info. Check it out. It’ll save you time and make you a happy web designer.

If the title of this blog posting makes you cringe (as should anything with the words IE 5.5+, at least when it comes to web design), then check the TwinHelix solution. It exploits the non-standard implementation of CSS “behaviors” developed by Microsoft for the Internet Explorer browser. The fix is a simple, non-JavaScript solution for a nasty, annoying problem.

Note: See an updated posting for local web development on OS X Leopard →

By default, Mac OS X ships with an installation of the Apache web server. If you’re a web designer or developer, this is a great tool to help you develop websites locally, increasing development speed and improving your quality of life. To get up and running, follow these easy steps:

1. Open your System Preferences… Sharing
2. Turn on Personal Web Sharing
3. The URL at the bottom of the screen maps to your /User/username/Sites directory, which is where you should place your local website files. You can also access your local web server by hitting http://localhost/~username/ (replacing ‘username’ with your actual username.)

You can place multiple website projects in your Sites folder by simply creating one folder per project, and accessing each project by corresponding URLs such as http://localhost/~username/MyProject/ and http://localhost/~username/MyOtherProject/. If you like to use absolute paths in your HTML code, you will have to use the following convention:

This is obviously not very convenient, especially if you’re sharing your code through a repository with other developers who do not share the same username. Additionally, once you complete local development you need to strip out the /~username/MyProject/ before deploying your code to a public web server. To get around this hurdle, you can customize your Apache server to use custom URLs by following these steps:

1. Edit the httpd.conf file. I do this using vi in Terminal, by executing the command:

   
   sudo vi /etc/httpd/httpd.conf
   

2. Uncomment the NameVirtualHost line and edit the line so it reads

   
   NameVirtualHost 127.0.0.1
   

3. Add the following lines to the file:

   
   
      ServerName MyProject
      DocumentRoot /Users/username/Sites/MyProject
   
   

4. Edit the hosts file by issuing the command:

   
   sudo vi /etc/hosts
   

5. At the end of the file, insert the the line:

   
   127.0.0.1 MyProject
   

6. Go back to System Preferences… Sharing, stop Web Sharing, then start it again. This action bounces the Apache web server.

You should now be able to access your project at http://MyProject/, which also allows you to use “real” absolute paths in your markup.

I recently ported an existing Rails site to the Radiant CMS as our client wanted changes more frequently that initially anticipated. The good news is that the port went well. Radiant is a nice system. But I did struggle just a wee-bit. So, as I typically don’t do front-end stuff at Bust Out, I figured I would take the opportunity to post a few things about what I went through from the perspective of a Rails developer accustomed to controlling my own destiny vis-a-vis MVC/Erb, rather than letting a CMS do it for me.

I’ll start with the layout. Our Erb layout looked like the following:

            <%= yield :layout %>
        



            <%= render :partial => “/layouts/#{@sidebar}” %>