Hendrik Lersch

Yes, you’re right. It’s because of this: https://github.com/mcguffin/acf-quick-edit-fields

Sry for the confusion. I didn’t meant the preview links while editing a post. I meant the “view” links, which shows up in the post overview at hovering. If that make a difference..

I have, but still no flags. It’s weird. If i add a new one, which will be dynamically added to the list, then it will show the flag. After a reload of the page the flag is gone. And saving or changing of the already existing terms has no effect, in terms that there is no flag. The rest works fine.

Oh, just noticed that the flags on the taxonomy overview pages are still missing. The languages column is complete empty.

Thank you again for your very fast support and bugfixing!

Thank You!

Glad to hear it’s now working for you. Regarding your screenshots, all these settings should work. But the conditions of the second pic are tricky, because it depends hardly on your page-settings. They could only match if frontpage and blog homepage is the same page.

And yes, it’s compatible with PHP 7. I have really no idea, what could cause an error like this, when it’s not a wrong condition setting.. so i hope it will not happen again ??

Have a nice day.

Hi Gulshan,
thanks for your feedback.

1. What you mean, when you say the plugin force you to set a user level? It’s just a notice that these JS or CSS files are located in the “wp-includes” folder and are most likely files that are enqueued by WordPress itself. But in fact they could be enqueued by any plugin too. What i want to say, it’s up to you, what you doing with these files. It’s just a warning message.

2. Sadly it’s not a bug, but a needed behaviour in the way the plugin currently handles the de- and re-registering of files. jQuery is a special case, which i had to handle especially. The reason for that is, that in WordPress you can register a few scripts, in this case jquery-core and jquery-migrate and enqueue them at once by register an additional jquery handle and set the two registered jquery scripts as dependency values. If you then enqueue jquery, WordPress will force jquery-core and jquery-migrate to enqueue as well.

I had to mimic this behaviour, otherwise things would be broken. But since jquery is not the only of this “special cases”, i had to find another, more flexible mechanic to handle these things, which will also solve a few other problems with planned features. The next minor version (which is almost a complete rewrite) will include this (and more).

Best regards.

Please check your PHP Version. The plugin needs at least PHP 5.5.0.
But you say “many” conditions. Does this mean, that some conditions work and others not? I’m sry, but i need a few more infos about your rules settings and their effects, because i can’t see any potential bug in the code. Maybe it’s just a misunderstanding of the rules system settings. Could you please make a screenshot of the rules settings, which not work?

Hi Joyce,

in my tests everything works fine. Just to clarify: Does the plugin not saving the rules in the admin panel or does it save the rules, but doesn’t execute these rules by deregister the JS or CSS files at the intended locations in frontend?

Best regards

Unfortunately i don’t really know, what’s happening here. Firstly i thought it’s because you haven’t installed the cURL library and/or allow_url_fopen was set to “Off” in your php.ini. That’s because i switched from using just cURL to using the WP-HTTP API, which uses many different (and more directly) ways to make HTTP-Requests.

I have tested it with deactivated cURL and allow_url_fopen set to “Off” and the API was still be able to establish a connection.

The status code “0” is also not a HTTP response code. It indicates more likely, that the request couldn’t be performed at all.

I will looking for an additional way to add pages to the list, maybe via AJAX or manually via an admin bar button on the target site. But this could take a few days, because i’m a bit busy at the moment ??

That’s not good. I will try to find another solution. Is there a status message after the status code? I have added it with the last update.

Ok, i have released a new version of the plugin. Please update and test if the error is gone.
It may be possible that the cURL library is deactivated in your PHP installation. I don’t use it anymore and switched to WordPress’s HTTP-API. I hope this fix the issue.

Also, it’s no problem to deactivate the admin bar JS and CSS files. But you should additionally write something like this into your functions.php.

if ( ! current_user_can( 'manage_options' ) )
{
    add_filter( 'show_admin_bar', '__return_false' );
}

Otherwise you will have a 30px gap at the top of your site. This code will hide the admin bar for everyone else but admins. But it don’t remove the files, so using my plugin to unload them for non-admins is totally ok. ??

Hello.

No, this feature hasn’t switched off, it should work. The acceptable form is any URL, which points to the WordPress site the Plugin is running on. It will be checked via PHP’s cURL to get the query-string WordPress uses to routing a request and show the right page to the user.

Unfortunately i can’t reproduce the error you describe. Could you provide me a few infos about your environment?

• What kind of error does appear?
• Which WordPress Version is in use?
• Which PHP Version?
• Do you use any kind of subdomain or WordPress in a subfolder? Maybe Multisite etc. ?

Best regards

You’re very fast in bugfixing ??
Thank You. It’s working now.