Problem with SiteOrigin PageBuilder

Hi @alexgso, I am very glad you chimed in, your input can make the things so much easier. I assume you are familiar with the document https://qtranslatexteam.wordpress.com/integration/, which actually needs to be extended and revised especially in case of SiteOrigin PageBuilder, but one may get the main idea of integration approach, which is apparently the only correct approach for an ML plugin, since it is impossible to make any ML plugin work with any other plugin/theme out-of-box. qTX needs to know which fields are supposed to be multilingual. Such information can only be provided via an integration configuration.

Integration also allows to inject custom JS scripts, which should make it possible to handle “gather data” method.

Please, understand that qtx is not “done” plugin, it is a work in progress, and the things get improved basically every day. Our final goal is to make it completely flexible, so that any plugin can be integrated easily enough. It is the authors of 3rd-party plugins and themes who can make integration in the most efficient way. We hope that when documentation and good tutorials are finalized, the authors will start taking care of such integration themselves, like they do it now with static internationalization via po/mo file framework.

At the end, any integration results in a .json configuration file and possibly a few JS scripts, which are placed in the root of plugin’s distribution. Usually, there is no need to modify the code of 3rd-party plugin, with a rare exception of really non-standard implementations. Even if some modifications are needed, they are normally cosmetic, simply better PHP code regardless qtx, and they do not affect performance of the plugin in the absence of qtx.

There are a few plugins which work via “gather data”, which have already been successfully integrated. I will look up the names later, do not have it handy right now, but the point is that usually it requires a little bit of JS code. qTX allows custom JS code and provides appropriate hooks.

With that said, @alexgso, would you consider helping us to integrate your plugin? You would need to teach us a little bit on the details of how SiteOrigin PageBuilder works. I understand that, at this point of incomplete documentation, it would not be fair to ask you to do the whole thing, but once it is done, and integrating configuration files are ready, I think it would not be difficult for you to keep maintaining them in the future. These files would have to be included in your distribution, but will only act in the presence of qtx, without hurting anything else. They would need to be adjusted in the future only if you decide to update the core design, which should not be a frequent case, if it ever happens at all.

Here is the plan.

1. (maybe @femorais would not mind to do this step?) Turn off qtx. Enter some data in SiteOrigin PageBuilder using Raw ML format and save it. Now turn on qtx and see if it works properly at front end. Do not make any changes on admin side yet, when qtx is on. If Raw ML shows up at front end, we will need to find which filters to employ to translate those values at front end. I guess, it should not be difficult for @alexgso to provide an answer to this question then.

It could be a case that it is sensitive to which ML encoding is in use. Please, try both ‘[:]’ and ‘{:}’, but thy them one at a time, I would not mix them.

2. Find out which tables and fields in db those ML fields end up to be stored in. I hope @alexgso can easily answer that. Do those places survive preserving language tags like ‘{:xx}’ and ‘{:}’? This information is needed to understand how to do integration in a best possible way.

3. On admin side with JavaScript. This is where @alexgso can help a lot. qTX needs to know how to re-load a different language using JS. Usually, a builder plugin uses JS to load the standard WP data to their own framework. Is there a function like load_builder_data, which qTX can call when language needs to be switched? There is also a need for save_builder_data, which puts data from the builder’s framework back to WP standard fields to be passed back to WP. Normally developers of builder plugin do not think about having a single clean function to re-initialize the whole thing or to save the whole thing, since they need to do it one time only on page load and on page saving. qTX needs to do it on a press of an LSB button. qTX provide two hooks, for ‘save’, which is called before a language switch, and ‘load’, called after the switch. In most of the cases, a plugin has a few functions to be called in each case ‘load’ or ‘save’. Whatever it is we need to know how to implement ‘load’ and ‘save’, and that part is usually the most time consuming to figure out.

It would be very helpful if @alexgso can tell us which his plugin’s functions need to be called to achieve ‘save’ and ‘load’ in JS. We will take care of the rest.

It could be a case that the builder does not use standard WP route to save/load its data. In any case we need to know all the details how exactly it is done, which can be figured out from the code, but it would save a lot of time if @alexgso tells us such details.

4. If the things get overly complex, and the integration also needs applying some custom filters or actions at admin side, then we would need to implement a separate iteration plugin instead of using simple configuration files. We will know once we learn the details of how SiteOrigin PageBuilder works.

Is that what we all would be willing to do?

Thanks a lot in any case!

Yes, @femorais, you can do #1 and let us know the result. Yes, testing site where we all could login would also simplify communication a lot.

I have not tried it yet at all, but I see that page https://qtranslatexteam.wordpress.com/incompatible/ says that Raw ML format simply works with SiteOrigin:

It works, if Raw ML format is used in SiteOrigin’s custom fields. I bit inconvenient, but possible to use.

Could you confirm? It would mean that the most important part of integration already works out-of-box. We would only need to figure out JS part on admin side, #3.

But it should be already usable with Raw ML, is it indeed?

Thank you, Fernando!

@alexgso, please, if you decide to help, get in touch with us via Fernando’s e-mail or our contact page or simply answer my questions here.

Thank you.