After almost 4 years building the BU CMS on WordPress MultiSite, the BU WebTeam, which consists of staff from IS&T and Interactive Design, has decided to release some of our plugins to the broader WordPress community. The first two plugins planned for release tackle some of the workflow limitations that content editors have been asking us to address for a few years.

The Problem

The BU CMS contains quite a few large websites. In most cases, the bulk of the content comprises of pages (the “page” post_type), so a significant percentage of the day-to-day content modifications are updates to published content. Unfortunately, WordPress does not provide any controls for restricting the editing of published content or limiting what content a particular user is allowed to publish, so if a user has the capability to edit one page, they can edit all pages. For sites that have more than 50 editors and over 1,000 pages, the primary site administrators worry that ill-advised changes will be made to prominent content by an editor with less experience or without the authority to make the change. In addition to cracking that nut, we wanted to provide a mechanism for staging an edit to a published page so that the change could be worked on directly (with its own revision history), reviewed, previewed, and scheduled for publication.

After reviewing some of the existing plugins that provide this sort of functionality, we decided to write two plugins to address these problems. Both plugins will be released under the GPL.

Design Goals

• Blend naturally into the existing WordPress admin UI
• Simple to use
• Manage permissions with a full view of all post content
• Perform well on sites with more than 2,000 pages
• Support custom post types

BU Section Editing

The BU Section Editing plugin creates a new role: Section Editor and adds screens for managing groups of Section Editors. Each group is granted access to publish and edit published content for individual pages.

BU Versions

The BU Versions plugin adds functionality for creating an alternate version of pages, posts, or any public custom post type. After cloning the post, editors are able to make and preview changes. When the changes are ready to be published, the user simply clicks “Replace Original” or schedules the replacement. Users that do not have the “publish_posts” capability are able to create and edit an alternate version, which makes an edit, review, then publish workflow possible even when modifying published posts.

We really want to get feedback from other folks using WordPress on large sites, so don’t hesitate to leave a comment on the original post.

Boston University is hosting WordCamp Boston again this year, and I will be giving a talk. I am particularly excited to share some of the plugins that BU has been developing with the broader WordPress community.  Below is the description:

WordPress includes a well-defined workflow for running a blog with multiple contributors in various roles. It works great; But what if you are using WordPress to run a 1,000 page hierarchical site? Well… the workflows available are a bit limited without getting under the hood. For example, WordPress does not define fine-grained capabilities for controlling who can edit published content. As a result, users have to be granted full editing permissions, which increases the chance that a less-experienced user will make an ill-advised change. Drawing from our experience running large Multisite installations, Boston University has developed a couple of plugins to address some of the limitations. And for the first time, we are planning to release our plugins to the broader WordPress community under the GPL.

This talk will include an overview of the role/capability system presented from both a user and developer perspective as well as overviews of the BU Versions and BU Section Editing plugins. Along the way, various insights will be shared that provide a window into how BU has built an effective content management system on top of WordPress.

For more information, visit the WordCamp Boston 2012 website.

Description

For basic content publishing needs, the ease-of-use of WordPress shines. Unfortunately, once a project exceeds 500 pages, using WordPress is much less straightforward. How has Boston University made it work? From a technical standpoint, building relationships between content objects and creating simple to use UIs for managing the relationships is key. Once established, the semantic relationships can be coupled with bits of meta data to construct menus, indexes, facets, filters, and so much more. Using code examples, this talk will highlight essential parts of the WordPress API and demonstrate various techniques used in BU plugins and themes that help us build better large websites.

The slides from the presentation and a link to code for the proof-of-concept are below:

• slides (slideshare)
• code (github)

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

Read Matt’s full post…

The default sshd configuration pulls the port information from /etc/services and sets up a listener on that port. The Sockets dictionary is used to let launchd know when to launch the service. The purpose of this system is to speed up the boot process by launching services on demand instead of automatically.

To change the sshd port as means of provide some additional security simply modify /System/Library/LaunchDaemons/ssh.plist and change SockServiceName from “ssh” to the port number you want sshd to use. You also have to modify the Port number in /etc/sshd_config to match the launchd configuration.

<key>Sockets</key>
 <dict>
 <key>Listeners</key>
 <dict>
 <key>SockServiceName</key>
 <string>40000</string>
 <key>Bonjour</key>
 <array>
 <string>ssh</string>
 <string>sftp-ssh</string>
 </array>
 </dict>
 </dict>

Actions/Filters Presentation (pdf)

Modern Posts Widget (github)

Updated: The video is now online.

The Problem

Shared PHP hosting requires a careful system admin. In a typical mod_php Apache httpd installation, all virtual hosts share the same Apache instance running with the same permissions. Unless special precautions have been taken, any PHP file can read/write/execute any file that the Apache process has permission to read/write/execute. Deploying in this situation means that you must trust all of your neighbors.

Over the last week, I tested three managed WordPress hosts. How did they fare? Not, good. Two hosts with a good reputation in the community have serious vulnerabilities. The vulnerabilities are severe enough that I could easily manipulate the data of an adjacent installation.

How do you know if your host is vulnerable?

Below is a script borrowed from phpsec.org:

<?php

echo "<h3>Current directory:" . dirname(__FILE__) . "</h3>\n";

echo "<pre>\n";

if (ini_get('safe_mode'))
{
    echo "[safe_mode enabled]\n\n";
}
else
{
    echo "[safe_mode disabled]\n\n";
}

if (isset($_GET['dir']))
{
    echo "<h4>Scanning: " . htmlentities($_GET['dir']) . " </h4>\n";
    ls($_GET['dir']);
}
elseif (isset($_GET['file']))
{
    cat($_GET['file']);
}
else
{
    echo "<h4>Scanning: / </h4>\n";
    ls('/');
}

echo "</pre>\n";

function ls($dir)
{
    $handle = dir($dir);

    while ($filename = $handle->read())
    {
        $size = filesize("$dir$filename");

        if (is_dir("$dir$filename"))
        {
            if (is_readable("$dir$filename"))
            {
                $line = str_pad($size, 15);
                $line .= "<a href=\"{$_SERVER['PHP_SELF']}?dir=$dir$filename/\">$filename/</a>";
		if(is_writable("$dir$filename"))
		{
			$line .= " (writable)";
		}
            }
            else
            {
                $line = str_pad($size, 15);
                $line .= "$filename/";
            }
        }
        else
        {
            if (is_readable("$dir$filename"))
            {
                $line = str_pad($size, 15);
                $line .= "<a href=\"{$_SERVER['PHP_SELF']}?file=$dir$filename\">$filename</a>";
		if(is_writable("$dir$filename"))
		{
			$line .= " (writable)";
		}

            }
            else
            {
                $line = str_pad($size, 15);
                $line .= $filename;
            }
        }

        echo "$line\n";
    }

    $handle->close();
}

function cat($file)
{
    ob_start();
    readfile($file);
    $contents = ob_get_contents();
    ob_clean();
    echo htmlentities($contents);

    return true;
}

?>

1. Copy the code to your favorite editor, save as dir-scan.php, and upload to the root of your web directory.
2. Visit the page by going to http://hostname.com/dir-scan.php
3. When the page loads, you will see the current directory, whether safe_mode is active, and listing of the files/directories in “/”. If no files are listed that is good.
4. To view a specific directory, go to http://hostname.com/dir-scan.php?dir=/var/www/path.

1. Download the source code for svn_load_dirs.

svn co http://svn.apache.org/repos/asf/subversion/tags/1.6.6/contrib/client-side/svn_load_dirs svn_load_dirs

2. Move svn_load_dirs.pl.in to a bin directory and rename to svn_load_dirs.pl.

mv svn_load_dirs/svn_load_dirs.pl.in ~/bin/svn_load_dirs.pl

3. Because we will not be building subversion from source, we need to edit the script and replace

my $svn = '@SVN_BINDIR@/svn';

with

 my $svn = '/usr/bin/svn';

For the more experienced sysadmin/developer that uses more sophisticated hosting (VPS, dedicated server, or even shared hosting with cron support) there is another option: using cron to execute wp-cron.php. First, wp-cron needs to be disabled in the configuration section of wp-config.php.

define('DISABLE_WP_CRON', true);

Then, simply request wp-cron.php directly using cron. For more information on cron, the Wikipedia article is a good starting point.

To edit a user’s crontab, log into the server via ssh and issue the following:

$> crontab -e

If you don’t use ssh often, you may also need to set the $EDITOR environment variable to an editor that you are comfortable using (e.g. vim, emacs, nano, pico, etc…).

There are two different approaches that can be used to execute wp-cron.php.

1. Use wget or curl to issue a HTTP request for wp-cron.php

*/30 * * * * wget http://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

2. Write a small wrapper script to setup the environment and execute wp-cron.php directly.

*/30 * * * * /usr/bin/php /var/cron-scripts/run-wp-cron.php /dev/null 2>&1

<?php
chdir('/var/www'); // WordPress install DocumentRoot
include('wp-cron.php');
?>

In both examples, ‘/dev/null 2>&1′ is used to send both stdout and stderr to /dev/null which discards any output and errors. By default, cron will send an email to the email address defined for the user.