{"id":90,"date":"2026-10-26T08:00:00","date_gmt":"2026-10-26T07:00:00","guid":{"rendered":"https:\/\/hoja.in\/blog\/ddev-for-a-typo3-site-and-a-wordpress-blog-in-one-project\/"},"modified":"2026-10-16T14:00:12","modified_gmt":"2026-10-16T12:00:12","slug":"ddev-for-a-typo3-site-and-a-wordpress-blog-in-one-project","status":"publish","type":"post","link":"https:\/\/hoja.in\/blog\/ddev-for-a-typo3-site-and-a-wordpress-blog-in-one-project\/","title":{"rendered":"DDEV for a TYPO3 site and a WordPress blog in one project"},"content":{"rendered":"

Hi folks,<\/p>\n

For years my blog lived on its own subdomain, blog.hoja.in, with its own folder on the hosting and its own database. When I rebuilt hoja.in this year on TYPO3 14.3, I moved the blog to hoja.in\/blog. One domain, one repository, and locally one DDEV project. I was a bit afraid of this, because TYPO3 and WordPress both want to own the URL space with their rewrite rules. It turned out simpler than expected. Here is the setup exactly as it runs on my Mac.<\/p>\n

The layout<\/h2>\n
myport\/\n\u251c\u2500\u2500 .ddev\/\n\u2502   \u251c\u2500\u2500 config.yaml          # TYPO3 project, generated by ddev config\n\u2502   \u2514\u2500\u2500 config.myport.yaml   # my additions\n\u251c\u2500\u2500 config\/                  # TYPO3 system and site configuration\n\u251c\u2500\u2500 public\/                  # web root\n\u2502   \u251c\u2500\u2500 .htaccess            # TYPO3 rules\n\u2502   \u251c\u2500\u2500 index.php            # TYPO3\n\u2502   \u2514\u2500\u2500 blog\/                # WordPress 7.1\n\u2502       \u251c\u2500\u2500 .htaccess        # WordPress rules with RewriteBase \/blog\/\n\u2502       \u251c\u2500\u2500 wp-config.php\n\u2502       \u2514\u2500\u2500 wp-config-ddev.php\n\u251c\u2500\u2500 Source\/Extension\/sitepackage\/\n\u2514\u2500\u2500 composer.json<\/code><\/pre>\n
WordPress is simply a folder inside the TYPO3 web root. Its core files are in git next to the TYPO3 project, the WordPress uploads are too, and the TYPO3 vendor\/<\/code> folder is not.<\/p>\n
Step 1: the DDEV config<\/h2>\n
The main file is what ddev config<\/code> generated for a TYPO3 project, with PHP and the database pinned:<\/p>\n
name: myport\ntype: typo3\ndocroot: public\nphp_version: \"8.4\"\nwebserver_type: apache-fpm\ndatabase:\n    type: mariadb\n    version: \"10.11\"\ncomposer_version: \"2\"<\/code><\/pre>\n
I chose apache-fpm<\/code> on purpose. Both TYPO3 and WordPress ship .htaccess<\/code> files, and the production hosting is Apache too. With nginx I would have to translate both rule sets and keep them in sync with production by hand. With Apache the same files work in both places.<\/p>\n
My own additions are in a second file. DDEV reads every config.*.yaml<\/code> in the folder and merges it, so I never touch the generated file:<\/p>\n
disable_settings_management: true\nweb_environment:\n  - TYPO3_CONTEXT=Development\/Ddev\nhooks:\n  post-start:\n    - exec: mysql -uroot -proot -e \"CREATE DATABASE IF NOT EXISTS blog CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; GRANT ALL ON blog.* TO 'db'@'%';\"\n      service: db<\/code><\/pre>\n
Three things happen here. disable_settings_management<\/code> stops DDEV from writing its own TYPO3 settings file, because my config\/system\/additional.php<\/code> is in git and handles DDEV itself. TYPO3_CONTEXT<\/code> lets the site configuration pick the local base URL. And the post-start hook creates a second database called blog<\/code> for WordPress, with rights for the normal db<\/code> user. It runs on every start, so IF NOT EXISTS<\/code> is important. (My real file creates a third database, legacy<\/code>, for the old TYPO3 7.6 data the import script read during the migration.)<\/p>\n
Step 2: WordPress config per environment<\/h2>\n
WordPress has no environment handling like TYPO3’s context, so I split wp-config.php<\/code>. The main file is in git and holds nothing secret:<\/p>\n
<?php\nif (getenv('IS_DDEV_PROJECT') === 'true') {\n    require __DIR__ . '\/wp-config-ddev.php';\n} else {\n    require __DIR__ . '\/wp-config-production.php';\n}\n\ndefine('DB_CHARSET', 'utf8mb4');\ndefine('DB_COLLATE', '');\n\n$table_prefix = 'myblog_';\n\ndefined('WP_DEBUG') || define('WP_DEBUG', false);\n\nif (!defined('ABSPATH')) {\n    define('ABSPATH', __DIR__ . '\/');\n}\n\nrequire_once ABSPATH . 'wp-settings.php';<\/code><\/pre>\n
DDEV sets IS_DDEV_PROJECT=true<\/code> inside the containers. The DDEV file then points to the second database and the local URL:<\/p>\n
define('DB_NAME', 'blog');\ndefine('DB_USER', 'db');\ndefine('DB_PASSWORD', 'db');\ndefine('DB_HOST', 'db');\ndefine('WP_HOME', 'https:\/\/hoja.in\/blog');\ndefine('WP_SITEURL', 'https:\/\/hoja.in\/blog');\ndefine('WP_ENVIRONMENT_TYPE', 'local');\ndefine('WP_DEBUG', true);\ndefine('WP_DEBUG_LOG', true);\ndefine('WP_DEBUG_DISPLAY', false);\n\/\/ plus the salts<\/code><\/pre>\n
The production file has the real credentials and is in .gitignore<\/code>. Old habit from the hosting days, but a good one.<\/p>\n
Step 3: the rewrite rules<\/h2>\n
This was the part I worried about, and the answer is boring in a good way. Apache reads the .htaccess<\/code> of the deepest directory. A request to \/blog\/some-post\/<\/code> is handled by public\/blog\/.htaccess<\/code>, and its rewrite rules replace the ones from the TYPO3 file one level up, because mod_rewrite does not inherit parent rules unless you ask for it. So the WordPress file only needs the right base:<\/p>\n
<IfModule mod_rewrite.c>\nRewriteEngine On\nRewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]\nRewriteBase \/blog\/\nRewriteRule ^index.php$ - [L]\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteRule . \/blog\/index.php [L]\n<\/IfModule><\/code><\/pre>\n
That is the standard block WordPress writes itself, with \/blog\/<\/code> instead of \/<\/code>. Everything outside \/blog\/<\/code> still goes to TYPO3. In TYPO3 the “Blog” menu entry is a page of the type Link pointing to \/blog\/<\/code>.<\/p>\n
Step 4: import and export both databases<\/h2>\n
DDEV’s database commands take a --database<\/code> flag, so the blog database is handled like the main one:<\/p>\n
# TYPO3 (default database \"db\")\nddev import-db --file=hojain_v14.sql.gz\nddev export-db --file=.project-migration\/backups\/pre-change.sql.gz\n\n# WordPress (database \"blog\")\nddev import-db --database=blog --file=blog.sql\nddev export-db --database=blog --file=.project-migration\/backups\/blog-pre-change.sql.gz\n\n# Both at once, as a DDEV snapshot of the whole database server\nddev snapshot --name=before-upgrade<\/code><\/pre>\n
After importing an old blog dump, the URLs inside the database still point to the old domain. WP-CLI fixes that, and it is already inside the DDEV web container. Because my project type is typo3<\/code>, I call it with ddev exec<\/code> in the blog folder:<\/p>\n
ddev exec --dir \/var\/www\/html\/public\/blog wp search-replace \n  'https:\/\/blog.hoja.in' 'https:\/\/hoja.in\/blog' \n  --all-tables-with-prefix --precise --dry-run<\/code><\/pre>\n
Run it with --dry-run<\/code> first and read the counts. Then without. search-replace<\/code> handles serialized PHP arrays correctly, which a plain SQL REPLACE()<\/code> would break.<\/p>\n
Step 5: check both apps in one go<\/h2>\n
Two applications means two ways to break things. I keep a plain list of URLs in the repository, old TYPO3 pages and new ones, plus the blog front page and one blog post, and run them through curl after every change:<\/p>\n
grep -v '^#' .project-migration\/urls.txt | while read -r url; do\n  printf '%s %sn' \"$(curl -sk -o \/dev\/null -w '%{http_code}' \"$url\")\" \"$url\"\ndone<\/code><\/pre>\n
Every line should start with 200. If a WordPress URL suddenly returns the TYPO3 404 page, the blog .htaccess<\/code> is missing or has the wrong base. If a TYPO3 URL returns a WordPress page, something is very wrong with the document root. The check costs two seconds.<\/p>\n
Mail is the other shared thing. DDEV catches every outgoing mail in Mailpit, so the TYPO3 contact form and WordPress comment notifications both land there instead of in a real inbox. That is how I tested the new EXT:form contact form of hoja.in before going anywhere near production.<\/p>\n
What I would tell my younger self<\/h2>\n