Consider this simple example:
<link rel="stylesheet" href="http://example.com/wp-content/themes/default/style-ie.css" type="text/css" media="screen" />

If as part of a migration or server change, WordPress ends up in a sub-directory this will break.

For file system based access, if I see ABSPATH . '/wp-content/ … things are likely OK, though if WP_CONTENT_DIR or similar are changed, this will also break.

I’m tempted to use the constant STYLESHEETPATH or is it TEMPLATEPATH? But, those are static variables initialized early in the WordPress run.

I’ve been meaning to write this article for a while. Serendipitously, when I went to write a first draft of it, Mark Jaquith‘s had just published “Force CSS changes to “go live” immediately“.

In the comments, demetris suggests using STYLESHEETPATH, but Will Norris quickly points out “sure, but you still have the same problem of bypassing any plugins that may be using the ’stylesheet_directory’ hook to pull the stylesheet from some place else entirely.”

Mark’s solution beautiful illustrates how to get the the URL location of the theme’s files and also directly the URL for the main stylesheet style.css:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); echo '?' . filemtime( get_stylesheet_directory() . '/style.css'); ?>" type="text/css" media="screen, projection" />

What Will describes is exactly what WordPress.com depends on. We have a similar, but much more complex solution to deal with the CSS in the content delivery network (CDN) going stale on updates, and also some web browser’s with their funky caches not keeping up. Our solution is both for WordPress’s front end and dashboard (also dealing with the various ways CSS can be called or @imported).

I do have one niggle about Mark’s solution, and it’s the same with most WordPress code out there, the use of bloginfo(). Strings within strings within strings within strings give me headache, so to ease readability and make it more verbose replace:

bloginfo('stylesheet_url'); with
echo get_stylesheet_uri();

bloginfo('stylesheet_directory'); with
echo get_stylesheet_directory_uri();

If you look up in the codex get_stylesheet_directory() you’ll see that would be the file system path, which is confusing given the behavior of bloginfo('stylesheet_directory'); returning the URL. This presents another reason why I favor the consistency of always using the specific getter function calls. Also, when I’m using bloginfo() calls, I have a tendency to get in a mind set where I think I’m directly retrieving the option in the database (accessing directly the info shown in wp-admin/options.php). By using the specific getter function, I remember that there are hooks (actions, filters) that might be triggered.

Some of the other areas, I see wp-content is in CSS style sheets themselves. Relative paths are almost always the correct solution.

Far more painful for me are the plugins that assume where plugins are, because this can take quite a bit of debugging to unwind the assumptions.

That is a topic for me to postulate on another day. Will has written the very relevant “WordPress Plugin Pet Peeve #2: Direct Calls to Plugin Files“. Duane Storey has taken a crack at a “WordPress Plugin Checker“  for these and other common problems (which I’m certain he would enjoy feedback on).

A fast, distributed, horizontally scalable system built upon linux, php5.2, and mysql 5.1 wherein work can be stored in a database, and processed outside the flow of script execution. Examples of common things that are part of script execution but not necessary to the rendering of the response to the user might be spam scanning, statistical analysis, email notification sending, processing input data, etc. Also included is an equally distributed cron mechanism to remove single servers as a point of failure for scheduled jobs.

There are a lot of terms I like in there like fast, distributed, horizontally scalable, scheduled. It could probably benefit from robust and fault tolerant. Any others?

Anyway, this crontab-like system for PHP scripts is an essential part of our WordPress.com infrastructure, and I’m really excited to see it open sourced!

Check out code.trac.wordpress.org for other pieces of our puzzle that don’t have pretty project pages.

Dr. Andrei Dmitrievich Sakharov Sculpture photo by Flickr user dbking. Andrei Dmitrievich Sakharov (May 21, 1921 – December 14, 1989) was an eminent Soviet nuclear physicist, dissident and human rights activist. Sakharov was an advocate of civil liberties and reforms in the Soviet Union. He was awarded the Nobel Peace Prize in 1975. (wikipedia)

There is a small project that I’m working on with a friend, and since for years I’ve wanted to try Python…

I find two of the greatest assistants in learning and developing expertise in something are:

• Helping someone else (teaching).
• Using something else (compare).

Experimenting with something else helps me take the emotions and religion out of what I’m developing expertise in. It lends to a pragmatic foundation and helps be able to speak to another audience.

So while I work on this Python project, I won’t feel like I’m cheating on PHP and WordPress. Instead I’m continuing my learning about both and will be a better representative of both.

I read on the WordPress Support forums “Error establishing a database connection on OS X 10.5” where jonokane had the novel solution of changing the database host (DB_HOST) to capital L, ‘Localhost’.

mrogers writes that “This is definitely a bug in WordPress 2.5, because every other web app I have running on this machine uses “localhost” and it connects to the MySQL server just fine.”

The problem can be isolated to the PHP function mysql_connect() and its error return value is being suppressed:

Warning: mysql_connect() [function.mysql-connect]: Can't connect to local MySQL server through socket '/var/mysql/mysql.sock'

There is quite a bit of misinformation about what the problem and solution out there. The Apple doc “Mac OS X Server 10.4.4: Improvements to Apache/PHP/MySQL interaction” from January 2006 gives clues as to the problem. On Server, a custom MySQL is included and the doc includes:

If you have downloaded and installed MySQL yourself but are using the pre-installed version of PHP, note that your custom version of MySQL might be configured to use the old MySQL socket location, /tmp/mysql.sock. The version of PHP in this software update uses the newer location /var/mysql/mysql.sock by default.

The problem with Apple using the “newer location” is that MySQL hasn’t had a major release since 2005 and so their packages don’t use the newer location, and there is no custom MySQL package for the rest of us. We have to download the regular MySQL 5 package from MySQL.com.

Jonokane’s novel solution likely works because instead of using a socket for the local connection, it attempts a TCP/IP connection, and ‘Localhost’ resolves to ‘localhost’. That will only solve the problem for WordPress though, and you would have the same problem with other PHP applications.

The correct solution is to:

$sudo cp /etc/php.ini.default /etc/php.ini
$sudo chmod +w /etc/php.ini

And in your favorite editor find the line that starts mysql.default_socket and update it to read

mysql.default_socket = /tmp/mysql.sock

Now restart Apache, and it should be golden.

You won’t encounter this problem if you are using the packages from Mac Ports or MAMP, but those would be their own adventures.

Congratulations to the Drupal community!

The first lessons if you want to reach your goals in a small company is that you have to be willing to do every job, and will probably have to do many of them. You have to be flexible, there is no organizational hierarchy to assign the work to.

So although not in my job description doesn’t include PHP programming, it will help me be a better participant in the company and in the products I care most about.

Discovering and isolating problems comes fairly naturally to me, as does duplicating other’s results, but turning a coding problem into a solution no longer does — I’m long out of practice, and that practice never included PHP.

Sure, I can fix a typo or add a token or two of code, but I’m long out of practice in creating real solutions. Getting there would give me a much better understanding of the WordPress code, and ultimately the experience.

I have my PHP book, PHP and MySQL Web Development by Luke Willing and Laura Thomson (purple spine, aquaducts on cover), have plenty of small projects on my mind, and will find the time, but first I feel like I want to find myself a crutch of a good PHP development environment.