https://frankenphp.dev/install.sh should ask whether the installation will be used to run Wordpress, and use saner defaults

[glenstewart]

Describe your feature request

Users trying to use Frankenphp to serve up Wordpress are having a steep learning curve. My personal experience is coming from a working Caddy installation - one would assume this would be somewhat easy, but it's not.

If install.sh was modified to ask whether the installation will be used to run Wordpress, some crucial settings could be set/suggested to ensure a better experience, so people are not turned off by FraknenPHP.

Suggestions:

Add this to a custom Wordpress site plugin:

add_filter('wp_image_editors', function($editors) {
return array('WP_Image_Editor_GD', 'WP_Image_Editor_Imagick');
});

Why?
//WordPress defaults to Imagick if the PHP extension is available. Imagick is notorious for causing segmentation faults under FrankenPHP's C-bindings (Go/CGO memory space allocations) when handling complex image types like webp or progressive jpegs. Force WordPress to use the standard, more stable GD library by adding this filter to your theme's functions.php file.

Set these settings in php.ini:

memory_limit = 512M
max_execution_time = 300
max_input_time = 300

Set these values in /usr/lib/systemd/system/frankenphp.service:

After=network.target network-online.target mariadb.service
User=www-data
Group=www-data
ReadWritePaths=/usr/share/wordpress/

A suggestion to install the following PHP modules:
apt-get install php-zts-gd php-zts-gettext php-zts-imagick php-zts-intl php-zts-mysqli php-zts-mysqlnd php-zts-pdo-mysql php-zts-pdo php-zts-zip

Finally, provide a link for basic instructions to modify the Caddyfile if they are transitioning from Caddy/PHP-FPM to Frankenphp.

Thank you

[henderkes]

//WordPress defaults to Imagick if the PHP extension is available. Imagick is notorious for causing segmentation faults under FrankenPHP's C-bindings (Go/CGO memory space allocations) when handling complex image types like webp or progressive jpegs. Force WordPress to use the standard, more stable GD library by adding this filter to your theme's functions.php file.

Since when? I've been using Imagick in development and production with FrankenPHP for 3 years and haven't had a single crash related to it.

Set these settings in php.ini:

memory_limit = 512M
max_execution_time = 300
max_input_time = 300

That sounds like a very, very, very, very bad idea. If anything we should lower max_execution_time to 10-15s, but I'm closely following what Remi (RHEL, Fedora, etc.) ships.

Set these values in /usr/lib/systemd/system/frankenphp.service:

After=network.target network-online.target mariadb.service
User=www-data
Group=www-data
ReadWritePaths=/usr/share/wordpress/

This will break unless you set up correct permissions for www-data to access and write into frankenphp's folders. FrankenPHP also doesn't depend on mariadb or the www-data user existing, so this is not even an option.

Add this to a custom Wordpress site plugin:

add_filter('wp_image_editors', function($editors) {
return array('WP_Image_Editor_GD', 'WP_Image_Editor_Imagick');
});

I don't understand how this would even work. Is the install script supposed to magically figure out you have a WordPress folder setup somewhere?

[glenstewart]

I appreciate all you do for Frankenphp.

I run a Wordpress site with over 37,000 articles for over 10 years. I've bumped into some "restraints" over time - plugins needing to wait on long-running MySQL queries, plugins doing mass-conversion of images (eg. jpg to AVIF), search-and-replace of strings in posts, etc, etc.

After switching from Caddy/PHP-FPM to Frankenphp, I lost the ability to auto-convert uploaded JPG to AVIF. This affected several plugins, like Bunny.net (CDN), Instant Images, and Modern Image Formats (made by Perfomance Labs). The filter to switch from Imagick to GD solved the problems with all plugins immediately.

I think Frankenphp is a wonderful solution. I love the single-process perspective from an administrator's viewpoint (installation and monitoring), where I can see what the WHOLE delivery system is costing me in CPU and RAM - at one glance. That's why I worked thru the issues.

My hope is that my post will pave the way for Frankenphp to be adopted by other admins frustrated with the complexity of their architecture.

[henderkes]

After switching from Caddy/PHP-FPM to Frankenphp, I lost the ability to auto-convert uploaded JPG to AVIF. This affected several plugins, like Bunny.net (CDN), Instant Images, and Modern Image Formats (made by Perfomance Labs). The filter to switch from Imagick to GD solved the problems with all plugins immediately.

That sounds like a misconfiguration in my packages (assuming it's using them). Are you using the Debian packages? Could you paste the phpinfo() output of your frankenphp?

[henderkes]

Hah, I actually found an issue, though I'm not sure it's related to the one you were facing. The x86-64-v3 baseline on github ci runs compiles amd-only instructions into imagemagicks libjpeg, meaning reading jpeg images fails on intel cpus.

[glenstewart]

Yes, that may be it. I am on Intel and the search I did on "illegal instruction" did come back with a compilation problem as possible cause. I'll test reverting this "fix" when the next Ubuntu/deb build comes out. Thanks!

…

On May 21, 2026 10:00:52 AM EDT, Marc ***@***.***> wrote: henderkes left a comment (php/frankenphp#2434) Hah, I actually found an issue, though I'm not sure it's related to the one you were facing. The x86-64-v3 baseline on github ci runs compiles amd-only instructions into imagemagicks libjpeg, meaning reading jpeg images fails on intel cpus. -- Reply to this email directly or view it on GitHub: #2434 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[henderkes]

Figured it out I believe, ImageMagick has a --with-gcc-arch parameter that performs build host cpu feature detection. Contrary to the parameters implication, it defaults to on.