Notice: Undefined index: aiosp_can_set_protocol

What page(s) do you see the message on?

Seen on Home page
* whether or not I am logged in
* Using static front page
* Is a wordpress network (multi-site)
* Only appears on main (first) site as far as I can tell

Thank you for letting me know. I’ve implemented all those conditions on a multisite install and still can’t replicate it.

We have the same issue, but i cant give access now.

I’ll see if i can give access on Monday.

The only pattern i see is that the same notice was on another plugin.
screenshot here: https://prntscr.com/bjydfu

After updating that, the error appeared on your plugin.

Thanks.

I was able to make the warning go away by going into the settings for all in one and just pressing update to manually set the values. This means some people who haven’t pressed the update button in settings won’t have this value set.

I don’t see exactly where but I believe the plugin is not properly loading the default values. The best way I’ve found to do this is via the following method using wordpress’ built in get_option( $option, $default ) functionality.

$this->defaults = array(
	'slug' => 'location',
	'name' => 'Locations',
	'name_singular' => 'Location',
	'api_key' => '',
	'placeholder' => 'Enter Your Location'
);

$this->options = get_option( 'plugin_options', $this->defaults );

https://codex.www.ads-software.com/Function_Reference/get_option

Hi Joel,

Thank you for the information.
I’d also discovered this by logging into someone’s affected site earlier today. We’ll figure out what’s causing this and have a fix in the next version.

As far as that particular option goes, just turn of wp_debug and the notice will go away. Functionality it doesn’t have an effect (outside of a notice) because not being set is the same as being set to auto as far as the code goes. We’ll get this taken care of soon though and make sure there are no other issues being caused by this.

Michael

Joel,

Just out of curiosity, about how long ago did you first install AIOSEOP? 1 week, 6 months, 5 years?

It would have been years ago, possibly 5 years. I wasn’t the one to first install it on this site.

Ok great, thank you for that. There’s was an issue where in some cases, new option defaults didn’t get applied to very old installations (unless you click update options).
We’ll fix it, although it’s pretty rare, since generally people don’t go so long without changing an option or two. ??
Also, I take this to mean you haven’t enabled the various other modules like Social, XML Sitemap, etc?

That’s correct on the modules, we only have performance enabled on this site.

Thanks for looking into this! As I said earlier, I highly recommend using get_option( $option, $default ), it really simplifies the assignment of the variables and allows you to guarantee that all options will be set to the defaults even if they do not exist in the database.

Unless I’m mistaken, I think that would only apply to the existence option itself (the one entry in the database), which is an array of all the actual settings. I don’t think it would apply any defaults for missing array keys. We’ll definitely need to take care of that in a future update soon though.

If you use the array that get_option returns when using the second $default parameter it will contain all variables that you enter in $default so you would no longer receive the missing key errors. That way you would not have to have the “isset()” or “!empty()” calls in all your if statements.

Ah, I see what you’re saying. We’re using get_option(), but not the $default parameter.
Our options storing, getting, filtering, etc process is pretty complex, so it will take some time to figure out the best way to handle this and test to make sure we don’t break anything else.
Feel free to dig in if you like. ?? https://github.com/semperfiwebdesign/all-in-one-seo-pack