I may have to run this through a few tests, and like you say, removing $this->_post
is only temporary.
Currently doing some much needed organizing and cleaning after the recent code push. So it may be a little while. However, I do suspect these…
1. [post_meta]
is being passed to another ‘internal’shortcode – This is likely NOT the issue, but “internal shortcodes” was designed to be encapsulated, and only work within the Internal Shortcodes Class. However, I designed everything to be loaded before the [php_function]
.
2. The WP_Post has nothing to reference to in that instance while in another function/shortcode that also uses $wp_query
. Which is still odd considering there should still be a valid $post
. I’ll need to confirm this theory first.
3. Removing $this->_post
prevents the defaults, and fixes the issue, but is still being stored in APL_Internal_Shortcodes::_replace()
. This is rather interesting, but falls under #2. However, in one of the 0.3.X versions, I did remove WP_Post from being passed, but quickly added it back in to prevent issues with other sites.
4. It is an issue with the WP Review Plugin code when getting the meta data; which seems like a function rather than a value to reference to, but I still want to confirm this scenario ( personally haven’t had much need for meta data…yet ). Please note: I might not be able to help if it is a Premium Plugin/Feature.
Hope this helps some, but I at least wanted to add my thoughts on it for later if needed. I’ll need some time until I can reproduce this, and it may even end up on the GitHub Ticket list.
-
This reply was modified 7 years, 6 months ago by EkoJR. Reason: Converted Markdown to HTML