Development

Jason Coleman

WordPress as an Application Framework

By | January 11, 2013 | 10:19 pm

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.

Jason Coleman

Don’t Break The Code

By | November 10, 2011 | 5:57 pm

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!

Jason Coleman

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

By | October 22, 2010 | 10:24 am

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!') );
	}
Jason Coleman

Jason Speaking at WordCamp Philly October 30th at Temple University

By | September 23, 2010 | 12:33 pm

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 Coleman

Making Our Current Features Solid Before Adding New Ones

By | December 13, 2006 | 10:59 pm

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.