Earlier this week I went through the migration and your tool automatically created a new header and put it on all pages, but it did not create a new footer nor put it on ANY pages. I have over 60 pages and had to go one-by-one adding the new footer… not to mention it took me quite a while to figure out how to create a footer in the first place. All told it easily took over an hour to create the footer, customize it, then add it to all my pages including the new Utility Pages automatically created.
I recommend fixing that before more users try the migration.
Thank you for taking a moment to share this feedback with us. It’s a tough one cause some times the footer is needed on the page, and sometimes it’s not. So assuming that it’s needed cause also cause the same amount of friction (but the other way around).
I believe the team is looking at a solution to solve for this at a higher level though to make it easier for apps with many pages.
Either way, thanks again for sharing this with us and we hope you enjoy the updated blocks!
If [page] has [footer], generate [newFooter] on [page].
If [page] has multiple [footer[n]], generate [newFooter] on [page] from [footer[0]].
There should also be a mechanism to try to generate the footer with all the collections and links rather than just adding a blank one.
If creating a new footer configuration from the existing footer is too complicated, then just at least put the footer on the correct pages, would have saved a lot of time.
I had multiple headers before, the service auto-created one of them and I then had to change it to reveal/hide different links and buttons based on the user group. The service attempted to generated multiple headers to use for selection at the page level, I can tell by the naming conventions that it iterated through them, but only one other was generated and it was completely blank, so I only got one good one out of the three anyway.
