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.

[dd32]

Replying to johnjamesjacoby:

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.

In the case of buddypress.org it's hit because pentesters request it directly :)

That can be reproduced on the playground: ​https://playground.wordpress.net/?multisite=yes&url=%2Fwp-includes%2Fms-files.php

However, it's not at all clear to me how examples shared in this ticket of /files/ in a generated media url could occur, although it seems to me likely that it would be caused by incorrectly configured constants in wp-config.php or a plugin.

@jakeparis If you're still experiencing the issue above, please note that this is something incorrectly configured in your environment, and resolving this ticket won't actually help you.

[realloc]

@dd32 That's why I proposed to return an error 500 and stating the misconfiguration. This is probably much better than a fatal error.

[johnjamesjacoby]

In 60956:

Networks and Sites: check if the BLOGUPLOADDIR constant is defined before using it.

This change prevents a fatal PHP error from occurring when ms-files.php is accessed without legacy multisite file-handling support being configured.

Instead of the fatal error, these same requests will new return a header status 500 along with a die() message "500 - Directory not configured." This differs from the existing 404 statuses to help indicate to site owners this fallback is not working as intended.

Props danielpw, dd32, jakeparis, johnjamesjacoby, spacedmonkey, saurabh.dhariwal, sukhendu2002, realloc.

Fixes #63104.