When the user visits the homepage, the user select the filters and the results are displayed in the boxes below. when the user is log in as an author the error is present and the filter doesn't works.
It is not something I can reproduce, testing a View with ajax filters on the homepage, while visiting the site as a user with a role of author.
Can you run a conflict test, please?
Try switching theme to twentyseventeen to see if you still see the problem.
Try disabling all non-Toolset plugins to see if you still see the problem. If this appears to resolve the issue you can identify which plugin is causing a conflict by re-activating the plugins one-by-one (or in batches) and re-testing each time.
Let me know how that goes so I can see how to proceed, thanks.
Sorry, I should have tried that first. The filter does work when I activate twentyseventeen, so I guess this is theme related. I'm using Beaver Builder theme. Should I contact Beaver Builder?
If we find it is a problem that needs to be fixed by BB then you may need to contact them, but let us investigate some more first.
You are using the BB theme, or a child theme?
Anything special I should know about the View you have added to the homepage? You get the error when you use any of the filters, or only a particular filter?
And, can you confirm, the user in question has a role=author, is that right?
It's a child theme. And yes, all the filters are not working when logged in as an Author. I'm not sure what would be deemed as special with this view but my developer has added this js code to the View's Filter Editor:
// @ hover effect only
jQuery(document).ready(function(){
jQuery('.hover').hover(function(){
var parent_tag = jQuery(this).parent().parent();
jQuery(parent_tag).addClass('flip');
},function(){
var parent_tag = jQuery(this).parent().parent();
jQuery(parent_tag).removeClass('flip');
});
});
jQuery( document ).on( 'js_event_wpv_parametric_search_results_updated', function( event, data ) {
jQuery('.hover').hover(function(){
var parent_tag = jQuery(this).parent().parent();
jQuery(parent_tag).addClass('flip');
},function(){
var parent_tag = jQuery(this).parent().parent();
jQuery(parent_tag).removeClass('flip');
});
var el = {};
$('.placeholder').on('click', function (ev) {
$('.placeholder').css('opacity', '0');
$('.list__ul').toggle();
});
$('#stopper').on('click', "a", function(ev) {
ev.preventDefault();
});
$('.list__ul a').on('click', function (ev) {
// ev.preventDefault();
var index = $(this).parent().index();
$('.placeholder').text( $(this).text() ).css('opacity', '1');
$('.list__ul').find('li').eq(index).prependTo('.list__ul');
$('.list__ul').toggle();
});
$('select').on('change', function (e) {
// Set text on placeholder hidden element
$('.placeholder').text(this.value);
// Animate select width as placeholder
$(this).animate({width: $('.placeholder').width() + 'px' });
});
});
And this js code to the Loop Output Editor:
jQuery(document).ready(function(){
jQuery('.hover').hover(function(){
var parent_tag = jQuery(this).parent().parent();
jQuery(parent_tag).addClass('flip');
},function(){
var parent_tag = jQuery(this).parent().parent();
jQuery(parent_tag).removeClass('flip');
});
});
If that code is added directly to the View then it will be used regardless of the theme, so if switching to 2017 fixes the problem the code is probably not the cause.
One more thing. Can you try switching to the parent theme and testing again?
I don't know how much custom code has been added to the child theme, but you can comment out sections at a time and re-test, which should enable you to pin-point the specific code in the functions.php file which is the culprit.
I used that code to redirect the author after they logged in to account details page. Is there a way to redirect the user to the account details page without using the code?. Why does the code causes an issue to the view?
Sorry for the delay getting back to you over the holidays.
Your code causes an issue because it uses the admin_init filter and so applies to all admin requests, which includes front-end ajax requests and does not just apply when a user tries to access the back-end.
So you could add a check for !wp_doing_ajax() so that it applies only when the back-end is being accessed directly, or you could try an alternative method using the login_redirect filter to send different roles to different locations.