More than that though, the playground offers an easy way to try out WordPress themes and plugins without worrying about the hassle of setting up a site themselves. Users can do that themselves, by constructing URLs to automatically launch the playground with certain plugins installed, or manually installing them once the playground has launched but it’s not that straightforward.

The great news is that the WordPress.org plugin directory also supports easily “Live Previews” for plugins using the WordPress playground.

The process is opt-in at the moment, but if a plugin author has opted in to Live Previews, then you’ll see a button to launch the preview right on the plugin page on WordPress.org. Here’s what it looks like for the Say What? string replacement plugin which is opted in to Live Preview.

The WordPress.org plugin directory implementation is driven by ‘blueprints’. These offer a way for plugin authors to configure how the playground will be launched by providing a simple JSON file.

WordPress.org will generate a default blueprint.json file for you as a starting point to opting in to Live Previews. That blueprint will install WordPress, and the selected plugin automatically. Here’s what a default blueprint.json looks like for the Say What? plugin:

{
    "landingPage": "\/wp-admin\/plugins.php",
    "preferredVersions": {
        "php": "8.0",
        "wp": "latest"
    },
    "phpExtensionBundles": [
        "kitchen-sink"
    ],
    "features": {
        "networking": true
    },
    "steps": [
        {
            "step": "installPlugin",
            "pluginZipFile": {
                "resource": "url",
                "url": "https:\/\/downloads.wordpress.org\/plugin\/say-what.2.2.2.zip"
            },
            "options": {
                "activate": true
            }
        },
        {
            "step": "login",
            "username": "admin",
            "password": "password"
        }
    ]
}

For many plugins this may well be sufficient. It will install the latest WordPress release, install and activate the plugin and login the user with the default admin user.

However, plugin authors can add additional steps to the blueprint before making it available to users. The blueprint can install other themes, plugins, define PHP functions, or run custom PHP. You can run SQL queries, import dummy content using the WordPress importer and even run WP-CLI commands.

In our case, to show off what the Say What? plugin can do, we’d like to launch the preview straight to the plugin’s admin page, with a number of example replacements set up.

We could do that by running custom PHP, or SQL queries in the blueprint, however in order to keep the blueprint as simple as possible we decided to use the WP-CLI import command that the plugin already makes available.

Here’s how you’d normally use it to import a set of replacements from a CSV file:

$ wp say-what import my-replacements.csv

The question is though – how do we pass our ‘sample data’ file to the playground?

I tried a few different approaches – initially assuming that the playground would have access to the files from the WordPress.org plugin’s ‘assets/blueprints’ folder which is where the blueprint.json file lives. That isn’t the case though. The playground is passed your blueprint.json file, but beyond that it’s a completely standalone instance.

It wasn’t initially too clear from the docs how to run a WP-CLI command that accepted a file as input, but a GitHub issue asking the question led to an excellent answer from Adam Zielinski (the creator of the WordPress playground) showing just how easy it can be.

Your blueprint.json can specify a ‘writeFile’ step which can take an external URL as the source, and will write out the file somewhere that your subsequent steps can access.

So, here’s the two steps I ended up adding to the Say What? blueprint.json file:

 {
     "step": "writeFile",
     "path": "\/wordpress\/sample-replacements.csv",
     "data": {
         "resource": "url",
         "url": "https:\/\/raw.githubusercontent.com\/leewillis77\/say-what\/sample-replacement-branch\/sample-replacements.csv"
     }
 },
 {
     "step": "wp-cli",
     "command": "wp say-what import \/wordpress\/sample-replacements.csv"
 }

In the first step, we pull down a file from GitHub*, and write it out as ‘wordpress/sample-replacements.csv’. In the second step we run our WP-CLI command and pass it the filename of the downloaded file, and everything works as normal.

* Note: It would be nice to pull this from the wordpress.org repo, but there are some restrictions on where resources can be fetched from around CORS headers, which the wordpress.org repo doesn’t currently support – hopefully that will be fixed in the future.

If you want to see the full blueprint.json file for Say What? you can see it here.

Want to see the live preview in action – simply hit the Live Preview link on the plugin’s wordpress.org page, or click here to launch it directly.

The post Using files in plugin preview blueprints appeared first on Lee Willis.

However, some client hosting can’t always manage to pull products, build product objects, apply business logic for output, and construct the output for all products within execution time limits / memory limits. This is especially the case for stores which may have large inventories, but not necessarily high levels of site traffic. These people have had to make do with generating multiple, partial feeds which increases complexity for them, and can cause other issues around re-use of output data with multiple integration partners.

There’s a couple of obvious approaches to solving this:

1. Make the processing less complex
2. General code optimisations
3. Pre-generate the output and cache it

I’ve looked at, and worked on, several of these avenues over the years, [1] and [2] have given me some pretty good results, and even proved a learning opportunity in WordPress internals at times…

https://twitter.com/leewillis77/status/768859124339736577

It’s now reached the point that the only way to eek out more performance would be to stop using WordPress to generate the content, and to pull it out with straight database queries instead. This would no doubt be a lot quicker, and a lot lighter on CPU.

However, it misses out on a lot of the point of WordPress – that plugins can add, update, and remove information programatically.

From my support work on the plugin over the years, it’s clear that many people rely on plugins / hook customisations to get their final data to be what they want. Raw SQL queries would most likely result in incorrect data, so it’s not really an option.

That leaves us with item [3] – pre-generating the output and caching it. Due to the previous scalability concerns though – we can’t assume that we can generate the full output in a single request. Nor do we want to have to invalidate the full output if a single product, or category is changed.

The solution I’ve settled on generates cached output for each item included in the full output. This gives a couple of benefits:

1. We can generate our final output with a simple SQL query to pull all of the fragments. This is quick. We also don’t have to  worry that information won’t include input from other plugins on the site as full processing was used to build the fragment
2. We can invalidate, and rebuild single products, or sets of products without having to invalidate everything
3. We can build up our cached output in parts, we don’t have to generate it all at once

I was left with a requirement for background processing infrastructure that the pre-generation, and batched invalidation could be handed off to.

I’ve been working a lot with Laravel recently. One of its strengths, and something I’ve used on most (if not all) of my Laravel projects is its Queue implementation. It allows you to easily add jobs to one or more queues, and have them processed by workers in the background. You can set up multiple queues, and you’re in control of how many workers you set up, and which queues they’ll process. The library is usable standalone – it can be used outside of a Laravel project. Unfortunately this plugin supports WordPress’ minimum requirements which are still anchored at PHP 5.2, while Laravel’s Queue system requires 5.6.4 minimum making it a non-starter.

Fortunately, I came across and mentally noted the WP Background Processing library from Ashley Rich / Delicious Brains a while ago:

It’s the perfect solution to this problem. It’s simple, and lets you build background jobs that will run automatically through WordPress’ existing cron infrastructure, taking care to balance running as many jobs as possible in an execution with getting through the jobs as quickly as possible. It’s also compatible with PHP 5.2.

Using the library has let me build out some pretty neat invalidation / pre-generation jobs without having to worry about putting together the cron logic myself. Definitely worth looking at if you need to do any background processing in WordPress plugins.

The post Background processing for WordPress appeared first on Lee Willis.

On small stores, this is pretty straightforward, but on larger stores, the effort to query all products (including all individual variations of products) can be significant.

I’ve recently been doing some work on performance-tuning the plugin. I started out with some really simple performance tracking outputting total time and memory usage at the end of the XML document. There were some quick wins as a result of that, but it didn’t really give me a feel for what was going on, or any big gains.

I’m normally a big fan of the Query Monitor plugin for reviewing what queries are run to generate a page, however in this instance it doesn’t help since there is no HTML output to the page for Query Monitor to add its results to. I needed something that wasn’t tied to logging its output to the generated page. I finally settled on Time-Stack by Joe Hoyle.

There are actually two things you need to get up and running – the timestack “app” (repo linked above), and the WordPress plugin that logs the data. Once you’ve got the app installed, and the WordPress plugin activated, then every request will be tracked, and visible in the app:

You get to see the total runtime, and memory usage, but more importantly you can drill into sections of the page request to see further information. You can right down to the actual queries being run and see exactly what’s going on. You can even instrument your code to markup useful sections for your profiling.

How did I get on? I’ll let the evidence speak for itself …

https://twitter.com/leewillis77/status/768863921763717120

Probably not for every site, or every occasion, but an awesome tool to have in the locker – thanks Joe!

The post WordPress performance tracking with Time-stack appeared first on Lee Willis.

Working on WordPress plugins in my spare-time gave me the flexibility to experiment with things that interested me. I built some fun plugins, some useful plugins, and some boring-but neatly functional plugins. I’ve also learnt a lot along the way.

Selling some of those plugins has given me the flexibility to give up the day-job, and go out on my own full-time. So – as of early April, this my new office:

It comes complete with personalised mug from my ever-supportive wife Claire, greenhouse-style window display, and Bella the code-reviewing cat.

Going forward, my main aims are to:

• expand my range of plugins – both free and paid
• take care of some housekeeping and feature development on existing plugins
• explore some other technical arenas

I’ll also be taking on some contract work (WordPress, Drupal, Symfony or Laravel for starters) to keep things interesting.

So far, I’ve released Cart recovery for WordPress, as well as its pro add-on, added new features to a few free, and paid-for plugins, done some R&D with Laravel and Ionic for future projects, and got a few nice contracts lined up.

Not a bad start – here’s to the future!

The post Looking ahead appeared first on Lee Willis.

I first came across Wapuu at WordCamp London, where Scott Evans had designed an awesome Punk Wapuu which covered posters, stickers – and even scarves! (You can see some of the artwork here: https://london.wordcamp.org/2015/). It turns out that the Wapuu character was original developed by the Japanese WordPress community, released under the GPL, and has since been modified by many people for many different events / purposes.

Every better – they’re maintaining an archive of publicly release Wapuu interpretations.

Coincidence struck when I was:

a) Looking for a just-for-fun project to soothe my soul

b) Stumbled upon a tweet by @NickHamze

https://twitter.com/NickHamze/status/662370659075407872

Well, I couldn’t resist – the timing seemed just right

So if you want your WordPress avatars to be cute Wapuus in various poses – the wait is over – check out Wapuuvatar on GitHub – or download it from WordPress.org.

The post Wapuuvatar appeared first on Lee Willis.

This is something I’ve always been an advocate of – particular on sites that go beyond simple posts and pages. One of my plugins provides some of the tools that can help with this. The “Say What?” string replacement plugin for WordPress allows you to override strings from WordPress core and/or plugins that you’re using so you can personalise the phrases that are used to your particular use case.

I took the opportunity to make some small updates to the plugin over the last few days. Particularly I’ve extended the plugin to have support for WP-CLI. This allows you to import and export string replacements – particularly useful if you have a standard set (or sets) of replacements that you use on sites you build. You can also use it to get a list of all replacements you currently have set up on your site.

Generating a list of replacements

$ wp say-what list
+-----------+-------------+--------+--------------------+---------+
| string_id | orig_string | domain | replacement_string | context |
+-----------+-------------+--------+--------------------+---------+
| 3         | Tools       |        | Lee's tools        |         |
| 9         | Dashboard   |        | The dashboard      |         |
+-----------+-------------+--------+--------------------+---------+

Exporting your replacements

This will ‘export’ all of your replacements in CSV format to the file /tmp/my-replacements.csv. This file is in the same format you need for importing back into the site, or into another site.

$ wp say-what export --format=csv > /tmp/my-replacements.csv

Updating replacements

Sometimes you might want to export a set of replacements, edit them, and then re-import. You can do this with the ‘update’ command – this will update any items with a string_id provided, or insert any items without a string ID. The following command will read in the file /tmp/my-replacements-amended.csv and update the database.

$ wp say-what update /tmp/my-replacements-amended.csv

Importing replacements

If you just want to add the replacements in a file to the database, you can use the ‘import’ command. This will insert each item in the file as a new item in the database.

$ wp say-what import /tmp/my-replacements-new.csv

Trying it out?

You can grab the plugin from WordPress.org – or check it out on GitHub – thanks to WordCamp London for the inspiration!

The post WP-CLI import and export for Say What? appeared first on Lee Willis.

If you do want it to default to the cheapest option, try this simple plugin:

The post Default Lowest Shipping Choice on WP e-Commerce appeared first on Lee Willis.

Fortunately, it’s pretty easy to change this order – simply paste the following function into your theme’s functions.php file, or use a functionality plugin. Just change the $gateway_order array to the gateways you have enabled, in the order you want them, and you’re good to go.

function lw_edd_enabled_payment_gateways($gateways) {
	$gateway_order = array(
		'stripe',
		'paypal',
		'manual',
	);
	$new_gateways = array();
	foreach ( $gateway_order as $gateway ) {
		if ( ! empty( $gateways[$gateway] ) ) {
			$new_gateways[$gateway] = $gateways[$gateway];
		}
	}
	return $new_gateways;
}
add_filter(
	'edd_enabled_payment_gateways',
	'lw_edd_enabled_payment_gateways',
	10,
	1
);

Here’s what our revised default checkout looks like – much neater.

The post Change order of payment gateways in Easy Digital Downloads appeared first on Lee Willis.

The problem is…

Most (e-Commerce) themes is that they’re designed to show off the products in the best light possible, and as a result they tend to be image heavy. This is an approach that really doesn’t work well if you’re selling code. Currently my store relies on screenshots on products.

While I think this is really useful in terms of people understanding the functionality available in the plugin, it’s not great for people navigating the store, or “selling” people on the product. So – I’ve decided I need product “icons” of some form.

I’ve not yet decided what they’ll be, or how complex they’ll be. My design skills might stretch that far, or I may be looking for an illustrator who can help me out – but I’m not yet convinced that’s what will be required. 

Choosing a theme

As part of my original research on this project, I’d looked closely at WP e-Commerce, and WooCommerce – both of which have a broad selection of lovely looking themes. Discounting the really image heavy themes there’s still a great deal to choose from.

Since I settled on Easy Digital Downloads, and because it’s not a plugin I’ve spent a lot of time theming, I really wanted something that worked out-of-the box. Unfortunately, while there are a couple of nice themes, there’s not really as broad a choice as there is with other plugins – I think this is the only area I’d score the plugin down in. 

I settled on a shortlist though:

• Quota
• HumbleShop
• Forelight
• Shop Front

Forelight is great, and would be fantastic for someone selling digital art or similar, but I felt it relied too much on imagery. Quota and Shop Front also got discounted as great as they are, they were a bit too plain. I thought I’d have too much design to do to make them feel polished. In the end, I settled on HumbleShop (Be careful, there’s a normal, and an EDD version of the theme available on the net – make sure you grab the right one).

Aside from throwing a few warnings during installation, I’m pretty happy with this choice so far. As you’d expect from someone who tinkers a lot, I expect I’m going to be throwing a few improvement patches the authors way – we’ll see how that goes. However – first impressions are that it’s going to deliver the sort of experience I’m looking for.

Styling it up

Of course, I won’t be leaving HumbleShop as-is. I’ve created a child theme already and have started playing around with styling and colour schemes. I’ve been browsing colourlovers.com for colourscheme inspiration. Again I had a shortlist (Higher, Wordofmouse & Worf, Winter Olympics, and Breakfast Berries), but after a discussion with some trusted friends – I settled on Wordofmouse & Worf:

Color by COLOURlovers

Actually – when I say “settled” on – that might not be entirely true – after applying it to HumbleShop, I’m not quite sure it works, so it may be back to the drawing board. We’ll see…

The post Designing the plugin store appeared first on Lee Willis.

One question I got asked on Twitter was definitely too difficult to answer in 140 characters:

@leewillis77 Yes, thanks – so you host+sell Woo plugins yourself, and via Woo. How do you decide which is right for your plugin?

— Tom Barrett (@TCBarrett) February 22, 2014

The discussion related to my WooCommerce plugins, some of which are sold directly on my own site, and others which are sold through WooThemes. I admit that I don’t have a hard and fast set of rules which make the decision for me, but the list below gives some of  the factors I consider.

Note: While this is written mainly about selling through WooThemes vs. selling on your own store, many of these apply equally to any other non-direct sales channel.

1. Product similarity

One of the main considerations is the availability of similar products. For example, one of my most popular plugins is my WP e-Commerce Premium Shipping plugin. When I considered porting this to WooCommerce, I reviewed what was already available through WooThemes. Sure enough – WooThemes already sell their Table Rate shipping plugin which covers roughly the same set of features.

It takes a different approach, and the functionality isn’t a 100% match though. Being a believer in healthy competition, I decided that this wasn’t reason enough to not port the plugin to WooCommerce. However I didn’t think it would really make sense for both of those to be available in the same place – it would muddy the water too much – so I sell it myself, through my own store.

 2. Pricing

WooThemes (just like any other marketplace) take a percentage of sales made through WooThemes.com. For simple, or smaller plugins this can puts quite a lot of pressure on the selling price. For some of my plugins, I simply feel that a marked up price would make the plugin too expensive if sold through WooThemes.

3. Likely support overhead

As part of the WooThemes extension agreement, WooThemes provide first line support. If your extension is likely to have issues with badly coded themes, or is likely to raise many questions, then having a team available for support can be a great thing.

4. Eggs in baskets

As the expression goes: “Don’t put all of your eggs in one basket”

5. Customer ownership

Building up a list of customers allows you to market to them on an ongoing basis, cross-sells, up-sells, product updates etc.

If you sell through a third party marketplace, you might not have that opportunity, and you may be relying on the marketplace to market effectively to their customers on your behalf to drive further sales.

6. Route to market

For me, one of the biggest advantage to selling plugins through WooThemes is that they are a great route to market. If you’re a WooCommerce user, it’s likely to be one of the first stops when trying to find suitable plugins. Not selling through a well-known marketplace (whether that’s WooThemes, the EDD extension store, CodeCanyon or similar) means you have to build your own reputation, work on your own SEO, and driving your own customers.

If you’ve read my planning post, then you’ll know that I’m keen to maintain good schema.org markup, and existing review data. Hopefully you now know one of the reasons why …

7. Supporting the community

WooCommerce is a free plugin. I’d like to think that the money that WooThemes earn on the commission on premium plugins goes some way to supporting the ongoing development of WooCommerce – something that’s in extension developers’ interests.

Hopefully that provides some information on what I consider when deciding where to sell plugins.

The post To sell direct, or not? appeared first on Lee Willis.