Tag Archives: php.ini

PHP: What is the Maximum Amount of Variables in $_POST? Tips, Tricks and Tutorials 01 AUG 2013

green php elephants - elephpantsI came across an interesting problem the other day when a fairly large (poorly written) form seemingly wasn’t being completely processed, and no one could figure out exactly why. Now we’re all familiar with the post_max_size PHP configuration option which controls the maximum size of a form POST, and usually this is the first one that gets turned to when it appears as if a POST isn’t coming through correctly.

However, in this particular case it was only small strings being pushed through, meaning that size wasn’t an issue here – so I did a little digging and found this little bugger: max_input_vars.

It turns out that by default, PHP applied a 1000 element limit to the $_POST variable. If the limit was exceeded, then PHP would simply truncate the $_POST variable back to the correct size – which was exactly what was happening with the large form in our case.

Luckily for us, with version 5.3.9 of PHP came this new configuration option, max_input_vars, which allows us to change this limit. From the documentation:

max_input_vars: How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request. This limit applies only to each nesting level of a multi-dimensional input array.

Note that you can’t set this configuration option at runtime meaning that you must add it to your php.ini file and reload the Apache server.

If you are working in Ubuntu from a terminal:

# add your new value anywhere in the php.ini file: max_input_vars = 2000
sudo nano /etc/php5/apache2/php.ini
# reload apache
sudo service apache2 reload

Nifty.

How to Fix PHP Warning: “It is not Safe to rely on the System’s Timezone Settings” Programming 26 FEB 2013

At some point in time with the newer versions of PHP, a lot of you would see this warning spit out by your PHP installation every time you called a date related function:

“It is not safe to rely on the system’s timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘UTC’ for ‘Africa/Johannesburg’ instead”.

What it is basically telling you is that you need to explicitly set the timezone which PHP is to use, instead of just letting it run with whatever the server was using as you used to do in the past. To do this you have two choices, which if you had bothered reading the warning message, would have been given to you on a platter.

The first option you would use on a script by script basis, which of course doesn’t really make all that much sense. Basically, call the date_default_timezone_set() function and set it to a timezone string of your choice.

The second option, and the one which makes the most sense is to set the default timezone in the php.ini configuration file itself, using the date.timezone declaration. In practice:

...
date.timezone = 'Africa/Johannesburg'

Nifty.

Related Link: http://php.net/manual/en/function.date-default-timezone-set.php

How to Check if PDO is enabled in my PHP on Apache Installation? CodeUnit 13 DEC 2012

PDO is a popular way of managing database connections and activities in the LAMP stack, though it isn’t always turned on by default unfortunately.

Lucky for us, the following simple PHP code snippet runs a simple enough check and then alerts us to the status, making it a breeze to pick up on whether of not PDO is actually available or not.

if (!defined('PDO::ATTR_DRIVER_NAME')) {
echo 'PDO unavailable';
}
elseif (defined('PDO::ATTR_DRIVER_NAME')) {
echo 'PDO available';
}

Simple but rather effective.

How to Solve: Fatal error: Class ‘PDO’ not found in PHP File CodeUnit 07 DEC 2012

I tried installing the useful open-source invoice management web application Siwapp the other day, and on trying to run the install script I kept getting shot down with a “Fatal error: Class ‘PDO’ not found in…” error message.

Some time spent on Google informed me that the problem lies in the fact that the popular PDO database handling extensions weren’t installed properly on my web server, despite PHP info telling me explicitly that the version of PHP which the server was running was compiled with PDO support.

Anyway, after some digging around on the ‘Net, I found the quick way of solving this issue, pretty much through adding some lines to your existing php.ini configuration file.

So, after opening up the relevant php.ini file via my server’s cPanel installation, I added the following lines to the bottom of the file, in the extensions section of the .ini file:

extension=pdo.so
extension=pdo_sqlite.so
extension=sqlite.so
extension=pdo_mysql.so
extension=php_pdo.dll

Obviously, you don’t have to add all the database types if say your application only uses MySQL.

You might have to restart your webserver, though this is doubtful, and as long as your version of PHP has been compiled to support PDO, you should now be free of the dreaded “Fatal error: Class ‘PDO’ not found in…” message. (phpinfo should give you some more information about what PDO functionality you now have access to).

Nifty.

PHP: Warning: stream_socket_enable_crypto(): this stream does not support SSL/crypto CodeUnit 30 AUG 2012

“Warning: stream_socket_enable_crypto(): this stream does not support SSL/crypto” is a message you will often come across when doing mail send work in PHP, particularly when your SMTP settings require you to connect using either a SSL or TLS mode.

The reason for the PHP warning message is actually not insidious at all – 99% of the time it refers to the fact that the OpenSSL extension hasn’t been enabled in your PHP configuration file – and under XAMPP this is almost always the case.

So a simple fix is to navigate to your php.ini file (for XAMPP it usually sits under xampp\apache\bin\php.ini), open it up and run a search for “extension=php_openssl.dll”.

Uncomment this line by removing the semi-colon at the front of it, save the file and then restart Apache via the Services panel.

Nifty.

Ubuntu: Change the File Size Limit for phpMyAdmin SQL Dump Imports CodeUnit 19 NOV 2010

phpmyadmin logoWorking with the web-based phpMyAdmin can sometimes be a bit of a lesson in frustration, particularly when you start bumping your head against its various limitations. One such annoying limit is the default 2MB upload limit applied for SQL file imports.

The good news is that this limit is actually not a hard and fast part of phpMyAdmin any more – and changing it to something a bit larger to handle those bigger databases is pretty simple to achieve!

So let’s get started then.

The size limitation is actually controlled by the PHP implementation powering the web server that is dishing up the phpMyAdmin portal, meaning that changing the default limits imposed by the PHP configuration will in turn adjust the limits imposed by phpMyAdmin.

The first step is thus to open up the php.ini configuration file for editing.

gksudo gedit /etc/php5/apache2/php.ini

Once open, search for the following three settings and adjust them accordingly to suit your upload needs – e.g. change 2M to 16M.

  • upload_max_filesize
  • post_max_size
  • memory_limit

Save the changes made to your php.ini file and then reload Apache’s privileges (i.e restart the webserver):

sudo /etc/init.d/apache2 reload

And that is that. Reload the phpMyAdmin import page and you will see that the limit has now changed to what you have set it to be in the php.ini file.

Nifty.