hussong

I’d be rather interested in this as well, since I need to import a huge custom taxonomy tree with 20 parent and 80 child taxonomies in total.

To make things worse, taxonomy names can be quite long (up to 50 characters) and contain spaces as well as ampersands. Could this possibly work with your plugin?

Thanks!

It would be great if someone could reply to this.

I am still desperately looking for a way (any way) to make the custom post type archive page meta description multilingual.

Same goes for the open graph description snippet BTW.

Thanks!

Just wanted to share a quick workaround: If you’re using a custom php template, you can wrap the part that displays the related posts in a conditional statement that checks if the current language is the primary language.

Your modified yarpp-template-multilingual.php would look like this:

<?php
/*
YARPP Template: Multilingual
Description: An example template for use with the WPML and Polylang plugins
Author: mitcho (Michael Yoshitaka Erlewine)
*/

if (function_exists("icl_register_string")) {
	icl_register_string("Yet Another Related Posts Plugin", "related posts header", "Related Posts");
	icl_register_string("Yet Another Related Posts Plugin", "no related posts message", "No related posts.");
} ?>

<?php if(ICL_LANGUAGE_CODE=='en') :?>
	<h3><?php echo (function_exists("icl_t") ? icl_t("Yet Another Related Posts Plugin", "related posts header", "Related Posts") : "Related Posts") ?></h3>
	<?php if (have_posts()):?>
	<ol>
		<?php while (have_posts()) : the_post(); ?>
		<li><a href="<?php the_permalink() ?>" rel="bookmark"><?php the_title(); ?></a></li>
		<?php endwhile; ?>
	</ol>
	<?php else: ?>
	<p><?php echo (function_exists("icl_t") ? icl_t("Yet Another Related Posts Plugin", "no related posts message", "No related posts.") : "No related posts.") ?></p>
	<?php endif; ?>
<?php endif; ?>

Change the language code to your primary language and you’ll have at least properly working related posts on your primary language and nothing bad on the secondary languages.

This solved it for me as well, with YARPP 4.0.7b1:

1. de-activate plugin
2. manually delete all yarpp entries in wp_options from phpmyadmin
3. re-activate plugin

Update: I’ve installed YARPP 4.0.6 along with WPML 2.9.1 and it works OOTB as far as “language separation” is concerned — i.e. related German posts are shown on German posts and related English posts are shown on English posts.

However, the related post generation for the secondary language (English in my case) seems to stall somewhere after the first page load and the related posts shown are the same on every other post (it would even show a link to the current post).

When I change the maximum number of related posts and save the settings, it seems to re-generate related posts on the first page load (they change), but then it keeps showing the new de-facto static set of related posts again all over the place.

Same with YARPP 4.0.7b1 BTW.

Hope this helps!

I am currently working relaunching a bilingual website that I just migrated to WPML and was planning to implement related posts via YARPP as well.

I can offer some testing next week, let me know if I can help.

Thank you for the great plugins!

the .custom-font-enabled class is only used in this style in Twenty Twelve:

This just made my day, I was worried that the absence of this class would have some side-effects, thanks a lot!

Awesome, thanks for the quick reply!

I’ll bounce this off of my host and report back.

Still works like a charm for me on https://www.letterstotheisland.net/ — haven’t found a great replacement yet. The Google Translate element doesn’t integrate as nicely into a site as the plugin does and seems to add more weight to the page (some users have reported an increase in page load time).

You can find step-by-step uninstallation instructions here: https://www.ads-software.com/extend/plugins/wp-super-cache/other_notes/

Happy to hear that sharing my experience was helpful, vTz ??

I had it set to “Month and name” when it stopped working. Set it back to defaults and back again to “Month and name” and it worked again.

I’m pretty sure I removed the Supercache rules only (I remember double checking when I edited the files). Anyway, thanks for adding the troubleshooting note!

Thanks for the update. Yeah, I think it makes a lot of sense to not mess with the body-tag at all. And I guess I’d rather stay away from the window.onload event handler to prevent conflicts with other scripts. My knowledge of JavaScript is quite limited though…

Thank you for the super-fast update! In the meantime, I had gone ahead and added a few changes myself.

In humansnotbots.js, I used getElementsByTagName to avoid having to insert an id attribute into the body element:

function HumansNotBots()
{
    var htmlbody = document.getElementsByTagName('body')[0];
    var rep = '<a href="mailto:$1@$2.$3">$1@$2.$3</a>';
    var newInnerHTML = htmlbody.innerHTML.replace(/([a-zA-Z0-9._%+-]+)\sAT\s([a-zA-Z0-9.-]+)\sDOT\s([a-zA-Z]{2,4})/g, rep);
    htmlbody.innerHTML = newInnerHTML;
}

In humansnotbots.php, I used wp_enqueue_script:

/* Add javascript to html head */
function add_header () {
    if ( !is_admin() )
  	{
        wp_enqueue_script( 'humansnotbots', WP_PLUGIN_URL .'/'. plugin_basename(dirname(__FILE__)) . '/humansnotbots.js', '', '1.2', false );
    }
}
add_action( 'wp_print_scripts', 'add_header' );

using the tutorial here: https://weblogtoolscollection.com/archives/2010/05/06/adding-scripts-properly-to-wordpress-part-1-wp_enqueue_script/

And to call the script, I added a function that inserts js upon the wp_footer event, which then calls the function HumansNotBots if the body has loaded:

/* Add onload after body has loaded and call function */
function add_onload() {
    ?>
    <script type="text/javascript">
    my_onload_callback = HumansNotBots(); // call function

    if( typeof jQuery == "function" ) {
        jQuery(my_onload_callback); // document.ready
    } else {
        document.getElementsByTagName('body')[0].onload = my_onload_callback; // body.onload
    }
    </script>
    <?php
}
add_action( 'wp_footer', 'add_onload' );

using a solution I found here: https://wordpress.stackexchange.com/questions/879/adding-onload-to-body/882#882

This should be a lot safer across different themes and plugins. Feel free to use this code for one of the next update ??