[Ernest Marcinko]

Hi!

I’m afraid not. It’s a too deep code change, I can’t really make a hook to it. But most likely I will make an option in the upcoming versions, something like “exact matches only”, so you might not need to change anything.

[Ernest Marcinko]

Of course we can try. But please don’t expect google-like relevance, the product is smart, but not as smart as google 😀

Okay, so what I understand is that you are interested in comparing the titles in a more “exact” way. What we should try is to change the query to look for exact title matches, and ignore the individual words from the title.

Open up the reladed-posts-pro/includes/related_content.class.php file. It’s a huge file handling and building up the final quiery for the lookup.

On line 298-303 you should see something like:

  $like = implode(' OR ', $parts);
  if ($like == "")
      $like = "(1)";
  else {
      $like = "($like)";
  }

That’s the part you don’t really need anymore, instead let’s change it to an exact title match thing:

  /*$like = implode(' OR ', $parts);
  if ($like == "")
      $like = "(1)";
  else {
      $like = "($like)";
  }*/
  $like = "(lower($wpdb->posts.post_title) LIKE '%".strtolower($post->post_title)."%')";

As you can see I just commented out the old code and added one line. The new line basically grabs the title and compares it to other post titles.

One last thing, this affect the non-fulltext lookups, sou you should disable the fulltext lookup (http://i.imgur.com/28Bp0mW.png) on the advanced options panel. Also the caching as well.

• This reply was modified 11 years, 10 months ago by Ernest Marcinko.

[Ernest Marcinko]

Hi!

I believe the problem is that the every post in this case contains the work “Man” which is most likely picked up as a keyword.

If you need very specific results, then I would recommend to select the posts which you need as results (you can do it for each post on the post editor screen, http://i.imgur.com/4byCeeF.png)

Or you can add the keyword “man” to the restricted words list if you feel, that it’s too common. (it’s in the related-posts-pro/restricted.txt file, words are separated by spaces)

Or it is also possible to create a custom field with keywords on the post editor, and select to only look in that custom field on the related posts pro settings page.

I would recommend the first solution, because you can customize the results on a post level – other posts won’t get affected.

[Ernest Marcinko]

Hi!

The crayon syntax highligher uses a post-page content filter, which means it filters the content via an ajax request.

Try to turn off “Run the content” filter and “Run the title filter” on the Content Options panel, it should help: http://i.imgur.com/EWZGYt0.png

Thank you for reporting the second Issue, I was not able to recreate it, but I will certainly add a fix to the next version.

[Ernest Marcinko]

Hi!

Your shortcode placement seems all rigth to me, it should work.

Is the error message related to the search plugin? Can you please paste it here, I might be able to tell if it’s something known.

The fact that your theme does not support widgets in header should not affect the search, but I might be wrong.

Also, what happens if you place the search somewhere else? (inside a page, post or widget bar) Is it working then?

[Ernest Marcinko]

Hi!

Please change the file permissions on the cache and css folders, here is an article on how you can do it: http://wp-dreams.com/faqs/the-search-is-not-saving-the-changes-i-made/

After changing the permissions, please save the search once again!

As I upper suggested, please try the search with the default template, and if it works, then we will know if it’s the template causing that.

Also, can you provide temporary administrator and ftp access? Then I will be able to run a quick debug as well.

[Ernest Marcinko]

Hi!

I’ve done some test searches, and it looks like that something is interfeering with the ajax request, that’s why the results box doesn’t show up. This can be anything – plugins, theme, server configuration, .htaccess restrictions.

If you switch the theme to the default then it works, or is it not working with any theme?

[Ernest Marcinko]

Hi!

I think I managed to solve the issue with the escaping characters. I’m attaching the fixed version of the plugin. You can safely deactivate and delete the previous version, the created instances and options will remain.

I’ve tested with multiple quotes, special characters, backslashes, and it outputted exactly the input, I hope it will work for you as well.

You may need to empty the custom css field first, save it a couple of times and then enter your custom code, just to make sure it’s refreshed in the database.

[Ernest Marcinko]

Of course. Tomorrow morning I will start with this, I’m 90% sure I can solve it relatively quickly (I hope). So at some time tomorrow I will attach a fixed version here.

[Ernest Marcinko]

Me too! It makes the plugin better.

I’m hoping to finish the new version of the ajax search pro 3 mid next week, then I’m going through the various bugs reported to this plugin. I’m not sure if new features are coming very soon, I keep findig bugs, I’m afraid I might generate even more 😀

I’m also working a knowledgebase and moving the demo pages, so there is that as well.

Anyways, thank you for discovering and reporting this, I’m going to fix it asap.

[Ernest Marcinko]

Wait, I thought you were putting these values into a custom.css file, not the custom css form.

The values are saved with update_option() internal wordpress function, so it’s the wp_options table. But that’s managed by wordpress, so I’m advise not to touch the values there.
So it’s either that, or the output scrambles it up, I will look into it in the next hotfix version. Or even better, I might base64 encode/decode the custom css values to avoid this conflict. (that’s the safest option) I never thought this could happen, sorry.

Please don’t use the custom CSS form until then, rather a custom.css file in the theme.

[Ernest Marcinko]

Hi!

Check the id of the element first. The .rpp_content:before is not working because it’s a lower priority CSS selector then the other one.

Try div[id^=”relatedpostspro_0_”] .rpp_content: before instead. If not working then #relatedpostspro_0_1 .rpp_content: before should be the highest priority.

[Ernest Marcinko]

Thank you!

No, in the next update I will include these changes, you don’t need to worry about that.

Have a nice day!

[Ernest Marcinko]

Dear Mohammed,

You are right, I accidentally turned off images on the arabic version. I turned them back on, they should start showing after the cache expires.

The safest way is to copy the wp-content/plugins/reladet-posts-pro folder and all of it’s content to the production site. It contains all the modifications I made.

As for the settings, they are stored in the database, but all I did was disabled timthumb (image options->use timthumb): http://i.imgur.com/YudqKLK.png

and also i made a change on the compatibility options panel, swithcing the javascript source to “Non-minified scoped”: http://i.imgur.com/KA51op8.png

If you copy the files from the plugin folder and make sure, that these options are changed, it should work as on the test site.

[Ernest Marcinko]

Hi!

Those files are only pre-created stylesheet files, only some of them are used and are generated dynamically. I don’t recommend editing them, because after saving the plugin instance they are re-generated.

In your case I would recommend to rather use one of the site theme CSS files. They usually have a custom.css somewhere in the template folder. I used to do this, it’s the safest and the best way – because then I only need to backup one css file.

There is not really a better solution to this, because if I put a custom.css file into the plugins directory, then it would be overwritten with the next update by the plugin manager automatically.

[Author]

Posts