Ideas for Arc XP

Expose PB resolver and debugger API enpoints

a) Our concrete issue: We have created a tool that will manage vanity and shorturl redirects using the draft API. But, for these redirects to work, we have to modify a resolver to capture the wanted regex for that specific redirects. Do enable a smooth process on this, we have to allow non-technical people access to the "developers" tab in pagebuilder. This however involves some risk that they by mistake will modify the resolvers that they should not.

To avoid this, it would be better if we could programmatically access the resolver endpoint used on this page https://mentormedier.arcpublishing.com/pagebuilder/tools/resolvers by API, and just make the changes in in one operation through our redirect management tool. Then we could close the (edit) permissions to developer tabs for all, except actual developers.
Could you open these APIs endpoints, for example using the same tokens as for the deployer?
Having APIs will also simplify programmatic setup of new sites.

b) Same as above, but for the https://mentormedier.arcpublishing.com/pagebuilder/tools/debugger Endpoint - Resolver debugger and Content source debugger. We often find it hard to use the debugger if there is something wrong with it - because nothing is returned in those cases. An exposed API that we could use in Postman or similar would be helpful.

  • Arnstein Andreassen
  • Mar 25 2021
  • Future consideration
  • Attach files
  • Arnstein Andreassen commented
    May 05, 2021 19:12

    Thank you Richard, a "catch all" last effort resolver/content source is actually a good idea. We will consider this!

  • Richard Lane commented
    April 21, 2021 13:39

    We are currently avoiding the need for specific redirect resolvers by combining our last "catch-all" resolver with a lookup to the content api. This allows for all previous resolvers to catch and process or pass on a request but then process any redirects before returning a 404 error for content not found.

    Specifically we have our content by section resolver/content source last. If a URI is not resolved by looking up by section then we check the content-api before letting it trigger a 404.

    We too are using a GUI to let non-technical people create redirects but without the need to setup any additional resolvers.