If you’re a theme developer, you’re probably aware of the bits and pieces you need to look out for to have your theme be compliant with WordPress standards, for example in order to get it to appear in the wordpress.org themes repository. A theme is pretty much a separate unit within the infrastructure of a WordPress setup, it uses several specific functions that WordPress core provides and may also use some markup that is already part of core, such as a default search form or pagination. What is less commonly known though is that there are also things to look out for to make your theme fully compatible with the Multisite feature of WordPress. It’s nothing complex for most cases, but it is often overlooked. I’ll highlight the two special requirements in this post.
The reason I’m writing this post is that I recently encountered a related bug with the Twenty Seventeen theme. So really, if you haven’t taken care of this before, don’t worry. It’s nothing too critical, and even the latest default theme apparently has some problems there. But being aware of these Multisite-related parts should make sure your future themes (and updates) can be compliant so that Multisite users are happy. 🙂
In the first paragraph I highlighted that usually a theme uses some functionality or markup that WordPress core provides. There are two parts in Multisite however, where it’s basically WordPress functionality that uses functionality and markup that your theme provides – so it’s the other way around here. Let’s dive into the details: I’m sure you’ve previously seen the files wp-activate.php and wp-signup.php, which are located in the root directory of a WordPress installation. These files both exist to handle new registrations in a Multisite. If your setup has registrations enabled, you can access these files directly via their URLs, as they render actual pages handling registration functionality. You will recognize that they for the most part appear in your active theme’s design, and this is exactly what you need to be aware of: Both of these files use your theme’s header and footer (by calling get_header() and get_footer()) as well as any scripts or stylesheets enqueued by it. They render the main content of the page themselves though. How much effort you put into optimizing your theme for these two pages is obviously up to you, but you should at least make sure that they render in an acceptable way, i.e. that the layout is not broken. In many cases, this will be the case by default, so you only need to have a look to verify that. But sometimes, if your theme does more custom things, some minor tweaks might be necessary. This is exactly what’s the case for Twenty Seventeen, as the layout appears broken in wp-activate.php, and there is also a JavaScript error message caused by the theme (see the Trac ticket for more information). In many cases it’s only the stylesheet that needs to be adjusted in case something is off, but if further tweaks are required, you can even create custom header and footer templates for these files: If your theme includes a header-wp-activate.php / header-wp-signup.php, it will be used on the respective page instead of the theme’s default header template. Similarly you can also use a custom footer template by including a footer-wp-activate.php / footer-wp-signup.php respectively.
Note that the code in these two files is rather terrible as it’s legacy code which has been around for a long time. It’s certainly not optimal that your theme has to integrate with these pages in their current state, which can cause unexpected issues. But they’re there for now, and I highly recommend you to check your themes to be compliant with them – a small detail only, which however can raise the quality of your themes.
Leave a Reply