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

[logart]

Hello,

I just checked my system update email and saw this error:

Running Cleanups...Hostname Virtual Host is already setup
...Done
Updating services & databases...PHP: Error parsing /usr/local/lib/php.ini on line 793
PHP version file has been updated to 5.2.9

Here is what my php.ini looked like:

; url_rewriter.tags: (ini file field description not available)
url_rewriter.tags = a=href,area=href,frame=src,input=src,form=,fieldset=

I fixed the error by placing Quotes around the config value:
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="


Not sure how this line was added, but I did not edit the php.ini at all before this. Maybe a bug or something.

 

[rezman]

Hello,

I just checked my system update email and saw this error:



Here is what my php.ini looked like:

; url_rewriter.tags: (ini file field description not available)
url_rewriter.tags = a=href,area=href,frame=src,input=src,form=,fieldset=

I fixed the error by placing Quotes around the config value:
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="


Not sure how this line was added, but I did not edit the php.ini at all before this. Maybe a bug or something.

I started getting the exact same problem today. I added the quotes around and it started working then stopped and now all php script just hang. typing 'php -v' at command line returns nothing. If I put it back to how it was then everything works however the Zend engine stops working. This is originally how I found this problem.

# php -i | grep "url_rewriter.tags"
PHP: Error parsing /usr/local/lib/php.ini on line 796
url_rewriter.tags => a => a

 

[cPanelTristan]

My own php.ini at /usr/local/lib/php.ini has the following:

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

So it has the quotes. Did either of you have EasyApache run recently or any other changes? Also, which version of cPanel are you using and do you have it updating nightly by cron?

cat /usr/local/cpanel/version

For the issue with php -v functioning, could you try moving the existing php.ini file and recreating it?

mv /usr/local/lib/php.ini /usr/local/lib/php.ini.bak110202
/scripts/phpini

This will restore a default php.ini file. You'd then have to re-add anything you had added or customized, but could find those via a diff:

diff /usr/local/lib/php.ini /usr/local/lib/php.ini.bak110202

Thanks.

 

[rezman]

I have the following on 2 lines in my php.ini.

Line: 796

; url_rewriter.tags: (ini file field description not available)
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="

Line: 1598

; The URL rewriter will look for URLs in a defined set of HTML tags.
; form/fieldset are special; if you include them here, the rewriter will
; add a hidden <input> field with the info which is otherwise appended
; to URLs.  If you want XHTML conformity, remove the form entry.
; Note that all valid entries require a "=", even if no value follows.
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="

Line 796 originally did NOT have quotes around it but 1598 did. If I comment out 796 php will not run anything. If I remove the quotes it runs but Zend will not fully load.

#  cat /usr/local/cpanel/version
11.28.76-RELEASE_51149

EasyApache was not manually run before this started. I did run it 2 times after while trying to fix the problem.

After I make a backup then rebuild the php.ini using the script I only have one "url_rewriter.tags" line in the file. I then readded the following to then end if the file re-enable Zend and thus seems to be working.

 ; zend_extension: (ini file field description not available)
zend_extension="/usr/local/Zend/lib/Optimizer-3.3.9/php-5.2.x/ZendOptimizer.so"

After going back into WHM -> PHP Configuration Editor -> Advanced to make some changes and saving I then get this with a once again broken Zend:

# php -v
PHP:  Error parsing /usr/local/lib/php.ini on line 826
PHP 5.2.16 (cli) (built: Feb  3 2011 17:19:53)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

Line: 826

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

Also Line: 1212

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

So right now I have everything working (or appears to be) but I can not use the WHM -> PHP Configuration Editor to make changes. I'm manually editing the php.ini for the time being. It also appears that the WHM editor is not placing double quotes around many of the string values when it goes to save the php.ini file. I honestly don't know how many of the Cpanel scripts work but this is what I see in the 'diff php.ini php.ini.bak' results.

 

[cPanelTristan]

Thank you rezman for the details. I'm going to be investigating using the PHP Configuration Editor tonight during my shift to see the results of using it for that url_rewriter.tags line.

 

[Nick57]

Hi,

I have same problem now since I updated to the latest version of WHM Release 11.28.83.
Please tell me how to fix it because the php configuration edior doesn't seem to allow the " " around it. it just complete igores my " "

 

[cPanelTristan]

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

 

[Nick57]

thank you very much

 

[ikillbill]

we have exactly the same issue and manual fix to php.ini is NOT working~~

 

[cPanelTristan]

Did you remove the second url_rewriter.tags entry and then ensure the first one has quotes around it? If you have, please open a ticket using WHM > Support Center > Contact cPanel or via the link in my signature.

 

[ikillbill]

Hi

yea, issued ticket long time ago

could you please fix this ASAP - ticket #1237725

thanks

 

[ikillbill]

There were duplicated ZEND too, removed it, now working

 

[boonjackmedia]

I'm guessing the PHP editor is not fixed yet?

We had duplication errors also since late 03/01 and today.
When any edits are made and then saved, a blank page is returned.
Looks like it is duplicating after the php.ini "modules" section, we made a bk copy and then created a new php.ini last night for php5-3.4.

Ran sys/server updates, easyapache, and makecpphp but the problem still exists with the whm php editor.

I think issue this has to do with the changes of php5-2.9(cpanel php version) to php5-3.4(Our php version) related to the php.ini's settings; parsing, functions, variables, etc.

Our php.ini needed to be modified a lot for php5-3.4, ex:

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

Needed to remove the "form=" setting.

The cPanel php.ini (/var/cpanel/3rdparty/lib) uses:

register_argc_argv = On

Which needs to be off, if: variables_order = "EGPCS"
This line needs commented out also: gpc_order = "GPC"

In our php.ini we also had to change:

allow_url_fopen = On

to Off, or we couldn't access PhpMyAdmin via cPanel/WHM, because it prompted a file download instead of opening the php.

And some other settings, too many to list here.

Our Server specs:
Apache 2.2-1.7
Prefork
Mod_fcgid

[email protected]# cat /usr/local/cpanel/version
11.28.85-EDGE_51177

[email protected]# php -v
PHP 5.3.4 (cli) (built: Mar  3 2011 01:40:12)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by eAccelerator
    with the ionCube PHP Loader v3.3.20, Copyright (c) 2002-2010, by ionCube Ltd.

Php 5 only
Fcgi
Suexec

 

[smoge]

I just had a server down due to this... running WHM 11.28.83 - so it appears it is not fixed (at least in the RELEASE code).

Can we get an update as to when this will be or has been fixed?

 

[cPanelTristan]

Hello,

I've checked the #46972 case and it is resolved in our nightly builds that will be going into 11.30. I do not see any backmerge tag for the case to put it into 11.28.

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.

Thanks.

 

[sneader]

I opened a ticket to look into the issue on my server, and also to ask about the back merge for 11.28, per your suggestion. I'm told that the back merge is now complete. Per cPanel tech:

Also, as per your inquiry about requesting a back merge, both cases are already marked for a back merge to 11.28.

- Scott

 

[cPanelTristan]

If you review the changelog for 11.28:

CPanelVersion1128 < AllDocumentation/ChangeLog < TWiki

#46972 does not appear there. In order to determine if a case has actually been pushed into a set version, the number will appear in the changelog, which is why we oftentimes advise reviewing the changelog for the cases and quote the case number here and in tickets.

If there is another case that this is in reference to specifically, please provide the number(s). There is absolutely no backmerge tag set for #46972, so that is not set for backmerge from anything I can find in it. I re-reviewed the entire case in our internal system to ensure again that it wasn't set to port back to 11.28 and it is only set for 11.30 at this time.

 

[sneader]

Hi Tristan. Would you be willing to take a look at my Support Request Id 1279601, where the tech has stated that the case was set for a back merge. Perhaps that tech needs some help in understanding the situation as well.

Thanks!

- Scott

 

[cPanelTristan]

Upon looking over your ticket in our system, the technician had referenced case #47683 for duplicate entries (not the quotes around the url_rewriter.tag itself), that case 47683 has been marked for backmerge, but has not yet been backmerged.

The case 46972 is not set for backmerge. I have sent an inquiry to development about whether this can be considered, since 46972 is now in closed (fixed) status due to having been implemented into 11.30 code base.

 

[sneader]

Thanks for the clarification -- I missed the two different case numbers!

- Scott