Reasons Why Bulk Publishing Is Needed
- Auto and manual cache clear processes do not work consistently or reliably in AVEVA's implementation
- Bulk publishing provides a workaround solution to address this challenge in the short term
- Tag changes (edit/move/delete) require all affected pages to be republished; sometimes there can be hundreds or thousands of pages impacted across all languages
- It is quicker to bulk publish all pages than it is to inventory only the pages impacted by the tag changes
- Some code changes (x-default, padding fix in Background Container, etc.) require republishing of pages to push changes to the live site
Two Methods for Bulk Publishing
- Manual: Go site section by site section - manually check pages to be republished, then click "Manage Publish"
- Limitation: Only 50 pages can be manually published at a time (414 error occurs if more than 50 pages are being republished)
- Automated: Go through the AEM interface to bulk publish Live Copy pages
Recommendations
Do the following before bulk publishing, regardless of the method used:
- Verify no content is queued in Live Copy, but not approved to be launched yet (e.g., press release timed for a later launch date)
- Automated bulk publish tool will inventory the unlaunched pages in Live Copy for review
- Automated bulk publishing is all or nothing, so do not proceed with bulk publishing if any pages in Live Copy need to be verified for publishing first
- Delete as many ARCHIVE pages as possible to reduce risk of these pages being republished and getting back into external and internal search
- Follow the Unpublishing process to ensure that pages are being handled correctly when retired to reduce unintentional republishing
- Address any tag updates needed
- Address any experience fragment updates needed
Do the following after bulk publishing, regardless of the method used:
- Do a search in AEM Sites for "ARCHIVE" to verify no pages marked as ARCHIVE have been accidentally republished
- Note: Other naming conventions to search for and assess for manually unpublish after a bulk publish is run: CH, DEAD, HOLD, REDIRECT
- Unpublish affected pages if accidentally republished
- Run Oncrawl report for sitemap orphans to flag any pages that may have been unpublished incorrectly (e.g., not marked as ARCHIVE, No Index, Hide from Coveo)
Limitations
If tag changes were made before bulk publishing, then the tag changes may cause the Card Carousels on pages break. Unfortunately, republishing the pages will not fix broken Card Carousels. Instead, a new Card Carousel will need to be added to the page and authored, and the original Card Carousel will need to be deleted. Then, the page will need to be rolled out and republished again.
How to Locate Impacted Card Carousels
- Run an ACS Commons report to find the impacted tags associated to Card Carousels, and then audit the pages and take the necessary actions. (Make sure the Stage environment has a recent copy from Prod for the most accurate report data.)
- Ask ROAST to run a report to find the card carousels that are missing (they query based on H2 for the Card Carousel stack on the page)
Best Practices for Bulk Publishing
- Publish only the Live Copy pages
- Select only the checkboxes for:
- Only Activated (this option protects pages that have been rolled out to Live Copy but have not been published at least once from being published before an upcoming launch date)
- Ignore Deactivated (this option protects pages that have been unpublished and marked as ARCHIVE from being republished)