Package Tools: Migration Helpers about umbraco.packages HOT 4 CLOSED

Yes this has been called "Package Migrations" ... there's a very old PR in the core for this, but it needs to be entirely revamped. I've spoken to numerous people about this including @jmayntzhusen as a feature that is needed. IIRC @jmayntzhusen has substantial notes about this, else i will need to re-create these notes about this whole feature.

Package Migrations means:

• this obsoletes package actions
• makes both nuget packages and umbraco packages work as one (i.e. you will be able to install data with nuget packages in the exact same way as if an umbraco package was installed in the back office)
• developers don't have to do any dirty hacks on startup to run custom migrations, this will all be taken care of appropriately and to avoid any startup costs
• when a package migration is detected (i.e. a new package has been installed or a package has been updated where the new version has migrations), the Umbraco installer will execute, but under a different type of runtime state with a different UI showing which packages require migrations to run, then the user clicks 'upgrade' (or whatever) and the installer will run just like normal. This way we get feedback about any errors that might be occuring.
  • It would be possible to have an option to run these silently but IMO that is not a good experience since if any errors happen then "kaboom" and the user has no idea what went wrong... so what needs to happen is that we have a silent option and if errors do occur we stop the app execution and render a nice error screen stating what went wrong (in fact we should have this option for the normal installer for patch upgrades ;) )
  • Another option that should exist is that there should be a configured 'holding page' that is displayed to any public user visiting the site if the site is in an upgrade/install/migration state and only the logged in administrator actually gets redirected to the umbraco install screen

So before any fluent APIs or nice to haves, we first need to make this possible.

from umbraco.packages.

I would probably say one thing:

Create.ContentType("myContentType")
             .Property("PageTitle", "Umbraco.TextBox")
             .Property("PageBody", "Umbraco.RTE", required: true);

I would prefere if Umbraco basic Editors aliases would be available not as string but static properties like in ModelsBuilder TypeAlias:

Create.ContentType("myContentType")
             .Property("PageTitle", Umbraco.TextBox)
             .Property("PageBody", Umbraco.RTE, required: true);

I would just avoid using a string which could change in core and they would be still exposed in Umbraco.

from umbraco.packages.

I have flagged this issue with the status/idea label. This means that it is currently in a feature request / idea state where we are opening it up for discussion.

At this point we can't say if this issue will end up being accepted or not, but we welcome all feedback 🙂

from umbraco.packages.

Closing this issue for now. We have an RFC running that involves this, once that is through the process we will open new tasks and issues based on the decisions in the RFC.

umbraco/rfcs#22

from umbraco.packages.