Where does my modified php.ini need to reside?

Author Message

André Jönsson

Friday 06 February 2009 5:41:14 am

Hi!

Installing eZ Publish isn't exactly all that easy when you don't have root access to the server. I'm in a hosted, albeit very customization friendly, environment right now and am trying to install eZ Publish.

PHP runs not as a module but in CGI mode, through the use of SuPHP. While this hinders php option setting in .htaccess-files, it enables me to use my own php.ini (which, at the moment, is the servers' default one but modified with the allow_url_fopen and those other changes) that right now resides in my /ezp folder (which is the root).

Now I'm just wondering; running a .php-script in /ezp/bin/php, for example, or any of the folders that have php-files will not use this php.ini.

Therefore I've been thinking about using a symlink in each needed directory to php.ini in the root. That way I only need to change one file if I need to change settings.

But is this needed? I'm still pretty (make that very...) new to eZ and not yet quite confident in it's internal structure. Therefore my question is two-fold. Is it needed that I create these symlinks in all folders that have .php-files in them (of which I do have a list, after running a find-command)? Do I even need to have it inside /var/cache/template/compiled, for example?

And the second part of my question is quite obvious: is there any better way of doing this?

Greatly thankful for all input on this.

Regards,
André

Gaetano Giunta

Friday 06 February 2009 7:08:44 am

I am not a su-php expert, but the doc says that it can be configured to use a php.ini file from a given directive, via the suPHP_ConfigPath directive.
This means you can put your php.ini eg. at the eZ Publish root and have it always used by any php script run by your webserver, be it index.php or within aany subdirectory (I imagine you will have a vhost section in the Apache file that is under the control of the hosting providers but that is dedicated to your website, where suPHP_ConfigPath is set).

I would not recommend running eZ Publish without an (Apache) rewrite rule that redirects all accesses through the index.php file, unless really necessary.

About running php scripts designed to be run from the command line:

first of all they will not activate at all if run via the webserver, and that is a security measure. They are designed to be run by the site admin, not by any site visitor going eg. to http://mysite/bin/php/ezsubtreeremove.php. This also applies to runcronjobs.php, and since you are quite likely to need at least a couple of the eZ cronjobs running, you should see if you can have cronjobs set up in your environment.

Second is, if you have a shell access to invoke those scripts using php in cli mode, you can invoke php using the -c option, or setting up the PHPRC env var. Both options tell the php interpreter where to find the ini file, so you do not have to symlink it all over the place. It is quite common to have eg. one php.ini for the webserver and a different one for cli scripts.

Principal Consultant International Business
Member of the Community Project Board

Gary Teh

Sunday 08 February 2009 10:56:53 am

Perhaps do the ini settings in a configure.php and have it included in the index.php file?

http://name1price.com : Get a Cool website for yourself and also learn how to manage it. It is easy. Use it to get more customers for your business.

André Jönsson

Wednesday 11 February 2009 3:25:10 pm

I just want to say I'm incredibly thankful for the friendly answers. I have resolved my issues, which I mistakenly thought were on my part. It wasn't – as I originally gathered from the logfiles – an issue with the php.ini but rather that php wasn't compiled with mbstring.
A quick email to my host sorted it (by the way, they must be one of the best hosts in the world... it never takes more than 15 minutes for them to respond to an email and at two separate occasions they've recompiled php (the first time for ImageMagick) in less than an hour from my inquiry). Apparently they had missed the compile flags when upgrading php.

Anyway, after that all my problems disappeared and finally I have a perfectly (so far at least!) working eZ Publish environment. Now I've just got to dive straight into learning to use it... but that's another story.

<b>Again, thanks a lot guys!</b>

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.