Global (All) differs from Global (Front) for code that runs on the frontend?
-
Hey, thanks for another handy plugin. I like the layout + the ability to test the code before saving. Pretty cool.
I noticed something odd though, I have this code:
/** * Filters the protection status of a form. * * @param string $value The protection status of a form. * @param string[] $source The source of the form (plugin, theme, WordPress Core). * @param int|string $form_id Form id. * * @return bool */
function hcap_protect_form_filter( $value, $source, $form_id ) {
if ( ! in_array( 'kadence-blocks/kadence-blocks.php', $source, true ) ) {
return $value; }
if ( 7 !== $form_id ) {
return $value; }
return false;}
add_filter( 'hcap_protect_form', 'hcap_protect_form_filter', 10, 3 );It works fine, if I select it’s placement as Global (Front). But when I select Global (All), it doesn’t work, although (All) should include (Front) right? So it should work. As Global (All) is the default option and usually I would leave it at that, even if it’s frontend only code, it feels incorrect that it’s not working.
I know that it’s better / more efficient to select Global (Front) for frontend only functions, but that’s a different discussion. This is only about what every user will likely assume = that (All) encompasses (Front) and (Back), albeit it doesn’t seem to be the case.
-
Hey @lukascech! 👋
Sorry for the late reply. By default, the Global snippet uses more security checks as it is executed everywhere. So, if you didn’t whitelist the route, then it will be blocked. If you use Global Front, you don’t have to worry about this. If you want, you can use the meow_mwcode_white_listed_rest_authorized($authorized, $requested_route) filter if you want to use Global with manually whitelisted REST routes. Or bypass the authorization using the
meow_mwcode_white_listed_rest_authorizedfilter.Hope this helps!
The topic ‘Global (All) differs from Global (Front) for code that runs on the frontend?’ is closed to new replies.
