Gallery media editor fails to save metadata for images over 100 (10 posts)

  1. drueck
    Posted 3 years ago #

    I am running WordPress 3.4.1 on a Dreamhost shared hosting plan and was attempting to create a slideshow with the Portfolio Slideshow Pro plugin, which uses (and extends) the standard WordPress Gallery to manage its images and metadata. It had always worked well until I attempted to create a slideshow with 119 images. The uploader allowed me to upload all 119, and the editor allowed me to save metadata (Alternate Text, Description, etc) for each image up to 100, but when I attempted to add metadata to image 101 and clicked "Save all changes" it silently failed. It behaved just the way a successful save would in that it refreshed the list and collapsed all the expanded image sections, but when I went back in to verify the data was saved, it was not.

    I posted a support ticket on the Portfolio Slideshow Pro forum here: http://madebyraygun.com/support/topic/not-saving-metadata-for-gallery-images-over-100/ and they had me try a few things, one of which was trying to upload over 100 images to a standard WordPress page that was not using the extended features of the plugin. I tried this and the same behavior occurred. I also disabled all other plugins, increased the memory limit to 96M and enabled WP_DEBUG and found that there were no relevant errors logged.

    I put in a support ticket with Dreamhost in case this is a hosting issue, but it feels like the fact that it is being consistently limited to exactly 100 must be something in the code, intentional or otherwise.

    Anyone encountered this before? Any thoughts? Thanks,


  2. bootle
    Posted 3 years ago #

    Can confirm exactly the same issue - also using Portfolio Slideshow Pro. Thanks for proving that it's not the fault of the plugin, but happens with the normal gallery.

    Not using Dreamhost for hosting, with icdsoft.

    Agree with you that it's most likely in the WordPress gallery code, intentional or otherwise. My client created a portfolio of 174 images and wondered why the captions were not working - so clearly if there's a limit, it needs to be much higher. The user case is an auctioneer's site - so a portfolio of many small items to be real-life auctioned.

  3. drueck
    Posted 3 years ago #


    Just to test a different configuration I decided to try uploading over 100 images to a standard page on a different WordPress install on a different host without Porfolio Slideshow Pro installed. I uploaded 143 photos to a standard page on a WordPress install on Bluehost shared hosting and it allowed me to edit and save metadata on all the images with no problems. That install had WooCommerce installed, which I don't think works side-by-side with Porfolio Slideshow, so I wasn't able to test if Portfolio Slideshow made a difference or not.

    I just wanted to post that as an admission that we may not have ruled out Porfolio Slideshow Pro yet. I am planning to do some more research, including possibly creating another WordPress install on my Bluehost account and installing Porfolio Slideshow on it without WooCommerce or any other plugins to see if it still works. If so, that might point to the host or my particular server with the host. My experience with Dreamhost so far hasn't been very good, but that may be because of the other users on my shared server taking up a lot of resources?

    Dreamhost is also following up with me, so maybe they will have some insights after they login and try to reproduce the error themselves.

  4. bootle
    Posted 3 years ago #

    Solution found.

    I set up a simple test case on a desktop machine (Ubuntu, with xampp) and my test account at the shared hosting company (www.icdsoft.com - they are wonderful).

    The local version (xampp) was OK, the simple test case at the hosting company showed the same fault - i.e. above 100 images the metadata was not saved.

    I raised a ticket with ICDsoft, which was immediately taken. After 38 minutes of investigation (an unusually long time, but this was a relatively hard query) they had the answer. Here it is:

    We checked this. The problem was caused by the default limit (1000) of the max_input_vars variable. We created a global php.ini file for your account and added the following line to it:
    max_input_vars = 2000
    Thus, we increased the limit to 2000. You can modify this line according to your needs.
    You can edit the global php.ini file for your account via the hosting Control Panel (https://xx.xxx.xxxx..com) -> the "System Information" section -> the PHP Settings (edit) link -> the Advanced Mode link at the left-hand side. More details are available at:
    The "max_input_vars" setting was introduced with PHP 5.3.9. Servers running versions prior to 5.3.9 would not experience this problem. 
    Let us know if we can assist you further. Thank you.
    Best regards,
  5. drueck
    Posted 3 years ago #

    Bootle, I replied in the Raygun forum, but I thought I'd reply here too for the benefit of anyone else reading this thread. I was excited to see that your host found a solution for you... that's pretty impressive service! So, I tried setting my max_input_vars to 2000, then to 3000 to see if that solved the problem, but sadly it didn't for me. So, there must be yet another issue in my configuration.

  6. bootle
    Posted 3 years ago #

    Hi - did you try phpinfo() to check the PHP version (below PHP 5.3.9 does not have this setting and should not be affected), and if PHP 5.3.9 or above, it should show whether your config changes have actually been picked up.

  7. drueck
    Posted 3 years ago #

    Yeah, I checked phpinfo and I'm running PHP 5.3.13 and max_input_vars is set to 3000 currently. : (

    I really wish that would've fixed it.

  8. bootle
    Posted 3 years ago #

    Here's my phpinfo in case useful:


    and the demo running 176 images, minimal (i.e. latest WP, PSP and nothing else)


    Hope that helps you find the issue. If it does, let me know, so I can close the above projects.

  9. drueck
    Posted 3 years ago #

    Thanks so much for posting your phpinfo. I compared yours to mine and made a couple of changes to make mine closer to yours, but none of my changes seemed to make any difference. I also tried what my host suggested and changed from FastCGI to CGI and disabled mod_security and neither of those things made any difference either.

    We are running different versions of MySQL... kind of doubt that has anything to do with it, but it's possible. Data not getting saved? Man, kind of running out of ideas.

    Anyway, thanks so much for your help, bootle. Definitely going above and beyond to help me out. I saved the output of your phpinfo just in case I want to further explore it, so feel free to take down your test site whenever you'd like to.

  10. bootle
    Posted 3 years ago #

    I double checked by resetting the max_input_vars to 1000 to prove metadata could not be saved, and back to 2000 to prove it could be saved again (on first and last image - it only has an issue with images > 100).

    This might be useful - the php.ini file my hosting company put at the top of the shared hosting (home/bootle, where I do not have direct access, but can edit through a control panel):

    zend_extension = /usr/local/ioncube/ioncube.so
    register_globals = Off
    magic_quotes_gpc = Off
    post_max_size = 20M
    memory_limit = 200M
    upload_max_filesize = 20M
    max_execution_time = 120
    expose_php = Off
    session.save_path = /tmp
    mysqli.default_socket = /tmp/mysql5.sock
    mysql.default_socket = /tmp/mysql5.sock
    error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
    max_input_vars = 2000

    Finally, I set max_input_vars to 1000 again and then tried to override with a local php.ini in my wordpress directory. This did not work.

    Overriding it with a php.ini file in the directory one above the wordpress directory did not work either.

    So clearly needs some care in where the php.ini file is. Pretty convinced max_input_vars is the key as I can toggle the effect reliably. But the variable does need to be set globally.

Topic Closed

This topic has been closed to new replies.

About this Topic