Merge Script Guidelines

Follow

Overview

  • How the Merge Script Process Works
  • Guidelines for Specific Actions

 


 

How the Merge Script Process Works

The merge script process occurs in three stages and includes three different versions of your website.

There will be your current live site, a working copy (of your live site), and a live test (which combines both).

Initially, Metro Publisher developers will clone the live site to the working copy. The working copy will look exactly like the live site at the moment of the clone except the clone is "anonymized" – it serves no ads and has a restrictive robots.txt file. All design changes will be done on the working copy while content changes will continue on the live site. These will be “merged” later.

At various times as needed throughout the project, the database from the live site and the design of the working copy will be merged into a live test. On the live test you will be able to see any changes in content from the live site combined with any design changes on the working copy.

At the end of the project when it is time to launch, one final merge of the design into the live site from the working copy will be done. At that point, the live database and all design changes will be merged on the live site and will be viewable by the public. The live site will look exactly like the live test. It is critical that the live test be reviewed adequately to prevent surprises.

Process Details:

  1. Clone Existing Site to Working Copy
    Clone client's complete site to new test instance as a working copy.





  2. Merge to Live Test Site
    Once changes have been made to the working copy, we copy the design from the working copy TO the live test. At the same time, we clone the client's live site TO the live test. We continue this process as needed throughout the project.





  3. LAUNCH: Merge Working Copy to Live Site
    On the day of the launch, we do one final copy of the design back to the client's live site FROM the working copy.


 

 


 

Guidelines for Specific Actions
The working copy is where all design and most structural changes must occur. Below are guidelines to prevent database conflicts when the merge script is run.

General warning:

In general, the merge script affects many components of the web, but is not syncing the content. Thus, pages, articles, locations, images and any other content items created in the working copy will not be moved to the live site. If you wish to create new content, pages, blog entries or modify existing ones, please do so in the live site. 

You should refrain from making design or structural changes to the live site while you are in the process of re-designing your site on the working copy. While the merge script is sophisticated, if you are making structural changes to your live site while making different changes to those same objects on the working copy, situations can arise that create conflicts when we merge the two databases.

For example, adding new content as part of the normal editorial process is safe, but moving sections, merging sections, merging tags, moving tags between categories or changing design on the live site while you are re-designing on the working copy can cause confusion when the two databases are merged. 

 

 


 

Fully synchronized
Many things will be fully synchronized by the merge script.

That means:

  • If the object only exists on the working copy, it will be copied over to the live site
  • If the object exists on both sites, the working copy version will be copied to the live site
  • If the object only exists on the live site, it will be deleted from the live site

Examples:

  1. New Layout – If you create a new layout for an existing section and publish it on the working copy, the merge script will change the existing layout to draft, add your new layout to the live site, and make it published.

  2. Existing Layout – If you make changes to an existing layout, the merge script will copy those exact changes to that section on the live site.

  3. Deleted Layout – If you delete a layout for an existing section, the merge script will delete that layout on the live site.

  4. Live Site: New Layout – If you add a layout on the live site, but it is not on the working copy, the merge script will delete that layout on the live site.

For these reasons, it is vital that everyone within your organization working on the re-design and those continuing with the day to day edits on the live site are synchronized with regard to changes they are making on both.  

Objects that are fully synchronized:

  • Layouts
  • Sprockets on content
  • Sprockets - Only new sprocket types
    • Posterboard
    • Classic List
    • Image Teaser
    • HTML
    • List
    • Carousel
    • Slider
    • Gallery
    • Ad Slot (DFP)
    • Calendar
  • CSS and theme options Everything editable via the design studio
  • Footer HTML Embed Any code added to HTML Embed in Settings
  • Custom style selections – Custom classes attached to tags which is fully synchronized.
  • Header/Footer Settings Any changes to Header & Footer in Settings
  • 404 redirects – These are redirects made with the redirect tool
  • DFP general settings - The admin Url is: /thirdparty/dfp_settings.html. We don't fullsync dfp size mapping which are only inserted/updated

 


 

Create and update only
For more critical objects, the merge script will only create the new and update the existing, but not delete anything.

That means:

  • If the object only exists on the working copy, it will be copied over to the live site
  • If the object exists on both sites, the working copy version will be copied to the live site
  • If the object only exists on the live site, the live version will not be changed

Examples:

  1. New Size Mapping for DFP – If you create a new size mapping on the working copy, the merge script will add it to the live site.

  2. Modified Size Mapping for DFP – If you modify the existing size mapping on the working copy, the merge script will copy those exact changes to the live site.

  3. Deleted Size Mapping for DFP – If you delete an existing size mapping on the working copy, the merge script ignore that and will not delete it on the live site. In these situations, you will need to manually delete the object after the final merger.

Objects that are created and updated but not deleted:

 

  • DFP size mappings – Size mappings are defined within DFP settings
  • Sections – New sections on the working copy will be copied to the live site. Live sections not in the working copy will be changed to “hidden in the navigation” on the live site. You can delete those manually after the final merge.
  • Location search groups
  • Location search quick links
  • Location search map zones
  • Location searches
  • Event searches
  • Location search categories
  • Event search categories

 

 


 

 

Create only
For some objects, the merge script will only add new but will not update any changes nor delete. You can add these objects, but you cannot change existing ones. If you want to change or delete them, you must do that after the merger.

That means:

  • If the object only exists on the working copy, it will be copied to the live site
  • If the object exists on both sites, the live version will not be changed
  • If the object only exists on the live site, the live version will not be changed

Examples:

  1. New Tag – If you create a new tag on the working copy, the merge script will add it to the live site.

  2. Updating an Existing Tag – If you change a tag (change the title or the URL) on the working copy, the live version will not be changed. The only exception is for custom classes. If you add a custom class to an existing sprocket on the working copy, that change will be copied to the live site.

Objects that are created but not updated nor deleted

  • Tags – Except for custom classes attached to tags which is fully synchronized, tags are only created, not updated or deleted.
  • Tag Categories – Tag categories are only created, not updated or deleted.
  • Users - We sync only 'go' users. We only create new users if they were added to the wc, but we don't update existing ones.

 

 


 

Custom options:

  1. Merge sections – Clients may want to merge existing sections. The simple and easy way is to merge manually from the admin before the redesign starts (so, before the working copy and the live site start to diverge) or after the merge. However, if the decision is taken when the redesign is ongoing, it can be done via the import script. The clients has to communicate us the list of origin and destination sections. The section must already exist before the sync (the script can't merge sections that are freshly-created in the working copy). The destination sections must exist in the live site (the client can create draft sections). After the merge, the old section will be set to 'draft' and the client will have to remove it manually. The entries that are moved to the destination section will be tagged with the old section title, not to loose track of the objects.
  2. Merge blogs – Similarly to 1, clients may want to merge blogs into sections. The procedure is the same.
  3. Custom SQL instructions – This option enables clients to run a specific sql instruction. It is not always possible, because it depends on the entity of the query, the elapsed time and other considerations. An example may be to remove all thumbnails for entries created before a specific date, or remove all descriptions for locations created by a specific user. We will talk about it during the project to see if it's feasible (if the query is particularly time consuming, it can also be done separately from the merge).

 


 

Frequently Asked Questions (FAQs)

  1.  If I move a piece of content from one section to another in the working copy, will the content be moved in the live site after the merge? No, the script does not move content around. However, if you moved the article and deleted the old section, the deprecated section will be hidden in the live site. Also, if you move the content to a freshly created section, the new section will be created in the live site.
  2. What happens if the client renames a section in the working copy? Is it renamed by the sync?
    Yes, the section is renamed. You should not rename it also in the live site to avoid conflicts.
  3. What happens if the client updates a tag (ex. changes the title) in the working copy? Is it renamed by the sync? The tag is not renamed. Tags are only inserted, not updated nor deleted. The only exception is the custom class: if that is updated, the sync updates it in the live site. The best thing to do if you wish to rename a tag is waiting to do it in the live site once the merge is done. You can also rename the two tags in both sites as long as the tag titles match.
  4. I want to create a new tag: shall I create it only in the working copy, or create it in both wc and live site? We suggest you to create new tags only in the working copy, so then the script merges them to the live site. This is also valid for tag categories.
  5. I want to delete a tag. What happens if I delete it in the working copy? Will it be deleted on the live site after teh sync? No, the sync does only insert tags, not update or delete. Thus, the tag will still exist in the live site after the merge.
  6. I want to delete a tag. What happens if I delete it in the live site? Will it be deleted on the live site after teh sync? No, the sync does insert tags, so the tag still exsiting in the working copy will be recreated in the live site.
  7. I want to merge two tags into one. Should I do it in the working copy or in the live site? What would happen during the sync? Merging tags may cause a conflict. To prevent the conflict, you should use a different urlname that is not yet in use in the live site. For example, merging 'tag-1' and 'tag-2' into tag 'tag-3'. Once the sync is done, the new merged tag will be created in the live site. The old tags ('tag-1' and 'tag-2' in the example) won't be deleted so you will need to do it manually.
  8. How can I remove a tag when a redesign project is ongoing? You have two options: removing it in both working copy and live site, or wait after the merge and remove it at once (this is the best option in our opinion).
  9. I created a new location search in the working copy using exising tags. Will it be merged to the live site? Yes, location searches are created and updated.

  10. I created a new location search in the working copy using freshly created tags that only exist in the working copy. Will it be merged to the live site? Yes. Tags are also inserted by the merge.

  11. I removed a location search, what happens in the live site? No, location searches are only created and updated.
  12. If I update a location search on the working copy, will my changes be merged to the live site? Yes, location searches are updated.
        
  13. I created a new sprocket and inserted an image. Will the new image be automatically loaded to the live site after the merge? No, the merge script does not sync any images or content, so you won't find the new image in the live page. You'll need to add it after the merge. In particular, for curated sprockets, we only sync tags, sections, urls but we don't sync content, location, pages and images which need to be added manually.
    Note: FAQs 5,6,7 are also valid for event searches
  14. I deleted a sprocket from the work site. Will it be deleted in the live site? Yes, sprockets are being fully sinchronized. Thus, the sprocket will be deleted in the live site. If there was some datasource related to the sprocket, it would not be deleted from the live site and could be re-used after the sync.
  15. I updated a sprocket in the work site. Will it be updated in the live site? Yes, sprocket are fully synced so any change you make in the wc will be replicated in the live site (with the exception of manually-picked items in curated sprockets, see FAQ 13)
  16. What happens to the DFP settings during the sync? The DFP general settings are fully synced, so the final site will have the settings that are selected in the working copy. We insert/update the DFP size mapping. Old and unmodified mapping sizes will still be available but the new ones will be applied.

 

Have more questions? Submit a request

Comments

Powered by Zendesk