I've just had this weird problem start happening on a large Ubercart store. When editing a product's attribute options, we can't make any changes. It just reloads the same page with the same options selected when you hit "Save".

This was working fine when we first deployed the site on the server, and the only recent change made is moving the site from a 'dev' sub folder to the root to send it live.

I also have the "Option Images" module installed, but I've already tried disabling that module to rule it out as the cause.

I noticed a similar issue was reported for 6.x.2.7 here - http://drupal.org/node/1441196

I'm really stumped. Does anyone have any suggestions?

Comments

tr’s picture

Category: bug » support
Dan Z’s picture

Problems that pop up when you move a site's files are often write-permission problems. I'm not sure how that could be related to saving options, since that's just a database operation, but check it your sites/default/files directory and subdirectory anyway (don't forget selinux, if you're running that).

Do other operations work, or is it just saving options that's a problem?

If nothing obvious shows up, turn on error, debugging and developer messages to see if that gives you a hint. See http://drupal.org/node/1056468 for instructions on how to turn on some of those, and http://drupal.org/project/devel to see a bunch more. You may wish to look at your logs, especially your database logs, as well.

Anonymous’s picture

Thanks so much for your response. I have changed sites/default/files and everything underneath to 777. All other functions on the site work correctly, including other attribute-related tags (Attributes and Adjustments). The Options tab just doesn't update the options and doesn't return any message, just refreshes the page as it was.

Have also updated to the latest Ubercart dev but still no luck. Have checked the Drupal error logs and there's nothing of interest there. The devel module is useful, but I don't really see anything in the query log that is suspicious.

One thing worth mentioning, we do have an awful lot of options, and the problem only seemed to arise after the client had added those in.

Also - more importantly - I have just tried moving the site to my dev server on my local machine and it works fine. Cloned database and files. That tells me it's something unique to the host/server. I believe the system meets minimum requirements. The fact that it was working previously on that server makes me wonder whether the DB request is timing out or failing due to the large number of options. Just an idea.

Anonymous’s picture

OK so after a bit more testing I have narrowed it down so the problem only happens when a certain combination of attributes is selected. It just so happens that these are the two attributes with a lot of options. Colour Range A has 95 options and Size has 151 options. Any other combination of options works, but when these two are selected together, the form doesn't get submitted. So I guess it does have something to do with the database query being too big.

Having said that, are there any options I can look at to prevent this happening?

Dan Z’s picture

It sounds like you're on the right track. Some things you may want to try:

Talk to a DBA.

Look at the database error and session logs.

Increase the PHP maximum execution time.

You may also be running into an issue described at http://drupal.org/node/375019. That's a lot of options!

tr’s picture

Status: Active » Closed (duplicate)

From what you said in #4, this is a duplicate of #375019: Adjustments page breaks MySQL on too many attribute option combinations - you can pursue a solution in that issue.

Anonymous’s picture

Thanks for your help - will do.

Anonymous’s picture

I found the solution to this - max_input_vars was set to 1000 on the problem server, which was causing the form to fail when trying to post. Increasing to 5000 fixed the problem.

DenimTornado’s picture

Thank you very much! It's help me to!

DenimTornado’s picture

Issue summary: View changes

clarify