Where is the latest code to be forked?

[johnclause]

Hi Pedro (@LC43) & Carlos (@not-only-code), just a quick question, where is the version of -slug at github which I can fork to investigate?
I assume that svn tags/1.1.13 is the one currently distributed. However, http://plugins.svn.wordpress.org/qtranslate-slug/tags/1.1.13/readme.txt is different from both https://github.com/not-only-code/qtranslate-slug/blob/trunk/readme.txt and http://plugins.svn.wordpress.org/qtranslate-slug/trunk/readme.txt.

Moreover, https://github.com/not-only-code/qtranslate-slug/blob/trunk/readme.txt shows version 1.1.12. How did they get all different?

Where is the master repository, which I should use to submit pull requests to? I am trying to fix compatibility with qTranslate-X: #107

[LC43]

hi @johnclause, the latest is from tag 1.1.13, but there's a final PR that i want to push, so let me just test it and i'll make all based on the same code.

[johnclause]

Thanks, Pedro, yes, I would not be able to pr against svn tag 1.1.13, so I'll wait.

Are you doing adjusting for #107 too?

BTW, could you make detection of qTranslate-X based on 'QTRANSLATE_FILE' constant, otherwise when people test betas and install -X in a different folder, -slug stops working. This is one of the things I was going to pr too.

There is also qTranslate-Team/qtranslate-x#54, which is easy to adjust: 'qtranslate_slug_header_extended' is no longer need for -X.

[johnclause]

Hi Pedro, did you finish your move, you mentioned other day, or you are in the middle of it? I hope all is going well with you?

Quick question, just out of curiosity. Why did not you store slugs in posts.post_name field in multilingual format with tags like [:en]slug-en[:de]slug-de? This would be natural to q, would not it? Were you afraid of performance issues? I am not saying that it needs to be done in this way, I am just curious on your exact reason. Best regards, John.

[LC43]

I wasn't the author for that code, but i'll assume that yes. one of the things qtranslate was so slow was because of all the costly regexes. If you access the db, select what you need without further calculations.

[johnclause]

Hi LC43, it confirmed that the latest code of q-X from GitHub broke -slug again. If you go to any custom slug, "page not found" is shown. I am in the process of formalizing PHP integration interface and the internal code gets changing all the time. It will keep happening until -slug is integrated properly through "allowable" interface.

I see that GitHub for -slug still does not have the latest code, which prevents us from attempting to fix the stuff. I am also sure you would be able to fix it much quicker than we can. Could you take a look at the cause of the current trouble? You do not have to fix it properly for now, just tell us what it is and I might be able to put back whatever is needed for current -slug to continue working for now.

I am reluctant to release qtx 3.4 with that much broken -slug integration, since I was told that -slug works more or less fine with the current qtx 3.3.

Thanks a lot!

[LC43]

hi!

yes, unfortunatly i did a couple of fixes on the wp.org branch and never got the change to merge with this code. Its a shame too, because there were some nice additions by the contributors.

anyway, i hope friday i have some free time to check your code. can you hold on until then?

[johnclause]

Hi Pedro, @LC43: I think I found the problem in the beta qtx which broke the latest -slug. Could you try the latest from GitHub on your sites and see if it works as good as before?

[LC43]

@johnclause i've been trying to get a way to detect if your dev version is active but i found that the way wp inits the plugins is by alphabetic order. so, it will first init ours qtranslate-s(lug) and then yours qtranslate-x. that means the variable isnt defined.

what i found weird is that it wp tries to init our plugin later on. but i'm not sure why...

any help?

i'm using qtx 3.4.6.4.