-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update linkfield developer doc regarding fluent #237
Comments
The docs for this should really just link to fluent docs - if even that. Really i don't think we need anything more than " |
I could live with a simple "Fluent compatibility" section that make clear what works and doesn't work with Fluent. |
@emteknetnz identified a potential Gridield issue during refinement that would block this card. He will create a matching card for it. |
These AC's just don't seem good. This really does not belong in the 5.2.0 change log IMO. I have this currently ([!Note] section is new): ...
Once the above have all been resolved, you can use that documentation and copy the relevant `BuildTask` code into your projects if you need it. These will be included in `silverstripe/linkfield` directly in the next minor release.
> [!NOTE]
> When using the optional [fluent module](https://github.com/tractorcow-farm/silverstripe-fluent) you can only translate `has_one` single `Link` relations and not the `has_many` multi-relations.
> If using content blocks you can make a `has_many` relation translatable without the `Link` relation itself being translatable. (Each localised instance of the block will have a different `Link` DataObject)
> Read more about [configuring fluent](https://github.com/tractorcow-farm/silverstripe-fluent/blob/7/docs/en/configuration.md).
Check out [the linkfield documentation](/optional_features/linkfield/) for more information about this module.
... It seems wildly out of place in the rest of the linkfield section of the changelog having specific information about fluent while we do not mention any other optional modules Also I have no idea what the AC "Make a custom content block with an has_many Link relation translatable with Fluent without the Link relation itself being translatable. (Each localised instance of the block will have different Link DataObject)" even means. It sounds like a very specific fluent customisation to try and work around the lack of has_many support, but at the same time we're mentioning one line that has_many is not supported just one line above. I think we should modify the AC's in two ways:
I'm going to move this back to refinement for discussion. |
Back in refinement as per #273 (comment)
TL;DR there are some UX issues with fluent when archiving links for both |
I would like to see if the issue is fixable before we document it as something that needs to be worked around. |
Validation for this is going to be done in #285 |
Context
We've reviewed the high level compatibility of Fluent with LinkField.
We've identified some upstream problems that make it difficult to fully accommodate Fluent with LinkField. Althought the simpler use case seemed to work pretty well.
User story
As a Fluent developer, I want clear guidance on how to get simple LinkField usage to work with Fluent so I can build interfaces that meet needs of my content authors.
Acceptance criteria
has_many
relations is called outRelated card
PRs
The text was updated successfully, but these errors were encountered: