I am trying to:
Edit a page.
Link to a page where the issue can be seen:
Any page of the website.
I expected to see:
The admin backoffice to modify the page.
Instead, I got:
You can see on the screenshot. So it is not possible to edit the page normally.
I tried to deactivate all plugins, and the bug occur when toolset is active. I also tried to reinstall types plugins but nothing changes.
Hi, I'll try to help figure this out. I suspect we will need to get your hosting provider involved because I'm seeing some issues related to the server. Specifically, I'm seeing several 403 errors that are preventing Toolset from loading CSS, images, fonts, and PHP scripts. For your reference https://en.wikipedia.org/wiki/HTTP_403:
HTTP 403 is a standard HTTP status code communicated to clients by an HTTP server to indicate that access to the requested (valid) URL by the client is Forbidden for some reason. The server understood the request, but will not fulfill it due to client related issues. - Wikipedia
With Types active (and no other Toolset plugins) I see the following 403 errors on the plugins dashboard:
GET net::ERR_ABORTED 403
<em><u>hidden link</u></em>
GET net::ERR_ABORTED 403 <em><u>hidden link</u></em>
GET net::ERR_ABORTED 403 <em><u>hidden link</u></em>
These files are font files, used to display Toolset-specific icons...that's why there is a missing icon displayed as a square next to Toolset in the wp-admin main left menu.
If I edit a post, I see those same 403 errors plus another one:
GET net::ERR_ABORTED 403
<em><u>hidden link</u></em>
This new one is a PHP script that should help WordPress load the necessary admin CSS files...that's why there are missing admin styles here. So we need to get your hosting company involved to find out why these font files and the PHP script noted above were refused by the server. Feel free to copy the information above and provide it to their support team, who will have the tools necessary to track down the security configurations at play here.
NOTE - I replaced the domain and demo directory with dummy information above, for your privacy. You should update that to inform your hosting team of the true URL and demo directory. Let me know if there is anything else you need from me to help facilitate this conversation.
You may also ask them to verify these two Toolset requirements for server configurations:
- The eval() PHP function must be enabled. https://toolset.com/toolset-requirements/#eval-usage
- The Multibyte String extension (mbstring) must be enabled.
Please note during testing I deactivated the ReallySimpleSSL plugin. When I reactivated RS SSL I did not change any configurations or enable 301 .htaccess redirects per https://really-simple-ssl.com/knowledge-base/remove-htaccess-redirect-site-lockout/, because I do not have FTP access.
Hi, thanks for your reply,
We're still searching why the 403 error occurs.
But we already verified that the eval() function and mbstring extension are enabled.
No problem for ReallySimpleSSL plugin, since this is a website under developement we disabled 301 .htaccess redirects for compatibility.
Okay thank you for the update. It's a strange issue...if I go to this URL directly in the browser, the file is downloaded successfully (HTTP code 200):
hidden link
I'll stand by for more information.
Hi, after searching,
We found a solution to continue to edit pages as usual even with the 403 errors, by adding this line to wp-config.php :
define('CONCATENATE_SCRIPTS', false);
And it seems that the toolset font file is blocked by the firewall of the server, here is an extract of the log :
[client IP_ADRESS] ModSecurity: Warning. Operator GE matched 5 at TX:inbound_anomaly_score.
[msg "Inbound Anomaly Score Exceeded (Total Inbound Score: 5 - SQLI=0,XSS=5,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): XSS Attack Detected via libinjection"] [tag "event-correlation"] [hostname "WEBSITE_DOMAIN"] [uri "ERROR_DOCS/forbidden.html"] , referer: WEBSITE_DOMAIN/wp-content/plugins/types/vendor/toolset/onthego-resources/onthegosystems-icons/css/onthegosystems-icons.css?ver=4.0
Okay I see, a ModSecurity warning. This is a false positive, assuming the CSS file has not been tampered with. You reinstalled Types already so I doubt that is the case but you can try reinstalling again to be very cautious. This warning is not something to worry about. If possible, I would ask the hosting company if they will choose higher ModSecurity tolerance settings in general, or ask them to specifically whitelist this CSS file, the font files, and any others that trigger these types of ModSecurity warnings.
Something as simple as a comment in a CSS file can trigger a warning like this, even Gutenberg suffered from this: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1309
Let me know if you have questions about this, but again it's a false positive and nothing to worry about.
Hello, thanks for the advice,
We have a VPS on Plesk so we managed to do it by ourselves. Here's the doc we used for those who are in the same case :
hidden link
So we whitelisted the specific file, and after that we noticed that Toolset was not responsible for the admin styles not loaded as you said. So we whitelisted the other file, and all work good now!
Thanks again.
Great, thanks for sharing your solution. Plesk's relevant documentation may be helpful to other Users.
