[Test Build] MODx 0.9.2 preliminary test versions

Quote from: davidm at Apr 04, 2006, 07:32 AM

Yeah well some of us don’t have SVN

@davidm: did you see my earlier post about SVN now being available to the public? So actually, you do have access to SVN; now all you need is an SVN client. If on Windows, I suggest TortoiseSVN, which provides shell integegration with SVN.

Quote from: OpenGeek at Apr 04, 2006, 09:59 AM

@davidm: did you see my earlier post about SVN now being available to the public? So actually, you do have access to SVN; now all you need is an SVN client. If on Windows, I suggest TortoiseSVN, which provides shell integegration with SVN.

Duh, dumb me, how did I miss that ?!?

This is great ! Thanks Jason
Yeah I am quite familiar with TortoiseSVN I’ll go checkout : Working great !


While I am here, I have a few things coming to mind :

In .htaccess, we currently have zlib loaded by default, but it’s not a widely supported feature on shared hosting (or at least it seems so since many users have to be told to comment those lines out to have MODx working). Shouldn’t we comment those out ?

A while ago, I had noticed some QuickEdit strings were not localized when I switched to french. It might be me, but I still have the same problems with the 3 2 strings ("go", "content" and "settings"). Can anyone confirm that (Banzai ?) ?

Speaking of language settings, one of the things I’m working on is getting all the RTE’s to recognize the language selected in the manager and apply it as the language choice in the RTE by default. So if a user has the manager set to Spanish then the RTE will be set to Spanish as well. I’ll have to play with it to get it to work right for front-end template variables.

Which brings me to a small dilemma. One of the things I noticed is how we’re dealing with language settings to begin with. Honestly, I think this is one area we need to clean up and rethink a bit. For starters, I feel that all language settings need to comply with the ISO standards for language codes (http://www.loc.gov/standards/iso639-2/englangn.html). This is very important and will help greatly in allowing for other plugins, modules, and such to lookup the language setting by it’s two or three letter abbreviation (en, es, etc.) rather than looking for a whole string (english, spanish, etc.). Great help if we had this...especially since the RTE’s all use the ISO language codes. Also, I feel that when building a plugin, module, or the like, it’s a good idea to include a language directory so that it’s easier to implement language choice with a plugin or module. Many modules already have this implemented (i.e. QuickEdit). I’ll likely be rebuilding the RTE’s to include this feature...not only because it makes sense, but also because it’ll greatly reduce the amount of code going into the manager for a given RTE.

So...on that note, I think these items should be added to the to-do list for 0.9.2:

• Change language files and selection to use ISO language codes.
• Ensure all language code is in a ’lang’ directory.
• Standardize how language files and code are to be used throughout MODx.

More to come...

Quote from: Bravado at Apr 04, 2006, 11:00 AM

Speaking of language settings, one of the things I’m working on is getting all the RTE’s to recognize the language selected in the manager and apply it as the language choice in the RTE by default. So if a user has the manager set to Spanish then the RTE will be set to Spanish as well. I’ll have to play with it to get it to work right for front-end template variables.

Funny, I was thinking about this last time I edited the language setting for FCK This is great news !

Quote from: Bravado

Which brings me to a small dilemma. One of the things I noticed is how we’re dealing with language settings to begin with. Honestly, I think this is one area we need to clean up and rethink a bit. For starters, I feel that all language settings need to comply with the ISO standards for language codes

Great ideas !

Also, it brings another thing back to mind : why is MODx not full UTF-8 by default ? Will it be in the future ?

Talking of QuickEdit, has anybody tried this in the latest SVN build? I think the latest Prototype update isn’t playing very nice and I can’t move my QuickEdit bar around the screen, it’s permanently fixed in position.

My javascript console on FF says:

Rolling back Prototype to the version in 0.9.1 seems to fix the problem.

Any ideas anyone?

Quote from: Bravado at Apr 04, 2006, 11:00 AM

So...on that note, I think these items should be added to the to-do list for 0.9.2:

• Change language files and selection to use ISO language codes.
• Ensure all language code is in a ’lang’ directory.
• Standardize how language files and code are to be used throughout MODx.

Absolutely! The language codes should definitely be based on ISO standards, but I do not think we should deal with this for the current pending release. In fact, I’d like to say that 0.9.x features are closed at this point. So basically, nothing else is to be added to trunk unless it is at least a semi-critical or easy to knock out bug fix. We need to get this out the door.

In fact, we need to discuss this in more depth, as 1.0 is coming down the pipe fast. In fact, I want everyone to prepare to shift gears immediately following this release. The 1.0 work that will need to be done is being defined as I complete the new core (I’d say I’m 60% to 70% complete with the new MODx 1.0 core), including working with a layer above language which will be called culture, and can represent localized variations at a more granular level than can simple division by ISO language codes.

I’m adding the ISO language code field to the modCulture object now in the 1.0 branch, but be aware there could be multiple cultural-specific revisions with the same language code in the 1.0 data model.

I think there will be a lot of things that Adam, Jeff, Jared, Mark, and all our major resources coder to adjust their resources into this new core. Some of the things that pop into my mind are quickedit, breadcrumb, dropmenu, newslisting, fckeditor/tinymce, markdown/textile/bbcode parser, eForm (combined with simplicity of SendAnyForm snippet), and etc.

Btw, I believe 1.0 will support, multi lingual, subsites, tv being associated with document/doc group, changing of page/chunk/elements into elements, recursive elements parser (instead of looping the parser with a set of number), user/web user integration with flexible user pre-defined attrbutes, better events management allowing custom events, and core rewrite with half support of OOP and better API for processing elements, managing users/groups, checking permission, and etc.

Will that be on the 1.0 roadmap or they all will be available only in Tattoo?
Sorry, I’m kinda off-topic.

Wendy, I think everything you posted is right on and due in MODx 1.0

One thing I noticed about the latest release in the trunk. After a fresh install, the default Character Encoding is set to Arabic (ASMO 708). Err...shouldn’t this be Western European (ISO)? Just one of those little things to change in the trunk.

Definitely agree with holding off on any major changes regarding the language settings. But it’s definitely something we need to work on for a future release.

I think it should be UTF-8... :/