Category: Blog

Updated 02 – 05 – 18: plugins object is now returned as an array.

On a whim this May bank holiday, tucked up on the sofa watching movies, I decided to create a plugin to display my favourited plugins on WordPress.org.

After a bit of digging I found you can use the plugins_api() function and pass it a username, e.g.:

plugins_api( 'query_plugins', array( 'user' => emirpprime, 'per_page' => '-1' ) );

This returns an object with some information about the results, then an array of plugins. A stripped down example of the structure is below:

stdClass Object
    (
    [info] => Array
        (
            [page] => 1
            [pages] => 0
            [results] => 57
        )
    [plugins] => Array
        (
            [0] => Array
                (
                    [name] => Autoptimize
                    [slug] => autoptimize
                    [version] => 2.1.0
                    [author] => <a href="http://blog.futtta.be/">Frank Goossens (futtta)</a>
                    [author_profile] => https://profiles.wordpress.org/optimizingmatters
                    [requires] => 4.0
                    [tested] => 4.7.5
                    [compatibility] => Array
                        (
                        )
                    [rating] => 94
                    [ratings] => Array
                        (
                            [5] => 419
                            [4] => 23
                            [3] => 12
                            [2] => 8
                            [1] => 22
                        )
                    [num_ratings] => 484
                    [support_threads] => 121
                    [support_threads_resolved] => 81
                    [downloaded] => 1349088
                    [last_updated] => 2016-12-14 5:45am GMT
                    [added] => 2009-07-09
                    [homepage] => http://blog.futtta.be/autoptimize
                    [sections] => Array
                        (
                            [description] => Autoptimize makes ...
                            [installation] => Just install from your WordPress...
                            [faq] => Installation Instructions...
                            [short_description] => Autoptimize speeds up your website and helps you save bandwidth by aggregating and minimizing JS, CSS and HTML.
                            [download_link] => https://downloads.wordpress.org/plugin/autoptimize.2.1.0.zip
                            [screenshots] => Array
                                (
                                )
                            [tags] => Array
                                (
                                    [css] => css
                                    [html] => html
                                    [javascript] => javascript
                                    [js] => JS
                                    [minify] => minify
                                )
                            [versions] => Array
                                (
                                    [0.1] => https://downloads.wordpress.org/plugin/autoptimize.0.1.zip
                                    ...
                                    [trunk] => https://downloads.wordpress.org/plugin/autoptimize.zip
                                )
                            [donate_link] => http://blog.futtta.be/2013/10/21/do-not-donate-to-me/
                            [contributors] => Array
                                (
                                )
                        )
                )
        )
)

A simple loop over the plugins array will get all the details about a plugin you could want.

A short while later, and a rough and ready version is complete – a basic plugin that registers a shortcode and returns a list of a user’s plugins.

What does the plugin output?

Here are my favourites as an example – the markup is basic but easy to style, with a couple of classes for targetting. I’ve kept it simpler than the layout in wp-admin or the plugin repository, but hopefully with enough info to be useful:

Found: 64

What do you think? Is there any other info you think would be useful to include? Let me know in the comments.

Fancy sending your WordPress site back (or forward) in time for a day? Thanks to the multitude of filters it only takes a few lines of code. In this example I’m just going to filter the_time(), but in a future post I will also show you how to put together a more comprehensive function that uses multiple filters (and has a more practical use).

The filter for the_time() passes two values in – the value it was going to display, and the formatting string used to create it.

Hooking in to the filter

This is fairly standard – pass the name of the filter we are using to the function add_filter(), along with the name of our custom function that is going to modify the value:

add_filter( 'the_time', 'cc_time_machine' );

However, since we need both of the arguments that the filter passes, we have to add in the optional values for ‘priority’ and ‘accepted arguments’. The default priority is ten, and as mentioned there are two arguments – so that gives us:

add_filter( 'the_time', 'cc_time_machine', 10, 2 );

Travelling in time:

Now we can receive the data in our function and modify the value. None of the arguments relate to the ID of the post being dealt with, but we can use the global `$post` variable to retrieve it. Then we use the get_the_time() function to retrieve the date/time of the post in timestamp format – this makes it easy to manipulate. Let’s send everything 30 days into the past:

$timestamp = get_post_time( 'U', true, $post );
$adjusted = $timestamp + ( -30 * DAY_IN_SECONDS );

Finally, we need to return the new value. Utilising the second argument ensures we format the date in the same way as it was originally requested:

return date( $format, $adjusted );

The complete function:

N.B. this version reads the time travel value ($offset) from the database so it can be controlled through wp-admin.

WordPress has a handy get_terms() function that retrives a list of all the terms for a taxonomy – this is great if you are, for example, building a <select> box for filtering a custom post type listing page. But there’s one big problem, if you use this on a shared taxonomy, it will show all terms even if they aren’t used on the particular post type you are dealing with. There is a hide_empty argument that you can pass to get_terms, but this only excludes terms that aren’t used for the default “post” post type.

What to do about it

Facing this today, I ended up with this little snippet that utilises a $wpbd query along with get_terms to achieve what we want:

• First it uses a nested select query to get the IDs for all posts in our custom post type, this is then immediately utilised by the outer select query to grab a list of term IDs from the term_relationships table
• Then this list of IDs is passed into get_terms
• Finally it’s output to build the select box

You’ll also notice in there it is being cached as a transient for 4 hours. Depending on the nature of your site and server you might not need this, or may need to adjust the duration.

The key parts to modify if you want to utilise this is post_type='cpt' on line 8 and 'taxonomy' => 'country' on line 9. These set the custom post type you want to retrive terms for, and the name of your taxonomy respectively.

Garlic.js is a great library – it uses localStorage to save the state of forms, so if your users accidentally close the tab or browser before submitting, their entry isn’t lost. This works seemlessly for almost all form elements, however WYSIWYG editors like TinyMCE present problems. Luckily it isn’t hard to fix – there’s a comment on the github repository for the project with the snippet you need to add to the init function:

setup : function(editor) {
    editor.on("change keyup", function(e){
        console.log('saving');
        //tinyMCE.triggerSave(); // updates all instances
        editor.save(); // updates this instance's textarea
        $(editor.getElement()).trigger('change'); // for garlic to detect change
    });
}

So far so easy. But today the challenge was a little harder as WordPress was in the mix too.

At Helpful Technology we have a training product called Crisis90 that allows users work through a scenario and compare their responses. It is built on WordPress and makes use of GravityForms to allow users to submit responses to the crisis scenarios presented (there’s also a simulated Twitter environment for practicing real-time responses). When asking users to draft a press release, for example, we provide a WYSIWYG editor – this is native to GravityForms which in turn leverages the bundled TinyMCE library in WordPress. But this means that TinyMCE is being loaded automatically without me being able to modify the init function. Luckily there is a filter for that – tiny_mce_before_init. This filter lets you modify the settings array used to initialise TinyMCE. Despite the lack of a setup item in the defaults or example, it is perfectly valid. You can use this filter in a simple plugin or in your theme’s functions.php:

As you can see, we’re just adding a setup key to the $settings array containing the snippet from above. I’ve also included a little check that we aren’t in the admin area as I only want this to apply to the instances of TinyMCE used in forms on the front-end of the site.
Now Garlic.js will function correctly with TinyMCE, and a slip of the finger won’t lead to any lost work.