[@jnomell Participant 2 weeks, 4 days ago]

Hi again,

We currently have approximately 550 terms across our taxonomies: around 500 in the custom series taxonomy, 37 categories and 3 tags.

The problem occurs regardless of which taxonomy we use. Creating or deleting terms produces the same behaviour, so I suspect that the total number of terms may be relevant. The problem first appeared when the site had somewhere around 200–300 terms.

I have tried to isolate the issue as carefully as I can. With WordPress core and no plugins active, term creation and deletion work normally. If I then activate BuddyPress as the only plugin, the problem returns.

I have also tested the opposite configuration: all plugins are active except BuddyPress, and term creation and deletion continue to work normally.

It does not matter whether I activate BuddyPress first or last. As soon as BuddyPress is activated, the problem appears. If BuddyPress is the only active plugin, the problem occurs. If all the other plugins are active but BuddyPress is disabled, the problem does not occur.

I find this particularly interesting because it suggests that the issue is not simply caused by the total number of plugins or by a conflict between several plugins. BuddyPress appears to be the component that triggers the problem, possibly in combination with the number of terms or the server environment.

I understand that this does not necessarily prove that BuddyPress itself contains a bug. However, the fact that BuddyPress alone is sufficient to trigger the problem seems significant.

Our server uses Apache MPM Event and PHP-FPM, but these are standard configurations and have not been specially modified for this purpose.

I would be interested to know whether other BuddyPress sites use similarly large numbers of terms without problems, and whether this has been tested by the development team.

I realise that this may be an interaction between WordPress, BuddyPress, the number of terms and the server environment rather than a straightforward BuddyPress bug. Nevertheless, if someone from the BuddyPress development team could take a closer look at what happens in this situation in our system, I would be extremely grateful.

Thank you.

[@jnomell Participant 2 weeks, 5 days ago]

Hi again,

I’m afraid I’ve reached the limit of what I can investigate with my current level of knowledge, and I would really appreciate some help.

I use a screen reader, so I unfortunately cannot use the browser developer tools effectively enough to follow the suggested debugging steps in tags.js around line 50.

The problem is still present and has become quite frustrating. Would someone from the BuddyPress development team be willing to take a closer look at this issue and see whether the cause can be identified and, if appropriate, a fix included in a future BuddyPress release?

Any help or guidance would be greatly appreciated.

Thank you very much!

[@jnomell Participant 4 months, 3 weeks 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.

[@jnomell Participant 4 months, 3 weeks ago]

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

[@jnomell Participant 4 months, 3 weeks 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 4 months, 4 weeks 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.

[@jnomell Participant 5 months 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!

[@jnomell Participant 5 months 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.