Oh my
Alright, so that was probably a bit much but I couldn’t come up with a better way to start the post. Not to mention this is probably the closest I will come to having a harrowing or cautionary tale to post, though this really is neither. What it is is what happened when I went to update the one plugin I maintain for what should have been a simple change.
Custom Post Types
When custom post types were introduced in WordPress 3.0 my first inclination was to simply respond to no one in particular, “thats neat.” It wasn’t until I had gone through this article by Justin Tadlock that I started to wrap my feeble little mind around how this was going to affect the sites I built in WordPress. Gone were the days of hijacking a category or tag to segment out specific posts to be treated differently than the rest of the blog. No more pages being created simply to be parents for pages that were to be pulled out and displayed differently. Now all that needed to be done was register a new custom post type and any custom taxonomies or post meta that need to be included. With the update to the default link tool that allowed for linking to custom post types they became just another part of the planning phase when mapping out a new site.
Multisite
Another notable addition in 3.0 was the inclusion of the previously separate WPMU, giving developers the ability to more easily create a multisite network. Unlike custom post types this made sense to me at first read, though I couldn’t at the time think of a reason I would have to create a network. When I finally had the opportunity to work on a site large enough to warrant creating a multisite install I realized I didn’t know as much about custom post types as I had thought.
Thats not to say that everything I had read to that point wasn’t enough for me to understand how to setup and work with custom post types, I just hadn’t though of how WordPress saved and accessed those registered post types. Working on a multisite install with a single theme for each “site” I realized that the custom post type information was read out of the file in which it was created. Which in this case meant that every site in the network could see all the custom post types, registered in the theme functions file, whether they were supposed to be able to or not. Having stalled in writing what became the Link to Your Content plugin the only concern that raised at that point was hiding those custom post types from the sites they weren’t supposed to be on.
Link to Your Content
When it came to working on the Link to Your Content plugin I tested it in the environments in which I would be using it, including the multisite setup mentioned above. Everything worked fine so I felt confident in releasing it to the WordPress repository and waiting to see what problems, if any, appeared. And one did, though it was not related to custom post types so I never gave that functionality a second thought figuring it worked. Perhaps I should have used the work assume in that previous sentence as the old saying holds true in this case.
Going to update the plugin for WordPress 3.3 I set up two new testing environments for the development of this and other plugins. The multisite setup had no custom post types so I went and downloaded Types to quickly create a few to complete testing on the supposedly easy update. Thats when I ran into the issue that caused more than a few expletives to be blurted out – custom post types created on a site in a multisite network with a plugin, or a theme running on just that site, are not accessible through WordPress functions from another site. Which wouldn’t be a problem if one of the main features of the plugin wasn’t linking to custom post types from one site in a multisite network on another.
Version 1.5
It makes sense that in a multisite network one site wouldn’t have access to the files of another site as one of the primary uses is to create a network like WordPress.com. Thats not to say that the information isn’t accessible cross site, but the switch_to_blog() function only allows access to database information from one site to another, and understandably so. And in that lies the solution implemented in version 1.5, a winding trail of switching from site to site to get the necessary information for linking to custom post types (and taxonomies).
Conclusion
As stated previously, its not exactly a cautionary tale but it is why the plugin is the way it is and why in the future I wont procrastinate so long before making updates, even “easy” ones. Of course the next update, adding in search capability, will probably go a lot more smoothly. C’est la vie.
Pingback: wp multi sites | Pearltrees