MODX Staff
☆ A M B ☆
Contexts – This new concept will allow MODx configuration settings to be overridden, extended, isolated, or shared across domains, sub-domains, sub-sites, multi-sites, cultural-specific sections, specific web applications, etc.Does this mean I can install MODx on my server’s root (server-gateway/data/) and then redirect various domains on my server to MODx documents (server-gateway/domains/adamwintle.com/html/ or server-gateway/domains/mallmusdesign.com/html/) - anyone familiar with Media Temple’s server structure would know what I mean...
Simplified, unified tag formatWill the 0.9.7 installer update all my old {{chunk}}’s, etc to the new [[$chunk]] - or will it be recommended to rebuild our sites into a new 0.9.7 install?
MODX Staff
So am I -- and I know it’s way overdue, but as I am working on an actual paying client project now that must be delivered with 0.9.7 (for various reasons), momentum is building. You’ll be seeing a lot more attention, activity, and announcements around the new version of MODx, as well as it’s new foundation, xPDO, throughout October.
I’m so excited about 0.9.7
MODx 0.9.7 will consist of a core framework library, which can be placed in a common location (i.e. server-gateway/data/), and various contexts. For a typical deployment, this would simply be the ’mgr’ context, the ’web’ context, and the new ’connector’ context (a set of Ajax services responsible for performing the administrative processes, regardless if they are coming from the ’mgr’ or ’web’ context). However, you can define additional contexts that can override any of the system settings specified in the core, and, more importantly, can have their own index.php gateway from any other web directory that has access to the shared core. It’s as simple as including the new modX class file and initializing it to a specific context, as demonstrated in the index.php included with the default ’web’ context.
Contexts – This new concept will allow MODx configuration settings to be overridden, extended, isolated, or shared across domains, sub-domains, sub-sites, multi-sites, cultural-specific sections, specific web applications, etc.Does this mean I can install MODx on my server’s root (server-gateway/data/) and then redirect various domains on my server to MODx documents (server-gateway/domains/adamwintle.com/html/ or server-gateway/domains/mallmusdesign.com/html/) - anyone familiar with Media Temple’s server structure would know what I mean...
It remains to be worked into the installer (i.e. no interface yet), but there is a migration script that can operate on both existing database content and file content to automatically migrate your tags (or it can just be used to suggest where the changes need to be made). It certainly cannot migrate 100% of tags, especially when mixed within PHP code as strings, but I’ve used it myself to migrate several sites to 0.9.7 with a surprisingly minimal amount of manual intervention. Putting this feature into the installer is on the to-do list, and is one of the final things to do before releasing an actual installable package of 0.9.7-beta.
Simplified, unified tag formatWill the 0.9.7 installer update all my old {{chunk}}’s, etc to the new [[$chunk]] - or will it be recommended to rebuild our sites into a new 0.9.7 install?
☆ A M B ☆
I am working on an actual paying client project now that must be delivered with 0.9.7If everything on the Roadmap happens I’m going to be able to deliver a much higher quality web site for one of my current paying clients
as well as it’s new foundation, xPDOWhat’s xPDO?
MODx 0.9.7 will consist of a core framework library, which can be placed in a common location (i.e. server-gateway/data/), and various contexts. However, you can define additional contexts that can override any of the system settings specified in the core, and, more importantly, can have their own index.php gateway from any other web directory that has access to the shared core.This sounds brilliant! - Lets say I’ve got a total of 20 domains and subdomains, with the new Contexts would I be able to have one core installation and then integrate a shopping cart system across all sites? - or aggregate news from across all domains into one news column?
It’s as simple as including the new MODx class file and initializing it to a specific context, as demonstrated in the index.php included with the default ’web’ context.Does this mean I’d have to create a PHP Class file on the server to activate Contexts on my server? - of will the use of Contexts be built into the MODx Manager?
MODX Staff
What’s xPDO?A lightweight PHP object/relational mapping layer I wrote so we could:
This sounds brilliant! - Lets say I’ve got a total of 20 domains and subdomains, with the new Contexts would I be able to have one core installation and then integrate a shopping cart system across all sites? - or aggregate news from across all domains into one news column?Yes; part of the conceptual work I’m doing to integrate contexts will allow for several different configurations, that would allow sharing at various levels from a single core install (i.e. similar to a PEAR library). See this thread for additional thoughts on the various scenarios being considered.
Additionally, would a network of sites setup in this way be secure? If I wanted to have a shopping cart system on X-domain and then another on Y-domain; although running the same cart snippets from the core would it be possible to run completely separate cart systems? With different templates and products, and the users would be none the wiser?
Again, the idea is to have contexts as an organization structure which you can use in various ways. I expect that what we will see are custom distributions of the new MODx core that include extensions and add-ons designed for use in specific multi-site scenarios.
Another query that comes to mind, in the ’mgr’ context, would you specify a Site Name for each ’web’ context you need, and then call them within their Context using [(site_name)]?
Does this mean I’d have to create a PHP Class file on the server to activate Contexts on my server? - of will the use of Contexts be built into the MODx Manager?It will be built-in to the core. There will be manager interfaces, and Ajax services, providing the ability to manage contexts. To implement a context representing a domain, you would simply deploy an index.php file in the web directory your web server is serving the target domain on that contains a few lines of PHP to instantiate the modX class with a specific config file, and then initialize a context. Here’s a sample showing all it really takes...
<?php
ob_start();
require_once ('/path/to/modxcore/model/modx/modx.class.php')
$modx= new modX('/optional/path/to/custom/config/dir/');
$modx->initialize('contextofchoice');
$modx->handleRequest();
?>
MODX Staff
We’re working to make it as easy as possible to migrate without sacrificing the new features. As discussed, their is a tag migration tool that will be built-in for upgrades from pre-0.9.7 releases, which will cover most of the work.
This discussion about 0.9.7 sounds amazing, but how hard will it be to upgrade from 0.9.6?
