Skip to content

Tag: Software

Sometimes I really hate software…or maybe just Wordpress

I’ve been struggling for a while to get some kind of workflow in place to track and organize my posts on my photography site. Just having a pile of drafts with no real order to them was causing me to lose things that were almost complete but needed a finishing touch to two. Then I cam across the plug-in Edit Flow which seemed like the a good solution to my problem. It would let me create custom post states (i.e. draft, pending review, etc.), which I could then use to organize my content as I was developing it.

Only problem, Edit Flow’s developers apparently do something with Wordpress’ post_date_gmt field, which Wordpress uses to indicate whether a post is scheduled or not, and what date ot post it on. Because of this, they have a function that runs to normalize the post_date_gmt instead of leaving it to Wordpress’ devices. As a result, Edit Flow basically breaks the publishing and administrative post display behavior built into Wordpress.

Now I’m not sure which is a worse actually.

Wordpress really should have a post_on_date field for each post that controls the scheduling. If it’s set to null—and yes, null is a perfectly appropriate value to represent not applicable, more so than ‘0000-00-00 00:00:00‘ is at least—then the post isn’t scheduled to be posted and Wordpress should behave as if it’s a publish immediately type of thing. On the other hand, if there’s a date stamp in the field, then that’s when the post is scheduled to be published, assuming it’s status is set to publish or scheduled.

Going off on a slight tangent here the date situation in thewp_posts table is simply ridiculous. Granted dates suck, the whole time zones, daylight savings, etc., etc. makes dealing with dates a minefield for even the most experienced programmers. That said, pick a standard and stick to it, either store all the dates in GMT or store all the dates in local time, or GMT with an offset (i.e. YYYY-MM-DD HH:MM:SS ±OFFSET). The rest can be handled though the intermediate code (either at the DB level with stored procedures, views, or dynamic columns) or in the API side though the functions presented to the users.

Getting back to the rant…

Of course the Edit Flow developers instead of working around the issue, say by building their code to GMTify the post_date field, or creating a new field, or storing things in another table, decided to appropriate the post_date_gmt field for something without much concern or though—at least it seems that way—for the fact that doing what they do break Wordpress’s default behavior. I’m sure they had their reasons, and personally I don’t know if I really care what they were, but I really hate people that do things in a way that breaks the functional, if quirky, default behavior unless the point is to deliberately change that behavior. Nor do I think that deliberately breaking the default behavior was their intent.

Oh and how do I come across this little gem?

I was writing a plug-in that would reset that the “scheduled/post on date”. Why isn’t this native functionality, though? It sure as hell should be.

Slight side tangent: What’s worse that it not being native functionality, is the insultingly ridiculous work around that’s trotted out when you Google for how to unscheduled a post in Wordpress. Here’s what your “supposed” to do: Change the date the post is scheduled to be posted on. That’s been the work around for at least a couple of years now to boot, even though there seems to have been patches submitted that fixed it almost 2 years ago.

Back to where I was, ya, so resetting the “scheduled post date” back to “post immediately” is actually as simple as zeroing out the post_date_gmt field, which is a rather trivial task to write a plug-in to do. (Yes, when I’m sure there aren’t any unintended consequences for doing what I’m doing and the code is the way I want it, I’ll probably release the plug in here, under my typical “You can use it, but don’t ask me for help” type license.) Well, at least it would be trivial if there was good documentation available. Instead, you’re left to do something like this.

Google a post hook that sounds about right, or visit this page or this page. Find something that looks reasonable, and then visit here to see where the hook occurs in the Wordpress source code or just grep though the source with something like grep -R 'action_hook' * | grep 'do_action'. Open up the source file, find the function and the hook call, and see if there isn’t a more appropriate action to hook into. In this case there isn’t, I can’t hook into pre_post_update because it doesn’t have a way to modify the post object before it’s put in the DB and doing the DB manipulation directly at that point would overwrite the operation.

Speaking of dropping down to writing the SQL, seriously Wordpress guys, I can do in 5 SQL statements what takes 50 odd plus lines of PHP and god knows how much more code and queries between the function calls and manipulating the data. Should I, or anybody else, do that? Probably not, but damn if it’s not an attractive proposition.

So what have I learned form this?

On one hand, I  can’t imagine giving up Wordpress now that I’m familiar enough with it, that I can actually make it do what I want on a programmatic level. Moreover, the fact you can get plug-ins to do so much (I picked up WYSIWYG Inline Code Command in the process of writing this to save having to drop to HTML to wrap bits in <code></code> tags), makes it real attractive to keep dealing with the annoyances.

On the other hand, some things really make me want to fork Wordpress and re-implement it in a more clean, extensible, clear, way. Then again, I don’t really want to release my plug-ins because I don’t want to feel obligated to support them after I solve my problem, dealing with a major 1100+ file 170,000 odd line (by my count) code base. Such is life.

Broken Features are Worse Than No Features

When it comes to software providing a feature or function that’s broken  is worse than not providing the feature at all.

Let me weave the story of broken functionality from this weekend.

Google’s Apps for Domains provides 2 ways to reset your administrative password, either you have an alternative address configured and a check-box checked allowing Apps for Domains to reset your password using that address. Alternatively, if you missed that configuration option you can go though an alternative process that involves creating a DNS record with a value provided by Google to verify that you own the domain.

From what I’ve gathered, the functionality is suppose to work like this; you create a CNAME record with a value provided by Google and point that at google.com. Google’s system is then supposed to look up that CNAME record and verify that it points to google’s domain. If it does, the instructions for resetting your password are sent to the email address you provide when you go though the recovery process.

The problem is, the system is broken right now.

What should happen, and what’s actually happened are two different things. In reality I’ve received 2 automated responses form Google indicating that the system couldn’t verify the CNAME record. After searching the Google Apps support forums it turns out that the CNAME method is currently broken and that Google is aware of the issue but hasn’t bothered updating anything on their site to note that or temporarily disable the function.

Since the functionality was present and failed in the same way one would expect it to fail if you had simply configured something wrong the result is spinning your wheels with no results. If Google had disabled the functionality or provided a link to their support request system in the resulting email, I could have at least opened a ticket after the first failure instead of going though the process again double checking everything.

the least they could have done was provided a link to their support ticketing system. The worst possible thing to do to a customer is make it look like their spinning their wheels. In this case at a minimum the auto-reply email for a failure should include a way to open a ticket on the issue instead of just sending you back to the same process with a generic error.

The moral? If you’re a developer and you realize that some functionality you’re providing isn’t functional, disable it until you’ve fixed it. If that means you have to deal with more support tickets for a while so be it. This is even more important in a customer service situation like resetting a password.

Needless to say, if you use Google Apps for Domains and your administrator account doesn’t have a secondary email address that can be used for resetting the password, set that up post haste. On top of that, it might not be a bad idea to create a second administrator account with a long random character password that’s stored in a safe place. With a second admin you could use that to log in and reset the primary admin account’s password as well.