Display language tabs issue when visual editor mode is active

[smiddus]

When enabling 'Display language tabs' under ACF qtranslate settings I get the following behaviour

1. When the page editor is in 'visual' mode (Classic editor):

• Click on language switch button of an ACF field
• Language mode changes correctly, but
• Page scrolls up all the way to the page editor
• The editor mode changes from 'visual' to 'text'

2. When the page editor is in 'text' mode: everything works fine

(qtranslate-xt 3.9.3, ACF Pro 5.9.5, WP 5.6)

[herrvigg]

I've never used 'Display language tabs' but I can reproduce this. I thought it was easy fix but it's not the case. Maybe not so urgent since this feature can be disabled and ACF/QTX should still work without this.

[smiddus]

I understand. Thanks for checking!

Any idea where I should start looking to fix this? I may give it a try, since I find these tabs very handy especially on somewhat larger ACF layouts:

a) To see in what language you are currently editing (unlike WPML, qtranslate doesn't have a language switch button that is always in sight)
b) To edit/translate a single field. Now you have to scroll away from the field to switch languages, and then find the field again.

The current bug will be too confusing for clients though.

[MK-RD]

... /wp-content/plugins/qtranslate-xt/dist/modules/acf.js

SEARCH
t('.qtranxs-lang-switch[lang="'+a+'"]:first').trigger("click")

REPLACE
t('.qtranxs-lang-switch[lang="'+a+'"]:first').trigger("click"); return false;

@herrvigg [SCRIPT_DEBUG] Is there a way to disable this distribution process?

[herrvigg]

That seems to fix it, thanks! New patch available.

[SCRIPT_DEBUG] Is there a way to disable this distribution process?

What do you mean by "disable"? The new JS framework is a billion times more powerful! I've been working on it for several weeks to make it work 😅

See #990 for all the instructions (I will update the Wiki later). If you need debug scripts just run npm run dev to get the equivalent of the old SCRIPT_DEBUG but now it's way better with modern JS and source maps for breakpoints and so on. The old scripts were impossible to maintain. In reality SCRIPT_DEBUG is only to debug WP (but i'm quite sure they will drop this soon or later for equivalent distributions and builds).

[herrvigg]

Example of devtools with the source map on that case (after local build with npm run dev):

[herrvigg]

For precision, the dist folder is not meant to be touched manually. You should always update the source JS in admin/js/ or modules/acf/... then run:

• npm run build -> update dist srcipts with release versions for productions
• npm run dev -> update dist scripts with debug versions

[MK-RD]

First of all, thank you for your answer!

Please don't get me wrong if I think that these changes have created a lot of new unnecessary dependencies. In addition, the core functionality could be provided in a single script (70% less code) with a new (API) and a legacy interface. But what do I know.

Based on the previous version, I was able to resolve many upcoming problems in active production environments, but some of them no longer work.

Believe me, I know what kind of work is behind it and since the primary responsibility for this project rests with you, it is especially important that you are satisfied with it.

Best regards.

[smiddus]

Thanks for fixing this. Happy to see that qtranslate is being kept alive!

[herrvigg]

Based on the previous version, I was able to resolve many upcoming problems in active production environments, but some of them no longer work.

What kind of tools are you using? Moving to a new framework for Javascript was very much needed. Until now we had old-school code from the 2000's that was impossible to maintain or evolve.

I think that these changes have created a lot of new unnecessary dependencies.

What kind of dependencies are you referring to? Difficult to be more standard than Babel and Webpack, that's very widely used. This is only for build time. There's no more dependency at runtime, it's exactly as before.

In addition, the core functionality could be provided in a single script (70% less code) with a new (API) and a legacy interface

Do you mean source code or distribution? Having a single source script is not viable on the long run, it's a hell for the coders when the project gets bigger. Indeed this was a blocker for developing new features.

For the distributions it's currently as before but I will actually go the other way, I want to reduce the number of distributed libs. The new code in production should actually be smaller, Wepback give much more control for minification and support of future features with polyfills and so on.

The API is almost exactly the same as before! All the functions that were supposed to be the interface are still there. There will be breaking evolutions in next versions for sure.

[MK-RD]

It was not my concern about these choices per se.

I thought that for simple requirements should also use simple solutions.
Especially when you are dealing with WordPress.

Maybe I've just been doing this for too long.

Hey, the most important thing is that we look forward with good humor :-)

[MK-RD]

I think that was asked before.

This is also currently to be considered as a quick solution!

I also have more for other areas such as "Screen Options" ...

$('#message a, #sample-permalink a').each(function () {
    this.search = '';
    var href = $(this).attr('href') + '?lang=' + language_code;
    $(this).attr('href', href);
});

[herrvigg]

What was the last snippet for?

I thought that for simple requirements should also use simple solutions.
Especially when you are dealing with WordPress.
Maybe I've just been doing this for too long.
Hey, the most important thing is that we look forward with good humor :-)

Sure! I really appreciate your help, this project is quite huge and I only do it on my free time. I can't do it alone, especially with all the integration that is often very specific.

I was just wondering what you were using. I'm 100% for simple solutions, there is a lot of legacy code in qTranslate that is really spaghetti code impossible to maintain. I've been simplifying a lot of code.

Regarding the new JS I'm really happy with the new solution, this is so much easier to use than before and the code is now readable and open to evolutions. You will perhaps understand it later ;) Webpack is perhaps not the simplest tool for simple setups but I've been using it for a while now and it's the most customizable bundler. The current setup is really minimal but it's going to be extended, we can do much more now.

I also encourage you to try the new build system. You should consider the dist folder in git as a default distribution for production. On the dev side, nothing prevents you from building your own distributions with different types of releases and debug information to find the bugs. Once fixed in dev mode you switch back to prod releases. This is a billion times more flexible than before.
https://webpack.js.org/configuration/devtool/

[MK-RD]

Thoughts!

My gut feeling is already alarming me that all the so-called solutions (fixes, workarounds) will become a problem.

There is a sub-area which, viewed in isolation, can be implemented completely independently - the application programming interface, which should be available system-wide.

WordPress itself as well as extensions will constantly change (versions) and should be viewed as modules.

The API could take care of core tasks such as configuration, language switching and auxiliary functions.

Actually just a plain Javascript object that provides the core functionality.
Basically simple string manipulations. Maybe even without jQuery.

Is there any documentation about the current interface for Javascript?

[herrvigg]

The JS API for us is the qtx object. See all functions documented with "Designed as interface for other plugin integration" in https://github.com/qtranslate/qtranslate-xt/blob/master/admin/js/core/qtranslatex.js

With internal refactoring the API does not change. This is what I've been doing constantly, preserving most of the API to not break anything. At some point evolutions are necessary though, leading to breaking changes.

qTranslate does much more than string manipulations. It's the hook management and the integration with TinyMCE and Gutenberg that is the most challenging.

Also, it's not enough to reason just about the API. Many difficulties come from asynchronous events and the complexity is to integrate all components making many assumptions. WordPress is a very messy environment because it's open but this is also what gives its flexibility. This is another reason for cleaning the code to have a better control on the flow of events.

[MK-RD]

I totally agree, but not every developer needs to deal with the module (WP) such as Gutenberg and TinyMCE.

That's your job :-)

An API globally accessible in the whole admin area allows all developers to implement individual concepts.

Such an (experimental) implementation can take place completely independently!

Do we want to develop this together or should I implement this myself in advance?

[herrvigg]

What's the exact need? We have already a "global" API, it's the qtx object but you have also a few qtranxj functions exposed.
For common usage you should not have to worry about TinyMCE or Gutenberg, this is mostly handled internally. I don't see why you write every developer has to deal with that, it's not the case.
Currently the JS API of qTranslate is mostly meant to deal with the switching buttons (LSB). There's already a lot of features available. If we need new features, the API will have to evolve for sure.

[MK-RD]

All right, I think the initial issue (smiddus) has been addressed.

[herrvigg]

Yes the discussion diverged but if you have some ideas of API improvement you can open a new ticket or submit a PR.
But first take a look at what already exists, there's quite a lot.
I'd rather want to simplify that API by eliminating functions that are not used.