Topic: Problem when deleting terms

Problem when deleting terms

@jnomell

Participant

2 weeks, 6 days ago

Hi,

I’ve run into an issue that appears to be caused by BuddyPress when deleting terms (categories, tags, and custom taxonomies) in WordPress admin.

When I delete a term in wp-admin (for example a category or a custom taxonomy term), I get the following error message:

“An error occurred while processing your request. Please try again later.”

However, after reloading the page, the term is actually deleted successfully.

– Deleting posts and comments works without any issues
– The problem affects:
– Categories (category)
– Tags (post_tag)
– Custom taxonomies (e.g. from PublishPress Series)
– No errors are logged in:
– wp-content/debug.log
– Apache error log

When deleting the same term using WP-CLI, everything works perfectly:

bash wp term delete category <term_id>

– No errors
– Term is deleted correctly

I disabled all plugins and then re-enabled them one by one. The issue only occurs when BuddyPress is active. With BuddyPress deactivated, term deletion works normally in wp-admin (no error message)

In our system we use PublishPress Series, which registers a custom taxonomy called series. We have currently ~440 terms in this taxonomy
– The number is continuously growing
– The issue started appearing when the number of terms became relatively large

This might indicate a scaling issue or something triggered by higher term counts.

– The term is deleted successfully via wp_delete_term
– Something in BuddyPress interferes with the response afterward
– Possibly an issue with AJAX response (invalid JSON, unexpected output, etc.)

Has anyone seen this behavior before?

Is there anything in BuddyPress that hooks into term deletion (e.g. activity, notifications, or other components) that could break the admin AJAX response without triggering a PHP error?

Could this be related to the number of terms in a taxonomy?

We have also a similar problem when creating terms. No error messages in wp-admin but when clicking create it doesn’t look like that the term has been created. But when reloading the page the term is there.

Any pointers on where in BuddyPress this might happen would be greatly appreciated.

– WordPress: latest version
– BuddyPress: latest version
– PHP: 8.3 (PHP-FPM)

Thanks!

Viewing 10 replies - 1 through 10 (of 10 total)

@fatiima

Participant

2 weeks, 4 days ago

“Looks like an AJAX response issue—BuddyPress might be outputting unexpected data during term operations, especially with larger taxonomies. You could try checking for hooked actions on term deletion/creation and enable WP_DEBUG_DISPLAY to catch any hidden output affecting JSON responses.”

@jnomell

Participant

2 weeks, 4 days ago

Thanks for your suggestion.

I have enabled debug logging, but I’m not seeing anything that seems related to this issue, neither in wp-admin nor in the debug.log.

The only thing that appears is the following deprecated notice:

[27-Apr-2026 16:56:19 UTC] PHP Deprecated: The function bp_core_get_user_domain is deprecated since version 12.0.0! Use bp_members_get_user_url() instead. in /wp-includes/functions.php on line 6131

I have looked through the code in my plugins, and it seems that a few BuddyDev plugins are making this call, including BuddyPress Moderation Tools and BuddyDev Poke, so it doesn’t appear to be directly related to the issue and if I deactivating these plugins the problem still is the same.

I haven’t been able to find anything else. I should also mention that I’m very much a hobbyist, so my knowledge in this area is quite basic.

@jnomell

Participant

1 week, 6 days ago

Hi again,

Since I’m not finding anything in any logs or debug logs, I’ve reached the limit of what I can figure out with my current level of knowledge. It would be greatly appreciated if a BuddyPress developer could take a closer look at this issue and hopefully help identify a solution.

I’m speculating here, but creating and deleting terms in wp-admin used to work without any problems. The issue appeared at some point, and the only thing I can think of is that it might be related to the growing number of terms in one of our custom taxonomies. It seems like something in BuddyPress hooks into term creation or deletion and causes this behavior.

When creating a term:

* No error message is shown
* However, the term list does not refresh (possibly an AJAX issue)

When deleting a term:

* An error message is shown
* The term is actually deleted in the background
* But again, the list does not refresh automatically

I’m not sure, but perhaps our setup is somewhat unusual. We use a relatively large number of terms in a custom taxonomy so that our authors can organize their texts into series. However, it doesn’t seem like deleting a term should be more resource-intensive than deleting posts or comments, of which we have many thousands without issues.

I am a bit concerned that more problems could appear as the number of terms continues to grow.

Additionally, we are using BuddyPress Moderation Tools from BuddyDev. This has also recently started behaving strangely — for example, it is no longer able to create reports when a user flags content. This used to work before. I don’t know enough to say for sure, but it doesn’t seem impossible that these issues could be related.

We have, of course, tested creating and deleting terms with all plugins deactivated (including BuddyDev plugins), and this issue only occurs when BuddyPress itself is active.

I would be extremely grateful for any help or guidance.

Thank you!
@emaralive

Moderator

1 week, 5 days ago
```
An error occurred while processing your request. Please try again later.
```
The above error message appears to originate from the WordPress tags.js file, line 83 with line 84 adding the message to the DOM; if the AJAX action of delete-tag has completed after the function wp_delete_term() has returned a value of false or a numeric `0′.

The following is an excerpt from the docblock for said function:
```
 * @return bool|int|WP_Error True on success, false if term does not exist. Zero on attempted
 *                           deletion of default Category. WP_Error if the taxonomy does not exist.
```
You might want to debug the AJAX call via “DevTools” of your web browser, start with looking at the results (Status, Payload & Response) for admin-ajax.php when deleting a term (Category, Tag or Series).
@jnomell

Participant

1 week, 4 days ago

Thanks. This is what we could find out:

Payload:
action
delete-tag
taxonomy
category
tag_ID
950
_wpnonce
ac946b4d8f

Below response first an empty line and then one line with the number 1.

When creating a term there are nothing at all. The term is created but it looks like it is just working.
@emaralive

Moderator

1 week, 4 days ago
Interesting regarding “creating a term” because there should have been a payload with 10 key:value pairs & response with XML data, however, let’s put a pin it for now and focus on delete-tag, which may solve the “creating a term” issue, as well. As an aside, “creating a term” may be using the normal “form” method, the same as when “JavaScript” is disabled but, this is mere conjecture since we don’t have all the facts.

Backing up to delete-tag the payload and & response look normal, of which, the numeric 1 indicates that the function wp_delete_term() returned a value of true and thus the term was deleted. So now we need to solve the mystery of why tags.js appears to be functioning in an abnormal way or in IOW, ‘what the heck is going on?’.

On another note, when the “delete” link is clicked does the background color of the row change to hex color value of #faafaa? Furthermore, if you look at line 50 of tags.js the conditional checks for a numeric value of 1 which should be satisfied due to the response being a numeric value of 1 and that row should have been removed according to the code within that condition, along with not receiving the An error occurred while... error message.

So now, you will need to step through the code of tags.js in an attempt to understand what might be occurring. So, you will need to utilize the “source” tab within “DevTools” and select the tags.js file so that it shows in the code window, then select line 50 to set a breakpoint, then delete a category, then step through the code to make sure the condition of line 50 is being stepped through. Additionally, make sure the code in the code window matches code from GitHub. The path top->domain->wp-admin->js where the targeted file should be residing.

NOTE: As an aside, your file might be named tags.min.js in which case you won’t have sequential line numbers. If this is the case, you may want to temporarily add the following to the wp-config.php file (you can remove or comment it out after you have finished debugging):
```
define( 'SCRIPT_DEBUG' true );
```
This will load tags.js in which you will have line numbers, instead of the minified tags.min.js.

OK, this should be enough for now and, hopefully, help to determine the next steps to take.
@jnomell

Participant

6 days, 18 hours ago

As I mentioned, I’m not entirely sure when the issue first appeared. I’m the one associating it with the growing number of terms, but I don’t actually have anything concrete to support that assumption.

It could just as well be related to the changes I made to the server setup — switching from Apache MPM Prefork with PHP 8.3 to Apache MPM Worker with PHP 8.3-FPM. BuddyPress hasn’t been updated in quite a while, and rolling back one version did not resolve the issue.

So at this point, I’m not sure what is actually causing it. The error in the AJAX response makes me wonder if BuddyPress might behave differently under PHP-FPM compared to the previous setup, rather than this being a change within BuddyPress itself.

Now I just need to try to get some help with the remaining debugging. I use screen reader software and therefore cannot work with the browser developer tools. I’m hoping to get some assistance with that shortly.

@jnomell

Participant

6 days, 18 hours ago

…or if PHP-FPM is allowing some kind of invalid or unintended output that previous PHP configurations did not expose?

@emaralive

Moderator

3 days, 12 hours ago

Out of curiosity, why did you switch from MPM Prefork to MPM Worker (PHP-FPM)?

@jnomell

Participant

3 days, 11 hours ago

Good question — and sorry for the confusion, I actually meant Apache MPM Event, not Worker.

The reason I switched from Prefork was that it was spawning a very large number of Apache processes, which eventually caused the server to run out of resources and crash repeatedly.

After switching to MPM Event, things have been much more stable. As part of that change, I also had to move from mod_php to PHP-FPM, which is why I’m now running PHP 8.3 via FPM.

So the change was mainly driven by stability and resource usage rather than anything related to this issue.

Viewing 10 replies - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

BuddyPress.org

Problem when deleting terms

Topic Info

BuddyPress.org

Problem when deleting terms

Topic Info

Reply Search