Symphony.

Awse.

That's awesome! 80% fewer queries and 1/3 less memory used. Can't wait to see this in the repo, I'm going to roll this out to a ton of sites if it works!

Will it remain backwards compatible? I think fields like the Reference link extend the SBL, so will function signatures remain the same?

• It's already in the integration branch
• It's backwards compatible
• Some function signatures have changed, but they were fortunately all private or protected, and in RL's case, it didn't extend SBL so it will continue to work (and prosper)

I already talk about this, but since the recent update, I had to bring back my hack in order to make the SBL filtering according to the multilingual handle. I know some of you are not trilled with the idea of coupling extension together, but in this case, I can't think of any other way to do this, except copying code from the Language Redirect Extension.

Basically, the behaviour I implement in a few extension if this - Get the status of the extension with the ExtensionManager()->fetchStatus(); hold this in private var - If INSTALLED or REQUIRES_UPDATE (even if it's never RU), include the LanguageRedirect class - When filtering, check if it's multilingual: if so update the WHERE clause accordingly

I would love to have you 0.02$ (again) on this, as ALL my site I build are multilingual.

EDIT: BTW, I know Sym3 will be much more friendly for this... what about NOW ?

EDIT: BTW, I know Sym3 will be much more friendly for this... what about NOW ?

It's a fair point and to be honest, I don't know. It's part of a much bigger problem/situation and applying little hacks and dependencies on other extensions is not a solution, at least not from an official stance. Symphony core extensions are designed to be black boxes that don't depend on other extensions, and it's risky to depend on a third party extension. Consider if the Language Redirect extension becomes deprecated, or if a new extension comes out that fixes the problem better/is more powerful etc, suddenly the core is out of date.

It's something that does need to be fixed, at a core level I would think, so that all field extensions can just 'work' in a multilingual environment. It'll be relatively complex thing to get right, partly because people use language in very different ways (ie. Fields having languages, or the whole Entry having a language). Language isn't part of the 2.3 scope, not at the this stage anyway, and to be honest, the likelihood of it being included is low due to the complexity and the resources we have available for this release.

@brendo: then we need to address this problem ASAP. As for Sym3, I was referring to the 3.0 version, not the 2.3.

I know the dependency with other ext is not good, but I can not think of anything else. Multilingual support in the core is a feature we need to leverage.

What are the basic things that block this at the core level ? Why having the language at the entry level ? Only field level is required, as you only have to uses multilingual fields everywhere in your section.

Again, I repeat, what about now ? If no merge is possible, I will publish my SBL multilingual on the site, for those who absolutely need it.

Please do not force "mutlilingual fields" method onto everyone.

Maybe it will be better to add some delegates, that will allow multilingual field extension do do its magic, without pushing it down everyones throat.

One of the reasons that Symphony is so great is its flexibility. Right now we can implement content translation in multiple ways. "multilingual field" is not suitable for all projects out there.

I second ahwayakchih. Quite often it makes sense to use both methods, multilingual fields and entries flagged with a language, in a single project.

@klaftertief, @ahwayakchih: I think I did not made myself clear. I do not wanna force anything, because flexibility is a super nice attribute to have in a CMS. What I was saying is there should be something in the core to "flag" a field as being a multilingual one, since coupling ext together is not "nice".

BUT, I can't think of any other way to make the SBL filter as I want it: Be able to filter in the good language, if I do not include some ref to the ML field.

I think this multilingual discussion should be taken to a new thread.

@Lewis: Maybe, but the issue is REALLY about the SBL, as this fields brings as lot of hicks in a Multi Lingual Environment because the SBL depends on others' fields values. I am trying to find a way to modify it in order to work well in MLE.

@ahwayakchih: I have two and a half questions for you:

1- Since relating to other extensions' name is not "kasher", is relying on a certain format is ? What if Multilingual Fields of all kind SHALL respect the 'field-name'-'lang-code' format ?

1a- If #1 is positive, how can we detect those fields in the SQL ?

2- How about having Abstracted Extensions or API Extensions ? Those extensions only offers PHP classes and methods that addresses particular recurrent issues. Than programmers could build extensions, check if the API is present or not and behave in a correct manner either way. I am thinking about the LanguageRedirect Class in the language_redirect ext. A couple of extension already depends in this class.

Thanks you for time to read my ideas!

As Nils says, can we start a new thread to discuss this? This is now beyond the specifics of the SBL.

ok ok : see http://getsymphony.com/discuss/thread/74319/

Is there any way to sort/group entries in back-end by linked field? Maybe i should use some alternative approach?

Basically, i want to sort entries of section works by field name from linked section authors.

It seems GitHub issues are disabled for this extension.

I have a feature request: Wouldn't it be possible to filter values of a selectbox by a determined filter from settings? System ID, title or whatever fields are in the section where the entries come from.

I have a section with 200 articles and they are ordered by Order Entries. This is the sort order that SBL uses to show entries as well, but I would better use sorting by title when adding a comment.

Of course I'm not adding the comment in backend, but if necessary, adding it is cumbersome.

Thanks

Let's pretend I never posted this here.

I spotted a (small) problem related to the Select Box Link field during the set up of a front end form. In the section I would like to submit the data I have a Select Box Link field with the option “Allow selection of multiple options” enabled.

Whenever I select several options in the front end form and the submission event returns an error, not all the values of the Select Box Link options already selected are returned in the post-values list – which stores only one of them – therefore in the form page which needs to be corrected I’m not able to make Symphony automatically re-selecting all the options the user has just chosen.

Does your form markup send the option as an array? Note the trailing square brackets indicating that an array is being sent:

<select name="fields[your-field-name][]">...</select>

You’re right Nick, since I was not aware of the function of those trailing square brackets before now I completely forgot to add them in my code markup… that was the reason it wasn’t working… thank you very much for the tip! Be patient, my lack of knowledge stroke again….

Is it possible to filter values in the selectbox link?
For example; I got section 'a' which has a select box link field linked to a name field in section 'b'.
section b has a select box field (not select box link) with dynamic values taken from the title field of section a.

In this case i would like to filter the values in the selectbox link field by the value of the title field in section a.
So the selectbox link list would only contain the values that are linked to the current record (section a)... hope this makes sense

Seems the selectbox link doesn't support this kind of filtering… or would there be a better way to approach this? any suggestions?

Thanks