Jason was on WPwatercooler again. Summary.

The WPwatercooler is a great show, and I was on it again this past Monday with my BWAwWP co-author Brian Messenlehner. I may make it a habit to get on that show. And I may make it a habit to follow up each show with a summary of what went down.

The show topic was How do I make sure I don’t have to re-do my website just months after it’s done?

The consensus was that you can’t make a website that won’t require updates. But you can do a few things to prepare for future updates and minimize their impact:

  • Make sure you are using a good developer. Good developers will do things “the WordPress way” (e.g. using hooks and filters instead of hacking plugins), which will be less likely to be broken by plugin and core updates.
  • Make sure you are using a good designer. Good designers will simplify things and use proven methods that are less likely to be broken by software and browser updates.
  • Make sure your website has a purpose other than looking pretty. One year after your website goes live, it will probably be out of style… at least a little bit. But if you built a website that encourages people to call your sales phone number, it will still do that no matter what the design trends are.
  • Make sure you have a maintenance plan. In addition to having someone on call to perform WordPress upgrades, have a developer on retainer or on call to fix things if anything goes wrong.

We need to do a better job of communicating with our clients about what role maintenance will play in their website. There were a few analogies thrown around on the show (websites are like babies?). My favorite was to think about your website like a car bought on lease (get regular oil changes and be ready to trade it in every 2-3 years) instead of a used car you buy and run into the ground.

Jason was on WPwatercooler again. Summary. was last updated on August 7, 2013. Bookmark the permalink.

Heartbeat API for WordPress

As part of the JavaScript chapter for our upcoming book Building Web Apps with WordPress, I got a chance to research and work with the Heartbeat API that is new to WordPress 3.6.

It’s a cool little piece of functionality that will help out developers building asynchronous apps on top of WordPress.

At first, I didn’t see the need for it. (It’s not too hard for developers to create their own script to poll the server every few seconds.) But I soon realized why an API like this would be useful. If  you have 5 different plugins all with their own server polling, you are going to have 5 different hits to your server every 15 seconds. However, if they all piggyback on the Heartbeat API, those polling requests are going to be bundled so you are only hitting your server 1 time every 15 seconds. There are other benefits, but that’s the big one to me.

For people trying to get started with the Heartbeat API, I put together this nice little minimal example that you can use as a starting point. The script below simply sends the message “marco” from the client and then detects this on the server and sends back “polo”. The messages are logged in the JavaScript console (so if you inspect elements and click on the console tab in Chrome you will see them). You should be able to easily tweak this to send requests like “how many members are logged in?” and send back a number, etc.

Let me know if you have any questions about the API and I’ll try to address them.

Heartbeat API for WordPress was last updated on August 7, 2013. Bookmark the permalink.

Continuing the WPWatercooler Discussion on Rapid WP Core Development

In his 2013 State of the Word Speech, Matt Mullenweg shared his plans to release two major versions of WordPress later this year in addition to 3.6 coming out this week and to generally increase the rate of WordPress updates. We discussed this a bit on the WPWatercooler today, but there wasn’t really time to get into things.

The discussion (argument?) went something like this: (paraphrasing here)

Scott Bolinger: The WP survey reported back that the two worst things about WordPress were updates and plugins. And Matt’s State of the Word Speech was basically a call for more updates and plugins.

Chris Lema: It’s really annoying and costs a lot of money to retrain people when WordPress is updated, especially in the enterprise.

Jason Coleman: You’re whining.

Chris Lema: Of course updates are easy for you, you bleed blue WordPress blood. You need to be able to relate to end users who are confused by UI updates, etc.

And that’s about where we left it before moving on to the next topic. If I had time, I would have continued on like this…

First, I do understand the end user’s perspective. I have to do these updates for clients, answer the support calls, and sometimes retrain them. I used to be in the Chris Lema camp and thought WordPress was needlessly updating their UI too fast. I mean, I thought the change in version 3.3 to hide submenus in the dashboard behind flyouts was a big big deal. But that’s nothing compared to the potential change between the current version of the WP dashboard and this mockup of how things might look under the new “MP6” dashboard UI.

mp6_screenshot mp6_screenshot2

I’ve since changed my mind. Here are a few arguments for faster WordPress updates.

  1. What’s the alternative? Slow down? Have fewer updates? I don’t think Chris’ enterprise clients would like that option. WordPress needs to iterate to stay relevant. If WordPress gets stale, we’ll stop using it to build cool stuff.
  2. Things aren’t even changing that fast. That flyout menu feature was added in version 3.3 back in December 2011. Since then, the media library update was the only big UI change which happened earlier this year. An MP6-like update to the WordPress UI possibly (possibly) happening by the end of this year will be a big change, but then so is the jump from Microsoft Office 2010 to Office 2013. Enterprise should be ready for these kinds of things.
  3. What about new users? Sure existing users are disrupted when the UI updates. But if the changes are meant to make WordPress easier to use, it will make training new clients easier. I use a similar argument all the time with clients: sometimes you can’t worry about the few existing users you have and need to instead focus on the many future users you want to have.
  4. Finally, faster updates should encourage some changes that will make things easier for enterprise users. Things like automatic minor version updates or a better decoupling of the admin UI to the underlying WordPress framework are a bigger focus of WP development right now. I think the updates in these areas will make up for the inconvenience of a larger number of core updates.

I really mean for this to be a continuation of the discussion we started on the show. So I look forward to feedback and counterarguments in the comments below. Why am I wrong?

Update: Chris Lema has posted a reply on his blog.

Continuing the WPWatercooler Discussion on Rapid WP Core Development was last updated on July 29, 2013. Bookmark the permalink.

WordPress as an Application Framework

I wrote a comment over on Justin Tallant’s blog post titled WordPress is not an application framework. My comment got pretty long, so I figured I would also post it here. You should read Justin’s post first. He ends by asking “What do you think? Is WordPress heading in the right direction with the goal of being a Web Application framework, or should they focus on being a blogging platform and CMS?”

My Comment:

WordPress is heading in the right direction. Matt’s goal is to have WordPress used for EVERY “website” on the Internet. Our Internet use is moving away from sites to apps, and allowing more apps to be created more easily with WordPress is a good move.

It’s not just a good business move for those of us with interests in having WordPress used more often. There is something fundamental about WordPress that makes it popular and useful for people wanting to setup sites quickly with the flexibility to extend those sites later.

When you say “it’s a blogging platform that can work well as a CMS”, you are understating WordPress as a CMS. It’s the most popular CMS platform in use*. There must be some reason for that, no?

* http://w3techs.com/technologies/overview/content_management/all

This wasn’t always the case. Matt and the WP community made CMS functionality a priority and CMS use went from a fraction of a % to the 50%+ market share it has now.

This is why people may say you are short sited to think that WP can’t take over framework market share just because they are behind right now. We remember when people said the same thing about WP as a CMS… or hell WP as a blogging platform.

You can already think of WordPress as an application framework with some very successful apps running on top of it: WordPress blogs, CMS, ecommerce sites, membership sites, forums. It already works well for building custom apps and can be improved on in that area without being detrimental to the existing blog and CMS functionality.

The secret sauce of WordPress is not the UI or blogging feature set… it’s the plugin architecture, platform stability, and community.

MVC, REST, and database migration support are not requirements for building apps. MVC is a useful way to organize things, but not the only way. The theme/plugin paradigm works great for separating design concerns from programming concerns. I am a little bit removed from using other frameworks, but I know that I can easily build RESTful APIs and migrate databases with WordPress.

The way that WordPress really shines as an application framework is if you think in a “Lean Startup” kind of way. With WordPress you can start with a minimum viable product and incrementally develop it into a full blown application using the same platform the whole way. Something like:

  1. Simple one pager built in WordPress, using an existing theme, to announce the concept of your app.
  2. Add a blog to discuss development, etc.
  3. Use Paid Memberships Pro and free levels to get people to sign up for the beta release (gathering emails).
  4. Use plugins to integrate with MailChimp to start emailing the mailing list.
  5. Combine existing plugins and simple content to develop a wireframe or proof of concept.
  6. Create a custom plugin to house your beta app classes, logic, and customizations.
  7. Create a custom theme for your branding.
  8. Use Paid Memberships Pro (see a pattern here? 😉 to accept paying customers.
  9. Re-factor your plugin/app for a version 1 release.
  10. Use plugins for forums, social integration, analytics, caching, SEO, third party integrations.
  11. Scale your system at the server level. Rewrite individual bottle necks in lower level PHP when it helps.
  12. Rinse and repeat for version 2.

The beauty is that all along the way your app always has the same user base and underlying infrastructure. Your gathered emails become users then become paying customers. You can quickly add and test new features. You can use the same WordPress developers throughout the entire process and if you business pivots at steps 2-6, you didn’t waste time or money building a full blown app.

I’m excited to continue this discussion over the next couple years. 🙂 Pointing out how WordPress lacks as a framework is important to improving its functionality and use that way. What may look like insurmountable shortcomings to you are just challenges to be overcome by me.

I think your prediction that WordPress can’t “catch up” feature-wise and your fears that “WordPress will become a Molotov cocktail of code” as we try to build out WordPress as a framework are wrong. The WordPress core team has shown their ability to push updates that pretty successfully juggle new features with reverse compatibility and clean code.

There are advantages to having a platform built with applications in mind from the get go. There are also advantages to having a platform that is scrappy, accessible, and practical.

WordPress as an Application Framework was last updated on January 11, 2013. Bookmark the permalink.

Don’t Break The Code

Last Saturday at WordCamp Philly, I ran a session on “Building a Plugin in One Night”. Together, with about 50+ attendees, we brainstormed ideas for a new WordPress plugin that I could code that night.

The brainstorming went great, coming up with some good ideas… like plugins to:

  • Help first responders after a disaster (Big Idea!)
  • Add VIM (a Linux editor) shortcut commands to the Visual Editor
  • Disable the Visual Editor on a per-post basis (The Winner)
  • Allow users to create pages from the front end
  • Add easy donations
  • Log into WordPress via Google+ (Brian did it!)
  • Add syntax highlighting to the Visual Editor (Chris did it!)

The concept that the audience voted for me to work on was a way to disable the Visual Editor tab on a per-post basis. The motivation for this is the fact that the autoformatting of the Visual tab will sometimes break a complicated (or not so complicated) HTML structure ruining your code. Folks wanted a way to say, “Hey, WordPress, back off on this page/post.”

And someone (you introduced yourself to me later, but I forget your name) came up with a kick ass name: Don’t Break the Code. It explains the purpose and also harkens back to my days at Haverford College, which has a strong social/academic honor code.

I had hoped for something a little more mainstream. Only a developer or power user will really appreciate a plugin to disable the Visual tab, but that’s okay. The effort would be appreciated.

Turns out there are already a few plugins that either disable the Visual tab or remove other filters to keep WordPress from breaking code. The started trickling in after the presentation wrapped:

… and probably a few more. So we weren’t blazing new ground.

Still, some good ideas came up during the session that could improve the experience of using a plugin like this. Like:

  • Put the checkbox to disable the editor in the screen options area so it doesn’t clutter up the editor
  • Only allow admins to disable the editor. Other roles will see what the admin chose.
  • Allow admins to add a note RE why the Visual Editor is disable.
  • Remove other filters (like wpautop) to lower interference even more.

I spent the spare time I had during that day and then after the after party from midnight to 5:30am the next morning looking through the code in the existing plugins and piecing together the best pieces of them. I liked how “Disable Visual Editor WYSIWYG” just grayed out and struckthrough the Visual tab instead of removing it directly. I liked how Raw HTML put things in the screen options space and also how they allowed for disabling the other filters.

Anyway, the plugin released that morning on GitHub and then later at the Dev Day to the WP repository. You can grab it here:

Don’t Break the Code WordPress Plugin

So far it allows admins to disable the Visual Tab just like we said. I improved on the DVE WYSIWYG plugin by disabling via Ajax for a better user experience (you don’t have to click update for it to take affect). And after trying to copy Raw HTML’s method of placing things in the screen options, decided to scratch that and just code it myself using some tutorials I found online.

It works nicely. I plan to add checkboxes for disabling other filters similar to Raw HTML and also want to include that “add a notice” functionality somehow. I was going to incorporate the syntax highlighting, but that works really well as a stand alone plugin. Chris’s code had some problems on my setup that I hope to look into and patch for him.

Let me know what you think of Don’t Break the Code. If you want to contribute, you can fork and patch via GitHub here.

Thanks!

Don’t Break The Code was last updated on November 10, 2011. Bookmark the permalink.

Duplicate comment detected; it looks as though you’ve already said that!

Not sure how long WordPress has been doing this, but there is a check for duplicate comments. If the same user/email posts the same exact comment on the same post, the user will get a message like:

Duplicate comment detected; it looks as though you’ve already said that!

This is great actually, and keeps people from submitting the same comment twice if they get impatient waiting for moderation or otherwise click that submit button twice.

As a blog owner and WordPress developer, there may be situations where you want to allow people to post the same comment. If you want to enable duplicate comments on your blog for some reason, you can use this code here. Just add it to your theme’s functions.php or put this in a .php in your plugins folder and enable it.

function enable_duplicate_comments_preprocess_comment($comment_data)
{
	//add some random content to comment to keep dupe checker from finding it
	$random = md5(time());	
	$comment_data['comment_content'] .= "disabledupes{" . $random . "}disabledupes";	
	
	return $comment_data;
}
add_filter('preprocess_comment', 'enable_duplicate_comments_preprocess_comment');

function enable_duplicate_comments_comment_post($comment_id)
{
	global $wpdb;
	
	//remove the random content
	$comment_content = $wpdb->get_var("SELECT comment_content FROM $wpdb->comments WHERE comment_ID = '$comment_id' LIMIT 1");	
	$comment_content = preg_replace("/disabledupes{.*}disabledupes/", "", $comment_content);
	$wpdb->query("UPDATE $wpdb->comments SET comment_content = '" . $wpdb->escape($comment_content) . "' WHERE comment_ID = '$comment_id' LIMIT 1");
		
	/*
		add your own dupe checker here if you want
	*/
}
add_action('comment_post', 'enable_duplicate_comments_comment_post');

For reference, here is the dupe check code in wp-includes/comment.php. A newer version should probably have a hook above and/or below to allow people to override the dupe checker more directly.

// Simple duplicate check
	// expected_slashed ($comment_post_ID, $comment_author, $comment_author_email, $comment_content)
	$dupe = "SELECT comment_ID FROM $wpdb->comments WHERE comment_post_ID = '$comment_post_ID' AND comment_approved != 'trash' AND ( comment_author = '$comment_author' ";
	if ( $comment_author_email )
		$dupe .= "OR comment_author_email = '$comment_author_email' ";
	$dupe .= ") AND comment_content = '$comment_content' LIMIT 1";
	if ( $wpdb->get_var($dupe) ) {
		do_action( 'comment_duplicate_trigger', $commentdata );
		if ( defined('DOING_AJAX') )
			die( __('Duplicate comment detected; it looks as though you’ve already said that!') );

		wp_die( __('Duplicate comment detected; it looks as though you’ve already said that!') );
	}
Duplicate comment detected; it looks as though you’ve already said that! was last updated on October 22, 2010. Bookmark the permalink.

Jason Speaking at WordCamp Philly October 30th at Temple University

I will be speaking on Business Models for Plugin/Theme Distribution. What You Need to Know About the GPL at WordCamp Philly October 30th, 2010 at Temple University in Philadelphia.

With lots of sweat and little luck, we’ll have our membership plugin available for some sort of release by then. But really I’m excited to share my thoughts on how to distribute, market, and make money off this plugin… and more interested in others ideas about the same.

If you want to hear me speak or are otherwise interested, get your ticket now.

Jason Speaking at WordCamp Philly October 30th at Temple University was last updated on September 23, 2010. Bookmark the permalink.

Pagination Update

Earlier in the year, I wrote a tutorial on how to create pagination similar to Digg’s. The article focused on the basic algorithm for displaying the pagination, and there was definitely some opportunity for improvement in its implementation.

Well, the improvements are in. We have a modularized PHP version and a Perl version. See the updated pagination demo page for details.

Pagination Update was last updated on December 29, 2006. Bookmark the permalink.

Making Our Current Features Solid Before Adding New Ones

Kim and I were getting a lot of work done on a new import tool for WineLog. There is no question that this tool is awesome. It is one-of-a-kind and will help users who have invested a lot of time into another wine tracking system to convert to WineLog. This new feature is good for our users, and good for the growth of WineLog.

However, there are a lot of existing features that could use our attention. The RSS feeds for instance need some help. Some are more flexible than others, some are not yet taking advantage of the smarter search code, and some are not working at all. There is a lot we can do to make subscribing to our content through RSS more user-friendly and easier to understand for folks who may not be familiar with Real Simple Syndication.

There are a lot of web sites moving into the wine space recently. Some of these web sites are really solid. While I think we currently offer the best mix of features and community, others are catching up fast. And their quality is not suffering. We can’t afford to have a reviewer say something like, “Sure, WineLog has a huge database of wines, but such and such a feature was rough around the edges and confused me.” We can’t afford to lose a user who runs into a problem like that.

For these reasons, over the next few weeks Kim and I will be focusing on making our current feature set as solid as possible before moving on to new things. Adding new features will only complicate things if we’re not sure that the current offerings are the best they can be. Sometimes we try to run faster than our legs can take us and we stumble a bit. When this happens, we need to slow down a bit and focus on our technique.

Making Our Current Features Solid Before Adding New Ones was last updated on December 13, 2006. Bookmark the permalink.