When deviated from its default value, it can lead to inexpected behavior in common functions like json_encode() and serialize().

The Problem

If you change the serialize_precision setting from its default value of -1, the float precision will be more digits than 2 decimal places.
If you are not aware of this setting, it can lead to hard-to-debug issues in your application.

This behavior can silently break payload validation, API responses, or any logic that relies on exact string comparisons of numeric values or which assumes that float values come with 2 decimal places.

Impact on Functions

When serialize_precision is set to something other than -1, the following functions are affected:

• json_encode()
• json_decode()
• serialize()
• unserialize()

Consider the following example.
Setting a high precision changes the number in the JSON output:

<?php
// High precision
ini_set("serialize_precision", 100);
echo json_encode(12.12);
// Output: 12.1199999999999992184029906638897955417633056640625

// Default (recommended) precision
ini_set("serialize_precision", -1);
echo json_encode(12.12);
// Output: 12.12

How to Check Your Configuration

So better verify your current setting, especially when dealing with mysterious floating-point issues in legacy environments.
When on shared hosting, you might even not know that the setting was changed.

You can check it via code:

echo ini_get("serialize_precision");

Or, if you are using PHP 8.5 or newer, you can conveniently check for configuration differences using the CLI:

php --ini=diff

This will highlight any settings that differ from the PHP defaults, making it much easier to spot such dangerous configurations.

Conclusion

If you encounter unexpected floating-point behavior in your PHP application, check the serialize_precision setting first. It’s a simple fix that can save you hours of debugging.

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.

One click away in PHP Runtime Configuration docs you will find that in the php.ini the default value is “60”.
In case you wonder what unit these “60” is, you will find (in seconds) a bit down below the config table.
– Yeah, seconds was my first guess, but I need to assure it is not microseconds by any chance. –

And thats it! Thats the post.

P.S: It is funny how scattered information sometimes is, although is all there.
AI did know, but did not name a source.
And since AI is not to trust, I still had to look it up via Search.

For surfing the web, checking mails, editing and uploading some fotos it is sufficient and I prefer using a laptop for this.

I used to run Xubuntu on it, but lately it had performance issues and all programs and actions were lagging very significantly. So I decided to reinstall the OS and try Lubuntu, since it should be even more lean.

I grabbed the current Lubuntu image (25.04 Plucky Puffin), created a bootable USB stick, and installed Lubuntu. So far, so good. And indeed, everything felt much smoother and faster.

But, as usual, there are some post-installation hiccups which needed a bit more tuning.

1. Wifi
   WiFi was not working out of the box.
   The E145 ships with a Broadcom WiFi chip (BCM43142), and the drivers are proprietary and need to be installed separately. After some Googling and trying this and that, this finally worked for me:
   sudo apt install broadcom-sta-dkms
reboot
   And WiFi worked. :)
2. Encryption
   Another change is the encryption strategy:
   before I had only my home directory encrypted, but this option wasn’t available anymore in the Lubuntu installer.
   Apparently, encoding only the home directory is discouraged nowadays since it has some security flaws. (“Encrypting only the home directory leaves swap, temp files, and system logs unprotected, exposing sensitive data.”)
   So this time I encrypted the whole disk, as offered in the installer. However, now I would have to enter the passphrase to decrypt the disk and then I would also have to enter user credentials to log in. This felt a bit cumbersome, so I enabled auto-login since I will be the only user using this laptop. And now I only have to enter the passphrase and can immediately use it.
3. Browsers
   There are more and more browsers to choose from, so picking the right one becomes a task.
   I used to use Chromium, but since I have had rather bad experiences with the Snap install and there is no easy other way to install Chromium, I simply turned to Chrome.
   Not the best choice in privacy regards, admittedly. But I will be using my Google account on this browser anyway, and then it is the full package.
   For more privacy-focused browsing, I will use Librewolf, a Firefox clone with privacy and security focus.

Librewolf recommends installation on Ubuntu/Debian via the Extrepo tool.
Extrepo is a neat tool that takes care of adding external repositories and installing software from there in one command.

Turned out Extrepo can also install Chrome, so I installed both browsers with it.
First install Extrepo:
sudo apt update && sudo apt install extrepo -y
Then install Librewolf & Chrome:
sudo extrepo enable librewolf
sudo extrepo enable google-chrome

That’s it so far. Ready to use my old travel laptop for some more years with newest software.
Keep using old hardware!

Yazi can render previews for images and PDF files, but in my case, PDF previews weren’t showing up. Yazi requires Poppler for PDF previewing–and it was already installed on my system–the previews still didn’t work.

So I began debugging by running yazi --debug, which provides detailed information about your Yazi installation. Under the Dependencies section, I noticed a suspicious message:

pdftoppm      : ExitStatus(unix_wait_status(25344)),"pdftoppm version 4.0...

This should actually just render the version of pdftoppm by poppler like:

pdftoppm      : 25.04.0

So there was clearly some issue with Poppler and pdftoppm here.
Then I ran Yazi with a debug log enabled: YAZI_LOG=debug yazi
and checked the log file in ~/.local/state/yazi/yazi.log

And there was also an error:

ERROR yazi_scheduler::prework::prework: Error when running preloader pdf:
Failed to convert PDF to image, stderr: pdftoppm version 4.05 [www.xpdfreader.com]

It turns out that Xpdf was conflicting with the actual pdftoppm utility from Poppler. I had previously installed Xpdf for some reason, and it was now preventing Poppler from being installed properly. The error message confirmed the conflict:

Error: Cannot install poppler because conflicting formulae are installed.
xpdf: because poppler, pdftohtml, pdf2image, and xpdf install conflicting executables

So I uninstalled Xpdf via brew: brew unlink xpdf
Reinstalled Poppler via brew and now everything works nice:

Composer-patches is a handy Composer plugin that applies diff patches to specific packages during installation.

Basically, you store a diff patch in your project, specify which vendor package it should be applied to in your composer.json, and the plugin will apply the patch to the original code of the vendor package after it got installed by composer.

The documentation provides detailed instructions on how to set up the plugin.
In short, you need:

• Install the plugin (we’re using the v2 beta) with:
  composer require cweagans/composer-patches:^2.0.0-beta2
• Create a patch. The plugin relies on Git as the patcher, so you can use Git to generate the patch file. (See below)
  However, I recommend using another package to create the patch file:
  https://github.com/symplify/vendor-patches
  This package provides an opinionated but reasonable way to create and store your patches. vendor-patches takes care of the correct paths in the patch file, which might not be immediately obvious: Pathes should be relative to the vendor package root and not relative to your projects root dir.
• Add the patch instructions to your composer.json by including a patches section under extra. For example:

"extra": {
  "patches": {
    "oxid-esales/oxideshop-ce": {
      "Disable user registration due to spam attacks": "./patches/disable-registerUser.patch"
    }
  }
}

On your next composer install the vendor package will be patched and the vendor’s
code will be altered according the patch.

Some notes: If you encounter the error:

Could not apply patch! Skipping. The error was: Cannot apply patch disable-registerUser.patch

You might have incorrect paths in your patch file. As mentioned above, the paths need to be relative to the vendor root directory, not your project’s root directory.
So to manually create the diff patches, run this command:

diff --git a/source/Application/Component/UserComponent.php b/source/Application/Component/UserComponent.php

This is wrong usage from project root dir:

diff --git a/vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php b/vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php

Happy patching! :)

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

This is surprisingly not intuitive, as you cannot simply pass an array of integers to a prepared statement. Instead, you need to add special binding types to inform Doctrine that this is indeed an array of integers.

It’s very well explained in the documentation under the Parameters Conversion section:
https://www.doctrine-project.org/projects/doctrine-dbal/en/current/reference/data-retrieval-and-manipulation.html#list-of-parameters-conversion
But it is rather hard to find and it took me a while.

The trick is to add the array binding types to the the types parameters to the query method. In the case of integers, it is \Doctrine\DBAL\ArrayParameterType::INTEGER.
Now Doctrine knows how to handle the types in the array while binding the values.

Example:

$sql = 'SELECT * FROM items WHERE id IN (?)'; 
$numbersAsStrings = "1,2,3";
$numbers = array_map('intval', explode(',', $numbersAsStrings));
$users = $con->fetchAllAssociative(
  $sql, 
  [$numbers], 
  [ArrayParameterType::INTEGER]
);

If you omit the types, Doctrine will simply try to bind the array as string, which will fail and you get this error:
Array to string conversion

If you try to pass it as a comma-separated string yourself and omit the types like $numbers = implode(',',array_map('intval', explode(',', $numbersAsStrings))); You will get an error because Doctrine expects an array of values for the IN clause and not a string.
Error:
count(): Argument #1 ($value) must be of type Countable|array, string given

I hope this helps someone finding out how to make WHERE IN SQL queries with Doctrine more quickly than me next time.