I assume you mean a screen shot of that Options>Content panel, and if so not a problem. I would be very curious to see what happens when I paste that row’s value that you guys have in your database.
This is ours but you will hjave to edit it. Interesting to see what happens though
a:9:{s:10:"sfnofollow";b:1;s:8:"sftarget";b:1;s:11:"sffilterpre";b:0;s:12:"sfdupemember";b:1;s:11:"sfdupeguest";b:1;s:10:"sfurlchars";s:2:"40";s:12:"sfallowlinks";b:1;s:10:"sfmaxlinks";s:2:"10";s:12:"sfnolinksmsg";s:56:"<b>** you don't have permission to see this link **</b>";}
Modified that data to my personal settings, copied it into the database and saved. Now when I go into Options > Content Settings everything looks correct and my options are all appropriately ticked. I tried clicking update content options just to test, and it wiped the sffilters empty again. Something definitely going on between the PHP and SQL.
I’ll enable trace mode in my php.ini and see what’s logged.
For now, I’ll just manually update the database with the appropriate data until we figure this out.
Nothing out of the ordinary in debug log file when viewing outputted SQL errors/warnings server-side. But, when attempting to save options in the Options-Content Settings, my database is definitely receiving a SQL drop command for the sffilters row (option_value) within the sfoptions table.
Nothing was changed whatsoever in WP between the SP 4.5x to 5.0 upgrade. This seems like a 5.0 issue to me. Any insight from you guys as to why this may be happening?
msyql drop?? do you mean drop the table or just saving an empty string?
time to start inserting some debug code…
find simple-press/admin/panel-options/support/spa-options-save.php… and then routine spa_save_content_data()… this is where its saved…
try inserting some echo commands for the different values of this section
# link filters
$sffilters = array();
$sffilters['sfnofollow'] = isset($_POST['sfnofollow']);
$sffilters['sftarget'] = isset($_POST['sftarget']);
$sffilters['sffilterpre'] = isset($_POST['sffilterpre']);
$sffilters['sfdupemember'] = isset($_POST['sfdupemember']);
$sffilters['sfdupeguest'] = isset($_POST['sfdupeguest']);
$sffilters['sfurlchars'] = sp_esc_int($_POST['sfurlchars']);
$sffilters['sfallowlinks'] = isset($_POST['sfallowlinks']);
$sffilters['sfmaxlinks'] = sp_esc_int($_POST['sfmaxlinks']);
if (empty($sffilters['sfmaxlinks'])) $sffilters['sfmaxlinks'] = 0;
$sffilters['sfnolinksmsg'] = sp_filter_text_save(trim($_POST['sfnolinksmsg']));
sp_update_option('sffilters', $sffilters);
and lets see what is going on…
It’s dropping the sffilters row (record) using an alter table statement. I’ll re-run it and copy the exact mySQL command that was logged.
I’ll try the echo commands. Do you normally turn implicit_flush on before debugging?
no. we have a sp-debug.php file that has some of our commands…
vshow
ashow
latter being for arrays… formats an echo and print_r…
the exact mysql would be useful.. we dont do alter commands unless its an upgrade…
I have the same problem. Only Admins can post links. The problem also appears on a test site I have in localhost. You can not save any changes to “Allow links in posts” made in the plugin Syntax Highlighting.
Very strange ..
Anybody else had the same problem and found a solution to it?
Curious. Why do you mention the syntax highlighting plugin? I really would very much like to know…
Sorry for the delay, I am restoring a boat for my father and I’ve been putting in some hours! 🙂
The first line is the SQL query I was getting before upgrading to 5.0.1. I’ve since successfully upgraded to 5.0.1 then I logged the exact PHP that my database was being passed and that is the second line. Clearly on that line you can see it is just saving an empty string, which to me seems more likely the case here…..just why is the question. The following lines are what I logged after attempting to save the Options>Content Settings again.
ALTER TABLE `wp_sfoptions` DROP `option_value` $sql = "UPDATE `gonzale1_wrd5`.`wp_sfoptions` SET `option_value` = '' WHERE `wp_sfoptions`.`option_name` = 'sffilters';";
[07-Mar-2012 05:45:27] WordPress database error Table '*************.wp_sfoptions' doesn't exist for query SELECT * FROM wp_sfoptions WHERE user_id=1 ORDER BY notice_id made by require_once, require_once, require_once, require_once, do_action, call_user_func_array, sp_load_current_user, spUser->__construct, spdb_table, spdb_select [07-Mar-2012 05:45:44] WordPress database error Table '*************.wp_sfoptions' doesn't exist for query SELECT * FROM wp_sfoptions WHERE user_id=1 ORDER BY notice_id made by require_once, require_once, require_once, require_once, do_action, call_user_func_array, sp_load_current_user, spUser->__construct, spdb_table, spdb_select [07-Mar-2012 05:46:20] WordPress database error Table '*************.wp_sfoptions' doesn't exist for query SELECT * FROM wp_sfoptions WHERE user_id=1 ORDER BY notice_id made by require_once, require_once, require_once, do_action, call_user_func_array, sp_load_current_user, spUser->__construct, spdb_table, spdb_select [07-Mar-2012 05:46:23] WordPress database error Table '*************.wp_sfoptions' doesn't exist for query SELECT * FROM wp_sfoptions WHERE user_id=1 ORDER BY notice_id made by require_once, require_once, require_once, do_action, call_user_func_array, sp_load_current_user, spUser->__construct, spdb_table, spdb_select [07-Mar-2012 05:46:32] WordPress database error Table '*************.wp_sfoptions' doesn't exist for query SELECT * FROM wp_sfoptions WHERE user_id=1 ORDER BY notice_id made by require_once, require_once, require_once, do_action, call_user_func_array, sp_load_current_user, spUser->__construct, spdb_table, spdb_select [07-Mar-2012 05:46:35] WordPress database error Table '*************.wp_sfoptions' doesn't exist for query SELECT * FROM wp_sfoptions WHERE user_id=1 ORDER BY notice_id made by require_once, require_once, require_once, do_action, call_user_func_array, sp_load_current_user, spUser->__construct, spdb_table, spdb_select
wow. nasty. This is a WP function that might be screwing us.
Tell me – are you using the SP Syntax Highlighter plugin and – if so – do you have the option on to use it on blog pages? If so could you briefly deactivate it just to see if this allows the save to be made on the admin panel.
I did have the syntax highlighter plugin installed and active. However, I didn’t have the option to use it on blogs or SP posts ticked within the Options>Content Settings panel.
I went ahead and deactivated the SP syntax highlighter plugin, then attempted to save the Options>Content Settings options panel and voila, it saved just fine.
Excellent. We have found the bug.Actually it was Gekko (post 24) who got me thinking although I don’t know why he mentioned the highlighter plugin. But now I have looked I can spot it.
So – sorry about this one. I will ensure it is fixed up for the next update.