Settings page will not retain changed values

For whatever it’s worth, I did find another install in a site I use as a sandbox – v.4.11. Saving options worked in v.4.11 and also when I updated to current v.5.3. Uninstall didn’t work in either version.

Forgot to mention that I also tried rolling back PHP versions – back to 5.* – without successs.

HI,

See other post – I can replicate the uninstall and will sort that.

I can’t replicate the ‘unable to update’ – all fields are updating for me. Also not getting the list reset problem. I’m on php 7.2.7 , soon to retest on php 7.2.8 ??
I wouldn’t roll back to 5.

You’ve done good testing deactivating other plugins. I note you say development subdomain that seems to be functioning correctly. Racking my brain here as to why your various other installs aren’t :

It sounds like an update submit is doing a reset. Googling wordpress updates/edit not working maybe something interfering?

Are there any ‘must use’ plugins that might affect ? ie that weren’t de-activated.
Does the theme maybe have some functions? Try standard theme
Code maybe corrupt? Try clean install.

Are the options corrupted in the DB? Try deleting via phpmyadmin and see what happens then.

AS a fix attempt (or at least will tell something), in file amr-ical-list-admin.php in function amrical_option_page() comment out lines 714 to 715:

	if (isset ($_POST['reset']))
		$amr_options = amr_getset_options (true);
	else

Then it will only fetch existing options, and not check for reset request at all.

Please Let me know how you go. I will be looking at the code and maybe make some changes to try avoid what you are describing – difficult if I can’t recreate.

Thanks so much for your thoughtful and thorough reply. I did deactivate all other plugins, and in addition I deactivated .htaccess files in case they were getting in the way. No go. I have not tried standard theme, but thought about that. However, I have one website working and one not on same theme, so I crossed that off my list.

In testing, I verified that changes submitted through the interface are written in the database, but are not reflected in the interface on page refresh. Changes written directly in the database are retained but not reflected in the interface.

The most promising solution I have found is a post from 2 years ago citing a mysql database collation of latin1_swedish_ci on the options table being a problem with ical events list, and changing it to utf8 made it work properly. https://www.ads-software.com/support/topic/unable-to-save-settings-10/ I’ve also noticed you have an article on your own site about similar matters https://webdesign.anmari.com/news/page/3/. Given that information, I took a look at the 2 installations I have that are working and both are variations of utf8 collations (utf8mb4_unicode_ci and utf8_general_ci). I’ve given changing a database to utf8_general_ci a go with my limited sql knowledge, but haven’t successfully changed the database and kept it working yet. Not sure if data is being lost, or if I have to change the entire database, or what. I’ll give it more effort in the morning (it’s 2:30 am here and I can’t think straight anymore).

Thanks again for your reply. Please share any thoughts you have on the collation aspect, and I’ll give your code a try in the morning.

Best,
Matthew

Hi Hope you had a good sleep! It’s weird if it’s the collation setting.

If that doesn’t work, then another thought I had based on you saying that the DB was being updated, but then the page shows the old data. If the database is updated, then there is no way the plugin by itself would ‘know’ the old data – it doesn’t save it. That starts sounding more like some kind of cacheing problem. Either a webpage caching gone wrong on the server OR in your browser? You could try using a totally clean browser, one you don’t normally use.

Some links that might help if it’s cache related:
https://codex.www.ads-software.com/I_Make_Changes_and_Nothing_Happens
https://blog.templatetoaster.com/wordpress-page-updates-css-content-not-working-visible/

Thanks Anmari. I really appreciate your willingness to delve into this.

Re: caching, I did try another browser, and no change. Also, if there were some sort of server side caching going on, I would hope to see the same behaviour over the other sites, but some work consistently, and some don’t work consistently. They could always be on different servers, however unlikely that might be, but…

It’s not true that NO data is retained. As I mentioned before, the radio button for image size retains changes (16 or 32 px). In the database this is a separate row (as you know), amr-ical-images-to-use. So the page seems to be able to save and fetch data from the Options table in the DB, but I suspect just not from the row amr-ical-events-list.

As I mentioned before, changes made directly to the amr-ical-events-list row aren’t fetched. However, changes to the amr-ical-images-to-use written directly to the database ARE fetched. So it seems like the page is fetching the data, but is unable to fetch from the amr-ical-events-list row.

My guess of what seems to be happening is, once the page saves the data, the cached(?) page with the changes still reflected is updated with the “saved” dialog. But once the settings page is actually refreshed, the page tries to fetch the data from the DB and fails. When it fails, it reverts to stock, except for the image size radio button data that it is able to fetch.

re: list types settings page, this acts similarly. Changes made to the via the list types settings page save fine, and are fetched back on refresh of this page (unlike the ical settings page). However, once the ical settings page is refreshed, the list types page reverts to stock. All settings are still in the DB, but not reflected. re: changes written directly to the DB, it seems that if I change one field (such as one of the ‘before’ fields) in the list types page, and then change that field in the DB, on refresh the list types page will revert to stock. HOWEVER, it seems some fields act as they should. For instance, the Start Time Before field in List Type 1 saves and fetches normally, survives refresh of the list types page OR the ical settings page. But if other fields are populated (such as EventDate Before) that are not normally retained, everything is reverted to stock.

Unfortunately I know nothing about collation, or why that would be affecting that one table row, unless maybe there’s some character or something that isn’t translating in the current collation.

In my trouble shooting I did a diff compare from two different databases, one from a working site and one from non-working, and didn’t see any significant differences. So that may support the other posters notion that the plugin isn’t working properly with latin1_swedish_ci, at least when fetching/echoing certain options in this table row.

Does any of that help? My wheels have turned about as much as they can with my more limited knowledge.

Thanks!

Your code suggestion above does not seem to change the behaviour.

Also have tried uninstalling and reinstalling, deleting the DB rows and reinstalling, all without other plugins.

Tried reinstalling latest WP. Tried 2017 stock WP theme. No joy.

I don’t think it’s actually resetting so much as having trouble fetching and echoing the field data.

editing out bad comment

• This reply was modified 6 years, 4 months ago by mlavanish.

Well, I’m optimistically calling success. It turns out, at least on the first DB I have tried, that the collation was the problem. I tried again to update the collation methods to utf8mb4_unicode_ci and have had some success. Key step I neglected before was deleting and recreating the amr database entries. Step by steps to correct:

In WordPress Plugins:
1) deactivate ‘amr event lists with ical files’ plugin

In phpMyAdmin:
2) backup your database!
3) search in ‘wp_options’ table for amr. There should be 4 entries called widget_amr_icalendar_widget, amr-ical-events-list, widget_amr-ical-upe and amr-ical-images-to-use. Delete these 4 rows (bulk delete by selecting each in the checkbox to the left and click delete under the item list)
4) change the collation setting of ‘wp_options’ table to utf8mb4_unicode_ci (select table, select the Operations tab at the top, in the Table Options box, change the collation to the desired setting)
5) change the collation settings of the ‘option_name’, ‘option_value’ and ‘autoload’ columns in wp_options table to utf8mb4_unicode_ci (expand the table in the menu on the left by hitting the +, select ‘Columns’, check boxes next to the item names you want to change, select Change underneath the item list for bulk change, change the settings for each in the collation column and click save)

In WordPress plugins:
6) activate ‘amr event lists with ical files’ (creates 2 new entries in database)
7) set options in Ical Events List settings page and press Update (creates 2 more new entries in database)
8) check for functionality, but you should be good to go at this point

I hope that helps someone else with a similar problem.

Anmari, I’m sure you’ll be looking into the problem, because you’re super good at support. If you have any aha moments and figure something out, I’d love to hear about it. I’m also happy to help you suss it out however I can, because I really appreciate your plugin and am happy to contribute. I think you could recreate the problem locally by reversing the process above and changing the collation settings on the above items to latin1_swedish_ci in one of your installs.

Now I’m going to try to fix my main database without screwing it up. Cheers!

Thanks for all your updates and persistence. That’s a weird one isnt’t. I did read something about older wp DB’s before WP had more collation rigour in the DB setup. I think your site has been going awhile?

I am tempted to totally ‘prove it’ by recreating but possibly time better spent getting the update up (the uninstall problem fixed – annoying to test because it deletes the plugin each time! – of course!)

Totally weird, and you’re welcome. Happy to help. Yes, this site is almost 10 years old now, so that might contribute to the difficulties.

Haha, that would be a difficulty testing the delete function. True dedication.

*It should also be noted that with the above steps runs the risk of plugins not working correctly after the collation switch. Basic functionality seems largely unaffected, but options for some plugins have been corrupted in the translation, which necessitates a rework or reinstall.

UPDATE: If you’re going to make database collation and character set changes, read this article and follow these instructions. Converting everything to binary first is the key to data integrity. This article also links to a more in-depth article on the topic, but this is the nuts and bolts of the conversion.

https://codex.www.ads-software.com/User:JeremyClarke/exampleSQLForUTF8Conversion