Adding patch file.
laura.j.johnson@gmail.com → created an issue.
laura.j.johnson@gmail.com → created an issue.
laura.j.johnson@gmail.com → created an issue.
laura.j.johnson@gmail.com → made their first commit to this issue’s fork.
laura.j.johnson@gmail.com → created an issue.
I implemented it by creating an entity reference view that filters by group argument and then altering the link widget on the menu_link_content form to use that view for autocomplete. But yes it would be a helpful feature! +1
We decided not to add POTS to Sous as we may want other options.
laura.j.johnson@gmail.com → changed the visibility of the branch 10.1.x to active.
laura.j.johnson@gmail.com → changed the visibility of the branch 10.1.x to active.
If it fails validation after the recipe is applied, then what should happen?
I agree, I think the Distributions part is a bit misleading and confuses people.
Thanks Mike! Putting back into RBTC.
Can we put it back into RBTC or is there something else needed?
Great! Just tagging Josué for credit for his review/test.
I have verified this is not an issue in the current version. Marking as fixed.
This is available in the current version. Marking as fixed.
This exists in the current version, closing.
I believe this ticket is still valid for Sous with recipes but needs to be updated.
This evolved to two base recipes which are now available here:
https://github.com/fourkitchens/sous-emulsify
https://github.com/fourkitchens/sous-admin
Closing ticket.
This was for the previous release of Sous. It would be helpful to know if you run into the same issue now. The command is the same minus the --no-interaction.
composer create-project fourkitchens/sous-drupal-project [PROJECT-NAME]
Good point, maybe we can discuss in Same Page? I'll open an issue.
PR was merged, this was fixed.
I added a MR with an update to RecipeConfigInstaller to install config in collections if provided. It works, although I'm not sure if there should be more to it than that, ie does the config in collections also need the dependency manager.
I added an example_translation recipe and an automated test.
ltrain → created an issue.
In attempting to create a test for this I found that the RecipeConfigInstaller doesn't process translations, which is to say that if you put language files in config/language/[langcode], it ignores that config. I'll create a new issue for that and leave this one here for creating documentation once that's fixed.
For this we're testing enabling translations and adding config of different languages to the config folder and verifying that it imports it correctly, yes?
I am also running into this by installing the Minimal profile and then applying a recipe that enables gin + gin_toolbar + navigation and importing config '*' from the navigation module.
Yes I was going to say that it could take region as an argument...
This looks good to me, except that I find it a little odd that in some cases we label it in agreement with the method verb:
setRequired() label = 'Set whether field is required'
...but other times instead of 'set' it's 'change'
setSettings() label = 'Change field settings'
I think I would always go with 'Set' (or whatever the verb of the method is).
I'll test all of these in a recipe at contrib day tomorrow.
hestenet → credited ltrain → .
hestenet → credited ltrain → .
hestenet → credited ltrain → .
hestenet → credited ltrain → .
hestenet → credited ltrain → .
hestenet → credited ltrain → .
I opened a new issue here 🐛 Linkit Link field: Double-encoded file links Active for visibility.
ltrain → created an issue.
We are also encountering this issue with 6.1.3 using the Linkit widget with a core formatter, in this case the Separate link text and URL formatter. And it's also with file entities.
If core link formatters expect a decoded url then it seems ideal that the Linkit widget should take care of decoding the url. I'm not sure if there is a better way to accomplish that but here is a patch that adds an urldecode() step in MassageFormValues() in LinkWidget.
Steps to reproduce:
install Linkit 6.1.x-dev
Upload a file/media with a space in the name
Edit the basic page content type, add a link field with default settings but change the form display to use the linkit widget, change the display to use a non-linkit formatter like Separate link text and URL
Create a page using the basic page content type and link to the file/media with the link field.
On the edit page the link will appear like this: /sites/default/files/2023-03/name%20with%20space.pdf
When the page is saved and viewed the link will appear like this: /sites/default/files/2023-03/name%2520with%2520space.pdf
I have the same issue and tested this MR, it works well.
@thejimbirch I tried your suggestion and that doesn't work even to append it. It threw the exceptions you see in the action for mapping/definitions checks, but even if I comment those it doesn't seem like chaining them the way you describe works in this case. It would be cool if it did.
I also tried
simple_config_add:
third_party_settings.field_group.group_content.children: field_content
Thanks @wim-leers, This suggests that it will be more complicated... probably a separate config action if we want to keep this one 'simple'!
I opened a MR so I could try it out as a patch. I agree with @sonfd's thoughts on this, I wonder if with #1 and #2 the normal config save event will take care of sorting.
I also wonder about adding something to a particular subkey, eg.
core.entity_form_display.node.page.default:
simple_config_add:
third_party_settings:
field_group:
group_content:
children:
<strong>- field_content</strong>
- field_text
Is there a way we can specify that we want to add an item to the children here?
Right now I'm using simple_config_update to replace the entire third_party_settings for this config just to get that child in there.
I have tested this and confirm it works both for setComponent() and setComponents(), the settings and third party settings are applied properly.
This works:
core.entity_view_display.node.page.default:
setComponent:
name: field_content
options:
type: entity_reference_revisions_entity_view
label: hidden
settings:
view_mode: default
link: ''
third_party_settings: { }
weight: 10
region: content
This works with setComponents(): from here
core.entity_form_display.user.user.default:
setComponents:
-
name: field_last_password_reset
options:
type: datetime_default
weight: 4
region: content
settings: { }
third_party_settings: { }
-
name: field_password_expiration
options:
type: boolean_checkbox
weight: 3
region: content
settings:
display_label: true
third_party_settings: { }
This adds the field, but it strips out all of the settings and third party settings. I'm wondering if there's another function I can use to add those...
https://git.drupalcode.org/project/distributions_recipes/-/blob/11.x/cor...
Also, the machine name of the field has to be in quotations.
core.entity_view_display.node.page.default:
setComponent:
'field_content'
-
type: entity_reference_label
label: above
settings:
link: true
third_party_settings: { }
weight: 10
region: content
My bad! Pro tip: use spaces rather than tabs in yaml.
I'm trying to use this to add a field to existing form and view displays using the sample action here, but I get this error:
In YamlSymfony.php line 40:
Mapping values are not allowed in multi-line blocks
I notice that Drush GenerateCommands uses the Symfony Console component. Maybe it could be used here?
In my case there was a broken sort handler in the view. If you take a look at the view in the UI you may be able to see the problem.
My mistake, I had the previous version.
ltrain → created an issue.
I am using the 10.1 patch from #29 and it's working well. Thanks @robert-arias!
I'm having the same issue. You can reproduce it by adding a block type that references a paragraph that includes a sub-paragraph (multivalue).
I rerolled the patch.
For anyone looking to suppress this warning until the related issue lands, this is the patch that's working for me. Similar to the one posted except it needs the null coalescing operator:
$element[$name]['#weight'] = $options['weight'] ?? 0
ltrainjohnson → created an issue.
ltrainjohnson → created an issue.
@bluegeek9
Sorry for the confusion! I just didn't have the most recent version of 1.0.
@bluegeek9
Sorry for the confusion! I just didn't have the most recent version of 1.0.
So, make sure your authorization is updated and you should not see these warnings/errors.
Over at the authorization module, they have a patch for these errors but they have not created a new release.
See: https://www.drupal.org/project/authorization/issues/3327917 📌 Drupal 10 patch (rector) Fixed
You can get the updates by using the dev version:
composer require 'drupal/authorization:1.x-dev@dev'
+1 request for a new release. Some of us are trying to update authorization_group for D10 compatibility and are seeing the authorization errors:
https://www.drupal.org/project/authorization_group/issues/3386268 💬 Drupal 10 working version? Active
Thanks!
ltrainjohnson → made their first commit to this issue’s fork.
We have a PR here:
https://github.com/fourkitchens/sous-drupal-project/pull/106
It is not quite ready.
ltrainjohnson → created an issue.
laura.j.johnson@gmail.com → created an issue.
See the fork, we have the sous_base recipe.
This works for me using focal_point 2.0.
laura.j.johnson@gmail.com → created an issue.
ltrane → created an issue.