Skip to:

Opened 17 months ago

Last modified 17 months ago

#8683 assigned defect (bug)

BP .htaccess rule causes server CPU spikes

Reported by: kuznacic's profile kuznacic Owned by: dcavins's profile dcavins
Milestone: Awaiting Review Priority: normal
Severity: major Version: 10.2.0
Component: Core Keywords:


I had posted this on the BP support forum, and a commenter said this is not common and suggested I create a ticket here. Please let me know if I can supply further info.

The issue: Running on a 2GB Cloudways-based Digital Ocean droplet with the latest versions of WordPress (5.9.3) and BuddyPress (10.2), a client site and server were seeing spikes to 100% CPU and high RAM usage — but only when a logged-in user opened the WordPress media library (/wp-admin/upload.php).

My hosting support first told me it was a plugin error, then I was told it was a theme error. But we were unable to find any evidence of this. I cloned the live site, deactivated all plugins and switched to a default WP theme, and the issue still occurred.

There were no related items in the Apache or Nginx error logs, but the PHP access log fills with lines like this, seemingly for every media file:

(server IP) – [15/Apr/2022:15:57:37 +0000] “GET /index.php?bp-attachment=13109/NorthCrawford-300×225.jpg” 301 0 – 798 14702 0.648 8388608 9.27% 3.09% “/?bp-attachment=13109/NorthCrawford-300×225.jpg”

The solution from my hosting support:

The issue is BuddyPress created htaccess that redirects all wp-content/uploads/bp-attachments/ to ?bp_attachments= URL. The redirects spawn heaps of apache and php-fpm which also cause the issue . They created this sample htaccess found on the directory below

/public_html/wp-content/uploads/bp-attachments# cat .htaccess

RewriteEngine On
RewriteBase /
RewriteRule (.+) ?bp-attachment=$1 [R=302,NC]

The htaccess has been renamed so, when you load medias, it should no longer reach 100%

The solution was to take the .htaccess file out of the equation by renaming it, which is only a temporary fix. I presume this file would be overwritten upon the next BP update?

If that’s the case, how would I keep this from happening, aside from renaming the offending .htaccess file each time there is a BP update?

Change History (4)

#1 @imath
17 months ago

Hi @kuznacic

To my knowledge, BuddyPress doesn’t include anything about generating an .htaccess file. I’ll check again to be 💯 sure.

#2 @kuznacic
17 months ago

@imath Thanks for the reply.

One thing I forgot to note but is likely relevant: This site also uses the BP Docs plugin with the ability to attach a file to each "doc."

I believe the BP Docs add-on would have created the .htaccess file, as it's located in wp-content/uploads. Anyhow, if this is the case then perhaps it is a support issue for the Docs team.

#3 @dcavins
17 months ago

  • Owner set to dcavins
  • Status changed from new to assigned

Hi @kuznacic,

This is not a BuddyPress issuse, as @imath suspected. Those htaccess files are created by BP Docs (which is not a plugin maintained by the BuddyPress team).

Those htaccess files are created to protect files that are attached to private docs. If there were no htaccess files for private attachments, anyone who had the URL could access those files. The way the protection works is that WordPress is started to determine whether the user should have access to a file, and if they do, the file is streamed to them, using php. So it does require more computing power than serving static files. However, I have sites that contain thousands of private documents and attachments, and they do function as expected.

It sounds to me like you might have an issue with your site that is causing general inefficiency, which of course is compounded by the number of image requests. If I were you, I would start troubleshooting by installing Query Monitor to see what a typical page load takes, looking for long queries or slow assets. Let me know what you find.

#4 @kuznacic
17 months ago

@dcavins Thanks for the reply. I am still investigating this issue but so far have not found anything definitive.

Coincidentally, our paths have crossed previously because of this issue -- you chimed in on a thread in the BP Docs support forum on back in February 2021 when I was receiving the notice, "Your BuddyPress Docs attachments directory is publicly accessible. Doc attachments will not be properly protected from direct viewing, even if the parent Docs are non-public."

Link to thread:

I am curious if you believe that the solution that Cloudways implemented might be a cause of the issue this site is experiencing with CPU spikes when accessing the WP media library? To my knowledge all was working properly from the time this was implemented in Feb. 2021 until my client reported an issue to me in March 2022. But, perhaps a recent WP or BP update might have altered something?

I will continue to investigate and troubleshoot on my end, but wanted to get your thoughts on this. Any advice or guidance you can provide is very much appreciated.

Last edited 17 months ago by kuznacic (previous) (diff)
Note: See TracTickets for help on using tickets.