modxbot / migrate

A testground for migrating issues and other such fun
0 stars 0 forks source link

Impact to multisiting #10247

Closed modxbot closed 11 years ago

modxbot commented 11 years ago

bakimenko created Redmine issue ID 10247

Hi! So, guys before yesterday i've got the Universal scale f*kup...

I'm using the MODX Advanced one core architecture for a couple of sites. And this sites uses the MODX extension the miniShop2 by Vasily Naumkin aka Bezumkin. It's very comfy and useful extension with great tech support. This extension supports a simple adding for classes by creating the files in special folders into a miniShop2 backend section (and in frontend section for plugins for miniShop2). As example we can use the custom classes for payments just a put the {name}.class.php into /modx/core/components/minishop2/custom/payment/

Ok. My great sadness began when i lost ALL of my custom files after installation miniShop2 on second site with using the one core for both of sites! Nothing broke but disappearing of my custom made files into extension folder at the backend (into /modx/core/components/minishop2/...). MODX shouldn't kill any files which not contains in install package! But it doing it. So we can make conclusion that's MODX Advanced just erasing the backend content of extensions when it installs to the new site. It impacts by the multisite support of MODX. Because of it nullifies the development of extensions such as miniShop2 which using customizing on filesystem layer.

Please make MODX installation process more friendly. As example let it ask us what to do with existing content - kill existing files and folders before installation or update it without erasin gof files which not present in install package.

!!! This case does not apply to the update process of this extension. When it already installed on both sites the updates happens normaly. Without any erases.

opengeek commented 11 years ago

opengeek submitted:

This is an issue specifically with a MODX Extra, or at least this is definitely not a critical core bug as described here. I would contact the author of this Extra to see if they can modify the package not to uninstall "some" of the files within a component's install locations, but in general isolating customizations from the installed package assets is a better idea.

You could make a feature request for the package management system to allow packaging of vehicles that do not remove the file trees they install or something similar, though IMO, it's debatable if custom code should go within an existing components subtree. This will eventually lead to data loss or could even invoke MODX inception...an Extra, within an Extra, within an Extra...