MLP - The Multi-Lingual Publishing Pack

Bloke · 2013-02-11 17:46:07

Thanks to Jonathan’s in-depth feedback and testing (when I eventually got the e-mails after a rather daft snafu on my part) I traced a lot of the issues to one simple problem: table synchronisation.

Essentially, when you edit an article on the admin side, Textpattern saves the details in the regular textpattern table and then duplicates this information into the relevant 10n_txp_<language_code> (rendition) table. Thus the MySQL definitions of all the tables must match pretty much exactly.

In Jonathan’s case, while using glz_cf, a new custom field had been created — custom_11 — but that change was not reflected in the renditions tables so MLP was throwing its toys out (silently of course).

Regardless that the problem came about because glz_cf did some weird things with the custom field values which permitted two custom_4s to exist(!) the fact that MLP didn’t detect the change was, I felt, a bug.

So last night I tried a different approach. Instead of reacting to glz_cf directly I’ve taken a more generic approach and MLP now monitors the textpattern table on every admin page hit, watching for any changes. Any time it finds something different, on the next admin page click it compares the definitions of both tables and tries to automatically alter the rendition tables to match.

This will hopefully make the pack easier to maintain because it’s not tied to “catching up” on specific plugins. In theory, any plugin that modifies the core’s table will be detected and handled by MLP without any intervention. And so far in my testing it works a treat.

There are limitations at present; most notably regarding Indexes: it does not synchronise those, so things like wet_haystack will not trigger MLP to do any alterations. It probably should, but making the necessary SQL statements up automatically is a bit more challenging so I’ll save that for another day (whether or not the indexes matter when synchronising tables is something I have not yet investigated).

The upshot is that the master branch that will very soon become the new version needs some testing so, please, if you have the ability to run it through its paces, please check that (for example) any changes you make in glz_cf are reflected in the rendition tables within one or two admin-side clicks (any tab except Plugins) and, more importantly, that article saves continue to work.

The fact remains that glz_cf is still a little flaky at times under certain conditions so what I may actually do is fork glz_cf anyway to fix the remaining couple of corner cases and also add sopme callbacks in there so other plugins (not MLP in this case) can react to changes immediately. Still thinking about that one.

In the meantime please leave feedback on the above aspects of MLP here if you can. Thanks.

Last edited by Bloke (2013-02-11 17:46:53)

ru · 2013-02-11 21:19:07

hello bloke,

i found another bug.

to reproduce it you need:

a category
some articles in this category
(i tried it with category1)

now, rename the category.
the textpattern table gets updated as expected (every thing looks fine at the txp interface)
but if you take a look at the localized table or the frontend, all articles where being removed.

if you save this articles again – via editing or the renditions tab – they appear again at the localized table.

this bug is present in version:
txp: 4.4.1
mlp: 4.0.3

as well as in the masterbranch @ 9c1d1559ce

ru

Bloke · 2013-02-12 22:53:57

ru wrote:

rename the category

Yikes! That’s a huge hole, thanks for spotting it. Looks like that functionality has never been part of the pack so I can assume you must be the first person who’s ever tried to rename a category :-o

New bit of sticky tape applied. Please let me know if it works, and thanks for testing.

jstubbs · 2013-02-13 00:50:17

For reference, I just tried to change the section title (for the default language) in the current MLP version (on the site we are working on Stef) and pressed save. Looked ok in the DB and on the front side.

Then I changed the section name – and the URL returns a 404. Changed the section name back to the original name and all is good again. So, seems this behaviour also applies to sections.

Bloke · 2013-02-13 00:54:47

jstubbs wrote:

So, seems this behaviour also applies to sections.

Strange, because there was already a handler for section name alterations. I just hijacked it for categories too in the changes I just made.

If the section name changes are not being picked up (i.e. the ‘Section’ columns in the rendition tables are not changing as well as the one in the textpattern table) then that may be some other issue. The code in the master branch works as far as I can tell on a clean install, so if this site doesn’t work with that version I’ll have to poke around and see what else might be affecting it.

jstubbs · 2013-02-13 01:14:01

Stef – probably you should take a look (its on the site using the IP address). I did not upload after your latest commit – just wanted to test on the current version (or whatever version you placed on the site) for info purposes. Sorry for the confusion.

roughnecks · 2013-02-18 13:17:28

Good day,
i have a git clone for MLP and today i pulled from it and found a lot a changes; i’d like to ask a question.

commit e3aed2642b1715839ede91163ad027eeabb6f179
Author: Stef Dawson <commit@stefdawson.com>
Date: Sun Feb 10 15:44:44 2013 +0000

Remove compiled plugins from source tree. Their presence merely adds confusion. Plugins will be manually packaged into the zip for official releases.

Sorry, but, what zip are you talking about? Won’t git have the .txt files to install plugins, anymore?
How am i supposed to use the source files? Just copy the .php into my webserver like the “textpatern/..” stuff?

Now, i saw that, since my last pull…

plugins/sources/l10n.php | 38 +-

that ^ was updated
In my plugin section i see a 4.5.2 version of it… do i need to update or have to wait for an official release? Isn’t it official?

Thanks

Bloke · 2013-02-18 13:56:36

roughnecks wrote:

what zip are you talking about?

The git tree houses the source code only now, not the compiled plugins. The reason is that the compiled plugins aren’t “source code” as such so it puts extra burden on me to:

bump the version number
update the docs
package up the plugin(s) as .txt files
commit all files to git

Arguably the docs should be done at the same time (ahem), but to do all those steps for every commit I do that alters the l10n and gbp_admin_library plugins is time overhead I could do without.

So what happens now is that those steps are only done for official releases (available from my site or txpforge), not for in-development features and fixes that are in the git repo.

If you want to try out such plugin code then by all means:

Backup your database/filesystem.
Open the .php file(s) from the /sources folder.
Copy the code between BEGIN PLUGIN CODE and END PLUGIN CODE markers.
Visit Admin->Plugins in your Textpattern site, click to edit the plugin code.
Paste the source over the existing code and Save changes.

(EDIT: or use ied_plugin_composer: the 1.00 version allows you to upload .php files directly to replace existing plugins. I’ll upload a newer version of the composer later today because there have been a few fixes since I last uploaded a copy in September)

The version numbers and docs may not tally up until I ‘catch up’ and make an official release, but the code will be the latest in-development version so you’ll be able to test the new features and fixes to provide valuable feedback for me.

Hope that clears things up.

Last edited by Bloke (2013-02-18 14:00:44)

roughnecks · 2013-02-18 14:19:15

Hey Bloke, hi :D

Let’s summarize a couple of things:
links

txpforge <— This is the official reference (?) So, why does it links to “Homepage: http://txp-plugins.netcarving.com/plugins/mlp-pack” which is dated 2011 if i am correct: i assume netcarver was the first developer, still informations and link should probably be up-to-date.
The file sections of txpforge has a “mlp-4.5.2.20121204.zip” release: the git repo has newer files: which one should i follow?

About your blog, i can’t even find the page about MLP in the plugins/ directory at “http://stefdawson.com/sw/plugins”: maybe today is not my day :-)

The textpattern plugins page is outdated too, as far as i can see: Multi-Lingual..

Ok, last ones:
git

There are two git repository about MLP and google seems to like better the old one:
netcarver-one
Bloke-MLP-one

I know google is not a problem of yours, still i was puzzled by this situation. Looking for correct informations about MLP seems to be an impossible mission. The only place i am sure about, is this forum.

And sorry for the rant: i just hope MLP can improve.
Greetings

Bloke · 2013-02-18 14:50:52

roughnecks wrote:

txpforge <— This is the official reference (?)

Uhh, it was. Then Graeme (who set it up) and Steve (the original author of the pack) moved on and I took over, shifting the source code to github for (my) ease of development.

What we really need is to sort the whole mess out and as you say make sure all the links work.

I don’t have an MLP section on my site because I just haven’t got round to doing it. I hosted the latest couple of downloads of the official pack zip file there simply because I lost my txpforge credentials and also haven’t fixed up textpattern.org properly: as you noted, the info there has started to get old, I’ll try and update that later today.

As of today:

The most recent development version is on my github page.
The most recent “official” version (albeit with a few bugs that have since been fixed in the github repo) is the one linked from txpforge and the opening post of this forum thread.

A further spanner in the works is Textpattern 4.6.0. When development of that moves on a little I’m hoping that MLP can actually be re-engineered in a more robust way using some new core features we have planned. That will hopefully make it less of a hack and more of an actual plugin. All speculation right now but I’m hoping we can gradually phase out the current MLP and start afresh with something more sustainable and powerful. As soon as I have more information on that I’ll post it.

In the meantime we’ll see about updating the info on txpforge to make sure it points to both the development version and the current ‘official’ version, plus put some of the details from these recent posts about how to use the different versions. Maybe Els or maniqui could help me out here as I’m pushed for time this week (pretty please?) For the time being I’ll try and make sure that becomes the de-facto place for all things MLP. When I finally get textpattern.org ready and 4.60 is released, that will probably become the official place for the new version and we’ll pull the txpforge MLP down, leaving “official releases” on textpattern.org and “development” on github.

Last edited by Bloke (2013-02-18 14:54:37)

roughnecks · 2013-02-18 14:54:45

Thanks Bloke, have a nice day.

wornout · 2013-02-26 14:29:29

How can I show more that article title, section and author in mlp article list?
For example add a custom field…

Last edited by wornout (2013-02-26 14:30:08)

Bloke · 2013-03-02 09:59:02

wornout wrote:

How can I show more that article title, section and author in mlp article list?

You mean in a public-side article list? Don’t you just use <txp:article_custom> with a form or container? Must admit I’ve not done it for a while.

jens31 · 2013-03-04 16:51:25

hi

i just placed a facebook og:url tag in the header and used the txp:permalink in there. that did not work, the permalink did not include the language “suffix”.
guess mlp only does modify the permalinks in the body area?
worked my way around with if_language & rah_replace, but wanted to report this behavior..

<meta property='og:url' content='<txp:permlink />' />

Bloke · 2013-03-04 17:08:41

jens31 wrote:

the permalink did not include the language “suffix”. guess mlp only does modify the permalinks in the body area?

Interesting, thanks for raising this point. It seems that permalinks don’t get the language marker at all regardless of where it appears on the page. I hope that’s not a bug I’ve introduced *panic*.

Can anyone confirm if the <txp:permlink /> tag ever included lang markers? I suppose it should or else you wouldn’t be able to direct someone to the language-specific URL if you’re not using a scheme that includes the ID in the URL.

I notice that if you follow a non-designated language URL then it serves you the page in the last visited language, or the default/browser language if you’ve never visited. If you have a lang switcher on the page it’s only one more click to switch to the native version but it’d still be better if the permlink was correct in the first place. Hmmmmmm.

Last edited by Bloke (2013-03-04 17:09:02)

Textpattern CMS

Textpattern CMS support forum

#2191 2013-02-11 17:46:07

Re: MLP - The Multi-Lingual Publishing Pack

#2192 2013-02-11 21:19:07

Re: MLP - The Multi-Lingual Publishing Pack

#2193 2013-02-12 22:53:57

Re: MLP - The Multi-Lingual Publishing Pack

#2194 2013-02-13 00:50:17

Re: MLP - The Multi-Lingual Publishing Pack

#2195 2013-02-13 00:54:47

Re: MLP - The Multi-Lingual Publishing Pack

#2196 2013-02-13 01:14:01

Re: MLP - The Multi-Lingual Publishing Pack

#2197 2013-02-18 13:17:28

Re: MLP - The Multi-Lingual Publishing Pack

#2198 2013-02-18 13:56:36

Re: MLP - The Multi-Lingual Publishing Pack

#2199 2013-02-18 14:19:15

Re: MLP - The Multi-Lingual Publishing Pack

#2200 2013-02-18 14:50:52

Re: MLP - The Multi-Lingual Publishing Pack

#2201 2013-02-18 14:54:45

Re: MLP - The Multi-Lingual Publishing Pack

#2202 2013-02-26 14:29:29

Re: MLP - The Multi-Lingual Publishing Pack

#2203 2013-03-02 09:59:02

Re: MLP - The Multi-Lingual Publishing Pack

#2204 2013-03-04 16:51:25

Re: MLP - The Multi-Lingual Publishing Pack

#2205 2013-03-04 17:08:41

Re: MLP - The Multi-Lingual Publishing Pack

Board footer