MLP - The Multi-Lingual Publishing Pack

jens31 · 2013-09-02 08:49:21

kienes schrieb:

2nd i set up a 4.5.0 with versioning and mlp wich leads mit to following alert box:
Internal error “Array to string conversion”.
the error is caused by _initiate_callbacks in l10n_admin_classes and could be removed by imploding the return value of the function … is that a proper solution, or do i miss smthg?

@els had the same problem at the beginning … use this file … don’t know where i got it from …
http://pastie.org/4656059
i hope this helps

… whatever i said … wrong …
its a problem of the xampp version … if you run 1.7.3 everything is fine on 1.8.0 i get the errors …

i have the same problem, but not on xamp, but on a regular shared 1and1 hosting. php 5.4.19, mysql 5.1.71-log, txp 4.5.4 (r4919), l10n-4.5.2, gbp_admin_library-0.4.2
everytime i enter the mlp tab or switch inside the mlp tabs, i get this alert box.

any ideas?

Bloke · 2013-09-02 09:49:42

jens31 wrote:

everytime i enter the mlp tab or switch inside the mlp tabs, i get this alert box. any ideas?

My money is on the fact that PHP 5.4 (which ships with XAMPP 1.8.0) changed the way it alerts people of code bugs which would have previously been handled silently. It now throws a notice instead, which Txp passes onto the browser.

If I can track down the line(s) of code (one of which may be the one that kienes spotted) then I’ll fix it today and let you know how to do it. I have XAMPP 1.8.0 installed locally, so should be able to test it there. Thanks for highlighting this again.

Still waiting for Kjeld to get back to me on whether the fix-for-the-fix I mentioned a few posts above works, so we’re in a weird limbo state where GitHub is the most up-to-date version, but has that known bug in it. I’m in two minds whether to just go ahead and fix it today, then worry about Kjeld’s obscure error messages later by issuing a fix-for-the-fix-for-the-fix.

Bah, software!

jens31 · 2013-09-02 10:32:28

thanks for your work stef. contact me, if you need any help, testing, server access..

Bloke · 2013-09-02 15:22:43

Hmmm, can’t get it to misbehave on XAMPP 1.8.0 with the latest GitHub version so either I’ve squashed it already or there’s something else amiss. jens31 and anyone else with this issue, please would you mind reporting if the issue remains or goes away with the GitHub version plus the fix proposed above. If it’s still there, any further details about which line of code is complaining (you can get that from the error logs, with luck) would be really helpful. Thanks.

jens31 · 2013-09-02 15:27:35

yo are right, stef. everything is working fine. and didnt even uses the “fix from above”..
thank you for the support!!

EDIT
errr. too hasty. needed the fix, since it did not save my changes.. now it does.

Last edited by jens31 (2013-09-02 15:31:25)

Gocom · 2013-09-02 17:11:38

Bloke wrote:

Still waiting for Kjeld to get back to me on whether the fix-for-the-fix I mentioned a few posts above works, so we’re in a weird limbo state where GitHub is the most up-to-date version, but has that known bug in it. I’m in two minds whether to just go ahead and fix it today, then worry about Kjeld’s obscure error messages later by issuing a fix-for-the-fix-for-the-fix.

Why don’t you just use branches? Create feature branch, test it, if its okay, merge it to master.

$ git checkout -b fix-cookie-error
$ git add -am "Snoop dog ate cookies?"
$ git push origin fix-cookie-error

And then merge later on:

$ git checkout fix-cookie-error
$ git merge master
$ git checkout master
$ git merge --no-ff fix-cookie-error

While at it, can you please tag versions? Without tags we can’t really consume the code base on production. We can’t know what are releases.

Bloke · 2013-09-02 17:29:59

Gocom wrote:

Why don’t you just use branches?

#scared-i’ll-mess-it-up.

But yeah, I should do that.

can you please tag versions?

When I release a new version I will. Don’t think I’ve actually released a full ‘version’ yet since moving it to GitHub. Might be wrong, but even so I probably can’t go back and retrospectively tag them. Hmmm, or maybe I can. Will RTFM.

Gocom · 2013-09-02 17:30:29

Oh yeah, I’ve added some comments to some of your changes (commits) here and here. Just mentioning it here since you may not be getting notifications about the comments as it seems that you haven’t set your email address in git. GitHub uses the email to detect the committer. Please set your email address by running:

$ git config --global user.email "stef@example.com"

Where the stef@example.com is one of the emails you have on your GitHub profile.

Bloke wrote:

Might be wrong, but even so I probably can’t go back and retrospectively tag them. Hmmm, or maybe I can.

Of course you can, git isn’t linear. You can add tags to any commit, branch from any commit etc. You can’t safely alter existing branches’ timeline, but you most certainly can branch from it, and add tags to it. Just checkout where you want and run git tag -a, or reference a commit from the command. You can check the command syntax by running help and asking the man.

$ git tag --help

Last edited by Gocom (2013-09-02 17:38:05)

Bloke · 2013-09-02 17:54:59

Gocom wrote:

I’ve added some comments to some of your changes

Thanks. I only did the session/cookie shit because yab_shop and a few other (probably not-currently-maintained) plugins caused the PHP_Incomplete_Class error which I presumed was MLP’s fault. As you have mentioned, cookies are not functionally equivalent so I’ll need to find a better way to manage sessions.

Honestly, I’m just biding time here until I can scrap this whole mess and start again under 4.6 with better support for Textpacks and the meta store. But I’m not starting anything until some of the new stuff is in core.

You can add tags to any commit

Cool, thanks.

Last edited by Bloke (2013-09-02 17:55:38)

maniqui · 2013-09-02 19:00:30

Gocom wrote:

And then merge later on:

$ git checkout fix-cookie-error
$ git merge master
$ git checkout master
$ git merge --no-ff fix-cookie-error

Chiming in to do some observations to this workflow.
The 2nd step (git merge master) seems unnecessary, as you are immediately merging the branch back to master (on 4th step). In other words, the git history will be in a better shape (ie. more readable) if you avoid the unnecessary merge commit created on 2nd step. Of course, in the end, it’s not about avoiding commits just for the sake of having nice-looking git history graphs. There has to be better reasons.
I’d guess that Gocom may be suggesting the merge on 2nd step as a way to check if any further changes on master (that is, changes committed to branch master after branching to fix-cookie-error to, well, fix the cookie error) could bring some conflicts with the “outdated” branch fix-cookie-error, allowing to solve them in the branch.

An slight improvement could be just doing the last 2 steps suggested by Gocom:

$ git checkout master
$ git merge --no-ff fix-cookie-error

I’d say that this is, technically, the same as Gocom’s proposed workflow, with the only difference that now, the conflicts (if any) are solved while “standing” on branch master. Also, the potential issues with this flow are related to branch fix-cookie-error being too outdated. But there is a solution for that (see the rebase workflow proposed below).

In any case, if anything sounds too scary, creating a temporary/disposable/sandboxed branch for integrating changes is too easy with Git.

$ git checkout master
$ git checkout -b integrate_master_fix-cookie-error
$ git merge --no-ff fix-cookie-error
# Everything went good? Cool. Let's do it for real then.
$ git checkout master
$ git merge --no-ff fix-cookie-error

Here, a new, disposable branch integrate_master_fix-cookie-error is created, then, changes from branch fix-cookie-error are merged. We use it just as a way to keep things isolated, particularly if we are afraid to f*ck things up with Git (it can happen if you are yet learning branching, merging, rebasing, etc).

Back to the original workflow, another improvement could be using git rebase:

$ git checkout fix-cookie-error
$ git rebase master
$ git checkout master
$ git merge --no-ff fix-cookie-error

Now, 2nd step rebases the topic branch fix-cookie-error on top of latest changes on master. Conflicts may arise too, of course, although hopefully not.
if you intend to use this workflow on a publicly published branch (ie. already pushed to GitHub or some server), I’d suggest you doing it just before you finished working in the fixes/features/whatever-you-were-working-at-in-your-branch. In other words, doing it only when you are closing the branch, if the branch is public. If the branch is private (or if you are not planning to push further changes publicly), feel free to use rebase as much as you want, to keep your topic branch as up-to-date as possible with changes in “upstream” (in this case, with further changes pushed to master).

Extra tip: activate git rerere (reuse recorded resolution) feature.

PS: sorry if this sounds too much like lecturing (and if it’s not the proper place to do it). But if the Bloke is #scared-i’ll-mess-it-up, I’d like to help him overcome his fears :). And happy to know that some of Gocom’s brain cells are looking at MLP :)

Gocom · 2013-09-02 20:11:49

maniqui wrote:

I’d guess that Gocom may be suggesting the merge on 2nd step as a way to check if any further changes on master (that is, changes committed to branch master after branching to fix-cookie-error to, well, fix the cookie error) could bring some conflicts with the “outdated” branch fix-cookie-error, allowing to solve them in the branch.

Yup, exactly the reason. While I’m personally in favor of rebasing too, I didn’t in advice it, since unlike merge, it’s not a command you can merely copy and paste. I did explain about rebasing in the Textpacks thread few days ago tho. As you note, you can only do it on private branches, when first pushing the branch to public or when merging back from the feature branch. Not that you can use it in the wrong way, unless you really like that --force flag. Stef, git will warn you if you actually really fuck up.

Advising to use temporary private development branches is smart. Even if you are a master git user, you may want to use the temporary step for testing. But, don’t bee too afraid about messing something up; as long as you don’t push, nothing you do affects anyone else than you.

As long as its private, you can freely alter your history and detach commits. Unless you are actually altering history, you can neither really loose your work. Normal merging and rebasing can be reverted; before you push (anything you push to origin is final in the branch it is located). If you aren’t sure about something, just create a temporary branch and test. Branches are separate, fucking up your temporary branch doesn’t affect the real one. If you want even more security, you can copy the directory.

Last edited by Gocom (2013-09-02 20:15:46)

maniqui · 2013-09-03 02:01:55

Gocom wrote:

But, don’t bee too afraid about messing something up; .

Yeah, an important point when using Git: once something has been committed, you have to try really hard to mess things up.
On previous post, I said:

We use it just as a way to keep things isolated, particularly if we are afraid to f*ck things up with Git (it can happen if you are yet learning branching, merging, rebasing, etc).

I apologize as I’ve created unnecessary FUD. I repeat, once a set of changes has been committed in Git, it’s really hard to lost it. Even when rewriting history (stuff that usually happens when using git reset or git rebase, among other commands), the garbage collector in Git keeps unreachable commits in the reflog for 30 days. In other words: if you know you committed some changes, but after having some fun (or “fun”) with rebase or merge or reset you can’t find those committed changes, don’t panic: chances are that the commits are still there, in the reflog, waiting for you to “save them” from the garbage collector.

“Gocom wrote:*

(…) as long as you don’t push, nothing you do affects anyone else than you

Or, as the rule goes: Do not rebase commits that you have pushed to a public repository.. Of course, as Gocom mentioned, the --force flag is there if you really need it, but you better know what you are doing before using it (basically, overwriting a history that other users —the “consumers” of your repo— may have already fetched). Use it with care.
^{Sorry for this thread hijacking}

datorhaexa · 2013-09-09 14:33:50

Ok, I had the ‘Form cannot be submitted’ error and did the changed Bloke has given earlier in this thread. Problem is, I don’t get an error but no changes done to articles are saved in the front-end, although they are saved in the back-end.
Does anyone have an idea what’s happening?

I am using the latest MLP with TXP 4.5.4 and Bloke’s modifications to l10n_admin.php

Bloke · 2013-09-09 18:03:19

datorhaexa wrote:

I don’t get an error but no changes done to articles are saved in the front-end, although they are saved in the back-end.

This is normally because the MLP schema (txp_lang_xx-yy tables) differs from the one in the textpattern table. They need to contain exactly the same fields, including any custom fields, and have the same ~~collations and~~ field types.

In theory, the latest GitHub version is supposed to keep track of all these (bar the error that Gocom spotted in his comments, which I need to address at some point). When you say you’re using the latest MLP, you mean the latest official or latest GitHub download?

Last edited by Bloke (2013-09-10 08:14:54)

datorhaexa · 2013-09-09 18:16:18

Stef, I use the latest official. I only slapped at line 18 the change you made and then after reading your next comment, commented the return statement. I’m actually in the dark here but noticed that on my test server the collation of the two language tables I have is different. I fixed that but still no saving after edit :-(

Let me know if I should copy all of your l10n_admin.php and replace the one I have.

P.S. I did replace my l10_admin.php with the github version and no change of problem. Interestingly, changes to articles are visible in the backend but not on the website.

Last edited by datorhaexa (2013-09-09 18:22:18)

Textpattern CMS

Textpattern CMS support forum

#2251 2013-09-02 08:49:21

Re: MLP - The Multi-Lingual Publishing Pack

#2252 2013-09-02 09:49:42

Re: MLP - The Multi-Lingual Publishing Pack

#2253 2013-09-02 10:32:28

Re: MLP - The Multi-Lingual Publishing Pack

#2254 2013-09-02 15:22:43

Re: MLP - The Multi-Lingual Publishing Pack

#2255 2013-09-02 15:27:35

Re: MLP - The Multi-Lingual Publishing Pack

#2256 2013-09-02 17:11:38

Re: MLP - The Multi-Lingual Publishing Pack

#2257 2013-09-02 17:29:59

Re: MLP - The Multi-Lingual Publishing Pack

#2258 2013-09-02 17:30:29

Re: MLP - The Multi-Lingual Publishing Pack

#2259 2013-09-02 17:54:59

Re: MLP - The Multi-Lingual Publishing Pack

#2260 2013-09-02 19:00:30

Re: MLP - The Multi-Lingual Publishing Pack

#2261 2013-09-02 20:11:49

Re: MLP - The Multi-Lingual Publishing Pack

#2262 2013-09-03 02:01:55

Re: MLP - The Multi-Lingual Publishing Pack

#2263 2013-09-09 14:33:50

Re: MLP - The Multi-Lingual Publishing Pack

#2264 2013-09-09 18:03:19

Re: MLP - The Multi-Lingual Publishing Pack

#2265 2013-09-09 18:16:18

Re: MLP - The Multi-Lingual Publishing Pack

Board footer