Working with WordPress, I often come across the same issue where hosting companies set the initial PHP settings for things like upload_max_filesize and max_execution_time to very low values. This becomes an issue when trying to import large demo content or migrate data from another server. I'm trying to find a way around it using only a PHP script (no FTP access, can't recompile PHP etc...). How can this be accomplished?
Here are a few things to consider:
Using ini_set() only works for certain directive, which makes it useless in my case.
Creating a php.ini or php5.ini file in the root of WordPress only works if PHP is set to scan this directory for additional ini files, which is rarely the case.
Modifying the .htaccess file is an excellent way to achieve this, however, if PHP is run in "CGI mode" and not as an Apache module, this won't work.
Is there a solution that can work regardless of the host's settings? Is there a way to force PHP to scan an additional directory for php.ini files?
Related
I am trying to set the include_path specifically for a given script in a given configuration.
Per Directory Values would be ideally suited for the task, so I am trying this:
[HKEY_LOCAL_MACHINE\SOFTWARE\PHP\Per Directory Values\c\phpDevScripts]
"include_path"="c:\\path\\to\\dev\\lib"
It doesn’t seem to work for CLI scripts but the docs say nothing about this.
Quoted from the "User Contributed Notes":
Being able to put php directives in httpd.conf and have them work on a per-directory or per-vitual host basis is just great. Now there's
another aspect which might be worth being aware of:
A php.ini directive put into your apache conf file applies to php when
it runs as an apache module (i.e. in a web page), but NOT when it runs
as CLI (command-line interface).
Such feature that might be unwanted by an unhappy few, but I guess
most will find it useful. As far as I'm concerned, I'm really happy
that I can use open_basedir in my httpd.conf file, and it restricts
the access of web users and sub-admins of my domain, but it does NOT
restrict my own command-line php scripts..
We have a web-app that we have modified a number of the default php.ini values for; short_open_tag = Off, expose_php = Off, memory_limit = 128M, etc, etc. Our current deployment strategy when we need to scale and bring another app server online involves cloning our app onto a 'new' server that has the latest version of php.ini, along with the distribution-specific (in our case, Debian) php.ini file.
We are currently storing our customized php.ini file in our repo and deploying that when we clone, but ran into a problem recently relating to deprecated config values when a new cloned app server fired up with PHP 5.4+ on it. This resulted in us having a broken config file, and got me thinking about how to best handle this. We'd like to use the default latest php.ini that would contain potentially new directives, and would have deprecated ones removed, and then be able to 'locally' override the settings we need.
Solutions we've considered include using .htaccess files and ini_set(), but three drawbacks here relate to the fact that some settings can only be adjusted in php.ini, that .htaccess will not be used by our cli scripts, and that for each user visiting the site via Apache, we have to process the .htaccess or make calls to ini_set() resulting in unneeded overhead. We've also looked at freezing the version of PHP we use so that there are no updates and changes to php.ini once deployed, but I am not sure if this strategy works best, given we would miss out on minor updates that could be related to security, etc.
Have we missed an option as it relates to portably deploying PHP engine settings?
Per the direction provided by #PeeHaa above, we've decided to lock our application to a specific PHP version (via Composer), taken that PHP version's default php.ini file for both Apache2 and the CLI, and added in our settings. This has then been pushed to our repo, and is copied as needed on deployment and on any git changes to the files.
FYI, in our Debian environment, we've followed the strategy outlined here in terms of installing a specific version of PHP other than latest.
I'm almost sure that PHP is always able to go anywhere on the server and do anything with any files but I'm wondering if there's a way to restrict it to work only in one folder and what would be requirements?
I mean I've got let's say 50 WordPress installations, 50 folders. If a virus from untrusted plugin affects only 1 installation - it instantly goes to 49 other, too (because PHP can scan all the directories on server).
Is there any way to prevent that? If virus breaks into 1 installation of WordPress - I want it to stay only there.
My hosting provider said it's not possible without buying another server. What is your opinion?
With php-fpm you can chroot php workers (for absolute separation) and give every php application its own user and php configuration (timeouts, memory limits, etc.). You don't have to use chroot to have unique users. With simple file permissions you can make the webroots unreadable to anyone not the dedicated user for that webroot. Also this is not specific to Apache, works any other webserver that supports fastcgi.
A little easier to set up way could be relaying on php's open_basedir (there's a dispute of how secure open_basedir is since php's developers frequently fixes bugs related to this feature)
You can install suEXEC and run PHP in FastCGI mode. With this configuration you are allowed to run the PHP instances under different users.
I didn't try this tutorial myself but it looks good to me: How to set up PHP FastCGI with suEXEC on Debian
I've just finished a web application written in PHP. I thought it was as easy as compressing my .php files and dumping my database in order to decompress those files in the "production" server, creating the database structure and database user, but it doesn't work. Several php files have include directives that are not working, I was using "relative" paths in those directives, I've tried $_SERVER[DOCUMENT_ROOT] and fixed the trailing slash issue in that parameter and still is not working. Any suggestions? Maybe you know some "tips" or "instalation-patterns" for PHP web applications.
Check the include_path on the production server compared to your development machine-- the server may be looking for files in different locations compared to your own box.
Regarding deployment there's two projects that I've come across that might be of some help (unfortunately, I've not used either; both are on my ever-growing to-do list):
Phar are PHP Archives; basically, a way of distributing apps in a .zip file that can be run without being unzipped
Phing is a build tool similar to Apache Ant. It can be used to automate the deployment, say if you need files copied to many different locations.
Are you using the same version of php (and host operating system) on the new server as you were on the old one?
PHP can parse your code differently in different version and installations.
PHP has some different behaviors between versions. Also, depending on the setting in your development php.ini file and the one in the production environment, you could see massive differences as they usually have very different security setups.
I am coding in PHP on Apache, and I have access to two main areas on the Unix server. I have a personal directory and I have a project directory. I noticed that in the project directory there is a extension/module that I have access to automatically which I don't have in my personal directory (I can see it listed in phpinfo()).
So I'm guessing that the server admins set it up this way because most users wouldn't require this extension in their personal area, but I do.
I have looked through several base level .htaccess files and conf files, but can't seem to find the point that this extension is being initialized for the project area. Is there a way via PHP for me to list not only all the loaded extensions but at what point they are loaded?
I can think of 2 ways for loading extensions
through php.ini with the extension/zend_extension directories. Note that this would not work with user.ini files (per directory configuration)
through the combined usage of auto_prepend_file INI setting and the dl() function. The latter can load extensions dynamically. And auto_prepend can be used to make the PHP interpreter run any code before yours runs. But dl() has been deprecated in PHP 5.3 and will be completely gone in PHP6.
And if all else fails - why don't you ask your server admins?
Is there a way via PHP for me to list
not only all the loaded extensions but
at what point they are loaded?
No. Ask server admin.