My checkout module has started to refuse the adding of additional products.
I can add new products and prices and hit the save but when I go back to add more nothing has been saved.
There are no error messages.
Everything is ok until 12 products are listed - after that it will not accept more products.
Is there a limit on how many products you can have in the checkout module?
Also once a product is listed - i find I cannot change it in any way - or even delete it.
Uninstalling the module and reinstalling is the only way to re-edit the product list.
this has got me stumped...
Gallery version = 2.2.6 core 1.2.0.8
PHP version = 5.2.6 apache2handler
Webserver = Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.8b mod_bwlimited/1.4 PHP/5.2.6
Database = mysqli 5.0.67-community, lock.system=flock
Toolkits = Exif, Gd, LinkItemToolkit
Acceleration = none, none
Operating system = Linux saturn.codev.co.nz 2.6.18-5-xen-vserver-amd64 #1 SMP Tue Dec 18 23:52:27 UTC 2007 x86_64
Default theme = matrix
gettext = enabled
Locale = en_US
Browser = Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.04 (hardy) Firefox/3.0.4
Rows in GalleryAccessMap table = 39
Rows in GalleryAccessSubscriberMap table = 1725
Rows in GalleryUser table = 5
Rows in GalleryItem table = 1724
Rows in GalleryAlbumItem table = 7
Rows in GalleryCacheMap table = 0
Posted: Tue, 2008-12-02 00:19
Posts: 39
Upgraded to:
Checkout 0.4.2
checkout by email 0.4.2
Checkout by Paypal 0.4.0
But the problem still remains, after 12-14 product entries it just stops saving any editing from then on..
Posts: 4342
There's no intentional limit. Somebody else had this problem, but I can't find the thread. If you want me to look into it, pm me an admin login for your installation, also access to your ftp server for code changes and credentials for your phpmyadmin.
Posts: 39
Thanks alecmyers I will organise that info for you.
The issue happened after the websites were migrated from one server to another.
The hosts are sure there is nothing wrong at server level so there must be something got screwed in the copying process.
There are 4 gallery installs which are all sub domains of www.sportsimages.co.nz
This problem occured on all 4 at the same time.
They have 25 or so products listed in checkout but I cannot edit them. ( the changes dont save )
If I reinstall the checkout module and rebuild the list it stops saving after a dozen or so entries.
Posts: 4342
Thanks for the pm.
I've looked at your website, and done some debugging.
I believe that you have a problem with your ISP - it appears that your $_POST php global is being truncated before Gallery runs, with the result that long forms are not having all their inputs received. In particular, the 'g2_form[action][save]' input was not being returned to php, and so no form action was happening.
The checkout admin page is quite a long form, with a large number of inputs, and the save/cancel buttons are at the end. So if the php installation was truncating the $_POST array, they would be the first to be lopped off.
I've moved the button code (in a local/admin.tpl file) in the site you asked me to look at to the top of the template. Saving now operates ok, but unfortunately a different set of inputs is now being lost - the ones which are now at the bottom of the page - the email settings.
In the short term, if you reduce the number of products then the number of form variables will decrease, and you should be able to re-enter your email settings.
I would also contact your ISP and see if they have a limit that they can increase for you. If it is something your ISP is imposing (I can't think of an alternative explanation, but there might be one) then I would change ISP. It's not a reasonable limit for your intended use of the webserver.
The fact that it's occuring on all four of your installations is consistent with it being a server issue.
I would also expect to see problems on other Gallery pages that have large numbers of form inputs, such as when deleting images, as well as other checkout pages like the "select" page (cart page) where you get at least one input for each product multiplied by the number of items in the cart.
Posts: 39
Thanks heaps for your diagnosis efforts - I will ask the hosts to have another look and show them your explanation.
cheers
chris
Posts: 39
My Host has upped the POST size to 256mb and then again up to 512mb (whatever that means) but the problem remains.
Is there some other setting that they need to adjust?
thanks
chris
Posts: 4342
Chris,
it's not the length (in bytes) of the $_POST array, it's the number of elements that appears to be limited.
I've just taken some copies of what's being sent to your server with Fiddler, which can log the browser's POST body, with all the form inputs. That's a decoded version of a IP packet dump of the transmission from my browser to your webserver. (I'm confident that it's not a browser or client artifact as it occurs on different machines on different continents, and with different browsers.) At present in your checkout admin page there are 207 inputs. POST_body.txt - attached - shows them displayed one per line - exactly what my browser is transmitting. You'll see that number 200 is the g2_form[emails][0][showThumbs] element (with value '1'), number 201 is g2_form[emails][0][emailLanguage] with value 'transaction_language' etc. That's with the save and cancel buttons moved right to the top, as I described in my previous email.
By inserting a debugging line at the very start of main.php (I've left it in, but commented out, so that you can continue debugging with your ISP) I've printed out the php $_POST array that is being delivered right at the start of php operation, before any of the Gallery code has actually executed. This is attached in file $_POST.txt.
You'll see that the last array entry is [g2_form][emails][0][showThumbs] (with value 1) - that's the 200th element in the browser POST, and the last 6 are missing, including the [emails][1]... [emails][2]..., g2_form[orderStatusFromAddress] and g2_form[orderStatusSubject] inputs. Gallery is obviously unable to record what isn't presented to it by the Apache Webserver.
I don't believe there's anything more I can do, and that if you and your ISP get this issue solved then Checkout will work correctly.
Good luck!
Posts: 1
As far as the php docs say, there is no limit on the length of $_POST.
Posts: 4342
I've also read the docs. racepics will no doubt be open to alternative explanations for what's happening to all four gallery installations on his server.
Posts: 39
The problem turned out to be cPanel ( or some sort of bug in cPanel ) - we reverted back to vitualmin and all is well.
Thanks so much Alec for your diagnosis efforts