Wiki is Slow to Load
Tagged: buddypress docs wiki, loading, slow, wiki
- This topic has 20 replies, 5 voices, and was last updated 10 years ago by
Matt Brooks.
-
AuthorPosts
-
June 20, 2014 at 10:55 am #4846
Matt Brooks
ParticipantHello,
We just updated Commons in a Box (and it’s plugins) from 1.0.7 to 1.0.8 on our production server. Everything seems to be working great right now except for the wiki. When going to the landing page for the wiki it takes a couple of minutes for it to fully load the page. Once the landing page loads the subsequent wiki pages load quickly for a while until you go back to the landing page. Any ideas on what might be causing this?
Thanks,
Matt
June 22, 2014 at 1:49 pm #4854Scott Voth
KeymasterHi Matt @brooks1man
We haven’t had any reports of this kind of slowness. Are you still experiencing it? Do you have a lot of content on your wiki? I was wondering if it is taking a long time to generate the content listing. Can you share a link (either privately or publicly)? I can ask one of our dev team members to take a look. Thanks.
June 23, 2014 at 10:10 am #4856Matt Brooks
ParticipantScott,
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
June 24, 2014 at 1:03 am #4866Ray
KeymasterHi Matt,
While trying to debug your issue, I ran into a similar problem.
This is what solved it for me. Can you try navigating to the WP admin dashboard and then going to the “Settings > Permalinks” page? This refreshes the rewrite rules across WordPress, which helps in some cases with plugins needing their rewrite rules registered in WordPress.
Next, go back to the main Wiki page and see if you experience any slow down.
June 24, 2014 at 2:30 pm #4870Matt Brooks
ParticipantI 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?
August 4, 2014 at 2:07 pm #4964Matt Brooks
ParticipantI 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
August 4, 2014 at 8:56 pm #4965Scott Voth
KeymasterGood research here – thanks Matt! @r-a-y – do you think this is a bug, or maybe an enhancement will handle this situation a little more efficiently? Thanks!
August 5, 2014 at 7:45 am #4966Matt Brooks
ParticipantMaybe 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 7, 2014 at 12:04 pm #4968Ray
KeymasterHi Matt,
Thanks for debugging. I would raise an issue on the BuddyPress Docs ticket page:
https://github.com/boonebgorges/buddypress-docs/issuesIn the meantime, I would look at disabling the attachment loop on the wiki homepage since you have a ton of attachments on your wiki.
Copy
/wp-content/plugins/buddypress-docs/includes/templates/docs/docs-loop.php
towp-content/themes/cbox-theme/docs/docs-loop.php
.Open up
/wp-content/cbox-theme/docs/docs-loop.php
, and remove the following lines:<div class="bp-docs-attachment-drawer" id="bp-docs-attachment-drawer-<?php echo get_the_ID() ?>"> <?php bp_docs_doc_attachment_drawer() ?> </div>
I’m comtemplating making this change directly for
cbox-theme
as attachments on the wiki homepage are hard to contextualize without reading the entire, individual wiki page.I’ll ping Boone (@cbox_admin), who is the plugin creator, on this thread so he’ll be able to chime in as well.
August 7, 2014 at 1:18 pm #4970Boone Gorges
KeymasterMatt – Nice detective work 🙂
It does look like this is a bug. Following the function stack you provided, you can see that bp_docs_attachment_protection() is called with no params, which means that the $force_check value should be set to its default, which is false. In the check_is_protected() method, $force_check=false means that the ‘bp_docs_attachment_protection’ value should be checked first, which if found will skip running the HTTP request. (This is similar to what you suggest with “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”, except that it’s good across page loads).
So, something is going wrong. My guess is that, for some reason or other, the bp_docs_attachment_protection option is not being set at the end of the check_is_protected() method. It’s not obvious how or why this would happen, though. Since you’ve gone this far down the rabbithole already, maybe you could do a bit more to see if you can figure out why this is not happening. Things to check:
– is $force_check indeed defaulting to false on these calls?
– is the .htaccess file being created as expected?
– what is the return value of the wp_remote_get() call?
– when bp_update_option() is run, is it returning true or false?August 13, 2014 at 3:56 pm #4993Matt Brooks
Participant@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 25, 2014 at 10:00 am #5062Matt Brooks
Participant@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 ago by
Matt Brooks.
August 25, 2014 at 11:12 am #5064Ray
KeymasterI think the problem is
bp_update_option()
not returning anything for BuddyPress v2.0.2 and below.BP recently made the change to fix this in v2.1-beta1:
https://buddypress.trac.wordpress.org/ticket/5518August 25, 2014 at 3:20 pm #5065Boone Gorges
Keymaster@brooks1man – Thanks so much for the debugging.
It looks like there’s an error in my logic in
check_is_protected()
. Can you change this lineif ( '' === $is_protected ) {
to
if ( '' !== $is_protected ) {
to see if that fixes the problem? I’m pretty sure that’s it 🙂
August 25, 2014 at 3:30 pm #5066Matt Brooks
ParticipantNo 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.
-
This reply was modified 10 years ago by
-
AuthorPosts
- You must be logged in to reply to this topic.