[Case 46972] url_rewriter.tag - PHP: Error Parsing

DjiXas

Well-Known Member
Feb 10, 2007
294
0
166
Same, added double quotes, still not working.

Removed one line, got internal error
 
Last edited:

DjiXas

Well-Known Member
Feb 10, 2007
294
0
166
I have like hundreds of duplicate line.

What the heck is going on and how is this in R build?

; bcmath.scale: (ini file field description not available)
bcmath.scale = 0

; auto_append_file: (ini file field description not available)
auto_append_file =

; auto_prepend_file: (ini file field description not available)
auto_prepend_file =

; doc_root: (ini file field description not available)
doc_root =

; ingres.allow_persistent: (ini file field description not available)
ingres.allow_persistent = On

; ingres.default_database: (ini file field description not available)
ingres.default_database =

; ingres.default_user: (ini file field description not available)
ingres.default_user =

; ingres.max_links: (ini file field description not available)
ingres.max_links = -1
This was NEVER fixed
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
/scripts/phpini only works if you move the existing php.ini and then run it to generate a new php.ini file:

Code:
mv /usr/local/lib/php.ini /usr/local/lib/php.ini.bak110327
/scripts/phpini
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
Then please feel free to open up a ticket in WHM > Support Center > Contact cPanel or using the link in my signature. If no error was output, since one wasn't mentioned, nor any error output into /usr/local/cpanel/logs/error_log when running the command and it still didn't generate a valid php.ini file, you should open up a ticket.
 

Metro2

Well-Known Member
May 24, 2006
480
51
178
USA
cPanel Access Level
Root Administrator
Just ran into this bug myself...

url_rewriter.tags appears in two different sections of /usr/local/lib/php.ini and one is missing the quotes (as mentioned in this thread)

For me, adding the quotes to the duplicate:

url_rewriter.tags = a=href,area=href,frame=src,input=src,form=,fieldset=

So that it looks like this:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="

Fixed the problem of mass errors being reported in the log.

For anyone who doesn't know how to find which line number they're on in php.ini when using something like pico in shell, hit ctrl+c to identify which line you're on.

Yes it's easier to do a ctrl+w for url_rewriter.tags IF you knew that that problem existed, but I found out the hard way tonight like many others.

Sorry if anything in this post is redundant, just trying to be helpful.
 

lbeachmike

Well-Known Member
Dec 27, 2001
306
1
316
Long Beach, NY
cPanel Access Level
Root Administrator
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.
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 -

Why would something so clearly disruptive in nature require users to find their way to this thread and then open tickets in order to get a much-needed backmerge?

Most of us don't mess with our PHP configuration on a daily basis and thus will have discovered this as we did today, unknowingly and after-the-fact, after we have lots of frustrated clients and admins going in circles.

Cpanel is relied upon to be the experts here who are clearly aware of the issue and thus need to take the initiative to get the needed remedies in place before they are impacting people today such as myself, my admins and my clients.

If this was known about on 3/6, there should have been a backmerge or other resolution one full month later. The forums are not an effective way of getting the message out there to the majority of your users and clearly have not attained the needed action.

If there is not yet a fix, then there should at least be a backmerge of a very clear and blatant warning on the PHP Configuration Editor page. As mentioned in my ticket response, your own tech support person used this page last night to help troubleshoot an issue we were having and had no knowledge of the issue.

Thanks.

mrk
 

sneader

Well-Known Member
Aug 21, 2003
1,179
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
Thanks for the update, David. I appreciate that very much. Looking forward to 11.30 making it to Stable.

- Scott
 

webmatrixau

Member
Nov 23, 2008
5
0
51
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
Thank you.
 

lbeachmike

Well-Known Member
Dec 27, 2001
306
1
316
Long Beach, NY
cPanel Access Level
Root Administrator
This was resolved in the original builds of 11.30, which is now in EDGE and CURRENT. To see if 11.30 has reached your update tier yet, visit: Downloads - cPanel Inc.
11.30 still has not reached Stable build, which means that I still have this very severely impacting issue in my "STABLE" release.

To me, this makes no sense. If am running a STABLE build, my goal is stability. If there is a critical fix which is clearly required to have stability, then there should be an incremental release to the stable branch to serve the goal of stability.

While you guys have the right ultimate goal in mind, I think the process needs some review to ensure that you are indeed serving the goals you have set out to serve.

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.

mrk
 

sneader

Well-Known Member
Aug 21, 2003
1,179
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
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.
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. :)

- Scott
 

lbeachmike

Well-Known Member
Dec 27, 2001
306
1
316
Long Beach, NY
cPanel Access Level
Root Administrator
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. :)

- Scott
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.

You cannot have server-crashing bugs in a stable release and consider it as being anything less than surprising.

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.

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. As such, you can have a critical issue which crashes PHP for all clients on a server have precisely the same transit time as a benign issue, such as correcting a spelling error.

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.

My most important point is that the flaws in the process need to be addressed. There is no way that such a critical bug should have ever made its way through all of the releases into the stable branch. Knowing that it has done has to minimize your confidence that a stable release is more stable than the other releases.

It is my best guess that the most stable current release is likely the RELEASE version, and that is not supposed to be the outcome of the process in place.

While we are taking our time haggling about the relatively importance of fixing critical issues, Amazon, Google and Apple are marching their way into the hosting arena.

Processes have to improve, or there will be little to haggle about in the future.

mrk
 

cPanelDavidG

Technical Product Specialist
Nov 29, 2006
11,216
12
313
Houston, TX
cPanel Access Level
Root Administrator
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 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.

We also have a releases email list to let you know via email whenever a new version is available. That list can be accessed via: - cPanel Inc.

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.
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.

As such, you can have a critical issue which crashes PHP for all clients on a server
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.

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.
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.

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.

Will STABLE change any time soon? We are open to suggestions. However, many admins I talk to that use STABLE like it the way it is: infrequent updates and being the last to receive any new features. That is their preference. I do not share that preference, but it is not appropriate for me to dictate a preference for them.

Processes have to improve, or there will be little to haggle about in the future.
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.
 

sneader

Well-Known Member
Aug 21, 2003
1,179
57
178
La Crosse, WI
cPanel Access Level
Root Administrator
David, this was a great explanation of how things work... and maybe you've convinced me to move up to RELEASE. If it's good enough for you, it should be good enough for me! :)

- Scott
 

lbeachmike

Well-Known Member
Dec 27, 2001
306
1
316
Long Beach, NY
cPanel Access Level
Root Administrator
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.
I think you've addressed my underlying point right here.

So, if the stable branch is not the most stable, then why are we calling it stable and recommending it for production environments? I think cpanel guidance should be clarified on this point if their is consensus which agrees with what you've stated here. I wonder if you guys have a sense of what the breakdown is for which versions servers are running.

I did not have one specific suggestion or recommendation as to how to fix/improve the process because I do not know your internal processes. However, it would seem that more rigorous internal testing is in order if you did not receive a single bug report for the issue being discussed here which made its way all the way into the stable release. I've also recommended incorporating announcement capability into the WHM interface and improving the facilitation of opening tickets via WHM - however, perhaps what is needed is some quick-link to a bug report to improve bug-reporting by users. Nonetheless, I'd recommend clarifying guidelines on recommended branches and more rigorous internal testing.

That being said, I'd really recommend re-evaluating the entire process and seeing if there may be a more suitable process that can be created which would better suit the needs of today's very fast-moving environment. Keep in mind that the current structure was put in place early on, when the pace of things and the competitive nature of the industry was not at all what it is today.

I think it is worth emphasizing once more that if a bug like that made it to stable, the process as it is does not work the way it is needed to.

mrk