Tag: PHP

I like WordPress because it’s easy to install and use. But I really dislike the way it’s put up.

I’m not going into an exhaustive critic here because I really bend to the dedication coders devote to WordPress. I’ll just say what refactoring WordPress needs.

1. the architecture must conform to a clean design, with the details hidden in lower layers, but with the mechanics shown in higher ones.

For example, if you open the wordpress/index.php file this is what you find:

<?php /* Short and sweet */ define('WP_USE_THEMES', true); require('./wp-blog-header.php'); ?>

which is certainly short and weird for the main code of any software! We shoud see the famous loop here, shouldn’t we?

2. the documentation must be organized like any other software documentation: A user guide + a developer guide + an API reference + an instant guide.

For example, at this moment in the docs main page there are 114 content links in 8 categories.

3. any given external name must get an expert approval, before it’s used for the first time. A name is to be considered external if it’s going to be used (or understood) by someone else, be they persons or software, outside the smallest scope where it appears for the first time.

For example, digging in the code I found this function name: maybe_create_table (at wordpress /wp-admin /upgrade-functions.php :332). By its name I’d say that sometimes the function creates a table, and other times it does not. This is true with respect to the chosen implementation, which has been optimized for not creating a table if it already exists. But it’s false with respect to the context, because before executing the function, a table may exist or not, but after executing it, a table will exist for sure. So, maybe_create_table should be renamed as always_create_table, or just create_table. In case of collision with a previous create_table function, it could be named create_table_if_needed. And it’s generally a good idea to sort the words of a multi word name such that in a sorted list of similar objects, similar/related entries will appear near to each other.

There is an issue related to how WordPress displays PREformatted html.
By default WP translates any post retrieved from the database before displaying it. It uses two filter functions: wptexturize and wpautop, both added to the same filter: the_content. It also translates any other piece of content (Title, Excerpt, …), but I don’t care now.

The function wptexturize is harmless but a bit annoying.
The concept behind WP is keep it simple, isn’t it? If I post a ” I expect a ” to be displayed, not a “ or a ”. Authors always need to see what they mean!

Until an optional setting appears for turning it off, I recommend you to turn it off now.
It’s quite easy. Just edit the file wordpress/wp-includes/default-filters.php and comment out the line that reads

add_filter('the_content', 'wptexturize');

The function wpautop is harmful, so here is a replacement.

Step 1/2
Edit the file wordpress/wp-includes/functions-formatting.php and copy and paste this function after the function wpautop.

function ae_autop( $unprocessed, $br = 1 ) {
	$processed = "<br />n";
	while( strlen( $unprocessed ) > 0 ) {
		$debugging += 1;
		preg_match( '{^([^<]*)?(</?[^>]+?>)?(.*)$}s', $unprocessed, $matches );
		$text = $matches[1]; // as much text as possible before an HTML tag
		$text = str_replace( "n", "<br />n", $text );
		$tag = $matches[2]; // an HTML tag
		$unprocessed = $matches[3]; // the rest of $unprocessed
		if( preg_match( '{<preb}i', $tag ) ) {
			preg_match( '{^(<preb.*?</pre>)?(.*)$}is', $tag . $unprocessed, $skipping );
			$tag = $skipping[1]; // a pre block
			$unprocessed = $skipping[2]; // the rest of $unprocessed
		}
		$processed .= $text . $tag;     
	}
	return $processed; 
}

Step 2/2
Last but not least, edit the file wordpress/wp-includes/default-filters.php and comment out the line that reads

add_filter('the_content', 'wpautop');

After it, add this line

add_filter('the_content', 'ae_autop');