Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Releases and Announcements /

Latest news about the SilverStripe software.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

SilverStripe 2.3.2-rc1


Go to End
Reply


27 Posts   7041 Views

Avatar
Andy

230 Posts

20 May 2009 at 5:53pm

We have a new release of SilverStripe available: 2.3.2-rc1

We'd appreciate everyone's help testing it, so that we can make a stable release as soon as possible.

Download here: http://www.silverstripe.org/assets/downloads/SilverStripe-v2.3.2-rc1.tar.gz
Post bug reports here: http://open.silverstripe.com
Changelog here: http://open.silverstripe.org/wiki/ChangeLog/2.3.2

Thanks,
Andrew O'Neil

Avatar
slang

Community Member, 6 Posts

20 May 2009 at 11:14pm

Hi.

I've just tried several installs of this one, both upgrades over prev 2.3.2-beta1 and completely clean. I'm hitting an error trying to get to /admin;

Couldn't run query: SELECT Distinct Locale FROM SiteTree GROUP BY Locale Unknown column 'Locale' in 'field list'
Line 400 of MySQLDatabase.php

with a stack trace etc.

Apologies - haven't used trac before and am not sure if this is right place to post feedback like this. I can't ever get past this, and don't know enough about the cms code to diagnose any more.

Wonder what my locale is?

Cheers -

Avatar
gerwout

Community Member, 1 Post

21 May 2009 at 1:43pm

I had the same and I fixed it (it's a hack) in the file Translatable.php.
Go the static function get_existing_content_languages($className = 'SiteTree', $where = '')
and comment the following lines:
$baseTable = ClassInfo::baseDataClass($className);
$query = new SQLQuery('Distinct Locale',$baseTable,$where,"",'Locale');
$dbLangs = $query->execute()->column();
$langlist = array_merge((array)Translatable::default_locale(), (array)$dbLangs);

After commenting this lines please add the following.
// custum hack/fix for multiple language bug when trying to login
$langlist = (array)Translatable::default_locale();

I didn't had this with a new install, but only with a upgrade. I think that it's caused by the subsites-module, but I am not sure of that. The subsites table in the database does contain a locale field.

Can you please tell me if you have the subsites module installed?

Avatar
slang

Community Member, 6 Posts

21 May 2009 at 4:39pm

Hi.

Thanx for the 'hack' - thought it may be in translation stuff somewhere from the little peek around that I had done.

It's fixed the issue for me.

I was experiencing the problem on vanilla installs with no modules at all and have/had done a dev/build several times - maybe that influenced behaviour a bit? The installs were into an empty directory and a new (or rather a recreated) database, so maybe something was being cached.

I'm now trying to get userforms to work, but that's another story...

Cheers -

Avatar
Juanitou

Community Member, 323 Posts

22 May 2009 at 12:33am

Edited: 22/05/2009 1:09am

@Andy

Hi!

For the moment being, this release candidate has resolved all the issues I had found with the beta. Good work!

Nevertheless I have a problem creating translations for pages created before upgrading: the original page is not being recorded in SiteTree_translationgroups, only the translated page which, by the way, appears in the CMS without the nifty original content in side-by-side grey boxes, ready to be translated. Adding manually the data in the table is a solution.

Avatar
Juanitou

Community Member, 323 Posts

23 May 2009 at 10:40pm

I continue testing this release candidate. Say we have a site with two languages. I've found that we can change the site locale (the Translatable one) by simply offering a link to a page in one language or another, that's nice. Here's my modified LanguageSwitcher function:

   function LanguageSwitcher() {
      
      if($this->URLSegment == "Security") return "";
      $langs = Translatable::get_existing_content_languages();
      $data = new DataObjectSet();
      foreach(array_keys($langs) as $code) {
         if($code == Translatable::get_current_locale()) {
            continue;
            }            
            if (!$this->hasTranslation($code)) {
               // If no translation, link to home page
               //echo "noTrans";
               $data->push(new ArrayData(array('name' => i18n::get_language_name(i18n::get_lang_from_locale($code), true),
                                       'link' => Director::baseURL() . Translatable::get_homepage_urlsegment_by_locale($code),
                                       'code' => $code)));
            } else {
               // If translation, link to translated page
               //echo "yesTrans";
               $page = $this->getTranslation($code);
               $data->push(new ArrayData(array('name' => i18n::get_language_name(i18n::get_lang_from_locale($code), true),
                                       'link' => Director::baseURL() . $page->URLSegment,
                                       'code' => $code)));
            }
         }
      return $data;
}

Nevertheless, if we don't append ?locale=$code to the link and use $_GET['locale'] in Page_controller init(), the i18n locale does not change and, for example, modules do not get translated or date format do not localize:

      global $allowed_locales;
      if((isset($_GET['locale'])) && array_key_exists($_GET['locale'], $allowed_locales)) {
         Translatable::set_current_locale($_GET['locale']);
         i18n::set_locale($_GET['locale']);
      } else {
         Translatable::set_current_locale(self::get_current_locale());
         i18n::set_locale(self::get_current_locale());
      }

It bothers me because I'd like to always have ‘pretty’ URLs, and for the moment I'm obliged to pass the locale at least once when changing languages. Also, if an user gets directly to a page in the non-default language, with a link not containing explicitly the locale, the content of the page will be for sure translated, but the translatable entities won't.

I know Translatable and i18n locales are different things, but there's certainly a proper way of setting both locales at the same time, could somebody help? I'm sure I'm missing something.

Thanks in advance, and congrats for the wonderful work.

Avatar
Ingo

Forum Moderator, 801 Posts

26 May 2009 at 9:04am

@Juanitou:
> Nevertheless I have a problem creating translations for pages created before upgrading: the original page is not being recorded in SiteTree_translationgroups, only the translated page which, by the way, appears in the CMS without the nifty original content in side-by-side grey boxes, ready to be translated.

Is that still the case in RC1? We had trouble with default pages created through the first dev/build not receiving a translation group. Do you have more information about your translatable config, if you're upgrading from a pre 2.3.2 datamodel, and wether the faulty page is a default page created by the first dev/build?

> Nevertheless, if we don't append ?locale=$code to the link and use $_GET['locale'] in Page_controller init(), the i18n locale does not change and, for example, modules do not get translated or date format do not localize:

Thats optional behaviour, you still might want to format stuff in a specific locale different from your current page settings. Its fairly easy to set in your page init():
http://doc.silverstripe.com/doku.php?id=multilingualcontent#setting_the_i18n_locale

Avatar
Juanitou

Community Member, 323 Posts

29 May 2009 at 2:28am

Thanks for the i18n suggestion. Also, I've resolved the problem with translation groups, as reported in the bug ticket.

Now, I have a lot to translate! :)

Best regards,
Juan

Go to Top