Attempt to assign property “domain” on null

Attempt to assign property “domain” on null

This is because $dm_domain is null or unassigned. You’ve not provided enough context for me to know why. If you do provide greater context, please do not post large amounts of code in these forums. Instead use sites like pastebin.com or gist.github.com and simply provide the resulting links here.

It’s also unclear how $domain_mapping_id is getting its value, or how it’s related to $dm_domain

Your likely getting image 404 status because the domain mapping to a proper server path is not working correctly.

What plugin is responsible for this sunrise.php file? /wp-content/ is an unusual place for a PHP file. Why the custom domain mapping anyway? WP Multisite has been able to do its own domain mapping for quite some time now.

Helping out someone with a multi site setup and not that familiar with WP MU myself. He deleted a sub site and it killed the main site. Adding mentioned code to (custom?) sunrise.php showed the offending blog causing the issue. And so yes a blog deletion caused the issue. Or at least as you mentioned

Your likely getting image 404 status because the domain mapping to a proper server path is not working correctly.

Have not been able to access the database to check for possible orphans.

I could do a domain_mapping table check for the orphaned blog_id:
SELECT * FROM wp_domain_mapping WHERE blog_id = 44;
If so this would confirm that the domain mapping entry exists.
wp_blogs table for blog_id = 44 check:
SELECT * FROM wp_blogs WHERE blog_id = 44;
If this query returns no rows, it would show the blog_id is orphaned.

If blog_id = 44 no longer exists in wp_blogs, we could possibly safely delete the orphaned entry from the domain_mapping table:

DELETE FROM wp_domain_mapping WHERE blog_id = 44;

I did read

Always delete subsites through the WordPress Network Admin interface. This ensures all associated database entries, including domain mappings, are cleaned up.

somewhere and perhaps the subsite deletion was done incorrectly in the dashboard.

Looked up sunrise.php and found https://github.com/search?q=repo%3AWordPress%2FWordPress+sunrise&type=code hits wise including:

...
*
* These may be populated through a custom sunrise.php. If not, then this
* file will attempt to populate them based on the current request.
if ( defined( 'SUNRISE' ) ) {
	include_once WP_CONTENT_DIR . '/sunrise.php';
...

at https://github.com/WordPress/WordPress/blob/47bb776fd70295d708b8eb68b79a3f0e42fb5041/wp-includes/ms-settings.php#L16

so sunrise.php is used , but in its location it could be a custom version.

• This reply was modified 3 months, 1 week ago by Rhand.
• This reply was modified 3 months, 1 week ago by Rhand.

I understand about sunrise.php now. Thanks for the direction. It’s not a default WP file, it serves as a pluggable hook to allow network oriented themes and plugins to do something that needs to be done early in the loading process where waiting until plugins load is too late. Thus its content could be anything. So I still don’t know for sure what this particular implementation is for. Apparently some sort of custom domain mapping scheme.

Could this be an old site installed before WP included domain mapping by default? Rhetorical question, the answer doesn’t really matter. The file exists no matter what.

The reason for using Network Admin to remove sites is to ensure all related data is removed. In a standard network installation, to flaunt the rule and manually delete a site, we mainly need to remove any reference to it from the sites and blogs tables. There will be a bunch of other data, but none of it should cause an error. It only takes up space that could be better used. Since there appears to be custom domain mapping in this installation, it’s not a standard network installation and I’m unable to suggest how to manually remove a site cleanly.

Are there other sub-sites in this installation besides the one that was removed? If there aren’t too many sub-sites, I’d be tempted to try removing the custom domain mapping and use the built-in scheme instead. But there’s likely more to the scheme than sunrise.php. Cleanly removing all related code and correctly altering any remaining sub-site data would require a good understanding of PHP code and how network data is organized in the DB.

Probably the smarter approach would be to patch up what’s wrong as best as possible and otherwise let things be. Before proceeding, make a full DB backup. You’ll need access to phpMyAdmin to effectively correct the data. Blindly poking at the DB via SQL queries is far from ideal. You really would want to see all that phpMyAdmin lets you see.

Once the site is correctly removed, perhaps sunrise.php will cease to throw errors. If errors persist, the code will likely need modification. If nothing else, more robust error checking such as validating the value of $dm_domain before attempting to use it. But if it turns out to be invalid, what to do about it? Throwing an error is not helpful. Invalid values would need to somehow fail gracefully, allowing everything else to work normally.

Are there other sub-sites in this installation besides the one that was removed? If there aren’t too many sub-sites, I’d be tempted to try removing the custom domain mapping and use the built-in scheme instead. But there’s likely more to the scheme than sunrise.php. Cleanly removing all related code and correctly altering any remaining sub-site data would require a good understanding of PHP code and how network data is organized in the DB.

Yes, there were several sub.site.com domains removed. All test ones it seems and ones having domains like 48.maindomain.com. There are currently 7 sites running with tlds like .dk , .de , .nl, .fr, .es (not subdomains but regular tlds). I will discuss the (temporary ) removal of sunrise.php and see if the built-in schema could work as well. But yes, that depends on the general setup beyond the custom domain mapping or reasons behind it all.

Probably the smarter approach would be to patch up what’s wrong as best as possible and otherwise let things be. Before proceeding, make a full DB backup. You’ll need access to phpMyAdmin to effectively correct the data. Blindly poking at the DB via SQL queries is far from ideal. You really would want to see all that phpMyAdmin lets you see.

Agreed. If we can patch it by checking database for current issue we should. But would also be nice to revert to a more default WP MU site setup if possible. Will need to ask when this was all setup and why with custom domain mapping. Perhaps because of limitations at the time. Could be a (much) older installation.

When I have another update I will let you know. Have a nice Sunday @bcworkz !

Multi Site did get restored by a third party. Unfortunately not all the way and perhaps not as suggested here. Many images somehow got lost. Around 800. And as there was no backup of those and Wayback Machine does not seem to have all easily available they will have to be re-added manually it seems. but at least the subsites are up and running again with general content, pages and a good chunk of the images.

Thanks again for all the feedback and tips!

Ye error WordPress multisite setup me subsite delete karne ke baad aa rahi hai. Iska reason hai ki sunrise.php file me $current_site ya $current_blog variable null hai, jisme “domain” property assign ho rahi hai.

Solution:

1. wp-config.php me SUNRISE define hai ya nahi check karein:phpCopyEditdefine( 'SUNRISE', 'on' );
2. sunrise.php file me line 22 pe assignment se pehle $current_site ya $current_blog ko check karein:phpCopyEditif ( isset( $current_site ) ) { $current_site->domain = 'example.com'; }
3. Database me wp_blogs aur wp_site tables check karein, koi orphaned entry to nahi.

Agar issue persist kare, to multisite mapping plugin ya sunrise.php ka koi custom code check karein.

@isablelas000 thanks for the feedback and possible solution. Perhaps better to translate it to English though. Seems you wrote in Hindi.