olliontheroad

Excellent! While the post had just appeared and @wocmultimedia already replied to it, I just got the message that the post is now held for “moderation”. I guess wordpress does not like it if you show alternatives to their system.

Well I have found a solution but I guess you’re not gonna like it.

I realized that I had to do a lot of work anyway to fix this broken plug-in and since it is already the 2nd abandoned plug-in I had to deal with in a relatively short time, I decided to fly solo and abandon WordPress altogether.

It wasn’t actually that hard from a technical point of view:
1) check the page source of your page, rendered with Word press.
2) Copy paste the header part into something you can call header.php and the footer part into something called footer.php. In my case header.php extends all the way to “<div class=”post”>” (I have only static pages) and the footer starts with the closing tag of the “post” div.
3) For the actual pages your templates looks something like:

<?php
include('header.php');
  <div class="post-header">
	<h1 class="post-title">{$page_title_from_language_file}</h1>
   </div><!-- .post-header -->
   <div class="post-content">
	<!-- here goes your actual page content. E.g.: -->
     <ul>
       <li>{$item1_from_languag_file}</li>
       <li>{$item2_from_languag_file}</li>
     </ul>
   </div><!-- .post-content -->
include('footer.php');
?>

That’s it! I also have some general init.inc.php which I include before the header.php and where I declare some global variables and do the language detection, load the language.php file, and set the language in a cookie, etc. Then just go through the css file and kick out the stuff your don’t need, save whatever you need from the functions.php and your’re done. If you have some other plugin you like (I had a contact form) google for the name and they often offer normal PHP versions as well (if not just go to the wp plug-in folder and copy what you need).

I have about 15 pages in 6 languages, so I had to manually go to every page in the WP admin panel and copy-paste any language string into the respective language file. This was the most time consuming I would say. But once it was done, it works like a charm.

My language files are called english.php, french.php etc., and I load them ahead of header.php so all the language strings (page title, and page content) are in there. It is also leaner as you only load those strings you need and not 1 massive string containing all languages as with qtranslate. Plus no database lookup.

You can do this as follows. Say you are in a page called about.php, and the user uses french (which you have detected already) then the template would look like:

<?php
define('ABOUT_PHP', true); // this is an indicator so you only load the language strings needed for this page
require 'lang/french.php';
include(header.php') // etc. as above

in french.php, you have:

<?php
/**  French language strings  *********/
$lang_code = 'fr-fr'; // for html tag
$lang_dir = 'ltr'; 

// some common lang strings
$lang_yes ='oui';
$lang_no ='non';
$lang_java_disabled = 'Vous avez actuellement JavaScript désactivé. Pour que cette page s\'affiche correctement, vous devez activer JavaScript ou au moins autoriser les scripts de notre domaine.';

// now the page specific stuff 

if (defined('ABOUT_PHP')) { // this ensure that you only load the language strings you need
$lang_page_title = 'Page title in French';
$lang_about_php = array(
  0 => 'Section title in french',  
  'intro' => 'Some page intro',
  'figure_caption' => 'A figure caption',
  ....
}

and so on … for all languages and all pages

OK, it took me about a week to do it all and have it (for now) bug free, but going multisite with WordPress would have also taken me several days. On the plus side:
– the page loads much faster now (no more database lookups, no more WP baggage, no more plug-ins phoning home)
– instead of having to constantly find workarounds to WP’s architecture you simply design your site how YOU need it, which allows for much better customization.
– You are safe from future WP architecture changes and abandoned plugins as you are in FULL control of your site now.

As I said, it is some work, but if you know a little coding, it is totally worth it. I originally went with WordPRess as I wanted a CMS that got me started quickly, took take of updating the code and functionality to the latest PHP standards, patched any security issues, and provided some basic SEO. But after several years with WP I realized that I basically know everything they are doing in terms of SEO anyway, plus in terms of security, I trust my code more than having to blindly trust some plug-in who maybe spies on you or your visitors.

It’s not that hard really, and what you don’T know, you google. If you have a small site and don’t know php, you could simply copy-paste the page source of each page you have into someting called index.html and store in in the same directory structure on your server as the virtual one used by qtranslate, e.g.,
yoursite.com/en/your-page/ yoursite.com/fr/your-page/ etc. (just need to edit the .htaccess file).

Sorry, this is not really a solution to the qtranslate issue but it solved it for me.

• This reply was modified 7 years, 2 months ago by olliontheroad.
• This reply was modified 7 years, 2 months ago by olliontheroad.
• This reply was modified 7 years, 2 months ago by olliontheroad.

@wocmultimedia: your website has no widgets. The problem is the version of wordpress not the version of php.

This plug-in has been abandoned by its owner

Hi weigertj,

ok thanks for the tip. I had tried that plugin on a dummy database and it seems to leave the English version intact. But considering that I manually need to copy-paste all other languages into new pages anyway, I might as well do that for English too and not risk have the plug-in mess up the database in some unforeseen way. For now (i.e. before the glorious Gutenberg editor ruins it entirely), you can use an html text widget and use the language tags directly in there, like: [:en]Enlgish[:fr]French[:de]German[:]. The normal text widget will give you an error but in the html formatted text widget it works. For now …

WPML looks good but it’s not free and just another plug-in, so after my experience with WordPress and abandoned plug-ins, I was actually thinking to drop WordPress altogether and move to a stand-alone site. It’s actually not that hard I think and this would not only make the site leaner, as you get rid of all the excess WordPress ballast, but it also means less maintenance … funnily enough.

While the reason to initially go with WordPress was to save time, i.e., to have the CMS automatically adapt to new web standards and SEO requirements, etc., with all these pointless changes to the core code (à la Gutenberg), it has the opposite effect now. Having to constantly adapt my site to these changes is a big fat waste of time. Plus I 10 times prefer to edit my webpages in UltraEdit or Sumblime rather than in this useless WordPress editor which has no syntax highlighting and where you need to install a plug-in so you can insert PHP code (I mean really?!?).

Well, this has turned into a bit of a rant, but as a sole business owner, I actually do have to spend some time on running my business rather than managing a CMS that should be managing itself, so v4.9 of WordPress will be the end point for me …

Good luck with WPML …

@phil-beckershoff
BTW, I just tried it on another site I have, using a clean install with an unmodified hemingway theme and no other plugins and it is definitely broken. Which theme do you use Phil?

One fix I found is to include the language tags in the widget body like so:

[:en]Testing English[:de]Testing German [:fr]Testing French[:es]Testing Spanish[:]

It’s ugly, but at least it works and you can still edit your widgets.

Hi Phil,

so you are running 4.8 and when you are in appearances -> widgets and you change the content of a widget body, the multi-linguality is preserved?
Just to clarify, my widgets are still displaying the different languages in 4.8, I just can”T edit them anymore as all other languages would be overwritten by whatever edit I am making.

If you can still edit yours that is good news. This would mean that I should simply identify a problem in the theme and fix it. I did alter my themme considerably, so perhaps this is the reason. I am using a child of the hemingway theme. Cheers

BTW, I am not offered to update to 4.9. Does anyone have any experience with this? While I can no longer edit my widgets in 4.8, at least they are still displaying all the different languages, how about in 4.9? Thanks.

Yes indeed. Bummer. I have just seen in all the review comments that I am not the only one with this problem. This sucks since this plugin has basically no uninstal function so just disabling it will leave the database in a big fat mess.

Rather than rolling back and being stuck on an old relsease of WP, are there any hacks out there to bring back the widget functionality? Does anyone know what has been changed in WP 4.8.

Or are there other plugins that replace qTranslate-X and that can simply update the database to their syntax?
Thanks again for your coomments …

Well it seems that I am not the only one who is bothered by the standard setup of the WP editor as there are dozens of plugins which turn the text editor exactly into what people seem to expect it to be … a plain text editor that does not alter the code you enter!
For me the problems was solved by installing the “PS Disable Auto Formatting” plugin. You may get some surprises as content that previously looked good, now may require you to manually add all the <p> and
tags in places, but once that’s done, you have an editor you can work with.