- Status
My guess is that the new server has a limitation on the upload size. This is not in the PhotoPost settings, but the actual web server software configuration.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20 ( )
:rotflm: :rotflm: :rotflm:
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Generally, these problems are really caused by the default values of the php.ini file. In the past when we asked Joey or guys to make the changes, they tended to be too conservative. I recommend strongly that you make Sure that admins have have access to the file or apache allows local php.ini files or parameter overrides via .htaccess
Here is brief summary of the parameters value that your people will need to understand. Actually I'm sure both Bas & Jim already understand.
I recommend as a starting point upload_max_filesize = 32MB and post_max_size = 34MB. This will give you the ability for a user to upload a group of pictures at one time that have a total of 32MB.
Tracy, Bas, and Jim, if you would rather I didn't post this kind of help, let me know by PM and I'll cease and desist.
Mozilla/5.0 (iPad; U; CPU OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5
I was just about to chime in with the same.
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Tracy, I may be saying things you already know but just in case. Php.ini is not always where the the effective php parameters are. The are several ways it can be set up.
The only way to be sure what the effective parameters are, is to run a phpinfo script in the pp
directory.
Create a file phpinfo.php containing
PHP:
<?php
phpinfo();
?>and place it in the pp directory and then run http://ncwoodworker.net/pp/phpinfo.php
Mozilla/5.0 (iPad; U; CPU OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5
This is just for my curiosity's sake so please take it with a grain of salt. 
My question is why would we want to upload picture files of 1MB or more?
Bandwidth and site files sizes(total size of the site) cost money, so generally speaking the smaller you can keep a file the better.
Most picture files can be kept under 100kb and still look really good on a web page. If your pictures are to be downloaded and printed out then that's an entirely different thing of course.
As an example the pics posted in this topic on my site show reasonably well and most, if not all, of them are under 100kb.
http://www.ourfamilyforum.org/FamilyForum/index.php?topic=2831.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
My question is why would we want to upload picture files of 1MB or more?
Bandwidth and site files sizes(total size of the site) cost money, so generally speaking the smaller you can keep a file the better.
Most picture files can be kept under 100kb and still look really good on a web page. If your pictures are to be downloaded and printed out then that's an entirely different thing of course.
As an example the pics posted in this topic on my site show reasonably well and most, if not all, of them are under 100kb.
http://www.ourfamilyforum.org/FamilyForum/index.php?topic=2831.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Agreed. For most web pages, the resolution does not need to be that high. However, we also have the annual calendar contest, and those pictures need to be of high quality since they'll be printed.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20 ( )
Ah... reason enough then. :icon_thum
Now I'll have to check out the contest details.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Now I'll have to check out the contest details.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
This is just for my curiosity's sake so please take it with a grain of salt.
My question is why would we want to upload picture files of 1MB or more?
Bandwidth and site files sizes(total size of the site) cost money, so generally speaking the smaller you can keep a file the better.
Most picture files can be kept under 100kb and still look really good on a web page. If your pictures are to be downloaded and printed out then that's an entirely different thing of course.
As an example the pics posted in this topic on my site show reasonably well and most, if not all, of them are under 100kb.
http://www.ourfamilyforum.org/FamilyForum/index.php?topic=2831.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Thanks Ken.
I did some digging around and learned how to resize digital ohotos and managed to upload to our site successfuly (Took the image down to about 100KB.) This picture doesn't need the size of a typical pic destined for the 2012 calendar contest.
Thanks again for the suggestion.
Wayne
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; FunWebProducts; GTB7.1)
You're welcome Wayne, glad to be of any possible service.
Back when I started my first web site there was only 5MB of space available to me, so I had to learn to squeeze out every last kb possible. :rolf:
And, at the time well over half of all internet users were still on dial-up so you had to be concerned about how fast a page would load for your users... currently it's a little less than 10% of the users still on dial-up I think, but page load times can still be an issue because many younger folks (and some older ones as well) are not willing to wait more that a few seconds for a page to load up.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
Back when I started my first web site there was only 5MB of space available to me, so I had to learn to squeeze out every last kb possible. :rolf:
And, at the time well over half of all internet users were still on dial-up so you had to be concerned about how fast a page would load for your users... currently it's a little less than 10% of the users still on dial-up I think, but page load times can still be an issue because many younger folks (and some older ones as well) are not willing to wait more that a few seconds for a page to load up.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
I don't know if you were aware, but there are three variables that will come into play here:
memory_limit - The maximum memory available to a script -- I recommend a bit more than twice
post_max_size, especially with smaller limits. Based upon my 16MB upload size suggestion, set to 50MB. Depending on how your scripts handle uploads, you may find that this can be dialed back to 32MB without restricting a 16MB upload.
post_max_size - The maximum size of an HTTP POST response (essentially the buffer for a POST response). Based upon my 16MB upload size suggestion, set to 24MB.
upload_max_file_size - The maximum allowed size for uploaded files (about 2/3 size of post_max_size can be a good start). I suggest at least 16MB to allow for tutorial uploads.
Two other variables that can also come into play are max_execution_time and max_input_time, especially with larger uploads and/or slow connections which can require more time.
On my primary web server these are rather astronomical figures (up to 320MB for memory_limit) due to users who need to routinely move large files (up to 144MB) via email (SquirrelMail) and their personal web storage area (also via SquirrelMail).
You will probably want to aim for a max_file_size of around 16-32MB to allow for Tutorial uploads and so forth and adjust the other variables accordingly. My max_execution_time is 1h20m (for your purposes 10-15m is probably better) my max_input_time is 10m (you may wish to start with 5-10min).
Over time you can experiment with increasing/reducing these values until everything is dialed in. You basically want values large enough to insure that 99.999% of legitimate activity can complete without hassle while keeping them low enough to protect the server during modest scripted attacks (there is no practical defense against a heavy attack -- that must be handled at the router level).
If you are using a PHP Accellerator, then there may be other relevant variables, though most accellerators will use the memory and timings already defined in php.ini.
I apologize for not taking the time to write this all up yesterday, but I was just about to nod off at the time and I only just woke up (I do best with 36-48hr days, so my bedtime is a bit longer than most).
Steve's suggested quick-and-dirty PHP phpinfo script is also an excellent tip for verifying your changes have taken effect and are not being overridden elsewhere. This is a common developer hack with PHP (I have a custom made equivalent for PERL that I wrote years ago).
HTH - And thanks for all the hard work.
Edit: I give times for max_execution_time and max_input_time in human format (1h20m) the actual php.ini values should be in seconds. I don't know if PHP converts 10m to 600 (sec) off hand, so convert to seconds for your php.ini value to be safe.
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Last edited:
- Status
Premier Sponsor
Our Sponsors
LATEST FOR SALE LISTINGS
-
-
Graco 395 FinishPro air assisted airless sprayer for sale
- Started by RobH
- Replies: 1
-
-
-