Support

You have to disable the "Disable client-side risky behaviour in static content" feature. The way Apache works prevents this being overridden in a subdirectory.

I realize I should have added a bit more context in my previous reply.

Before answering I did reproduce your issue and tried to see if I can make an adjustment.

If you have a specific file or directory, in most cases you can add that in the "Files which will always be made accessible" or "Directories where all files except .php will be accessible" option in the .htaccess Maker configuration page, respectively. This will add a directive to remove the Content-Security-Policy header.

However, you don't want that. You want to replace the header.

The way the .htaccess code is written right now and the way Apache works makes this particular use case impossible. Apache's manual explains this in a slightly iffy way, by saying that Apache doesn't keep a definitive list of headers for each file. Basically, the Header rules with "always" in them work separately from all other rules, and have a slightly different approach in how overrides work.

The good news is that there is a solution – as long as I change the way this header is applied. We actually made that change in Admin Tools for Joomla a couple of months ago and it works. I just never had the time to port it to Admin Tools for WordPress because first my wife was in the hospital, then I got sick, and next thing I know the entire month of May just disappeared.

What I am going to be doing for the next release of Admin Tools is use a SetEnvIf directive to set an Apache environment variable to "tag" the files that need to have the custom Content-Security-Policy header applied. Since it's an environment variable, you can unset it in a subordinate .htaccess file (a .htaccess file in a subdirectory). I have tested that, and it does work.

So, for now, disable this feature. When the next release of Admin Tools comes out re-enable the feature and put the following into your subordinate .htaccess file (in the directory you want to disable the feature):

SetEnvIf Request_URI ".*" !disable_risky_behaviour
Header set Content-Security-Policy "default-src * 'self' 'unsafe-inline' 'unsafe-eval' data:;"

I hope that giving you this additional context helps :)

What you are doing will not work just yet. It will work with the next version of Admin Tools for WordPress I will be releasing on either Monday or Tuesday.

As I told you a couple of days ago (added emphasis):

What I am going to be doing for the next release of Admin Tools is use a SetEnvIf directive to set an Apache environment variable to "tag" the files that need to have the custom Content-Security-Policy header applied. Since it's an environment variable, you can unset it in a subordinate .htaccess file (a .htaccess file in a subdirectory). I have tested that, and it does work.

So, for now, disable this feature. When the next release of Admin Tools comes out re-enable the feature and put the following into your subordinate .htaccess file (in the directory you want to disable the feature):

SetEnvIf Request_URI ".*" !disable_risky_behaviour
Header set Content-Security-Policy "default-src * 'self' 'unsafe-inline' 'unsafe-eval' data:;"

I hope that giving you this additional context helps :)

https://www.akeeba.com/support/admin-tools-wordpress/40784-overwrite-disable-client-side-risky-behaviour-in-static-content-for-subfolder.html#p221383

And then again yesterday:

What you are doing will not work just yet. It will work with the next version of Admin Tools for WordPress I will be releasing on either Monday or Tuesday.

https://www.akeeba.com/support/admin-tools-wordpress/40784-overwrite-disable-client-side-risky-behaviour-in-static-content-for-subfolder.html#p221440

For the third and last time.

Yes, the current implementation of this feature is not great. I am aware. I have fixed it in a much better way.

RIGHT NOW you can disable this feature completely if you are in such a time crunch.

When I release the new version in 3 to 4 days you can update the plugin, re-enable the feature (if you disabled it), regenerate the .htaccess so the new code gets applied, then use the .htaccess override code I already provided (see the quoted reply at the top of this post).

I am closing this ticket as you have been told why it's broken, how it's fixed, and when to expect the fix to be published. No further tickets about this filed by you will be answered before the next version of Admin Tools is released. Thank you for your understanding.