Linking to Next and Previous Pods

Howdy @jhabdas,

Actually, Pods Custom Post Types work just like WordPress Custom Post Types. I think the difference you’re running into is that the one in your website that is working is a direct custom post type archive ‘gang’ and your ‘neighborhood’, ‘housing project’ and ‘suburb’ might be taxonomy archives, possibly.

If that’s the case, this article might shed some light into the issue you’re having: https://bucketpress.com/next-and-previous-post-link-in-same-custom-taxonomy

or possibly this one: https://wordpress.stackexchange.com/questions/222498/is-it-possible-to-get-a-previous-next-taxonomy-term-archive-url

If it works for one custom post type ‘pods’ and not others, then it has to be something is different about those other ‘pods’. We treat ‘pods’ as ‘content types’ but use them to organize Custom Taxonomies, Post Types and Extended WordPress Objects.

Let me know if the above helps!

I know you guys are short on support time right now, Jim, which is why I verified ahead of time all suggested are custom post types, and not any other type of Pod. I spent time looking through pod settings with Gang (working) and one one of the other custom post type pods via Pods Admin and, at surface level, everything is identical.

Is there a place in the database or plugin code I should start looking?

Thanks for that, Josh. Yep, just needed to know they’re all Custom Post Types, so we can rule out the Taxonomy as the issue.

There must be something different amongst them. Check the Advanced Options setups since that correlates to what is sent to register_post_type. Specifically, look at Archive setup.

Thanks for the quick response. I ran though each of the custom post type pods and verified each of them is using Archives under advanced settings consistently across the board. The only differences I spotted are:

– One custom post type is hierarchal
– Housing Projects has rewrite slug as 301s wasn’t taking after Pod rename

Also, as a quick sanity check for you here’s an image showing confirmation of the Pod types for each of those mentioned: https://supload.com/S1zCr6-K-

I realize you’re working in a black box here. If you have any intuition as to where I can look that’d be a great place for me to dig into code or the setup. Otherwise perhaps I could get creative with a Related Content section instead.

Is Alliance working? I’d say reach out to your theme developer if it’s a premium theme and see if they can point you to anything specific to look at. The fact it’s not showing the options at all, makes me think ‘theme’ as opposed to post registration.

It is not the theme. Septera does it the same as any other.
Looking at his page source, the link locations and mark-up are there from the theme, except that the WP functions previous_post_link() and next_post_link() are returning nothing. So no links show up.

It is a WordPress thing, as WordPress is not seeing these posts as related in a next/previous kinda way.

@jhabdas, You mentioned that one post type is hierarchical? Which one?

As Caleb suggested, and as mentioned earlier. Very native WP functions. It’s Pods or WP internals. I just don’t know where to look.

Alliances are hierarchal because they have sub-alliances. I’ll keep digging and let you guys know what I figure out.

Next steps are to review Alliances more closely as I haven’t checked those pages yet to see if they exhibit the issue (I’ve chosen not to display them for now due to sparse content). If Alliances don’t see the issue I’ll assume there’s a pods bug with renaming Pods somewhere, and look at the DB to see if I can hack it.

Worst case scenario I recreate stuff—but that’d take forever as I have about 8 taxonomies connecting all those Custom post Types, and each custom post type has between 13-96 items—took me 2 weeks to wire it all together.

Thanks so much for your help, Jim! It’s worth it. All of it. Pods is AWE.SOME1!

This is definitely not an area of my expertise (the next_post_link() and the previous_post_link() as when I’ve had a theme that uses it, it just ‘works’ as @crudhunter suggested, this is a WP Native function. If you had archives disabled, I’d see that as a potential issue, but I checked and your archives are working on both of those post-types just fine, including the pagination in the archives, so that’s not the issue.

Personally, I’d expect the theme or something to provide some kind of error, not just display ‘nothing’. Do you have this site setup in some kind of development environment as well where you can turn on debugging?

If we ignore their obscure capabilities, such as filtering on specific taxonomies (which Septera does not), or separating between what to show logged-in users versus anonymous, the WordPress get_(next/previous)_post_link functions (which work using get_adjacent_post()) are quite simplistic.

The query run by get_adjacent_post() is merely something like “SELECT p.Id WHERE p.post_date OPERATOR CURRENT_POST’s_DATE AND p.post_type = CURRENT_POST’S_TYPE”

Meaning that it looks for a post_type equal to the current post’s post_type, and a post_date that is OPERATOR (‘<‘ or ‘>’) different fromthe current posts time-stamp. Assuming that all these posts were not bulk-loaded with the same exact datetime-stamp (to the second), they should be found. ?? It will not find posts if all their time-stamps are equal. ??

Other than that, the only thing I can see that can short-circuit this, is if the WordPress get_post(), which is used to find the WP current post at the very beginning, fails. If it cannot see a current post, then it fails. Nothing to compare to.

Hard to debug with a database one cannot see. ??

I’m all about failing loud and proud, but def wouldn’t want users to see an error in Prod for something so innocuous. Jim, that site is hosted on Pantheon. I have a test and a dev environment outside Live to play with. All are on PHP 7.x at current.

Which debuggers would you suggest? Just point the way and I’ll drive this baby home.

BTW, Jim.. The Theme does not display “nothing”.. As I mentioned, if you do a view source, the NAV html code is there. But the link locations are simply empty, because nothing is returned from WP.. The theme has no way of knowing that the WP functions returning nothing is actually wrong, since that is also the result if a post has no previous or no next. ??

If you only had one post in a post_type, both previous and next would always be empty. No way to see that as a failure that a theme would want to report to a visitor. ??

Caleb, most useful. If you’d like acces to a DB that’s no problem. I’ve got 3 environments and external automated nightly backups. Those SQL tips look super helpful either way. FWIW I’m just looking for guidance to learn to fish here, not to be fed :). Of course I never turn down a good cook.

Install the “Debug Bar” plugin.. Set it to show in your admin bar.
Turn on your Admin Bar, if not already, and then go view a page that is failing to show links. Then click on the “Debug” in the admin bar, and select “Queries”.

That will give you a page showing which DB queries were run, and you should find exactly what it is doing, so you can try the queries by hand.

In the debug page with the gazillion of queries WordPress unfortunately runs, hit Ctrl-F (search) and search for p.ID. (few or just one query look only to find ‘p.ID’).

The resulting query (for previous) will look something like this:

SELECT p.ID FROM YOUR-POST-TABLE AS p WHERE p.post_date < '2017-02-03 12:33:46' AND p.post_type = 'YOUR_POST-TYPE' AND ( p.post_status = 'publish' OR p.post_status = 'private' ) ORDER BY p.post_date DESC LIMIT 1

The (“OR p.post_status = ‘private'”) is only there if you look at the page when logged in and you have the user-rights to read private posts..

Sweet business. That sounds most excellent. I will give it a shot soon and report back. Thanks for the toolking tips! I’m a WP n00b!

I think that the main thing to learn immediately from what the query looks like, is that there is no Pods involvement at all, except for Pods having set the ‘post_type’ to something other than ‘post’, when the post was created.

Since the query only looks for a post with the same post type (whatever post type you have on the page) and a datetime less or larger than current post, there is no real Pods involvement at all. It only looks in your posts table.

More importantly, if you DO NOT find these queries on the debug page, that means that it did not even try.. The only thing that theoretically could make that happen, is if get_adjacent_post short-circuits itself because it’s initial ‘get_post()’ failed.
In other words, it cannot see what the current post actually is, and so has nothing to compare to. If that happens, you have learned a lot. ??

Please let us know what these queries look like when you find them.
For future brain-caching. ??