OK, I think I figured out what is going on .. I just need some pointers on how to fix it.
My testimonial custom post uses the main post text field for the substance of the testimonial, along with specialized custom fields for related info (name, location, etc.)
The widget template has a call to the magic tag {@post_content}
That works fine on most pages, but when it is on a page set by a template for a different custom post type, then I think the dual calls to post_content are creating a conflict.
So here’s my question:
Is there a some code I can use to limit a magic tag only to @post_content for the specific pod type — for example, I tried @testimonial.post_content — it didn’t work – but I am wondering whether there is some other syntax I can use to get that result.
Or is there something I could do with the where specification that would achieve the same result?
If I can’t then the obvious solution would be to simply create a custom field in the Testimonials pod and move the appropriate content to that section- but I thought I’d ask if there is another option first.
If you’re using the Auto Templates on your regular posts, then what is happening is the_content filter is being replaced anywhere it sees it on the page, including your widget since in essence that’s also the_content. They’re both being read by the same filter, regardless of the source.
We have a bug report/compatibility issue for this one on our GitHub: https://github.com/pods-framework/pods/issues/3381
A workaround would be to shift your testimonials from using post_content (ie give them another editor box field to display) or shift them to a post_excerpt, until we can make it so this is less of a compatibility issue. One of the tradeoffs with trying to do everything “automagically” is they don’t always work perfectly in every situation.
Thanks– I kind of figured that I would have to do that workaround, but was hoping there was some alternative I didn’t know about.
I’ll create a new field called something like testimonial_content and see how that goes.
Fortunately the site is only in the development phase, so I don’t have too many records needing to be changed.
OK-that worked — switching the content to the a custom field works fine.
If a fix isn’t likely in near future, it might be a good idea to document this at http://pods.io/docs/learn/what-are-custom-fields/ — just a short note that points out the benefit of creating a separate custom field rather than using the wordpress default editing box, for users who plan to create and display multiple pod types.
I continue to be amazed and delighted at the power that Pods give me, but it’s something of a learning curve and this is an example of a problem that would have been prevented if I had simply known of this quirk from the outset.
It’s a very complicated system. Probably 80% of the time you’ll never have an issue with pods_content because in most cases you’ll never repeat it (the Auto Templates are designed to fill in and only show the data that isn’t handled by your theme).
I think a better explanation of what Pods Templates and Auto Templates are doing might make more sense than putting it on the what are custom fields docs. We’re actually doing a complete revamp of our documentation, trying to be clearer about process, etc.
Feel free to jump on pods.io/chat/ and we’ll bring you on for early review of them.
Thanks so much for the feedback!
Maybe if you are revamping documentation, it would be a good idea to have an article geared to planning the structure of pods, fields & taxonomies for various needs. There are quite a few little tidbit that weren’t intuitively obvious to me when I got started but I realize are important, as well as some things I did with one expectation and later realized were not helpful.
So I agree, some sort of getting started area that explains more about function and how pods interact with wordpress core functions and standard templates would be helpful.
I like your videos but personally I learn better with print documentation, where I can reread and copy parts that are helpful for my own use.
We’re focusing on both video and print documentation and also ‘transcribing’ or ‘scripting’ our videos so you’ll get the best of both worlds.
And yes, planning documentation is a big piece of our process. If you ever have questions like this, please drop into pods.io/chat/ and ask them on our Slack Chat.
