Some pretty simple things people don’t realise when dealing with WordPress

Nobody Remembers the API

A lot of people worry that they don’t know the API, that it will take them a long time to memorise everything.

Nobody memorises the API.

It changes too fast, it’s too big, and it’s a waste of time when you have google. Honestly, every developer I’ve ever worked with regardless of skill has relied heavily on codex lookup tools, reference spread sheet, cheat sheets, search boxes, helper plugins, and an enormous amount of quick googling to figure out what a functions arguments are, or what the function that does X is called.

Ofcourse it’s good to read the API, just don’t expect anything but the functions you use most to stick around longer than an hour, so don’t stress about it. Just google for things, it’s what everyone else does

Taxonomies don’t have to use posts

Taxonomies and terms deal with IDs. Not post IDs, just IDs, and what those IDs are is determined by context. So it’s perfectly possible to have a user taxonomy, or even a term taxonomy, just pass in a user ID or a term ID instead of a post ID.

If you have pretty permalinks turned on, these special URL redirects are activated, and require no additional plugins. A lot of people ask how to implement this without realising that it already exists.

All queries are WP_Query

The get_posts function uses WP_Query, the main loop is a WP_Query, query_posts uses WP_Query, they’re all glorified wrappers around this class. Which is why I have its codex entry up half the time I work so I can look up what args to use to get different things.

PHP Has Error Logging

A 500 error is your servers way of saying “something went wrong, I don’t know what it was but here you go”. From this people decide that PHP must not have any error messages, and start printing things to the front end when they want to debug.

What’s actually happening is that there’s an error log file somewhere listing everything that happened, if you only look for it. You can print errors to the frontend too, using WP_DEBUG.

It’s easier to Use the AJAX API

Plenty of people add a php file to their theme or plugin for AJAX calls, then throw in an include that goes up 5 or 6 levels to include the WordPress environment. The alternative is a small amount of copy pasting that gives you a function you put your stuff in and hey presto, AJAX done.

There’s a dedicated API for theme settings

Instead of using add_option and update_option, use get_theme_mod and set_theme_mod.

set_theme_mod( $name, $value );
get_theme_mod( $name, $default );

WordPress will tidy it away when you change themes and restore it when you come back, and make sure it doesn’t clash with other option names.

Menus & Menu Items are Actually a Custom Post Type

That’s why they take so long to save, each menu is a taxonomy term, and the menu items themselves are menu_nav posts etc

This means they also have post meta/custom fields, and can be given things like featured images etc

To use all of this though you would need to implement your own custom walkers on the front and back end to add the UI editors and display the parts.

Comments have Meta too

You can add meta to comments, be them extra tags, attachment IDs, the only issue is you need to implement the User Interface to handle this.

Coincidentally, there’s nothing stopping you from creating a comments taxonomy, just like you would a user taxonomy.

Hopefully this was useful to you, and keep in mind there are a lot more of these out there, some glaringly obvious and so simple it just doesn’t occur to most people. Things always look more complicated than they actually are when you’re new, and seasoned professionals miss things too.

1 thought on “Realisations

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.