1. Avatar of Brett

    Any tips you may have on deployment would help. Here is the scenario.

    We are using Better CMS to display some data from our application using a server Widget. We setup the site just how we want it to look when we deploy. We are planning to 'install' BetterCMS running our custom widget at many customer sites and want exactly the same configuration each time. The same pages with the same titles, the same icons, etc. The customer can change it later but 'out of the box' we want it to look just as we have it.

    My current plan to do this is at the customer site:

    1. Run Better CMS website to create the initial database schema on the new database.
    2. Create a data .sql file to replicate the data exactly as I have it setup in my BCMS database.

    Is there a better way to create a website template, with pages, server side widgets, icons, etc and deploy it at many sites all having the same configuration? What about the URLs that are saved in the database....

    Let me know.

  2. Avatar of Everett

    I'm very interested in an answer to this question as well. I'm using BetterCMS to handle the knowledgebase, release notes and notices (downtime, EOS, etc.) on a website. I'm looking for a way to make sure that a fresh install of the site will have everything configured for content editors to get started immediately (categories, templates, default pages). I think what I want to do is pretty similar to what BetterCMS does in InitialSetup.cs. I'm considering 3 options and could use some guidance on whether one of them is preferred/recommended or there's some better approach.

    (1) SQL scripts, as mentioned by OP (Brett). The upside to this is simplicity and that you may not have to deploy the application to update the structure of the CMS database config. The downside to this is that I'm now tightly coupled to BetterCMS implementation details over which I have no control. (2) I notice that BetterCMS uses FluentMigrator so I could use it to setup CMS database config. The upside to this is that I'm using the same mechanism BetterCMS uses. The downside to this is that I've taken a dependency on FluentMigrator, which means I have to learn it AND I'm still tightly coupled to BetterCMS implementation details over which I have no control. Another downside to this is that you have to deploy the whole website in order to update CMS database config. (3) Use the API to setup CMS database config. If the API has everything I need to do this then the upside to this approach is that I'm using an explicitly defined API rather than relying on implementation details. The main downside I can think of to this approach is that you have to deploy the whole website in order to update structure.

* Mandatory
* Mandatory
* Mandatory

Verify that you are human