Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 11 years ago

Last modified 3 years ago

#5404 closed defect (bug) (fixed)

Can't go on the latest page of "Members"

Reported by: elpix's profile elpix Owned by: r-a-y's profile r-a-y
Milestone: 2.0 Priority: normal
Severity: normal Version: 1.9.2
Component: Appearance - Template Pack Keywords: has-patch commit
Cc:

Description

Hi there,

I have a big BP website (30,000 members on february 2014), and the problem is that I can't go on the last page of my members page : http://www.biowebspin.com/members/

Apache have a segfault, because of the very big request.

Do not hesitate to contact me for more information.

Bye

Attachments (3)

5404.01.patch (560 bytes) - added by r-a-y 11 years ago.
5404.01.2.patch (1.1 KB) - added by r-a-y 11 years ago.
Updated to fix logic problems.
5404.02.patch (1.1 KB) - added by r-a-y 11 years ago.
Follows my second approach I mentioned in comment:10 and is way cleaner.

Download all attachments as: .zip

Change History (18)

#1 @boonebgorges
11 years ago

  • Keywords reporter-feedback added

because of the very big request.

Can you say more about this "big request"? What are you seeing in your Apache logs?

#2 @elpix
11 years ago

Hi Georges !

Sorry, I have nothing in my logs.

A little bit more about the error :

  • When you go on the page (you type the url in your browser), everything is OK : http://www.biowebspin.com/members/?upage=1778
  • When you use the pagination (it use AJAX), something like 12,000 members are returned and it crash your browser, apache seems good.

In my logs, I see :

[18/Feb/2014:15:27:12 +0100] "POST /wp-admin/admin-ajax.php HTTP/1.1" 200 29475 "http://www.biowebspin.com/members/?upage=1780" "Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"

As I use "BWP Minify", I have others errors like :

[Tue Feb 18 15:29:21 2014] [error] [client 119.147.146.189] (36)File name too long: access to /wp-content/plugins/bwp-minify/min/,qf=wp-content,_plugins,_bp-bookmarklet,_js,_bookmarklet-button.js,,wp-includes,_js,_thickbox,_thickbox.js,,wp-content,_plugins,_contact-form-7,_includes,_js,_jquery.form.min.js,,wp-content,_plugins,_contact-form-7,_includes,_js,_scripts.js,,wp-content,_plugins,_invite-anyone,_by-email,_cloudsponge-js.js.pagespeed.jm._8_fhzpx0s.js/"+urlnoquery[0]+" failed

[Tue Feb 18 15:29:21 2014] [error] [client 119.147.146.189] (36)File name too long: access to /wp-content/plugins/bwp-minify/min/,qf=wp-content,_plugins,_bp-bookmarklet,_js,_bookmarklet-button.js,,wp-includes,_js,_thickbox,_thickbox.js,,wp-content,_plugins,_contact-form-7,_includes,_js,_jquery.form.min.js,,wp-content,_plugins,_contact-form-7,_includes,_js,_scripts.js,,wp-content,_plugins,_invite-anyone,_by-email,_cloudsponge-js.js.pagespeed.jm._8_fhzpx0s.js/'+m.iframesrc+' failed

Maybe it's linked, I don't know ...

#3 @boonebgorges
11 years ago

As I use "BWP Minify", I have others errors like :

Have you tried disabling this to see if it makes a difference?

When you use the pagination (it use AJAX), something like 12,000 members are returned and it crash your browser

This is probably the root of the problem. It should not be returning all members.

What theme are you using? What customizations have you put into place?

#4 @elpix
11 years ago

Without BWP Minify, the problem is still here.

My theme is this one : http://themeforest.net/item/buddy-multipurpose-wordpress-buddypress-theme/3506362?WT.ac=category_thumb&WT.seg_1=category_thumb&WT.z_author=GhostPool

I have lots of plugins, but no particular modifications on this part.

#5 @boonebgorges
11 years ago

Thanks. I don't have access to that theme, so it's a bit hard for me to test. Is it possible to briefly switch to a standard theme (like TwentyTwelve) to test whether the problem persists? At least that would help to narrow down the issue.

#6 @elpix
11 years ago

OK, I will try this on WE

#7 @elpix
11 years ago

Hi !

I've maybe an idea.

As some users have never been active on my website, I had to activate them manually like that :

$users = $wpdb->get_results("
SELECT  `ID` ,  `user_registered` 
FROM  `wp_users` 
WHERE ID NOT 
IN (

SELECT DISTINCT (
user_id
)
FROM  `wp_usermeta` 
WHERE  `meta_key` =  'lastvisit'
OR  `meta_key` =  'last_activity'
)
");

foreach($users as $user){
	$wpdb->query("INSERT IGNORE INTO wp_usermeta(user_id , meta_key , meta_value) VALUES (".$user->ID." , 'lastvisit' , '".$user->user_registered."')");
	$wpdb->query("INSERT IGNORE INTO wp_usermeta(user_id , meta_key , meta_value) VALUES (".$user->ID." , 'last_activity' , '".$user->user_registered."')");

}		

As many of them had this problem, it's maybe the source of the bug !

#8 @boonebgorges
11 years ago

Hm. I'm not sure how this one-time operation would cause problems with every members SELECT query, unless you're running the INSERT query every time WP loads!

#9 @elpix
11 years ago

No, I do this query one a month.

But maybe I've forgotten to add something in the query, and that's why it return me something like 12,000 members in one page !

Last edited 11 years ago by elpix (previous) (diff)

#10 @r-a-y
11 years ago

If I click on the last page in your member pagination links (the 2296th page), the POST request shows that the 'page' number is NaN.

The led me to discover that the problem is with our javascript.

We attempt to force convert a string to a number. But since elpix has so many members, the '2,296' string doesn't properly get converted to a number.

Attached patch is a quick fix at the problem by stripping all commas from the page number string. Perhaps a better idea would be to take the integer from the upage parameter in the href attribute.

Version 1, edited 11 years ago by r-a-y (previous) (next) (diff)

@r-a-y
11 years ago

#11 @r-a-y
11 years ago

  • Keywords has-patch added; reporter-feedback removed

@r-a-y
11 years ago

Updated to fix logic problems.

@r-a-y
11 years ago

Follows my second approach I mentioned in comment:10 and is way cleaner.

#12 @boonebgorges
11 years ago

  • Keywords commit added

Nice find! And yes, .02 is much better. Do it!

#13 @henry.wright
11 years ago

Hi r-a-y

One thing I noticed about the patch is upage. bp_has_members accepts page_arg so upage might not always be upage

#14 @r-a-y
11 years ago

  • Component changed from Members to Template Pack
  • Milestone changed from Awaiting Review to 2.0
  • Priority changed from highest to normal
  • Severity changed from critical to normal

Good point, henry.wright. I was thinking about that myself. Easy fix is to replace upage= with = in 02.patch.

FYI, the only way to duplicate the bug found by elpix is if:

  • the member loop is paginated
  • the member count in the loop makes pagination more than 1000 pages (or 20,000 members!)

This should only likely occur in the members directory and nowhere else. But, better to be safe than sorry!

#15 @r-a-y
11 years ago

  • Owner set to r-a-y
  • Resolution set to fixed
  • Status changed from new to closed

In 7946:

Fix AJAX pagination when clicked page number is 1000 or more.

Previously, BP's javascript was converting the paginated element
content to a number with the Number() function. This doesn't work
with comma-seperated number strings (eg. 1,000), which returned a NaN
value causing problems during the AJAX callback.

This commit changes the way the page number is parsed in BP's
javascript by grabbing the page number from the 'href' attribute.
Thereby, ensuring that AJAX pagination works for pages greater than
1000.

Fixes #5404

Note: See TracTickets for help on using tickets.