This isn’t my work, but added by a contributor. Looks like there’s some point to it, however, as some shortcodes need the global $post object to match the indexed post to make them work.
I’ll have to investigate this a bit, but I think the correct solution is to replace the global $post while indexing the document and then restore the old value.
Meanwhile, removing the global $post solves the issue, but may cause problems when indexing certain shortcodes.
Thread Starter
Steve
(@steveatty)
All I know is that changing the global post object does some very funky things – I have a hook on the transition_post and it updates its own post_meta and replacing the global post object seems to trash that change in the post meta. I’m not sure why it does it- its only in one specific set of circumstances but….
Thread Starter
Steve
(@steveatty)
Actually looking at the code you set it to $indexpost and then you do this:
$post = $wpdb->get_row("SELECT *,parent.post_status
FROM $wpdb->posts parent, $wpdb->posts post WHERE
(parent.post_status='publish' OR parent.post_status
So you completely replace a global object with a call from the Database. So if WordPress change the structure of the global post object (like adding new fields) you completely destroy that.
Thread Starter
Steve
(@steveatty)
Actually you only do that if $post is no longer an object.
But even then I don’t think you should be using the global object.
Yes, there are cases where the $indexpost can be a post ID, in which case it’s necessary to fetch the post object. In other cases it’s already a $post object.
I understand the global $post object equals a row in the _posts database, so whatever fetched from the database will always match the $post object.
Again, I’m not 100% sure about this, as this is contributed code, but I understand changing the global $post object is necessary in order to make sure that shortcode plugins that rely on the global object know which post is calling them.
Try replacing the relevanssi_index_doc() function with this and let me know if it works: http://pastebin.com/ZN4VXYtz
That version stores the global $post object and replaces it after the function is done. That would be a simple solution.
Thread Starter
Steve
(@steveatty)
No that doesn’t work.
You’ve admitted that the global post and the indexpost aren’t always the same but simply destroying the current global post object and replacing it with something else is something that I really think you need to reconsider.
Well, that’s part of the thing – I really don’t know why they would be different. As far as I can tell they should be the same.
I finally had time to start figuring this one out.
When Relevanssi indexes documents from the Relevanssi settings page, global $post is null. Relevanssi doesn’t destroy global $post object when indexing, because there’s no global $post object set when Relevanssi indexes documents.
When Relevanssi indexes document after an update, the global $post is set and it and Relevanssi $post don’t match. In that case Relevanssi points to the latest revision of the edited post, while the global $post is the public version.
So, looks like the correct behaviour is actually to check if the global $post is set and if that’s the case, use it. If no global $post is set, then set it from the $indexpost, so the shortcode plugins that rely on global $post know what we’re dealing with.
Steve, if you’re still following this thread, could you please try the follow version of relevanssi_index_doc() and let me know if it works correctly for you: http://pastebin.com/F5wtFtjq
Thanks!
The above code has one more problem, this should be correct: http://pastebin.com/zeXBzerZ
