The challenge: un-hack their WordPress then login and make sure everything is cool. The FTP part was easy – I just re-installed WordPress’ core files. I could go on here about why its important to keep your WordPress up to date, but I’ve done that before.

Since the person whose blog this is was out of the country, I couldn’t contact them to get a login, and since they were having login troubles anyway due to the hack, we were kind of stuck.

One of the things I like about WordPress is that it’s user-friendly for end-users, but underneath the hood is a pretty serious framework. I’m constantly finding new features, functions and calls to do things I want WordPress to do that it might not ordinarily by default.

In my case, I needed to get a user into WordPress. After some poking around and reading documentation, I found a WordPress function, wp_insert_user, which will put a user into the system. I found you couldn’t just call this from a post or a page, but I found wrapping it in a function, putting it in the functions.php file of the theme and calling it on page_init worked pretty well. Here’s the code:

function ft_insert_user(){
	$newUserData = array (
	   'ID' => '',
	   'user_pass' => wp_generate_password(),
	   'user_login' => 'mike',
	   'user_nicename' => 'mike',
	   'user_url' => '',
	   'user_email' => 'mike@highedwebtech.com',
	   'display_name' => 'Mike',
	   'nickname' => 'Mike',
	   'first_name' => 'Mike',
	   'user_registered' => '2011-10-16 08:54:47',
	   'role' => 'Administrator'
	);

	$newUserId = wp_insert_user( $newUserData );
}
add_action( 'wp_head', 'ft_insert_user' );

The trick with this is I let WordPress generate me a password. I didn’t get a password in my email, but it was easily reset and I was able to login. However, I wasn’t an admin (I’m sure my code about could be better.) After some Googling, I found this PHP script which can be run outside of WordPress (but in your web root) that will assign a specific role to a specific user. This script assumes you know your user ID.

<?php
/*
 * Updates user role using WordPress function wp_update_user.
 *
 * Simple script to be run at webroot. Update user_id and new_role to taste
 * and run as regular PHP file on command line.
 *
 * @package WordPress
 */

require( './wp-load.php' );

// id of user to update
$user_id = 2;

/*
 * Basic list of user roles
 *
 * administrator
 * editor
 * author
 * contributor
 * subscriber
 *
 */

// user role to update to
$new_role = 'administrator';

// update user role using wordpress function
wp_update_user( array ('ID' => $user_id, 'role' => $new_role ) ) ;

?>

Now, I was an admin user and could check the theme and all other settings that are available to administrators, including installing plugins, starting with Better WP Security, developed by higher ed’s own Chris Wiegman.

The thing to remember is that with method, you need to have FTP or shell access to the area that contains the theme or web root. You can’t just use these functions on any WordPress site.

One way is help WordPress (which is built on PHP) and MySQL by caching some expensive queries, that is, queries that return large result sets or you join lots of tables together on certain values. In our case, we’ve installed APC on our dedicated server and are trying it out as a user and opcode cache for some WordPress data to help speed things up. Here’s some ways you can do the same:

On one of our page templates, we query WordPress for a custom post type, in our case a calendar of events. Since some of our sites have many events, this query can take a bit of time to execute. We can help out by storing the result of the MySQL in memory and calling that as needed.  Here’s some code:

$cachequery = "bb_".$blog->ID;
$cacheexpire = 1800;

if($mypost = apc_fetch($cachequery)){
 echo "<!-- cached query -->";
}else{
 $mypost = query_posts($args);
 apc_store($cachequery,$mypost,$cacheexpire);
 echo "<!-- caching this -->";
}

The first we do is declare a variable, $cachequery, which is specificially generated per site, using the blog’s ID and a prefix depending on what template and query we’re using. In our case, the bb_ stands for big button, a template that looks like this.

At this point we also define how long we want this data to be cached. In this case, I say 1800 seconds, which is 30 minutes. This could probably be longer, such as 3600 seconds, but I’m working to find a sweet spot of speed and making sure the user is always seeing good data.

On line 4, you’ll see that we need to do is see if APC and PHP are currently storing any data for our variable. If there is good data, it is stored in the $mypost variable, and we echo a response, which is optional.

If PHP doesn’t a result from APC, the data hasn’t been cached yet. So we run the query, store it in the $mypost variable, and write the value to the APC store. Also, if the data is older than 1800 seconds, APC will return an invalid response and the query will be run fresh. This happens because we set the expiration time in the apc_store function.

APC has a nice PHP page you can install that will give you a report of how APC is doing and what data is being cached. It makes some nice graphs, but also allows you to explore the user-generated data, such as what we cached above. Let’s look at one of our stored variables and what APC is actually caching.

If we view the detail for an entry, we can see what’s being stored, in this case the array that WordPress returns when we use the get_posts or query_posts functions.

I’ve been keeping an eye on WordPress and the APC status for a few days now, and all seems well. I think this is also something I’d look into when building a non-WordPress PHP application as well. Faster is always better.

These types of emails would include account setups, password resets, etc. Since we host our WordPress installation off-campus, somewhere in the tubes between there and our mail system here the mails were being eaten, quite possibly by a large, scary email-eating koala bear. In reality, it was probably an overzealous filter somewhere on our campus end that couldn’t guarantee that emails coming from our Rackspace box to campus really were legit and really were from a University account.

This made creating user accounts very labor intensive. Instead of just emailing login details, password reset requests and more directly to the user, we found ourselves creating an account for a person and immediately resetting their password, and then giving them the login details. Same went for password changes, they were never getting the transactional email to reset their passwords, so they were calling us. Not efficient.

Enter SendGrid. They are one of a few providers of email service, but unlike MailChimp or Constant Contact, they aren’t about the marketing and list management end of emails. They are about providing a delivery gateway to ensure that emails reach their intended destinations with a high degree of reliability.

After setting up an account at SendGrid (look for the free plan at the bottom of this page to try it out. You get 200 emails per day and we’ve never come close to reaching that), SendGrid’s documentation directed us to a page about integrating SendGrid with WordPress.

Using the WP Mail SMTP plugin, we are able to now avoid using the default wp_mail() and PHP mail commands from our server and instead we have our transactional email sent via SendGrid. To keep the admin panel from showing up and potentially confusing users, even admin users, the plugin allows you to put some details in your wp-config.php file. That code looks like this:

define('WPMS_ON', true);
define('WPMS_MAIL_FROM', 'webmaster@gallifrey.edu');
define('WPMS_MAIL_FROM_NAME', 'Gallifrey University CMS');
define('WPMS_MAILER', 'smtp');
define('WPMS_SET_RETURN_PATH', 'false');
define('WPMS_SMTP_HOST', 'smtp.sendgrid.net');
define('WPMS_SMTP_PORT', 587); //
define('WPMS_SSL', '');
define('WPMS_SMTP_AUTH', true);
define('WPMS_SMTP_USER', 'YOURACCOUNTNAME');
define('WPMS_SMTP_PASS', 'YourAccountPasword');

And what do you know, they’re getting through. Our support calls and requests have dropped, and we can focus more of our limited resources on developing great sites and content with our campus partners. Win-win for everyone.

SendGrid isn’t just for these types of emails – it does much more as you can see in this video:

As you dig more into their system, you’ll see they offer email handling, reports and all sorts of other analytics – they don’t just handle transactional email.

So, SendGrid is and will be a part of any web projects for us (and me outside of John Carroll) going forward. It’s just one more thing I won’t have to worry about.

And that, my friends, is a good thing.

We’ve been testing Gravity Forms here as part of our WordPress CMS, allowing users easy access to be able to make forms and manage them right inside WordPress. So far, our tests have been positive, and we’re set to open it up to all our users.

We’ve run into a challenge though as we get ready to roll this out. When set up and turned on in one of our sites (we run multi-site), only administrative users could access and see Gravity Forms.

We set up our campus users as editors, so they can’t go and switch themes and install rogue plugins. Even though the plugin was installed, editors couldn’t see Gravity Forms. They could see all our other functions and custom post types, but not Gravity Forms.

I wrote to their support, who suggested I use yet another plugin. That’s fine if I was just running one site, but at 140 sites and growing, I can’t be spending all day in that plugin turning things on and off. I figured there’d have to be a way to give the editor role access.

Enter some code. It’s one of the things that I really love about WordPress. With a bit of good code, you can do a lot of different things.

I added the following to my functions.php file, making Gravity Forms see that the user role of editor had the correct privileges and could run it. After some trial and error, I found the following snippet of code worked for an editor:

	function add_grav_forms(){
		$role = get_role('editor');
		$role->add_cap('gform_full_access');
	}
	add_action('admin_init','add_grav_forms');

So far, so good. I can make new forms, see entries and more as an editor, and I think I won’t have to manage this with a plugin, which is good to avoid that overhead where possible. Here’s what an editor sees now. The other things (taters, tots, etc) are custom post types we’ve developed.

Each year, we do a “donor honor roll,” or a listing of all the people who gave money to my University in the past year. We’ve transitioned it from a print publication, sometimes inserted as part of our alumni magazine, to a stand-alone web-based site.

Basically, it’s a ton of text broken into pages based on giving levels. Some of the pages are rather short – like those that gave over $50,000. The longest list, unsurprisingly, was our list of people who gave under $1,000. It was near 30,000 words long – which is a LOT of text in one WordPress page.

As a donor to this University (and in the under $1k group), I was able to find myself using WordPress’s built-in search tool. When I went to the full list page, it was blank. Well, our header, sidebars and footer was there, but the actual page content, the stuff being pulled by the the_content() tag, was missing.

It was in the database, but WordPress wasn’t actually displaying it on the page. At all.

After some poking, I discovered that it was too much data for PHP to do any functions/plugin actions on it before it was displayed. I didn’t really want to break it into multiple pages, so I Googled around and found other people having similar problems with very long pages and posts.

The solution: change some PHP settings to up certain buffer sizes. The lines I used were this:

/** Trick for long posts */
ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

Those two lines, placed in either your php.ini file or your wp-config.php file, give PHP a bit more space and power to process large amounts of text and make sure there’s enough room to do all the processing on a post that WordPress has to do.

We host our sites on a dedicated machine, so I’m not sure what, if any, effect this will have on WordPress sites hosted on a shared server. Otherwise, I’d recommend breaking them into multiple pages or posts.

One of the new features in the newer versions of Google Analytics (GA) is the ability to track event actions on a link. This can be not only clicks, in our case, on a button, link or graphic, but you can setup javascript triggers when a user starts, stops or pauses a video, for example.

Setting this up is pretty straightforward. First, you’ll need to add a quick snippet to your GA embed code, if you aren’t already. It’s the trackPageview function. You’ll add it under the line in your GA code where you’re account code is. For example:

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

That will allow you to start tracking events on your pages. To add the event tracking action to a specific element on your page, you add a line of code that looks like this to your a tags.

onClick="_gaq.push(['_trackEvent', 'Videos', 'Play', 'Baby\'s First Birthday']);"

There are three fields there to pay attention to. The first is the category field. In the above example, it’s Videos. You can have multiple categories on a certain page. On our WordPress sites, we’re specifically tracking banners and small image buttons, often on the same page.

The second field is the action variable – which in the example above is Play. For our WordPress pages, we use the term Click. Through javascript and PHP variables, you can make your actions very specific, such as:

_gaq.push(['_trackEvent', 'Videos', 'Play - Mac Chrome');
_gaq.push(['_trackEvent', 'Videos', 'Play - Windows Chrome');

And finally, the label. Above, it's Baby's First Birthday. For our uses, we tailor this to the specific banner or button getting clicked. After a few days, we realized it would also be good to know what site the visitor was on. As with the other fields, this should be tailored to the specific content being clicked on. In the video example, you'd have something like this for different videos being played:

_gaq.push(['_trackEvent', 'Videos', 'Play', 'Gone With the Wind']);
_gaq.push(['_trackEvent', 'Videos', 'Play', 'Huckleberry Finn']);

To our user, our links look like this:

<a href="http://sites.jcu.edu/newsroom/?p=1697" onClick="_gaq.push(['_trackEvent', 'Taters', 'Click', 'Princeton Review Best in the Midwest (Site: JCU Newsroom ID: 1694)']);">
<img src="http://webmedia.jcu.edu/newsroom/files/2011/08/princeton_review-700x230.jpg" alt="Princeton Review Best in the Midwest" />
</a>

In our WordPress templates, it looks like this:

<a href="<?php echo $url; ?>" onClick="_gaq.push(['_trackEvent', 'Taters', 'Click', '<?php echo get_the_title($ID)." (Site: ".get_bloginfo('name')." ID: ".$id.")"; ?>']);">
<img src="<?php echo $img[0]; ?>" alt="<?php echo get_the_title($ID); ?>" />
</a>

We are tracking the individual banner that was clicked on, as well as the site the banner appears on. We add an additional field for our own, the actual ID of the banner asset. We do that just in case we need to find one quickly, or two banners get named the same thing. It’s happened.

That gives us a very nice report in GA that looks like this:

We can very easily filter by a specific site to see what buttons and graphics are getting clicked on. You could also add this to any static link as well, but I’m specifically interested on what specific calls to action are getting noticed by our users.

One of the reasons we selected WordPress was its Word-like interface for working with copy. For our users who had been using Dreamweaver for years, they’ve found it to be an easy transition.

The feedback we were getting is that what they were typing in the visual editor in WordPress wasn’t what they were seeing once when they previewed or saved their pages. They wanted to see actual line spacing, bulleted lists, blockquotes and more look more like what they’ll be like once they are published.

For our users, we want them to not see this:

But see this:

Luckily for us, it’s pretty easy to do this in WordPress. Here’s how:

Create a file in your theme’s main directory called editor-style.css. This is where you will style the HTML elements such as p, a, ul and so on for viewing in the editor. We made sure it matched up with our site’s CSS. Here are a few lines from it:

body, input, textarea, p{
  font-size: 14px;
  line-height: 24px;
 font-family: Helvetica, Arial, sans-serif;
  }

a{
	color: #003969;
  font-weight: bold;
  text-decoration: none;
}

blockquote{
	border: 4px solid #ebefef;
  border-width: 4px 0;
  margin: 0 0 32px -20px;
  font-family: 'MuseoSlab500', Georgia, "Times New Roman", Times, serif;
  padding: 8px 20px 0 40px;
}

blockquote p{
	margin-bottom: 8px;
	font-family: 'MuseoSlab500', Georgia, "Times New Roman", Times, serif;
}

Once that’s saved in your theme’s directory, open your functions.php file. You’ll need to insert this line somewhere in there:

add_editor_style();

Reload your editor and text put in the editor or using TinyMCE’s buttons should be styled correctly. Depending on your site’s CSS, you can add additional tags if you are styling them a certain way, such as hr or img.

Things mentioned:

• Scaling WordPress Site
• @scalingwp
• New Relic
• Pingdom

Want to learn more about WordPress and using it at your institution? Check out this webinar series at HigherEdExperts going on in a few weeks.

I use the Google XML-Sitemap plugin in all my WordPress installations. It’s a great way to tell Google, Yahoo and Bing when my site updates, and for them to easily see what’s new. It’s a nice set-and-forget kind of plugin.

I’ve been noticing something strange on one of my sites lately – the sitemap keeps timing out and producing nothing but a blank screen. That’s never good – so I’ve been digging into the site to suss out the issue.

I think part of the problem is that this particular site has over 2,700 blog posts. Building the sitemap for that site, and including all the tags and categories was killing the process.

My question today is this – should we be limiting the number of items we put in our sitemap.xml file? Should I cut it off at an arbitrary number, such as 25, or leave all 2,700 in there knowing that only the most recent 5 or so posts are the ones I really want Google to see.

Two weeks ago, my VP and I were interviewed by the campus newspaper. They’ve noticed the improvements we’ve been doing and wanted to know more about the process and why these changes were important. The article came out well, which, when you’re dealing with writers at a college paper, isn’t always a given. I should know – I wrote and edited my college newspaper.

The following week, the newspaper ran an positive editorial about the direction the web is taking and why the web is important. It was a nice pat on the back and is helping set expectations as we get ready to roll out a redesign in the new year.

My favorite bit was this editorial cartoon that ran with the story. I lol’d.