Full stack web developer, interested in all the things, but especially the web, code, design, Linux, OS X, PHP, WordPress, JavaScript & robots.

Snippet Language: php

Conditionally include additional CSS and JavaScript for page templates in WordPress

I’m currently working on a large’ish WordPress theme that has a number of custom page templates. The custom page templates require their own CSS and JavaScript files, so I’m using the following code to enqueue the additional files. This allows for a file structure like so:

themes/mytheme/page_template_foo.php // custom page template
themes/mytheme/css/page_template_foo.css // additional CSS
themes/mytheme/js/page_template_foo.js // additional JS

The code should be self-explanatory, but see the comments for explanations as to what’s happening.

Notes: this method increases overheads as it tests for the existence of files, if you’ve only got a couple of custom page templates, you’d be better off hardcoding. That said, if you’re using caching it shouldn’t be a big deal. Also, unless you’re using HTTP/2, you’ll probably want to use something like Autoptimize to concatenate the CSS and JS files.

A Simplified WordPress TinyMCE Editor

Sometimes, you might want to remove a few buttons from the WordPress TinyMCE editor. There could be a whole bunch of reasons for wanting to do this, but I’m not going to get into that just now. Anyhow, it’s good to know that you can make a simplified TinyMCE user interface, if you want/need to.

The following function and call to add_filter() will do just that.

You could use the above in your theme’s functions.php file, or wherever you deem fit, and it should result in an editor that looks similar to the image below (note the number of buttons).

A Simplified WordPress TinyMCE Editor

A simplified WordPress editor.

More information about removing buttons from the WordPress TinyMCE editor can be found here.

Abusing the WordPress REST API

Earlier, I was playing around with the WordPress REST API and I was struggling to figure out why the WordPress function is_user_logged_in() was not working with my custom endpoint. The function returns false regardless of whether the user is logged in or not. Turns out, this is by design and I needed to send a nonce within my endpoint request. Doh.

Anyhow, before I figured this out (RTFM, Philip), I came up with a rather fugly workaround. The hack was to add an action to the rest_api_init hook, call the is_user_logged_in() function and set a global variable, which could then be accessed from within the endpoint. Now, I’m not sure I would recommend using this hack, but it did occur to me that there could be a scenario where it’s not possible to send a nonse with the request, in which case the only way to test if the user is logged-in would be within the endpoint’s code.

How bad am I?

WordPress Pagination Fix for Loop with Custom Post Types

I’ve recently combined my WordPress custom post types into a single loop on my homepage. The code to do this was fairly trivial and well documented.

However, using the above function by itself caused a problem with pagination. Basically, the pagination routine did not seem to be aware that I was combining my custom post types and only counted regular posts. This meant that if I paged past the number of regular posts, I would hit a 404 error. To fix this, I’ve included the following function in my theme’s functions.php file.

The function tests for paging and whether or not the custom post type is set. If paging is set and the custom post type is not set, it will push a value into the query string to force the loop to count all post types. I’m not sure if anyone else will find this useful, but I thought I should post it.