WPBot

I forgot to mention that I’ve had the same results and without using a plugin to remove the category base, when I just set it to a . from the permalink options – it works fine when QTS is disabled and I get 404s on every page after the first one.

Hi,

No worries – I can wait a few more days or just apply it myself until the new version comes out.

Thanks for the help and the great plugin – it’s exactly what I needed.

So, I’ve tested the plugin on a few more blank WP installs (4.3.1) on different hosts (both shared and VPS) and I had the same problem with all of them.

I’ve used PHP versions from 5.3 to 5.6 but couldn’t make it work on any of them (even with numerous changes to php.ini).

I’ve also changed the database collation to different encodings and still nothing…

I started reading about stripslashes and this lead me to the get_magic_quotes_gpc function… so in public/partials/shortcodes/process/process_form_submission_ajax.php I changed line 27 from

$error_messages = json_decode( stripslashes( $form_data['error_messages'] ), true );

to:

if (get_magic_quotes_gpc()) {
     $err_messages = stripslashes( $form_data['error_messages'] );
}
else {
      $err_messages = $form_data['error_messages'] ;
}
$error_messages = json_decode( $err_messages, true );

and the problem was gone (that was done on a new plugin install without the JSON_UNESCAPED_UNICODE change I talked about earlier)…

This solution should work on all PHP versions, so could you include it in the next version if you don’t think there will be any side effects or maybe figure out something else because I really like the plugin, but losing the changes on every update doesn’t sound very appealing.

btw, while testing the different php.ini options I found out that on PHP 5.3 the plugin doesn’t work (or at least the form editor) with

magic_quotes_gpc = Off
magic_quotes_runtime = Off

I suppose you already know about that (or it might even be written somewhere in the plugin requirements that magic quotes should be turned off) but I thought to mention it just in case.

It’s a shared hosting with the following versions (taken from cPanel):

Apache Version 2.2.29
PHP Version 5.4.37
MySQL Version 5.5.45-37.4-log

Maybe there is some setting in php.ini that is responsible for the stripslashes thing you mentioned?

In class-yikes-inc-easy-mailchimp-extender-admin.php on line 4937 I’ve added
, JSON_UNESCAPED_UNICODE
This is the block that starts from line 4925 with
$error_settings = json_encode(
and that fixed things both in DB and the frontend.

The problem is that I’m not sure whether this “fix” is flawed somehow and won’t have any unforeseen side effects.
And another problem is that I’ll have to re-apply it every time you release a new version of the plugin…

That’s weird.
I thought the problem might be in json_encode but it could be something server related.

Could you take a look at the contents of the error_messages DB field for that form?

It doesn’t matter – anything written in cyrillic will trigger the error – for example Кирилица.

It shows fine in the messages editor in the form options even after the form has been saved but it doesn’t work on the frontend.

You can easily reproduce the problem by adding this text to the success message and the form description, and compare their contents in the DB after that.

I’m not really sure that gettext would be helpful in this case because the message needs to be different depending on the table data processed during the export and from what I gathered from the tablepress code the export itself occurs after the table has been saved and the message has been rendered (not really sure about the last one, though).

Guess, I’ll have to send the message through mail if what I’ve described above is really the case.

Thanks again for the help and also a big thanks for developing tablepress and the export plugin – they’re really awesome!

Does the plugin require any particular PHP extensions or any special server configuration in order to work?
I’ve made a clean install with vanilla WordPress (with the 2015 theme) and the latest github version of the plugin on a few different machines and the results were mixed.

On OpenShift (RedHat) and a Ubuntu VM of mine everything works fine, but on 2 different shared hosts all the problems I mentioned above occurred, which leads me to believe something server related causes the problem.

On all the installs I’ve done the following:
– change the permalink structure to /%postname%/
– upload the plugin’s zip file, taken from github
– change the plugin settings the following way:
https://anonimg.com/img/90c88f1c0611b0fe03b82d8a143140e8.png

– create a new menu from Appearance -> Menus, set it as primary and add the home page, the sample page and the language switcher
– go to the home page for the first time and see whether it works
– delete the cookies in order to repeat the test (the results are always the same)

After doing the tests above I deleted all the WP files and DB tables from all the hosts and repeated everything one more time with absolutely the same results.

On the hosts where the problem occurs the cookie is being set right and after a refresh everything works fine, which means the part of the code that handles the URL rewrites probably doesn’t receive the current language value for some reason.

Thanks,
Now the error is gone but three new problems appeared:

1) I’ve added the language selector to the main menu of the theme and the flag for the current language is not displayed.
This is the content of the image tag:
<img src="https://lecheniebg.com/wp-content/plugins/qtranslate-x/flags/">
When I hover over the menu all the available languages in the dropdown have their flags showing.

2) When the option “Hide URL language information for default language.” is not enabled (and “Detect the language of the browser and redirect accordingly.” is enabled) the automatically selected language is not added to the URL.
The URLs are generated by this option “Use Pre-Path Mode (Default, puts /en/ in front of URL). SEO friendly” but I suppose the same thing will happen even if I select “Use Query Mode (?lang=en). Most SEO unfriendly, not recommended.”.

3) All the links in the menu are stripped of their href attributes (except for the ones that change the language).
After I change the language the links are working again.

I guess all the problems are caused by an empty value for the current language variable, but I don’t know the code that well in order to fix it myself.

I’ve tested it by downloading this file https://github.com/qTranslate-Team/qtranslate-x/archive/master.zip and replacing everything on the hosting with its contents but the error is still there.

Perhaps you didn’t delete the wp_qtrans_front_language cookie when testing the fix and that’s why it’s working on your end?