Admin settings won't save

[dcmouser]

I've been having this problem for a year or so, spent some time looking for solutions and eventually found a workaround by not using https mode to connect; but that's not practical anymore so I need to find a fix.

Essentially what happens is that when I attempt to change settings on an admin page, the submitted changes are ignored.  The page submits without any complaint, and the new page reloads, but the settings aren't changed and are simply re-presented as they were originally.

• If I keep trying to make a change and save it, submitting it over and over, eventually it will accept the change, so that's a clue.
• As I said earlier, I used to be able to circumvent this by switching from https to http and reloading the admin page in question, so that's another clue.

There is an older similar thread on the smf forum here: https://www.simplemachines.org/community/index.php?topic=559747.0

But with no real solution.

It seems like maybe it's an issue with caching the settings, but I'm not sure.  I tried to look around in the code but couldn't figure anything out.

It happens on chrome and firefox.

(If it helps, the other interesting thing that happens is that the admin page urls are showing with some kind of session id in them -- i'm not sure if thats by design or what (for example an admin page url will be like a07123456=6f9a3429783847298e0e6cd9c8f7facf28)).

[m4z]

I've been having this problem for a year or so, spent some time looking for solutions and eventually found a workaround by not using https mode to connect; but that's not practical anymore so I need to find a fix.

Essentially what happens is that when I attempt to change settings on an admin page, the submitted changes are ignored.  The page submits without any complaint, and the new page reloads, but the settings aren't changed and are simply re-presented as they were originally.

• If I keep trying to make a change and save it, submitting it over and over, eventually it will accept the change, so that's a clue.
• As I said earlier, I used to be able to circumvent this by switching from https to http and reloading the admin page in question, so that's another clue.

Have you migrated your forum to another location before these issues began? In any case, I'd recommend you run repair_settings and check if it proposes any changes.

There is an older similar thread on the smf forum here: https://www.simplemachines.org/community/index.php?topic=559747.0

But with no real solution.

It seems like maybe it's an issue with caching the settings, but I'm not sure.  I tried to look around in the code but couldn't figure anything out.

It happens on chrome and firefox.

What version of SMF are you using? What type and version of database? What PHP version? Do you use any mods?

(If it helps, the other interesting thing that happens is that the admin page urls are showing with some kind of session id in them -- i'm not sure if thats by design or what (for example an admin page url will be like a07123456=6f9a3429783847298e0e6cd9c8f7facf28)).

That is expected behaviour.

[dcmouser]

v2.0.17 running on a dedicated server under cpanel.
We've been running SMF since 2005  -- upgraded to each new version along the way

Database is MySql.

I've run the repair tool -- it didn't do anything.

Yes we have quite a few mods -- and many of our own creation.

[Arantor]

Which settings?

[dcmouser]

All settings that I've tested on all admin pages that I've tested.

Maybe 5 out of 6 times, if i change the settings on any of the admin pages and click save, the page just submits and then shows the old settings (no error, no nothing).
The other 1 out of 6 times, the changes submitted stick.

The specific settings or values don't seem to make any difference.

And note that these problems have never been present on any of the normal pages (profiles, post forms, etc.) -- it's only ever the Admin area pages where this happens.

[Illori]

what type of caching is running on the server?

[Doug Heffernan]

The issue lies when using SSL. Is it set up properly in your forum?

P.s. Have you considered opening a support ticket about this so one of the Smf staff members can take a look into this?

[dcmouser]

what type of caching is running on the server?

"Level 1 caching (recommended)"

The issue lies when using SSL. Is it set up properly in your forum?

Seems to be working fine in all other areas of the website and forum.

P.s. Have you considered opening a support ticket about this so one of the Smf staff members can take a look into this?

If we can't solve it here I will do so.

[Illori]

even if you have level 1 caching enabled that does not mean your host may not be running other server side caching. ask your host.

also you have not told us if it is file caching or other type of caching that is level 1.

[dcmouser]

We're running cpanel on a dedicated server, and don't forget all other forms on other non-admin pages are working fine.  Joomla is also running on the server, no issues there.

The "Level 1 caching" is just what the setting says in SMF.  If there's some other caching setting in Cpanel that I should check, let me know.

[Doug Heffernan]

Can you run the repair_setting.php tool to double check that $boarddir and especially $cachedir are pointing to the right paths. It is worth a try imo.

P.s. Is there anything in the error log btw?

[dcmouser]

It feels to me from looking at the code, that the problem is in the updateSettings() function in the Subs.php source file..
That maybe the internal smf cache for settings is not working quite right -- like the cache_put_data() function called in there is not working as expected..  Or maybe its not saving the settings to the database table?  But I don't know.

Can you run the repair_setting.php tool to double check that $boarddir and especially $cachedir are pointing to the right paths. It is worth a try imo.
P.s. Is there anything in the error log btw?

Nothing (relevant) in error log.

I will recheck the $cachedir setting..

Looks fine, and plenty of files in that directory.

[dcmouser]

Ok here's a big clue:
If I look inside the database, it looks like it IS changing the settings each time I click save.

So the problem is definitely with the cache of the modSettings.. It seems it is not being refreshed after the save, so its showing me (and using presumably) the old values until the cache expires.

I think that's why it was looking like it was working 1 time out of 6.. It was probably just the modSettings cache expiring and then showing the setting values in the database.

So now the question is why isnt the modSettings cache working properly? i.e. why is it not updating when updateSettings runs cache_put_data()

[dcmouser]

Given that I see data files in the cache/ directory, I am surmising that smf is using its own file cache and not any php cache system.. (I'm inferring that from looking at the cache_put_data function in Load.php).
That makes me think that its failing to write the modSettings cache file when I click save.

[dcmouser]

I think I see what's going wrong -- at least proximally.

When updateSettings happens, it writes the settings to the database, and then it tries to INVALIDATE the cache, by calling cache_put_data with NULL as the data.

In the cache_put_data function, when using the built-in smf file cache, if its passed a NULL value, it tries to DELETE (unlink) the cache file in question.

I believe it's this file unlink/delete that is failing (silently).

Hence the cache never gets invalidated, hence it does not get updated.

What I don't know yet is *why* the unlink is failing.. it might be a file permission problem or file in use problem, etc...

It is clearly able to overwrite the cache file when it wants to (when the ttl expires), so writing the file is not a problem.  One workaround would be to force smf to update the settings cache rather than delete it, as it does when ttl expires.  But I will see if I can't figure out why the file unlink/delete is failing and how to fix that.

[dcmouser]

The plot thickens.. I now believe the problem is a bit wierder.

I think what's happening now is that the built-in smf file cache creates an MD5 for the cache5, thusly:
   $key = md5($boardurl . filemtime($sourcedir . '/Load.php')) . '-SMF-' . strtr($key, ':', '-');

As strange as it seems, I now believe the problem may be that $boardurl is not always the same.  I believe that when it's trying to invalidate the cache file, its using one value of $boardurl and when it does its normal read of the cache file of settings, it's using another.
There is code in Load.php to do some tweaking of the $boardurl  (see near lines 1573 in Load.php).

Since the modSettings cache is written in reloadSettings() which is called from the root index.php file, I *WONDER* if whats happening is its being called here BEFORE the url fixup code for $boardurl, and thus its writing out and reading from a DIFFERENT cache filename than is triggered in the saveSettings cache invalidate call.

And i wonder if the thing thats different is $boardurl = "http://whatever" vs " $boardurl = "https://whatever"

I think that would explain why the workaround of not using https was working... This is seeming likely.

[dcmouser]

YEP.

Ok so that's the problem and I've got a solution.

I'm going to fix my code by changing the two occasions in Load.php of

Code Select Expand

$key = md5($boardurl . filemtime($sourcedir . '/Load.php')) . '-SMF-' . strtr($key, ':', '-');

to something like

Code Select Expand

$key = md5($boardurl_original . filemtime($sourcedir . '/Load.php')) . '-SMF-' . strtr($key, ':', '-');

where $boardurl_original is a global in Settings.php

I understand the IDEA of this md5 to avoid clashes, if you were running multiple forums off the same directory or something.  (AS AN ASIDE: And the idea of hashing in the filetime of Load.php I guess is to refresh when Load.php is changed (though this feels weird to me); I think I remember something else odd about Load.php file date being touched programatically for some reason (maybe to invalidate cache)).

AGAIN TO REPEAT WHATS GOING WRONG:

I would suggest that this md5 calculation should probably be considered a bug, though one unlikely to affect many people.

It only happens when the Load.php $do_fix for $boardurl is triggered, which I think happens when someone hits the site at "https://..." and the boardurl in settings in "http://..."  That triggers the Load.php modification of the global $board_url, but that modification comes AFTER the early call from index.php to reloadSettings..   Because of that, the modSettings are normally loaded and saved to a DIFFERENT cache filename that the rest of the cache files, and different from the one that smf tries to invalidate when you save the admin settings.

I hope I'm explaining that well enough for smf authors to address...

There may be a more elegant solution, but I'd suggest some change of that md5 calculation for the cache files are in order.. maybe just remove the $boardurl entirely.. Maybe us a value from settings that is not messed with.

[vbgamer45]

Very interesting thanks for the in depth report. I think maybe we should switch to using boarddir or there could be a very good reason why we are usigng boardurl instead of another constant.

[dcmouser]

Hi vbgamer45.

It seems that the real purpose here is to give the cache files a prefix that would be unique even if you had multiple forums running on the same server and using the same cache directory for some reason.  If one wanted to keep that safety, then you could simply using another global value that is set early and not modified.  Alternatively you could have Load save the original $boardurl into another global variable and have the md5 calculation check for that and use it if its not empty.

[dcmouser]

ps. Thank you again to everyone who works on SMF.  It's hard to believe our site has been using it for 15 years now.. We're grateful for all the hard work you folks put into it year after year.