Archive for wordpress

Syntax Highlighter, WordPress & CSS

// April 26th, 2009 // Comments Off on Syntax Highlighter, WordPress & CSS // Tools, wordpress

I recently changed my Syntax Highlighter (which was cool, but old and abandon-ware) for the SyntaxHighlighter Evolved. Which I must say I love. Old versions were really bad. They were not that flexible. But version 2.0 is VERY flexible, and looks great. So I did the change in Neonlabs and Structum.

I stumbled with several problems. The first, and the one that bothered me more, was that in the Structum page, the code seemed to be broken into weird lines.

Broken Code

This was obviously a CSS problem since I didn’t have that problem in Neonlabs. So I used several tools to see which was the offending style. I mostly looked for the ‘pre’ tag on CSS but was not successful. After looking through the whole CSS style for my theme, I found the offending line of code:

#primary code {

Yep, it was a simple display attribute. I just commented that line and everything just worked.

Fixed Code

After that I tried editing the code to make it look better for the Structum page and I noticed that when it loaded it had a nasty Warning:

Warning: htmlspecialchars_decode() expects parameter 1 to be string, NULL given in /…/wp-includes/compat.php on line 105

And when I looked at the code blocks in my posts, there was nothing. They were empty.

I did a little research to see what was the problem, and it seems it is a WordPress bug. Simple variable naming bug in compat.php:

	function htmlspecialchars_decode( $str, $quote_style = ENT_COMPAT )
		if ( !is_scalar( $string ) ) {
			trigger_error( 'htmlspecialchars_decode() expects parameter 1 to be string, ' . gettype( $string ) . ' given', E_USER_WARNING );

Can you see the problem ? The problem resides in the $string variable. It doesn’t exist, so its value is null. Changing the variable parameter for is_scalar and gettype from $string to $str fixed the problem.

This is how it should look:

	function htmlspecialchars_decode( $str, $quote_style = ENT_COMPAT )
		if ( !is_scalar( $str ) ) {
			trigger_error( 'htmlspecialchars_decode() expects parameter 1 to be string, ' . gettype( $str ) . ' given', E_USER_WARNING );

After that, everything is working seamlessly again :D. hope this helps :D.

Upgrade to WordPress 2.6: Categories fix.

// August 3rd, 2008 // 2 Comments » // Site, wordpress

I just recently upgraded to WordPress 2.6 and the installation went smoothly (as always). But after installing my K2 style and adding my patches to the installation I noticed that *ALL* of my categories were blank. They were there, but blank.

I immediately panicked. I had carefully built my categories’ structure, and now it was gone. I quickly researched through Google and some WordPress related sites, I found some solutions but were incomplete, they only fixed Post Categories, I needed my link categories as well. So I decided to go into the database (which I should not needed to do). This could have been fixed easily if there was an edit mechanism for the categories (and it exists for posts categories, but for some reason the WordPress developers decided to hide it from the user. Great feature!) and link categories (I could not found any edit mechanism for the link categories in WordPress, it is probably hidden or maybe under some other name to make the user loose time).

I am actually not mad at the fact that the installation messed up MY DATA, I am mostly pissed at the fact that the WordPress developers don’t provide ways to fix the problem, I have to go into the database to fix it. I personally feel sorry for all those non-developers users which have to stick with blank categories if they migrate, or go back to what they had.

Anyways, let’s get back to the solution. Since the installer was not able to migrate the categories names, slugs and descriptions you have to enter it all over again but in the database. I have phpmyadmin setup so I just that to modify the database. The tables you are going to need to change are:

  • wp_terms: Here you will add the name and the slug name for each of the categories.
  • wp_terms_taxonomy: Here you will need to add the descriptions if any.

Since you are modifying the database, you’ll have to use your original database backup (which hopefully you did before upgrading) and match up the IDs.

For wp_terms the map from wp_categories goes like this:

wp_terms.term_id = wp_categories.cat_ID = wp_categories.cat_name
wp_terms.slug = wp_categories.category_nicename

For wp_terms_taxonomy, the map from wp_categories goes like this:

wp_terms_taxonomy.description = wp_categories.category_description

I found a lot of solutions on the web, but all of them only fix the post categories problem, they ignore the link categories completly. The best of them all is:

The only thing I think the solution is not describing well is that the table wp_terms_taxonomy only has descriptions and should not have the category name. The correct mapping is wp_terms_taxonomy.description = wp_categories.category_description. If you don’t have descriptions on your categories, then skip that step. Is not required.