Forum Replies Created
-
AuthorPosts
-
October 22, 2014 at 9:17 am #5204Matt BrooksParticipant
Sounds good, just let me know if you’d like me to test something out, give you more info, etc.
October 22, 2014 at 8:01 am #5202Matt BrooksParticipantSorry, I should have mentioned that refreshing the permalinks is the only thing I’ve tried so far (without success). I’m not sure what the pattern is for the docs not working as I have groups that have docs that both do and don’t work.
October 21, 2014 at 2:39 pm #5200Matt BrooksParticipant@scottvoth – I thought I’d chime in on this thread. I just updated an instance of WordPress to 4.0 which has the current version of CBox on it and it broke group docs for me. After the update some group docs work and others bring up the “Darn it.. Nothing found” page. Any ideas on what might be causing this?
August 26, 2014 at 2:44 pm #5074Matt BrooksParticipantGlad it helped!
August 26, 2014 at 1:03 pm #5071Matt BrooksParticipant@steveoc <your wordpress directory>/wp-content/plugins/buddypress-docs/includes/attachments.php
Line 769 is the beginning of the
check_is_protected(
function and I think it should be line 775 that has the if statement that needs to be changed.- This reply was modified 10 years, 4 months ago by Matt Brooks.
August 26, 2014 at 10:38 am #5069Matt BrooksParticipantGlad I could help!
August 25, 2014 at 3:30 pm #5066Matt BrooksParticipantNo problem. I changed the code you suggested and threw in some echos (for testing) and it looks like it’s now working without massive slow downs. The if statement is being evaluated to true and $is_protected is being returned there instead of continuing on.
August 25, 2014 at 10:00 am #5062Matt BrooksParticipant@cbox_admin – Sorry for the delay, but I have finally checked the things you have asked of me.
– is $force_check indeed defaulting to false on these calls?
Yes, I checked this and force_checked == false for every call that takes place on the wiki home page. However, on the next part of the function (the ‘ ‘ === $is_protected):
// Fall back on cached value if it exists
if ( ! $force_check ) {
$is_protected = bp_get_option( ‘bp_docs_attachment_protection’ );
if ( ” === $is_protected ) {
return (bool) $is_protected;
}
}is not evaluating as true, so the function is not returning there.
– is the .htaccess file being created as expected?
If I remove the .htaccess file that is in uploads/bp-attachments/0 then there is no slow down and the file is not recreated. When i put the file back with the following rules:
RewriteEngine On
RewriteBase /
RewriteRule (.+) ?bp-attachment=$1 [R=302,NC]
it slows down the load of the wiki. It looks like to me that with the .htaccess file removed the function never gets to the point where it can recreate it since it has to pass this check first:if ( ! file_exists( $test_file_dir ) ) {
Since the test.html file still exists even though the.htaccess file is gone (or even if the .htaccess file is there) this condition is never met. This may be its own bug?
– what is the return value of the wp_remote_get() call?
Array
(
[headers] => Array
(
[date] => Mon, 25 Aug 2014 13:34:26 GMT
[server] => Apache/2.2.22 (Ubuntu)
[last-modified] => Tue, 01 Jul 2014 17:24:36 GMT
[etag] => “e1f8b-5c-4fd250cbfedd9”
[accept-ranges] => bytes
[content-length] => 92
[vary] => Accept-Encoding
[connection] => close
[content-type] => text/html
)[body] => This is a test of the Protected Attachment feature of BuddyPress Docs. Please do not remove.
[response] => Array
(
[code] => 200
[message] => OK
)[cookies] => Array
(
)[filename] =>
)– when bp_update_option() is run, is it returning true or false?
It doesn’t seem to be returning anything. It doesn’t look like that function has a return type –
buddypress/bp-core/bp-core-options.php, line 262:function bp_update_option( $option_name, $value ) {
update_blog_option( bp_get_root_blog_id(), $option_name, $value );
}Please let me know if there is anything else I can do to help out!
Matt- This reply was modified 10 years, 4 months ago by Matt Brooks.
August 13, 2014 at 3:56 pm #4993Matt BrooksParticipant@r-a-y: I will submit an issue ticket on GitHub and reference this thread. Thanks for the info on disabling the attachment drawer, that should fix the problem and pretty up the wiki’s front page.
@cbox_admin: I’ll check the things you mentioned and get back to you on here. Thanks for the info!August 5, 2014 at 7:45 am #4966Matt BrooksParticipantMaybe the function check_is_protected could store the results in a static or global variable and just refer to that variable after the first time the function is run (for each page load)?
August 4, 2014 at 2:07 pm #4964Matt BrooksParticipantI believe I found what is causing this problem. The issue starts with the document list at the bottom of the wiki home page:
We have two pages that show up on that list often which each contain a lot of attachments (around 200 combined). After digging through some code I’ve found that the function bp_docs_doc_attachment_drawer (buddypress-docs/includes/templatetags.php) is called on that page, which in turn calls bp_docs_attachement_item_markup for each attachment that is on that page. …item_markup calls bp_docs_get_attachment_url, which calls bp_docs_attachment_protection, which finally calls check_is_protected (buddypress-docs/includes/attachments.php).
check_is_protected attempts to access a file it shouldn’t have access to (hence checking for protection) and is issued a 302 redirect if it fails. In our case when we have around 200 attachments on the home page of the wiki wp_remote_get is called 200 times, and then is issued a 302 redirect which then loads the redirect page 200 times. This totals over 400 page loads just to load the home page of the wiki. This is why the home page of our wiki takes ages to load if I don’t circumvent the check_is_protected function by returning true on the first line of it.
Please let me know if there is a better way to handle this, if this is a bug, etc.
Thanks,
Matt
June 24, 2014 at 2:30 pm #4870Matt BrooksParticipantI updated/refreshed the permalink settings and unfortunately that does not improve the speed of loading that page. Does anyone know if there is a way to “reset” the landing page of the wiki?
June 23, 2014 at 10:10 am #4856Matt BrooksParticipantScott,
The wiki is still slow and I don’t think we really have a huge amount of content on our wiki. It looks like there is something going on with the check_is_protected function in the buddypress-docs/includes/attachements.php file. Viewing the Apache access logs on our server shows that every time the base wiki page is requested there are almost 100 requests of the following three lines:
127.0.0.1 – – [23/Jun/2014:09:34:14 -0400] “GET /wp/wp-content/uploads/bp-attachments/0/test.html HTTP/1.0” 302 597 “-” “WordPress/3.9.1; http://<our_site>”
127.0.0.1 – – [23/Jun/2014:09:34:14 -0400] “GET /?bp-attachment=test.html HTTP/1.0” 302 401 “-” “WordPress/3.9.1; http://<our_site>”
127.0.0.1 – – [23/Jun/2014:09:34:15 -0400] “GET /wp/wp-login.php?redirect_to=http%3A%2F%2F<our_site>%2F HTTP/1.0” 302 328 “-” “WordPress/3.9.1; http://<our_site>”Which I imagine is why the page is so slow to load. Do you have any ideas why that check would be performed almost 100 times on the wiki page? If I disable the .htaccess file in the /wp/wp-content/uploads/bp-attachements/0/ directory the page loads a lot quicker (replying with 200 instead of 302), but that function is still running close to 100 times (plus the directory is no longer secure).
I’d be more than happy to give you access so you can check it out, just let me know if you need it or if I should post this elsewhere since it seems to be tied to BuddyPress Docs.
Thanks,
Matt
-
AuthorPosts