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.

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.

Let’s flash back and get a bit of a primer on passwords and password storage:

“…when storing passwords for your app, you have a many options. You could skip all security and store your users’ passwords in plain text in MySQL. Bad idea.”

This site is hosted at MediaTemple, and for the last few months since I migrated from Dreamhost to MT, I’ve had no problems or issues. Then, last Wednesday night they sent me an email saying I should change my account manager password as my account had seen some strange activity. Never an email you want to get. It said:

Dear Valued Customer,

This is an automated notice informing you that our system has reset your Server Administrator FTP/SSH password due to suspicious activity observed on your (gs) Grid-Service. Our systems have taken measures to protect your service from any possible future exploits.

Even though I was on my way to bed at the time, I logged back on and set off to figure it out.

My fist step was to FTP into my machine and check all the WordPress blogs I run from my (gs) service. It looked ok, and I eventually did find an injection in a static site (not WordPress.) Kind of odd, but not out of the ordinary.

Here’s where things get interesting.

I checked Twitter’s search and I quickly found I wasn’t the only one getting security notices from MediaTemple. Many people were and were understandably upset.

As the day wore on yesterday, news came out that MediaTemple was storing user passwords in plain, clear text in their databases. Seriously. Their database was compromised, which in turn compromised many, many customer accounts, including mine. MediaTemple had this to say:

“Clear Text” is a method of storing passwords in a database so that they are human readable. This preference was made to provide customers a convenient way of managing access to their services, e.g. connecting a PHP app to MySQL. The “clear text” method can be less-secure than methods involving “encryption”, where passwords are not human-readable. This is less convenient for customers, but adds a layer of security. Properly secured databases can store passwords using either method, with the information kept private. However, if a database gets compromised, the encryption method is the only way to keep the information secure. (mt) Media Temple has now changed to the encryption method for customers, which now breaks some AccountCenter functionality; however, it is more secure and ultimately what our customers now want.

The interesting phrase there is “what our customers now want.” Of course they want this after they’ve all been hacked. Securely storing passwords should have been happening from day number one. Always. No exceptions.

So, MT is doing damage control and to their credit have been on Twitter since this all started, but the damage is done and the customer relationships have been strained.

There are lessons here to be learned, not just by web developers but by anyone that uses a website that stores a username and password, which is pretty much all of them.

1. Don’t store passwords in clear text. Ever. There are a myriad of ways to encrypt and store passwords. Go and read this blog post for specific methods.

2. When a password needs reset, use email and a unique token to reset the password. Email the user and make them click on a link to verify its them.

3. If you are a user, and you are using a site that will show you your password in a “my account” area or in their administrative control panel means they are not storing your password securely. If you have credit card information stored there, good luck.

4. Use strong passwords. password is not a strong password. This is a strong password:

B;8(,4$n#

That was generated by this online strong password generator. I use it when creating any type of accounts, especially for my campus users. This could be antyhing ranging from MySQL to WordPress user accounts.

Want to get even crazier? Use an ultra secure password. Check out this one I randomly generated:

|[<;0Rw|t>Ir[Qh|?E|M]K#JPjz?`wIY_H1K=?fs}Cb@(5$PeP4h"F)%4P9I?3i

Passwords like that I prefer for servers and other very sensitive information. Want to generate one like that? Use this site. I now have a 63 character login for my MediaTemple account, just to be safe.

5. If you are a MediaTemple (gs) customer, and you haven’t yet checked out your sites, I’d highly recommend you do so now.

Additional Reading about the MediaTemple events:

• Michael Torbert
• DigWP
• Jeffrey Barke

My ideas about this are two-fold. One, look for open-source solutions. Second, look for web services that can fit a need. They are often very low-cost, or better yet, free.

Open Source

There are many open source products that we web developers can use to solve problems and get things done. You may already be using many of these technologies already.

Your web site is probably served by Apache. Maybe you code web apps in PHP, and use MySQL for databases. Maybe you code in Ruby on Rails. All these are open source products with great communities of developers.

Looking for a blogging platform? WordPress is a great, free platform you can build all sorts of sites on top of.

Need a CMS? Plenty of options there, including the aforementioned WordPress, Joomla, Drupal, Typo and many, many more.

Can’t get budget monies for that Adobe CS4 upgrade? Check out the Gimp, an open-source image processing tool. Want to do 3-D modeling? Check out Blender.

Web Services

Don’t forget there are many great web services you can use that will help you save time and money.

Our career services team wanted a custom calendar for all their recruiting events. We didn’t have the time to build or customize a calendar application, so we looked to Google’s Calendar product. Now, career services staff and students enter events into an online calendar and we take that and embed it one of their web pages. Google Calendar also allows users to subscribe to the calendar by RSS, Google Cal or iCal. It’s a great solution that was very quick for us to set up and we don’t have to spend a lot of time maintaining it.

Want to build a quick form? Try Wufoo’s free plan.

Use Flickr’s free account to post photos. Put videos for free on YouTube. Want to get suggestions and recommendations from your visitors? Try UserVoice’s free plan. Get free stats from Google Analytics.

As you can see, there are a ton of options and hopefully the lack of budget monies won’t keep you from creating great sites and web apps.

If you had an extra seat or needed a ride somewhere, you could post a note and hopefully meet up and share the expenses and pass the time.

Post renovation, the rideboard was gone, and they missed it. So, we came up with the idea to do an online version. Using PHP, the Google Maps API and a bit of RSS, I think we came up with a pretty good solution. The bulk of the coding on this was done by students working for me at the time.

If you click on that image, you’ll get a larger version where you can see the detail a little better. Since the site is limited to on-campus IP addresses, you can’t see the real thing.

Once you click on a pushpin, you’re taken to a detail page of that city, and the rides needed and being offered to that place. Signing up is simple – just a few fields of information are asked, since we know only students of our college will be using this page. The student gets an email right away with a link and code to approve their listing, and once they do it’s live. The code also works if they need to amend their listing, such as the number of seats available. Honestly, I haven’t had to touch this app in a long time since it’s coded to take care of itself.

Is anyone interested in the code for use on their campuses? I think we could open source it if a few people are interested. It would be our little attempt to be a bit greener. Let me know what you think.

I think I’ve mentioned it here before, but if you’re not running the Automatic Upgrade plugin, stop and add it to the top of your to-do list. True to it’s name, the plugin does all the work of updating your WordPress install with just a series of clicks. This is especially useful for users who may be afraid of uploading a bunch of files or perhaps don’t have FTP access to their blog.

From a technical perspective, the plugin does a lot of nice things on the system side. First, it gives you zip files containing your content and database backups. It’s more a just-in-case thing, but nice to have. Then, it puts your blog into a maintenance mode. That way, people aren’t leaving comments or trying to log in during the upgrade. It will also de-activate your plugins, again, to reduce the possible errors that may pop up. The plugin then gets new files from WordPress directly, updates your install, turns everything back on and asks you to clean up the cruft leftover.

Upgrading today took 3 minutes, which is a small price to pay to make sure your install is safe and secure.