🇨🇦Canada @Liam Morland

It would be useful to give maintainers a way to mark issues outdated in their own modules.

Thanks everyone!

liam morland → made their first commit to this issue’s fork.

liam morland → made their first commit to this issue’s fork.

liam morland → made their first commit to this issue’s fork.

liam morland → made their first commit to this issue’s fork.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork of Bartik and merge request.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork of Bartik and merge request.

Please put the patch into an issue fork of Bartik and merge request.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork of Bartik and merge request.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork and merge request.

Please put the patch into an issue fork and merge request.

liam morland → made their first commit to this issue’s fork.

Please put the patch into an issue fork and merge request.

Please update the issue summary, tags, and put the change into an issue fork and merge request.

liam morland → created an issue.

This issue is still mentioned in MigrationFormBase along with the warning message "Creating migrations is not yet supported". I suppose that text should be removed. The warning was added in the commit referenced in comment #6 above.

I have disabled some tests. There are still test failures. These may be caused by running the tests on more recent versions of Drupal 10.

Patch with current state of merge request.

@#65: That sounds like a bug. This can be worked-around by using radio buttons instead of a single checkbox. It seems to me that this behaviour should not be changed by switching which widget is in use.

The root problem is that radio buttons allow there to be a difference between false and null. But a checkbox, if un-checked, can be interpreted as false, which means that a value has been set. That could be seen as a core bug.

We might be able to work-around this for the purposes of this patch by having it check if the field is boolean. If so, consider a false value to be empty.

liam morland → made their first commit to this issue’s fork.

Tests are not passing. The phpstan failure is not caused by this merge request.

Branch robotstxt-3332302-3332302-update-readme.md-as created for this issue still exists. It can be deleted.

liam morland → made their first commit to this issue’s fork.

liam morland → changed the visibility of the branch 3114825-document-how-to to active.

Add documentation link for KernelEvents::REQUEST

Remove unnecessary whitespace

liam morland → made their first commit to this issue’s fork.

Drupal 7 is no longer supported. If this applies to a supported version, please re-open.

Changes are committed. Leaving open for more patches.

Tests are not passing.

Update link to module

You can probably clear the message with devel_entity_updates → module.

I have seen this message for custom entities without any clear reason. I wonder if there are ways this can happen without an entity being changed, perhaps due to Drupal core changes.

Put report into template.

Is it the case that this does not show up on 6.3.x? If this problem does appear on 6.3.x, please update the version and fix it there first.

Setting to active because there is no patch.

It still has a merge conflict.

I don't see a commit for this.

Fixed in this commit:

https://git.drupalcode.org/project/webform/-/commit/c167ee6dcfb79b5d54d1...

Has a merge conflict.

Has a merge conflict.

I don't know what EntityType::$entity_keys does well enough to write specific tickets. I need the docs because I don't understand how it works.

There needs to a general improvement in the documentation for EntityType::$entity_keys. I have read outside of api.drupal.org that it is related to key mapping. It also seem to play a role in whether or not a database column is set NOT NULL.

To debug this, I suggest you look at gcds_preprocess_select() and comment-out each property in turn until the error goes away.

Which property is it?

liam morland → created an issue.

liam morland → created an issue.

liam morland → created an issue.

Remove version from documentation link

How are we supposed to control whether or not a database column gets NOT NULL? I implemented ContentEntityBase::baseFieldDefinitions() without using ::setRequired(). All the fields ended up with NOT NULL. Then I added a field, also without ::setRequired(), and used drush entity-updates. That field did not get NOT NULL.

Please make a merge request.

The merge request should have its target switched to 5.0.x. If desired, once merged, this can be cherry-picked onto 4.2.x.

Note that module is only for Drupal 6

Module user_expire is a Drupal 10+ successor to this module. If you make me a maintainer, I would be happy to make the project page refer people to this new module.

The short description for the 4.2.0 release node says "Compatible with Drupal 9+ and Drush 11+". Since it is only actually compatible with Drupal 10, this should be changed.

Update redirected URL

It looks like branch 8.x-1.x-dev can be deleted.

I think this could be postponed until the resolution of 📌 Twig Filter "spaceless" is deprecated Active or until there is a branch to support Drupal 12.

I see it is a protected method and its return value is not used. In theory someone could sub-class this and use the return value. This could have a change record. I have updated the issue title to make it more clear what is happening, so perhaps the release notes are sufficient, rather than using a change record.

Tests are not passing.

Is it the goal that version 2.0.x will be only for 10.5+ and 11.2+?

This has added a spelling error for "titlecase".

The two branches are identical. You can just do a fast-forward merge.

I doubt the test failures are because of this issue. A new issue should be opened to fix them.

Is something holding-up getting this committed?

I was getting this error on every page of a site. I fixed it by uninstalling basic_auth module using Drush.

I think it is preferable to use DeprecationHelper::backwardsCompatibleCall().

Tests are not passing.

liam morland → made their first commit to this issue’s fork.

liam morland → made their first commit to this issue’s fork.

Yes, they need to match for sure. Is it that Webform doesn't control the schema for table webform_submission?

liam morland → made their first commit to this issue’s fork.

Please re-roll for 6.3.x.

liam morland → made their first commit to this issue’s fork.

liam morland → made their first commit to this issue’s fork.

liam morland → made their first commit to this issue’s fork.

Is this really supposed to be signed? Or is it that it's an easier change to make one signed instead of making the other unsigned?