search

tractorcow-farm / silverstripe-fluent

Multi-language translate module for Silverstripe, without having to manage separate site trees.
BSD 3-Clause "New" or "Revised" License
91 stars 109 forks source link

Translated Teaser-Object can't access it's has_one "TargetPage" [okay: it's FilteredLocale behavior] #690

Open RoyalPulp opened 3 years ago

RoyalPulp commented 3 years ago

Hello again!! :)

The next 3 lines are the same as in my last issue, just to give short overview of the project :

I have a Website project for a client in Austria with 4 Locales - 3 of them are german based (de_DE, de_AT, de_CH ... and english)

the current Live Version runs on SilverStripe 3.7 with fluent (3.8.2)
I have a Dev-Server with the Upgraded project (SilverStripe 4.7) and Fluent 5.0

There a objects like "Teaser" that have some simple $db Attributes like Title, SortOrder ... and $has_one Ralations to eg. an Image and a TargetPage

After the Upgrade (...and solving lots of other problems ;) ) I discovered, that all Teasers didn't link to the desired TargetPage or get any properties of that Page. $this->TargetPage() in PHP gets empty, while $this->TargetPageID has the correct value.

Same with other Objects like "MenuItem", the $TargetPage()-> Link() or ->Title don't get resolved...

Any idea, where that problem can originate?

Thanks (again and again :) Hendrik

RoyalPulp commented 3 years ago

Addition: I don't get any clue from the database, everything seems fine there .

...okayokay .. I think I got it:

(Again) it is the "FluentFilteredExtension" (applied to SiteTree) Every Page is DISABLED per Default !! That is really really awful/irritating behavior! I need to check 4 checkboxes per page (there are hundreds of pages in this project...) or let my client write a database script...

Quastion: How do I enable each page per default and only apply filter "DONT SHOW" by choice??

tractorcow commented 3 years ago

We should update FluentFilteredExtensions to automatically bootstrap that record in each locale for the initial write. It'll be a core module change though; Unless you want to write an onAfterWrite() in your own model for the time being.