View more context

 

wmk

afaik yes. Have a look at FluentState and Fluent::withState(). There might already be a Fluent hook for duplicate

Conan

@kinglozzer (https://github.com/tractorcow-farm/silverstripe-fluent/issues/579) Fluent does not currently copy translations for a translated data object, I have actually been thinking about opening a PR for this.

  1. FluentState::singleton()->withState(function (FluentState $tempState) use (
  2. $currentDataObject
  3. ) {
  4. $locales = Locale::getLocales();
  5. foreach ($locales as $locale) {
  6. $tempState->setLocale($locale->Locale);
  7.  
  8. // Fetch the data object with a different locale.
  9. $currentTranslatedDataObject = DataObject::get_by_id($currentDataObject->ID);
  10.  
  11. if ($currentTranslatedDataObject->isInDB()) {
  12. // Copy fields.
  13. // Then ->write()..
  14. }
  15. }
  16. });

You can use something like that to duplicate/copy translated fields.

Show 1 attachment(s)
conny-nyman

Currently if you right click a page in the CMS (tree view) and select Duplicate this page only, fluent does not copy the translations for the duplicated page, when you switch locale on the duplicated page it says the page does not exist in this locale yet, and you get the Copy and save, Copy and publish actions.

Is this a bug or a missing feature?

Hide attachment content
wmk

well, a PR for onBeforeDuplicate() would be great! Maybe switchable with a config variable in case you really don't need it. But when you duplicate a DO I suppose to get all content (and if configured all relations) duplicated. Normal text is also duplicated.

Conan

Yes it is a well needed feature, I might have time to look at it during the weekend. 🙂

blueskies

Has anyone had issues with new SiteConfig records being added? I'm suspecting Fluent is doing something odd.... I have a situation now where I have an Extended SiteConfig (with some translatable text-fields) and there are now suddenly 3 SiteConfig records in the database.... When I go to /settings in the CMS it's displaying the content for SiteConfig record #1 but the the website is using the SiteConfig record #3 (the newest one added)....

blueskies

Hmmm... this is very odd, because I haven't yet found out what triggers it (so I can't really raise an issue in github about it 😞 ). But it's good to hear I'm not crazy and seeing things 🤪 I've seen it once happen on the live server... suddenly there were some SiteConfig things missing from /admin/settings and when we dug into the db, we saw there were multiple SiteConfigs (and one quite "fresh" one with some blank fields). This happened after we upgraded to 4.4.4 to fix the bug listed in https://github.com/tractorcow-farm/silverstripe-fluent/issues/570. So we assumed it was possibly left over from that nasty bug.

But then yesterday, in my local dev, I was adding some more fields to the Extended SiteConfig, I dev/build, and I filled them in. Then I couldn't decided on the variable names, so I changed them a few times, dev/build a few times, and suddenly there were 3 SiteConfig entries in my local db. So I'm not entirely sure what triggers it or what is happening.... Have you narrowed down when the extra Siteconfig records are created?

Show 1 attachment(s)
baukezwaan

We are experiencing an issue with the handling of deletes in the latest version(s) of Fluent. When the latest record of for instance a Page is deleted, the deteleBaseRecord is being called.
This function deletes the record from several tables, and does this based on ID. This goes wrong for the _Localised table. There the selection should be on RecordID instead.

How to reproduce:

• fresh install of SS4 + Fluent ^4 (tested on 4.4.1 and 4.4.3) • create some Locales • add some pages, and save them in multiple languages (to make the ID higher than the RecordID in the version table) • Now; add a new page via the CMS • Remember the ID (for instance id=16) • Check which record is in SiteTree_Localised on ID=16 • Delete the page via the CMS • See record ID=16 is gone in SiteTree_Localised (instead of RecordID=16)

The snippet below fixes the issue, but probably not in the most elegant way... :face_with_head_bandage:

    protected function deleteBaseRecord(DataObject $record)
    {

        //... (collapsed)

        foreach ($queriedTables as $table) {

            if (strpos(strtolower($table), '_localised') > 0 ) {
                $delete = SQLDelete::create("\"{$table}\"", array('"RecordID"' => $record->ID));
            } else {
                $delete = SQLDelete::create("\"{$table}\"", array('"ID"' => $record->ID));
            }
Hide attachment content