Good Morning,
I know this issue has been covered in some detail here, and of course, I have read nearly all the comments and suggested resolutions highlighted by the TagDiv team. Unfortunately, none of these have resolved the issue.
To summarize – All the resources, including max files, ram and other items within the Status panel have been set, and are showing correctly (all boxes are “green”). I have spoken with my host, and they confirm that their systems are not blocking ajax-admin, and I have even gone so far as to install the Heartbeat plugin to reduce the resource calls made. I have also attempted to disable any additional plugins (of which there are few, as this is a fresh WP install with the theme).
Unfortunately, the problem persists. As I mentioned above, I have also disabled all the plugins except for the core plugins provided with the theme – the issue continues.
Is there any place I can possibly provide the TagDiv support team with some login details to try and have a look for themselves? I feel silly asking for help, as normally I have been quite adept at solving the majority of problems on my own, but in this instance I am sincerely stuck.
Any suggested actions to solve this?
I am simply trying to save the background color of the sign in/join modal in the Theme Panel, but to be fair, the issue presents itself no matter what I try to save.
Thanks in Advance
Okay – Solution found.
The problem was actually with WordFence, which is not installed as a plugin in this particular case, but in another installation on the same host, which was installed in the default “public_html” directory. This installation of WP is in a subdirectory, but the “.user.ini” file which is created in the default “public_html” directory overrides things.
In all cases, WordFence adds the following to the “.user.ini” file:
; Wordfence WAF
auto_prepend_file = ‘/public_html/wordfence-waf.php’
; END Wordfence WAF
Removing this, solved the issue.
Of course, it will create other issues for the site that uses WordFence, but I will have to resolve that another way.
For now, and in case anyone else may have run into similar issues – this is the solution that worked for me.
I suppose it makes an argument for putting all WP installations into their own subdirectories. For whatever reason, the original installation of the main domain in this case, was installed in the PUBLIC_HTML directory by default, and this was the source of the issue.
Hope this might help anyone with a similar issue.
