Settings not saving on new 1.6.8 20091202 install
I just installed EE 1.6.8 build 20091202 in a fresh local sandbox. I enabled CP jQuery and installed Low Variables 1.1.3. I can't save any settings. If I enter my license number and save, it goes back to the Extensions screen, and if I go back into the settings the license field is still blank. The same goes for any of the setting fields. I tried in Safari and FF; same result in either case.
I can hack LV to bypass the license check (which I did, but that is so not cool...) to at least test if the add-on works, and it does. Just seems that I can't save the settings. Any idea why that may be happening?
Replies
Low 28 Jan 2010 08:50
Hey Ryan,
Okay, I just did 2 fresh installs of EE 1.6.8 20100121 (the changelog mentions nothing about extension settings, so I'm guessing the build shouldn't matter). One on PHP 5.2, one on PHP 5.3...
Here's what I think is happening: EE cannot find the reference to the extension due to case sensitive collation in MySQL. Let me explain. I'm using EE's built in extension-save routine, so the form is built automatically and the settings are saved in that way, too. Nice and easy, I thought.
In the DB (the exp_extensions table), the reference to the extension class is entered like this: 'Low_variables_ext' ← first letter is uppercase.
In cp.utilities.php, line 465, the settings are saved using the reference
$DB->escape_str($IN->GBL('name')), which results in 'low_variables_ext' ← all lowercase. This is fetched from a hidden input field EE adds to the settings form, where the class name is put into, all lowercase.Now, normally this shouldn't matter, because most of the time, mysql's collation is case insensitive (like utf8_unicode_ci). However, if I change the collation to latin1_general_cs, which is case sensitive, the settings are not saved, reproducing your issue.
So... What's the collation on the database you're testing with? In the meantime, I'll try and change the extension, so it uses the custom form and save routines, keeping control to myself.
mdesign 28 Jan 2010 15:27
The DB on which I'm having the issues I had set to utf8_bin. I went through and changed the collation to utf8_general_ci, then uninstalled and re-installed Low Var, but I'm still not able to save the settings. I then changed every existing table collation to utf8_unicode_ci, uninstalled, reinstalled, and can't save the settings. Is there another step I might be missing?
I have a second install where I left the default EE tables alone, so the collation is latin1_swedish_ci, and the settings save fine there.
Low 28 Jan 2010 15:34
Try and set the collation of the 'class' field in 'exp_extensions' to 'utf8_unicode_ci'. So not on the DB as a whole, neither on the table itself, but on the attribute. You shouldn't even need to reinstall.
mdesign 28 Jan 2010 15:53
OK, that worked. Those individual fields were still set to utf8_bin.
Low 28 Jan 2010 16:00
Good. I think it might even be a bug in EE itself, if you're using a case sensitive collation and the auto-generated extension settings form. I'll check that with the EllisLab dev crew.
Anyway, I'm working on an update that will eradicate this bug anyway, by using a custom extension settings form. Coming later today or tomorrow!
mdesign 28 Jan 2010 16:03
Thanks, Low!