Fatal error on listing page after author's WordPress account is deleted

Bug Reports
1

When a WordPress user is deleted via the standard wp-admin “Delete User” screen without using the “Attribute content to another user” option to reassign their listings, any hp_listing post still authored by that (now-deleted) user ID becomes orphaned. Visiting one of these orphaned listings triggers a fatal error inside HivePress\Components\Listing::update_listing(), caused by a call to get_display_name() on what appears to be a null vendor/user object.

Separately, I’ve also noticed the affected listing’s card is missing its image specifically on the native HivePress search/grid results page, while the same listing’s image displays correctly on other cards (e.g. a homepage section querying the same listing). I’m not yet certain whether this is related to the same root cause or a separate issue, but I’m including it here in case it’s relevant.

Steps to reproduce

  1. Create a WordPress user and have them publish at least one hp_listing
  2. Go to Users → delete (+empty trash) that user via wp-admin, without reassigning their content to another user.
  3. Visit the listing page that was authored by the deleted user.
  4. Separately, view that same listing’s card on the native HivePress search/grid results page.

Actual result

On first visit to the listing page, the page fatally crashes with:

Uncaught Error: Call to a member function get_display_name() on null
in /wp-content/plugins/hivepress/includes/components/class-listing.php on line 148

The crash originates inside HivePress\Components\Listing::update_listing(), triggered when the Review Submit Form block renders. Stack trace summary:

Review_Submit_Form::boot()
→ Review::get_review_draft()
→ wp_insert_comment()
→ Hook::update_comment()
→ Review::update_rating()
→ Post::save()
→ Listing::update_listing()

On refreshing the page, the fatal error no longer occurs and the listing page renders normally. However, the listing’s card on the native search/grid results page still fails to display its image, even though the same listing’s image renders correctly elsewhere on the site.

Expected result

The listing page should render correctly on first visit, without crashing, regardless of whether the listing’s author account still exists. The listing’s card should also display its image consistently across all card contexts, including the native search/grid page.

Expexted Fix

Adding a null check before the get_display_name() call in update_listing() should resolve the fatal error. The image issue on the search/grid card may be a separate bug or may share the same root cause.

3

Thanks for the details.

The listing post type configuration has this parameter:

'delete_with_user' => true,

Based on this parameter, WordPress should delete all listings if the user is deleted, and there should be no orphaned listings left. Please check if these listings also appear in the back-end listings table in WordPress/Listings, if these still appear on the front-end but not in the back-end table, this may be a caching issue.

If there were no customizations related to the listing post type, please describe the steps to reproduce the issue (e.g. if specific configuration is needed) – I tested this locally by deleting a vendor user and their listings also disappeared.

4

Thanks for checking. I can confirm the listing is still present in wp-admin → Listings, still showing the deleted user’s name as the author. So this isn’t a caching issue. The listing genuinely wasn’t deleted, which means delete_with_user didn’t behave as expected in this case.

One thing worth mentioning: my site is running on WordPress Multisite, which I understand isn’t officially supported by HivePress. User deletion on Multisite goes through a different code path (wpmu_delete_user()) than a standard single-site install (wp_delete_user()), so it’s possible delete_with_user is only hooked into the single-site flow and simply doesn’t fire in a Multisite context. If that’s the case, this may not be something you consider worth fixing given the lack of official Multisite support. Totally understand if so.

If you’d like to test it on a Multisite setup anyway, here are the steps I used:

  1. On a WordPress Multisite network, create a user with a listing on a subsite.

  2. Delete that user via wp-admin (either from the subsite’s Users screen or the Network Admin → Users screen).

  3. Check wp-admin → Listings on that subsite. The listing is still present, still attributed to the now-deleted user.

No worries either way. I can handle cleanup on my end with a custom snippet if this turns out to be a Multisite-specific gap rather than something you’re able to address.