We are here sharing a recent experience with this theme author:
We initially thought this could be a good theme, but quick enough this MuffinGroup company proved us wrong.
The issue: Saving a page results in a blank page.
What we did? Open a support ticket.
Long story short, they turned to the claim that we HAD TO change the MASTER VALUES OF PHP VARIABLES, because setting LOCAL VALUES for environment variables ONLY WORK IF THE VALUE OF MASTER IS GREATER.
We invite EVERYONE to go and see the topic: [https://forum.muffingroup.com/betheme/discussion/65455/saving-changes-results-in-empty-page])
We don’t know what the problem with their software is. We know this is a total incompetence an ignorance about PHP. We also suspect they push clients to their cheap a\*\* hosting providers who use unsafe settings on configuration, endangering all customers.
And please, notice their claim carefully: They talked to administrators and providers WHO TOLD THEM THIS.
This sort of arrogance and these claims altogether, only display a gigantic ignorance and lack of technical knowledge and quality. I don’t know what the theme problem is, but clearly has some.
They are so bad, they are unable to create a test environment with low master values, and using higher local values and do some tests, which would immediately prove the wrong of their claims.
More, think of what kind of mediocrity is on those supposed “administrators and providers” they mention, that instead of using low master values and then fine tuning the values per project, use high master values for all.
Also, [alike this other user we found here on reddit]), we were also banned from their support forum: the only way they have to deal with their own incompetence is to ban people.
Wouldn’t touch this with a ten foot pole. These guys are utterly ridiculous.
[ad_2]
You are both mostly correct, but not completely. Here’s the thing: the `max_input_vars` setting **in particular** cannot be effectively changed through `ini_set()` because of its nature:
>> How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.
The problem is that when your browser submits the request to save the page contents there’s so many input variables that PHP is removing some of them **before execution begins, before your ini_set() is run**. The problem has already manifested before WordPress’ index.php even begins execution. That is why you have to raise the `max_input_vars` setting at the php.ini level.
They could (should?) have been able to explain this better, and it’s a little suspicious that saving one page’s content would pass over a thousand key/value pairs to the server, but they are correct that the only solution is to alter the php.ini configuration.