Question

Photo of Terry Rugg

0

How to replicate a Block from one dev environment to another

1

Before we start figuring this out... has anyone done any work on a reusable way to replicate a block from one dev environment to another (keeping the same GUIDs)?  We can generate SQL insert scripts, but they'll include record IDs which are possibly different in another environment.  Ideally the solution would accomplish 2 things: 1) generate the required SQL insert script for all the related tables (based on pointing it to a single Block table record).  2) in the destination environment, read the existing record IDs and generate appropriate new ones for the records to be inserted.  Or is there some easier way to copy a Block?

Blocks
  • Photo of Rock RMS

    1

    If you're writing new blocks the best way to do this is through migrations. This assumes that you are writing in the Rock 'Plugin' pattern. We have several videos on setting up your development environment for writing plugins. In your migration you can add pages and blocks using several helper methods. Below are some quick samples of what's available. Intellisense will help you see what each method parameter is.

    // adds a page
    RockMigrationHelper.AddPage( "0C4B3F4D-53FD-4A65-8C93-3868CE4DA137", "D65F783D-87A9-4CC9-8110-E83466A0EADB", "Documentation", "", "E9FA78AB-E05D-4EC1-BA26-E9CC3D4D18B1", "" );     

    // adds a new block type
    RockMigrationHelper.AddBlockType( "Book List", "", "~/Plugins/org_sparkdevnetwork/Documentation/BookList.ascx", "Spark > Documentation", "FA18D6D7-2AB2-4A90-B3C1-C98DBD2B8AB8" );

    // adds a new block type attribute
    RockMigrationHelper.AddBlockTypeAttribute( "FA18D6D7-2AB2-4A90-B3C1-C98DBD2B8AB8", "BD53F9C9-EBA9-4D3F-82EA-DE5DD34A8108", "Detail Page", "DetailPage", "", "", 0, "", "B3511E29-D40F-402F-B340-DA69809E0986" );

    // adds a block to a page
    RockMigrationHelper.AddBlock( "5A0D1178-F51A-4FD2-B934-CE508BFA7DBD", "", "FA18D6D7-2AB2-4A90-B3C1-C98DBD2B8AB8", "Book List", "Main", "", "", 0, "C492BD6E-C6E7-4697-B805-0B747D7FA4F3" );

    // adds an attribute value to a page
    RockMigrationHelper.AddBlockAttributeValue( "C492BD6E-C6E7-4697-B805-0B747D7FA4F3", "B3511E29-D40F-402F-B340-DA69809E0986", "99da3083-26d3-4d51-9ad5-d9fca3943462" );

    (there's several more helpers you can look at using Intellisense on the Rock.Data.MigrationHelper class)

    As you can see everything operates off of Guids. 

    If you're more interested in setting up exisiting blocks to pages you still might consider creating a plug-in project if those pages and blocks are going to be 'production configurations'. This would help manage your environment in a consistant manner. The other option would be to setup the pages and block in production and then develop off copies of the production environment. We're currently doing a little of both in our environments. We write plugin migrations to register all our custom blocks and add them to pages. But there are some pages that we stitch together by hand using existing blocks. These are managed in the database only. 

    Hope this helps.