Settings variables, not functioning correctly on new mod installs
 

I'm seeing a very strange issue which I'm thinking of raising as bug.

Before I do, I just want to double check that I'm not doing something silly.

A few weeks ago I had 2 users report that I mod I made was doing something which was not default behaviour (as I had set it up). Everybody else did get the default behaviour. At least one user said that they checked the setting in question and it was set to "No" which was the default. However, the mod was behaving as if it were set to "Yes".

To be honest, I assumed these users were just thick. Since it worked for everyone else, I guessed they were wasting my time.

Last night I uninstalled a new mod I was working on (totally different to the one I just mentioned), and then reinstalled it to test it. Without going and saving the settings I got non-default behaviour. I immediately went to check settings, and I could see a similar issue to the one that was reported to me earlier - those users weren't lying, it was possible for a variable to be set in the admincp options and for it to end up a something different!

I'm not able to recreate this (have to invest more time in it), but I'm suspecting that if the user checks the settings after install and clicks save, then everything is ok. However, if they accept defaults and never look at the settings, then maybe some of these variables are not being initialised correctly?

I am making the assumption that I don't have to have my installation routine update anything, that vbulletin should handle this automatically.

Should I raise this as a bug report?

Just to illustrate this point further in case it wasn't clear. Imagine a hypothetical mod called dancing hamsters. It has an option like this:

"Show dancing hamsters on every forum page. Recommended setting: No - hamsters will annoy visitors". Variable name: $showhamsters. Type: yesno. Default no.

In your plugin you have something like this:

Now 100 people install your mod and nobody gets hamsters by default. But one person contacts you about the annoying hamsters on their forum page. The conversation goes like this:

User: I have hamsters, how do I turn them off?
Coder: They are off by default, did you turn them on?
User: No
Coder: I don't believe you
User: It's true - I don't even know where to turn them on or off, what should I do?
Coder: Check in the settings.
User: Ok, according to the settings, they are off. But I still see them.
Coder: I still don't believe you
User: If I turned them on and off, that fixed it. Now they are off.
Coder: Mutters under breath, still doesn't believe the user.

Until one evening, coder discovers the same thing with a different mod on a new installation of that mod...

I didn't have the same problem as you, but I had a similar one. vBulletin didn't rebuild my bitfields after a fresh install of my own hack. I had to manually rebuild them.

Did you report that as a bug (the bitfields thing?) Is there some kind of function I should be running to force the initialisation of these variables correctly during installation just to be sure?

The really curious thing is that the variables had a value of 1, when I would expect a new variable to be 0, especially if that was the default, or if something hadn't initialised correctly.

Update - I just managed to reproduce this. My mod has 3 variables - all yes/no. The defaults, in order, are no,yes,no. After uninstalling and reinstalling the same mod, the settings (which I've added to Who's online options) all read as no,no,no. However, when I look at what happens when I load Who's online page - they all appear to be yes,yes,yes. If I go back and click save in the options, then the mod behaves as expected.

I think it is definitely not normal behaviour, and since I can reproduce it (if nowhere, but on my own forum) I think I'll raise this as a bug.

Another update on this. Have reported it on vbulletin.com as a bug, along with a demonstration of reproducing it here:

http://www.vbulletin.com/forum/proje...?issueid=22467

No, I didn't report it as a bug. No there isn't a function either, but you could possibly call the options file and "save" it.
Same here, I was expecting it to spit out an error at me, because it was a "Can Access" thing.

I took a look at what happens in options.php, right at the end after it checks all the settings it runs build_options(). This function returns the result, and if I print the entire array that it spits out, the correct values are there. When I put this function above my test code, it seems to make no difference, the false values are still reported.

If you (or anyone else) has been able to duplicate this, I'd appreciate it if you could follow the link above to the bug report and click the option to state that you can reproduce the same result.

Initially I flagged this bug as low priority, but after doing further tests I'm convinced that this bug could potentially have harmful effects. What if an admin installed a product where the option reports that something is not public, but in reality, it is (and he never realises).