I have several WOWRosters in 'exploitation'.

The one of my Guild : http://www.papy-team.fr/roster/index.ph ... ercp&a=g:1
This one isn't a 100 % pure "version 2.0.2"
A more or less pure "2.0.2" is here : http://www.les-potes-ages.fr/roster/ind ... list&a=g:1

For both rosters, look at the bottom.
Debugging is put to on.

Several times, this shows up :

PHP Errors
addons/memberslist/guild/index.php
Notice line 261: Undefined offset: 1
Notice line 261: Undefined offset: 1
.....

What happens on line +/- 361 in addons/memberslist/guild/index.php :
This:
list( $curr, $max ) = isset( $r_prof[1] ) ? explode( ':', $r_prof[1] ) : array( 1, 1);
Throws an error because $r_prof[1] DOES NOT contain a ":"
Reason : $prof is somewhat been cut off around 350 characters.... it seems like its overflowing .... or these field are build dynamicly.

Here's one (an entire $row['professions'] of a player thats faulting ) :

Protection|1:1,Fureur|1:1,Armes|1:1,Enchantement|428:450,Couture|405:450,Secourisme|418:450,Pêche|185:225,Monte|300:300,Masses à deux mains|300:400,Masse|50:400,Mains nues|399:400,Haches à deux mains|400:400,Haches|400:400,Epées à deux mains|400:400,Epées|400:400,Défense|400:400,Dagues|350:400,Bâtons|1:400,Armes de jet|1:400,Armes d'hast|3

The 3 should be part of somthing like
Armes d'hast|300:300

It has been cut of.

Please, put on Debugging on the main CP page, and have a look if you guys find the same issue.

edit : I've another roster to maintain - just remebered about it - it was still running 2.0.1.
I checked if the same PHP errors were there, but : NO.
I upgraded the roster to 2.0.2.
The errors were there.
So, I went to the WEBSVN to see what happened.

Aha : if I take away the "2.0.2" version of the addons/memberlist/guild directory (or, to be more precise, the file index.php) : put back the 2.0.1 version of this file then the errors are gone.

2.0.1 version was:
$toolTip = (isset($r_prof[1]) ? str_replace(':','/',$r_prof[1]) : '');
2.0.2 version is now:
list( $curr, $max ) = isset( $r_prof[1] ) ? explode( ':', $r_prof[1] ) : array( 1, 1);
$toolTip = $curr . "/" . $max;
in addons/memberlist/guild/index.php

Yeah, that column is constructed with GROUP_CONCAT from an external table. I didn't know there was a length limit for that.

This wasn't an issue in 1.7, since that did a separate query for each member to fetch profession info. If I ever grab some time together to work on memberslist again, I may implement a different solution. But don't hold your breath.

PleegWat wrote:Yeah, that column is constructed with GROUP_CONCAT from an external table. I didn't know there was a length limit for that.

Me neither, Google "group_concat_max_len" and you find out that it exists, and it's normally 1024 bytes/chars. It can be SET GLOBAL if you are the super user in MySQL, which of course, I'm not.
NO way to see it neither to check its value.....
This means that WOWRoster 5.0 (WOW 6.1 ^^) will walk out of it. GROUP_CONCAT will still work, but it will start to return BLOB's (glup).
I don't think this is an issue right now.

PleegWat wrote:This wasn't an issue in 1.7, since that did a separate query for each member to fetch profession info. If I ever grab some time together to work on memberslist again, I may implement a different solution. But don't hold your breath.

Yeah, I saw that, most of us use the memberlist as the main roster page, and building it would fire many SQL commands.
Now, the entire thing is being extracted in one shot - quiet amazing actually.

But please read my edit : 2.0.1 doesn't show the behaviour - 2.0.2 does.
2 lines changed, that's it.
I just can't see why right now, but I'll find out why.

I just wanted to know if I was running against my own errors from edits locally ^^ Do YOU see these errors also - because if not, my findings here are nearly useless :-) ??
----------

[some time later on... and some mind doping]

I still see the professions element being broken off.
Googling told me not to do the
.... ORDER BY `proftable`.`skill_order`.... part because "it could mess thinks up", so I removed that part : amasing, half the errors went a way !!
Now I have this warm fussy feeling that it could be me my host implementation with its MYSQL . Nice.

Then, an idea came in : look at this line :
'LEFT JOIN `'.$roster->db->table('skills').'` AS proftable ON `members`.`member_id` = `proftable`.`member_id` AND (`proftable`.`skill_order` = 2 OR `proftable`.`skill_order` = 3) '.

I added the black part because all skill icons are allways taken from skill_order 2 or 3 - without any exception (checked in four Guilds, 2 languages).
Now, my 'professions' is being given back as :

Cooking|450:450,Enchanting|414:450,First Aid|450:450,Fishing|450:450,Inscription|431:450,Riding|300:300

and just that.

Now, no more PHP errors - and some speed improvement of course.

The bug comes from this bit:

Code: Select all

list( $curr, $max ) = isset( $r_prof[1] ) ? explode( ':', $r_prof[1] ) : array( 1, 1);

I changed that code when I added separate flying icons - I needed to switch on the current amount of skill.

The sort in the query ensures the professions (skill order 2, in your case enchanting and inscription) are before the secondary skills (cooking, fishing, first aid, riding).

I'll put your filter in though. I checked back to the 1.7.3 code, it filters on the localized names we store for 'professions' and 'secondary skills'. skill_order should be safe, I don't think any of the categories are ever empty, especially not category 1 which holds the names of your talent trees.

Ok, figured out already that I could safely put back the ordering statements.
The list with profs. mentionned above doesn't take that in account.

Now, as my roster shows, http://www.papy-team.fr/roster/ skill icons are sorted as usual:
Inscription|431:450,Enchanting|414:450,Riding|300:300,Fishing|450:450,First Aid|450:450,Cooking|450:450

skill_order 2 comes first, 3 afterwards.

Filtering on these skill_order means some degree of hard-coding here, but it has to be done some where anyway.

The issue remains that your code (the line you mentionned) wasn't faulty - the original query contains a value, professions, that was being cut off for what reason so ever, I presume exceeding size.
When I stopped sorting, in theory, the size doesn't change, but the number of errors became less.

What I did to have a good check visually on what is happeing, is copying the huge SQL statement (visible in my roster now) - throwing it in phpmyadmin on the SQL page, and then, on the bottom of the result page, use Print view (with full text) [abandon the print popup windows].
Look carefully in the professions colum, you will find some strings that are truncated....
Guess I never know why exactly.