Unrelated content being linked to repeatedly

Has there been any change in your mySQL database version by any chance?

Hi Ajay,

No – my MySQL database has not been updated for almost 12 months. I am running MySQL 5.6.31, PHP Version 7.0.14 and WordPress 4.7.1 if that helps.

5.6 helps. One option worth exploring is to convert the table wp_posts from isam to innodb or vice versa to test the results.

Another thing to fine-tune the results is to use the CRP Taxonomy addon

Having the same problem – and it’s completely new for me, after having used this plug-in for years: Same few handful of posts recurring, regardless of the character of the post they’re supposed to relate to.

I’d be willing to perform the test mentioned above, although I’m a little reluctant to experiment with a table that is central to the functionality of the site and all of its content. Can you explain what the difference between isam and innodb is, actually, and why it seems to matter here?

I’ve tried the CRP Taxonomy add-on, and am still getting the same small handful of posts appearing over and over again as “related” in many cases. I’ve also experimented with some of the other settings – like the limit on content tested (I’d always had it set at zero before). The impression one gets is that no “contextual” matching is actually taking place.

In any event, it seems to be a new bad behavior in a plug-in that was working just fine for a long time. I wonder if any changes you have made during recent upgrades are the problem.

I’m thinking of either rolling back to a previous version if I can easily find one, or, regretfully, disabling the plug-in for now.

Incidentally, I also get a repeated “Javascript reference error, SIW is not defined error whenever I try to save options. This also seems new, though prior to my trying out the taxonomy add-on.

One thing worthwile trying out is the complete uninstall and reinstall of the plugin.

https://blog.danyll.com/myisam-vs-innodb/

Older versions at: https://www.ads-software.com/plugins/contextual-related-posts/developers/

I tried almost everything – re-installation, installation of earlier version, switching themes, disabling plugins, installing the taxonomy add-on, re-creating the index including with the direct MySQL commands, clearing the cache multiple times.

I was resistant about changing the database table Storage Engine from InnoDB to MyISAM, but finally got around to testing the change on my development/local installation, and, lo and behold, switching to InnoDB on the local site produced the same very unwanted behavior as on my production site, at which the Posts table is now set at InnoDB.

The Storage Engine change may have been done by my new host, and maybe it just took this long for me to notice what was happening – when a certain post happened to be getting some particularly ill-suited and hard to call “related” posts.

Though it probably wouldn’t make much difference for this particular production site, a low traffic blog, to switch to MyISAM, I still don’t think it’s an optimal solution since the site is a place where, among other things, I develop and optimize solutions for higher traffic/multi-user sites of the sort for which, according to my reading over the last couple of days, InnoDB appears designed.

If InnoDB defeats the main unique function of CRP, I think I would prefer the option to disable BOTH title and content matching, and instead just match by a random selection from multiple taxonomies, which I think would mean either hacking CRP, adapting some other Related Posts plug-in, or writing my own…

Any suggestions on rescuing CRP? It really has been one of my favorites for a long time!

If you’re using the taxonomy addon you can actually disable the relevance matching and then use tags etc to do it.

One thing that I have been seriously considering with CRP is to create a separate table that will serve as the relevancy matcher so staying out of the main posts table.

I’m still evaluating the best way to go about this with minimum disruption

Though I obviously cannot be sure what potential disruptions are concerning you, I sympathize!

You could even consider offering a version of the taxonomy + non-contextual CRP combo as a “light” or lighter standalone version of CRP, then develop the separate-db “contextual” version as an eventual add-on for it or for both the taxonomy version and legacy CRP. Possibilities are endless, as ever.

In any event CRP’s overall design and implementation also set it apart from other related posts plug-ins, so I may adopt the taxonomy add-on solution at least temporarily, and I look forward to seeing what you eventually do.

It’s mainly because the plugin runs on 70k+ sites and any major change can end up breaking a few sites down which worries me. Unfortunately, I don’t have a big support team to handle issues …

The idea would be to use the CRP base as a feeder for addons and move features around in the long run.

Well, if you treat the person who started this thread and myself as “the cockroaches you see,” you’re probably getting breakdowns that you’re not seeing, including for people who don’t know it yet. I don’t know what the economics of your situation are, so may not be able to offer any further practical input, but, if I can be of some reasonable service or you need some beta-testing, feel free to drop me a line via my site contact form.

When I have something respectable to trust, I will let you know. It always helps having someone with access to a lot of content.

My plan will be to add a separate table for CRP that will hold the post and the content (either full or matching) and use that algorithm for the matching. This should hopefully make a lot more sense with the relevancy matching.

I don’t have a timeline yet, as I develop these in my time away from the day job.

Ajay

• This reply was modified 7 years, 11 months ago by WebberZone.

Understood. Have the same problem!

So, I decided for now to go for the Taxonomy add-on plus original CRP. What I didn’t like was that it tended to get me the same group of related posts for posts in the same categories. So, to shake things up a bit – or keep re-circulating a variety of old content – I introduced a randomization function using your ‘get_crp_posts_id’ filter. In the main settings or widget I set CRP to 50 posts, and then the new function randomizes the get and slices off 3. I’ll continue experimenting with different approaches. I’m fairly confident you could write this function in your sleep, but here it is in case anyone else is interested:

add_filter( 'get_crp_posts_id', 'shuffle_crp_results' );

/**
 * RANDOMIZE AND REDUCE "CONTEXTUAL RELATED POSTS"
 * PRODUCE RANDOMLY SELECTED POSTS FROM CRP "GET"
 * AS PREVIOUSLY SET ON OPTIONS PAGE OR WIDGET

 * @param $results array of Post Object IDs returned by get_crp_posts_id()
 * in contextual-related-posts.php 2.3.1, line 596
 */
function shuffle_crp_results( $results ) {
     
    shuffle( $results );
  
    //last number = # of posts to display
    $results = array_slice( $results, 0, 3 );
  
    return $results ;
     
}

• This reply was modified 7 years, 11 months ago by CK MacLeod.

(The above code does lead to unexpected results in at least one case observed so far. Am currently researching the cause.)

You could also do this by adding a function to filter crp_posts_orderby to return RAND() directly in the mySQL query, although am not sure of the exact impact to performance vs. shuffle.

It would help if you have the cache on in both cases.

If the intention was definitely to bypass content matching, you could also try a WP_Query alternative. That said, my custom shuffler seems to work more than quickly enough. It does lead, as I noted, to an unexpected result, however.

It turns out that the problem is posts with “manual” IDs assigned.

In order to write the function, I reverse-engineered from the $results variable, which in CRP usually (whatever the Codex says about $wpdb->get_results() ) returns an array of objects. Maybe you can enlighten me on why this happens here, as it’s not obvious to me from analyzing your code.

The “manual” module’s code shows that, as I’d certainly expect, you are fully aware what kind of return you’re getting for $results in the get_crp_posts_id function, but your comment in get_crp_posts_id suggests that $results should be an object, when, as noted, it’s usually an array of objects.

Back to my purposes: When manual posts are set, and $results returns an object (or object of objects – not sure if there’s a proper term for one of these), my custom shuffler will produce a “not an array” error. I can get rid of the error by re-casting the manual “results” as an object, but then I’ll have to re-do the shuffle function to re-gain the basic functionality of the manual settings (giving the manually set related posts priority). Not terribly complicated, but a little, um, circuitous.

Anyway, with that I’m going to invite you again to contact me via my profile/blog/contact form, as the thread really doesn’t seem to be well-designed for dialogue: I continually have to re-load or come into it from different angles in order to view its complete content. My comments also are not being consistently output.

Not sure what’s going on. Are you not getting any weirdness along those lines? I’m thinking about notifying forum Administration.