Regular expressions are powerful.

I’m sure you’ve heard this claim before. But you’ve also heard lots of negativity against regular expressions on Stack Overflow and elsewhere. There are two main reasons for this:

1. Inappropriate use of regular expressions
2. Lack of understanding and fear of regular expressions

Probably the most common example of an inappropriate use of a single regular expression is to validate an email address. It turns out that most of us have been disallowing valid email addresses with regular expressions all along and that some code is required to properly validate an email address. And even then it’s probably wrong.

Using a regular expression when a simple string function could be used is another example of inappropriate use. For example, say you want to validate an email address by just checking for the @ symbol (which is what I do now — see this). Using a regular expression preg_match( '/@/', $email ) is overkill. There are no expressions there. We’re just searching for a character. It’s better practice to use strpos( $email, '@' ) instead.

I say “better practice” rather than “better performance” because in this example where we’re operating on a tiny email string. The performance is insignificant. In this case, it doesn’t really matter which we use. However, if we were searching a very large string instead of an email address and doing it several times within a loop, there could be a significant improvement in performance. Maybe we’re searching several strings in HTML page sources for example.

If you’re just matching a string constant, don’t use regular expressions.

Unfortunately some developers have misunderstood this to mean that regular expressions are terrible on performance and that they should go out of their way to avoid regular expressions. Some have even adopted it as a reason not to learn them. This is dead wrong.

Let’s add a couple of little requirements to our example. Let’s say we want to check if the @ symbol is the first character in the string and if it is, replace it with a # symbol. Maybe we’re converting tweet replies to hash tags for some reason. Using string manipulations might look something like this:

if ( 0 === strpos( $string, '@' ) ) {
    $string = '#' . substr( $string, 1 );
}

But this same thing can be achieved with a regular expression more concisely:

$string = preg_replace( '/^@/', '#', $string );

If you haven’t learned regular expressions, you probably feel that this is less readable, but realize that this is more readable to those who have a grip on regular expressions.

If we add another requirement to our example: that the last character also has to be an @, and only then do we replace both @ with a #. Then our string manipulation code gets more complex and less readable:

$length = strlen( $string );
if ( 0 === strpos( $string, '@' ) && $length - 1 === strrpos( $string, '@' ) ) {
    $string = '#' . substr( $string, 1, $length - 1 ) . '#';
}

Our regular expression changes only slightly:

$string = preg_replace( '/^@(.*)@$/', '#$1#', $string );

These are trivial examples, but hopefully they illustrate how the code can take a turn for the worst if you insist on sticking with string manipulation instead of taking up the challenge of writing a regular expression.

So, the next time you find yourself going out of your way to avoid using a regular expression, just Google for the solution, learn how it was done, tweak it, play with it, break it, struggle with it, and repeat. This is the best way to learn.

The post Stop Avoiding Regular Expressions Damn It appeared first on bradt.ca.

Alex argues that if these settings are not for the vast majority of users, they don’t belong in the control panel.

The people that need to do these things should use add-ons, or at the very least an about:config tweak.

I completely agree.

And so I found it ironic that Paul Rouget (also from Mozilla) had also posted yesterday about the future of Firefox DevTools.

DevTools is a set of features built into Firefox for web developers. As a developer myself, I absolutely love the work that Paul and his teammates are doing. But I have to challenge the idea of including these features in Firefox core rather than making them available as add-ons.

Surely the vast majority of Firefox users are not developers. So, why include this in Firefox?

Also, as much as I love the effort they are putting into DevTools, much of it seems like a repeated effort. Firebug has been around for a long time and is battle-tested. Why rebuild its features into Firefox core? Why not put the effort toward improving Firebug instead?

In his post yesterday, Paul talks about building a new network panel and timeline for DevTools like the one in Firebug. What advantage will the new panel have over Firebug?

I’m genuinely curious about the answers to these questions. I’m not trying to call out Paul or his teammates here or declare “you’re doing it wrong.” That’s not helpful.

I love Mozilla and the work that they do. I’ve had the pleasure of working with several talented folks who are now part of the Mozilla family. I deeply respect the work they do and I wouldn’t be writing this if I didn’t care.

I’d love to hear from Paul and/or his teammates, get some insight into their decision making, and start a discussion. I want Firefox to be the best goddamn browser, always.

The post Why Firefox DevTools? appeared first on bradt.ca.

Last year, I bought a sofa for my office from Costco. It went on sale two weeks later for $500 off. I called Costco and they refunded the $500. No questions asked.

The thing is, I knew there was a good chance the sofa would go on sale in the near future. I also knew that Costco would refund the difference. So, I didn’t hesitate to purchase. I didn’t wait for the sofa to go on sale.

When a customer is considering purchasing your product, you don’t want them thinking that waiting for a sale is a good idea.

Now should always feel like the best time to buy.

http://wpdaily.co/best-time-buy/

The post The Best Time to Buy is Now appeared first on bradt.ca.

Business

• Blue Ocean Strategy
• The Innovator’s Dilemma

Fiction

• Dracula
• Frankenstein
• The Hobbit
• Winter of the World

History

• With the Old Breed

Again, notice that both categories and book titles are sorted alphabetically. Unfortunately, there is no easy way to do this using a single call to WP_Query. There is no option to sort by taxonomy. Instead, most developers would get all the categories, then loop through them, calling WP_Query for each one. That would be ok for the tiny bit of data we have above, but let’s pretend we are outputting a printable catalog of books and we have hundreds of categories and thousands of books. We would definitely want to do this more efficiently, with just one call to WP_Query. So, we need to make use of the filters in WP_Query. In the past, I would have done something like this:

function my_posts_fields( $sql ) {
	global $wpdb;
	return $sql . ", $wpdb->terms.name AS 'book_category'";
}

function my_posts_join( $sql ) {
	global $wpdb;
	return $sql . "
		INNER JOIN $wpdb->term_relationships ON ($wpdb->posts.ID = $wpdb->term_relationships.object_id) 
		INNER JOIN $wpdb->term_taxonomy ON ($wpdb->term_relationships.term_taxonomy_id = $wpdb->term_taxonomy.term_taxonomy_id) 
		INNER JOIN $wpdb->terms ON ($wpdb->terms.term_id = $wpdb->term_taxonomy.term_id) 
	";
}

function my_posts_where( $sql ) {
	global $wpdb;
	return $sql . " AND $wpdb->term_taxonomy.taxonomy = 'book_category'";
}

function my_posts_orderby( $sql ) {
	global $wpdb;
	return "$wpdb->terms.name ASC, $wpdb->posts.post_title ASC";
}

add_filter( 'posts_fields', 'my_posts_fields' );
add_filter( 'posts_join', 'my_posts_join' );
add_filter( 'posts_where', 'my_posts_where' );
add_filter( 'posts_orderby', 'my_posts_orderby' );

$r = new WP_Query( array(
	'post_type' => 'book',
	'posts_per_page' => -1,
	// Optimize query for no paging
	'no_found_rows' => true,
	'update_post_term_cache' => false,
	'update_post_meta_cache' => false
) );

// Make sure these filters don't affect any other queries
remove_filter( 'posts_fields', 'my_posts_fields' );
remove_filter( 'posts_join', 'my_posts_join' );
remove_filter( 'posts_where', 'my_posts_where' );
remove_filter( 'posts_orderby', 'my_posts_orderby' );

Look at all those single purpose functions in the global scope. Gross. We can tidy this up by wrapping it in a class that extends WP_Query.

class My_Book_Query extends WP_Query {

	function __construct( $args = array() ) {
		// Force these args
		$args = array_merge( $args, array(
			'post_type' => 'book',
			'posts_per_page' => -1,  // Turn off paging
			'no_found_rows' => true, // Optimize query for no paging
			'update_post_term_cache' => false,
			'update_post_meta_cache' => false
		) );

		add_filter( 'posts_fields', array( $this, 'posts_fields' ) );
		add_filter( 'posts_join', array( $this, 'posts_join' ) );
		add_filter( 'posts_where', array( $this, 'posts_where' ) );
		add_filter( 'posts_orderby', array( $this, 'posts_orderby' ) );

		parent::__construct( $args );

		// Make sure these filters don't affect any other queries
		remove_filter( 'posts_fields', array( $this, 'posts_fields' ) );
		remove_filter( 'posts_join', array( $this, 'posts_join' ) );
		remove_filter( 'posts_where', array( $this, 'posts_where' ) );
		remove_filter( 'posts_orderby', array( $this, 'posts_orderby' ) );
	}

	function posts_fields( $sql ) {
		global $wpdb;
		return $sql . ", $wpdb->terms.name AS 'book_category'";
	}

	function posts_join( $sql ) {
		global $wpdb;
		return $sql . "
			INNER JOIN $wpdb->term_relationships ON ($wpdb->posts.ID = $wpdb->term_relationships.object_id) 
			INNER JOIN $wpdb->term_taxonomy ON ($wpdb->term_relationships.term_taxonomy_id = $wpdb->term_taxonomy.term_taxonomy_id) 
			INNER JOIN $wpdb->terms ON ($wpdb->terms.term_id = $wpdb->term_taxonomy.term_id) 
		";
	}

	function posts_where( $sql ) {
		global $wpdb;
		return $sql . " AND $wpdb->term_taxonomy.taxonomy = 'book_category'";
	}

	function posts_orderby( $sql ) {
		global $wpdb;
		return "$wpdb->terms.name ASC, $wpdb->posts.post_title ASC";
	}

}

Now all your custom query code is neatly contained in this class file that you can include when necessary. And because we’re extending WP_Query, you can use the usual functions in your loops:

$query = new My_Book_Query();

if ( $query->have_posts() ) :

	while ( $query->have_posts() ) :

		$query->the_post();
		...

	endwhile;

	wp_reset_postdata();

endif;

The post Extending WP_Query appeared first on bradt.ca.

Commercial plugins help or hurt WP?

I’m summarizing, but during his interview, Matt essentially said that designs have more value in being rare, charging for them makes them rarer, so it makes sense. On the flip side, plugins have more value being ubiquitous, charging for them makes them less so, so it doesn’t make sense.

I agree that plugins have more value being ubiquitous. We should strive to make plugins (or any code for that matter) more available and accessible. I mean, I was able to learn Perl and PHP in my teens by hacking on freely available open source code. I want the next generation to have that same opportunity. But I think there’s very little risk of losing that. When I was hunting for Perl scripts at cgi-resources.com, there were upsells to paid versions with additional features and support. And that was over a decade ago. The business model of giving away a free package but offering a commercial package with more features and support is ancient in web years; yet I’m pretty sure that free open source is as healthy as it has ever been. I think a very strong argument can be made that business helps the proliferation of free open source software more than it hurts.

In an ideal world, all code would be free open source and all developers would still be able to pay their bills. But that’s a utopian dream. In this world, there needs to be a balance between free and commercial open source. Give away as much as possible while still being able to pay the bills.

Charging for SaaS is better than charging for plugins

Matt explained that he believes it’s better to offer a free plugin and charge for a service (SaaS) that the plugin connects to (like Akismet & VaultPress) rather than charge for the plugin itself. I disagree. Giving away a plugin that doesn’t work without a paid SaaS subscription isn’t exactly a great contribution to the free open source community. In fact, I’d argue that the free plugin + commercial plugin model is better. I mean, in the SaaS model the bulk of the code is private. You can release little bits and pieces but not the whole thing. If you released everything, it would be too easy for competitors to setup shop.

With the free plugin + commercial plugin model, when you buy an open source plugin, all the code is available to be reviewed, learned from, and in the case of GPL, you’re free to use the code in your own GPL projects. Plus, you have access to a working, free plugin.

Bad idea to build a business on a feature that could be rolled into WP core

When people’s livelihoods depend on selling a certain plugin that could be incorporated into WP core, Matt explained that it becomes a bit of a dilemma for the core team. He gave the specific example that if WP core decided to incorporate some kind of form features it might hurt Gravity Forms.

This extends to business in general. It’s a bad idea to build a business on a feature that could be built-into the platform. I think it’s generally good advice, but as with most business advice, I don’t think it’s a hard and fast rule. If you recognize the risk of the platform incorporating the feature, but the investment is minimal, it might still be worth it.

A non-WP example of this is S3Stat, which was built by Expat Software to satisfy a need for their clients, then with a little development offered as a service for $5/month and set it on autopilot. That was 2007. Now, five years later, Amazon Web Services still has not integrated this feature into their platform, and the founder of S3Stat has been living off the income for the past three years, all the while bootstrapping other ventures.

As for Gravity Forms, I’ll let the founder, Carl Hancock speak to that.

I suggest heading over to the comments of Tony Perez’s post on this subject to read opinions from plenty of others including responses from Matt.

The post Commercial WordPress Plugins appeared first on bradt.ca.

Held last week in Phoenix, it was the inaugural conference for those in the business of WordPress (WP). Previous to this, Web Directions North had been my favourite conference. So why did PressNomics take the top spot?

I’m passionate about building web-based product businesses. Most conferences I’ve attended have focused on web development, talking mostly about the technology and a bit about client services business. Few attendees were interested in talking about products. They were either self-employed, happy doing client services, or employed at an agency. PressNomics was largely about products.

Every night, I had dinner with designers and developers who were building products for WP. I heard stories about scaling customer support, costs involved, and setting prices. I heard fascinating plans about upcoming projects. I was given feedback on my work, suggestions for what to work on next and strategies. I asked questions and was blown away by the feedback.

Due to the nor’easter storm, I had to reschedule flights and missed the day one sessions. I would really have liked to catch Cory Miller and Alex King‘s talks in particular, but upon landing in Phoenix, I felt lucky I had made it at all. I managed to arrive just in time for the happy hour drinks and was super pumped to meet a ton of awesome people I’ve been emailing with for the past year, especially Adii, who’s been advising me on WP App Store. I really enjoyed the day two sessions. I was particularly floored by the stories of humble beginnings from Envato‘s CEO Collis Ta’eed and the gutsy decisions made by Chris Drake to get FireHost where it is today.

And then there was the on-stage interview with Matt Mullenweg which went exactly as I expected it would. I had had a couple of back and forth emails with Matt about WP App Store months ago and felt I had a pretty good understanding of his position. I also had an in-depth email exchange with Otto about .org and why the WP App Store plugin isn’t allowed. I have a good understanding of the philosophy there as well. So when Matt was asked about his disapproval of WP App Store, I wasn’t surprised by the response and I didn’t see the point of challenging. As Tony Perez from Securi says in his post:

It is one of those things that is engrained in how an individual thinks and in their own beliefs. It’s not really one of those subjects that you can engage in, in the hopes that you will sway opinion.

I also wasn’t surprised that Matt’s beliefs conflicted with the majority of people in the room. I started writing out my beliefs and philosophy concerning selling plugins in this post, but it was running too long. I’ll put together a separate post in the next few days. Spoiler alert, my philosophy and beliefs aren’t in line with Matt’s. In the meantime, there’s an excellent discussion going on in the comments of Tony’s post about this stuff. Check it out.

I can hardly imagine how much work Sally, Josh, and the Page.ly crew put into this event. It was so awesome, that any issues don’t even register. Fuck the Wifi. Who cares who got VIP and who didn’t. As far as I’m concerned, it was flawless. Kudos to you folks. You should be very proud.

The post PressNomics Conference Recap appeared first on bradt.ca.

I agree with Tom, WP can make a great foundation for an app. I chose to use WP when I started building WP App Store and it gave me a huge head start when compared to starting with an app framework. Having the dashboard UI built and ready to customize is probably the piece that saved the most time. As Tom mentions, there’s user management, a clean API, and lots more. All of which are battle-tested by thousands of developers and millions of web sites. As I went deeper into building WP App Store though, I did learn some lessons about what works and what doesn’t when using WP for an app. In this post, I’ll describe one that I’ve been grappling with lately.

As WP App Store has become more complex, so has our data and our queries. Some of our queries are now looking pretty ugly, having a lot of joins. Here’s one that gets a report of a publisher’s sales commissions by querying the order post type and its custom field data:

SELECT pm2.meta_value as product_title, COUNT(*) as unit_count, SUM( pm1.meta_value ) as commission_total
FROM $wpdb->posts
	INNER JOIN $wpdb->postmeta AS pm1 ON pm1.post_id = $wpdb->posts.ID AND pm1.meta_key = '_commission_amount'
	INNER JOIN $wpdb->postmeta AS pm2 ON pm2.post_id = $wpdb->posts.ID AND pm2.meta_key = '_product_title'
	LEFT OUTER JOIN $wpdb->postmeta AS pm3 ON pm3.post_id = $wpdb->posts.ID AND pm3.meta_key = '_is_test'
	INNER JOIN $wpdb->postmeta AS pm4 ON pm4.post_id = $wpdb->posts.ID AND pm4.meta_key = '_publisher_id'
    INNER JOIN $wpdb->postmeta AS pm5 ON pm5.post_id = $wpdb->posts.ID AND pm5.meta_key = '_product_type'
    LEFT OUTER JOIN $wpdb->postmeta AS pm6 ON pm6.post_id = $wpdb->posts.ID AND pm6.meta_key = '_is_refunded'
WHERE pm5.meta_value = '%s'
    AND pm4.meta_value = '%s'
    AND (pm3.meta_value IS NULL OR pm3.meta_value = '' OR pm3.meta_value = '0')
    AND (pm6.meta_value IS NULL OR pm6.meta_value = '' OR pm6.meta_value = '0')
    AND $wpdb->posts.post_type = 'order'
    AND ($wpdb->posts.post_status = 'publish')
GROUP BY pm2.meta_value

Why a custom query? Why not use the WP_Query object for this? I believe WP_Query is intended for querying posts, but in this case we’re generating a report, leveraging MySQL’s awesome ability to count the number of sales, add up the commissions, and return one neat row with these numbers for each product title. This is the kind of stuff MySQL is great at doing.

Unfortunately though, custom fields were not designed for this. They were originally designed to be returned from the database and displayed, not queried. Performance is terrible when queries have to join the postmeta table many times for each custom field key. Plus, as Alex King pointed out in a recent episode of Shop Talk Show we’re querying a MySQL column of type longtext which is slow. And to top it off, the meta_value column isn’t indexed.

If we look at the custom fields in the query above, you could convert some of the custom fields into taxonomies because they would be repeated across several orders, but there is some data that is unique to a single instance of a post as well. Also, if we converted all the custom fields to taxonomies, we’d end up querying for many taxonomies in this one query, which would again result in many joins. Instead, I’ve been considering creating a custom database table for each post type with columns for each of the custom fields.

So, for the data in the example above, a custom table to hold the custom field data might look like the following:

CREATE TABLE IF NOT EXISTS `wp_pm_order` (
  `order_id` bigint(20) NOT NULL,
  `publisher_id` bigint(20) NOT NULL,
  `product_title` varchar(255) NOT NULL,
  `product_type` varchar(255) NOT NULL,
  `commission_amount` float NOT NULL,
  `is_test` tinyint(4) NOT NULL,
  `is_refunded` tinyint(4) NOT NULL
  PRIMARY KEY (`order_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Then the query above would look like this:

SELECT pm.product_title, COUNT(*) as unit_count, SUM( pm.commission_amount ) as commission_total
FROM $wpdb->posts
    INNER JOIN $wpdb->pm_order AS pm ON pm.post_id = $wpdb->posts.ID
WHERE pm.product_type = '%s'
    AND pm.publisher_id = '%s'
    AND (pm.is_test IS NULL OR pm.is_test = '' OR pm.is_test = '0')
    AND (pm.is_refunded IS NULL OR pm.is_refunded = '' OR pm.is_refunded = '0')
    AND $wpdb->posts.post_type = 'order'
    AND ($wpdb->posts.post_status = 'publish')
GROUP BY pm.product_title

We’ve gone from 6 joins down to 1 and the columns we’re now querying are of types representative of the data they contain. A major improvement to the query performance, but also much easier to read and maintain in the future.

What do you think of using custom database tables to store custom field data for an app built with WP? Maybe there’s a better way?

Thanks to Tom for reviewing and providing feedback on this post before I published it.

The post Custom Table for WordPress Custom Fields appeared first on bradt.ca.

It seems there’s two competing views on whether a set of functions or a class should be used in core. For example, the relatively recent transients API is a set of functions, but could have just as easily been a class. Is there some reasoning behind the decision to use a set of functions instead of a class? Or is it coders choice?

To be clear, I’m not for or against using a set of functions instead of a class. And the transients API is great the way it is. If there’s no difference in performance, I personally don’t care either way. However, I am for consistency and don’t see a reason why we should use both techniques.

And what about static class variables rather than global variables? WP stopped supporting PHP4 last year, so is there any reason not to use static class variables for new development?

The discussion that ensued was excellent. For me, the crux of the conversation was delivered by @nacin, with a detailed post about the core team’s work with classes and globals. I recommend reading the whole post, but here are few gems:

Don’t be surprised if WP_Post happens in 3.5 or 3.6.

Someone mentioned PHP 5.3 namespaces, and that makes me laugh. In two years, PHP 5.3 adoption (in terms of WordPress sites) has gone from 4% to 10%. Not holding my breath.

Rewriting code for the sake of rewriting code is not a good use of our time.

That also does not mean we’re going to use classes everywhere. There are plenty of situations where procedural code is going to be better.

I am at the point where I will fight hard to prevent any more globals be added to core; we’ve been rather good about this for at least a year now.

That said, static class variables (as suggested) aren’t exactly any better. They’re not.

Global state (a global variable, a static method, a static property, what have you) is not testable.

The last point about global state not being testable really hit home for me. I read through all of the referenced articles and it really opened my eyes to how code needs to be structured to be testable. I’ve been aiming to get into test-driven development and this was a big step in that direction.

Also, it’s clear to me now that I should avoid using the global state and look at implementing a class before a set of global functions, but not be afraid to use global functions if they work better for the situation.

The post WordPress Best Practices: Global functions vs. classes appeared first on bradt.ca.

Packaged as a Ruby Gem, Dandelion is super simple to install: gem install dandelion. To setup, you create a tiny YAML config file in the same directory as your Git repository with the server connection details. Then you can run  dandelion deploy. Pure awesome.

Why not use Capistrano? I’m definitely not a Capistrano expert, but I don’t believe it’s as easy to set it up to deploy over FTP, SFTP, or Amazon S3. From what I understand, it’s primarily designed for use over SSH. Unfortunately not all web hosts offer SSH access and those that do sometimes require time to set it up. As a result, I’d been using the Transmit‘s Sync feature for years. It’s slow (needs to check each file for changes) and a break from my command line workflow. Dandelion keeps my workflow on the command line and is much quicker to upload changes. A nice little bump to developer happiness.

I’ve been deploying WP App Store to WP Engine with Dandelion for a couple weeks now and it has been fantastic. As I bring on additional developers and deployment becomes a bit more complex, I’ll likely move to deployhq.com.

The post Dandelion: Git Deployment over FTP appeared first on bradt.ca.

I go through phases where the engineer takes over. There’s an itch that has been irritating him for weeks, maybe even months, and damn it, he’s going to scratch it. He starts writing some kind of framework, or refactoring some code, or implementing some new, fascinating approach he read about, or working on a cool, new feature that is out of scope. At the same time, from the back seat, the entrepreneur starts nagging for updates on the overall progress of the project. Unfortunately though, scratching these itches rarely moves the project forward, so the entrepreneur is relentless. With every line of code, the entrepreneur is becoming more and more irritating. Eventually the nagging is more irritating than the original itch, so the engineer drops his tangential coding and resumes hacking the project forward.

When I only had client work, I allowed the engineer to scratch a few itches per project. It improved my code base, often saving me time on the next project, and increased developer happiness. Sure, the project price was set and I would make more money by just hacking, but I valued developer happiness and it was worth the tiny cost.

But now in the throes of building a new business, I can’t afford to let the engineer take over at any point. A founder’s time is expensive and any time spent working on the business should be moving it forward. A balance is needed between the engineer and the entrepreneur. Neither should take over completely. The entrepreneur keeps things moving forward and the engineer ensures that hacking doesn’t create a complete disaster.

New businesses need to hack things together so they can start generating revenue as soon as possible. Adii shares a great inside story on this. WooThemes hacked together their membership and payment processing backend when they started. And hacked away at it for three years, until they were in a better position to rewrite it. The engineer cringes at the idea of hacking away at crappy code for three years, but the entrepreneur slaps him, quoting WooThemes’ success.

Fortunately, I’ve found that the entrepreneur’s nagging is much more intense when there’s no revenue, which makes it easier to keep the engineer in check. That’s not to say the engineer doesn’t try to take over as often as before. He does. But the mere threat of intense nagging sends him back to hacking.

Vote this up on HN:
http://news.ycombinator.com/item?id=3620954

The post Founder Inner Conflict: Engineer vs. Entrepreneur appeared first on bradt.ca.