Hi – I am having the exact same problem today… I only have started working with the theme over the past days, and hardly have anything added or changed.
I have confirmed in the “status” panel that all settings are ‘green’, including being sure that max_input_vars is set to 5000, and memory at 64MB
Any suggestions on how to fix this? I simply wanted to change the color of the login box, but it won’t save… just rolling icon without any save.
Ideas? Suggestions? Solutions?
@tageldart We’ve got the same story! I just started working on my site a few days ago.
Anyway, I was able to fix the issue.
What happened have I recently installed a plugin which affected the theme. So I just disabled my most recent plugin and I was able to same on them settings.
Another thing I noticed was the allowed memory limit on my host was just too low! 34mb. So I had to contact my host to increase it to 128mb.
Increasing the memory limit on your hosting a limit may just be the solution you need.
Hi,
It could also be the case that the admin ajax request is blocked by the server. Check this topic for more information
– https://forum.tagdiv.com/topic/cant-save-theme-options-2/
Thanks
Hi @Lordemma,
Okay – Solution found (for me anyway). This was the specific issue in my case, though it may not be specific to your issues. I also had some other peripheral issues that were specific to the use of SSL on my site, which were mitigated by ensuring that I had “https” set in the Settings->General->Wordpress URL settings in the WP Dashboard (you might like to look into this if you have other issues with the TAGDiv composer showing blank pages).
In all cases – with respect to the saving loop – my issues were all related to the “.user.ini” file.
The problem with the Saving Loop was actually with WordFence (in my case), 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.
*update*
If you are using WordFence – you can check to ensure your ‘Whitelist’ IP addresses and so forth to ensure your WordFence installation is not blocking your access.
@lordemma – I spent a very long time trying multiple solutions to this problem, so if you haven’t solved it yet, let me know, as perhaps some of things I experienced and have gone through can be of assistance to you in solving your issue.