wildmice

Here’s the reason that v6.3.4 is not working for me. Filtering the content from within the wp_head hook does not work. Here is that code from ssba_buttons.php

function ssba_add_button_filter() {
$arrSettings = get_ssba_settings();
add_filter( ‘the_content’, ‘show_share_buttons’, (int) $arrSettings[‘ssba_content_priority’] );
}
add_action( ‘wp_head’, ‘ssba_add_button_filter’, 99 );

I found that it works if i add the content filter without using the wp_head hook, as follows :

add_filter( ‘the_content’, ‘show_share_buttons’, (int) get_ssba_settings()[‘ssba_content_priority’] );

Um… On sites where this plugin was installed earlier and was upgraded to 6.3.4, it is working, but a fresh install of 6.3.4 where the plugin was never installed, seems to not be working. No errors. It just doesn’t work.

I’m unable to test anything without a working verison, but will look through your code anyway, as mentioned above.

FYI … when i go to the settings page i see a PHP error :

Notice: Undefined index: ssba_custom_facebook_save in F:\theme-dev\nelson-base.dev\www\wp-content\plugins\simple-share-buttons-adder\inc\ssba_admin_panel.php on line 362

This is version 6.3.4

You may need to show all PHP errors in your development environment to see this.

I will take a look at your code and see if i can make some specific suggestions.

It might make more sense, rather than deregistering scripts, to just not register them in the first place, except where you are going to deploy this plugin on the page. You should already know from the settings whether the page you are on requires the scripts. Just check the settings before registering scripts and don’t do it if you don’t need them for the current page.

In version 6.2.1 there is a Javascript error :

ReferenceError: stLight is not defined
ssba.min.js:1:1273

This error also seems to be in version 6.2.2

Yeh, not nice. There also should be a way to dismiss that notice without accepting it.

Our hosting provider is running MariaDB 5.5.44 with no specific SQL mode set, and it is defaulting to NO_BACKSLASH_ESCAPES.

I’m sorry, i was unaware at the outset that there is not a very solid consensus on which mode is the best. Understanding this, i think the best action is no action, and i’ll live with editing SQL that has to be ported from one system to another where they are using different SQL modes.

I do have a question though. When i do a backup on hosting that is using NO_BACKSLASH_ESCAPES, does UpdraftPlus respect that setting and escape by doubling single quotes? In other words, on such a system, will i be able to restore without any problems?

Hi David,

Well it does look (from your link) like escaping with backslash is the MySQL default, and i was surprised that it didn’t work.

I have made an inquiry with our hosting provider and will come back with their response.

Perhaps there should be an option in your plugin to deal with this?

The context here is that i backed up with UpdraftPlus, and then restored (to other hosting) by importing the SQL in Phpmyadmin, rather than restoring with the plugin.

Hi David,

Here’s what the hosting provider for this site said :

“I updated from php 5.6.17 to php 5.6.19, on a debian server.

“It was weird too, as I’ve been using Updraft on a separate server without issues.”

Hope this helps.

I have a report now from the hosting provider that they resolved this by upgrading PHP. Thank you for looking into this.

I know that in at least one of those cases it was internet rush hour and not a great time to run it. Sounds like what happened is a reasonable response of the plugin to this situation. Let’s call it resolved, and i’ll try to avoid slow times of day.

Thanks for looking into this.

It should be noted that in each case the problem occurred for the very first backup. I just ran one of them again and it did not happen (perhaps related to the server being much faster at the moment).

Here are the log files for the other one, which i am not going to run again unless necessary because it takes too long.

https://wildmice.ca/_temp/log1.txt
https://wildmice.ca/_temp/log2.txt

I had already checked with my hosting provider before posting this, and here is what they said :

“There are no errors in the php logs, and there is nothing helpful in the updraft plus log either.

“I’ve installed my backup plugin of choice (BackupWordPress), and it works just fine. A database backup with WP Security also worked.”

When i was on the current status page i was getting the progress bar/status display, but after switching to PHP 7 and returning to the current status page again i was not getting it. I did not realize until later that that display won’t return unless you start a backup again.

Sorry for drawing the wrong conclusion. I’m very pleased to hear that it works under PHP 7, because it is so much faster.