This was NEVER fixed; bcmath.scale: (ini file field description not available)
bcmath.scale = 0
; auto_append_file: (ini file field description not available)
; auto_prepend_file: (ini file field description not available)
; doc_root: (ini file field description not available)
; ingres.allow_persistent: (ini file field description not available)
ingres.allow_persistent = On
; ingres.default_database: (ini file field description not available)
; ingres.default_user: (ini file field description not available)
; ingres.max_links: (ini file field description not available)
ingres.max_links = -1
mv /usr/local/lib/php.ini /usr/local/lib/php.ini.bak110327 /scripts/phpini
Tristan - Great support as always and you already have feedback in my ticket, but reading this thread here I again have to emphasize my point publicly -If people are having issues and would like to see this considered for a backmerge, please submit a ticket using WHM > Support Center > Contact cPanel or the link that I have in my signature.
Thank you.You will need to edit /usr/local/lib/php.ini directly in root SSH and ensure that only one copy of url_rewriter.tags is there. The PHP Configuration Editor is duplicating the value and not putting the "" around it, so you have to manually edit the value rather than using WHM.
We do have a case opened about this issue, which is internal case #46972. Until the PHP Configuration Editor has been fixed, this simply has to be done manually by editing /usr/local/lib/php.ini
11.30 still has not reached Stable build, which means that I still have this very severely impacting issue in my "STABLE" release.
Well... if they fix this, and introduce a brand new bug, then that's not very stable either.Simply put, with a bug like this, the STABLE branch is currently - and for some time now - far less stable than every other build. That defeats the point of a stable branch.
How is it not a surprise to find that certain routine operations which worked perfectly in prior stable releases will now crash PHP for your server? Clearly that has to illustrate that STABLE is quite a misnomer and more of an illusion. And that means that there is a flaw in the underlying process.Well... if they fix this, and introduce a brand new bug, then that's not very stable either.
While I'd like this fixed also, I don't want any surprises either. Probably best to let this, and any other change, make it's way through the Edge, Release and Current builds, before making it to Stable. Thank you very much.
I recommend subscribing to our news mailing list at News - cPanel Inc. (scroll down, a signup form is on the left). This will let you know about major issues and significant updates.If users don't want to risk the simple fix of a critical issue, then at the very least there could certainly be a warning about it. I've made suggestions to cpanel to add notification functionality into the WHM interface as well as to setup a means of notifying users of critical issues in the same way I receive emails from phpbb or WHMCS when there is a critical issue and fix.
I think this statement is over-simplifying the development process. cPanel & WHM, regardless of how simple we design our code to be, interacts in a complex eco-system of varied software. I've seen very minor code modifications cascade into colossal problems on internal builds, let alone some innocent parameter being sent to a script leading to potential security issues on our internal builds (those are resolved long before reaching public builds, of course). You may see this as something simple like "just remove the quotes, what's the big deal" but there's caution to be taken. As sneader said, it's best not to have surprises.Getting back to the underlying issue, there has to be prioritization, but the process that is in place does not prioritize any one fix over another.
Remember, this went from EDGE to CURRENT then to RELEASE (our most popular update tier, our recommended tier and our default tier) then to STABLE without anyone reporting this as a bug before it went to STABLE. I am not justifying this error in coding, just wanted to note that if this was such a major issue where everyone running PHP in a cPanel&WHM environment suddenly had their servers crash - we probably would have noticed it back in EDGE rather than so few people making a bug report about this issue that it managed to get into STABLE. Also, as you would expect, many of us that work at cPanel use cPanel & WHM. This means anything that slips past QA is still likely to be caught by cPanel staff before the general public encounters the issue.As such, you can have a critical issue which crashes PHP for all clients on a server
STABLE is only the last build to receive any updates. Nowadays, there's no "secret sauce" that makes it somehow more robust. However, the assumption held by many is that since the majority of server owners have already deployed this exact version of cPanel & WHM on their servers and have not reported any bugs that prevent us from propagating this update to the update tier called STABLE, there is likely less exposure to unknown issues. This is certainly a logical assumption to make.There is no winning scenario with the system currently in place, because a bug like this simply encourages those running the stable branch to then "demote" to running what would presumably be less refined branches. That type of migration essentially eliminates the point of having a stable release in place.
Being informed by the above, what do you recommend? I understand you want streamlining of getting bug fixes through the update tiers to STABLE, but keep in mind that sometimes code intended to fix one problem can inadvertently break something else in an unexpected way that we cannot detect in a testing environment but can arise in production environments where administrators have customized their servers to suit their specific best practices.Processes have to improve, or there will be little to haggle about in the future.
I think you've addressed my underlying point right here.Despite that, I advocate that RELEASE is the most reliable tier. The problem with STABLE is what many consider its strength: that it infrequently receives updates. As a result, issues can arise that do not exist on other tiers with third party software we distribute on STABLE. RELEASE does gradual updates to third party software, whereas STABLE is making larger leaps in updates to third party software. If you've run a server long enough, you know making leaps between major versions of software is often more problematic than just doing many incremental updates.
|Thread starter||Similar threads||Forum||Replies||Date|
|D||Only ONE case yields pcfg_openfile: unable to check htaccess file, ensure it is readable and that 'file' is executable||Web Servers and Applications||1|
|K||SOLVED [CloudLinux Case EA4D-84] ea-php72 not loading additional ini files||Web Servers and Applications||4|
|R||SOLVED [case EA-6287] EasyApache 4 UI fails to load with UTF-8 error - The subprocess error||Web Servers and Applications||29|
|[Case 143665] fixmailman failed with exit code 6400||Web Servers and Applications||10|
|M||Feature Showcase - ModSecurity - More Information?||Web Servers and Applications||1|
|Only ONE case yields pcfg_openfile: unable to check htaccess file, ensure it is readable and that 'file' is executable|
|SOLVED [CloudLinux Case EA4D-84] ea-php72 not loading additional ini files|
|SOLVED [case EA-6287] EasyApache 4 UI fails to load with UTF-8 error - The subprocess error|
|[Case 143665] fixmailman failed with exit code 6400|
|Feature Showcase - ModSecurity - More Information?|