Page 1 of 1
Plugin configuration not saving
Posted: Thu Apr 04, 2013 5:29 pm
by rodneyrehm
Hey there,
for some reason I am unable to change the configuration of some of my plugins. I wanted to change the value of Spamblock Bayes' "Custom Rejection" from 90 to 95 - and it goes back to 90 after saving. The property "Recyler Bypass" can be saved without a problem, though.
I've tried it with Firefox 20 and Chrome 25. It's S9Y 1.6.2 - running on PHP 5.4.13--pl0-gentoo (cli) (built: Mar 24 2013 07:11:42). The error log doesn't say anything useful, just some strict warnings…
I've made sure the directory (and subtree) is readable and writable.
Any ideas what this could be?
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 5:33 pm
by yellowled
Only tried it in Chrome, but I can not reproduce this on 1.6.2 or 1.7-rc4.
Probably something onli should have a look at.
YL
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 6:25 pm
by garvinhicking
Hey!
OK, if you can save one setting but not another, this can get a bit uglier to debug, I'm afraid.
Small background coming up:
The actual saving is performed in the file include/admin/plugins.inc.php at around line 90, and line 114:
Code: Select all
$value = $_POST['serendipity']['plugin'][$config_item];
$validate = $plugin->validate($config_item, $cbag, $value);
...
$plugin->set_config($config_item, $value);
Now, the plugin itself does not utlize validating config settings, so it should actually pass through the value to the $plugin->set_config() call. Please add some debugging echo just before that call, something like:
Code: Select all
echo "Saving plugin config, item: " . serialize($config_item) . ", Value: " . serialize($value) . "<br />\n";
Then check what you get when you save. It should tell you the value "90" for the item "blockBarrier", or whatever you try to change.
My best guess is that maybe your browser actually submits the old value or an invalid/no value for the field, and we would need to check how that could come.
After that, the file include/plugin_api.inc.php at around line 1480 takes over to actually perform set_config(), which only routes it through to serendipity_set_config_var() which is defined in include/functions_copnfig.inc.php at line 98:
Code: Select all
$r = serendipity_db_insert('config', array('name' => $name, 'value' => $val, 'authorid' => $authorid));
First it deletes the config value, and then re-inserts is with a DB insert statement inside the DB. This could maybe also be a problem; however, if the SQL storage handler (mysql/mysqli) would hit an error, it should return as a string, and echo that string as an error - so I doubt that something's wrong at this point.
In either cause, sorry for that happening, but I'm sure we can figure out what's going on.
Regards,
Garvin
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 6:48 pm
by rodneyrehm
interesting, the output I get right before the set_config() call is
Code: Select all
Saving plugin config, item: s:6:"ignore";, Value: s:0:"";
Saving plugin config, item: s:14:"recyclerdelete";, Value: s:2:"98";
Saving plugin config, item: s:4:"path";, Value: s:43:"/plugins/serendipity_event_spamblock_bayes/";
if I move the dumper to the beginning of the foreach it is:
Code: Select all
Saving plugin config, item: s:6:"method";, Value: N;
Saving plugin config, item: s:15:"moderateBarrier";, Value: N;
Saving plugin config, item: s:12:"blockBarrier";, Value: N;
Saving plugin config, item: s:9:"autolearn";, Value: N;
Saving plugin config, item: s:6:"ignore";, Value: N;
Saving plugin config, item: s:4:"menu";, Value: s:0:"";
Saving plugin config, item: s:8:"recycler";, Value: s:0:"";
Saving plugin config, item: s:14:"recyclerdelete";, Value: s:0:"";
Saving plugin config, item: s:8:"emptyAll";, Value: s:2:"98";
Saving plugin config, item: s:4:"path";, Value: s:2:"98";
Saving plugin config, item: s:7:"logtype";, Value: s:43:"/plugins/serendipity_event_spamblock_bayes/";
Saving plugin config, item: s:7:"logfile";, Value: s:43:"/plugins/serendipity_event_spamblock_bayes/";
I've narrowed it down to
Code: Select all
$plugin->introspect_config_item($config_item, $cbag)
returning false and thus not even performing the validation
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 7:08 pm
by garvinhicking
Hey Sherlock
OK, what's funny is that at leat in my version of the spamblock bayes, the introspect_config_item() method has one huge switch() statement, and at the end, it properly returns "true".
I wonder why this does not return true on your case though...does your serendipity_event_spamblock_bayes.php have this return true just after the switch() statement?
Maybe this could be sme issue with a Bytecode-/OPcode-Cache, or even some PHP weird issue? Maybe you can check on your system if the "return true" does not get executed within the spamblock_bayes plugin, or if maybe simply your plugin version differs (HINT: check if you have inside yur plugins/ directory any old versions of spamblock bayes liening around, maybe those get included by s9y instead of the real recent PHP file?) *
Regards,
Garvin
* s9y dives into every subdirectory of the plugins/ directory tree, and whenever it hits a properly named plugin file, it actually loads that.
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 7:12 pm
by Timbalu
Hi
PHP 5.4.13 (win build) bayes version: 0.4.9.5 on Serendipity 1.6.1 or 1.7-rc3. - no problems!
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 7:23 pm
by rodneyrehm
It has the switch(). The Plugin has version 0.4.9.5, I don't see any old version:
Code: Select all
$ find . -name 'serendipity_event_spamblock_bayes.php'
./plugins/serendipity_event_spamblock_bayes/serendipity_event_spamblock_bayes.php
I don't think it's a problem of this particular plugin, as I'm experiencing the same issues with the plugins Spamblock Bee, Spamblock, (possibly others - haven't checked them all as broken properties appear random)
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 7:33 pm
by Timbalu
I know it sounds completely weird, but try to erase s9y-cookies, log-off and log-in again. And then have another go.
I had some different problems with template vars not being catched without any direct issue there,
http://board.s9y.org/viewtopic.php?f=10 ... #p10434265 which got solved by erasing all cookies and the newly log-in. Its at least worth a try (as it is similar in weirdness)!
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 7:46 pm
by rodneyrehm
yeah… "turning it off and on again" didn't do the trick
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 7:49 pm
by Timbalu
hmm, did you try with erasing cookies first...?
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 8:17 pm
by garvinhicking
I don't really think that would be related to the cookies. If it saves one variable, it should save all of them - if the login or cookie were a problem, it should affect every variable.
To me this sounds more like memory/opcode corruption or whatever, something must cache/trigger a wrong return value.
Rodney, maybe you can store the return value of $plugin->introspect_config_item in a temporary $helper variable and serialize that one, just to see what the real return value is?
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 9:53 pm
by rodneyrehm
The
returns »1«, which won't pass
- so I removed the strict-true-equality comparison (basically reverting to boolean coercion) and my properties are saved again!
I have no idea what how why is going on… but this solved the problem…
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 10:05 pm
by rodneyrehm
That was only half the truth. once I removed my debugging output, it was back to not saving the properties. Also the spam bee didn't save changes at all. in the config table the properties are named like »/do_honeypot« is this ok or does that look like a bug (other plugins are named properly).
I have uninstalled the spambot bee, properties weren't removed from the table. Spamprotector is still not saving changes.
Re: Plugin configuration not saving
Posted: Thu Apr 04, 2013 10:18 pm
by rodneyrehm
I fixed the options I wanted to change in the database… I'll just leave it at that and upgrade to 1.7.x once it's ready (read: hurry
)