Thread Starter
Harm10
(@harm10)
I just noticed that also the set category in the short code is no longer there for those reviews that are hidden.
As soon as I click the Read more on the page built by using the short code I get any category!
What is happening?
Just wanted to let you know that we are looking into whether or not there is an issue related to this. I just have nothing to report back yet. When I do, I will let you know.
Thread Starter
Harm10
(@harm10)
I understand. I also made a remark about it in the other report: do you have the filter function active on your site? Perhaps that has something to do with this all?
Can you also confirm that for each review a new grfwp_controller is set? Because it looks awfully empty for those hidden reviews.
I will experiment (probably tomorrow) what the effect is if I switch off the usage of the filter function.
Ok, so the issue is just that the new hook that we added (for you) doesn’t fire on AJAX. We’re working on adding that and hope to be able to release it in an update relatively soon.
Thread Starter
Harm10
(@harm10)
Thank you. Can I supply additional data or maybe test your solution in advance?
Hi Harm,
We’ve just released an update that corrects the issue in which shortcode arguments were ignored in the AJAX call to load more reviews using the Show More button.
Thread Starter
Harm10
(@harm10)
Thanks for the update! I can confirm that the filter grfwp_print_review_obj now gets the data after the Show More button is clicked but in filter grfwp_post_meta the data still seems to be missing?
Hi Harm,
Could you please share what you expect in post_meta and that is missing?
Apart from that, there are various other filters you can hook into to alter the default and processed arguments which are responsible for fetching posts and their meta_data.
You can hook into grfwp_query_args_defaults to modify default arguments that we use to fetch reviews, as well as grfwp_query_args after the internal processing of arguments.
Also, you can access meta_data defaults and processed values using the grfwp_review_metadata_defaults and grfwp_review_metadata filters
-
This reply was modified 3 years, 8 months ago by
jaysupport.
Thread Starter
Harm10
(@harm10)
It seems to me that when using the short code, filter grfwp_post_meta is not called when I click the AJAX button.
When I am on the short code page I use the filter to force the value back in $meta[‘review_date’] as it is blanked out in the code for the short code.
When testing now I put a fixed text in there that gets displayed for the reviews that are shown right away but not for those that are displayed after you click the AJAX button.
Can you confirm that grfwp_post_meta is called after the AJAX action?
Hi Harm,
Thanks for that extra info. The reason it takes longer for me to get you answers in this specific thread is I have to go back and forth with the devs for each question. The hooks are an advanced feature meant for people with coding knowledge to be able to extend the functionality of the plugin beyond what’s included. With that in mind, while I know how to make use of them, I don’t have much experience with how they’re coded or how they work behind the scenes. Sorry for the delay this causes.
That being said, I don’t have an answer for you yet on whether or not they get called on AJAX. It would appear as though they don’t. The questions from my previous post were meant just to try and find out exactly everything you’re trying to accomplish/display, so we can look at all of the existing hooks, to make sure they’re set up and/or able to do that, instead of one at a time.
Thread Starter
Harm10
(@harm10)
No problem that it takes some time! I am glad with the support I am getting. Many plug-ins can take this as an example.
As you may have gathered I often use hooks to customize things.
So I can wait for an answer.
If you ask me then offering a hook should mean that you offer it always irrespective on the form of code. But that is just my two cents…….. 🙂
Hi Harm,
Actually, we ran a few tests and the grfwp_post_meta hook definitely does seem to be firing on AJAX. Try the following function for example:
add_filter('grfwp_post_meta', '_grfwp_post_meta', 10, 1);
function _grfwp_post_meta($post_meta) {
$post_meta['rating_max'] = 10;
return $post_meta;
}
That function will cause the max rating to be changed to 10. So, with that function in place, you will now see your reviews have ten stars on them. And, if you click the Show More button, you will see that the extra reviews that load via AJAX also have the 10 starts. So that hook does indeed seem to be firing on AJAX.
What is the exact function you are adding to your functions.php file?
Also what is the current exact shortcode you have on the page?
Thank you!
-
This reply was modified 3 years, 7 months ago by jaysupport.
-
This reply was modified 3 years, 7 months ago by jaysupport.
Thread Starter
Harm10
(@harm10)
This is very weird. I have used your example code and for the reviews that are shown right away the max is changed to 10 indeed (as did my own customization), but on the reviews that are displayed when I click the button nothing changes.
But I found what causes it! At least something you can investigate!
My test code is this
function remark_greviews_post_meta_test( $meta ) {
if (is_admin()) { return $meta; }
$meta['rating_max'] = 10;
$meta['review_date'] = 'Test!';
return $meta;
}
And then the meta does not get changed whenever the AJAX is fired. But if I comment the is_admin() then it works!
I always use the is_admin() function so you will not get adverse effects when you are on the admin side of WordPress.
So the question now is why is_admin() is true after AJAX fires?
Can you please ask the developers?
You can use the following condition to check if admin logged in or not. However, it has one limitation: it will also return true for the front end when an admin or editor log in.
if ( current_user_can('editor') || current_user_can('administrator') ) { return $post_meta; }
I don’t believe you’ll be able distinguish between admin and non-admin screens for AJAX, as the AJAX can be originated from the front end as well as from the admin area with the same method provided by WordPress.
Thread Starter
Harm10
(@harm10)
I will try your suggestion and report back.
But…….. is_admin() is a WordPress delivered function: WP function so the result should not be interfered with by a plug-in! Or am I wrong in this assumption?
