We have a large (100+) amount of pages and templates and managing them manually through PB is very cumbersome and time consuming. Please provide an API access to the configuration to help in the following scenarios:
1. Searching for specific components or configuration options to check on which pages or templates they are used. There are two primary usages for that
- if a component is being changed or renamed we need to update all the places where it was used, and
- if we suspect that a component isn’t used we want to be able to search all the pages to verify that before deleting it
2. Updating specific pages to add or remove components or changing configuration of specific components. This would be primarily used during deployments, where we can test particular changes in sandbox before re-applying them in production environments. For now all those changes have to be tested and re-applied manually, which is time-consuming and error-prone.
3. Copying pages, templates, or component configurations across environments. Currently this can only be achieved by exporting and then importing the configuration of a whole page without any modifications. This is again being done manually, either by us or by Arc, by raising a support request. We would like to automate some of those updates. Also would be great to be able to amend the configuration before re-applying to a different environment, e.g. to supply environment-specific IDs or add broken links.
A related idea was posted here https://ideas.arcxp.com/ideas/PB-I-312
Grzegorz Junka
Thank you Faith. By API access I mean a similar access that you already provide to site services or when providing access to ingest articles to Arc. It's not offline, it's the actual data that is in the database.
I want to be able to read the PB configuration of a specific page from sandbox, update that configuration, and write it through API to production, so that the modified page shows up in Page Builder.
One issue we would like to solve with this case is periodially checking all pages and templates that contain ads against their proper configuration to identify any accidental changes that impact ad impressions.
Another issue we need to solve is to be able to update all header and footer components in all pages and templates through API during a release call. That requires reading the current configuration of the component, updating it, then writing it back.
That's just some of the examples that we hope to solve through API access. Currently we are forced to use workarounds, which are flaky, manual, time consuming, often not reliable (like fragments and links), and often expensive (like external monitors).
Hi Greg, you're right, the large amount of the details you have describes fully-programmatic, and API-based access. Thanks for pointing it out. We'll re-open this aha idea to keep track of that.
Hi Fatih, the search is offline with 12 hours delay, which I could consider to be a temporary workaround for point 1 until you finish implementing a proper solution. But point 2 and 3 haven't been shipped at all. Can you please reopen? Creating a new idea and starting with getting votes from scratch, after a year and and a half of waiting, seems like a daunting prospect. Thanks.
Hi Greg,
I followed up the split part of your idea around "reading" the pb-data to search and filter feature usage. But want to copy it here too.
We released a recipe github repository that contain collection of scripts to analyze feature and content source from PageBuilder page/templates. Check out:
Github Repo
Recipe tutorial in ALC (with video demo)
Since we talked about the "write" (bulk update configurations) in the separate idea that the way you described (allowing "import" of pb-data on to production), does not make sense, I'll close this idea as "shipped" as well. But I am tracking the underlying need you described as "Editor API to allow bulk updates" internally. I definitely agree that's a big need, in order to make changes at scale. And the scripts we provided does not provide that capability yet, it still helps the steps your team takes, at least the wayfinding parts. We'll get to the bulk-update parts but there are many complications that the team needs to properly solution design to find a safe and scalable way to do that when we prioritize that initiative. Thanks for submitting these ideas.
Feel free to reach out to me or your TAM about any questions.
Hello Katherine, thank you for your response.
As a first step, I think a read-only access to help with #1 would be a good start. By read-only I mean the ability to read the PB config as JSON from an API. Another, maybe a simpler way to achieve the same goal, would be to allow converting PB exports to JSON with some external tool. It would allow us to search for specific components before deleting or when we need to locate a component in another environment to apply specific changes.
However, for #2 exporting and importing isn't really an option for two reasons:
- we have no way of merging changes to production without an API
- exporting and importing all affected pages might take as much if not more time
As an example take the case from last release, where we renamed 3 components that were used on about 20+ pages. If we wanted to export them from sandbox and import to prod we would need to do that for all 20+ pages then manually recreate all links to fragments which would become broken during the export/import plus update all components for which the config in prod differs to what's in sandbox. That's about the same time that it takes to configure those 3 components on each of those 20+ pages.
Also, in order to export then import we would need to make sure that sandbox is up to date with prod, by requesting a backfill, which takes 5+ days. If we tested the component before the backfill, it would wipe out the configuration anyway. For that to work in the first place we would need to configure and test those changes only after the backfill has completed. Considering that we have a release every 2 weeks, that leaves us with only a couple of days to do the test and regression tests everything else.
We would love to have a conversation with you how to improve the deployment process. I will reach out to you separately.
Hello Grzegorz, Thank you very much for your submission. From reviewing, it looks like there are several PageBuilder Editor ideas here. For the first and third points, I've internally linked them to similar ideas to help ensure we're prioritizing highly requested Arc ideas.
For #2, I'm wondering if the current Export/Import feature in PageBuilder Editor could help with alleviating the need to reapply updates manually? So potential workflow: once a new bundle has been validated and updates have been tested on pages in Sandbox, a user could then promote the bundle in Production and then export the validated pages from Sandbox and import them to Production. Happy to discuss further your specific use case and workflow.
As we seek opportunities to improve the quality assurance processes for PageBuilder Editor, we'd love to hear more from clients and their current pain points. If you're interested in discussing further, please reach out to myself or your technical account manager who can help to facilitate a conversation. Thank you!