WordPress has some amazing features and a pretty robust plug-in system that allows coders to extend it way beyond the base functionality. However the plug-in system is often poorly documented and is by no means complete.
This post is going to review some thoughts I’ve had while developing the Schedule Posts Calendar plugin.
The idea is pretty simple really, by default when WordPress wants the user to enter a date it presents a series of html controls as such:
This is ok, but if you are trying to schedule a series of posts and want to change the date from this Friday to Monday in three weeks, it’s kind of hard without having a calendar handy.
The idea behind the Schedule Posts Calendar plug-in was simply to replace the default WordPress controls with something better.
The first couple of versions of the plug-in focused on the post and page edit pages in WordPress, these pages have a publish time that uses the default WordPress controls and was the most common place I personally used them.
The next trick was getting the calendar control inserted in to the page. This was actually a little easier than I thought it would be as WordPress has identified a lot of its page layout elements with id’s, including the calendar controls.
Once inserted the control updates the original WordPress controls each time the user clicks on a new date or time.
Version 2 of the plug-in added two significant pieces of code, a pop-up calendar (instead of an inline one) and preferences support.
The pop-up support required a different control to be inserted in the page and along with the preferences required some way to configure what the user wanted.
The previous versions of the plug-in focused exclusively on the edit pages in WordPress, however there is another place where the calendar control is used and that is in the “Quick Edit” on the posts and pages lists.
The next option I looked at was that WordPress does have a hook to add additional content to the Quick Edit menu. This seemed like a good idea, so while I would not be able to replace the existing calendar controls, I would be able to add new ones and hide the old ones. However, one of the “features” in WordPress is that to add items to the Quick Edit menu, you have to add columns to the posts/pages list.
Now I can see the logic here, you add a column to the list and then you need to add some additional items to the Quick Edit menu. However that is a pretty limited view of the functionality and it would make more sense for these hooks to be completely separate. As I didn’t have any requirement to add an additional column this option didn’t work for me either.
The final option (and the one I’ve gone with) was to leave Quick Edit alone and create a new “Schedule” option that behaved much like Quick Edit but was completely separate.
There are of course some new hurdles to overcome:
- Inserting new rows in to the posts/pages tables
- Deleting rows from the tables
- Updating the hidden values Quick Edit uses
- executing the update through AJAX
I mentioned earlier that WordPress does a pretty good job of using id’s to mark their pages up for easy reference later. However the Quick Edit mode is one exception I’ve found. WordPress uses some hidden div’s to store the time/date in for each post but does not add id’s to the div’s so you have to walk through them one by one until you find what you’re looking for.
So I knew I would be updating them again later, when I find them the first time I’ve added unique id’s to them. This may break things in a future version of WordPress, but I’ll gladly update the code if it does ;).
The biggest hurdle was the AJAX update, there were multiple issues here:
- jQuery conflict
- Required fields
- Inline edit
Fixing this required using the noConflict version of jQuery, which looks a little ugly, but seems to work just fine.
The second issue was find out which fields were required to do an update, it turns out you have to include the post id as well as any fields you are updating.
The final issue was that WordPress checks some kind of unique value when receiving an AJAX request, which turns out is stored on the page in a div with “_inline_edit” as the ID.
Adding all of this together and submitting the AJAX request succeeds in updating WordPress.
As a final step, you have to update the hidden div’s that we tagged earlier with the new date/time info so if the user want to Quick Edit the entry after scheduling it, Quick Edit will have the right time/date.
WordPress has an amazing array of options and extensibility, but you can still see some of the patchwork nature of it when you want to do things that are a little bit outside of the core.
Likewise support across browsers is weird and flaky, testing is key if you want anything to work.
I hate this library with a passion, it seems to be everywhere but so poorly documented and breaks without any easy way to figure out why.
Honourable Mention: Opera Dragonfly