I thought I’d post a picture of the usage of my hard drive. The Fedora (Linux) Operating System provides a cool picture of how much space each folder takes up.

Fedora Disk Space Usage
I thought I’d post a picture of the usage of my hard drive. The Fedora (Linux) Operating System provides a cool picture of how much space each folder takes up.

Fedora Disk Space Usage
WordPress hooks solve a fundamental problem with dynamic function calls in PHP: How do you insert 3rd party functions with a static function call? But also, how do you use one single call to include an unknown number of functions?
Looking into this more, PHP has two segments of code that deal with functions: the definition and the call. Here is an example of the two in the respective order:
<?php
function my_new_code($name) {
echo "Hello " . $name;
}
my_new_code('World');
?>
In that example, I, as a single author, defined the name in the definition and the call. That example was also a case of one definition and one call.
In order to include multiple functions with a single function call, which doesn’t know the names of the functions, we need to use an indirect method and this is where the “WordPress Hook” method comes into play. For this case were going to use a predefined call and definition to do the work for us. First were going to call the fetching function.
<?php
do_action('the_location', 'World');
?>
This function call, named do_action, is going to load a function in the same manner as the first example and send it the value “the_location”. The function definition, named do_action, will then call all the 3rd party functions that are in the group “the_location” and insert them into this location in the code.
The do_action function finds out about the functions it should include by a sibling function named add_action, which creates a list of all functions. You can thing of add_action as the boss and do_action as the worker. This function, like its sibling, is a predefined function in WordPress, so you only need to call it. This function call is often included next to the function definition its mentioning. The following is an example of defining my_new_code and asks WordPress to hook it on:
<?php
function my_new_code($name) {
echo “Hello ” . $name;
}
add_action(’the_location’, ‘my_new_code’);
?>
To rap it up, you define a function, add it to the list with a given location, then when the location gets called, your function is included. Here is another nice point about WordPess Hooks, the do_action could be written by someone else, such as a theme developer or WordPress its self (Have you heard of wp_head & wp_footer anyone?). The following is the code put all together so you can clearly see what is required:
<?php
function my_new_code($name) {
echo "Hello " . $name;
}
add_action('the_location', 'my_new_code');
do_action('the_location', 'World');
?>
Both examples out put the same thing: “Hello World”, but here is an example of how the second one could be expanded:
<?php
function my_hello_code($name) { echo "Hello " . $name; }
add_action('the_location', 'my_hello_code');
function my_what_is_up_code($name) { echo " What's up " . $name; }
add_action('the_location', 'my_what_is_up_code');
function my_bye_code($name) { echo " Bye " . $name; }
add_action('the_location', 'my_bye_code');
do_action('the_location', 'World');
?>
This will output: “Hello World What’s up World Bye World”.
The difference between actions and filters, is that actions do not return anything, while filters will often return a variable that was passed to them, e.g. return $value;. Filter are also less likely to have print and echo within the functions they include.
Did you know that add_action calls add_filter? Which means they use the same code and create a single list of functions to include. Check it out for your self in Trac.
Related post by other authors: An Introduction to WordPress Action Hooks, Using Action Hooks in WordPress Child-Themes, Using Filter Hooks in WordPess Child-Themes.
I take most things with a grain of salt. One thing in particular keeps popping up and because of my web experience I just have to question and test what I’m being told. The tip in question is converting particular PHP tags into static HTML to speed up your site. It was #2 on Pro Blog Design’s post 10 Ways to Speed up Your WordPress Blog, but also an entire post in 13 Tags To Delete From Your Theme, on the same site. At first it seams like a valid tip… less PHP means faster processing and that leads to a faster load time, but I’m a theme developer and I love my code.
To test out this tip, I setup a quick test to see how long each method took. Being a developer, I actually new quite a few ways PHP could be mixed in with HTML, so I setup the four most common methods. They are: only static HTML, echo-ing static HTML, PHP only where needed, and echo-ing everything (static and PHP parts). The results were how it first seamed, static HTML is faster… 200 times faster to be honest. So… I thought it would be faster, it turn out to be faster, and yet I still questioned the tip.
Here’s why I questioned it. A page loading time is made up of a few factors, one of them is the server processing the PHP, but the code is going to be processed at a rate of billions of commands per second. Although one PHP command never equals one command in the CPU, that’s besides the point. Removing these suggested lines of code is not going to change the speed up your website at all, because it’s only a couple of commands.
The truth is, while it may be 200 times faster to use static HTML instead of PHP, the total time of the slowest one is 1/10,000th of one second. If you are worried about that amount of time, I’d like to point out that the human reaction time is 1/10th of one second. But I will not stop there, here is the biggest factor that kills this tip… caching. If you have any caching turned on, such as in Apache or a WordPress Plugin, then it doesn’t matter if your page is a HTML document or generated through PHP, because a static copy is going to be saved in memory and the actual line of code you changed is never going to be processed. Using caching is one of a dozen ways to really speed up your site and doesn’t require hunting through a WordPress Theme.
Nothing against Pro Blog Design, just against that one bad tip that I’ve seen around the web. Sometimes it’s a matter of calling out tips and seeing if they hold up to what they clame.
I’ve written CSS for almost a decade and it has lead me to develop a natural instinct to write code the right that just works for every browser. This has two part however, the first is that I don’t often go out creating the most uniquely code sites and the second is I’ve found the best way out of the multiple ways to do the same thing. This has lead to browser blindness when I code, i.e. I just use Firefox and hope I don’t have to fix anything when I browser test. In terms of IE6, I don’t do testing for this browser. If people use it, then so be it, because it’s there choice and they must be willing to live with the side effects. Anyway, here’s my “funny” on Browsers and Internet Explorer Six.

Now I know I’m going to get some feedback on the technical aspects of the chart… The data is from W3Schools and is of their April 2009 visitors. In other words, it’s skewed by the fact that the visitors are mainly made up of web developers, rather than the average internet user.
To make customizing WordPress themes easier, theme developers have started to include hooks in their themes. They are often referred to as WordPress Hooks, because they use WordPress function to manage them and do the heavy work, but they aren’t bounded by any naming convention or locations in the WordPress Software or any of its attachments (Themes and Plugins). There name comes from the fact that you are “hooking” code into the original software without modifying the files.
These hooks that are being added in by theme developers should be standardized. Everyone using them has a similar naming convention and it would make it easier and more universal for the people that actually attach snippets of code to these hooks.
It’s going to take some work though. Theme developers need to agree on the names and locations. Then it needs to be made known to people making themes and popularized with the poeople that are going to use it. I think this will help bring theme options out of the theme and into plugins, which should be good.
Earlier this year it was predicted that theme frameworks were going to be the big thing on the block and with that came child-themes. As with anything, there are different view points as to what a WordPress themes should be, what frameworks should do, and how to modify themes. This has lead to some interesting ideas as to where themes in the WordPress community will go and made me consider that the current direction may be better than the old, but not without its problems.
WordPress themes use to be a collection of files that were created by a theme developers, then modified by others without the consideration of upgrades. Some people are still left in this mind set that modify core theme files is okay, only to find upgrades to be a pain. However, innovations have been made and problems changed, not solved.
This new way came as pair of ideas. The first being child-themes, which build off of and modify other themes without changing any of that themes code. The second is of course theme frameworks. These were two separate ideas, because they help two different groups of people, although, they did in part with the same tool, child-themes. The first idea was a way for anyone to modify their theme in a clean way. They second ideas was a way to speed up the development time of themes by providing a base. I my view, only one of these ideas was a good one. The other one was over kill and could lead to problems down the road.
The good idea was theme frameworks. While a basic theme can be build in minutes, a complete theme that is efficient and effective takes years to prefect. A lot of people forget about the non-essential pieces of a theme, such as internal SEO, microformats, and coding standards. The one overly inflated piece of a theme that no one forgets is design. Developers and designs should make design the only priority. Besides that fact that frameworks lead to better themes, they also speed up development time.
Now for the bad idea… modifying the design of a site with a child-theme. First off, you’re technically selecting another theme. It’s not a local modification, but effects the entire parent theme. It also groups all your modifications into one package, which does have some advantages, but also disadvantages. Most people make all their changes in one file, so once they want to remove one customization or change some values , it becomes tricky. It’s not hard put most modification in a theme, but then what happens to page templates. Well… they don’t need to be in a theme folder. PHP developers can either make page templates virtual or they can call them from other locations.
It’s not nice to shoot down ideas without suggesting better ones, so here’s mine. I think by that creating a plugin or having themes that allows the ability to customize a theme is the best bet for personal customizations to a site. This would allow for the manage of page templates outside of theme, whether through a database or some other folder location. Individual modifications would have their own file or could be kept in a Database, allowing for an easy way to remove or modify code.
Luckily WordPress is Open Source and the best solution, what ever that one is, will eventually win. I just hope that I don’t go down the wrong path, some what wasting my time.
When is trying your best not good enough?
Just a thought while thinking about perception and being critical.
Being critical of an idea is part of critical thinking, but being critical of a person is unethical and can only be a hindrance.