3Lancer

Are you using any translation plugin such as QTranslate?

As that will make multiple titles, descriptions, etc (one per language) – then the WordPress SEO plugin won’t know to only use one of them without some modifications. I’m working on that issue myself.

Hi fellows,

For version 3.6.5, here’s a quick solution.

Under the plugin, location the file ‘/inc/secure.php’ and search for the following code…

$HTTP_RAW_POST_DATA = @file_get_contents( 'php://input' );

			if ( $HTTP_RAW_POST_DATA !== false && strlen( $HTTP_RAW_POST_DATA ) > 0 ) {

				$data = base64_decode( $HTTP_RAW_POST_DATA );

				if ( strpos( $data, 's:10:"iwp_action";' ) !== false ) {
					$isIWP = true;
				} else {
					$isIWP = false;
				}

}

What’s wrong with this, is if it never gets into that IF Statement, it won’t set the ‘$isIWP’ Boolean value.

So just above that, just after this line…

global $bwpsoptions, $is_404, $isIWP;

Add the following…

$isIWP = false; // added fix

Thank you for your reply, donfre, but that would remove all related products.

I would like to keep the related products showing but just not show itself on it’s own page. If that makes sense?

For example:

Product 2 – related = Product 1, Product 2, Product 3, Product 4

Remove the related ‘Product 2’ from it’s single product summary as it just links to itself.

Comon, surely someone has encountered this?

When you go to the product page, listed below is related products, the only issue is it also displays itself there too.

Hi Niall, thanks for your quick response. That pretty much makes sense.

So Facebook is the one caching it for 24 hours, not my end?

Is there a way to overwrite that Facebook locale from my theme’s functions.php file (adding a filter there to force a selected language or something) rather than editing the plugin files itself which might get updated/replaced?

Nevermind – it was just a CHMOD issue in my case, for some reason it didn’t seem to accept the change, probably just due to cache (even thought I did attempt to clear it) – today it magically decided to work by reapplying the CHMOD via FTP. By the way never use CHMOD 777, as it’s a major security risk – 775 just for that languages folder would be slightly better, works but note it still could be a hole for weak script accessing it to be exploited.

Bit of an old post, but just curious if you or something else has managed to work it out?

I’m getting the same, but only on one server. My development server which has the same code isn’t affected by this issue. So it’s definitely based upon server settings, but CHMOD settings doesn’t seem to be affecting it.

Hi,

No idea when the developer will update or release a new version, but believe it won’t be affected anyways.

The ‘Parker’ update, aka WordPress 3.8, just features a responsive, redesigned dashboard and a few minor fixes. It should be all unrelated (except for possible widgets).

However so far tested this only a DEV Server and seems to be working fine without any major modifications. I have so far seen no issues and will release to live next week. Detected no compatibility issues.

If you so desired, recommend backing up database and files first.

Edit: qtranslate.php

Update this line to the WordPress version –
define(‘QT_SUPPORTED_WP_VERSION’, ‘3.8’);

This will make it work without that warning message popping up. Just save and refresh.