Administration Tools

These plugins provide CMS-like functionality to the WordPress Admin area.

• WP-CMS Post Control — Provides complete control over the Write-Page and Write-Post areas of the WordPress Admin. Enables you to hide unwanted items, disable the Flash uploader, kill post revisions, and even add a personal message.
• WP-CMS — Transforms the Admin area to focus more on page creation and less on post creation. Designed to simplify the whole process for your newbie clients. You can even disable the blog functionality entirely.
• Flutter — Enables you to edit posts without leaving the post page and also provides custom write panels that enable further publishing functionality.
• Supple Forms — Enables you to create custom write panels, as well as format and insert values into posts using shortcodes and snippets of HTML.
• Custom Write Panel — Enables you to create additional write panels with customized input fields. Add textboxes, checkboxes, radio-buttons, dropdown menus, and more.
• Pods — Comprehensive CMS functionality, enabling you to create, manage, and display custom content types. Features automatic pagination, public-form filtering, access control, menu editing, and more.

User Role Management

• Members — Comprehensive user-, role-, and content-management plugin that was created to make WordPress a more powerful CMS. Provides more control over your blog with an extensive collection of component-based features.
• s2Member — s2Member provides robust tools for setting up a PayPal-driven membership site, including secure members-only content with custom roles and capabilities.
• Role Scoper — Provides you the ability to specify different permissions levels for different WordPress roles. Also provides options for implementing user groups.
• Disclose-Secret — Enables you to hide specified posts from users unless they meet certain criteria.
• Page Restrict — Enables you to restrict specified pages to logged-in users.

Ordering, Filtering, Limiting and Displaying Content

• AStickyPostOrderER — Enables you to customize post-display order for category views, archive views, and even sitewide.
• Advanced Category Excluder — Provides advanced content separation and category management for WordPress. Exclude any number of categories according to your needs. Also provides control over feeds and search results.
• Custom Post Limits — Provides control over the number of posts that appear on the home page, in various archive views, and in search results.
• Custom Query String Reloaded — Rework of the original plugin, CQS Reloaded controls the number of posts displayed on just about any type of page view, including archives, months, categories, home page, search, and many more. For more information on CQS Reloaded, check out the popout in section 5.1.4.

eCommerce and Shopping Carts

• eShop — Provides shopping-cart functionality that includes customizable product listings, multiple product options, advanced payment options, basic statistics, and more.
• WP e-Commerce — Provides an “elegant and easy to use fully featured shopping cart” that claims to be the “most complete and powerful Shopping Plugin you will find for WordPress.”
• YAK for WordPress — Provides basic shopping-cart functionality that associates products with blog posts.
• Quick Shop — Adds a sidebar widget that displays cart contents to the user and enables easy item removal. Also enables you to easily add products to your posts and pages.
• Cart66 Lite — Shopping cart plugin that enables you to sell digital and/or physical products with a host of useful options. Features include advanced shipping options, custom fields for products, customizable email receipts, Amazon S3 integration, and much more.

Email Mailing List and Newsletter Plugins

• WP-Campaign-Monitor — Email newsletter and SMS functionality enabling users to send campaigns, track results, and manage subscribers. Even includes a plug-n-play sidebar widget.
• PHPList Form Integration — Enables users to easily subscribe to your newsletter or RSS feed from any page on your blog. Designed to work with PHPList, an excellent open-source newsletter manager.
• WordPress Double Opt-In Manager Widget — Enables users to subscribe to your mailing list by way of a double opt-in method that includes the email form and a confirmation email.
• MailChimp — MailChimp is a third-party email newsletter sending service. They have an official plugin to help integrate with WordPress.

Miscellaneous CMS Plugins

• ProjectManager — Manage any number of projects with recurrent datasets. Great for portrait systems, music and DVD collections, and just about anything else imaginable.
• WP-PostRatings — Enables users to rate your post content. Highly customizable. One of the best.
• User Submitted Posts — Enables visitors to submit posts and images from anywhere on your site. User-submitted posts optionally include tags, categories, post title, URL and more.

Using WordPress as a Forum

Although forum functionality is not (yet) built into the WordPress core, implementing a forum on your site is easily accomplished with the help of these awesome plugins.

• bbPress Forum — bbPress is simple, fast, and elegant forum software from the same people who make WordPress. bbPress is focused on web standards, ease of use, ease of integration, and speed.
• Simple:Press Forum, aka Simple Forum — A feature-rich forum plugin for WordPress that fully integrates into your WordPress-powered site. Fully customizable and includes plenty of skins and icons to get you started.

More Forum Plugins

Here are two more useful forum plugins for WordPress, both include great features and look like great forum solutions.

• Tal.ki Embeddable Forums
• Zingiri Forum

What else?

Know of a sweet CMS-related plugin that needs mentioned? Shout it out in the comments to share with the community!

© 2012 Digging into WordPress | Permalink | 32 comments | Add to del.icio.us | Post tags: CMS, plugin, tips, tools

• Pharma Hacked
• Security Lockdown

Pharmaceutical Apocalypse

A few weeks ago, DigWP.com was hit with the so-called Pharma Hack. We discovered the hack after some Google results turned up all sorts of spammy pharmaceutical garbage littered throughout posts, links, and titles. The tricky part about the hack is that it injects the spam garbage only when your site’s pages are requested by a search bot (e.g., googlebot). So when you view your pages in a browser, everything seems perfectly normal. Put simply, the hack is cloaked. We had no idea anything was wrong until about two weeks after the attack. During that time a majority of our search engine results were nuked with evil pharma spam. Ick.

Flash forward three weeks later and things are locked-down tight. The Pharma Hack has not returned, and most of the spam garbage in the search results has been filtered out and replaced with clean pages. At the time of the attack, DigWP was running WordPress 2.9/3.0 without any sort of additional site security. We were just using whatever “default” protection available from either WordPress or Media Temple. After detecting the hack, several days were spent cleaning it up and locking things down. At first, it seemed like an impossible hack to fix – nothing seemed to work. We ran through the following routine, hoping to fix it:

• Locate and remove hacked 404.php file
• Locate and remove hacked content from database
• Replace entire set of salt keys
• Upload new WordPress files
• Restore previous versions of other files
• Restore database to previous version

These actions alleviate the symptoms, but they don’t even touch the actual virus, which somehow regenerates the (base64) encoded spam script. As far as we know, the Pharma Hack works like this:

1. Evil script gains access to your WordPress site
2. Encoded spam script injected into database
3. Script inserts spam garbage into pages requested by search bots
4. Script makes no changes to pages requested by browsers

Within the database, the spam script is generated in any/all of these option_name fields:

• class_generic_support
• widget_generic_support
• wp_check_hash
• ftp_credentials
• rss_[string] e.g.,
rss_7988287cd8f4f531c6b94fbdbc4e1caf

If these fields are present and contain super-long strings of encoded gibberish, your site’s infected. You can assess the damages by examining the search results for your site (note: other spam keywords may be used):

site:digwp.com cipro OR meridia OR cialis

If you’re hit, hopefully you catch it before googlebot crawls along. But even if you have thousands of hacked pages appearing in the search index, it’s not too late to clean things up and secure your site. Here is how we did it..

WordPress Security Lockdown

This security strategy is best implemented on new sites. It just makes everything (like renaming table prefixes) so much easier. Either way, you want to start with a clean batch of files. Upload a fresh copy of WordPress, update your plugins, theme files, and so on. You may want to redirect visitors to a maintenance page while you work on your site. That said, here is our five-step Security Lockdown for WordPress:

1. File Permissions
2. File Protection
3. Database Protection
4. Essential Plugins
5. Important Details

[1] File Permissions

After uploading fresh files, the next step is to ensure proper file permissions. WordPress defaults to 644 for files and 755 permissions for folders. Make sure these are set properly. While cleaning up, we noticed some crazy permission settings for sensitive files. For example, wp-config.php was set to 777 – executable and writable by the entire world!! Make sure you don’t see anything like that, and if you do, fix it.

[2] File Protection

In addition to setting proper file permissions, we can also lock down key files with .htaccess. There are numerous files to protect, perhaps most importantly the wp-config.php file, which contains your database login information. Place the following code in your site’s root .htaccess file to protect it:

# SECURE WP-CONFIG.PHP
<Files wp\-config\.php>
 Order Deny,Allow
 Deny from all
</Files>

You may also want to password-protect your wp-admin directory, but it may cause more trouble than it’s worth.

[3] Database Protection

Changing the default table prefix is one of the best ways to protect your database. Malicious scripts need targets, and default targets are easy to hit. Change wp_ to something more like a password. Some random string like “crUQZPadESeKSy8Q_” will make your tables difficult to hit. Like having a built-in password for your database :)

There are two ways to change your prefixes: the easy way and the hard way. The easy way is to add the following line to your wp-config.php file before installing WordPress (important: change the random string to something unique):

$table_prefix  = 'crUQZPadESeKSy8Q_'; // custom table prefix

Do that before running the install script and WordPress takes care of the prefix naming automagically when it creates the database. Going forward, there is no reason not to change default prefixes for all future WordPress installs. For existing sites, you can do it the hard way using a plugin or doing it manually.

[4] Essential Plugins

After exploring the vast crop of WordPress security plugins, we narrowed it down to four plugins that collectively do just about everything in the easiest way possible:

WP File Monitor

This plugin tracks changes made to your files. If/when anything changes, it notifies you via Admin Dashboard alert and/or email alert. So anytime a file is changed, moved, added, or removed, WP File Monitor lets you know. Here is a list of features:

• Monitors file system for added/deleted/changed files
• Sends email when a change is detected
• Multiple email formats for alerts
• Administration area alert to notify you of changes in case email is not received
• Ability to monitor files for changes based on file hash or timestamp
• Ability to exclude directories from scan
• Site URL included in notification email in case plugin is in use on multiple sites

This is one of my favorite plugins. It’s perfect for keeping an eye on things. If anyone gets in and messes around with your files, you’ll know about it immediately, and even better, you’ll know exactly which files have been affected.

WP Security Scan

This plugin scans your WordPress installation for security vulnerabilities and suggests corrective actions. The scan report informs you of any problems with file permissions, system variables, and much more:

• Passwords
• File permissions
• Database security
• Version hiding
• WordPress admin protection/security
• Removes WP Generator META tag from core code

WP Security Scan also provides a nice summary of server information and latest scan information. Performing a new scan is immediate with the click of a button. Very easy.

Ultimate Security Check

This plugin provides even more security information, helping you to identify potential issues with your WordPress installation. It scans your site for “hundreds of known threats,” and then “grades” your level of site security. Here are some of the key things it checks:

• Checks for updates
• Checks configuration file
• Checks if config file is located in unsecured place
• Checks presence of install script
• Checks server configuration
• Checks database
• Checks code

And quite a bit more. The best part about Ultimate Security Check is that it’s so easy to use.

Secure WordPress

This plugin takes care of all those “little” things. Instead of installing a bunch of smaller plugins or custom functions for this stuff, the Secure WordPress plugin does it all for you:

1. Removes error-information on login-page
2. Adds index.php plugin-directory (virtual)
3. Removes the wp-version, except in admin-area
4. Removes Really Simple Discovery
5. Removes Windows Live Writer
6. Remove core update information for non-admins
7. Remove plugin-update information for non-admins
8. Remove theme-update information for non-admins (only WP 2.8 and higher)
9. Hide wp-version in backend-dashboard for non-admins
10. Block Bad Queries

Having all of this (and much more) done with a few clicks in the WordPress Admin is easy and effective.

[5] Important Details

The previous four steps comprise the majority of our security lockdown, but there are some important details to consider:

• Keep your WordPress install, plugins, themes, and scripts updated with current versions
• Use strong passwords and change them often
• Disable user registration if not needed/used for your site
• Check roles and permissions for all users
• Clean up and consolidate old/loose files
• Remove unused plugins and themes
• Check permissions of upload, upgrade, and backup directories
• Keep a backup of your site files
• Keep your database optimized and backed up

We did these things here at DigWP.com, but certain tips may not apply to every site. As a side note, despite our new security lockdown, I am still concerned/confused about how to handle the upload, upgrade, and backup directories. It seems dangerous to leave these folders set with 777 permissions, and for many shared hosts, that seems to be the required setting. I would be interested in hearing any ideas about securing these directories.

Bottom Line

There is no such thing as perfect security. If someone wants in bad enough, they’re going to find a way, despite your best efforts at staying secure. Fortunately, most malicious scripts target the least common denominator, default WordPress installs. At the very least, ensure proper file permissions, secure wp-config.php, and use unique database prefixes. Together, these three steps will put your site out of reach for a vast majority of malicious scripts and other automated attacks. Of course, there are many other ways to strengthen your site’s security, depending on how far you want to go with it. The lockdown strategy presented in this article provides strong security in the most efficient way possible, but there is always room for improvement, so share your ideas and help the community secure their WordPress.

© 2010 Digging into WordPress | Permalink | 44 comments | Add to del.icio.us | Post tags: database, hacking, plugin

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.

© 2010 Digging into WordPress | Permalink | 13 comments | Add to del.icio.us | Post tags: API, JavaScript, JSON, plugin

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:

© 2010 Digging into WordPress | Permalink | 11 comments | Add to del.icio.us | Post tags: 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.

© 2010 Digging into WordPress | Permalink | 12 comments | Add to del.icio.us | Post tags: plugin, svn

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.

© 2010 Digging into WordPress | Permalink | One comment | Add to del.icio.us | Post tags: 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.

© 2010 Digging into WordPress | Permalink | 26 comments | Add to del.icio.us | Post tags: plugin, SEO

• All visitors will see the current theme
• Only the designer will see the new theme
• All site plugins will work with the new theme
• Smooth transition between old and new theme at launch

These are the main concerns, but there are a few other details that need addressed to ensure smooth theme development on a live site. Let’s take a look at how to achieve these goals and effectively develop themes behind the scenes..

You need a plugin

The easiest way to develop a new theme behind the scenes is to install a good theme-switcher plugin. There are plenty available:

• Theme Switcher
• Theme Switcher Reloaded
• Alternative Theme Switcher
• Theme Preview
• Theme Test Drive
• NK Theme Switch

Any of these plugins will work fine for the purposes of working with multiple themes on your site. If you also plan on enabling your visitors to switch themes, I would have to recommend the newer NK Theme Switch plugin. NK Theme Switch does everything the other plugins can do, but with the added bonus that it redirects users back to the page from which they came after switching themes. The other two plugins switch themes, but the user is always redirected back to the home page after the theme switch.

Note that, for the different theme-switcher plugins, the URLs used when switching themes include different query-string parameters that are similar but not interchangeable. Once you implement a theme switcher, replacing it with a different plugin is going to be difficult.

In any case, once you have your theme-switcher plugin of choice activated, you’re going to need to know how to actually switch the themes..

Switching themes

Different plugins involve different methods of switching to a different theme. If you are using NK Theme Switch, you can select and activate your alternate (development) theme from within the WordPress Admin. This is the easiest way to do it. If you are using one of the other theme-switching plugins, activating the alternate theme for your browser is as easy as entering a specific URL into the address bar. These theme-switching URLs look similar for either of the first two plugins:

http://domain.tld/index.php?wptheme=ThemeName

For example, here is the URL used to switch to one of my favorite themes at Perishable Press:

http://perishablepress.com/press/index.php?wptheme=Perishable

The syntax here is straightforward — the only thing that needs to be changed is the theme name, which in this case is “Perishable”. When developing a new theme for Perishable Press, I simply jot down the theme-switch URL for both the new theme and the active default theme. This makes jumping back and forth very easy. Of course, the general format of these URLs will vary depending on the particular theme-switching plugin that you use.

Another option for switching between current and alternate themes is to actually include the theme-switching links and/or dropdown menu right there on the theme pages themselves. For example, including the theme-switch dropdown menu in the footer of all your themes is a great way to speed up and simplify the development process. But be advised, unless you explicitly exclude your new theme from the theme-switch menu, it will be available for all of your visitors to see and activate. The other method of just using the URL directly is a good way to ensure privacy.

Now that you are setup and easily switching between themes, there are a few other points to consider..

Your new theme is just another theme

This may sound strange, but there is nothing special about your new theme — it’s treated by WordPress as any other theme in your “themes” directory. All of the requirements of the default theme apply:

• Your new theme needs a properly configured style.css file
• Your new theme needs a working index.php file

Assuming your new theme meets these basic requirements, WordPress will recognize your theme as such and display it when activated (either through the Admin or via theme-switch plugin). Incidentally, the name of your theme is specified via the style.css file. The “Theme Name” that is listed here will be the same one used in your theme-switching URLs.

Once you get the basics of your new theme established, use your theme-switching plugin to activate it locally in your browser. Form there, you can rock the design however you want, exactly as you would do when starting from a fresh installation of WordPress. While you are working on your new theme, your visitors will still be seeing your default active theme, which is whatever you specify in the WordPress Admin. This is why the theme-switch development method works so well.

Pages, plugins, and custom functions

Here are a few more little things that will help you when developing your themes behind the scenes..

Plugins affect all themes

Even when your theme is not set as the current default, it will still be affected by all of the plugins installed on your site. This is one of the benefits of using plugins over custom functions..

Custom functions only affect the theme being used

In contrast to plugins, custom functions (i.e., functions placed in your theme’s functions.php file) only affect the current theme being viewed. If you seem to missing some functionality in your “behind-the-scenes” theme, make sure that you have properly transferred any required custom functions.

Page templates will confuse you

This happens to everyone: you are working behind the scenes on a new theme and you can’t seem to get a custom page template to appear in the WordPress Admin. This is because the page editor only shows the templates available to the current default active theme (i.e., the one that everyone sees). To work around this, you can either upload a copy of the custom page template to the active theme, or temporarily switch the default active theme to your behind-the-scenes theme. Personally, I use the former method and just delete the page template if it’s not needed in the default theme.

And last but not least..

Prepare for launch!

Once you have your new theme pimped out and ready to go, simply change your default active theme in the WordPress Admin to launch it for the world see. That’s all there is to it! :)

© 2009 Digging into WordPress | Permalink | 27 comments | Add to del.icio.us | Post tags: plugin, theme-switch, tips

In any case, the Feed Count plugin is too awesome to let disappear into the ether, so it will be hosted here at Digging into WordPress until Francesco’s site checks into a rehab center and cleans itself up. Hopefully that will be sometime soon. In the meantime, to download a squeaky-clean copy of the Feed Count plugin, simply click on the title of this post.

Direct Link to Article — Permalink on DiW

© 2009 Digging into WordPress | Permalink | No comment | Add to del.icio.us | Post tags: plugin

Subtitle

I think it would be a cool format for a blog to have a title and a subtitle for every single Post. You could easily do it with Custom Fields, but this plugin would alter the Admin screen for writing posts to insert an additional text area underneath the title and above the content area.

Then there would be a special function for displaying the subtitle like:

<?php the_subtitle(); ?>

Rich Text Titles

Speaking of titles, it would be cool if we were able to use HTML tags in titles sometimes. For example, just being able to add <em> tags to a word in the title would be cool, but that causes problems currently. It might display OK on your site, but it may cause validation problems (since the tags will show up inside title attributes and such) and may come across screwed up in feed readers. This plugin would alter the the_title() function to automatically strip the HTML tags, but create a new function like the_title_html() that would retain the tags for display anywhere you want to make sure they persist. This would ensure the RSS feed remains unscathed.

Plugin Notes

Ever look through your list of plugins and forget just exactly what one of them does? I know they have descriptions next to them, but that doesn’t always speak to exactly what you are using it for and why. This plugin would just put a text field in each plugin field you could type some notes in there, theoretically to keep information about why and how you are using this plugin.

You’d probably have to also add buttons/links for adding & removing notes.

Notify All Admins

On this blog we have two admins: me and Jeff. When I write and publish a post, and someone comments, I get an email about it (but Jeff doesn’t). When Jeff writes and publishes a post, and someone comments, he gets an email about it (but I don’t). Since this is both of our sites, I wouldn’t mind getting ALL comment notifications. But I’m not sure if Jeff feels the same way. So this plugin would just add an extra user option (only active for full site admins):

Title Un-Widower

There is a pretty robust plugin called WP-Typography that covers widows in post titles. I give it props, but my personal preference is to handle 90% of what it does on my own. What I can’t do on my own is add non-breaking spaces to the last two words in a post title (one of the things it does). I currently do this with jQuery on some sites which is OK, but would be better done with PHP so it happens before the page renders no matter what.

So if there are already plugins out there that do this stuff, I apologize. I admit I didn’t launch a giant manhunt to find existing plugins that did these things.

© 2009 Digging into WordPress | Permalink | 27 comments | Add to del.icio.us | Post tags: hacking, plugin, title