Category: wordpress

In the post Interesting new kind of WordPress Plugin Spam I reported about a site which offers WordPress plugins to attract the careless user to a scam site.

Since then Rahul (the man behind the scam) wasn’t inactive. A German user reported problems with his website which could easily be tracked down to a problem with an installed plugin. After a bit of research a plugin named “Visitor Stats” could be accused.

A quick peek at the known site confirmed my suspicion: the plugin is offered by “111 ways to make money”. Interestingly the site itself does not off the plugin (anymore). OK, maybe Rahul’s forgot to upload it. But where did the user got the plugin?

Continue reading WordPress Plugin Spam, part 2

There’s seems to be a new way of luring users of WordPress to spam sites: WordPress Plugin Spam.

Like most other plugin authors I regularly check what others are saying about them; actually I have a Google Alert set on the names). The other day I received an an e-mail from this service telling me that there is a new fork of my pagebar plugin called Advanced pagebar. Hey cool, some one build a new plugin based on my code.

The plugin was called  “Advance Pagebar – New way to navigate Pages …”. Surprisingly the link “http://wordpress.org/extend/plugins/advance-pagebar/” did not work. What the heck?

Continue reading Interesting new kind of WordPress Plugin Spam

You’ve created a plugin that worked happily since version 2.5 of WordPress. Then came version 2.9 and the users of your plugin complain that the theme editor does not work anymore! What the theme editor? What have I to do with the theme editor?

That were my thoughts when I received bug reports for the pagebar plugin. I had absolutely no idea why and first checked the usual suspects; with no success. So I tried a different approach and disabled all initialisation code. The theme editor worked. I enabled the first disabled line and Eureka! The theme editor failed. This has to be the
erroneous line:

$dir = trailingslashit(WP_CONTENT [...]

The $dir variable is global and that seemed to be the problem. A short look at theme-editor.php shows that’s there a global variable called $dir. So I changed the variable name in my plugin to a more unique name and voilà, everything works as expected.

There are some lessons I learned from this incident:

• Use a unique name for your global variables.
• Better: Never use global variables at all.
• Even better: encapsulate everythin inside a class.

I hope his short story helped you to debug your plugin and leave some happy users behind.

How does Peter Westwood look like? How does Mark Jaquith talk? Is Ryan Boren funny? You can find some anwers in this video from the first meetup of all WordPress core developers:

Most WordPress users will know the <!--more--> tag which allows you to create a teaser for your blog post. The text in front of the tag will be displayed on the main blog page and after clicking the “more” link the single post page containing the teaser and remaining part of the blog post will be displayed.

More often than not this is adequate but there may be situation where you want to create a separate teaser which isn’t displayed on the single post page. So it may be a good idea to create a collage as the teaser for a post containing various images. On the post page itself the collage would not be appropriate. Another situation could be a very striking teaser which does not fit into the main post but still is a good teaser to attract readers.

To hide these parts of the post you can use the lesser known <!--noteaser--> tag:

Teaser text
<! --more-><! --noteaser-->Post text.

The <!--noteaser--> necessarily has to follow directly after the <!--more--> tag otherwise it will not be evaluated.

However there are some issues using the tag:

• After clicking the more tag the content of the post will be moved to the top of the browser window. This may be appropriate for a standard posting where the teaser text shall be hidden from the reader’s eyes. Using the noteaser tag there is no such text any more and the reader is wondering if there is anything above.
• The text in front of the <!--more--><!--noteaser--> tags will not be shown on the preview page. So you have to write your post in two steps: first creating the text as usual and inserting the <!--noteaser--&gt in the final state.
• All line breaks are preserved. To avoid an additional empty line at the top of the post you should insert the tags on a single line.

These issues may be solved by creating a plugin… maybe later. Nevertheless the tag is a nice tool to add a different view to your blog.

(img by shindohd)

There are times when you want to access the data from your WordPress database from a webpage outside of your WordPress installation. This can be done by using the mysql_connect of PHP and selecting the data with some genuine SQL statements. This will work but it has the substantive disadvantage that the WordPress database is changed now and then and that the SQL statement will fail sooner or later.

There has to be a better solution and there is one! Simply use the function provided by WordPress itself to access the data. It’s as simple as this code:

include '../blog/wp-blog-header.php';

In this example WordPress is installed in the directory “../blog” relative to the directory of the current script. You have to adapt it to your installation, of course. Now you can access the database using the $wpdb-instance, i.e.

$post_id = 666;
$sql = "select post_title from $wpdb->posts where ID=$post_id";
$title = $wpdb->get_var($sql);

Ok, if Automattic decides to change the row names you’ve lost again. So you should completely avoid direct database calls and use the functions build into WordPress which are also available after including the above file:

$post_id = 666;
$title =  get_the_title($post_id);

This should be a safe call for a very long time!