Every project we build should preferably be built somewhat the same way, so it's easy to jump between projects and know that stuff like meta data on pages, extra html snippets etc. are handled the same way.
For this task, we've been using (and maintaining) our own Starter Kit containing some Content Types, Data Types, Templates etc. for building out the absolute basics of a site. This contains for example a SiteNode Content Type, a ContentPage Content Type, properties for setting the 404 page, meta data, etc.
A Starter Kit is a kind of Umbraco Package, that includes eg. schema data and content nodes, to get a head start on building an Umbraco project. Starter Kits can serve as a demonstration of what Umbraco can do, but can also be used for scaffolding, or turn Umbraco into a complete point-and-click style website builder.
Starter Kit Maintenance gives me headaches
Maintaining a Starter Kit can be cumbersome and error-prone. You often risk missing dependencies or including incorrect content types, leading to additional rework.
Everytime you make changes, you need to go to your Created Package in the Umbraco project where you build your Starter Kit, and make sure that everything is checked and okay. There is little to no validation, so you can easily end up creating a package containing eg. Content Types depending on Data Types that you forgot to include in your package.
The package that you create in the backoffice, is then exported as a package.xml file (or package.zip if you include media items), and you can then create a NuGet package, with a migration for actually installing the package.xml file.
Deploy and uSync doesn't play nice with Starter Kits
Another thing I dislike about this approach - at least when building sites like we do at my work. Is that you have to remember to remove the Starter Kit once it's been installed, as the migration will run every time you recreate the database. Eg. when a colleague clones the project and starts working on it. We use Umbraco Deploy or uSync (depending on the client) to keep track of schema changes, and these tools can get in a fight with the Starter Kit about what schema to create.
For example, if you change your SiteNode on a project basis (which we always do, our Starter Kit is just a very simple baseline), you can end up having Deploy/uSync create your schema as per the .uda/.usync files, and then the migration for the Starter Kit runs and overwrites everything again. I know, you could just have a "Starter Kit" based on .uda/.usync files, but then you suddenly have two "Starter Kits" to maintain.
The solution
The Schemex Exporter package addresses this by allowing you to generate a package.xml of all schema and content automatically, without the hassle of manual package creation.
With the Exporter package, I keep the Umbraco project for actually maintaining the Starter Kit, but throw away the manual export of package.xml file, and updating of internal Nuget packages. Let's just call this the Source Project.
The package works by simply exposing an API, which when invoked, generates a package.xml of all content, schema etc. of the project and returns to the user.
This package is then installed in the Source Project, and I can then go to /umbraco/schemex/export/get to download a fresh package.xml of everything in the Source Project.
Note: The package.xml also contains all content, or at least the first content node and its descendants. So it's probably not wise to have this package installed in anything not supposed to be used as a baseline. Eg. if you have sensitive data in your content.
With the package.xml file generated automatically, I could then just go and do the rest of the work, updating the NuGet package of my Starter Kit and be done with that.
But as I wrote, I don't really like the Starter Kit approach for the type of projects we build.
Importing the schema in new projects
So instead of having to manually create new versions of a Starter Kit, and make sure that new projects actually gets the newest version of the Starter Kit installed, I created a companion package (Schemex Importer). This package exposes an API that can fetch the package.xml file from a project using the Exporter package and install it.
The Importer package is installed in the newly created project. Let's just call this the Target Project.
It works by going to /umbraco/schemex/import/push/?source=[HOST_NAME_OF_SOURCE_PROJECT_HERE], which will make the package download the package.xml from the hostname mentioned, and install the contents in the Target Project. Giving you essentially the same as what a Starter Kit would do.
The import will only run if the Target Project is running in Development mode, and it will also prevent installing if the project already has Content Types, meaning it probably isn't a newly created empty project. You can skip this check by adding &force=true to the import URL though.
The only thing it doesn't do, is installing any dependent NuGet packages from the Source Project. For example, we are big fans of Contentment and have a few Data Types from that package in our Starter Kit. To me, this is a responsibility of the dotnet template that we roll anyway, so for me it's no big deal.
One could also argue that the Importer package should be removed after the first use, but it isn't strictly necessary, as it is made to prevent overwriting existing schema (unless you set &force=true), and it only runs in Development mode.
Get the package now
The package is released under an MIT license, and you can get it today from the Marketplace. It supports both v13 and v14 - but doesn't support importing package.xml files generated in v13 though.
Top comments (0)