next »

[madmage]

A small demo you can find in http://www.mindreamz.net/modx091/ but I would like the MODx-gurus to look at my code to know if I used the right functions in the right places (going into the core code to find out which function to use is not a great thing, maybe sometimes I used a deprecated function or something like this)

The goal was to provide a multi-language-content site, in which the user can choose a preferred language and browse the site reading pages in that language if they are available, and been redirected to a "default language page" if not.

My solution is the following:
1) there is a $_SESSION variable that stores the preferred language choice of the user;
2) I modified the *_site_content table adding two fields:
 - contentLang, that stores something like "en", "it", "fr", ...
 - refId, the id of the page in the default language which this one is a translation
3) I added a snippet to show the language flags for the user choice
4) I added a plug-in that redirects to the right-language page
5) I modified the DropMenu to show only the chosen language entries
6) I modified the manager in these ways:
 - in the document tree, each page has next to it its current translations (you can click on them and go to the translation, without the need to have a different tree for each language and to have not every page translated)
 - while vieweing a document, you can also see in which language is the content and you have a button that duplicates the page to begin to translate it
 - in the settings page you have to write which languages your site is in and the default language

The only thing that is to be implemented is a plug-in that rebuilds the tree accordingly after the insertion of a new translation (it is needed and you can easily figure out why)

Now, then, how can I show my solution? I can give to someone the access to my manager, in order to see my modifies. Or... what else?

[Djamoer]

That's so cool. I saw it already, and it's nice!

Hope I can have the right to access the demo version of it, if you wouldn;t mind. FYI, I'm not a core developer for MODx and I'm not a PHP or programmer guru, hope it doesn't bother you.

Great job in implementing that, that looks awesome. Hope it can be implemented later as the core system, by the time all the core developer agree to that, and willing to make an aoverhaul backend for MODx.

Btw madmage, you know the backend already, so do you think its going to be hard in implementing sub site capability of MODx?

Sincerely,

[madmage]

Isn't it already implemented? I read a message in which someone develop a snippet to do this... Am I missing something?

[Djamoer]

yeah, it's being implemented, but it won't work the way you want it with alias path. Let's assume that you have a folders for subsites, and each folder will have its own alias, lets call it subsite1, subsite2, and etc. Then for each subsite will have this alias being appended as alias. So the address will look like this, http://www.domain.com/subsite1/home.htm.

I just want the ability to remove the subsite1 path for each domain, without the need to use it. Do you have any thought of this?

Thanks

[davidm]

I very much like the underlying logic, if this can be made into a snippet we could have real multilingual content for MODx which would be yet another strong point for us

Very nice, can't wait to have our coding team look into this and help you turn this into a proof of concept solution for multi-lingual content... thanks !

[madmage]

mod_rewrite?

RewriteRule ^([^\/]*)\/(.*)$ http://www.yourwebsite.com/$2 [L]

or I haven't understood your problem?

[madmage]

I very much like the underlying logic, if this can be made into a snippet we could have real multilingual content for MODx which would be yet another strong point for us

Very nice, can't wait to have our coding team look into this and help you turn this into a proof of concept solution for multi-lingual content... thanks !

I hope to succeed in having a contact with some core coder... it seems hard in these days...

[madmage]

mod_rewrite?

RewriteRule ^([^\/])*\/(.*)$ http://www.yourwebsite.com/$2 [L]

or I haven't understood your problem?

this is better (remember that it have to be in the modx installation root directory):

RewriteRule ^[^\/]*\/(.*)$ /$1 [L]

[davidm]

I hope to succeed in having a contact with some core coder... it seems hard in these days...

Yeah well it's only normal given the holidays. I've no doubt they'll get in touch pretty soon, few ideas are lost around here, that's one of the strength of this community

Thanks for the login/pass for the demo : VERY NICE ! The way you integrated this into the backend is simply great and I wish to see it as one of the bundled plugin. Plus I wouldn't mind having this kind of marketing ammo Few CMS have this implemented, often it's a workaround or a hack to implement multilanguage.

Really impressive work !

[xwisdom]

I hope to succeed in having a contact with some core coder... it seems hard in these days...

Well it's the holiday season so you know...

Very nice work on the multi-language content implementation

We will certainly look into what you have done and see how it can be added to the new core.

PS. where possible it 's best to use plugins to handle your changes. There are events that you can use to overwrite most of the core.

Many thanks and happy holidays!

 

[madmage]

Well it's the holiday season so you know...

Yeah, I know... Just joking... ;-)

Very nice work on the multi-language content implementation

We will certainly look into what you have done and see how it can be added to the new core.

PS. where possible it 's best to use plugins to handle your changes. There are events that you can use to overwrite most of the core.

This is the reason for my looking for core coders... and questions about plug-in events

Many thanks and happy holidays!

Yeah, to you too...

[rthrash]

I've poked through it a bit and created a test page in the repository. Looks like a really great start!

The biggest thing that immediately popped out was how it handles the menus... that's going to take some thought... but regardless, quite impressive. Do you have a full changelog/modification procedure that you went through in order to get this implmented?

[Djamoer]

It's great to have someone who able to contribute something on the core code.

Hope this can be the start of MODx to support multi lingual content by default. Hopefully this can be added into the new release or provided as a patch to the current release.

Thanks for the reat work you've done there, especially by hacking into the core code, but still keeping it in minimum changes, and make it integrated with MODx manager so well.

Sincerely,

[madmage]

I've poked through it a bit and created a test page in the repository. Looks like a really great start!

The biggest thing that immediately popped out was how it handles the menus... that's going to take some thought...

what do you mean for "menus"? which menus?

but regardless, quite impressive. Do you have a full changelog/modification procedure that you went through in order to get this implmented?

Yes, of course! :-D

2 field to be added to site_content table
1 snippet to be added
1 plug-in to be added
1 snippet to be modified (DropMenu)
about 80 lines to be added in four manager php files

it's all tagged in my code, so I can easily find them

I have still to implement the tree rebuild plug-in (necessary when adding or deleting a translation that has children); and use $_lang[] for messages/captions in manager

for the first topic: which plug-in event do I have to use (OnDocFormSave and OnDocFormDelete are the right choices? can I access the $modx->documentObject['id'] in those events?)

for the second: do I have to put translations my caption/messages in manager/includes/lang ? at the end?

note: ah, well, there is an error in the italian.php.inc file, line 730: salvataggiog. -> salvataggio. (without the last "g")... and some other translation errors... who do I have to contact?

[davidm]

what do you mean for "menus"? which menus?

I think Ryan was talking about the menu tree, and you already are working on it, it seems :

I have still to implement the tree rebuild plug-in (necessary when adding or deleting a translation that has children); and use $_lang[] for messages/captions in manager

Anyway, like wendy I must say this is a much expected feature that we will all be glad to have

[madmage]

I think Ryan was talking about the menu tree, and you already are working on it, it seems :

I will wait for Ryan answer...

Anyway, like wendy I must say this is a much expected feature that we will all be glad to have

and I will be glad to share it, of course... :-)

it seems that the only thing that I have to do is something to manage the "move document" feature...

[Djamoer]

Is there any further follow up with this feature?

Madmage, will you mind posting a zip file containing the plugin, snippet, and core files that were modified? I want to implement this on my own site, and looking forward to use your approach.

Thanks for your help.

[Djamoer]

Hi guys, after talking in email with madmage, I found several issue that I really believe, integrating multi lingual content solution will need a big major overhaul with MODx core. I don't really know the current roadmap that we have, but the core of MODx need to be changed soon or later, and it will take more than only a month or so, but it will also take commitment and patient in doing this, because most of us just doing this on our free time, while MODx core code is not something small and easy to be overhaul.

But anyway, one thing that I would like to address, by having major overhaul, I don't think we can keep all the snippet that had been made up till this point. I haven't have much thought of this yet, but looking at the current API, most of the snippet are directly accessing the DB, which is one of the big no no in modularity, because we kinda stuck with MySql right now, and not only that, when we need to do something with the way how the document going to be managed, for example implementing multi lingual solution. When we change the concept of accessing, it doesn't mean that the whole snippet will follow the changes to the new document concept. So it makes MODx a little bit harder to be modified when it comes down to the core.

This is just my thought while thinking about this solution. I think we really need to start thinking about having this major overhaul, or we will stuck with the way how the old etomite work, because we keep having a lot of snippets and plugins that are not usable for the next major system overhaul.

So for now, I can't see the real implementation of other features, such as multi lingual to be integrated into the core, unless we come up with another idea, but for now, I should admit that it will be hard to implement. 

Correct me if I'm wrong, because with this small tiny little brain that I have in mine will not be enough to take the whole big picture of this current CMS Framework, unless somebody that has a bigger brain able to sort out some of my consfusing questions and assumptions about the current MODx, and the future plan.

Until then, I will keep hitting my head over and over, until I can think of a better way to do this stupic multi lingual solution. *sigh....

FYI, I just finish hacking the core of subsites, and it proves to be a lot simpler than multi lingual 

[OpenGeek]

This is just my thought while thinking about this solution. I think we really need to start thinking about having this major overhaul, or we will stuck with the way how the old etomite work, because we keep having a lot of snippets and plugins that are not usable for the next major system overhaul.

So for now, I can't see the real implementation of other features, such as multi lingual to be integrated into the core, unless we come up with another idea, but for now, I should admit that it will be hard to implement. 

Correct me if I'm wrong, because with this small tiny little brain that I have in mine will not be enough to take the whole big picture of this current CMS Framework, unless somebody that has a bigger brain able to sort out some of my consfusing questions and assumptions about the current MODx, and the future plan.

I couldn't agree more Wendy.  At some point we have to make the leap to do this, but I'm not sure MODx is absolutely the right place for this switch to take place.  Let me try and explain, as this is happening as a result of two different initiatives within the core team, one based on ideas that can be rolled into MODx in relatively easy upgrade paths, and can remain accessible to a wider audience of PHP 4 / MySQL users; the other, based on database abstraction, OO design, and dependency on advanced features available only in PHP 5.

First I think we need to take advantage of the contributions of the community to continue to make MODx strong, and not make major sweeping changes all at once to address every need of an enterprise-level solution, and making everyone reauthor their snippets.  At the same time, I see the need to overhaul everything to make it a product that can address enterprise-level CMS and application framework needs.  So, while we have been continuing development of MODx, I have branched off, and developed what I am considering an advanced solution based on the concepts of MODx, but that might not fit the need of the average MODx user.  I think this is where Tattoo comes into the picture (at least in my vision of the MODx future), and I should have a proof-of-concept of this new PHP 5, multi-DB, multi-cultural, object-oriented CMS framework before the end of the month.  At that point, I may submit it to the team for review and consideration as the initial release of Tattoo.

Here are some features of the system I am working on to wet your appetite...and many of these concepts can be back-ported to the current MODx system if they find merit in them.

Resources and Elements
Everything in this system would be reduced to one of two things, a Resource or an Element.  Resources would essentially be what is now a Document (or a WebLink).  Instead, you would now have Resources, PageResources (Documents), and LinkResources (WebLink), and you could define new Resource types by implementing a class that extends the Resource class or any of these subclasses.

Elements would replace everything else except Placeholders, from Template to TV, to Chunk, to Snippet, to Plugin, to Module.  You would define a base Element to attach to the Resource (as you would a template), and then everything else in the Resource could be attached to the base Element (i.e. the way TV's are attached to a template), a Resource directly (essentially providing Resource or Page variables), or called via an ElementTag in the content of any Element the way our current tags work.

Resources, Elements, Content, Culture, and Revisions
When it comes to content, this new structure is extremely flexible.  It provides Content records that are related directly to each Element.  Then, each Content record has content stored in the Revision table.  So when looking up the latest content, it would, by default, pull the latest Revision of the Content for the culture specified in the Context of the request.  Additionally, every Resource can provide alternate Content for any Element, in much the same way as TV values can be overridden by the Document now.

Contexts and Management
The final part, which I am working out now, is dealing with Contexts.  Think sub-sites, think multi-sites, think manager.  This would basically allow you to manage, with a single install of the core classes and manager, any number of site installations, sub-sites in sub-directories or on sub-domains, etc.  And the manager in this becomes just another set of Resources and Elements, isolated from the others by Context.


But as they say, the proof is in the pudding, so until I have a working preview, and we have worked out everything internally on the team with regards to these ideas, that's about all I want to reveal for the time being.  I just wanted to let everyone know that all of these issues are being addressed by an initiative to overhaul the entire core system, but with the caveat that it might not be the solution for everyone.

In the meantime, thanks for everyone's contributions in all of these areas, and I'm sure the team will be seriously considering these when planning the implementation of such features in future releases of MODx.

Cheers 

[Mark]

Can't wait Jason!