wp_hela

I don’t know if it is the same reason on Google.

In my case images in a gallery are linked as /wp-content/uploads/2016/04/image.jpg

This cause an error when uploading the sitemap to google.

Images not in a gallery are linked as https://mysite.com//wp-content/uploads/2016/04/image.jpg and not causing an error.

Have you checked wether the images causing your errors are in a gallery?

@francesco

hmmm … in my case I have 5 different sitemaps … not a single sitemap_index.xml.

Where do you get this single one from?

Yoast SEO 3.2.3

br
Heinz

Hi Takis,

today still the same issue here.

Could you please add an @ to line 88 so it won’t send the above mentioned notice:

$cookie_resolution = @$_COOKIE[‘resolution’];

br
Heinz

Hi all,

I just stumbled upon this.

I’m loding the child stylesheets this way, because I wanted to easily see if the page is loading my or the original stylesheet.

add_action( 'wp_enqueue_scripts', 'enqueue_parent_theme_style' );
function enqueue_parent_theme_style() {
    wp_enqueue_style( 'prima-parent-style', get_template_directory_uri().'/style.css' );
    wp_enqueue_style( 'prima-child-style', get_stylesheet_directory_uri().'/prima-style.css' );
    wp_enqueue_style( 'prima-common-child-style', get_stylesheet_directory_uri().'/prima-common-style.css' );
}

Now I found out that the 2014 theme still tries to load a style.css after all other stylesheets, which does not exist in my child theme:

<link rel='stylesheet' id='twentyfourteen-style-css'  href='https://xxx.at/wp-content/themes/prima-theme/style.css?ver=834b9028f95a4306565536d58443f6df' type='text/css' media='all' />

So the original would overwrite all others …

2014 theme does this in funtions.php:

function twentyfourteen_scripts() { ...
	// Load our main stylesheet.
	wp_enqueue_style( 'twentyfourteen-style', get_stylesheet_uri() );
...}

Other stylesheets are imported using get_template_directory_uri() … which points to the parent whereas get_stylesheet_uri() points to the child.

I hope that helps.

br
Heinz

Hi Yorman,

I have the same issue here.

Would you please consider to automatically switch on “API Service Communication” in the next version, so all the people switching it off now don’t forget the have switched it off due to the errors.

Thanks
Heinz

Yes, you could downgrade to PHP 5.4 … or move your ass (oo9ops, sorry for the bad word).

The mysql_query() used in the plugin was depreciated in PHP 5.5.0.

Also it might be a better idea to use the WordPress built-in wpdb-class to connect to the database.

However, I repaired the plugin by changing the functions causing the warnings and failure of the plugin ??

Hi Tamer,

I doubt it has anything to do with your change from a Windows to a Unix host.

The mysql_query() used in the plugin was depreciated in PHP 5.5.0.

Also it might be a better idea to use the WordPress built-in wpdb-class to connect to the database.

However, I repaired the plugin by changing the functions causing the warnings and failure of the plugin ??

Yorman,

sounds great, thank you so much.

br
Heinz

The same btw applies to liesmich.html, the German readme.html

btw

I’ve already removed the original api key.

Recovering it failod as I never got an email with the key.

So I generated a new one

Get_logs: Key not set.

Same problem here.

Newest Wordpres & newest plugin versions

It obviousely brings the error messages only on a certain hoster (Hosteurope.de)

Sucuri: (1452195870) Get_logs: Key not set.. if Display audit report disabled

Sucuri: (1452200217) Get_logs: Key not set..
Sucuri: (1452200219) Get_logs: Key not set.. if Display audit report enabled

Sucuri: (1452200367) Get_logs: Key not set.. if Display audit report disabled again

Sucuri: (1452200422) Get_logs: Key not set..
Sucuri: (1452200425) Get_logs: Key not set.. if Display audit report enabled again

So obviousely the bracketed numbers come from a sequential numbering …

Linux wp349 3.15.8-xenu-static-x86_64-he+1 #6 SMP Wed Aug 20 13:24:06 UTC 2014 x86_64

PHP Version 5.3.29

“This can be used to check if the issue is with the plugin itself or the HTTP transport protocol configured in the server.”

I can’t get it how to “check” or use this check?!?

br
Heinz

even if I clear the last logins file the page still keeps blank.

Memory limit does not seem to be the Problem with v1.7.13 and WP 3.4.1

define(‘WP_MAX_MEMORY_LIMIT’, ‘256M’);
define(‘WP_MEMORY_LIMIT’, ‘256M’);

Reset core integrity logs 94.00B of data
Reset last login logs 15.38K of data
Reset failed login logs 4.04K of data
Reset sitecheck logs 4.81K of data

qTranslate slug activated, definitely changes the name of the menues!!!!!

lol … forget the last one … it only appears if I deactivate mqtranslate as a work-around