API to obtain the list of pages & templates on sandbox/prod
Guys, would be great to have some API or some way to obtain the list pages & templates with all their related layout, chains and features from prod and sandbox.
Hi Carlos, we recently shared a set of scripts as recipe that provides list of pages and templates from locally downloaded pb-data. Which you can download from any arc environment you want then run these scripts locally to extract list of pages, templates. The scripts also have csv output flag that you can pipe the output to a csv file and continue doing analysis in spreadsheet apps.
Scripts also help navigating which features used in which pages, or the top used features/chains/layouts/content sources.
I want to note that this is still not a real-time way to obtain this list from Arc XP environments, like an API endpoint. Our engineering teams still exploring fully productized, API that can work with real-time data at scale.
I have seen that but I don't know how to use it. I can see the ID, label and custom fields. Under all of that there is a button with the text "check feature usage", when I press it I always see this message:
Detail search found no pages or templates, you may force delete this feature.
so I can't know where the feature is being used.
Also, in case that button works and I am able to see a list of the templates/pages that are using the feature, would be great to be able to download a .csv or something like that so would be easy to report to the business. (The API would be a plus but I understand maybe doesn't worth it yet).
We do have a feature usage UI available in the developer tools (Developer Tools > Configurations > Feature Configs) and this feature will be re-implemented for the new Editor. If you look at the existing functionality on the interim admin, what improvements could we make to this UI to address some of your use cases?
Our org has multiple websites, dealing with the styles is a difficult part since we keep adding more and more features. I understand that while working with a single page we can enable fusion to build a CSS file per page & template only with the features that are being used, since we can't do the same on multisite and we have to build a CSS file per website, we believed maybe to build those CSS files locally knowing the features in each page and template would be not efficient for us as devs but maybe could have a better result to the client.
However, even this idea to solve that issue is not the best, then we realized that maybe this could also help other areas of the business, ie. when we need to do a refactor, if we need to change a feature that is being used, for a new version, if we need to do some critical changes, in those cases would be perfect to receive it in the UI or as an API as well. Another example is that if we want to make the decision to remove a feature, if we need to show evidence about the usage of some feature, if we need to create a report of the pages & templates highly detailed, we believe in those cases would be specially better to receive this from an API.
I hope this information is helpful, Happy new year!
Hi Carlos - thank you for the suggestion. Can you provide more context as to how you might utilize this? What is the impact or pain point you experience of not having this functionality? The context you provide will help us to plan a more solid solution to this suggestion - we'll need to consider exactly what information you'd want (publish pages and templates only?) and how you should receive it (as an API or in the UI?) based on some existing use cases. Looking forward to hearing more.
Carlos Fernández
Hi Carlos, we recently shared a set of scripts as recipe that provides list of pages and templates from locally downloaded pb-data. Which you can download from any arc environment you want then run these scripts locally to extract list of pages, templates. The scripts also have csv output flag that you can pipe the output to a csv file and continue doing analysis in spreadsheet apps.
Scripts also help navigating which features used in which pages, or the top used features/chains/layouts/content sources.
Here is the ALC documentation about this scripts that links to the github repo: https://docs.arcxp.com/alc/en/how-to-check-feature-content-source-usage-using-pb-data-analysis-scripts?id=kb_article_view&sys_kb_id=ac1d479bc376ca50a046930a05013141
I want to note that this is still not a real-time way to obtain this list from Arc XP environments, like an API endpoint. Our engineering teams still exploring fully productized, API that can work with real-time data at scale.
I have seen that but I don't know how to use it. I can see the ID, label and custom fields. Under all of that there is a button with the text "check feature usage", when I press it I always see this message:
Detail search found no pages or templates, you may force delete this feature.
so I can't know where the feature is being used.
Also, in case that button works and I am able to see a list of the templates/pages that are using the feature, would be great to be able to download a .csv or something like that so would be easy to report to the business. (The API would be a plus but I understand maybe doesn't worth it yet).
Hi Carlos,
We do have a feature usage UI available in the developer tools (Developer Tools > Configurations > Feature Configs) and this feature will be re-implemented for the new Editor. If you look at the existing functionality on the interim admin, what improvements could we make to this UI to address some of your use cases?
Hi Tania, thank you for taking a look on this.
Our org has multiple websites, dealing with the styles is a difficult part since we keep adding more and more features. I understand that while working with a single page we can enable fusion to build a CSS file per page & template only with the features that are being used, since we can't do the same on multisite and we have to build a CSS file per website, we believed maybe to build those CSS files locally knowing the features in each page and template would be not efficient for us as devs but maybe could have a better result to the client.
However, even this idea to solve that issue is not the best, then we realized that maybe this could also help other areas of the business, ie. when we need to do a refactor, if we need to change a feature that is being used, for a new version, if we need to do some critical changes, in those cases would be perfect to receive it in the UI or as an API as well. Another example is that if we want to make the decision to remove a feature, if we need to show evidence about the usage of some feature, if we need to create a report of the pages & templates highly detailed, we believe in those cases would be specially better to receive this from an API.
I hope this information is helpful,
Happy new year!
Hi Carlos - thank you for the suggestion. Can you provide more context as to how you might utilize this? What is the impact or pain point you experience of not having this functionality? The context you provide will help us to plan a more solid solution to this suggestion - we'll need to consider exactly what information you'd want (publish pages and templates only?) and how you should receive it (as an API or in the UI?) based on some existing use cases. Looking forward to hearing more.
This would be great to reports, analysis and other implementations.