janrenn

@rafaucau @jeffpaul

Yes, but the default Gravatar is displayed instead of the Gravatar set by the user.

Sure, in SLA 2.7.8, the default Gravatar “mystery person” is displayed despite the “Local Avatars Only” option is disabled. It is caused by this pull https://github.com/10up/simple-local-avatars/pull/260/commits/5a0b2e6d4a2932618d870410672aed9628cc29f0

I don’t think the pull is an apropriate solution for broken avatars mentioned in pull discussion. It just removes ! empty( $this->options['only'] ) check so it forces to use local avatar everytime, bypassing the WP default Gravatar usage.

Notice that the option 'only' check is not used in the whole plugin code anymore, therefore this option does effectively nothing now.

Thanks a lot!

Thanks a lot, David. JR

That’s perfect! Thanks a lot, @joppuyo
JR

@mwilton13 to the functions.php in your theme.

• This reply was modified 3 years, 6 months ago by janrenn.

//brings back title separators removed in 17.1
add_filter( 'wpseo_separator_options', function ( $separators ) {
  $separators['sc-pipe'] = '|';
  $separators['sc-tilde'] = '~';
  return $separators;
}, 10, 1 );

It looks like cURL error in configs.php file. There is only one place where ‘error:’ string exists: wp_die( 'error:' . curl_error( $ch ) ); It means that your server does not respond on HTTP request on https://example.com/wp-content/plugins/images-to-webp/tests/test.png. There may be many different reasons why. Replace ‘example.com’ with your host and try to open the URL in browser.

BTW implementation of cURL in the plugin should respect WP filter https_ssl_verify, something like

$ssl_verify = apply_filters( 'https_ssl_verify', TRUE, $test_image );
curl_setopt( $ch, CURLOPT_SSL_VERIFYPEER, $ssl_verify );

I had to add it manually to be able to install the plugin on my local installation.

Hello guys, maybe a little tricky bit is the fact that

update_option( 'relevanssi_light_activated', 'done' );

is set BEFORE relevanssi_light_database_alteration tries to alter database. If the ajax request fails (for any reason, e.g. SSL checks on local installation) the plugin will not ever try to create necessary columns but proclaims installation as ‘done’.

Thank you! JR

But i have to say that after index reset with https://www.ads-software.com/plugins/yoast-test-helper/ everythings goes smoothly in production mode. Described inconsistencies appears in development mode until i force indexables to work always in production mode:

add_filter( 'wpseo_should_save_indexable', '__return_true' );
add_filter( 'wpseo_indexing_data', function ( $data ) {
  $data['disabled'] = false;
  return $data;
} );

• This reply was modified 3 years, 11 months ago by janrenn.
• This reply was modified 3 years, 11 months ago by janrenn.
• This reply was modified 3 years, 11 months ago by janrenn.

Yoast indexables still cannot handle some types of content. For instance, the Column ‘ancestor_id’ cannot be null message appears regularly when saving a menu with nested items. And morevoer, the nav_menu_item objects are then stored in wp_yoast_indexable table with complete nonsense as permalink. When Yoast later tries to insert a nested nav_menu_item into wp_yoast_indexable_hierarchy it is not able to compute ancestor_id and the error message appears.

Is it really necessary to store nav_menu_item types in indexables? Maybe more filters in Post_Helper->is_post_indexable() or a method checking the post type would help.

Apparently, there are common situations when Indexable_Hierarchy_Builder->save_ancestors() is not able to obtain $ancestor->id and yet it tries to write to wp_yoast_indexable_hierarchy with inevitable DB error. I am not sure it is a good solution.

@collizo4sky fixed. Thanks a lot. JR

@stodorovic +1 for this solution

Thank you, Johannes! JR

I am using this fix: https://github.com/janrenn/file-renaming-on-upload-fix (not sure if it targets exactly your issue, try it). JR

• This reply was modified 6 years, 4 months ago by janrenn.