[Ernest Marcinko]

Hi!

This sounds like a minor database inconsistency. Try the following steps:

1. Open up all the search instances you have created and save them without changing anything: https://i.imgur.com/tSs0Voz.png
2. Open up the Cache Settings and save them without changing anything: http://i.imgur.com/vqNnZzX.png

Let me know if anything changes, or if you get different error messages.

[Ernest Marcinko]

Hi!

That url is currently working for me. This is very strange. How is it possible, that sometimes it’s working, sometimes it’s not. I mean, the related posts plugin outputs the same exact html for the same post – so I don’t understand how can it get corrupted.

Anyways I did a googling on this thing, and if I’m correct then you are using the WP Fastest cache plugin. I’ve found a support thread with a problem very similar to yours with a different plugin: https://wordpress.org/support/topic/html-is-corrupted?replies=6

I’ve downloaded the plugin and examined the code, and my best guess is that the html checking function is failing or it’s buggy in some cases – that would explain why a page on your site is working sometimes, then it fails on other times. Anyways, in my opinion the best thing to do is to bypass that function with a minor modification on their code. Since they are aware of this issue I think they will solve it sometime soon.

Open up the wp-content/plugins/wp-fastest-cache/inc/cache.php file and go to line 137, where you should see this function:

public function checkHtml($buffer){
	if(preg_match('/<\/html>/si', $buffer) && preg_match('/<\/body>/si', $buffer)){
		return false;
	}

	return true;
}

replace it with the following:

public function checkHtml($buffer){
  return false;
}

This will bypass the html check for now, until they fix the regular expressions in this function. After this change, clear the cache and the pages should start showing up correctly.

[Ernest Marcinko]

Okay! I hope it will work, then I can safely include this fix in the future versions.

[Ernest Marcinko]

I think I might figured out the problem. If you have more than 6 items, then the pagination is used. The pagination icons are svg vectorgraphic images, which have a xml type of declaration included as well. Maybe that is confusing the cache plugin, since it’s unusual.

Anyways, I removed the unnecessary xml declaration codes and zipped the img folder and attached to this post. Please unzip this file to a folder in your computer and copy it’s contents to your servers wp-content/plugins/related-posts-pro/img/ folder and overwrite all the files with the new ones in that directory.

Then refresh the page a few times, enable the caching and gzip plugin, clear the cache a few times and hopefully it will work.

[Ernest Marcinko]

Thanks, now it’s fine!

Okay, all I can see right now from the page source, that the HTML is rendered until the beginning of the post content then it stops. And there is also a hidden message at the end of the site code which tells, that HTML is corrupted. Are you using some kind of html minification or caching plugin? Maybe it sopts with page rendering because there is a syntax error somewhere, or some kind of unstripped html inside the related content, I’m not sure.

First you should try to deactivate the caching or html minifying plugin temporary and see if it works then, or if it’s throwing any kind of errors or if there is some kind of funny unfinished code.

If it’s going to work with caching disabled, then maybe I can catch the error in the output.

Also, by default the HTML is not removed from the content, which can cause such issues I think. Try to change the formatting options as it is on the following screenshot: http://i.imgur.com/rrZxYVh.png
Then save the options, empty the cache and refresh the page a few times.
This way unfinished content from shortcodes or remaining html tags will get stripped correctly and might fix the problem.

[Ernest Marcinko]

That is a license code for a different item, Advanced Social and Menu Bar and not Related Posts Pro. Please submit the one you got for Related Posts Pro. Thank you.

[Ernest Marcinko]

Hi!

The search uses a custom function to list the available multisite instances. As I looked through the source code, it only list public, non-spam, non-archived blogs. I believe that the user created blogs might have a different flag for public(?) status.

Anyways I have changed the search plugin code a bit so blogs with different statuses will show up. You should see every multisite blog now properly.

[Ernest Marcinko]

Hi!

Could you please re-open your ticket with proper product key or attach your product key to your next post in a text document? I can only help tickets with confirmed purchase keys. (some people with pirate versions had abused the support unfortunately)

As for the issue. I’m not sure if I’m going to be able to reproduce this issue on my servers. Do you have a development copy of your site, which I could access on the same server? I think that would be the fastest way of solving the problem, as I could see it happening.

[Ernest Marcinko]

Custom taxonomies are like product categories in WooCommerce, or forum tags in BBPress. The regular post tags are a little bit different.

[Ernest Marcinko]

Hi!

Currently it is only possible to search categories and custom taxonomies. The plugin also looks in tags, but only the posts are returned related to those tags.

I will add this request for the next version of the plugin (will be available in a couple of days), as it’s unfortunately not possible to do with a quick modification.

[Ernest Marcinko]

I just checked, that page has no content at all, only a shortcode. So the shortcode content is used. But since it’s not viewed as a page I guess it gives this message.

I have changed to strip the shortcodes instead of running them, you can turn that back if you want to on the “Advanced options” panel.

This way however it will show no description, since the page has no text available, only a shortcode, which is not executed anymore.

[Ernest Marcinko]

Hi!

If you switched to fulltext search, then I recommend switching it back. That can cause such issues. The database skips some common words when using fulltext search, and “after” sounds like a very common word. Here is a quick knowledgebase article on this.

Also, here is a post about the different available search logics: Search logics explained

Plus make sure you have the search cache disabled. That can give you different results when you add new products.

[Ernest Marcinko]

No problem at all.

It appears to me that the theme changes the location of that block at a certain height. All you can do is change the position of the search, or try to force the absolute position on that element:
[html]
div.header-scrolling div.header-custom-block {
position: absolute !important;
}
[/html]

[Ernest Marcinko]

Same here. I’m using win8.0, ff33.0 and the same resolution. I also tried on a different computer with a lower resolution, but it still works.
1. my computer: http://i.imgur.com/ml86kZ2.png
2. laptop: http://i.imgur.com/5Ih3buM.png

But my guess is that it somehow get’s out of the boundaries based on your screenshots. I can’t reproduce it, but I might have a solution. Try to add the following CSS code to the search plugins “Theme options->Custom CSS” field:

[html]
div[id*=ajaxsearchpro3] {
max-width: 243px !important;
}
[/html]

Will check that IE, that’s a bit tricky. I’ve implemented fallback, but it only should apply with versions below 10. I hate IE, it’s almost impossible to check the version of it on server side, that is probably going to be a bug with the 3.2 plugin version. I’ll do some testing on both computers + virtual machine on that and get back to you with a hotfix.

[Ernest Marcinko]

I just left the office, so I will check that firefox thing again tomorrow morning. Could you please post your operating system version, screen resolution and firefox version? I will double check this on another computer as well.

[Author]

Posts