Bump.

The link to "Package actions documentation" in the latest version, http://our.umbraco.org/wiki/reference/packaging/package-actions, comes up with a 404.

Yeah can't seem to find a working link anymore @Donald what are you trying to do (maybe I can assist with some tips)

In Umbraco 7.5.10, the link (Developer Section, Packages, on Package Actions tab) still points to the non-existing url:

http://our.umbraco.org/wiki/reference/packaging/package-actions

Is this link going to be fixed in a newer version of Umbraco?

--

I would like to get an idea on the kind of actions that are possible and how easy it is to define/implement them.

Are there any alternative urls available that show examples about adding custom installer / uninstaller events to perform certain tasks during installation and uninstallation?

Me too.

I want to know if ExecuteSQL requires the Package Action Contrib package to be installed.

I would prefer not, especially as I think the topics in the discussion below still hold true.

https://our.umbraco.org/projects/backoffice-extensions/package-actions-contrib/using-the-package-action-contrib/11089-Best-way-to-use-Package-Actions-Contrib#comment-11089

On a separate note it seems package actions are not compatible with Umbraco Cloud so we need to use an alternative approach now if you want your packages to install on Umbraco Cloud.

Tea Commerce have already updated their installer because of this:

https://docs.teacommerce.net/blog/release-320

yeah

if you are adding sql during an install then you are better using Migrations (v7.3+)

https://cultiv.nl/blog/using-umbraco-migrations-to-deploy-changes/

as these work on Umbraco Cloud, are better for deployments and are will let your packages work both as a package and as a nuget package.

K

Thanks Marc,

Umbraco cloud might be a very valid reason not to support package actions any longer. And there may be many more good reasons...

Do you know if this is already mentioned/announced anywhere?

Just removing links without any explanation and still having "old" topics talking about them, makes it hard to know if they are still recommended for using in non cloud solutions.

So, can someone from the Umbraco team shed a light on the future use of package actions and recommended alternative future proof approaches?

Eg, is it recommended to bootstrap the install process on application load, just like Tea Commerce now does?

Examples and ideas on how this is done, are more than welcome!

Definitely looks like something is going on which hasn't been passed on to the community.

'Developing Umbraco Packages' forum topic is in read only mode.

https://our.umbraco.org/forum/umbraco-7/developing-umbraco-7-packages/

Hi

I can't talk for the core team, but it is my understanding that the long term goal is to more towards Nuget packages being the default install method. how this will work in the back office i don't know - but i think a single source and that working in both Visual Studio and Umbraco is the ideal state.

There where some discussions about packages at codegarden last year and that is certainly the impression I got. but i don't think there was an 'official' statement at any point.

Migrations do all the databasey things you should ever need to do and are baked into umbraco, they are how umbraco upgrades are performed.

Migrations them selves can be quite simple - you have a class that overrides the MigrationBase class and implements an Up (and down) function:

e.g.

    public override void Up()
    {
        if (!_db.TableExist("PublishQueue"))
            _db.CreateTable<QueuedItem>(false);
    }

see : https://github.com/KevinJump/Our.Umbraco.PublishQueue/blob/master/Our.Umbraco.PublishQueue/Migrations/TaregetZeroOne/CreateDbMigration.cs for full example

then you hook into app startup events and get umbraco to run any migrations between the current version in the db and your desired target version :

example here : https://github.com/KevinJump/Our.Umbraco.PublishQueue/blob/master/Our.Umbraco.PublishQueue/PublicQueueEventHandler.cs#L45

As of yet there is no offical support for other things like config changes or adding doctypes in migrations but you can actually call the packaging service within a migration to add a doctype / etc..

So for example. if you export your desired doctype as xml you can load it and call the packaging service.

XElement docTypeXml = XElement.Load(filepath);      
ApplicationContext.Current.Services.PackagingService.ImportContentTypes(docTypeXml);

But you need to be aware of things like dependencies (i.e the parent doctypes needs to be imported first). which is something the package manager does for you.

Hi Kevin,

Thanks for the info, this is a great help. Thanks for the links.

Cheers,

Marc

is working on a reply...