Undefined constant "BLOGUPLOADDIR" for subdirectory multisites

[danielpw]

A fatal error occurs when navigating to any site URL that contains '/wp-content/files/' on subdirectory multisites. Example: sitedomain.com/wp-content/files/

The error is:
PHP Fatal error: Uncaught Error: Undefined constant "BLOGUPLOADDIR" in /www/site/public/wp-includes/ms-files.php:26

This error does not occur when navigating to '/wp-content/files/' on subdomain multisites.

This was tested on a new/fresh subdirectory multisite install, with the latest version of WordPress using a default theme, and the error still occurred.

Steps to reproduce the problem:

• On a multisite that uses subdirectories, go to '/wp-content/files/' and it should result in a critical error
• Example: sitedomain.com/wp-content/files/

[sukhendu2002]

Reproduction Report

Description

This report validates whether the issue can be reproduced.

Environment

• WordPress: 6.7.2
• PHP: 8.2.23
• Server: nginx/1.26.1
• Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.23)
• Browser: Chrome 133.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Steps

• Set up a fresh WordPress multisite installation using subdirectories.
• Navigate to '/wp-content/files/' on any subsite.

Actual Results

1. ❌ Unable to reproduce the issue. The page loads without errors.

Additional Notes

• Not able to reproduce this in 6.8 Beta 2

Supplemental Artifacts

[saurabh.dhariwal]

Test Case: Fatal Error on Navigating to /wp-content/files/ in Subdirectory Multisite

Title: Verify if navigating to /wp-content/files/ triggers a fatal error in a subdirectory multisite setup

Test Type: Functional, Regression
Environment:

WordPress Multisite (Subdirectory Setup)
PHP Version: 8.1
Debug Mode: Enabled (define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);)
Plugins: Minimal active plugins
Theme: Default Twenty Twenty-five

Preconditions:

WordPress is installed and configured as a Subdirectory Multisite.
Pretty permalinks are enabled.
No custom rules affecting /wp-content/files/ are present in .htaccess or Nginx configuration.
The database is backed up before testing.

Steps to Reproduce:

Open a browser and navigate to ​https://example.com/wp-content/files/.
Observe the response from the server.
Check the PHP error log (wp-content/debug.log or server logs) for any fatal errors.
Repeat the test with different sub-sites:

​https://example.com/subsite1/wp-content/files/
​https://example.com/subsite2/wp-content/files/

If no error occurs, manually inspect ms-files.php to verify whether BLOGUPLOADDIR is defined.

Expected Result:

The page should return a 404 Not Found or a proper redirection if the file handler is working correctly.
No Fatal Error should occur.
BLOGUPLOADDIR should be properly defined before being used in ms-files.php.

Actual Result:

[PASS] No fatal error occurs, and a "Page Not Found" message is displayed.
[FAIL] A fatal error appears in ms-files.php, indicating BLOGUPLOADDIR is undefined.

Post-Test Actions:

If the fatal error is confirmed, check the WordPress core file ms-files.php for incorrect reference to BLOGUPLOADDIR.
If no error occurs, verify the issue with different PHP versions and fresh WordPress installations.

Additional Notes:

If the fatal error is reproducible, consider defining BLOGUPLOADDIR in wp-config.php as a workaround.
If the issue is not reproducible, it may have been resolved in newer WordPress versions or specific server configurations.

[spacedmonkey]

Seems like this line does not check to see if the const exists before using it.

​https://github.com/WordPress/wordpress-develop/blob/eaeda35de1726b9dfb80045f1074a268313e783c/src/wp-includes/ms-files.php#L28

[realloc]

Add check for BLOGUPLOADDIR and return 500 error on misconfiguration

[realloc]

@spacedmonkey I would handle it with a check if the constant is defined and exit with a 500 in case it is not.

https://core.trac.wordpress.org/ticket/63104

[johnjamesjacoby]

The attached diff mitigates the fatal error. I am +1 to it being committed into 6.9.

Despite some debugging, it’s still unclear how ms-files.php can be requested without ms_upload_constants() being called – unless perhaps ms_files_rewriting is unexpectedly being flipped.

I haven’t been able to reproduce the fatal error so far.

[jakeparis]

Not sure if you're looking for someone else to debug, but I can reproduce this on our mu site. We have a blogs.dir in use.

Site id: 174
Site name: news

The url looks like:

https://ourdomain.org/news/files/2025/03/FINALS-DAY-3-228-1.webp

I can confirm the file actually exists in the file system at

.../htdocs/wp-content/blogs.dir/174/files/2025/03/FINALS-DAY-3-228-1.webp

and the file is visible at

https://ourdomain.org/wp-content/blogs.dir/174/files/2025/03/FINALS-DAY-3-228-1.webp

as well. But the editor wants to insert all images with the /files/ bit in the path, and none of our images show up in the editor.

I also tried uploading a new image, and is not visible either after it is uploaded.

EDIT: I'm not sure if I understand the above conversation perfectly, but this would be a disaster for us to not fix until 6.9. That would mean we were stuck on the old version for another 8 months.