Hi everybody,
I've just created this as bug #121, but it ends with a question, so I
thought I should post here to get your opinions.
(This is on 1.10.7, but probably applicable to newer Bricolages.)
When a story has a large number of contributors (larger than the
pagination number), a few bad behaviours emerge:
1. The edit-contributors screen inside the story offers pagination and
"show all" links, but these do nothing when clicked.
2. The order of contributors set with the number-pulldowns is not
respected. For example, set one contributor to #1, then save and stay.
The #1 spot will be occupied by a contributor other than the one just
selected.
My best guess is that pagination and user-controlled ordering are not
playing well together. So if there are 55 contributors, and the first 50
show up on the edit screen, contribs 51-55 do not get order numbers at
all, and this snaps them to the head of the line on a save.
I'm not sure there's an easy way to do user-controlled ordering without
having all the elements (in this case, contributors) present at once.
Anyway, a quick fix that worked for me was a change
to /comp/widgets/listManager.mc. Here's a summary:
I removed the line initializing $limit from the <%init> block, and added
$limit to the <%args> block, with the default value set to the same
thing that used to be present in the <%init>:
Bric::Util::Pref->lookup_val( 'Search Results / Page' ) || 0
Then, in /comp/widgets/story_prof, in the call to listManager.mc, I set
the limit to a number three times larger than the total number of
contributors in the system. Now the screen shows all the contribs in the
story, and everything works fine.
Obviously, this introduces a hard-coded value where there shouldn't be
one. Would it just be smarter to have listManager.mc check for sorting
by order, and have it set $limit to 0 whenever that is the case?
Thanks,
Bret
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com
I've just created this as bug #121, but it ends with a question, so I
thought I should post here to get your opinions.
(This is on 1.10.7, but probably applicable to newer Bricolages.)
When a story has a large number of contributors (larger than the
pagination number), a few bad behaviours emerge:
1. The edit-contributors screen inside the story offers pagination and
"show all" links, but these do nothing when clicked.
2. The order of contributors set with the number-pulldowns is not
respected. For example, set one contributor to #1, then save and stay.
The #1 spot will be occupied by a contributor other than the one just
selected.
My best guess is that pagination and user-controlled ordering are not
playing well together. So if there are 55 contributors, and the first 50
show up on the edit screen, contribs 51-55 do not get order numbers at
all, and this snaps them to the head of the line on a save.
I'm not sure there's an easy way to do user-controlled ordering without
having all the elements (in this case, contributors) present at once.
Anyway, a quick fix that worked for me was a change
to /comp/widgets/listManager.mc. Here's a summary:
I removed the line initializing $limit from the <%init> block, and added
$limit to the <%args> block, with the default value set to the same
thing that used to be present in the <%init>:
Bric::Util::Pref->lookup_val( 'Search Results / Page' ) || 0
Then, in /comp/widgets/story_prof, in the call to listManager.mc, I set
the limit to a number three times larger than the total number of
contributors in the system. Now the screen shows all the contribs in the
story, and everything works fine.
Obviously, this introduces a hard-coded value where there shouldn't be
one. Would it just be smarter to have listManager.mc check for sorting
by order, and have it set $limit to 0 whenever that is the case?
Thanks,
Bret
--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret@pectopah.com
www.pectopah.com