Support

This is most likely caused by one specific option in Admin Tools’ .htaccess Maker. YOOtheme’s own support describes it in the thread you linked, and it matches how this option works.

1. Go to Admin Tools, .htaccess Maker, Basic Security.
2. Set Protect against common file injection attacks to No.
3. Click Save and create .htaccess. Changing the option is not enough on its own: the setting only takes effect once the .htaccess file is regenerated.
4. Clear your browser cache and any caching plugin or server cache, then click the “yootheme” button on a page or article again.

If the button now works, you’re done. If it still doesn’t, please tell us what happens when you click it and send us the information below, so we can look further.

• The full URL and status code (403, 404, 500…) of the failing request, from the Network tab of your browser’s Developer Tools (F12).
• Any new entry in Admin Tools, Web Application Firewall, Blocked Requests Log after you click the button (its Reason and Target URL).

Technical information

You do not need to read this section to apply the steps above.

That option works by refusing any request whose query string contains an http:// or https:// URL. It is meant to stop Remote File Inclusion attacks, where an attacker tricks a vulnerable extension into loading code from their own server. Some legitimate features also put a full URL in the query string, and it appears that YOOtheme’s page/article button is one of them. We have not tested this ourselves; we are relying on YOOtheme’s support analysis plus the way the option is documented to work, so please tell us if turning it off doesn’t fix it.

Turning this option off does reduce the protection at the web server level. Our documentation recommends using the RFIShield (Remote File Inclusion protection) feature in the Web Application Firewall in these cases. It checks the same kind of request inside PHP, so it covers the same threat. Please check in Web Application Firewall, Configure WAF that it is enabled.

Yes, switching that option off removes a layer of protection, and we can avoid that. Instead of leaving it off, you can keep it on and add one narrow exception that lets only YOOtheme’s builder link through. Thank you for sending the URL; it is what made this possible.

1. Go to Admin Tools, .htaccess Maker.

2. Set Protect against common file injection attacks back to Yes.

3. Find the box titled Custom .htaccess rules at the top of the file and paste in exactly this, without changing anything:

   RewriteCond %{REQUEST_METHOD} GET
   RewriteCond %{HTTP_HOST}::%{QUERY_STRING} ^([^:]+)::action=yootheme&yootheme=customizer&site=https?://\1/[^&:]*&return=https?://\1/wp-admin/post\.php\?post%3D[0-9]+%26action%3Dedit&section=builder$ [NC]
   RewriteRule ^wp-admin/admin-ajax\.php$ - [L]

4. Click Save and create .htaccess. Saving alone is not enough; the file must be regenerated.

5. Clear your browser cache and any caching plugin or server cache, then click the “yootheme” button on a page or article.

The same text works on all of your sites without editing it, because it compares the addresses in the link against the site’s own domain name.

How to check that it worked and that the protection is still on

• The “yootheme” button should open the builder.
• Visit https://YOURSITE/?x=http://example.com/ (use your own domain). You should get a “403 Forbidden” page. That shows the file injection protection is active again.

If your site shows an error 500 after step 4, the pasted text was altered somewhere, for example by a text editor changing the quotes or breaking a line. Remove what you pasted from the box and click Save and create .htaccess again. If you cannot reach your administration area, use FTP or your host’s file manager to rename .htaccess.admintools to .htaccess. Admin Tools keeps your previous .htaccess under that name whenever it regenerates the file.

Technical information

You do not need to read this section to apply the steps above.

What the option protects you from. With the option on, the web server refuses any GET request whose query string has a parameter whose value starts with http://, https://, ../ or /path/. This stops attacks that trick a vulnerable plugin into loading a file from an attacker’s server, or from elsewhere on your own server, and it does so before WordPress and PHP even start.

A correction to our previous reply. We told you the Web Application Firewall’s RFIShield “covers the same threat”. That was too broad. RFIShield only looks at parameters containing http(s):// and ftp:// addresses. The other two cases (../ and /path/) are the job of a separate feature, DFIShield, which rejects a request if a parameter looks like a file path that points to a file that exists on your server. Both run inside PHP, so they are a second line of defence. They are not an exact replacement for the server-level rule, and that is why we are now recommending the exception rather than switching the option off.

What the exception does. The link behind the “yootheme” button looks like this (your own domain in place of MYSITE.fr):

https://MYSITE.fr/wp-admin/admin-ajax.php?action=yootheme&yootheme=customizer&site=https://MYSITE.fr/PAGEURL/&return=https://MYSITE.fr/wp-admin/post.php?post%3D47%26action%3Dedit&section=builder

(The link you pasted showed §ion=builder at the end. We believe this is only your browser or the ticket page turning &section into a § sign, so we used section=builder in the rule. Tell us if the real link differs.)

The rule lets a request through only if all of the following are true. Anything else keeps being blocked exactly as before.

• It is a GET request for wp-admin/admin-ajax.php.
• The query string is exactly the parameters above, in that order, with nothing before, after or in between them.
• The site and return addresses belong to the same domain name the visitor used to reach your site.
• The site address does not contain a further : or &, so another address cannot be smuggled inside it.

What we tested, and what we did not. We ran this rule in a real Apache 2.4 server with the file injection protection block from Admin Tools’ own generated .htaccess. The YOOtheme link above was allowed (with different upper and lower case in the domain name too). A request with an extra x=http://evil.example/… parameter added to the end or inside the site value, a lookalike domain, a different domain name, and an ordinary ?x=http://example.com/ or ?file=../../etc/passwd were all still refused with 403. We did not test it with YOOtheme itself or on your sites, so please tell us if the button does not work.

Limitations. This is deliberately strict. If a future YOOtheme update changes the order or the names of the parameters in that link, the button will stop working again; the site will not become less safe, you will just need to send us the new link. The rule also assumes WordPress is installed in your domain’s root folder, as in your example. If it is in a subfolder, let us know and we will adapt it.