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!

The Yazi package manager ya will be used to install the plugins mentioned below, which is shipped with Yazi.

For the installation of necessary terminal tools, I will use brew, since I am currently on OSX. For Linux use the equivalents like apt.

1. MediaInfo

The MediaInfo plugin adds detailed information to the preview of media files such as JPG, PNG, and other media formats.

Especially Width, Height and Size is very useful.

Installation:

1. Install MediaInfo terminal tool using Brew: brew install mediainfo
2. Add the plugin to Yazi: ya pack -a boydaihungst/mediainfo
3. Add the necessary configuration to your yazi.toml file.

2. DuckDB

DuckDB.yazi is a plugin for handling CSV, TSV and Parquet files.
It uses DuckDB under the hood for adhoc rendering of the data files.

It can also render JSON files as tables, but I have not enabled this, because I want json files preview to just render json as is.
So I just added the viewers for tsv and csv in yazi.toml:

{ name = "*.csv", run = "duckdb" },
{ name = "*.tsv", run = "duckdb" },

3. Glow

Glow.yazi is a plugin for previewing Markdown files.
I uses terminal markdown renderer Glow.

Installation:

1. Install Glow: brew install glow
2. Add the plugin to Yazi: ya pack -a Reledia/glow.yazi

Note: the plugin is deprecated by now in favour of the new Piper plugin, a general-purpose previewer.
I might check this out as well in the near future.

4. Ouch.yazi

This plugin uses Ouch for handling zip, tar, and other archive formats.

Installation:

1. Install Ouch and 7-zip using Brew: brew install ouch 7-zip
2. Add the plugin to Yazi: ya pack -a ndtoan96/ouch
3. Add the “C” to your `keymap.toml` file to compress files:
   [[mgr.prepend_keymap]]
on = ["C"]
run = "plugin ouch"
desc = "Compress with ouch"

Simply press “Enter” on an archive file should uncompress the archive.

5. OpenWithCmd

OpenWithCmd is a plugin for opening files with specific commands, such as opening a file in LibreOffice. In Finder one would usually use right click “Open with” dialog.

Installation:

1. Add the plugin to Yazi: ya pack -a Ape/open-with-cmd.yazi
2. Add the “o” and “O” to your `keymap.toml` file to open the OpenWith dialog:
   [[mgr.prepend_keymap]]
on = "o"
run = "plugin open-with-cmd --args=block"
desc = "Open with command in the terminal"
[[mgr.prepend_keymap]]
on = "O"
run = "plugin open-with-cmd"
desc = "Open with command“

To open a file in LibreOffice from Yazi, type “o” and enter calc type:soffice --calc in the dialog.

Note that the window might not focus directly, and you may need to check if it is opened in the background.

This plugin overrides the `o/O` keymap, but you can still use `Enter` or `Shift+Enter` to open files directly in the default app.

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

Deployer executes a set of commands on the target server to build your project and enable the newly built version. A typical deployment process with Deployer involves SSHing into the target machine, where it performs a Git checkout of the project, installs dependencies via Composer, runs build commands, and possibly triggers some database migrations. When everything is successful, it will symlink the webroot to the new release.

On some servers, however, there are limitations that make this process unfeasible. For instance, you can’t install Composer, Git isn’t available, the CLI PHP version is different and can’t be changed, or certain asset-building processes aren’t possible because Node.js isn’t installed. This is often the case with shared hosting.

The strategy, therefore, is to build the project locally and upload it to the target machine.
In Deployer 6 there was a buildIn mechanism for building your project on the local host.
However with Deployer version 7 this has been removed and building your project locally has become a bit more fiddly.

With Deployer 6 you could just use the local() method on a task and set the deploy_path to a local dir.

task('build', function () {
    set('deploy_path', __DIR__ . '/.build');
    invoke('deploy:prepare');
    invoke('deploy:release');
    invoke('deploy:update_code');
    invoke('deploy:vendors');
    invoke('deploy:clear_paths');
    invoke('deploy:symlink');
})->local();

Then you could combine this with an upload task in a deploy task an you are done.

task('upload', function () {
     upload(__DIR__ . "/.build/current/", '{{release_path}}', ['--links']);
 });

 task('deploy', [
     'build',
     'upload',
     'cleanup',
     'success'
 ]);

See here for the docs of Deployer 6:
https://deployer.org/docs/6.x/advanced/deploy-strategies#build-server

Since Deployer 7, however, the local() method was removed. Instead, there is now a localhost() method, which defines a host for local builds. Additionally, you still need to define the remote host as the target destination for the upload.
However, you cannot specify a single task to run on a specific host, and therefore you cannot combine tasks for localhost and the remote host within a single task.

To build the project, we now need two separate tasks.
I managed to make it work with two tasks and two hosts: one for local build and one that takes the fresh local build and uploads it to the remote host.

localhost('local')->set('deploy_path', __DIR__ . '/.build');

host('remote')
    ->setHostname('server-host.com')
    ->set('remote_user', 'user')
    ->set('deploy_path', '/www/blog')
    ->set('http_user', 'user');
....

task('build', function () {
    // build it
})->once();

task('upload', function () {
    upload(__DIR__ . "/.build/current/", '{{deploy_path}}', ['--links']);
});

Then I simply run two separate commands: one for building on the local host and one for uploading to the remote host.

vendor/bin/dep build local
vendor/bin/dep upload remote

Not as convenient as previously but it works. :)

See this issue for context: https://github.com/deployphp/deployer/issues/2838

The plan was to use chrome-php with a headless chrome to generate the PDF.

Usually you would install chrome/chromium on a linux server via apt and just run chrome from the PATH with chrome.
Since i was on shared hosting i was not sure if this was possible since i was not allowed to run apt commands.
So i tried to use Puppeteer which ships a headless chrome executable and use just this directly.
I installed Puppeteer with npm locally and uploaded the chrome executable to the shared hosting.
Puppeteer will place the headless chrome in the .cache dir in your home directory, f.e.:

~/.cache/puppeteer/chrome/linux-113.0.5672.63/chrome-linux64/chrome

Upload:

scp -r ~/.cache/puppeteer/chrome/linux-113.0.5672.63/chrome-linux64 me@sharedhosting:/usr/home/test

I also created a nice little command line tool to create the pdf with chrome-php.
I used minicli which is a “minimalist, dependency-free framework for building CLI-centric PHP applications”.
So you can create cli commands fast and without all the clutter, exactly what i needed for this small test.
You can find the code on Github: https://github.com/ivoba/chrome-php-minicli
The command is here: https://github.com/ivoba/chrome-php-minicli/blob/main/command.php

Then i tried to generate the pdf:
CHROME_PATH="/usr/home/test/chrome" php command.php pdf url=https://ivo-bathke.name

However this failed because the server lacked required dependencies to run the chrome executable.
You can check this by running this command:

me@sharedhosting:/usr/home/test$ ldd chrome-linux64/chrome | grep not
libatk-1.0.so.0 => not found
libatk-bridge-2.0.so.0 => not found
libxkbcommon.so.0 => not found
libatspi.so.0 => not found
libXcomposite.so.1 => not found
libXrandr.so.2 => not found
libgbm.so.1 => not found

Ok, so it wont work with the uploaded chrome executable.
What a pity but still a finding.

In the end i contacted the support and fortunatly they were willing and able to install chromium via apt. Nice!

Eventually it worked with:
CHROME_PATH="chromium" php command.php pdf url=https://ivo-bathke.name

Pdf created :)

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. :)

There are several ways to import the data in your docker-compose setup.

1. Using a volume for import data
2. Using mysql client from commandline with docker-compose exec
3. Using phpmyadmin in docker-compose setup
4. Using a mysql GUI client on the host and connect to the DB in the Docker container

So let’s see how we can do this:

1. Using a volume for import data

This applies to both official Mysql and MariaDB official images.
These have builtin import mechanism to import data.
To quote from the docs:

Furthermore, it will execute files with extensions .sh, .sql and .sql.gz that are found in /docker-entrypoint-initdb.d. Files will be executed in alphabetical order. You can easily populate your mysql services by mounting a SQL dump into that directory

So all dumps that are found in the /docker-entrypoint-initdb.d directory of the image will be imported unless the database already contains data.

So let’s add this volume to our docker-compose.yaml

volumes: - ./database_dump.sql:/docker-entrypoint-initdb.d/datadump.sql

On next docker-compose up the data will be imported in your empty database.
You will see something like this in your docker-compose logs:

2023-02-06 15:40:16+00:00 [Note] [Entrypoint]: /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/database_dump.sql

Note: if there is already data in the database you need to clear the data first by f.e. clearing the volume, otherwise the import will not start:
You can clear all volumes of your docker-compose setup with (caution: this will clear all volumes, not just the database volume):

docker-compose down -v

2. Using mysql client from commandline with docker-compose exec

With this one liner you can import a SQL dump from a docker image that has a MySql/MariaDB client installed and are linked to the DB container:

docker-compose exec my-app bash -c "mysql -u root -h mysql --password=root database < database_dump.sql"

This will execute the application image and import the data with the mysql client which connects to the host mysql which is the linked mysql container.

3. Use phpmyadmin in docker-compose setup

If the above is too consolish then you also can just add a phpmyaadmin container in your docker-compose setup and administer the database with a GUI from the browser.

  myproject_phpmyadmin:
	image: phpmyadmin/phpmyadmin:latest
	ports:
	  - 8080:80
	environment:
	  PMA_HOST: myproject_mysql

Then you can just open http://localhost:8080 in the browser and log into to Phpmyadmin.
To import data go to the import tab and upload the dump file.

4. Using a mysql GUI client on the host and connect to the DB in the Docker container

For this approach you just need to open a port in the database container to the outside and use this port with localhost in the settings of your database client.

  myproject_mysql:
    image: mysql:5.7
    hostname: mysql.${DOMAIN}
    container_name: ${CONTAINER_NAME}.mysql
      volumes:
	- ${PWD}/data/mysql/:/var/lib/mysql
	- ./container/mysql/my.cnf:/etc/mysql/conf.d/z_my.cnf
    ports: # open the mysql port to the host
      - "3306:3306"
    environment:
  ...

See this screenshot from IntellIj’s PHPStorm Database tool:

From my experience these clients are very good to check data but not so good for import, at least I had rather poor experience in the PHPStorm DB Tool.
So going consolish on imports is recommended :)

Since we blog a lot about PHP in general and Symfony in particular https://phpc.social seems like a good choice for us as our Mastodon instance.

If you are a PHP nerd you might consider to join this instance as well.

Other fits could be:

• https://phparch.social the Mastodon instance of php[architect] Magazine
• https://fosstodon.org it is a broader community around all OpenSource Software
• https://uiuxdev.social a more frontend resp. web development focused Mastodon community

If you wonder how to find well know figures from the PHP scene on Mastodon Spatie’s Freek Van der Herten got you covered: https://freek.dev/2384-laravel-and-php-developers-to-follow-on-mastodon

Happy Tooting!

So since version 5.1 symfony will log deprecations to a dedicated log channel when it exists and ships with this monolog config:

monolog:
    channels:
        - deprecation # Deprecations are logged in the dedicated "deprecation" channel when it exists

This is added already in the recipe and ships when installing symfony.

Ok, but the handler for this deprecation channel is not configured, so you have to do this yourself.
How? Add this to your monolog config:

...
when@dev:
   monolog:
       handlers:
           main:
	       type: stream
	       path: "%kernel.logs_dir%/%kernel.environment%.log"
	       level: debug
	       channels: ["!event", "!deprecation"]
	   deprecation:
	       type: rotating_file
	       path: "%kernel.logs_dir%/%kernel.environment%.deprecations.log"
	       max_files: 2
	       channels: [deprecation]
	   console:
	       type: console
	       process_psr_3_messages: false
               channels: ["!event", "!doctrine", "!console", "!deprecation"]
...

What is happening here?
We declare a new handler for deprecations named deprecation when in dev environment.
This handler listens to the deprecation channel.
We declare it as a rotating file since the assumption is we dont need to keep this log entries for longer.
The other handlers will ignore the deprecation channel by adding a !deprecation to the channel directive.

The deprecation channel was already created and so all deprecations are now not in the main log file but in a dedicated deprecation log file.

For production we dont need to edit configuration since the log level here is info and therefore deprecations will not be considered anyway.