switch to hlx3

[rofe]

Migrate blog.adobe.com onto the Helix 3.0 architecture.

Related: #620

[rofe]

These are likely the relevant steps to migrate this project to Helix 3:

Preparation (main branch)

• [x] Merge branch master into main
• [x] Add Helix Bot to repo
• [ ] Add hlx3 flag to Sidekick config so it uses Helix Admin API
• [ ] Remove ESI includes from code (except head.html) part of business-website, see next comment
• [ ] Remove sourceHash in helix-query.yaml
• [ ] Change media URLs from /hlx_* to (./)media_*
• [ ] Load fonts directly from typekit part of business-website, see next comment
• [ ] Move sitemap-*.xml to Sharepoint (leave sitemap.xml)
• [ ] Regenerate sitemap-*.xml with new canonicals (no .html)
• [ ] Regenerate analytics-tags.*.txt with new canonicals (no .html)
• [ ] Find new solution for atom feeds? (@trieloff)
• [ ] Front-load preview and live from index

Switch to Helix 3

• [ ] redirect .html extensions to no extension in outer CDN
• [ ] Remove onedrive-listener (@dominique-pfister)
• [ ] Remove sourceHash column in index
• [ ] Replace /hlx_ with ./media_ in hero column, using the following expression in a new column:

  =SUBSTITUTE(C2, "/hlx_", "./media_")

  (provided the hero column is column C)

• [ ] Remove¹ .html extension in path column, using the following expression in a new column:

  =LEFT(C2, IF(ISNUMBER(FIND(".html", C2)),FIND(".html", C2) - 1, LEN(C2)))

  (provided the path column is column C).

• [ ] Republish index
• [ ] Change origin to main--theblog--adobe.hlx3.page in Fastly
• [ ] Delete master branch

¹ Changing a column in an Excel sheet based on a formula can be done as follows:

• Insert a new column in the table
• Enter an appropriate formula in the first cell of that column, which will extend to the whole column range
• Select the new column range, and Copy
• Select the old column range, and Paste Values
• Remove the new column again

[kptdobe]

The migration is tightly coupled with the https://github.com/adobe/business-website project. For this project, we took theblog code base and re-wrote it to be "hlx3" compliant (Lighthouse score = 100, blocks...). As part of this project, @fkakatie and myself are writing an importer (see https://github.com/kptdobe/helix-importer-projects/tree/main/src/blogtoblog), to "transform" the blog posts and convert old style components (inline embeds and promotion into blocks, metadata table, no section breaks...). We'll "move" some articles (~200?) from theblog (remove there) to the business website (new here). Once the business-website project is ready, we'll have:

• a fresh new code base that can be used for both projects
• an import mechanism to convert the blog posts from hlx to hlx3.

From there, we can start to migrate theblog site. A big step is to import the 35k blog posts and convert them. What's described above can then be executed.

[kptdobe]

I wonder if creating a fresh new repo (theblog-website ?) is not a better / cleaner approach. Like a full new project (and a copy of the business-website project). Like this we can prepare everything as a new project and "switch" the backend between the blog.adobe.com DNS as a final step.

[trieloff]

My plan for the new solution for the feeds was to piggyback on the sitemap.xml. A feed is just a partial sitemap, after all.

[tripodsan]

• [ ] Replace /hlx_ with /media_ in hero column, using the following expression in a new column:

looking a the current index, https://master--theblog--adobe.hlx.page/en/query-index.json?limit=2

I see:

"hero": "./media_1337a73606e16a6724ce1d910e72b116a5e1f14ac.jpeg?width=2000&format=webply&optimize=medium",

isn't this already ok?

[dominique-pfister]

the latest are, yes. if you increase the offset, you'll see the other variant as well, e.g.:

https://master--theblog--adobe.hlx.page/en/query-index.json?offset=10000&limit=2

[tripodsan]

the latest are, yes. if you increase the offset, you'll see the other variant as well, e.g.:

https://master--theblog--adobe.hlx.page/en/query-index.json?offset=10000&limit=2

ok. I fixed the description (it should be ./media)

[rofe]

I wonder if creating a fresh new repo (theblog-website ?) is not a better / cleaner approach. Like a full new project (and a copy of the business-website project). Like this we can prepare everything as a new project and "switch" the backend between the blog.adobe.com DNS as a final step.

What would in your opinion be cleaner about a new repo, compared to simply the main branch of this one? Like in a new repo, we could start from scratch there as well if we think it's necessary, but the go-live would be simpler.

1. Keep existing repo: we change the origin of the existing outer CDN (controlled by the Helix team) to point to the Helix 3 inner CDN. Skyline CDN remains untouched.
2. Set up a new repo: also set up a new outer CDN (for naming consistency) and change the origin in the Skyline CDN (involves the Skyline team).

(2) would add more complexity and have more dependencies than (1).

[trieloff]

I think it is worthwhile to keep the history and make the transition an explicit merge rather than starting a new, unrelated repo from scratch.

[kptdobe]

History can stay in this repo, it would not be lost. I agree that the Skyline dependency is probably a blocker for a new repo. A fresh new main branch could do the same job similar. Code migration in that case is not about changing some few lines, but a complete re-write, that's why I do not see the need of having a PR to be merged with all the new code. A code diff will be useless.

[kptdobe]

The content migration is a complex task because we need to wipe out the old content and replace it with a migrated version of it. At the same time, the code needs to be updated. I think having a new sharepoint site is a good strategy.

It will also require to train the authors, i.e. requires syncing with Matt and management team.

[rofe]

Code migration in that case is not about changing some few lines, but a complete re-write, that's why I do not see the need of having a PR to be merged with all the new code. A code diff will be useless.

Well, the scope of the PR is more than JS patches, I just included the few JS changes to make the current code work on Helix 3. We can (and should) of course still swap it out completely when ready.

[davidnuescheler]

I wonder if creating a fresh new repo (theblog-website ?) is not a better / cleaner approach. Like a full new project (and a copy of the business-website project). Like this we can prepare everything as a new project and "switch" the backend between the blog.adobe.com DNS as a final step.

i think that's a good idea, personally i don't even think that it needs to use our commonly -website post fix and definitely should lose the... the reason why we are using the -website postfix, is eg. for spark, that repo really is not the spark project, but for something like the blog, it really is the blog project from a github standpoint.

[kptdobe]

All other adobe projects have the -website postfix which somehow became the rule, I would keep it for uniformity.

[kptdobe]

For the record, extract from a Slack discussion:

• [ ] old /x.html URLs become 301 redirect to the new /x url - we need to see if the redirects.xlsx can handle 35k+ urls
• [ ] some old blog.adobe.com/a/x.html will  301 to business.adobe.com/b/x during the https://github.com/adobe/business-website migration.

[rofe]

All other adobe projects have the -website postfix which somehow became the rule, I would keep it for uniformity.

I'm with @davidnuescheler on this one - imo the -website suffix only makes sense if the prefix isn't already the site descriptor.

[rofe]

Continued in https://github.com/adobe/project-helix/issues/598