Symphony.

I did. :)

Aham! So that's the reason for the change :P :)

Aham! So that's the reason for the change :P :)

Well, I don't really know, to be honest. When I reported the bug, there was no sort order at all. My clients complained about lost articles, and when I dug into it I found the order to be quite random.

But maybe the sort order is automatically reflected by the sort order in the backend, and there was something else going on, I don't know.

Sorry for possibly stupid questions, but, after reading this discussion I started feeling that I might be missing something important in the whole concept.
First, why people mention "Sort Order" in relation to SBLF? Isn't Sort Order a property of Data Source? So,then, how can it affect the order in which values are displayed in the drop-down list of SBLF?
Then, I've seen mentioning of using SBLF in the frontend. How is it possible? Isn't frontend what the regular (not logged in "yoursite"/symphony) visitors are seeing?

I too get confused about this sort order discussion. All I would ever want the options to be sorted by is alphabetical. Why would anyone want it any other way? If you wanted custom sort and the like, you should be choosing a field like SSM.

This is just overcomplicating a very useful simple field.

All I would ever want the options to be sorted by is alphabetical. Why would anyone want it any other way?

Imagine linking featured articles on your homepage. Then I would prefer to sort the options by date they were added: I will probably need recent items more than articles starting with an A.

Isn't Sort Order a property of Data Source?

Yes, is it. But in the backend (where the data is entered) the options are also sorted in some way. This is the sort order the discussion is about.

@designermonkey: to add on that, because the list is actually truncated this is an actual problem. If all articles were displayed alphabetical order would be just fine.

Imagine linking featured articles on your homepage. Then I would prefer to sort the options by date they were added: I will probably need recent items more than articles starting with an A.

Thanks. I was about to ask what would be the possible use cases where other than alphabetical order may be useful. But, from what I've read here, 90% of use cases are those where alphabetical order is the best and no "Limit to the most recent entries" is necessary. Like

1. assigning a category to an article
2. selecting a group for a product
3. choosing an album for a song

And, of cause, the best way to display those lists of 'categories', 'groups', 'albums' and so on is in alphabetical order, and showing all the choices without limitation.
This looks to me the most classical way of using the select boxes.
Am I wrong?
(I'm not argueing, as it might look like due to my poor knowledge of English and Symphony. Just want to provoke people for answering some questions I couldn't find the answer, yet).

And, of cause, the best way to display those lists of 'categories', 'groups', 'albums' and so on is in alphabetical order, and showing all the choices without limitation.

Yes, sure. But the problem is this: when you have lots and lots of articles (think thousands), you don't want your list to be that huge, both for usability (try selecting an article when there are thousand articles above it!) and performance (loading all of those records in the html will melt your computer).

Thanks for the examples, of course I would use an SSM for all of those.

Thanks for the examples, of course I would use an SSM for all of those.

Sure, the SSM works in these situations, but it too does not cope well with thousands of entries. Also, if you have many of these fields in the same section the interface is very cluttered and not really user-friendly (not to mention slow!).

So, let me put it out there again: my vote would be to use Select2: it is a default selectbox at heart, but you can add pagination, searching and multiselect using JS. So your client will either see the default select box, or a very nice, user friendly interface.

Also, because Select2 can lazy load the entries, the problem of the limiting/ordering is solved.

The only problem is the license, but I am sure we can work something out with the author.

my vote would be to use Select2

As long as you have (only) a few thousand entries, you can easily put the Select2 JavaScript on top of the current implementation. I did this using an extension (called "Client XYZ Backend Assets"), and it works fine. So in this case there is no need to bloat the core field.

I think it is a very good feature — the SBL field reflecting the entry order. Just tell your authors (or use Select2, see above).

As long as you have (only) a few thousand entries, you can easily put the Select2 JavaScript on top of the current implementation.

Hmm. This is not really what I experienced: the browser would often have quite a hard time rendering the page if that many entries were in the selectbox.

Ah well, it seems like I alone in this, so I will drop the subject and just modify the extension for my needs. Thanks all for your opinions!

One last thing though: the reason for me to suggest these changes is not because I like the added features, but because I want to fix important problems. In my opinion, if you are bundling extensions with the core, you better make sure they are damn good at what they do, even if that's not much (like the text input).

And, frankly, at this moment I don't think the SBL falls in that category: its queries are slow, its interface isn't user friendly and it can even break your content if you are not careful (try editing an old entry if you have the limit on the SBL set to something like 100, and the originally linked item is no longer on the list to see what I mean).

So no, I don't consider something like the Select2 library to be bloat, I consider it to be a necessary evil to fix fundamental problems with one of the most powerful fields available.

/rant

try editing an old entry if you have the limit on the SBL set to something like 100, and the originally linked item is no longer on the list to see what I mean

There is code to prevent this happening. If you're experiencing this, it's a bug.

There is code to prevent this happening. If you're experiencing this, it's a bug.

Just checked: with SBL 1.20 on 2.2.3 this is very much happening. I have to hack the DOM to get the correct entry in. Is this fixed in a later release, or should I file a bug?

No, it was fixed years ago. If the current value isn't in the limited list, it should be appended to the top of the list of options where the option should have a selected attribute. You're saying the value is lost?

You're saying the value is lost?

Yep. In my setup I have a "reactions" section, with text and all that, and a SBL link to the same section, to indicate responses (parent/child relation).

Now, if I go to publish/reacties/?filter=parent:393, I get one entry in the entry list, so that should have a parent field with value 393, right?

If I then go to the publish page of that entry, the SBL field is blank.

I just checked out the 1.2.0 tag of the SBL, and there is indeed code in place to prevent this from happening, so why I am seeing this I do not know.

After upgrade to 2.2.5 from 2.2.1 i've tried to upgrade SBL to the latest version. FastCGI sent in stderr: "PHP Fatal error: Class extensionselectboxlinkfield contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Extension::about) in /var/www/academiatest/docs/extensions/selectboxlinkfield/extension.driver.php on line 91" What does it mean? I can't event open the Extensions page.

Huib, Nick, Michael, John – guys: do you remember that there was a reason why we talked about fixing relationship management in the core and create a new Relationship field when we were in Cologne?

Time to get that done - we need a single working solution that extension can build upon.

PS: Huib's exams seem to be quite easy, so maybe he could just start with it ;)

After upgrade to 2.2.5 from 2.2.1 i've tried to upgrade SBL to the latest version.

You are using a version that is meant to work with Symphony 2.3. I'm not sure which version is the right one, but you need an earlier one.