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.

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.

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.

Thanks to the great work that’s been going on in WP e-Commerce core – there are now a bunch of useful hooks and filters that allow the content to be changed by filters rather than by editing the plugin direct.

So – if you want to add the SKU to your order emails you can just install and enable the plugin below to add it for you.

The post Adding SKU to email notifications in WP e-Commerce appeared first on Lee Willis.

None of this is a criticism of WordPress, but as you start building larger, or more complex sites you’ll probably want to start smoothing off some of these rough edges, and make sure the language of the site (frontend or admin side) makes sense in the specific context of the site you’re working on.

That’s something I come across frequently in my day job as a Drupal developer. Fortunately Drupal has the excellent String Overrides module. This lets you specify the current string, and a replacement, and will change the text whenever that string is used, with the caveat that the original string has to be passed through Drupal’s translation function t().

When someone recently asked me how to change some text in one of my own WordPress plugins – my first suggestion was this exact same approach. After all, all of my Premium plugins use translatable strings, and suggesting to someone that they should create a translation file just to change one or two strings for their needs has always seemed a bit excessive. So – I had a hunt around the WordPress.org repo for something similar, but couldn’t really find anything that did the job.

Figuring it’d be something fairly simple to achieve I set out to knock up a plugin that did the job. So next time you need to quickly change a string in WordPress, or a plugin you’re using – don’t hack it in the plugin – or in WordPress core, leaving your client unable to upgrade, give “Say What?” a go:

The strings we want to change

The say what page – setting up our string replacements

The text – automatically replaced for us

The post How to change text in a WordPress plugin appeared first on Lee Willis.

So, I’ve also now published a plugin that will let you embed plugin summaries from WordPress.org into your posts and pages just by pasting in the URL.

Check it out here:

The post Easily embed WordPress.org plugin details into your posts appeared first on Lee Willis.

This post is just a quick walk through explaining the approach. In general the plugin:

• Registers an oEmbed handler for the selected URLs (http://github.com/{something} in our example)
• Registers an internal oEmbed handler for that URL
• Handles the oEmbed call itself, retrieving the details it needs via the 3rd party’s API and then passing WordPress back an oEmbed response

Effectively you make your own site an oEmbed provider for the service you want to embed. Here’s the key bits of code:

First – we register an oEmbed handler, and point it to an internal URL:

function register_oembed_handler() {
    $oembed_url = home_url ();
    $key = get_key();
    $oembed_url = add_query_arg ( array ( 'github_oembed' => $key ), $oembed_url);
    wp_oembed_add_provider ( '#https?://github.com/.*#i', $oembed_url, true );
}
add_action ( 'init', 'register_oembed_handler' );

Note: get_key() just generates a site-specific key to stop other people using your oEmbed service.

Next, we tell WordPress to look out for an inbound oEmbed request:

function handle_oembed() {

    if ( ! isset ( $_GET['github_oembed'] ) ) {
        return;
    }
    // Check this request is valid
    if ( $_GET['github_oembed'] != $this->get_key() ) {
        header ( 'HTTP/1.0 403 Forbidden' );
	die ( 'Sad Octocat is sad.' );
    }

    // Check we have the required information
    $url = isset ( $_REQUEST['url'] ) ? $_REQUEST['url'] : null;
    $format = isset ( $_REQUEST['format'] ) ? $_REQUEST['format'] : null;

    // Call the 3rd party service, and create an oEmbed response here

}
add_action ( 'init', 'handle_oembed' );

All we need to do now, is retrieve the details we need using whatever API tools are available, then create an oEmbed response, e.g.

    $response = new stdClass();
    $response->type = 'rich';
    $response->width = '10';
    $response->height = '10';
    $response->version = '1.0';
    $response->title = $repo->description;
    $response->html = 'Your info here';
    
    header ( 'Content-Type: application/json' );
    echo json_encode ( $response );
    die();

And that’s it in theory, simple as pie. If you want to see working example, checkout out the github embed plugin on github:

The post Simple embedding for non oEmbed services appeared first on Lee Willis.

Instead, WordPress’ oEmbed support allows you to simply paste in the URL to the page from your browser, and WordPress does all of the hard work contacting the provider and agreeing how they can embed it.

I wanted to use this to embed a summary of a GitHub repository, but unfortunately GitHub doesn’t support oEmbed – although they do have a fairly simple API that can be used to retrieve information about the repository.

I could have written a shortcode to interrogate the API, but I wondered if I could achieve an oembed style user experience instead. The result is the Github Embed plugin which is available from WordPress.org. The plugin allows you simply to paste in the URL to either a GitHub profile, or a repository, and have information embedded into your post automatically.

As you might expect, the plugin is also hosted on GitHub, and is embedded below …

It needs a bit of UI love, and pretty sure it can show some more useful information, but it’s usable now.

The post Embed Github repo information in WordPress appeared first on Lee Willis.

In most cases this is down to one of two issues:

• An incompatibility of PHP version – the plugin requires PHP 5.2 or above.
• Incorrect API details – the plugin needs to use the Account ID, and List ID, not the Client

So – these should always be the first things to check. If you’re still having problems, then the guide below explains how to see what error messages are being generated. To diagnose this you’ll need a copy of “Firefox”, and the “Firebug” extension. (Note: You can also do similar with Chrome, and its developer tools if you know your way around them instead).

To start, open the page with the widget on, and open up firebug. Switch to the “Net” panel – you should see something like this (Click for bigger version):

Submit the form, and you should see a “request” logged in the net panel – it’s an HTTP POST request – so should start with POST, like this:

Click on the + symbol to the left of the POST to see the details of the request:

Click on the “Response” to see what data the AJAX POST is outputting – the error message should give you an idea of what’s not working.

The post Debugging Problems with the Campaign Monitor Widgets appeared first on Lee Willis.