SonataPageBundle
SonataPageBundle copied to clipboard
Add support for i18n routing
Feature Request
I have dynamic pages and I have defined them like this: https://symfony.com/doc/current/routing.html#localized-routes-i18n and I use https://docs.sonata-project.org/projects/SonataPageBundle/en/3.x/reference/multisite/#host-by-locale-strategy
when I run the update-core-routes command those dynamic pages are updated to all of my sites so I end up with many duplicate pages as one site should be used only in one locale.
Other thing that localized routes breaks is the current dynamic page retrieval from the CmsManagerSelector.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is clearly a bug should not be closed
This one does not seem easily solvable TBH.
When a route is i18n, internally symfony generates N routes, one for each locale. And the routeCollection exposes all of them, the update-route-routes command picks them all and tries to generate one page for each one. Up to this point we can discuss if we want that behavior or not, but it "works".
(There is a problem with the update-core-routes that does not take into account if the site have the locale used by that route)
And then on the render side, when you visit a route with i18n, it does not work at all, you have a routeName: something_something
, but the page has: something_something.es
and it does not find it, because the request think there is only one route.
And even if we fix those 2 problems, I don't know if we really should be generating one page per language, I guess yes? because here we don't have any i18n concepts.
wdyt @VincentLanglet ?
I think all is said.
It's not a bug, it's a very complicated feature request to implement. So if nobody wants to work on it we can close this as "not planned".
In my case the only real problem this raises is that I cannot give the user of the page admin easy way to change the page SEO attributes as the page cannot be found in the front controller even if I run the update core routes and manually delete the wrong language ones from the site. Of course block addition would be nice to have too.
Other way to solve this could be that as we define route without i18n we could somehow decide in which site the route belongs?
extra parameter perhaps? sonata_page_site_id=1
?
This would be useful as I have also project that has 2 sites with different domains and one admin to control them and now I have to delete the routes manually from the other one after update-core-routes.
I changed the subject to be more descriptive
Should I do another issue about the dynamic page assignment to a site?
Dynamic pages are just normal pages, they have a $site assigned to them, I don't think there is something wrong with that. Just try dynamic pages without i18n, if you see any issue, yes, open an issue. (What we won't do is patching something that is not implemented AKA i18n routing).
Dynamic pages are just normal pages, they have a $site assigned to them, I don't think there is something wrong with that. Just try dynamic pages without i18n, if you see any issue, yes, open an issue. (What we won't do is patching something that is not implemented AKA i18n routing).
Done here: https://github.com/sonata-project/SonataPageBundle/issues/1610