Search

Hi to all symphonists !

I have been using about 30 extensions together in order to build several website and I must say it has been working great. But today I came across a issue when combining the two extensions mention in the title: Select Box Link + Multilingual Field.

The objective of this post is to have your opinion and idea before I switch to my alternative method (more on that later...)

The current implementation is this:

-A news categories section that contains 2 fields: Title (ML field), Entry Order.

-A news section that contains some obvious field (title, body, image, date...) and a select box field related to the title of the news categories, with multiple selection enable.

In the DS, I use the select box link in order to filter news based on categories. I works great in the default language (fr) but fail in other languages (en). I found out this is because the where clause is done directly to the handle column and not the handle-{lang} one.

So, how can we change this ? How to change which column is use in the select ?

If this requires to much effort, my alternative method is to use a plain text input and tell my client this will be the key for filtering (since it is a list based filtering, with predefined urls).

I really like symphony and would really appreciate your $0.02 on this. Thanks

@Nitriques: a rapid solution could be use always the handle of default language to filter the news datasource. The multilingual field display handles in all languages in the datasource, so you can selecte the default value from there to pas as parameter to the datasource.

@Nitriques

This is a problem I faced as well. It lies between lines 440 and 448 in selectbox_link_field/fields/field.selectbox_link.php. This query looks only for handle field in current table; instead it should search for handle-<country-code>.

The obvious solution is to add the current language handle in the query.

$return = Symphony::Database()->fetchCol("id", sprintf(
    "SELECT
        `entry_id` as `id`
    FROM
        `sym_entries_data_%d`
    WHERE
        `handle-%s` = '%s'
    LIMIT 1", $related_field_id, $currentLanguage, Lang::createHandle($value)
));

It should be fetched form $this->_parent->_env[] array, but at the time of the execution this array is not yet populated (a.k.a. empty).

The only option remains for Language Redirect to provide a static method to access the current language. I'm using a dirty solution a.t.m. from my Page LHandles extension witch outputs the current language.

I'll fork Language Redirect and provide the necessary modifications.

Thanks for your relies !

@guillem_l: I though of that, but I don't feel safe with that since my xsl will be used across multiple site and I cannot guarantee which language will be the default one.

@vladG: Super, wow ! I took the time to read the code you mention but was not sure it was the right thing to change. I am beginning to learn the php framework for symphony so my skill are very low about extensions. How can I access the data provided by your Page LHandles extension in php ? (extention that I use too).

You really are nice to explain this to me. It takes time to do and it is appreciated and makes me wanna participate more in the symphony cms community. I really like it and I will do my best in order to promote it.

Thanks

And maybe this extension could help ? http://getsymphony.com/download/extensions/view/70912/ Available languages

@Nitriques

You're welcome.

The catch with Available languages is that it provides the languages as an event which fires, after the execution of datasources so it is useless in this context. I already contacted klaftertief, the author of Language Redirect, and an update of the extension will come soon.

How can I access the data provided by your Page LHandles extension in php?

Well, that's implemented on my local version of Page LHandles as a quick & dirty & "temporary :))" solution. The good practice, clean thing is to add it to Language Redirect.

Stay tuned ...

@Nitriques: Inside language-redirect event do you have the tag supported-languages, the first item of this list is your default language. You can use it to get default language in each site.

@vladG: Thanks I stay tune for this !

@guillem_l: I need the information in php, not in xsl... how about that ?

@Nitriques: Where do you need it?

@guillem_l: see comment #3 on this thread...

@vladG: what about Lang::get() ?

From: http://getsymphony.com/learn/api/2.2.1/toolkit/lang/

@Nitriques: In comment #7, I give you a soultion to get the dafault language in order to implement the rapid fix I propouse in comment #2. You don't need to modify any php file. Just in your xsl, where do you give value to the param used to filter datasource use the handle value of the default language.

@vladG: never mind Lang::get() always returns en for me, even if i am in fr

@guillem_I: I cannot do the filtering in the xsl because it messes my pagination

@vladG: I sucessfully had it by usign General::Sanitize($_REQUEST['language']) which do not relies on anything else to do it... I send you a pull request

Now, how about detecting that multilingual field is enable ? I would like to have a downfall in case the handle- column does not exists ???

Thank you so much

Lang::get() returns the Symphony language, not the language of the browser (which is what Language Redirect does)

@nitriques

Check this out https://github.com/vlad-ghita/language_redirect/tree/1.0.2. There's a new class in town in lib/class.languager.php. You can now make something like this in SBL field (it works, just tested it on my multilang sites):

$return = Symphony::Database()->fetchCol("id", sprintf(
    "SELECT
        `entry_id` as `id`
    FROM
        `sym_entries_data_%d`
    WHERE
        `handle-%s` = '%s'
    LIMIT 1", $related_field_id, LanguageR::instance()->getLanguageCode(), Lang::createHandle($value)
));

@vladG: Wow super ! You did add this class in your lr ext ? That is awesome man! I always though that programming will befenit from peers and that we should not want to reinvent the wheel.

So if I follow you ? I must update the two ext (lr and sbl) ?

Soooo many thanks. If I can help you with anything I would be super nice.

Finally could with do something like this pseudo code ?

if symentriesdata%d has column handle- // btw should it be tbl instead of sym_ ?

$where = 'handle-%s'

else

$where = 'handle'

That way, the ext would be compatible with anything... This is something I though of a week ago while looking at other ext's code. Another path could be creating another class that inherits from the one without languages ? So many ideas, so little time to realize them...

Another path could be creating another class that inherits from the one without languages ?

It is only a small modification but I think another class would be better because PROBABLY there will be other modifications needed in SBL because of Multilingual Field.

I'll take care of updating my SBL to latest today and create a multilingual branch for Multilingual Field compatibility.

Update (9:45): I decided to wait for 1.20 stable release for SBL. It is still in development. Then I'll make the necessary modifications.

ok super #1.

But branches are not helping maintainability... i would do something like this

Create a new extension that inherits from the first one. The new extension "SBL ML" will added a new field type, select box link ml. That way, both behaviour could be used on the same site... what do you think ?

We could do that for a lot more extensions... a neutral version and than a ML version, without only few bits of code.

We're on a mission as a community to thin out duplicate extensions, so I'd frown on this approach as being counter intuitive. The recommended approach (although still undocumented) is to fork the extension and add the features you require, and your name to the developers list. If the features are useful, they would be pulled in, otherwise, you have a custom version to use yourself.

It would be best to wait for the release of 1.20, it's just around the corner.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details