After converting the WordPress export to Markdown, you will find `<!– more –>` tags in your content. These tags serve as delimiters in WordPress, allowing you to define where the excerpt ends on listing pages.

The Challenge

Astro does not provide a built-in mechanism to handle these tags. I also could not find a suitable plugin that would manage this functionality.

My first approach was to use a Remark plugin like remark-excerpt. However, this did not work as expected. Instead of adding an Excerpt property to the frontmatter or to the data object of the content collection, it simply replaced the Content with the Excerpt.

Writing a custom Remark plugin proved challenging as well. While extracting the excerpt markdown is straightforward, rendering it to HTML is not. Since Astro does not expose its renderer (yet*), you would need to create your own renderer or use Astro’s internal `astrojs/markdown-remark`. Both approaches are rather hacky and not really recommended.

* There are ongoing discussions about making the renderer API public: Astro Roadmap Discussion #1094.

The Solution

The current best way to handle the WordPress More Tag in Astro is to split the rendered HTML content directly.

On the list page where you want to display the excerpt, you can map over the entries, split the rendered HTML at the <!--more--> tag, and add the excerpt to the return object:

const previewPosts = await Promise.all(
	posts.map(async (post) => {
		const fullHtml = post.rendered?.html || '';
		const moreIndex = fullHtml.indexOf('<!--more-->');
		const excerptHtml = moreIndex !== -1 ? fullHtml.slice(0, moreIndex) : fullHtml;
		const hasMore = moreIndex !== -1;
		return { post, hasMore, excerptHtml };
	}),
);

{previewPosts.map(({ post, hasMore, Content }) => (
	<div class="preview-content">
		<Content />
	</div>
	{hasMore && <p class="read-more">Read more...</p>}
))}

Straightforward and effective :)

For Astro there is astro-og-canvas, a nice and useful Astro plugin that utilizes Canvas to create dynamic OG images.

In this post, I’ll walk you through how to generate dynamic OG images for your Astro site, inspired by Aidan Kinzett’s excellent post.
I’ll also share some odds and learned lessons.

Step 1: Set Up `astro-og-canvas`

First, install the package:

npm install astro-og-canvas

Create a new file at src/pages/og/[...routes].ts.
This will dynamically generate images for your content.
Here’s how I set it up for my newsletter collection:

import { OGImageRoute } from "astro-og-canvas";
import { getCollection } from "astro:content";

// Fetch all newsletter entries
const newsletters = await getCollection("newsletter");

// Map newsletters to OG image configurations
const pages = {
  ...Object.fromEntries(
    newsletters.map((newsletter) => [
      newsletter.data.slug,
      {
        data: {
          title: newsletter.data.title,
          description: newsletter.data.newsletter.parts
            .map((part) => `${part.emoji.icon} ${part.title}`)
            .join(" • "),
        },
        slug: newsletter.data.slug,
      },
    ])
  ),
};

export const { getStaticPaths, GET } = OGImageRoute({
  param: "route",
  pages,
  getImageOptions: async (_, { data, slug }) => ({
    title: `Ivo's Ecotainment Newsletter: ${data.title}`,
    description: data.description,
    bgGradient: [
      [255, 221, 0], // Yellow (from logo)
      [255, 255, 255], // White
    ],
    logo: {
      path: "./public/Ivos-Ecotainment-Newsletter_Salamander.png",
      size: [1080],
    },
    border: {
      color: [83, 174, 90], // Green accent
      width: 2,
      side: "inline-start",
    },
    font: {
      title: {
        size: 42,
        weight: "Bold",
        families: ["Noto Sans", "Noto Color Emoji"],
        color: [0, 0, 0],
      },
      description: {
        size: 20,
        weight: "Normal",
        families: ["Noto Sans", "Noto Color Emoji"],
        color: [0, 0, 0],
        lineHeight: 1.4,
      },
    },
    fonts: [
      "./public/fonts/Noto_Sans/NotoSans-VariableFont_wdth,wght.ttf",
      "./public/fonts/Noto_Color_Emoji/NotoColorEmoji-Regular.ttf",
    ],
    padding: 50,
  }),
});

Some learned lessons:
1. Logos: SVGs won’t work here. Use PNGs instead.
2. Fonts: Add font files, if you use fonts.
3. Emojis: If you use emojis in your content, include an emoji font (like “Noto Color Emoji”) to ensure they render correctly.

Step 2: Integrate with astro-seo

I use the astro-seo component in my main Layout component to handle SEO metadata.

For the OG image I add a prop to be passed from the respective page:

const { title, description, ogImage } = Astro.props;

<SEO
  title={title}
  description={description}
  openGraph={{
    basic: {
      title,
      type: "website",
      image: ogImage || `${Astro.site}Ivos-Ecotainment-Newsletter_big.png`, // Fallback
    },
  }}
/>

In Your Content Pages:
Construct the OG image path and pass it to your layout:

const ogImage = `${Astro.site?.href || ""}og/${entry.data.slug}.png`;

<Layout title={entry.data.title} description={description} ogImage={ogImage}>
  {/* Post content */}
</Layout>

Astro Odds:

A bit odd is if your astro.config.mjs has trailingSlash: "always", you’ll need to add a trailing slash to OG image URLs in development:
http://localhost:4321/og/${entry.data.slug}.png/

In prod (no trailing slash needed) so you can just pass it as: http://localhost:4321/og/${entry.data.slug}.png

3. Testing OG Images

As recommend in the Blog post of Aidan Kinzett: Use opengraph.xyz to preview your OG images before sharing links.
Very good tool!

Here is how the OG image looks like with logo, title and description with emojis:

Happy hacking!

First, add the Obfuscate-Link web component to the project:

npm install obfuscate-link-web-component

Now register ObfuscateLink with customElements: 

<body>
    <slot />
    <script>
      import { ObfuscateLink } from 'obfuscate-link-web-component';
      // Only define the custom element if it hasn't been defined yet
      if (!customElements.get('obfuscate-link')) {
        customElements.define('obfuscate-link', ObfuscateLink);
      }
    </script>
</body>

This occurs in the Layout.astro component, making it available across all pages. The registration happens within a script tag in the HTML to execute only on the client side, avoiding it execution while SSR rendering performed by Astro beforehand.

Next, create an Astro component that wraps the web-component and handles the obfuscation by encoding the passed prop.

---
type BaseProps = {
  id?: string;
}
type EmailProps = BaseProps & {
  email: string;
  tel?: never;
  sms?: never;
  facetime?: never;
  href?: never;
}
type TelProps = BaseProps & {
  email?: never;
  tel: string;
  sms?: never;
  facetime?: never;
  href?: never;
}
type SmsProps = BaseProps & {
  email?: never;
  tel?: never;
  sms: string;
  facetime?: never;
  href?: never;
}
type FacetimeProps = BaseProps & {
  email?: never;
  tel?: never;
  sms?: never;
  facetime: string;
  href?: never;
}
type HrefProps = BaseProps & {
  email?: never;
  tel?: never;
  sms?: never;
  facetime?: never;
  href: string;
}
export type Props = EmailProps | TelProps | SmsProps | FacetimeProps | HrefProps;
const props = Astro.props;
const { id } = props;
// Find the active prop (email, tel, sms, facetime, or href)
const activeProp = Object.entries(props).find(([key, value]) => 
  key !== 'id' && value !== undefined
);
let attribute = '';
let value = '';
if (activeProp) {
  [attribute, value] = activeProp;
  const orgValue = value;
  value = Buffer.from(value).toString('base64');
}
---

<obfuscate-link
  id={id}
  {...{[attribute]: value}}
><slot /></obfuscate-link>

Finally, you can utilize both the Astro component and the Web component throughout your Astro project.

---
import ObfuscateLink from './ObfuscateLink.astro';
---

<div class="card">
  <p>
    Email: <ObfuscateLink email="info@example.com" />
  </p>
</div>

The complete code can be seen in this Gist:

https://gist.github.com/ivoba/222d5a49ad4542392772195c5e5ad032

I adjusted it to Pico V2 in a Astro component, ready to use in a Astro project with Pico V2 as CSS framework.
Since the component is just one file i just a made a gist: https://gist.github.com/ivoba/f3e0a8d7423faf318ce2217f5af9c510

Here is how to use it, f.e. in your navigation:

---
import ThemeSwitcher from "./ThemeSwitcher.astro";
---

...
  
<li>
  <ThemeSwitcher />
</li>

Update:
I added a persistence layer for localStorage to the Gist.
So the selected theme is remembered between pages.

Therefore, I created a web component: obfuscate-wc that now provides an HTML element capable of obfuscating your email (and some other contact data).

 <obfuscate-link id="obfuscate" email="aXZvQGxvY2FsLmRldg==">custom link</obfuscate-link>

The component accepts an encoded email address, rendering it human-readable after events that typically align with human browsing behavior.
Custom decoders can be configured, with the default set to base64.
While sophisticated spam crawlers may still manage to decode the email, the likelihood decreases as you customize your encoder/decoder. It’s worth noting that the decoder could also be crawled, but the assumption is that this presents too much effort for the crawlers.

Using the web component itself is already blocking spammer that just look for mailto links.

How did I get there?

When using React I took this React component: https://github.com/coston/react-obfuscate

In a new project, I began using Astro, and React became unnecessary. However, I found myself missing the obfuscation component. Consequently, I chose to create a web component with similar functionality. This endeavor also served as a valuable exploration into web components. Web components, native to the browser, enable you to define your own HTML tags with specific functionality within the component.

Since the API of the web components is not the nicest, let’s say.
I took StencilJs which is a framework for Web Component development.
It also comes with nice tooling like Typescript support, tests and builds helpers.

I crafted it with Stencil, learned the process of building the component–admittedly, this was a bit cumbersome–but now it’s ready for use in any web application.

1. Content changed rarely and when, authors forgot how to do it and asked me anyway.
2. Content is now part of development.
   The “paid” support time is now rather spent for adding content than for helping the authors adding their content.
   They will just send me an email.
3. Content is now versioned in git.
4. Hosting is cheaper, no need for the PHP Mysql package.
5. A static site is easier to host. No forced PHP updates by the hoster.
6. No security attack vectors on the site. Try this with WordPress ;)
7. Astro comes with topnotch frontend tooling and green lighthouse audit by default. Try this with your CMS ;)
8. Contact forms are overrated. Mailto links work. If a contact form is your only dynamic requirement, ditch it and consider to go static.
9. A static site loads faster and does not need to run the compute cycles of a dynamic language or a database.
10. Last but not least: A static site presumably has a lower carbon footprint out of the box because of less computing and optimized frontend tooling.

This is based on of a twitter thread of mine and crossposted here for the sake of owning my content. :)