[Ernest Marcinko]

Hi!

Make sure you are using the latest version of the plugin (4.5.3), this was a known issue beforehand. Let me know if this still persists.

[Ernest Marcinko]

Oh, you are using a different version than what I’m looking at and I forgot about the secondary ordering as well.

For the correct solution, first find line 602:

[code]if (count($all_pageposts) > 0) {[/code]

and replace it with this negative statement:

[code]if (0) {[/code]

So it becomes inactive. Then the go to line 384:

[code]ORDER BY priority DESC, relevance DESC, " . $wpdb->posts . "." . $orderby . "[/code]

and change that to:

[code]ORDER BY RAND()[/code]

If I’m correct, this should work 🙂

[Ernest Marcinko]

Yep, it’s not there unfortunately, because it’s a get-around solution yet 🙂

Just change the text in the source code like so:

[code]<?php if (isset($options["title_text"]) && $options["title_text"] != ""): ?>
<?php icl_register_string(‘related_posts_pro’, ‘Header title’, ‘Recommended for you’); ?>
<legend><?php echo icl_t(‘related_posts_pro’, ‘Header title’, ‘Recommended for you’); ?></legend>
<?php endif; ?>[/code]

As you can see there is two ‘Recommended for you’ strings there between apostrophes, that’s the default english text. Change that to anything you want. Once you are done, only then start translating, because I’m not sure if changing the text looses the translations or not.

[Ernest Marcinko]

Great! I will implement this as a feature to the upcoming version.

If you like the plugin, feel free to rate it anytime on your codecanyon downloads page.

Feel free to contact me if you need any help, have a nice day!

[Ernest Marcinko]

Hi!

I looked up all possible solution based on this WPML article.

Method 2 and 3 are the possibilities, probably method 2 is easier in our case. This means that the title must be hard coded and then translated on the WPML string translations interface.

Open up the wp-content/plugins/related-posts-pro/includes/views/rpp.shortcode.php file and go lines 15-17, where you should see this:

[code]<?php if (isset($options["title_text"]) && $options["title_text"] != ""): ?>
<legend><?php echo $options["title_text"]; ?></legend>
<?php endif; ?>[/code]

Change that code to something like:

[code]<?php if (isset($options["title_text"]) && $options["title_text"] != ""): ?>
<?php icl_register_string(‘related_posts_pro’, ‘Header title’, ‘Related Posts’); ?>
<legend><?php echo icl_t(‘related_posts_pro’, ‘Header title’, ‘Related Posts’); ?></legend>
<?php endif; ?>[/code]

Now, refresh one of the frontend pages where the Related Posts Pro plugin is active a few times to get this string registered.
Then if you open the string translations submenu on WPML, you should be able to see this string and translate it: http://i.imgur.com/CpBCnA2.png

[Ernest Marcinko]

Sorry, I just checked and I lowered that for testing when you contacted me with the first issue and I forgot to revert it back. I changed it back to the default value. Can you please check if there is any change in results?

I’m sorry about that.

[Ernest Marcinko]

There is one thing I can try though. I can increase the result set limits to a higher number, which might increase the probability of getting the desired results. Let me know if you want to try it 🙂

[Ernest Marcinko]

The index table engine calculates the priority based on word occurence. If the word spot is occured more times in the selected fields than the others the result is shown first. For multiple words the occurence values are added together. If seemingly the “spot” word is prioritized it’s because it’s most likely occuring more times for the given results along with the “head” word.

With tens of thousands of results it’s even more complicated, because the logic determines the operation between each result set. Each result set is limited to a certain number based on an optimum calculation. The AND or OR logic only determines the connection between results sets for each keyword.

After determining the results, the script orders them by relevance first which is calculated based on the upper mentioned occurence, then if there are results with equal relevance, secondary ordering is used, which is date by default.

The exact matches will not work with the index table engine, it’s programatically impossible. (if you want I can explain why)

The index table is an extremely complex thing to explain. It’s a very high performance focused construction. For basic pro-con list you can read the documentation if you want: https://wpdreams.gitbooks.io/ajax-search-pro-documentation/content/index_table.html

The regular engine uses a bit more intuitive logic to calculate the relevance, but in your case I would not recommend using it. This is unfortunately not possible to implement with the index table engine.

[Ernest Marcinko]

Yep. It’s a known bug with the current version, which I’m updating soon.

I’ll fixed it manually for you, the upcoming update will of course contain all the bugfixes I applied on your installation regarding the index table, so you dont’ have to worry about that.

It should be working now.

[Ernest Marcinko]

Interesting.

I did some debugging, and WPML reports that the language is not set for the products? (missing ID error or something like that)

Anyways, I changed the index table to register the default site language if there was no language returned. I will note this as a bug, but I will have to ask WPML devs why the WPML plugin is returning an error when asking for the language for items with unregistered language information.

The tables contain the proper information, it should work now.

[Ernest Marcinko]

Hi!

Fortunately nothing big. The index table was generated before WPML was active, so the language was not set. I re-generated the index table to register the language as well, it should work now.

[Ernest Marcinko]

Hi!

It’s not yet possible. Tomorrow when I get back to office I look up a solution to hard-code something translatable there for you.

[Ernest Marcinko]

Hi!

I see multiple issues there.

The search shortcode is placed inside a Form element, which causes invalid HTML output and possibly malfunctioning as well – beacuse the search uses it’s own form, and a nested forms are prohibited in HTML.
The solution is to remove the container form element.

Currently the shortcode must be placed something like:

[html]<div class="col-xs-12 col-sm-12 col-md-6">
<form ….>
<?php echo do_shortcode("[wpdreams_ajaxsearchpro ...]"); ?>
</form>
</div>[/html]

and the correct layout is without the form, so something like:

[html]<div class="col-xs-12 col-sm-12 col-md-6">

<?php echo do_shortcode("[wpdreams_ajaxsearchpro ...]"); ?>

</div>[/html]

This might not solve the problem yet, because there is something else. The navigation bar is a floating element as I can see, and the “col-xs-12 col-sm-12 col-md-6” div container is not. So it just sits on top of the floating navigation bar incorrectly.

My suggestion is to use a CSS code to force a floating clear before the search is displayed:

[code].navbar:after {
content: "";
display: table;
clear: both;
}[/code]

or if that’s not working, maybe:

[code].col-xs-12.col-sm-12.col-md-6 {
clear: both;
}[/code]

I don’t know exactly, it’s not a plugin related issue, but I guess one of these should work.

[Ernest Marcinko]

Thank you for the video.

What I mean is, when you search and click on the “bosh espresso machine”, you are taken directly to that image page in the video.

Now, leave that page open and on another tab go to the administrator area and on the plugin manager deactiavate the Ajax Search pro plugin. Then go back to the previous browser tab, where the “bosh espresso machine” is still opened and refresh that page. If the images are still displayed incorrectly, then it is most likely not related to the Ajax Search Pro plugin – because it is deactivated. In this case it means that something else is messing up the attachment template page.

[Ernest Marcinko]

Hi!

Unfortunately this is most likely not related to the search plugin at all. Try opening the same result page when the search plugin is inactive, it should be displayed the same way.

What I’m guessing is that the widget manager might be applying some of the content filters, and it results in displaying the content (attachment in your case) once again.

If the problem does go away if the search plugin is inactive, then I gladly take a look. Otherwise it’s probably unfortunately not related.

[Author]

Posts