allowoverride problems

Hi @havealookhere, I’m not familiar with SiteGround but I’m told they have good support. You can test if the BP Docs attachment protection is working by attaching a file to a private BP Doc. Then, copy the attachment url, and in a browser in which you are not logged in to the site, attempt to load that attachment via the url. If you can see the attachment, then BP Docs is not able to write the htaccess rules as needed. If you can browse the site files, visit /wp-content/uploads/bp-attachments/{whatever your new docs's ID is} and see if there is a hidden file, .htaccess in that directory. If the doc is private, the htaccess file will contain:

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

Best,

-David

Hi @havealookhere,

Did you ever resolve this issue? What was the problem?

Best,

-David

HI,

No, it was caused by the nginx fast delivery service of siteground.. I have switched it of and then it worked again.

I am sorry, i did not give a reply to your comment.I was very busy with a lot of things.

In the near future i will go into this problem again, but now its not at the top of my to do list.

regards

Jap

Thanks for the update!

I also have this issue, but with Cloudways (who also run apache and nginx) Attachments are visible on private documents when viewed through an incognito window. The AllowOverride is on for the apache server

I think this might be something you want to explore David, as if nginx fast service delivery is being used by hosts to deliver websites quickly, you don’t want your plugin to impact site speed because it has to be turned off.

I have let Cloudways tech support know and I’m awaiting their response regarding the impact on site speed.

at siteground they couldnt change this behaviour.. the tech support tried it, but could only give me the advice to switch nginx off.

Cloudways tech support is going to have a look. If they solve it, I’ll let you know what they did.

Hi all, you can read more about BP Docs’ support for nginx here: https://github.com/boonebgorges/buddypress-docs/wiki/Attachment-Privacy#nginx

Best,

-David

@edroundtables Were you able to get this resolved and/or receive a reply from Cloudways?

I ask because I am dealing with the same issue on a Cloudways server (Digital Ocean) and this is the reply I received:

Thanks for reaching out to us. The directive for AllowOverride is already used and enabled on apache server and the following code is already added to Apache configuration:
Options -Indexes -Includes -ExecCGI +FollowSymLinks
DirectoryIndex index.php default.php index.html default.html
AllowOverride All
Require all granted

If there are some permission issues on the application or any special permission which we have to use for your BuddyPress plugin you can share with us so we can change the permissions as your WordPress multisite is currently using standard set of permission.

I am curious if this issue is related to nginx as @havealookhere mentioned? That will be my next question to Cloudways support.

I got the same answer as you did. They did make some changes to the nginx server but ended up blocking access to the attachments entirely. I am looking at alternative options at the moment. I am reluctant to do anything that would impact the site speed in the future, and then for me not to remember what changes were made to the server and what to undo.

If they manage to come up with a solution let me know.

@edroundtables Thanks for the quick reply, and I will post here if a solution is found.

@edroundtables I will spare you the details, but after a week I was finally able to convince/prove to Cloudways support that this issue was caused by the server configuration.

Here is the reply they gave me; I would think you could contact them again, reference the issue and this thread, and let them know what was done in my case.

The issue was with Nginx. In our stack, Nginx is working as a reverse proxy for Apache and the plugin you are using is used for static content. Nginx is serving the content before the request reaches to Apache. Now its working fine when we force the content is processed through Apache.

@kuznacic, Thanks for the update! The setup they’re describing would be fine for a static site, but a membership-based site requires something else.

Thanks for sharing your solution.

-David