So in between battling puppy pee, I’ve also been fighting with regular expressions for the better part of the evening. To summarize, I hate regular expressions. I just don’t get the logic, never have, and just when I think something makes sense, I’m told that I forgot like eight different escape characters or special circumstances or whatever and I feel like I’m back at square one.

With that said, after my last geeky code post of this nature, I decided that I want to get in the habit that when I fight with something long enough, I at least post about it online, both to vent and also to share in case someone else encounters something similar in the future!

Anyways, the scenario is this – working in PHP with WordPress, writing a custom category template for a new site I’ve been building. In this case, I needed to be able to pull the first image tag out of a post so that essentially I could create a category view that simply showed POST TITLE/DATE/ETC, IMAGE, MORE LINK TO VIEW ENTIRE POST.

Quickly, the caveats:

1. I know that there are plug-ins to do this, however using code directly in the template is far more efficient because this will really only affect a fraction of the posts.
2. Those plug-ins basically just parse out the tags, which won’t work for me anyways because I’m using NextGen Gallery for my images, meaning that the syntax stored in post is a shortcode like this – [singlepic id=123 w=550 h=413 float=center].

I fought with regular expressions for hours upon hours, but finally managed to come up with this:

(searching for this tag)
[singlepic id=123 w=550 h=413 float=center]

preg_match_all ('/(^\\[.*?\\])/is', get_the_content(), $matches);
$image = $matches[0]; $image = $image[0];
echo do_shortcode($image);

Basically it just looks for a tag in brackets at the very beginning of the post, which is my default format, however also meaning that it won’t get caught on anything if for whatever reason I end up using additional tags later on in the post. The first function does the actual search through the post content and throws the results into an array ($matches), with the second line extracting the tag out to a single variable and the final line executing it as a WordPress shortcode.

I’m still not entirely sure why I have to do line #2 twice – I guess between the preg_match_all() function and the data, it ends up as an array within an array, but after literally four hours of staring at this stupid thing, what you see above is officially the point where I said, “It works – good enough!”

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!