I know that this one is going to get a little more technical than most, but after battling with WordPress over something that in retrospect just seems incredibly inane, I feel the need to pronounce my victory in a public forum such as this…
So on one of the sites that I’m currently revamping (and hoping to officially launch in May), I’m doing a lot with photo galleries embedded in pages … probably not using pages exactly the way that was intended, but it seems to get the job done so I’m not going to complain. Anyways, the trouble started when I wanted to introduce a related posts plugin that also accommodates pages – the plugin technically works great, however one tiny detail in the format that I wanted for the output really just managed to throw me for a loop.
Basically, despite my pages being nested – sometimes several levels deep – in the related posts output, I always wanted to see the top-level mentioned instead of a page’s immediate parent. For example:
Photo Galleries —> Food —> Watermelon
becomes
- (Photo Galleries) Watermelon
not
- (Food) Watermelon
So the trick here is that you can’t simply look to a page’s parent, you need to loop through all of its parents’ parents until you get back to the top. The good news is, there’s actually a function already in WordPress to do exactly this. The bad news is, it’s broken!
I discovered this the hard way after feeling triumphant one night about solving my problem, then getting up the next day to find that it was only sometimes working. Most of the time I would get the correct “grandparent,” but for one page in particular I got back a null value instead, despite seeing the hierarchy plain as day through the main admin interface. From there I tore apart the database tables looking for an incorrectly populated relationship, started from scratch with the function itself, and even tried deleting and rebuilding the page, thinking that it might be a problem from when the page was originally generated.
Nothing, until another day at random I happened across this page…
Apparently it’s a caching problem that was found almost two years ago, however obviously being not a very high priority just never got addressed. Fortunately in my case, though, a workable fix was found at the end of that thread – the basic solution was to run a function to clear that specific post out of the cache. Admittedly not knowing a ton about how WordPress’ cache works and not wanting to break something by constantly clearing the cache for every single post and page, I ended up doing something like this…
if ($post->post_parent) {
if (!get_post_ancestors($post->ID)) { wp_cache_delete($post->ID, 'posts'); }
$ancestors=get_post_ancestors($post->ID);
... }
At least this way the deletion only runs if the ancestry is already broken for a particular page. This is definitely the first time that I’ve ever had to dig this deep to root out a problem in WordPress … usually it’s a problem with my coding, not theirs! So anyways, that’s my story and all is now well in the universe – just had to share in case someone else one day stumbles across that same problem with get_post_ancestors() and they still haven’t fixed the bug yet…
Happy coding!