otravers

I can replicate the same behavior though it’s not always happening. Sometimes indeed the %user_password% shortcut in email notifications is rendered as “both”, which is not the actual password and leads to a very confusing customer experience.

This never occurred prior to WP 4.3.

I’m running into this issue too in my local dev environment which is a Windows 7 PC running the XAMPP stack with PHP 5.3.8. In our staging environment which runs Centos and PHP 5.3.18, the same Mandrill API key was accepted without a hitch. Both WP installs are similar (local dev has a few extra plugins) with WP 3.5 and wpMandrill 1.23.

It’s a custom theme made in-house. For now we’ve moved related articles within the loop, which restricts our layout options somewhat. You can see it in action at:
https://www.marketingcharts.com/wp/direct/data-dive-us-online-ad-spend-per-user-2000-2011-22956/

FYI I installed the Log Deprecated Notices WP plugin which returned this about your plugin:

Argument in add_options_page()
Used in wp-content/plugins/contextual-related-posts/admin.inc.php on line 346.

Usage of user levels by plugins and themes is deprecated. Use roles and capabilities instead. Deprecated in version 2.0.

I don’t think it has anything to do with the original topic of this thread but I thought I’d mention it in passing.

To be more specific on my code, until 3.4.1 the following query, made after having closed the loop, was properly picked up by the echo_ald_crp() function:

$the_query = new WP_Query('p=$thePostID');
$the_query->the_post();

Since 3.4.2 it looks like echo_ald_crp() is oblivious to the value returned by that query and only works within the loop.

For maximum flexibility in terms of placement and look & feel, it would be great to have the ability to only retrieve IDs for the related entries and leave everything else to the developer, inside or outside the loop.

After further tests, I have found that the plugin itself still works, but only when I let it add its content to posts. When I use:

if(function_exists('echo_ald_crp')) echo_ald_crp();

I still get the same 5 unrelated entries no matter the displayed post. Does that help? This is not on a live site right now, just in dev, so it’s hard to share a URL.

Edit: I just found that echo_ald_crp() still works for me, but only within the WP loop. I’m pretty sure that until I upgraded from WP 3.4.1 to 3.4.2 I had CRP working for me outside of the loop.

Am I supposed to only use CRP within the loop? This diminished its value as a tool to place related posts wherever you want. Is there a way to put its output into a PHP variable as opposed to directly echo it?

These entries still exist. I went through a whole cycle of disable/uninstall/reinstall/reindex and still get the same issue. Where should I look in the database to manually delete the index built by your plugin?

The method posted by magnus78 worked for me. Is there any way to change it to fetch the author’s first and last name instead of their IDs?

I’ve tried the methods listed in the help file but couldn’t get them to work (in WordPress 2.1).

Well, since we’re using a GET search form, I went ahead and used the PHP variable from the URL parameter instead ($s). It still wouldn’t hurt to have more documentation about WordPress search.