My multi-content solution is ready to be tested... who wants to test?

Quote from: xwisdom at Dec 27, 2005, 07:57 AM

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...

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?

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,

Quote from: rthrash at Dec 27, 2005, 10:34 AM

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?

Quote from: madmage at Dec 27, 2005, 02:46 PM

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 :

Quote from: madmage at Dec 27, 2005, 02:46 PM

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

Quote from: davidm at Jan 03, 2006, 07:02 AM

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

I will wait for Ryan answer...

Quote from: davidm at Jan 03, 2006, 07:02 AM

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...

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.

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

Quote from: wendy at Jan 08, 2006, 01:00 PM

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

Can’t wait Jason!