The point of the Visual editor is that it likely makes more sense to the “average” user. When they highlight a word and click the [b] button, the word literally turns bold, not gets wrapped in <strong></strong> tags. If they insert a picture, they see it. If they insert a link, it looks like a link.

The Visual editor is perfectly fine, but the nerdier among us likely prefer the HTML view so they can see exactly what is going on. After all, the Visual editor has had a history of not being super hot when it comes to leaving our nicely organized HTML alone (when switching back and forth).

You can turn off the visual editor from your User Preferences.

Once that is off, we are free to compose posts in HTML. But that’s not our only option. We could also compose in Markdown!

What is Markdown?

Markdown is a special syntax for composing. It was originally conceived by John Gruber and you can learn more about it here.

Getting it into WordPress

Markdown was originally written in Perl. It was converted to PHP by Michel Fortin and comes with a WordPress plugin. You can get it here, which also has instructions for installing and activating it.

Why Markdown?

The idea is that it makes looking at the writing much more readable than HTML would be.

While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.

It does look quite a bit like a text email.

Markdown Syntax

There isn’t all that much to it, but you might want to check out the actual documentation page instead of me rehashing it here.

In a nutshell:

*italic*
**bold**
[link text](http://example.com)
## header 2
### header 3
   code is indented

Is it for you?

Whether or not this looks appealing to you is simply a matter of taste. Do keep in mind that Markdown is compatible with HTML. So if you have articles you have previously written in HTML, those will be fine with this activated. However, the opposite is not true. If you create a bunch of content in Markdown and then decide to turn it off, you will be looking at asterisks and octothorpes and such.

One other concern would theoretically be shortcodes. Short codes also use the [foo] syntax, so I’m actually not sure which one would take precedence. Definitely should be tested if you are a heavy shortcodes user.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 3 comments | Add to Delicious
Categorized: Plugins | Tagged: editor, HTML, markdown

So RSS is pretty sweet. There are lots of feed parsers out there that can do cool stuff with feeds. XML is pretty cool. PHP5 has functions to make decently quick work of parsing XML.

But what if you are working with JavaScript? XML + JavaScript kinda sucks. The JSON format is approximately one million times easier to work with. Fortunately there is a kick-ass plugin for us!

The Plugin…

is by Dan Phiffer who created it for for working with the MoMA (Museum of Modern Art) blog. Apparently it’s some Frankenstein’s monster of Ruby on Rails and WordPress.

WordPress JSON API Plugin

All you need to do is install and activate it, and you’ll have access to a new URL structure that servers up JSON data.

At its most simple:

http://example.com/?json=1

Which will return delicious, delicious JSON:

{
  "status": "ok",
  "count": 1,
  "count_total": 1,
  "pages": 1,
  "posts": [
    {
      "id": 1,
      "slug": "hello-world",
      "url": "http:\/\/localhost\/wordpress\/?p=1",
      "title": "Hello world!",
      "title_plain": "Hello world!",
      "content": "<p>Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!<\/p>\n",
      "excerpt": "Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!\n",
      "date": "2009-11-11 12:50:19",
      "modified": "2009-11-11 12:50:19",
      "categories": [],
      "tags": [],
      "author": {
        "id": 1,
        "slug": "admin",
        "name": "admin",
        "first_name": "",
        "last_name": "",
        "nickname": "",
        "url": "",
        "description": ""
      },
      "comments": [
        {
          "id": 1,
          "name": "Mr WordPress",
          "url": "http:\/\/wordpress.org\/",
          "date": "2009-11-11 12:50:19",
          "content": "<p>Hi, this is a comment.<br \/>To delete a comment, just log in and view the post's comments. There you will have the option to edit or delete them.<\/p>\n",
          "parent": 0
        }
      ],
      "comment_count": 1,
      "comment_status": "open"
    }
  ]
}

The plugin page has comprehensive notes on how you can structure the URLs to get just what you need back.

Of course, the more that you want, the larger the size of the data is, the harder it has to work, and the slower it can be. The plugin allows you to trim down what it returns to speed things up if needed. This is how to get just 10 posts, with a specific custom field, and only a few other things:

http://example.com/?json=1&count=10&custom_fields=PostThumb&include=title,custom_fields,excerpt

What might you use this for?

jQuery UI has recently released a new feature: Autocomplete. I learned that it basically consumes JSON data to populate what it autocompletes with. So I decided to try and connect the two and make an autocomplete search box for this site.

Try typing in like “CSS” or something and you can see some articles autocomplete below the input. You can select one and press return to go to that post. It’s kinda cheezy, probably not something I would roll out live, but it was a fun demo to work on. If you want to see the JavaScript that powers it, check it out.

To be fair, I had to hack the plugin just slightly to get it to work. The autocomplete plugin wants a “value” and “label” data in the JSON, so I added them. It’s a pretty trivial adjustment so if anyone wants that code, let me know.

UPDATE: Demo temporarily removed for security.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 13 comments | Add to Delicious
Categorized: Plugins | Tagged: API, JavaScript, JSON, plugin

Let me note that this isn’t an absolutely comprehensive comparison of every single feature. For example, they both claim to be fast. I’m not techy enough to know which one is really “faster”. These are the features that are important to me.

Other little features

• You can disable All-In-One SEO without deactivating or uninstalling it.
• You can export and import settings with wpSEO. So if you have a specific setup you like to use, it’s easy to move that to other sites.

General thoughts

• wpSEO definitely has more features, but of course more isn’t always better. The settings page may be overwhelming for some.
• All-In-One SEO is free, and it does all the things I consider vital for a SEO plugin.
• On a pure features / functions / UI standpoint, I like wpSEO better.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 24 comments | Add to Delicious
Categorized: Plugins | Tagged: meta, SEO, title

Normal look for a plugin that needs updating

But W3 Total Cache also needed an upgrading, and this is what it looked like…

Now there is some info!

This plugin clearly explains why upgrading would be a good idea. I like it. I think this should definitely be employed on plugins, especially on updates which may have seriously implications on your sites performance.

Oh and look, it doesn’t bug you with all the notes if it isn’t activated:

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 11 comments | Add to Delicious
Categorized: Plugins | Tagged: plugin

If you are a seasoned plugin developer, you already know how to hook it up at the WordPress Directory, but for those who don’t, this DiW tutorial will show you everything you need to know.

Why host your plugin at the WP Directory?

Some of the benefits of hosting your plugin at the WordPress Plugin Directory:

• Track basic statistics regarding how many people are downloading and when
• Provide a centralized location for users to leave comments and feedback
• Get your plugin rated against the many other hosted WordPress plugins
• And of course, give your plugin greater exposure to the WP community

Further, it seems that plugins hosted at the official directory are perceived to be associated with a greater degree of “trustworthiness.” People trust WordPress, and they also trust the various resources (plugins, themes, etc.) made available to them through the wordpress.org website. Basically, if you’re writing plugins for the WordPress community, you should be sharing them with as many people possible. The Plugin Directory does this exceedingly well.

“Worth playing for?” Let’s look at a quick overview before digging into the specifics of getting your plugin added to the Directory..

Overview

To help get a sense of direction before getting started, consider this overview of events:

• Write and prepare your plugin
• Prepare the readme.txt file
• Sign up for access to the Subversion Repository
• Wait for approval and SVN access information
• Use Subversion software to upload your plugin files
• Wait a few minutes for the system to add your plugin to the Plugin Directory

Of course, the big hurdle that many “would-be” contributors have is using the SVN/Subversion system and software. To be honest, this was one of the reasons why I never bothered adding my other plugins, but now that I’ve seen how easy it actually is (once you learn it), I will most likely add my other plugins as well (eventually).

First steps

First, get your plugin and files ready. You don’t need to compress anything with zip or tar because the SVN system will do that automatically for you based on the contents of your plugin. In my case, the plugin was Block Bad Queries, which contains the following two files:

• block-bad-queries.php
• readme.txt

The actual plugin file is the “block-bad-queries.php”. The “readme.txt is the only other required file. If you have multiple plugin files, that’s fine too, they will be uploaded and managed together during the subversion process.

For more information on getting things ready, check out Plugin Submission and Promotion at the Codex. A key factor in the process is a well-written readme.txt file, which we’ll look at next..

Pimp your readme.txt file

I think having a well-prepared readme.txt file is one of the things that helped everything go smoothly for my first time out. Your plugin’s readme.txt is used for the content of the various pages in a typical plugin listing:

• Plugin Name
• Description
• Installation
• Faq
• Screenshots
• Other Notes
• Changelog
• Stats
• Admin

That’s basically it. If your readme.txt contains each of these sections, you should be good to go. There are various details required for certain sections, such as the opening “Plugin Name” information, which requires the following specifics (using BBQ as an example):

=== Plugin Name ===

Contributors: Jeff Starr
Plugin Name: Block Bad Queries
Plugin URI: http://perishablepress.com/press/2009/12/22/protect-wordpress-against-malicious-url-requests/
Tags: wp, protect, php, eval, malicious, url
Author URI: http://perishablepress.com/
Author: Perishable Press
Requires at least: 2.3
Tested up to: 2.9
Stable tag: 1.0
Version: 1.0 

I think we’re all familiar with this type of information – something similar is included at the top of virtually every plugin (and theme) in existence. In any case, this is the first part of a proper readme.txt file, as seen in the WordPress/bbPress plugin readme file standard, which also contains details and further information about the various requirements.

So, to put all of this together and create your own readme.txt file, just copy & paste the following template into a blank .txt file and flesh it out with your own details:

=== Plugin Name ===

Contributors:      (plugin contributors)
Plugin Name:       (name of your plugin)
Plugin URI:        (web page for plugin)
Tags:              (tags for the plugin)
Author URI:        (plugin authors site)
Author:            (the plugin's author)
Donate link:       (a link for donating)
Requires at least: (minimum required WP) 
Tested up to:      (tested WP up to ver)
Stable tag:        (plugin's stable ver)
Version:           (plugins current ver)

== Description ==

== Installation ==

== Upgrade Notice ==

== Screenshots ==

== Changelog ==

== Frequently Asked Questions ==

== Donations ==

Aside from wanting to put the “Plugin Name” section at the top of the file, these different sections can be rearranged in any order, but they all need to be present in order to adhere to WordPress guidelines and pass the readme validation. For more information on fleshing out each of these different sections, check out the standard readme.txt example. Once you get everything pimped and ready, the readme validator will display the good news:

Your readme.txt rocks. Seriously. Flying colors.

If you don’t see this message, you’ll get a list of things that need fixed in order to pass validation. The validator is a great tool that makes it easy to put together a proper readme.txt file.

A few notes on the readme file

Here are a few notes that I found helpful while creating the readme.txt file:

• The readme file uses markdown for marking up your info with links, lists and so on.
• You may use PHP in your readme content (escape with backticks: `<?php ?>`)
• Use asterisks for *emphasized text*
• Use double asterisks for **strong text**

As you can see, the readme.txt file is quite flexible, enabling you to customize your plugin’s information as provided in the Plugin Repository.

Prepare the plugin file

After creating and testing your plugin, you need to give it a license. Here is what the WordPress Codex has to say about it:

• Your plugin must be GPLv2 Compatible.
• The plugin most not do anything illegal, or be morally offensive.
• You have to actually use the subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.
• The plugin must not embed external links on the public site (like a “powered by” link) without explicitly asking the user’s permission.
• If you don’t specify a v2-compatible license, what you check in is explicitly GPLv2.

Once you’ve given your plugin the required license — either explicitly by including the license or implicitly by not including any license — you’re ready to get hosted at the Repository. Take a few deep breaths and clear your mind..

Sign up for access to the Plugin Repository

Now with your plugin files ready to go, visit the Sign-up page, login to your account, and fill out the form with the following information:

• Plugin Name (required)
• Plugin Description (required)
• Plugin URL

After submitting the form, be prepared to wait awhile to be approved access to the subversion repository. For my plugin, it took around 18 hours to receive a response. Just be patient, if everything looks good, someone will approve your request within a reasonably undefined amount of time. Eventually, you should receive an email with all the information you need to access the Subversion Repository. This is where you will upload and store your plugin. The system will use the files and information included in the Subversion Repository to generate the actual web pages that appear in the Plugin Directory with all of the other plugins. It usually takes a few minutes for the system to create your plugin’s entry, so be patient after uploading. Just as a general reference, I think I waited something like five or ten minutes before seeing my plugin listed in the Plugin Browser.

Use Subversion software to upload your plugin files

At this point, you’ve been granted access to the SVN repository and are ready to upload your files and call it done (until the next plugin update). To begin this task, familiarize yourself (if necessary) with the basics of using Subversion with WordPress.

There’s a LOT to learn about Subversion, but don’t let that stop you from making quick use of it to get the job done.

What is Subversion?

Basically, Subversion is an open-source piece of software that people use to more easily manage files and directories as they change over time. The key thing about Subversion is that it enables you to restore previous versions of your data and understand how things have changed. This “time-machine” functionality is especially useful for managing things like continually changing source code, and makes managing thousands of plugins much easier.

How do I use Subversion?

To use Subversion, you’ll need some software. Mac people get it pre-installed with Leopard, and Windows peeps can download the binary installer here. Keep in mind that, for either operating system, Subversion is something you run through either Terminal (Mac) or the Command Prompt (Win) as a series of commands. As you can imagine, there are a gazillion commands available, but we’ll only be needing a select few for our purposes here.

Please don’t make me use the command line!

If the thought of using the command line to run software makes your stomach turn, you can use Subversion through a graphical interface such as Versions for Mac, and/or
Tortoise for Windows. I haven’t used either of these apps, but they certainly look more inviting than the command prompt, which is what we’re rolling with for this tutorial.

How does it work?

There are two sets of files we’re working with: local files (on your computer) and remote files (on the server). For each set of files, we want the following directory structure (using my plugin as an example):

root-folder/
	/trunk/
		block-bad-queries.php
		readme.txt
	/branches/
	/tags/

To get started, we’ll place our files into the /trunk/ directory, and then in the future add new versions to either the /branches/ directory (for major updates) or /tags/ directory (for minor updates).

Once uploaded, your files are stored in the central plugin repository on WordPress servers. From the repository, anyone can check out a copy of your file(s), but only you (the plugin author) have the authority to check in new file(s). Using Subversion, any changes made to your local files are mirrored exactly on the server, and eventually reflected in your plugin pages in the WordPress.org plugin directory.

Add your plugin to the Repository

Now that we have our files ready and Terminal (or Command Prompt) open, let’s wrap this up and upload our files to the Plugin Repository. Here’s an overview of what we’re going to do:

1. Check out the blank repository (i.e., the empty directory structure)
2. Add your files to the local /trunk/ directory on your computer
3. Update the repository with copies of your local files

Here’s how to do it with Mac Terminal, and it’s very similar for Windows Command Prompt:

$ mkdir my-local-dir
$ svn co http://svn.wp-plugins.org/your-plugin-name my-local-dir
$ cd my-local-dir/
my-local-dir/$ cp ~/my-plugin.php trunk/my-plugin.php
my-local-dir/$ cp ~/readme.txt trunk/readme.txt
my-local-dir/$ svn add trunk/*
my-local-dir/$ svn ci -m 'add some notes here'

And here are the same commands with comments and returned messages:

# create a local folder for your copy of the repository

$ mkdir my-local-dir

# download the empty directory structure to your new folder

$ svn co http://svn.wp-plugins.org/your-plugin-name my-local-dir
> A	my-local-dir/trunk
> A	my-local-dir/branches
> A	my-local-dir/tags
> Checked out revision 11325.

# copy your plugin files to the local trunk directory

$ cd my-local-dir/
my-local-dir/$ cp ~/my-plugin.php trunk/my-plugin.php
my-local-dir/$ cp ~/readme.txt trunk/readme.txt

# register the new files with Subversion

my-local-dir/$ svn add trunk/*
> A	trunk/my-plugin.php
> A	trunk/readme.txt

# update the Repository with the new files

my-local-dir/$ svn ci -m 'add some notes here'
> Adding	trunk/my-plugin.php
> Adding	trunk/readme.txt
> Transmitting file data ..
> Committed revision 11326.

# All done!

That may look like a mouthful, but it’s actually only about seven commands, even fewer if you manually create the directory structure and add the local files yourself. You should also keep the following notes in mind if you are new to the whole “command line” thing:

• Any line prefixed with a pound sign # is a comment and should not be used as a command.
• Lines beginning with a ”>” character indicate a response from the software and should not be used as a command.
• All of the specific file and directory names need to be changed to match your own.
• The “-m 'add some notes here'” in the last command is used to add notes for the event — they may be anything you wish (or none at all).
• At the last step, you may be prompted for your username and password, which should be the same as used when logged into the WordPress.org site.

After running those commands, your plugin will be in the Repository and ready for the system to automatically create your actual plugin pages as they will appear in the Plugin Directory. This usually takes some time, so grab a drink and kick back for around five to ten minutes. Eventually, you will see your plugin appear on the Newest Plugins page, and then also at its dedicated page, which will be something like this:

http://wordpress.org/extend/plugins/your-new-plugin/

Once you get this far, you’re golden. There are many other cool things you can do with Subversion to manage and update your plugin. To get started with updating and tagging, check out the How to Use Subversion in the Plugin Directory. And for even more information on the entire process of adding your plugins, check out the Plugin Developer FAQ.

Final thoughts..

Overall, getting my first plugin hosted at the WordPress Plugin Directory was a great learning experience that will make it easy to add other plugins in the future. Hopefully the fruits of my labor will help you when adding your own plugins to the Directory. As always, feel free to chime in with suggestions, questions and concerns about any of the techniques described here. It would be great to hear more about using Subversion (tips, tricks, etc.).

Also, if you are interested, you can see the result of all this work by checking out the Block Bad Queries (BBQ) Plugin at the Plugin Directory. There’s still a few details that need to be added/tweaked, but it’s great just having it in there.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 12 comments | Add to Delicious
Categorized: Plugins | Tagged: plugin, svn

I find these results to be very interesting. Looking at the data, we see that 63% of voters use 10 plugins or less. Further, a whopping 84% of voters use fewer than 20 plugins. Also surprising to see a significant percentage of voters using absolutely no plugins whatsoever. And last but not least, we have the most hardcore WordPress peeps weighing in with over 50 plugins per site! Amazing.

There was also some good conversation about the optimal number of plugins and which plugins are absolutely essential. Here are some of the highlights:

redwall_hp

[...] reducing plugins isn’t the only route to a screaming-fast site. You can run 20 plugins and still have lightning-fast page serving times if your server is well-configured. Using a RAM cache, switching from Apache to NGINX to save on RAM, and making other server tweaks can make a WordPress site scream.

Jillian Nichols

In response to those arguing that you can always benefit from Akismet – don’t forget that it’s kind of pointless if your WordPress site doesn’t have any comment forms. I use WordPress to make sites of static content a lot, and there’s no reason to have Akismet installed. In general WordPress out-of-the-box by itself works for me, occasionally I may use one or two plugins.

Alex Denning

I’m using 9 which is still too many – Akismet, Sitemap, RSS Footer, SEO Comments, Subscribe to comments, W3 Cache, Backup, WP125 and YARRP. Would love to get that figure down below 5 though.

Ryan Rampersad

I look at the plugins I have enabled every now and then to see if I can disable some of them. I think having 15 plugins is too many but I can’t live without them.

Carlos

The only plugin I’ve installed is the askimet. I haven’t used any plugins because I’m learning how wordpress works. So if I start depending on plugins it takes the fun out of learning and I don’t find out the capabilities I have of tinkering with wordpress.

Matt

I’m using 71 plugins at the moment, which I realise is a lot but they don’t hinder performance that much. I’ve fine-tuned most of them.

Chris

I want maximum functionality and comfort, so I use more than 20 plugins, to turn my WP into what I absolute want to have :-D

Lucian

I use WordPress as a CMS for my clients. I have an average of 10-20 and I don’t see how is possible to achieve some of necessary functionalities, without or with just few of them. Most of them if are well written don’t affect too much the speed of the website.

Thanks to everyone who voted! Stay tuned for the next DiW poll! :)

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 19 comments | Add to Delicious
Categorized: Plugins | Tagged: polls

I explained my thinking on all of this in a post on CSS-Tricks: Curating Comment Threads. This has screenshots of how the plugin works, and my first exploration into using it.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | One comment | Add to Delicious
Categorized: Plugins | Tagged: comments, plugin

• If you update and forget to re-activate (somewhat hard to do since it reminds the shit out of you on every page of the admin), it could cause problems.
• We are forced to see Michael’s large promotional/donation blocks up in our faces above where we can reactivate. I’m all for plugin authors making as much money as they can, but this seemed to me a bit too far.
• I really like the plugin and use it on all my sites and wish it was closer to my version of perfect.

But Michael recently stopped by to explain his side, which is interesting, so I thought I’d update the record, as it were.

Michael Torbert:

… a site complained that a new feature damaged their site’s search engine results placement. They finally admitted that they were incorrect in this assumption, and that the cause was something else unrelated to the plugin, but their original assessment was that a new feature hurt them.

From then on, any update which introduces new options (not just behind the scenes changes) require the user to reactivate the plugin from the settings page, to make sure that they can review the options.

I can understand this line of thinking. Forcing the user to visit the options page may be the closest thing to getting them to think about the plugins options as is possible.

Michael is also aware of the potentially negative experience:

I’m aware of how it looks, and I understand that it’s annoying for some users. I spent a lot of time thinking about it and consulted with a number of other people in the community when contemplating the decision about what to do.
Unfortunately, in this case there was no way to make everyone happy, so I sided with ensuring that nobody could ever say (even if incorrectly as was the case) that new features introduced caused harmful effects to their sites SEO.

Perhaps a better way?

Let’s say that the moment you decided to upgrade the plugin to a version with new features, the google bot decided to stroll by your site. The plugin is momentarily deactivated, so the google bot sees lots of differences. The canonical tag is gone, the meta tags are gone, the page title is different. Surely that isn’t good for SEO.

Perhaps this plugin could save the currently running version number in the wp_options table. Then when an upgrade is performed, it could update this but also save the previous version number. Then instead of deactivating itself, it could display a message (rather boldly, like the current message) which explains what is new with the plugin and things you should watch for.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 26 comments | Add to Delicious
Categorized: Plugins | Tagged: plugin, SEO

Subscribe To Comments, rebuilt for modern WordPress

This is an incredibly popular plugin, and we use it right here on Digging Into WordPress. It still works with 2.9, but it hasn’t been updated since 2007-12-14. There is no admin panel to speak of, and the management screen that does exist looks like this:

I would love to see this re-built, designed up, and intergrated into the Admin area of WordPress.

Publishing a page, main action button

If you publish a lot of Pages in WordPress, you can feel me on this one.

Approved comments to all admins

For posts that Jeff writes, when someone comments, Jeff gets an email and I don’t. When I write an article and someone comments, I get an email but Jeff doesn’t. There should be some kind of way (plugin?) where we both get emails about comments.

Feature/Bury comments

Alright this one I think would be a HUGELY awesome idea for a plugin. Two more buttons for comment moderation:

All the plugin does is add this information to the comment data somehow. When all the comments are output with wp_list_comments, the only thing that happens is a “featured” or “bury” class is applied to the list items classes:

Then it is up to the theme designer to integrate styling or functionality with these hook. Imagine special backgrounds for featured comments, or gray-ing down buried comments. I could even see this being in the WordPress core, as a way to really enhance the readability of long comment threads through admin moderation.

Style-XXXX.css

I like the Art Direction plugin* for it’s ability to add code into the <head> section for any particular Post or Page. This gives the ability to add CSS or JavaScript unique to a page and all the possibilities that brings.

Another way to approach this would be to have your theme automatically look for the presence of a CSS file unique to it on the server somewhere. Probably in the format “style-%PAGE-ID%.css”. If this file exists, it appends it into the head and uses it. If not, it doesn’t. That way styling a post is as simple as chucking in a CSS file of the proper name and writing code.

* Important note about the Art Direction Plugin: it breaks caching plugins. I’m sure many of you use caching plugins like W3 Total Cache or WP Super Cache. The combo of these plugins will wreak all kinds of havoc on your site. Frederick Townes has re-wrote the art direction plugin for my use on CSS-Tricks, and we’ve tried to submit it to the author be he hasn’t done anything with it yet.

Rules for turning comments off

There is one setting under Settings > Discussion for when you want comments turned off on all Posts/Pages. It’s fairly common on bigger sites to turn off comments on older content. After a certain amount of time relevant conversation dies off and turns into all spam and makes moderating comments on the site a much bigger job.

However, there might be certain content on a site which may make sense to have different durations for open comments. An opinionated blog article, maybe 2 weeks. A snippet of code, perhaps a year would be better. I think it would be cool to be able to set how long comments stay open. Perhaps based on what page template is in use, or the category applied.

That’s all I gots for now. Food for thought.

Like the article? Get the book!

© 2010 Digging into WordPress | Permalink | 31 comments | Add to Delicious
Categorized: Plugins | Tagged: art-direction, wishes

Not even Akismet..

“Sure,” you are thinking, “you don’t need any plugins except for Akismet.” I mean, you definitely need that plugin, right? After all, it’s included with WordPress, so it’s got to be important. Umm, not so much. Yes, there are certain blogs that would probably be wise to take advantage of the additional spam-protection that Akismet might provide, but for 99% of the sites out there, it really isn’t necessary.

WordPress is strong enough..

I think one of the most underrated strengths of WordPress is its built-in anti-spam functionality. With an ounce of knowledge and a pound of forethought, you can configure your WordPress Discussion settings to act as a powerful and effective defense against the evil forces of spam. No plugins required! Let’s look at WordPress’ anti-spam tools and see why they’re all you need for a spam-free site..

Default article settings

First up, consider your default article settings. If comments aren’t enabled, of course you know that you don’t need Akismet or any other anti-spam plugin for that matter. If comments are enabled, you can cut out a significant portion of spam by simply disallowing pingbacks and trackbacks. By clicking a single checkbox, all of that crap that comes rolling in as trackback spam will stop. That’s a huge step right there, and it will eliminate every plugin that has anything to do with displaying or controlling ping/trackbacks.

Comment author must fill out name and e-mail

Another smart move, although I think most sites do this one already. By requiring your commentators to at least fill out these two fields (even if it is just dummy data most of the time), you brush off all of those lazy spammers who are picking up the easy ground fruit. Most legitimate commentators don’t mind filling in this info because they usually have something they want to say. Lazy spammers, not so much.

Users must be registered and logged in to comment

If possible given the specific goals of your site, requiring users to log in before commenting is an extremely effective way of preventing comment spam. Although requiring registration will stop a lot of legit comments as well, it is a powerful deterrent to lazy spammers and completely stops automated scripts. Sure, you may still get some trolls stinking up the place, but you would be getting those anyway. Plus, if they’re registered, it makes it easier to deal with them.

Automatically close comments on articles older than XX days

This is my favorite WordPress anti-spam feature. For a long time, we needed a plugin to get this done, but now that it is built into WordPress, everyone should be using it. Here at Digging into WordPress, we close comments on old posts after 90 days, which seems to be just about the right amount of time. Anything longer than that, and your posts begin to get targeted by spammers and automated spam scripts. Especially if your posts tend to do well and build up a lot of page rank, they will be prime targets for spam as time rolls on.

Break comments into pages with XX comments per page

This one’s not as obvious, but it is also a great way to reduce the incentive to spam your site. Spammers target strong pages for their junk, so by breaking your comments into pages of, say, 20 comments each, you get the best comments on the first page (the same page as the article), and then the typically declining-quality comments on subsequent non-ranking pages. Just make sure you are using meta canonical tags to keep the juice where it should be.

E-mail me whenever..

Unless your site is literally flooded with comments on every post, getting email alerts for new comments is an excellent way to kill any spam nonsense that gets through. I have done this at Perishable Press for four years now, and you would be hard-pressed to find even one spam comment anywhere on the site.

Before a comment appears an administrator must always approve the comment

This could get kind of labor-intensive, but it is a 100%-guaranteed way of completely eliminating spam without using any plugins whatsoever. Zero. Nada. Nil. If you are one of the many millions whose blog receives fairly few comments, this method will keep your comments squeaky clean.

Comment author must have a previously approved comment

A super-effective strategy that is not as labor-intensive as moderating all comments and not as restrictive as requiring registration. The idea here is that you get a chance to “meet” each one of your commentators and leave the door open only for the good guys. This technique drastically cuts back on human spam, and virtually eliminates automated spam (unless you don’t catch it the first time).

Hold a comment in the queue if it contains XX or more links

Lots of comment spam is just crawling with links. A few mindless words and then BAM — they drop in a few hundred links. Some of the more subtle spammers are less obvious, but still have to unload their payload somehow, so they usually integrate a couple of links within some not-so-carefully crafted text. You know what I’m talking about. You definitely want to moderate anything with more than like two or three links. This trick is great for catching some of the craftier spam maggots.

Comment Moderation Blacklist and Spam Blacklist

A finely tuned WordPress Blacklist list eliminates the need for many types of plugins, scripts, and third-party blacklists. Any words, characters, or IP addresses included in either the Moderation or Spam Blacklist will be used to innoculate your site against any matching comments. Granted, it takes a bit of persistence to build up a good list, but once you do, it is very difficult for spammers to get around it. Note that, unless you are absolutely sure, you should probably stick with the Moderation Blacklist (regular expressions are powerful things!).

All of these great anti-spam features are like having fifty plugins already built-in to WordPress. With them, you can configure a powerful anti-spam strategy for just about any type of site without any plugins — not even Akismet.

Why not just use a bunch of plugins instead?

Because you don’t have to. Plugins require maintenance, frequent updating, etc. Every upgrade of WordPress and/or your plugins opens the door to possible issues and conflicts. Further, plugins consume valuable server resources, affecting the performance and consistency of your site. In general, the fewer plugins you have, the easier and more efficient things are going to be. I guess my feeling is, try to take the “zen” approach as much as possible — if something isn’t absolutely necessary, don’t bother with it. More and more, I am realizing that anti-spam plugins simply aren’t needed to run an effective and spam-free site.

Like the article? Get the book!

© 2009 Digging into WordPress | Permalink | 47 comments | Add to Delicious
Categorized: Plugins, Security | Tagged: comments, spam