Skip to content

feat(content): render DA content via the real html2md -> html-pipeline chain#2761

Open
shsteimer wants to merge 13 commits into
mainfrom
content/da-html-pipeline-render
Open

feat(content): render DA content via the real html2md -> html-pipeline chain#2761
shsteimer wants to merge 13 commits into
mainfrom
content/da-html-pipeline-render

Conversation

@shsteimer

@shsteimer shsteimer commented Jul 9, 2026

Copy link
Copy Markdown
Contributor
  • When serving local DA checkout content in the content/ directory, run those through the real pipeline: content/*.html@adobe/helix-html2md → Markdown → @adobe/helix-html-pipeline
  • This handles icons, section metadata, page metadata all through the same pipeline used when publishing content, instead of selectively re-implementing the pieces we need (e.g. the now deleted src/content/html-pipeline-internals.js

Please ensure your pull request adheres to the following guidelines:

  • make sure to link the related issues in this description
  • when merging / squashing, make sure the fixed issue references are visible in the commits, for easy compilation of release notes

Related Issues

Fix #2755
Fix #2756
Close #2759 (superseded by this)

Thanks for contributing!

🤖 Generated with Claude Code

shsteimer and others added 2 commits July 9, 2026 11:44
…e chain

Replaces the hand-ported page-metadata transform (and the icon-only
approach proposed in #2759) with a local run of production's actual
rendering path: content/*.html -> @adobe/helix-html2md -> markdown ->
@adobe/helix-html-pipeline's rendering steps, driven by a hand-built
minimal PipelineState (no S3 loader, no network, no live site config).

This gets icon rewriting, page metadata, and section metadata (#2756)
from the same mechanism instead of three separate reimplementations,
and fixes .plain.html serving raw unprocessed content along the way.
Sheet-based metadata.json overrides now go through the pipeline's own
Modifiers class instead of a hand-rolled glob matcher.

Supersedes #2759 and resolves #2756.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jul 9, 2026

Copy link
Copy Markdown

This PR will trigger a minor release when merged.

shsteimer and others added 7 commits July 9, 2026 12:03
…otate

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both content-html-pipeline.js and MetadataSheetSupport.js reach into
non-public internals of @adobe/helix-html-pipeline (individual steps,
Modifiers). Pulls all of that into one html-pipeline-internals.js
module instead of scattering deep imports (and eslint-disable
comments) across the two consumers.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The step list/order run in renderContentHtml is hand-copied from
htmlPipe()'s markdown branch, not introspected -- point at the exact
pinned-version source so a future reader can diff against it, and
call out that a step reorder/add/remove upstream won't fail loudly
on its own.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…fy-response

html-pipe.js imports these as `html` and `tohtml`; we'd renamed them
to makeHtml/stringify with no real reason. Keeping the same names
makes it easier to diff our hand-copied step sequence against the
upstream source (see the comment added above the sequence).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@shsteimer shsteimer requested review from kptdobe and tripodsan July 9, 2026 21:33
@shsteimer shsteimer marked this pull request as ready for review July 9, 2026 21:33
@tripodsan

Copy link
Copy Markdown
Contributor

cool. but this looks rather complicated, why not directly use the htmlPipe like here, for example:
https://github.com/adobe/helix-html2md-lib/blob/main/test/roundtrip/mock-pipeline.js

shsteimer and others added 3 commits July 10, 2026 08:37
Reaching into individual @adobe/helix-html-pipeline step modules to mirror
htmlPipe()'s internal order created a drift risk on every dependency bump.
Calling htmlPipe() directly against a minimal fake s3Loader (content md +
metadata.json) removes that risk and lets fetchSourcedMetadata build
sheet-based overrides itself, so MetadataSheetSupport no longer needs to
depend on Modifiers internals either.

Requires stripping .html to a clean path before constructing the pipeline
request, since htmlPipe treats a literal /foo.html as a code-bus static
file and skips markdown rendering (production only requests clean paths).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Passes the project's actual AEM org/site into renderContentHtml() instead
of hardcoded placeholders, so local rendering matches production more
closely if a future pipeline step or cdn config starts keying behavior off
them. owner/repo/ref stay 'local' -- they're code-bus (GitHub) identifiers
with no da.live equivalent, and this path never touches the code bus.

Also simplifies the index-path check (a string ending in '/index' already
covers the exact-match case).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
These two scenarios (falls back to a broader URL-pattern rule; no rows
match the requested path) were covered in the deleted
metadata-sheet-support.test.js, which unit-tested our own URL-glob
matching. That matching now lives entirely in helix-html-pipeline's
Modifiers class, but the boundary we still own -- feeding sheet rows
across via the loader -- is worth exercising end-to-end rather than
trusting upstream's tests alone.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@shsteimer

shsteimer commented Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

cool. but this looks rather complicated, why not directly use the htmlPipe like here, for example: https://github.com/adobe/helix-html2md-lib/blob/main/test/roundtrip/mock-pipeline.js

Thanks. as I was doing, I figured there'd be a simpler way; Updated with this approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants