• Firefox with the highly popular Adblock or Adblock Plus extensions
• WordPress with the visual editor enabled

As part of its functionality, Adblock inserts a tab next to Flash objects, etc. to make blocking that object as easy as a couple clicks.

The problem is, Adblock will insert the HTML code for this tab into the visual editor for a WordPress post that includes Flash.

And who wants code like this in their posts?

<a href="http://www.example.com/flash.swf" style="left: 0px ! important; top: 0px ! important" title="Click here to block this object with Adblock Plus" class="abp-objtab-0032072711718704405 visible ontop"></a>

Thankfully, the solution is simple:

• For Adblock, right-click on the link in the status bar and select “Whitelist this whole site.”

• For Adblock Plus, right-click on the icon in the status bar and select “Disable on (your domain name).”

This will stop Adblock from adding the “Block” tab (and its associated code) into your posts.

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"
WIDTH="550" HEIGHT="400" id="myMovieName"><PARAM NAME=movie VALUE="myFlashMovie.swf"><PARAM NAME=quality VALUE=high><PARAM NAME=bgcolor VALUE=#FFFFFF><EMBED src="myFlashMovie.swf" quality=high bgcolor=#FFFFFF WIDTH="550" HEIGHT="400"
NAME="myMovieName" ALIGN="" TYPE="application/x-shockwave-flash"
PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer"></EMBED></OBJECT>

Not only is this messy-looking, it’s invalid XHTML, since the <embed> element isn’t part of the XHTML specification.

Often this wouldn’t be a problem, but since WordPress uses the stricter XHTML standard instead of the loosey-goosey HTML specification, using such code in your posts, pages, or template will likely cause your blog to not validate.

Thankfully, the same Flash video can be included in the following manner:

<object type="application/x-shockwave-flash" data="myFlashMovie.swf" height="250" width="800"><param name="movie" value="myFlashMovie.swf" /></object>

Not only is this much cleaner and shorter, it also avoids the <embed> element, ensuring XHTML compliance.

I have, and I’ve successfully used this tactic buried in the WordPress Codex’s Using Permalinks article under the “Fixing .htaccess Generation Issues” section.

This only applies if your web host is using Apache (if you aren’t sure, chances are it is, but you might want to check with your host first).

Your host might have blocked the SERVER_SOFTWARE variable and this will cause WordPress’ .htaccess generation to fail. If you are sure that your server is running Apache, you can force WordPress to believe that your server is running Apache by changing your wp-includes/vars.php file. Follow the steps below to implement these changes.

• Open the wp-includes/vars.php file using the built in file editor in your WordPress Admin panel. To navigate to this panel, login to WordPress, click on “Manage”, then on “Files”, scroll to the bottom and type in wp-includes/vars.php into the text box under the “Other Files” title.

  Look for

  $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

  and replace it with

  // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

• Add a new line under

  // $is_apache = strstr($_SERVER['SERVER_SOFTWARE'], 'Apache') ? 1 : 0;

  and type in

  $is_apache = 1;

Then click “Update File,” and try re-enabling permalinks.

Did this tip work for you? Have another permalink troubleshooting tip you’d like to share? Use the comments section below!

Fatal error: Call to undefined function: wp_die()

I did extensive research a la Google, and lots of other people seemed to have the problem [1, 2, 3], but I still couldn’t find the answer.

I finally figured it out: the database user I had added wasn’t setup with permissions to access the database. Apparently there’s a bug in WordPress MU that chokes on this instead of displaying an explanatory error message.

If that trick doesn’t work, I’d suggest double-checking your database information. In particular, if you’re in a shared hosting environment, you’ll probably have to prefix the database name/user with some form of your hosting username (e.g. “username_database” instead of just “database”).

Hope this helps someone!

http://wordpress.jdwebdev.com/

http://wordpress.jdwebdev.com/#test

Sure, the Digg button’s behavior could be useful in some situations (like when anchor-based permalinks are used). But what happens when you click the “Read more” link on a WordPress post? Yep, it takes you to a URL with an anchor. Although this seems trivial, it could nevertheless result in:

• Your readers’ Diggs being split across two submissions for the same thing.
• Your Digg button showing a “Submit” option instead of its true Digg count.

Here’s how to fix it:

It’s pretty simple. This is assuming you added the Digg button to single post pages yourself as opposed to using a plugin. (If you use a plugin, check and see if the author took the anchor factor into account. If not, contact the author and send him or her a link to this post.)

1. Login to WordPress administration, then go to Appearance > Editor > Single Post.

2. Find the code for the Digg button. Here’s the typical JavaScript:

   <script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script>

3. Insert this line of code right before that one:

   <script type="text/javascript">digg_url = "<?php the_permalink(); ?>"</script>

4. Click Save, and you’re done!

You shouldn’t have to worry about other buttons like those for BloggingZoom, Sphinn, and Scoop, since they don’t seem to have this anchor issue.

Social this post and share this tip with other Digg-using bloggers!