Revo Migration

Quote from: OpenGeek at Feb 05, 2009, 06:28 PM

Quote from: BobRay at Feb 05, 2009, 05:34 PM

I see a couple of other issues. One is the assets/snippets->components change which will effect a lot of paths.

That has nothing to do with converting tags or upgrading the core data and is not in the scope of anything that will be automated. People depending on specific components will have to rely on component-specific migration tools/guides to deal with any changes other than their use of legacy tags. assets/snippets or components or whatever is arbitrary IMO; the paths that people choose to store their components in are up to them and may depend on any number of determining factors. That’s important in keeping MODx flexible.

Fair enough. I should have realized that just installing the Revo version of any components that aren’t included in the Revo install would take care of this.

Also remember that MODX_ASSETS_PATH will represent a dynamic location for multi-site installations to share common assets, while $modx->config[’assets_path’] will represent context-specific assets locations.

Yikes. I’ve been assuming they were synonymous. Is this true for base_path and base_url also? Which would be appropriate for SPForm, Captcha, and ezFAQ?

Quote from: BobRay at Feb 05, 2009, 10:36 PM

Yikes. I’ve been assuming they were synonymous. Is this true for base_path and base_url also? Which would be appropriate for SPForm, Captcha, and ezFAQ?

Yes, this is a new challenge with the introduction of advanced multi-site capabilities and contexts; components will have to be aware of and choose between the configuration constants which represent what would be shared or common paths/urls, and the configuration settings, which can be modified by context and/or user settings.

For instance, you may want to share some common images or CSS elements via MODX_ASSETS_PATH/URL and then provide some context specific code and/or additional CSS elements via the $modx->config[’assets_path’]/$modx->config[’assets_url’] settings. This could also set up the ability to handle a central management interface and define a separate manager interface for specific contexts, which will be very handy for multi-domain setups where you offer limited/custom admin features for specific domains.

As for which is appropriate, there are a number of factors to consider, but in general, if you are writing components that are meant to be shared across contexts, the constants would be appropriate. If they are associated with elements that are meant to be customizable by context (or user), then use the config variables.

Thanks. I’ll have to check the code and see what I’ve done.