json/ajax filter ?

Although not tried, it may be possible to set ‘wp-json’ or ‘admin-ajax’ as a keyword in the URL Page filter of the beta test function.

thanks for your replay.
that was my first idea also. your regex is matching that. the problem for my “idea” is, that i e.g. need a plugin in admin area AND on selected frontend parts. so in practice i only need 2 plugins on frontend when using admin-ajax and skip the rest. but these plugins shoudn’t been deaktivated in backend itself**. right now i can only decide full/admin/page. so for my simple needs of full page speed optimisation i would like to have more options to select that. a simple json/ajax extra option with backend/frontend would give the ability to really speedup things in wp, as your plugin is really a solution for one of the worst problems in wp.

what do you think?

**or isn’t a cron call of the plugin affected by the deaktivation?

In order to judge backend / frontend, I think that it is necessary to check whether or not you are logged in. However, at the time of filtering plug-in loading, it is not yet ready for login judgment with the wordpress core function.

You need to implement your own login judgment function without relying on login judgment of wordpress core, and it is necessary to judge site, validity period, user information is correct from cookie and nonce … … I do not know well because I do not have much knowledge about authentication processing.

There is also a way to judge by only whether there is cookie, but if it is only it will feel something wrong.

for my needs a simple is_admin() judge is ok. i think for most queries regarding ajax/json the logged in judge isn’t necessairy.

what i just found out is, that the judge in your settings “admin filter” doesn’t execute by cron calls – so every admin plugin isn’t called by cron anymore! so it must be “normal” loaded – what is quite sad.
maybe have a hint or plan to fix that?

Whether the request for admin-ajax.php is wp_ajax_ (backend) or wp_ajax_nopriv_ (frontend) can not be determined by is_admin(), so it should be conditional branched in the login state.

I do not understand somewhat what kind of problem is.
We do not know the details of wp-cron, but requests to wp-cron.php are not included in the subject of admin filter.

Could you explain this in a straightforward way with a concrete example?
Plugin name used, target page type, expected behavior, etc.

good point. i solve the judge by simply using my own ajax in frontend now.

regarding the more important point of “admin filter” and cron – broker link remover, snap social auto post, updraft backup and as good every plugin with cron relevance and the applied filter isn’t executed/called. don’t ask my why – but after setting these plugins to normal execution, all is fine.

It is better not to filter the plug-in, mainly in the background by wp-cron.

This is because if you register these plugins in “admin filter”, processing registered in cron will be executed only when you access the management area (in most cases, when you performed the site management operation yourself). Therefore, it will be in the same state as the site without access.

Execution of registered processing by wp – cron is basically started for all accesses. Therefore, since some degree of access is absolutely necessary, for example, it may be possible to substitute it by executing it only when accessing the homepage or archive page and not doing it on posting or fixed pages