Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Thread Starter vkovalcik

    (@vkovalcik)

    @arnaudbroes Cool, thank you for a very quick fix!

    Thread Starter vkovalcik

    (@vkovalcik)

    @wpsmort Sorry to report, but the fixes doesn’t seem to resolve the original issue. I am testing 3.4.3 now and I see a lot of changes, however both the description and the breadcrumbs are still untouched by the translation.

    I can use the same quick&dirty fix for breadcrumbs as described above. For the description I now moved the usage of the __() function, so I changed the method AIOSEOP_Graph_WebPage::prepare() (in graph-webpage.php), specifically changing the line

    $current_desc = $context->get_description();

    to

    $current_desc = __($context->get_description());

    did the trick. I am sure this is not a proper way to do it, but it gets the string to be translated.

    • This reply was modified 4 years, 6 months ago by vkovalcik.
    Thread Starter vkovalcik

    (@vkovalcik)

    Thank you, I can confirm this has been fixed in 3.4.3.

    • This reply was modified 4 years, 6 months ago by vkovalcik.
    Thread Starter vkovalcik

    (@vkovalcik)

    It could be even more granular I guess, but this covers the most obvious cases.

    Thread Starter vkovalcik

    (@vkovalcik)

    @wpsmort Thank you for the reply, I appreciate you put so much effort into this!

    You are right: The plugin I am using is old, but I made gradual changes, so it still works under newest WordPress. I believe the original plugin is qTranslate Plus before its shutdown.

    I found another fork called qTranslate XP with modification only a month old, but when disabling my plugin and activating this one, my website crashed… not unexpected, there seems to be some inconsistencies. So I am back to my version and I am exploring the AIOSP code.

    I am no expert, but currently I believe the problem is on AIOSP side, here is why:

    I found that the Schema:description is generated by the get_post_description() function in the graph-webpage.php (in all-in-one-seo-pack/inc/schema/graphs directory). It is getting the actual description by calling this:

    $post_description = get_post_meta( $post->ID, '_aioseop_description', true );

    There is no explicit localization at all, perhaps if some qTranslate/WPML plugin has hook to get_post_meta (but that might be too dangerous as it could overwrite it i cases you don’t want to). Anyway the same description is ALSO retrieved in a different part of AIOSP code – in aioseop_class.php, but this time the call is:

    $description = trim( $this->internationalize( get_post_meta( $post->ID, '_aioseop_description', true ) ) );

    That seems really weird, it is obviously explicitly localized in one spot and not localized in another. The internationalize() function seems to be not easily accessible in the first spot, so I put __() there instead which fixed the issue. Hence my quick and dirty fix of the code is:

    $post_description = __(get_post_meta( $post->ID, '_aioseop_description', true ));

    This fixes the original issue.

    I also found that a similar issue is in the Schema:breadcrumbs:name(s). There can be similar fix in graph-breadcrumbs.php, line 63 changed from

    'name' => $list_item['name'],

    to

    'name' => __($list_item['name']),

    Thread Starter vkovalcik

    (@vkovalcik)

    @arnaudbroes It is “qTranslate Plus” with my own tweaks. Pretty generic ones, no complex things. If you are interested, I can send you my version.

    It works pretty much everywhere – Gutenberg editor, various settings, plugins and All in One SEO plugin as well, except for that single “Description” property.

    Now I have noticed that the same description is used for meta:description, which works great (= is localized properly). There should be the same string in Schema:description, but it isn’t.

    I haven’t analyzed your code much, but it seems that the meta:description is using get_main_description() function from the aioseop_class.php, while the Schema:description is NOT using this function and neither get_post_description() or get_aioseop_description() (haven’t yet found where it gets the description from ?? ).

    • This reply was modified 4 years, 7 months ago by vkovalcik. Reason: Inserted two other methods I have explored

    Thanks, mitchoyoshitaka! The 3.1.1 version seems to be working right out of the box on my site ??

    vkovalcik

    (@vkovalcik)

    I stand corrected, the main problem wasn’t the timeout. But I found a solution (that works for me at least) ??

    It can be fixed as follows. All done in 3.0.14b1, file magic.php. Replace line 212, originally:
    $newsql .= " having score >= $safethreshold";
    with this:
    $newsql .= " having score >= " . number_format($safethreshold, 2, '.', '');

    Explanation: It was a “localization bug”. The original line generated SQL select with
    “… having score >= 0,5 …”
    which is correct in my language (Czech), but incorrect in English and SQL. The second statement will generate
    “… having score >= 0.5 …”
    Surprisingly, this happens only when WPCG2 plugin is active, which probably means that WP itself works in neutral language and WPG2 switched the context somehow – the problem might be in WPG2, but I guess the same problem happens with some other plugins.

    Hope it will help you!

    vkovalcik

    (@vkovalcik)

    Rhia42: You have to install phpMyAdmin, so you can view your database.

    Anyway, I think I am slowly starting to see the root of the problem on my system. Here is my hypothesis:
    The issue seems to be in the cache generation, more precisely: The queries that generate the yarpp_related_cache are sometimes timing out.
    I sometimes see the “Constructing the related posts timed out” message (I haven’t seen that before this week), but it seems to me, that this is only shown for the first query. If the subsequent queries fail, the user won’t know that (!) and the yarpp_related_cache table contains a lot of zeroes.

    In my case, this difference lies in the WPG2 plug-in, which significantly slows down certain operations. With this plug-in disable the cache generation of related posts takes about 30 seconds and yarpp_related_cache table contains those zeroes and a few valid numbers – these numbers are different every time I rebuild the cache, so I can see that it’s not a simple software error (it would probably be the same every time).
    With the WPG2 deactivated, the generation takes about 4 seconds and all is ok. Of course, for different blogs, there might be different plug-ins that cause this slowdown.

    The solution might be to increase the waiting time, but I don’t know exactly how to do it. I will try to guess it, but I am no PHP/Java/Ajax programmer, so it is a bit difficult for me (I am only experienced in C++/Pascal). Mitchoyoshitaka, could you help me, please?

    Aside from that, when I was examining the code, I found one possible inefficiency in yarpp_get_cached_keywords() function:

    $out = $wpdb->get_var("select $type from {$wpdb->prefix}yarpp_keyword_cache where ID = $ID");
    	if ($out === false or $out == '')
    		yarpp_cache_keywords($ID);
    	$out = $wpdb->get_var("select $type from {$wpdb->prefix}yarpp_keyword_cache where ID = $ID");
    	}

    should probably be:

    $out = $wpdb->get_var("select $type from {$wpdb->prefix}yarpp_keyword_cache where ID = $ID");
    	if ($out === false or $out == '') {
    		yarpp_cache_keywords($ID);
    	  $out = $wpdb->get_var("select $type from {$wpdb->prefix}yarpp_keyword_cache where ID = $ID");
    	}

    YARPP 3.0.9, 3.0.13 and 3.0.14b1 show “no related posts” to me too. The MySQL server is of a version 5.0.44. I am running WordPress 2.8.4 with some plug-ins including SuperCache. I’ve tried to disable it, but that doesn’t help.

    As others pointed out, the wp_yarpp_related_cache table looks strange … “reference_ID” column seems ok, but “ID” and “score” columns contains zeros in almost all of the positions (with the exception of one entry).

Viewing 10 replies - 1 through 10 (of 10 total)