Any chance on a 1.x release any time soon? Its been a while and several bug fixes landed in that time.
+1 on RTBC.
This fixes the bug.
This puts a hidden dependency on token.module. Or at least, my kernel tests (which didn't have token required previously) now require me to add token. Because otherwise,
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "token.entity_mapper".
To echo #6, ideally this MR would be just to enable gitlab and not all the code standard changes.
Here's the simple move. I manually tested the code after moving from devel to admin.
Fixes the issue.
This fixes our failing tests on the project related to config schema errors.
It should, but you'd have to test that to confirm.
heddn → created an issue.
Fixed up MR and merged #24 back into it. I've hid all the patches.
Can we get these changes back into the MR? Core doesn't really use a patch workflow any more.
Some feedback posted on MR. Also, is there a simple way to add to our test coverage?
Opened https://www.drupal.org/project/simple_search_form/issues/3436251 🐛 User error : InvalidArgumentException: The user-entered string 'your_path' must begin with a '/', '?', or '#'. Active as a follow-up.
heddn → created an issue.
Rolled the patch into an MR and added general module schema to it as well.
It was introduced w/ 2.0.0-rc5. RC4 is not impacted.
I'm not sure if it is a regression from this change, but even though I don't have Allow creating new items selected, all of my SHS widgets display an Add new term option.
Maintainership granted. If you wish to release a new tag, feel free to reach out and I'm happy to help with that.
NW because tests are failing (the first few failures look simple to fix) and phpc/phpstan complaints.
heddn → changed the visibility of the branch 2979223-search-string-summary-v2 to hidden.
It should also see a re-roll for 3.x though, so maybe NW is accurate?
This is marked as NW for 2 years. Why don't we get brave and ask for a review?
We are using default content to export menu items on a site. So I think this must be a feature that works.
To expand on #66, I've got a client who is looking at this project and their security posture is to use code/modules that have security support. Since this project is still a non-stable release, they feel a little uncomfortable to use it. From reviewing the must-haves, this looks really close to a stable release. It would be nice to see 📌 Get PHPStan level 1 passing and enable automated test job Active land (it is rtbc) and 📌 Drop PHP7 support to help with code cleanup Needs work as well (only NR, but easy to get to RTBC). That only leaves ✨ Allow select widget for "Add existing items" Needs work from what I can tell as blocking release. Am I reading that correctly?
I love the updated (and clearly stated) IS updates. Is there any specific timelines for the first 3.0.0 stable release?
NW because of test failures.
+1 on RTBC.
Nice work here. Thanks for the added tests.
Back to RTBC.
It works. Really well. LGTM.
Possibly if 📌 Additional source plugin filtering Needs review lands first, this could be closed duplicate and credit transferred over there.
Posted minor feedback on MR.
Traced this back to 🐛 When adding a new menu link, restrict the available parents to the current menu Fixed . It isn't in 10.1 but is in 10.2. GCM does not have a full config backed menu. It never will. Additionally, the menu parent logic is overwritten by that module after this here. The patch in #2 seems like a decent solution. An entity load can fail to load (that's what we see here). We should check and handle appropriately.
Still needs tests, but this can be easily reproduced. In a test controller add something like:
public function addLink(GroupContentMenuInterface $group_content_menu) {
$menu_name = 'non-existent';
$menu_link = $this->entityTypeManager()->getStorage('menu_link_content')->create([
'menu_name' => $menu_name,
'bundle' => 'menu_link_content',
]);
return $this->entityFormBuilder()->getForm($menu_link);
}
+1 on landing this.
This looks ready.
Is it just a change in format?
Posted feedback on MR.
Tests pass green on php 8.2 in the bot. I couldn't figure out an easy way to run a test-only pass on the code to demonstrate the error w/o any fixes..
third_party_settings:
sections:
third_party_settings:
lb_plus:
uuid: 3084b21e-317d-44b3-9d74-5e3d126bdc0c
This is what is being complained about.
heddn → created an issue.
Probably needs tests.
Line 22-24 is what is triggered. Solr has those values as null. But the validator thinks they should be an empty array.
if (!is_array($value)) {
throw new UnexpectedTypeException($value, 'array');
}
+++ b/config/schema/fullcalendar_view.views.schema.yml
@@ -81,9 +87,21 @@ views.style.fullcalendar_view_display:
+ type: integer
Since this is a checkbox, this should be:
type: boolean
I've merged this into a new https://www.drupal.org/project/group_domain/releases/3.0.x-dev → branch.
What version of config inspector? The most recent? None of my sites are still using 10.0/10.1 any more but when were still using it, we didn't have issues. It was only recently this started.
Automated testing in the CI where we essentially do protected $strictConfigSchema = TRUE does not trigger any exceptions. Running drush config:inspect --only-error and the web UI trigger the same exception logic.
I'm not sure how related or unrelated this is, but search_api_solr in 10.2 is throwing fits with the new config validation. 🐛 ValidKeysConstraintValidator thrown by config inspector Active has some details on what I'm seeing.
I think is comes from all of the nullable: true stuff all over the config schema in this module. There is a lot of it though, so I wonder if something in core should be handling this differently.
heddn → created an issue.
Not all custom code uses contrib entity module. The place that gets the greatest visibility is in core.
Yes, the CR update would be very helpful.
The error that comes from this module is attached:
On 10.2+, the additional validation for ck5 attributes and properties is getting in the way. I attempted to use extend_html_filter and the the MR from ✨ Match the filter_html <> ckeditor5 integration in Drupal core Needs work and still no joy.
This MR fixes modules that use _this_ module's API. For group.module fixes, see the related issue.
For group module, see 🐛 Drupal 10.1: Revisions tab appears twice on Groups Needs review
Let's get this merged.
This has test coverage added now. They were failing because they were actually written with the bug we are seeing present. There are 2 of the 19 different test cases in the data provider that included nested (below) items that are filtered out by the build process. But the twig variable was still indicating there were items.
A rebase should be all that is needed to fix the counts.
LGTM if it returns green.
I've run into this before w/ drush on some other un-related operations. It assumes everything is non final and tries to wrap objects in its own wrapper via reflection. In the past we had to check for if the object was final. I wonder if that is what is happening here. The obvious thing is to not make the class final. But its awful convenient for a simple class like we have here to make it final and not need to worry about BC.
I fixed one small issue with a doc block. But that was so small I doubt it blocks from re-RTBCing. LGTM.
change record looks good to me.
For me, this is RTBC again if the tests pass green.
I'm happy to rebase this if the other one goes in first.
Tests are green, now ready for review.
heddn → created an issue.
This is safe to land as dependency injection of the container should work even in earlier versions of Drupal.
heddn → created an issue.
Once support for 10.1 is sunset, this can land. Otherwise if we want to support both <=10.1 and 10.2+ at the same time, we'll have to do a BC dance.