MLP - The Multi-Lingual Publishing Pack

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)

Bloke · 2013-09-09 18:36:00

datorhaexa

If you’re using the GithHb version you should replace all of the files, including overwriting the two plugins with the code in the repo. Once you’ve done that you can amend the l10n_admin.php to comment out my stupidity for the time being.

~~The collations would certainly have been one factor but if you fixed those~~ It’s probably something else that differs in one or more of the language tables compared to the textpattern table. But if they are truly identical in structure, you’re running the full GitHub version and it’s still giving you problems then there must be something else. If you get no joy there and wish to send me a login, I can take a look for you and see if I can figure it out.

Last edited by Bloke (2013-09-10 08:15:32)

datorhaexa · 2013-09-09 19:28:10

Stef, first thanks for the help! I will do this tomorrow on my local server and see how it goes. I’m severely restricted by the client’s sysadmin to what I can do on their server so I hope it works out.

Bloke · 2013-09-09 19:34:28

datorhaexa wrote:

Stef, first thanks for the help! I will do this tomorrow on my local server and see how it goes. I’m severely restricted by the client’s sysadmin to what I can do on their server so I hope it works out.

No worries. Let me know how it goes. I just committed the fix for the botched fix so you should be able to use the GitHub version as-is now.

Textpattern CMS

Textpattern CMS support forum

#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

#2266 2013-09-09 18:36:00

Re: MLP - The Multi-Lingual Publishing Pack

#2267 2013-09-09 19:28:10

Re: MLP - The Multi-Lingual Publishing Pack

#2268 2013-09-09 19:34:28

Re: MLP - The Multi-Lingual Publishing Pack

Board footer