Hi

We recently moved our site to a new server, and ever since doing so everything works fine with one exception. We can't change any of the ubercart attribute options when editing the products.

We can edit the product content fine and the rest of the site, it is purely just the options for the attributes which won't save when we change them. Basically the page just refreshes with the original options selected again.

We use the attributes to identify "dates" for the product (we sell seats at events) so it is pretty crucial.

Can anybody suggest why this might be the case as it's getting frustrating editing the database tables manually to keep on top of this. I thought it might be a permissions issue of some kind but don't really know where to start looking, and the user trying to edit the dates has admin permissions.

I tried posting this to the forum at Ubercart.org a couple of weeks back but no response at all, so hopefully somebody here can give me a few ideas.

Thanks a lot.

Andy

Comments

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Status: Active » Postponed (maintainer needs more info)

Do you have any kind of caching enabled? Is anything recorded in the Drupal or webserver logs when this happens? Do you have any contrib modules enabled that extend attributes in any way?

The fact this only started happening since you moved to a new server points to a configuration issue, somewhere.

mrandy’s picture

mrandy CreditAttribution: mrandy commented

Hi longwave

Thanks for the quick response. I have both cleared the cache and disabled all caching at various points in the last few weeks while trying to pin this down and it seems to make no difference.

No contrib modules are installed that extend attributes, although I do have a few mods installed that extend Ubercart such as payment modules and discount coupons. These were all there prior to the server move though.

I have already checked the logs and can't see anything that relates to this.

Everything definitely worked fine until the move, so it's clearly tied to that in some way, I just can't see what though.

Thanks for any more suggestions you can give.

Andy

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

No further ideas, sorry; I haven't seen this before and I already listed all my guesses at the source of the problem in #1.

mrandy’s picture

mrandy CreditAttribution: mrandy commented

ok no worries I appreciate the ideas. If I come up with a solution I will post here so others can find it.

Andy

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

If you find out what caused this I'd still be interested to know.

mrandy’s picture

mrandy CreditAttribution: mrandy commented

still not resolved this, but am going to have another go this next few days and see if I can crack it.

Andy

azoho’s picture

azoho CreditAttribution: azoho commented

Hi,

I had this issue after copying the site to new location and database for testing, and found that I had imported the database with wrong character set.

After importing with correct character set, the attributes were saving correctly.

mrandy’s picture

mrandy CreditAttribution: mrandy commented

Hi azoho

I checked this but the database all appears to have the correct collation etc. and I am pretty sure was imported with the right settings (utf8)

If I figure it out I'll post here, but I might end up just building a new D7 version of the site, as I have been toying with doing that anyway.

Thanks a lot for the idea though.

Andy

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Did you ever find out what was causing this? I've just had the exact same issue crop up in Ubercart 7.3.2.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

In my instance, the problem was that max_input_vars was set to 1000, which was causing the form to fail when trying to post. Increasing to 5000 fixed the problem.

mrandy’s picture

mrandy CreditAttribution: mrandy commented

Never did fix it, however we moved to a new host a few weeks back and everything started working fine again. Today we then updated PHP to 5.3.19 (it was on 5.2.x previously) and this problem immediately started again. There is no doubt the PHP version update triggered it this time, as the minute the update was done it stopped working immediately.

I'll have a look at the max_input_vars setting, maybe that changed when PHP was updated, so thanks for the suggestion there.

Andy

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented

I hadn't thought of that; max_input_vars could definitely trigger this if you have a lot of attributes or options on your product, due to the sheer number of form fields on the page.

mrandy’s picture

mrandy CreditAttribution: mrandy commented

I can confirm that seemed to be the issue for me too. We had the hosting provider increase the max_input_vars this afternoon and it seems to have fixed it (although we also had to increase the memory limit too in order to prevent a memory error).

Cheers for all the help on this everybody.

Andy

longwave’s picture

longwave
he/him
Primary language English
Location UK
CreditAttribution: longwave commented
Status: Closed (cannot reproduce) » Fixed

Let's mark this fixed so this might help others in the future, now it has been reproduced on at least two installations.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jasonabc’s picture

jasonabc CreditAttribution: jasonabc commented

A recent upgrade of PHP was causing this. I can confirm raising the max_input_vars limit in php.ini solved the problem for us.