I'm having trouble getting Fluent to play nice with Elemental. My Config look like this

Widget:
  extensions:
    - 'FluentExtension'
    - 'FluentFilteredExtension'

However on and SubClasses of BaseElement only Title shows correctly in the CMS. The translated Values write correctly to the database, but the CMS show the value for the default locale.

I tried extending FluentExtension and applying it to both my Subclassed Elements as well as Widget with no effect.

If a user changes the field value of a "translation" to be empty, the default value gets copied over.

Example: Fluent is configured with 3 Languages, DE, FR, IT, where DE is the default. User edits a Page and fills in content for all 3 languages (say in the "Title" and "Content" field).

Now if the user wanted to remove the content in any of these languages (eg. selecting "Italian" and then deleting all the content inside the "Content" field), the content will then be reset to another language.

I know that this is probably due to a fallback mechanism in case a field isn't translated, but it makes for a very weird experience for CMS users (if they want the field value to be empty, they have to enter whitespace).

I guess this is a tricky problem to solve. Maybe a configuration-option to disable the fallback could be introduced? Maybe even on a "per field" level?

This RFC covers a new major version of Fluent with an updated data model, designed to address some of the weaknesses of the original fluent ORM.

Support

In order to reduce maintenance burden, this new version will be specific to framework 4.x, and will not be back-ported to framework 3.x.

History

This major version update should address the following issues:

• https://github.com/tractorcow/silverstripe-fluent/issues/257
• https://github.com/tractorcow/silverstripe-fluent/issues/145
• https://github.com/tractorcow/silverstripe-fluent/issues/156 (in a better way)

ORM

The new ORM for fluent will move from column based localisation to table based localisations. In keeping with the initial principles of the original ORM, fluent can be safely added to any existing site, and likewise can be safely removed without any migration needed, as these extra tables will only contain extra information, and the base tables will contain all information for the default locale.

E.g. tables for SiteTree will look like the below. In this example SiteTree.translated config will be Title, Content

SiteTree / SiteTree_Live Unique index: ID

• ID
• ClassName
• Title
• Content
• NonLocalisedField

SiteTree_Versions Unique index: RecordID, Version

• ID
• RecordID
• Version
• ClassName
• Title
• Content
• NonLocalisedField

SiteTree_Localised / SiteTree_Localised_Live Unique index: RecordID, Locale

• ID
• RecordID
• Locale
• ClassName
• Title
• Content

SiteTree_Localised_Versions Unique index: RecordID, Locale, Version

• ID
• RecordID
• Version
• Locale
• ClassName
• Title
• Content

Note that for SiteTree_Localised and SiteTree_Live the ID is not the record ID, but rather a unique index that's ignorable by the application. All joins will be on SiteTree.ID = SiteTree_Localised.RecordID AND SiteTree_Localised.Locale = 'the_locale'.

A second major change for this version will be the behaviour of coalescing of localisations over default locale. Instead of defaulting on a per-column basis, the join will switch on the joined SiteTree_Localised.ID column. If a row exists in the SiteTree_Localised on any given join then all localised fields will be selected from that table, even if null.

We may provide the option to default on a per-field or a per-row basis (e.g. check SiteTree_Localised.RecordID IS NULL on the join vs SiteTree_Localised.Title IS NULL).

Default values

Defaults can be configurable on a per-locale basis; E.g. if DE defaults to NL, we would join twice on SiteTree, SiteTree_Localised on Locale = DE and SiteTree_Localised on Locale = NL.

It will be possible to have locales which don't fail over to the main default locale. E.g. CN locale perhaps should not default to a western locale.

Instead, the query builder will have an injectable FluentDefaultProvider service, which given a class, field, and locale, will return the default value the query should return.

E.g.

class i18nDefaultProvider implements FluentDefaultProvider
{
	public function provideDefault($class, $field, $locale) {
		$default = i18n::get_locale();
		try {
			i18n::set_locale($locale);
			return _t($class.'.'.$field.'_DEFAULT', '');
		} finally {
			i18n::set_locale($default);
		}
	}
}

Locale management

UI components will remain much the same as in fluent 3.x, but with the move away from per-column localisation, we may include a "locale" config admin which will allow locales to be created via a gridfield. Locales will no longer be set via config.

Versioning

Initial implementation may not include support for historic versioning of localisations. (i.e. the SiteTree_Localised_Versions table), but if not this will be built at a later date.

Fluent will implement the VersionableExtension interface to work with versioned.

Existing features to port across

These features will be ported without much change:

• Routing
• Templates
• SEO / sitemap.xml
• frontend (css / js)

Other architecture

This new version of fluent will move from static class to a fully injectable service to allow for better dependency injection.

Tasks

• [ ] ORM
  • [x] Implement table building
  • [x] Migrate augmentSQL()
  • [x] Localise WHERE fragment
  • [x] Migrate FluentFilteredExtension
  • [x] Migrate FluentMenuExtension (if applicable)
  • [x] Ensure DataQuery params are set properly
  • [x] Migrate augmentWrite()
  • [x] Default fallback / nullability behaviour
    • [x] Implement per-locale/row default behaviour
    • [x] Implement default fallback behaviour service
    • [x] Implement cascading locale default (configurable via CMS)
  • [x] Versioning support
    • [x] Versioned tables are built
    • [x] _Localised_Versioned records are populated when a version is built
    • [x] All versioned reading models (archived, version, stage, etc) all work with localisation
    • [ ] Restore to an earlier version restores the correct version of localisations
  • [ ] Permissions
    • [ ] Allow locale-specific group permissions (similar to translatable)
• [ ] CMS
  • [x] Fluent ModelAdmin for domains / locales
  • [x] Update fluent locale selector dropdown
  • [ ] Add "publish all locales" CMS action
  • [x] Add "Publish just this locale" CMS action
  • [x] Add fluent icon to localised fields
• [x] Routing
  • [x] Convert FluentRequestFilter to HTTPMiddleware
  • [x] Migrate Fluent::is_frontend()
  • [x] Update Director.rules with fluent routes
  • [x] Implement prefix-omitted option for default locale
  • [x] Migrate Fluent.domains feature
  • [x] Migrate Fluent::detect_browser_locale to pluggable home redirect service
  • [x] Migrate FluentRootURLController
• [ ] SEO
  • [x] Migrate GoogleSiteMap integration
  • [ ] Migrate meta tags
• [x] Support full text search of localised content
• [x] Templates / Helpers
• [x] Unit tests
• [x] Documentation

I had a problem with setting domain per locale, since we had a couple of websites running different languages, one per domain.

The fix was hardcoded, didn't have the time to look where the functions are called for a pull request.

Fluent.php

public static function default_locale($domain = null) {

with

public static function default_locale($domain = true) {

AND

public static function locales($domain = null) {

with

public static function locales($domain = true) {

Maybe if I have time I will make a pull request.

@tractorcow This issue relates to #132 with related bug(s). I have not verified if the following were introduced recently or existed prior to #132 being fixed:

Env

• Fluent: dev-master as 3.2.2 with aliases enabled in YML for all locales and FluentExtension + FluentFilteredExtension enabled for SiteTree
• Newly updated, raw SS 3.1.12 (No project-code whatsoever)
• PHP 5.5 / Ubuntu 14.04
• Chrome 44 (CMS) Firefox 39 (Frontend)

Bug reproduction

• [OK] Login to the CMS
• [OK] Select "English (New Zealand)" from LHS locale menu
• [OK] Create new top-level "Page"
• [OK] Enter a title in English; e.g. "TEST 01"
• [OK] Press "Save & Publish"
• [OK] Observe "Page name" field reads "TEST 01" and "Navigation label" reads" "TEST 01"
• [OK] Navigate to /en/test in the frontend, observe Menu title reads "TEST 01" and page-heading reads "TEST 01"
• [OK] Select "Arabic (Egypt)" from LHS locale menu
• [FAIL] Observe "Page name" suddenly displays "New Page" (Could be session related as this seems inconsistent..)
• [OK] Enter a "Page name" in Arabic; e.g. "TEST 01 Arabic"
• [FAIL] Focusing off the "Page name" field does not auto-change the "Navigation label" field as it would normally do (No JS errors observed) - this could be related to the above as it also seems inconsistent)
• [OK] Press "Save & Publish"
• [FAIL] Observe "Page name" field reads "TEST 01" (Expected "TEST 01 Arabic")
• [FAIL] Navigate to /en/test in the frontend, observe Menu title reads "TEST 01 Arabic" and page-heading reads "TEST 01" (Expected both to read "TEST 01")
• [FAIL] Navigate to /ar/test in the frontend, observe Menu title reads "TEST 01 Arabic" and Page-heading reads "TEST 01" (Expected both to read "TEST 01 Arabic")

Relating to #132 I see similar behaviour for pre-existing pages:

• [OK] Login to the CMS
• [OK] Select "English (New Zealand)" from LHS locale menu
• [OK] Open an existing default page e.g "About us" (ID #2)
• [OK] Select "Arabic (Egypt)" from LHS locale menu
• [OK] Enter a new "Page name" in Arabic; e.g. "About us in Arabic"
• [OK] Press "Save & Publish"
• [FAIL] Observe the "Page name" fiel din thre CMS reads "About us" but the "Nvaigatioin field" reads "About us in Arabic"
• [FAIL] Navigate to /en/about-us in the frontend, observe Menu title reads "About us in Arabic" and page-heading reads "About us" (Expected both to read "About us")
• [FAIL] Navigate to /ar/about-us in the frontend, observe Menu title reads "About us in Arabic" and page-heading reads "About us" (Expected both to read "About us in Arabic")

Localised versioned history

This is intended to go into 5.1 as these changes are high impact and possibly need more improvements to cover the intended scope.

Details

• archive flag respects localised state - either it's archived in current locale or other locale
• restore action is only shown if there is archived content available in current locale
• archive view is only available for objects which have something in the localised archive
• Versioned history versions list localised - each locale shows only versions for the current locale
• Version history preview localised - viewing past versions in the history viewer shows correct data

Archive behaviour

• archive view is available only for objects which have some archived content in the current locale
• user is expected to switch to the locale where the content was archived to do the restore action

Dependencies

Merged

https://github.com/silverstripe/silverstripe-versioned/pull/287 https://github.com/silverstripe/silverstripe-versioned/pull/297

Released

Waiting for the silverstripe/framework 4.7

Test setup

Locale

• NZ - global default
• US - fallbacks on NZ
• JP - no fallback

Basic test setup

• create a new page in NZ
• copy to US locale
• copy to JP locale
• edit page in US and assign US Title
• edit page in JP and assign JP Title

History view test

• Basic test setup steps
• view history in each locale and each version and check that the versions sets are distinct for each locale
• version preview works as intended (shows data only form current locale)

Archive view test

• Basic test setup steps
• archive page in US
• archive page in JP
• switch back to US and restore to draft, you should get back the US version
• switch back to JP and restore to draft, you should get back the JP version

Discussion points

Versioned methods

Versioned methods are now fully localised. For example isPublished() will look at localised record, not base record. This has a big impact on the CMS UI as lot of UI is built based on the versioned state.

Archive view

CMS is able to show a page even though there is no content for the page - it will show the data from base record. If we localise version lookups this approach doesn't work for the archive view. If there wasn't any content for the page in specific locale the archive view will show page as not found. This might be consistent from technical point of view but it may be user unfriendly. It would be much better to show a read only page from other locale and show a label saying that this may has been archived in some other locale.

This example shows that consistency might need to be overridden with user friendly-ness ins some cases.

Conclusion

Maybe we need to review this feature from the requirements point of view and check if we can achieve it technically.

The biggest decision is this one:

isPublished() localised lookup vs isPublished() base record & isPublishedInLocale() for localised record

Am I right in thinking that for DataObjects in ModelAdmin the falling back to the default language is not there?

I.e if you manage a dataobject through a gridfield on pages, you'll see fields falling back to the default values (as described here https://github.com/tractorcow/silverstripe-fluent/blob/3.1/docs/en/how-fluent-works.md in 'Creating translations'). But for dataobjects on ModelAdmin, this is not the case and you get blank fields?

At least that's the behaviour I'm seeing. Just a question really more than an issue :)

Locales

• International -Default -No fallback
• United States -Fallback International
• Australia -Fallback International
• Japan -No fallback

Process

Created a new Page in International

Localised Page in Australia with new metadata

Localised Page in United States with new metadata

Localised Page in Japan with new metadata

Result

Each Locale that you view the "History" tab in will show all versions for all Locales.

Each "History" tab will also have the most recent version selected - even if that versioned belongs to another Locale.

(Japan pictured below, but it's the same result in the other 3 Locales)

Pull requests

• [x] https://github.com/silverstripe/silverstripe-graphql/pull/185
• [x] https://github.com/silverstripe/silverstripe-versioned/pull/182
• [x] https://github.com/tractorcow-farm/silverstripe-fluent/pull/472
• [x] https://github.com/silverstripe/silverstripe-framework/pull/8406

Localisation manager UI improvements / configuration improvements

These changed can be split into separate pull requests and processed individually.

Configuration changes

New configuration options were added.

Batch actions configuration

• Fluent menu batch actions are potentially quite destructive and may not be needed in some projects
• added an option to disable this menu (menu is enabled by default)
• following actions are not shown if the menu is disabled batch unlocalise, batch localise, batch unpublish, batch publish, batch archive

Copy to / from locale configuration

• copy content from one locale to another can be achieved by either action and this may be confusing for the content authors (simplicity over flexibility)
• this new configuration allows the developer to choose which actions are desired
• both actions are enabled by default (previous behaviour)

Terminology

These change are related to how we name things.

• isLive - refers to an object being available on the frontend
• IsPublished refers to an object which has a a localised record in its live table

Features

New features were added.

Localisation state

• current UI is a little bit confusing as it's mixing multiple concepts together
• concern 1 - where data is available and in which state, this information is mostly useful for operating copy to / from actions
• concern 2 - what is displayed on the frontend
• new UI separates these concerns
• Draft column renamed to Status
• Published column renamed to Live
• Source column added to reflect where the content is coming from (which locale)

Non-versioned UI

• Status column shows either Localised or Not localised
• Source show the locale which is the source of the content

Versioned UI

• Status column shows either Draft, Published, Modified or Not localised
• Source show the locale which is the source of the content
• Live column shows either Yes or No

Detect modified state

• added stagesDifferInLocale which is a Fluent friendly version of stagesDiffer

Badges UI

• badges now only reflect localisation state which makes the UI less confusing (separation of concerns - don't mix versioned state and localisation state)
• any terminology which is related to Versioned state has been removed as the information is represented elsewhere
• new badge states are: localised (has localised record), inherited (inherits from another locale) and unknown (no localised record and no inheritance)
• messages updated accordingly

copy to draft, copy & publish action configuration

• added an option to enable / disable localise actions (copy to draft, copy & publish), enabled by default
• these actions may not be needed as the same result can be achieved by using localisation manager

Global template helper for current locale

• current locale object helper method added
• this is useful for situation where locale object is needed in the template for cases like outputting current locale Title or other data

Publish state fix for multiple actions / areas

• Following actions now reflect the published state based on localised record instead of base record (publish action, information panel, unpublish action, archive action)

Non-versioned UI improvements

Pushed up Non-versioned UI improvements:

• save action is changed to Localise in case the record is not localised in current locale (edits only)

• delete action is changed to Unlocalise in case he record is localised and i's not the last locale

Related issues

https://github.com/tractorcow-farm/silverstripe-fluent/issues/621

Hi, I've got a weird problem with Siteconfig.

SiteConfig has extension CustomSiteConfig SiteConfig has fluent extension (see config below)

Somehow:

• multiple SiteConfig-Rows are created in DB
• for the multiple SiteConfig-Rows localised are created
• the right translations are not found

See Example below.

In the Backend I see the translations (SiteConfig ID 1 gets translated, see below). But no translation is shown in Frontend or accessible via PHP*. Seems like the CMS thinks the fields are NULL (see below)

* e.g.
$SiteConfig = SiteConfig::current_site_config();
var_dump($SiteConfig->MailTo);

mysite.yml

---
Name: myproject
---
...
SilverStripe\SiteConfig\SiteConfig:
  extensions:
    - App\Extension\CustomSiteConfig

fluentconfig.yml

---
Name: myfluentconfig
After:
  - '#versionedfiles'
  - '#myproject'
---
...
...
SilverStripe\SiteConfig\SiteConfig:
  extensions:
    - 'TractorCow\Fluent\Extension\FluentExtension'
  translate:
    - 'Title'
    - 'Tagline'
    - 'MailSubject'
    - 'MailThankYouMessage'
    - 'ContactMapInfoWindowTitle'
    - 'ContactMapInfoWindowAddress'
...
...

Table SiteConfig

|ID|...|MailThankYouMessage|MailTo (untranslated)|Title| |---|---|---|---|---| |1|..|Thank you for your request!|[email protected]|domain.com| |2|...|NULL|NULL|Your Site Name| |3|...|NULL|NULL|Deine Webseite|

The "NULL-Fields" are not shown in CMS, all fields seem to have been filled out. The following returns NULL in it_IT and de_DE though "[email protected]" is shown in Backend in all Languages:

$SiteConfig = SiteConfig::current_site_config();
var_dump($SiteConfig->MailTo);

Table SiteConfig_Localised

|ID|RecordID|Locale|...|MailThankYouMessage|Title| |---|---|---|---|---|---| |1|1|en_US|...|Thank you for your request!|domain.com| |2|2|it_IT|...|NULL|Your Site Name| |3|1|it_IT|...|Grazie per la vostra richiesta!|domain.com| |4|3|de_DE|...|NULL|Deine Webseite| |5|1|de_DE|...|Vielen Dank für Ihre Anfrage|domain.com|

Values from ID 2 and 4 are shown in Frontend. Values from ID 3 and 5 shown in Backend. So the shown/displayed values can not be edited. And the values that I can edit are not used/shown in Frontend/PHP.

Edit: If I use class CustomSiteConfig extends FluentExtension I get this Error: [Emergency] Uncaught SilverStripe\ORM\Connect\DatabaseException: Couldn't run query: ALTER TABLE "SiteConfig_Localised" DROP INDEX "Fluent_Record", ADD unique "Fluent_Record" ("RecordID","Locale","RecordID","Locale") 42S21-1060: Duplicate column name 'RecordID'

Just installed fluent on a clean SS 3.4.1 install. These are the only alterations I made:

• Removed i18n::set_locale('en_US'); from _config.php
• Installed latest Fluent: 8e839bf
• Placed the fluent.yml in mysite/config/
• Ran dev/build?flush

fluent.yml

---
Name: myfluentconfig
After: '#fluentconfig'

---
Fluent:
  default_locale: en_US
  locales:
    - en_US
    - pl_PL
    - de_DE
    - nl_NL
    - tr_TR
  aliases:
    en_US: en
    pl_PL: pl
    de_DE: de
    nl_NL: nl
    tr_TR: tr

---
Name: myfluenti18nconfig
After: '#fluenti18nconfig'

---
i18n:
  default_locale: en_US

In the back-end, every single locale mode works fine, except for the Turkish one tr_TR. Switching to the Turkish locale throws the following 500 error:

PHP Fatal error: Interface 'CurrentPageIdentifier' not found in /home/<..path to project>/cms/code/controllers/CMSMain.php on line 12

in 5 and 6 as soon as I create a Widget I get the following error [Emergency] Uncaught LogicException: Field must be associated with a form to call Link(). Please use $field->setForm($form); Line 377 in /srv/http/ss_thermotex4_web/vendor/silverstripe/framework/src/Forms/FormField.php

on 4.7.0 this does not happen.

We have added fluent to an existing site, without migrating pages to a default locale yet ... the presence of fluent does not seem to negatively affect site, except for one thing. The query below returns a huge amount of pages, seemingly ignoring the filter condition. If I pick a parentID other than 0, all is well again.

Once we migrated the existing pages to the default language the behavior reverted to returning only pages matching the filter.

I have not tried this on a fresh install, but we are using all the latest ss4, graphql4 and fluent 5 bits. Maybe this problem does ring a bell with someone who knows about fluent GraphQL interaction.

query { 
    readPages(
        sort: { sort: ASC }
        filter: { parentID: { eq: 0 }, showInMenus: { eq: true } }
    ) {
        nodes {
            title
            link
            showInMenus
            className
            parentID
        }
    }
}

Originally opened as Silverstripe/silverstripe-framework#10259 by @marimchen

Can you please add some kind of warning message or an red error-message in dev/build for classes which have a blank at the beginning of their name e.g " MyTable" or "My Table". It's hard to see in the database itself and it causes real bad behaviour for popular modules like silverstripe-fluent from tractorcow.

Thank you very much, kind regards

Per discussion in the original issue, spaces in table names are valid in SQL and so should be allowed by the fluent module (as opposed to presenting an error or warning as suggested above).

This is now being raised here because as per @marimchen:

It was overlooked because everything worked as it should, except of fluent, which couldn't handle fetching the translations correct because of that.

It sounds like table names just aren't being quoted correctly somewhere - hopefully @marimchen can provide more specifics about exactly how this was found and how the problem presented.

Plugin version: 4.4.5.

Hi There,

We want to partially add content for another language but keep the pages unpublished until we have completely finished and are ready to push it live.

I have a website that has English and Portuguese language version. English is the main language and we started to add content for Portuguese in some pages. Even-though those pages are unpublished and in draft mode, the URL https://mywebsite.com/pt/page is still accessible and google is indexing it. I was expecting that the website returns a 404 as the page is unpublished/draft in Portuguese.

Due this it doesn't seem possible to keep two languages having one of them unpublished/draft.

The solution for us was to remove completely all the Portuguese version for the pages, then if we access https://mywebsite.com/pt/page* it finally returns a 404 instead of loading the fallback english version.

I tried to go to global language settings and disable the fallback but it didn't work, second language pages that are unpublished/draft can still be accessed by URL and the content fallbacks to english.

Thanks,

I have a form that works for the default Locale but not the other Locales. When the form is submitted, on non default Locale the form doesn't submit to the form action. The form is called WagonCalculatorForm and the action is calculateWagon. On submission of the form I can get all the information in the WagonCalculatorForm method but the calculateWagon doesn't get hit at all when used on a non default Locale.

Any ideas why this would be, I'm at a bit of a loss. No errors in the log, the site is in dev mode.