macOS local install: site and /wp-admin both show a "Nothing Here Yet" page #513

Activity

1. ogorzalka

   added

   bugSomething isn't workingSomething isn't working

   documentationImprovements or additions to documentationImprovements or additions to documentation

   on Oct 20, 2026
2. ogorzalka commented on Oct 20, 2026

   

   ogorzalka

   on Oct 20, 2026 – with Claude

   MemberAuthor

   More actions

   Update from the reporter

   • Environment: macOS, Laravel Valet, PHP 8.4.2, VS Code. Installed with composer create-project.
   • APP_URL is pollora.test in .env, and siteurl is pollora.test/cms in the database.
   • The database exists.
   • The setup refused an empty database password, while their local MySQL uses root with no password. That is now Setup refuses an empty database password #515.

   What this changes

   Cause 1 (APP_URL mismatch) is less likely, since APP_URL and the browser URL now match on the host. Two points remain to check:

   • Does APP_URL have a scheme? The setup prompt refuses a value without http://, but a hand-edited .env (likely here, given the password problem) is not checked. With APP_URL=pollora.test, WP_HOME and WP_SITEURL have no scheme and every URL WordPress builds is relative to the current path.
   • Do home and siteurl in the database have the same scheme as APP_URL? Valet serves plain http unless valet secure was run.

   The Valet driver is ruled out, from Valet's source (cli/Valet/Drivers/ValetDriver.php, 01b8cef). LaravelValetDriver is tried before every specific driver, including WordPressValetDriver. It serves any directory with public/index.php and artisan, which the skeleton has. So public/wp-config.php cannot pull a Pollora project to the WordPress driver, unless a custom LocalValetDriver.php sits in the project.

   The page is not Valet's own either: its 404 template reads "404 - Not Found". The remaining Valet lead is the site name:

   • Valet serves <directory>.test. pollora.test only reaches this project if the directory is named pollora, or if it was linked under that name.
   • Otherwise Valet answers with its 404, or with the default site set in ~/.config/valet/config.json ("default"). That default would be another project, which could be the one showing "Nothing Here Yet" on every URL.

   Next questions for the reporter

   1. The exact line APP_URL=… in .env, with its scheme.
   2. The name of the project directory, and the output of valet links, valet paths and valet which (run in the project).
   3. Whether ~/.config/valet/config.json has a "default" entry, and whether LocalValetDriver.php exists in the project.
   4. curl -sI http://pollora.test/ and curl -sI http://pollora.test/wp-admin/.
   5. php artisan pollora:doctor.

   The reproduction on a rented Mac planned for tomorrow will cover these cases: Valet with a matching and a mismatching directory name, a default site, APP_URL with and without a scheme, and root with no password.

   ---

   Generated by Claude Code
3. ogorzalka commented on Oct 21, 2026

   

   ogorzalka

   on Oct 21, 2026

   MemberAuthor

   More actions

   First results of the reproduction (Linux, throwaway project)

   Installed with composer create-project pollora/pollora (framework v13.38.0), nginx, PHP 8.4, outside DDEV's own detection, and tried the APP_URL cases from this issue. A reproduction on a real macOS (Valet, Herd) is running next.

   APP_URL	URL in the browser	/	/wp-admin/
   https://site.test	https://site.test	200	302 to /cms/wp-admin/
   http://other.test	https://site.test	200	302 to https://other.test/cms/wp-admin/
   site.test (no scheme)	https://site.test	200	404

   • A different host in APP_URL sends /wp-admin/ to that host. If something else answers there (another site, a default page of the local server), the visitor sees that page, which fits this report. / itself is still served by Pollora in this test, so the same page on / points to a request that never reaches Pollora (wrong site name or default site in Valet, wrong document root).
   • APP_URL without a scheme is a real bug, found along the way: every Artisan command failed with Undefined array key "host", and /wp-admin/ answered a 404. Fixed in fix: read an APP_URL without a scheme as http:// #519 (issue APP_URL without a scheme breaks /wp-admin and crashes the console #518): the value is read as http://<value>, and pollora:doctor warns about it.
   • An empty database password worked once written in .env (installation completed with a MySQL user without a password). The setup prompt itself was the problem: fixed in v13.38.0 (Setup refuses an empty database password #515).
   • The title "Nothing Here Yet" is not in Pollora: not in the framework, the skeleton, nor the default themes. It comes from another tool in front of the project, which only a macOS test can name.

   Still to check on a Mac: the page Valet and Herd answer on an unknown .test domain and on their default site, and a project directory whose name differs from the domain.
4. ogorzalka commented on Oct 21, 2026

   

   ogorzalka

   on Oct 21, 2026

   MemberAuthor

   More actions

   Reproduction on a real Mac: why a Mac setup ends on a 404, a loop or a blank page, fixed in 13.38.1

   Machine: macOS 15.8 (arm64, AWS EC2 Mac), PHP 8.4 on the command line, framework 13.38.0, skeleton 13.38.0 (composer create-project pollora/pollora, installed with an empty MySQL root password).

   We could not find the text "Nothing Here Yet" in Pollora, WordPress or Valet: it most likely comes from another tool's placeholder page. What we did find are the ways a Mac setup ends on a blank page, a 404 or a redirect loop instead of the site. Each one is fixed in a PR below, with the same Mac as proof.

   What fails, and the fix

   Setup	Symptom	Cause	Fix
   Valet (and Herd)	/ redirects to itself: ERR_TOO_MANY_REDIRECTS	Valet runs the site through its own server.php, so SCRIPT_FILENAME is not public/index.php; Pollora took the request for a WordPress entry point and redirected to the home URL	framework #521 (merged into develop)
   Valet (and Herd)	/cms/wp-admin/, the address pollora:install prints, answers 404	Valet hands every URL that is not a file to the front controller	framework #521: a public/ directory with an index.php is redirected to it
   Herd	/cms/wp-login.php and /cms/wp-admin/index.php answer the site's 404: no way to log in	Herd's server.php sends every .php URL to the front controller (even a public/probe.php returns the home page). Valet runs those files, Herd does not	skeleton #258: LocalValetDriver.php
   MAMP, any server on PHP 8.3	Fatal error / blank page: Your Composer dependencies require a PHP version ">= 8.4.1". You are running 8.3.30.	The skeleton says php ^8.3 but its lock was resolved on PHP 8.4 and held Symfony 8. MAMP's default PHP is 8.3 while the command line (Homebrew) is 8.4	skeleton #257: lock resolved for 8.3 (Symfony 7.4)
   Apache / MAMP pointed at the project folder	/ answers 404 and /.env is served as a text file (application key, database password)	The document root must be public/	Site Health error (framework #521) + docs
   APP_URL without a scheme (APP_URL=my-site.test)	Every Artisan command crashed; /wp-admin/ 404	WordPress built its URLs without a host	already fixed in 13.38.1 (#519)

   Environments tested after the fixes

   

   Environment	PHP	/	/cms/wp-admin/
   php artisan serve	8.4	200	login (200)
   php -S -t public	8.4	200	login (200)
   Valet 4.12, HTTP	8.4	200	login (200)
   Valet 4.12, HTTPS (valet secure)	8.4	200	login (200)
   Homebrew Apache 2.4 + PHP-FPM, document root public/	8.4	200	login (200)
   MAMP 7.4 (Apache, FastCGI), document root public/	8.3.30	200	login (200)
   Laravel Herd 1.30 + LocalValetDriver.php	8.4	200	login (200)

   Before the fixes: Valet loops on /; Herd answers 404 on the admin; MAMP stops on the platform check. The black bar at the bottom of each screenshot gives the environment, the URL requested, the final URL and the status.

   

   More: Herd admin, MAMP admin, MAMP before, Herd before.

   Other findings

   • The install works with an empty database password on macOS (Homebrew MySQL root): pollora:doctor reports 0 errors, 0 warnings.
   • Opened through another host than APP_URL (127.0.0.1 instead of my-site.test), WordPress redirects /cms/wp-admin/ to the APP_URL host: log in on the address written in APP_URL.
   • With a document root on the project folder, a root .htaccess sending everything to public/ hides .env but breaks WordPress's trailing-slash redirects (/public/...): not shipped. Site Health and the docs cover the case instead.
   • Herd and MAMP were run with their own binaries (Herd.app 1.30.2, MAMP 7.4 with PHP 8.3.30 through FastCGI).

   Shipped

   • framework v13.38.1 (fix: serve the home page and the admin address under Valet and Herd #521, fix: leave the content folders to the site's 404 when redirecting to a directory index #522)
   • skeleton v13.38.1 (LocalValetDriver.php for Herd and Valet, lock resolved for PHP 8.3)
   • documentation: a macOS section in Installation

   Existing project: composer update, then for Herd/Valet copy LocalValetDriver.php to the project root, and if the site is served by PHP 8.3 add "platform": {"php": "8.3.0"} to config in composer.json and run composer update "symfony/*" --with-all-dependencies.

   If it still fails on your Mac, we need

   1. php -v and the PHP version chosen in your server (MAMP: Preferences › PHP; Herd: site settings): they must both be 8.3 or 8.4.
   2. Your server: Valet, Herd, MAMP, other, and the address you open (APP_URL from .env, without the password lines).
   3. The result of php artisan pollora:doctor.
   4. What curl -I <your address>/ and curl -I <your address>/cms/wp-login.php answer (status line and Location).
   5. If the page is blank: the last lines of the server's error log and of storage/logs/laravel.log.