-
-
Notifications
You must be signed in to change notification settings - Fork 536
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
[5.x] Ability to select entries from other sites #9229
[5.x] Ability to select entries from other sites #9229
Conversation
# Conflicts: # resources/js/components/fieldtypes/relationship/RelationshipFieldtype.vue
Alrighty. Thanks for this PR. We've made a handful of changes! 1. Made this opt in You have to enable a setting in order to be able to see the site filter now. We believe being able to pick only from the current site as it is now is a good default behavior and we don't want to change that on unsuspecting users. 2. Opting into it disables the localization behavior during augmentation. Maybe you weren't aware of this as you were making this PR, but localization happens automatically on the front-end. So, opting into this new option will disable that behavior. By opting into cross-site selections, whatever you pick is now what you get on the front-end. We figure that if you're explicitly choosing to pick entries across sites, you want more control. If you want a different set of selections on other localizations, you can mark the field as localizable and just pick a different set. 3. Removed most of the JS where you set the site filter The PHP was handling this. I'm not sure exactly why you had all that in there, but it seems to work fine without it. 4. Applied all of these changes to the select/typeahead modes. The site names will show in the dropdown options so you can tell the difference. Handy if you happen to have similarly named entries in different sites. |
Thanks, Jason! This sounds great!
If I recall correctly, the JS was related to the global (or entry sidebar) site picker, so that the site filter will have the correct site applied. |
Ah, beautiful. You're right, it doesn't do that anymore. Thanks! I'll sort that out. |
I need to resolve the initial site being filtered based on the site of the entry you're editing.
Any chance to get this merged soon? Got a project that is going live this month that depends on this. I can use composer patch in the meantime. |
It looks like commit a654e32 disabled the option for cross-site selection of entries in a navigation, because you made the cross-site selection opt-in. So we now probably need to add a configuration option to the navigation configuration to enable cross-site selection there as well. I'm not entirely sure, but I have a feeling that this might conflict with your earlier comment: 2. Opting into it disables the localization behavior during augmentation.. You said "By opting into cross-site selections, whatever you pick is now what you get on the front-end." This sound like a good idea for a regular entries fieldtype. But in a navigation context, it might be better to always link to the localized version of an entry if it exists. Imagine the tedious task to select the correct localized entry for all navigation localizations in a massive navigation tree. Before After |
Bumping (for myself) |
# Conflicts: # resources/js/components/inputs/relationship/SelectField.vue # src/Fieldtypes/Entries.php
This also sorta conflicts with #9749 in that this PR adds a site label to the select field options, where that one adds collection names. Gotta consider how both situations can be handled. |
Sorry for the delay.
In the current 5.x branch, in navs, you can only pick entries from the respective site.
I agree, but this PR isn't changing the behavior. At the moment you still have to define an entire nav for each site. Please correct me if you believe I'm wrong. |
Can we make it so that you can pick entries from a different site? This was possible earlier in this PR. I've got a live project that depends on this. Currently, I am working around the limitations of the UI by manually adding the entry's IDs to the navigation's yaml.
You are right, all good. If we make it possible to select entries from different sites in the navigation, what you said earlier makes total sense: "By opting into cross-site selections, whatever you pick is now what you get on the front-end." |
Yup I don't see why we can't add another opt-in on the nav for that. 👍 |
# Conflicts: # resources/js/components/inputs/relationship/SelectField.vue # src/Fieldtypes/Entries.php # src/Fieldtypes/Relationship.php # src/Http/Resources/CP/Entries/EntriesFieldtypeEntries.php # src/Http/Resources/CP/Entries/EntriesFieldtypeEntry.php
# Conflicts: # resources/js/components/navigation/View.vue # resources/js/components/structures/PageSelector.vue
Edit by Jason:
There are a bunch of changes to this PR, see my comment below.
This PR adds the ability to select entries from a different site in the stack selector of the entries fieldtype while also making some general improvements to the site filter.
The reason why
I'm aware that it was previously possible to select entries from different sites in the entries fieldtype. This feature has since been removed because it was confusing for users to be able to select entries from a different site. But this was before the site filter was a thing. So I believe it's time to resurrect this feature. Let's have the cake and eat it too.
See this issue for why this feature is important: statamic/ideas#646
What's new
What's improved
To be considered
Currently, cross-site linking is only possible in the stack selector. The dropdown and typeahead mode still only show entries of the current site as to not confuse the users. However, we might want to add a new feature toggle to allow cross-site linking if desired, e.g.,
Allow cross-site linking
. We could then add the site in brackets behind the entry name in the dropdown, e.g.,Home (Default Site)
.Closes statamic/ideas#646