1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

configuring custom php settings via panel.ini issues

Discussion in 'Plesk 10.x for Linux Issues, Fixes, How-To' started by burnleyvic, Feb 6, 2012.

  1. burnleyvic

    burnleyvic Regular Pleskian

    17
    85%
    Joined:
    Nov 9, 2011
    Messages:
    174
    Likes Received:
    1
    Just wondering if anyone else has noticed the following while trying to configure the custom php settings available to customers in php settings tab. Its configured via panel.ini which is well and good but...

    Firstly, when customer selects a setting and clicks ok plesk builds the custom php.ini for the client but the setting is in quote marks so safe_mode = off becomes safe_mode = "off" I've noticed it seems to do this for almost every setting it adjusts in the custom php.ini These marks are not in the base php.ini and should be removed so they don't cause errors in applications. If this could please me fixed with a MU...

    Second, I can't configure some of the settings, such as for session.save_path, it seems to ignore any values I enter e.g. settings.general.session.save_path.custom=false I have noticed when I add that line a new section comes up on the php settings tab down the very bottom labelled "session" so I think plesk is not handling the directive settings.general.session.save_path correctly. bug?

    The same also seems to happen for mail.force_extra_parameters, panel is interpreting it only as 'mail' which is why panel.ini configuration does not work. Additional section comes up in plesk called 'mail' which has the values i've pre-defined. If I select one of these php.ini is created with php variable of mail = "value specified from cp" with quotes.

    Strangely it has no issues with settings for open_basedir which is why I suspect the above are bugs.

    Also is there any way to remove a parameter from the php settings tab. I'd like to remove parameters for which we don't want to give customers the ability to change anything. If not can this be added please. Also ability to add/edit the description would be good. Happy for it to all be done in the panel.ini
     
  2. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,564
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    From /etc/php.ini:

    ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one
    ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression
    ; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
     
  3. burnleyvic

    burnleyvic Regular Pleskian

    17
    85%
    Joined:
    Nov 9, 2011
    Messages:
    174
    Likes Received:
    1
    Hi Igor,

    I'll do some more testing regarding the quotes, if the applications don't have issues with the quote marks that's fine, I'll update tread once tested.

    That said the second issue I mentioned regarding the two parameters which don't seem to load properly from panel.ini Are you able to re-produce this?
     
  4. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,564
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    Regarding second issue. As far as I know Plesk does not manage these options. It behaves differently for module/cgi because the OS vendor setup PHP this way. Possible workaround in http://kb.parallels.com/7056
     
  5. burnleyvic

    burnleyvic Regular Pleskian

    17
    85%
    Joined:
    Nov 9, 2011
    Messages:
    174
    Likes Received:
    1
    Sorry Igor I don;t think you quite understand the issue. Session save path works perfectly if I specify it in customers php.ini file. we sorted out those permissions some times ago with regards to write errors in cgi & fast-cgi modes. The issue is to do with the script that reads custom settings from the panel.ini.

    See http://download1.parallels.com/Ples...sk-10-linux-advanced-administration-guide.pdf page 29 & 30

    Hiding the Custom Value Fields
    To hide the field that allows entering the custom value for a certain PHP parameter, add the line of the following type to the
    PHP:
     section of the panel.ini filesettings.<parameter_group>.<parameter_name>.custom=false

    so I have added the line settings
    .general.session.save_path.custom=false but plesk ignores this value.  If I set a custom value plesk creates a new field down the bottom labelled "session" so your script is not interpreting the value properly.  Same goes for mail.force_extra_parameters.
     
  6. burnleyvic

    burnleyvic Regular Pleskian

    17
    85%
    Joined:
    Nov 9, 2011
    Messages:
    174
    Likes Received:
    1
    In regards to customer php.ini settings per domain there seem to be several bugs still in existence all of which should have been dealt with by parallels in the past. Clearly the work is being rushed out the door before its getting more than a cursory test. For example the issue with quote marks around the safe_mode parameter has been fixed but they have ignored the same issue with regards to error_reporting parameter. The second issue was reported as a bug or more likely a simple typo that was not picked up but the fix has not been merged into the MU update channel and is now broken again.


    Here are the details;

    First issue;

    In the panel.ini file if I don’t specify anything for error_reporting then plesk gives a drop down box with 3 options by default, they are respectively;

    Default
    ~E_All
    E_All & ~E-Notice
    E_All

    Selecting any of these results in Plesk writing the parameter in quotes into the configuration file;

    e.g. error_reporting = "E_ALL"

    Note the double quotes, making it a String, not a constant (number value).
    So phpinfo() dutifully reports that 'error_reporting' is set to the characters E_ALL, but when PHP converts that to a number to use it, it returns 0.

    Proposed fix to send to the people at Plesk - don't put quotation marks in the error_reporting value in the customer's php.ini.

    Authors note:

    I can sort of fix this by adding the following linex into plesk’s panel.ini configuration file. The only problem with this is that Plesk then only the numbers in the drop down box e.g. 37719, 37711, etc I’m not sure the average developer will know what the various numbers mean so plesk will need to display the words but save it in the customers php.ini without the quotes!

    ;error_reporting
    settings.general.error_reporting.custom=false
    settings.general.error_reporting.values[]=E_ALL
    settings.general.error_reporting.values[]=E_ALL & ~E_NOTICE
    settings.general.error_reporting.values[]=E_ALL & ~E_NOTICE | E_STRICT
    settings.general.error_reporting.values[]=~E_ALL

    selecting the first line gives the following in customers php.ini which I believe works;

    error_reporting = 30719


    Second issue.

    Since updating panel to MU#27 the session.save_path and mail.force_extra_parameters are both broken again! I believe we had a ticket open concerning this but they have obviously not merged the fix into the latest MU updates. I believe this was ticket numer #1331003. I can confirm they have indeed fixed the quote marks around safe_mode parameter but I suspect a rush job as there are still some very simple errors.

    In panel.ini I add the following lines as per your documentation;

    ;session.save_path
    settings.general.session.save_path.custom=false
    settings.general.session.save_path.values[]=/var/lib/php/session
    settings.general.session.save_path.values[]={DOCROOT}/session
    settings.general.session.save_path.values[]={WEBSPACEROOT}/session

    ;mail.force_extra_parameters
    settings.general.mail.force_extra_parameters.custom=false

    In both cases all parameters are ignored! Perhaps parallels could consider making their existing stuff work before pumping out more broken stuff. Just a thought!
     
Loading...