MODx 0.9.7 Roadmap and Milestones, you can help!

There are a lot of things to get done in order to release MODx 0.9.7 to the public (beta or otherwise), so I thought I’d start off with a quick brainstorm of things to do. Feel free to help me build this list by referencing new or existing feature requests in this thread, or just discuss your ideas/suggestions/concerns.

SOME GENERAL THINGS TO KEEP IN MIND

• Do not automatically choose the path of least resistance; most proper solutions require careful consideration
• Never assume anything; take the time to understand or experiment before you decide to make a change
• If what you are trying to accomplish requires SQL, you should consider requesting/adding a function to the API
• Do everything possible not to break upgrade paths

TO-DO’s

• Regression testing[list]
  [li]Full feature regression testing on new installs
• Add-on compatibility regression testing in conjunction with tag migration tool[list]
  [li]need to catalog incompatible add-ons and track conversion

[/li]
[li]Upgrade regression testing in conjunction with the tag migration tool

• need to catalog issues to identify where to improve migration tools and documentation

[/li]
[li]Core features to finish implementing

• Contexts need to worked more deeply into the core model (also see New manager features to implement)
• Input and Output filtering for all Elements
• Merged user/security model (web_users and manager_users --> users)[list]
  [li]Test manager_user migrations
• Design and author web_user migration process(es)

[/li]
[/list][/li]
[li]Finish converting all manager pages to Smarty templates with AJAX accessible connectors and processors

• See manager/controllers/ and manager/templates/MODxLight/ for the logic and presentation of manager pages (replace manager/actions/)
• See connectors/ and core/model/modx/processors/ for the AJAX connectors and processors (replace manager/processors/)
• Remove legacy manager code once you have successfully converted it
• For now, mootools (+ our own code where necessary) will be the Javascript framework used in the manager (others are being considered for the future)

[/li]
[li]New manager features to implement

• Design and implement context support, including site sections, subdomains, add-on domains, and multi-domains

[/li]
[li]Start converting latest versions of add-ons to xPDO-based API

• Try to remove all dependency on SQL
• Use new API or suggest changes to add-to or improve it for what you need it to do

[/li]
[li]Core features to be implemented or refactored

• Redesign/refactor/rethink lexicon/dictionary/$_lang
• Data/file import/export[list]
  [li]New database agnostic install process using xPDO[list]
  [li]New xPDO core installation and model provisioning
• New MODx core installation and content provisioning
• New MODx add-on installation and provisioning

[/li]
[/list][/li]
[li]Content types added to model

• Standards-compliant SEO URL refactoring based on content-type delivery model

[/li]
[li]Documentation

• DocBook/PHPDocumentor (more on this soon)

[/li]
[/list]

This again is just a quick list off the top of my head, of the key things that need attention.[/list][/list]

RE: "Start converting latest versions of add-ons to xPDO-based API"

One API function Ditto will require is a getDocuments variant that gets documents (including select rendered TVs) down to a specified depth. The current implementation in Ditto is SQL dependent (albeit extremely fast )

Quote from: Mark at Apr 25, 2007, 10:13 PM

RE: "Start converting latest versions of add-ons to xPDO-based API"

One API function Ditto will require is a getDocuments variant that gets documents (including select rendered TVs) down to a specified depth. The current implementation in Ditto is SQL dependent (albeit extremely fast )

That is an example of a highly-specialized query that will be owned by the add-on. Also, please realize that most of the current API functions will be deprecated with 0.9.7; functions like getDocuments(), getUserInfo(), getTemplateVarOutput(), etc. This is literally a new API, based on object-oriented principles, i.e. functionality is localized to specific classes representing the MODx data tables. Your challenge is to build this query using xPDO and the new API.

API functions will be added only where the functionality is so common as not to constitute unnecessary bloat to every request involving a specific class of object. The burden of that bloat should fall to the components being executed in a specific request.

I’ll be watching this thread and doing my best to contribute!

Personally I’d recommend PHPDocumentor over DocBook, but that’s just me, I have more experience with phpdoc...

Will there be specific assignments for each member of the team to complete (using the bugtracker for instance)? This being my first coding team to be a part of I’m still a n00b

Quote from: sirlancelot at Apr 26, 2007, 01:09 AM

Personally I’d recommend PHPDocumentor over DocBook, but that’s just me, I have more experience with phpdoc...

Actually, DocBook will be my recommendation for the documentation format (an XML format) for all non-source documentation (tutorials, guides, etc.), which PHPDocumentor can then use to link with source documentation, and produce output in HTML, PDF, CHM and other formats, all from a single source. This will also allow us to keep the documentation versioning in SVN with the source, and in a format that is easy to diff and merge.

Quote from: sirlancelot at Apr 26, 2007, 01:09 AM

Will there be specific assignments for each member of the team to complete (using the bugtracker for instance)? This being my first coding team to be a part of I’m still a n00b

Purely volunteer; if there’s an area you want to be involved in, by all means jump in and start collaborating on it... But yes, all these things do need to make it to the bug tracker and contributors need to start using it religiously to make sure they aren’t duplicating efforts on a task whenever possible. I’ll be introducing Team Code Reviews in the near future to increase the number of eyes that code has put upon it before being promoted from the branches...

I’d also like to add that the interface is in desperate need of some graphical improvements, specifically in the ways of standard CSS global styles. The "sectionBody" stuff is great, but inline not so good.

A few of those needs are:

• Better table styles - The current ones are a bit ugly, and dont seem to really fit into the manager color scheme.
• Better list-as-row styles - i.e., a UL/LI list that mimics a simple table. This is needed sometimes.
• Better Form styles - I’ve done some work with classes such as .standard, .settings and .informational, but this still needs a lot of work.

There’s more, and as you poke around the interface, I’m sure you’ll find more. The main thing we need are global classes so that tables/lists/etc can be quickly and easily formatted with minimal specified class attributes (basically, i could just set <table class="standard"> and then go from there).

Note: - Also, another task to be done, is that in a lot of the processors, we’ve enhanced the manager to have a lot more error messages (and ones more detailed too). However, what this does is that it creates a lot more language strings.

Sooooo, putting those into the lang files and translating them is a definite need.

Okay guys, in the latest 097 commit (rev 2621), I’ve put in a good way for you guys to know what’s left in the conversion process.

In manager/includes/init/navigation.php, the gigantic switch statement resides. Each action has a ’case’, and cases where the number is in quotes, ie:

case ’43’:

...means that the page is not done.

case 32:

...means that the page is done (or is ready to be tested/upgraded/spiffied up)

So if you see a page that isn’t done, feel free to do some work on it. For now, stay away from the user management pages, until we finish the user merge.

Also, a HUGE need is to test/upgrade/improve the finished pages. So if you see something you want done, do it!

Thanks guys.

Also, just FYI, I am about 40 or 50% done with rewriting the installer. I was basically forced to do so in order to perform more intelligent upgrades, especially when dealing with merging manager and web users; and it needed to be done anyway to prepare for supporting xPDO databases.

In the meantime, 0.9.7 web_users is pretty much broken, including webuser logins, registration, etc. I will be fixing this once the new installer is ready and working.

Also, for better core development collaboration on 0.9.7, Shaun and I would love it if more of the team would join us on IRC at #xpdo, #modx, and/or #tattoo. Shaun and I have been discussing 0.9.7 development in #xpdo for the past month and it’s getting lonely with just the two of us...

I never much liked that installer anyway, way too much clever javascript for my peace of mind.

Also, for better core development collaboration on 0.9.7, Shaun and I would love it if more of the team would join us on IRC at #xpdo, #modx, and/or #tattoo. Shaun and I have been discussing 0.9.7 development in #xpdo for the past month and it’s getting lonely with just the two of us...

I’ll pop in at some point this week ... I completely forgot about the #xpdo chat room. Still trying to get my head round some of the changes so it will help tremendously to chat with you guys.

Cool news on the installer, sounds great!