🇨🇦Canada @joelpittet

This is great, just ran into this exact problem and the array_filter() was how I was going to solve it too. I committed the @smustgrave suggested changes, though haven't changed the main solution nor the tests which is around the array_filter().

This is reviewed and ready. 🚀

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

Created a follow-up issue for the reports after the initial commit 🐛 Error: Cannot use string offset as an array in MailSystemModules.php on line 36 Needs review

This fixes the error but again I echo Berdir in that this migration might be better to manually do.

I am not sure I have a good solution for this. My guess is to skip it when there is no key.
Here's the xdebug session
→

joelpittet → created an issue.

I ran into this as well. Ended up cherry picking the migrations I wanted to run instead of running them all.

Also for fun I just stubbed out the missing action plugin to my custom Migration module. This will work because all it cares about is that the plugin id exists.

drush gen plugin:action --answer=MY_CUSTOM_MODULE --answer=auto_entitylabel_entity_update_action --answer=auto_entitylabel_entity_update_action

The input field is empty when this error is happening, Major if not critical so bumping the Priority.

Added another one for the logger 🐛 SQLSTATE[HY000]: General error: 1366 Incorrect string value: '\\xFF\\xFE Needs review

Not sure where the tests should go, my guess would be \Drupal\Tests\dblog\Functional\DbLogTest anybody confirm?

I am ok writing the test, though if someone wants to take a crack at it I am happy to leave it to someone else.

Keep changing the version...

joelpittet → created an issue.

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

The patch in #11 seems to be just the MR in patch form

I am just going to RTBC this as it's a fatal and up the priority

Thank you @WalkingDexter that does the trick.

Thanks for keeping this up-to-date, I would agree with you that the CSS stuff needs to be moved to a separate fix if it's needed.
Issue summary could explain this better

joelpittet → changed the visibility of the branch 3443616-off-by-a to hidden.

Sorry to hear that is happening, I wonder if it's some timezone issue. Can you provide details on reproducing it?

Made a release beta2 with that change in. Sorry for the delay. This is a duplicate of 🐛 Creation of dynamic properties is deprecated Fixed

Thanks I did a partial commit of most of the changes but not the permissions change on the route or many of the unused variable removals.

joelpittet → created an issue.

@DD 85 it looks like you are missing an email from that error, so might be a different issue. We are using MR 14

This has been a while, I am going to close as fixed and remove MR 22 patch from my sites. If someone chimes in with it still happening we can re-open. Just triaging ;)

This looks fixed from #9

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

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

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

It looks like it might be the first stable release. I believe we are close for D10 as well.

I don't plan on doing this...

Generally I don't fix these kinds of issues because they are disruptive to the issue queue existing patches. But there are no issues to conflict with so I commited them. Thank you both for the clean-up.

I've committed the schema file to the dev branch. Thanks for bringing this to my attention!

Thanks for adding a test to prove the problem exists and fixing my typo!

Thank you both, this issue is indeed major as it is a WSOD for content editors. I have reviewed the patches and tested it out and it works well.

Love this, it what I was asking for in ✨ Provide Layout Templates with a variable to indicate they are in layout mode Closed: duplicate closed it as a dupe

Closing as a duplicate for this issue (thanks @larowlan and @eclipsegc)
#3273317: Add 'in_preview' variable to block and layout templates →

@ELC, I share your frustration and have personally disabled emails from the update module in favor of using composer audit to catch more serious security issues. However, I believe this discussion belongs upstream in either the Drupal core queue → or the Drupal.org infrastructure → queue.

I have had many discussions with them regarding this frustrating scenario (on Slack). It’s technically a security issue since we (maintainers) are no longer supporting that branch. This means a security issue could arise, and we are indicating that we will not address it on that minor release branch. Additionally, this problem is historical as we never used to have semantic versions, which compounds the issue, as do our branch naming conventions and how Drupal.org creates releases.

Alternatively, we could keep it open on this project as you’re suggesting, but this would be like playing whack-a-mole. Other maintainers might do this accidentally or on purpose, and you would end up chasing them around the queue. That’s why I recommend taking this problem upstream.

joelpittet → created an issue.

Thanks for the support @irinaz. The release is out. I will create a follow-up for the next release

Fixed in dev

RTBC++

This is a quick fix that should go in soon as possible on a deprecated annotation service

Yes this has had a deprecation notice for some time. Time to let it go!

I am going to cut a stable release next.

This is a bit stale just closing for now

Thanks for fixing this @cboyden. I have committed it to the dev branch

Thanks for this, I have committed it to latest dev branch

Getting a bit closer...

I have it set to PHP 7.4 which did help.

MAX PHP: https://git.drupalcode.org/project/feeds/-/jobs/1864063
Not MAX PHP: https://git.drupalcode.org/project/feeds/-/jobs/1864177
PHP 7.4 explicit: https://git.drupalcode.org/project/feeds/-/jobs/1864327

I will likely disable some tests if they are from third party integrations failing:

1. Organic groups integration 0 passes, 4 fails, and 3 exceptions
2. Rules integration 0 passes, 4 fails, and 7 exceptions

I might also create a new release for OG to help here too...

Changed the template comments to the current template and read the docs on the test dependencies:
https://project.pages.drupalcode.org/gitlab_templates/info/drupal7/#depe...

This is the first one of these I am doing, so we'll see how it goes...

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

Committed so now compatible with D11

Thanks @ramil g, I have committed this for the next release.

I agree with @jwilson3 in #66. This should be default to always use the aspect ratio. That said, if there is no value set for this setting (on existing sites) it should remain off as mentioned in #67.

It's unfortunate that the default settings are always merged, this is why we can't have nice things *whines*.

It seems like this should be set the default for new installs and maybe we need an update hook to set it to FALSE for existing sites? Would that work?

@smustgrave Thanks for taking a look. I believe this is correct in this case but thanks for checking. This case I know the user-input is the source of the problem which is in the issue summary. FYI it looks like this ?tags[0][0] to help read the URL encoding above.

This problem is discrete but part of a bigger set of attack vectors in the parent.

If you could point to a place where I can add a test case, that would really help me out. Otherwise I will take a horrible guess...

I'm cherry-picking pieces of this attack but one part (for me at least) was this 🐛 TypeError: Illegal offset type in isset or empty in FormValidator->performRequiredValidation() Needs review which I made a follow-up from this for

I realize this will need tests.

joelpittet → created an issue.

@timwood This latest solution seems to check all the boxes. I check if there is a base_path and strip it out only when the destination URL is starts with a starting / (which might be always), then the full URL built has a base_path included (can't seem to get around this without manually building it)

Adding another related issue #2418219: Deprecate destination URLs that don't include the base path → as I dig into this further. Specifically #2418219-22: Deprecate destination URLs that don't include the base path → from @claudiu.cristea

Or better keep the current behavior: if the destination starts with a slash, it has the base path prefix. No slash, it's the internal path or alias.

Bump, this would be nice to get in.

@Grevil I tried to do that one yesterday too but 2 problems:

1. Drush 13 (unlucky) wasn't installing on my Drupal 11 local environment
2. Looking at the new annotations for the class in core we are overriding I assume it's not going to be as easy as enabling it compatibility (but I need to just try it...), I saw some CRs that gave me pause though

Thanks @iler for jumping back to grant the extra access and for being a part of the community for the time you have.

By fits and spurts... I will close this but if you have any other RTBC's that I missed that you have been using for years (especially a bug fix) I can add you as a co-maintainer to keep things moving.

Closing this as outdated because the event subscriber was removed and replaced in 🐛 Suppress display of regular system menu blocks in Layout Builder RTBC

Missed this but yes this will require a 9.x only version as 8.x will not be compatible with this change

Thanks I have merged this in to the 2.x branch

There are big changes to plugin discovery and other things so we'll need to test this out before deciding if 1.x or 2.x is the right place for this.

Ran out of time to test and commit this so moving to the next release plan

Ran out of time to test and commit this so moving to the next release

I committed a few of the planned and RTBC'd issues. I will close this as the release happens and move to the 1.12 the remaining

joelpittet → created an issue.

Thank you @dougreen for applying my feedback. I have committed this for the next release.

Thank you and I appreciate the tests on this as well. I have committed this for an upcoming release of 1.11

Thanks all for your patience, I have committed this to the dev release for inclusion in the upcoming release.

Closing this as it was released a while ago.

There is not enough info and I don't know what twig tweak is intended to do, so best just try to do it and describe your experience (success or failure)

Going to close this as works as designed as per comment #2

This sounds like it would conflict with https://www.drupal.org/project/block_class →

I tried to reproduce the error you reported and could not on a stock drupal 10.2 site with the standard install profile, logged in and logged out with the user menu placed in the content area.

If you can provide more details to reproduce we can look at re-opening this issue.

This doesn't sound like critical, and it is hard to tell if it's a bug or a feature or a support request. I will leave it as a bug request for now and hopefully someone confirm the steps to reproduce

@jeroendegloire Before squashing this bug I wonder what got it into this case in the first place. Is it possible to put a breakpoint where this is and see what is happening with the pluginid in this case? Maybe this error is highlighting a bigger data problem in your site that should be addressed.

Merging the MR was proving challenging, made a small change and merged it manually. I manually tested it and works with layout builder and block layout and simplifies the code.

Also I reverted the code in 🐛 Duplicate menu blocks appear in Layout Builder choose block form Fixed as it does double the work as it was doing hook_plugin_filter_TYPE__CONSUMER_alter

I appreciate the intent behind this fix but the problem with coding standard fixes is that they disrupt the fixes in the queue for actual bugs and features and forces them to be re-rolled (unnecessarily).

I would recommend these fixes be fixed when the lines, themselves, are being fixed in active issues, or the very least the same files.