🇺🇸United States @smokris

smokris → created an issue.

The patch works but has unintended side effects.
Namely, the new parameters message_orig and message_args leak into the logs.

@ragnarkurm, I intentionally included those values — when bulk-analyzing log messages, it's helpful to know which template was used (message_orig) in order to group together similar log messages, and it's helpful to have the individual argument values (message_args) in order to show them in columns and sort/filter them (otherwise the log analyzer needs to parse the formatted message in order to recover them).

I converted the patch to a merge request, as instructed by the above needs-review-queue-bot comment.

Rebased.

Thanks, @zengenuity.

Patch attached.

smokris → created an issue.

Add a section mentioning which factors influence the cache identifier.

smokris → created an issue.

Thanks, @xjm. Here's an MR for 10.1.x: https://git.drupalcode.org/project/drupal/-/merge_requests/5362

Created https://git.drupalcode.org/project/drupal/-/merge_requests/5355.

Revised test data since the transformation now removes empty attribute values.

Both patches failed. Investigating…

(Unintentionally changed issue status. Sorry for the noise.)

Thanks. #26 has an unnecessary variable assignment which wasn't present in #17. I've attached a modified patch that removes that line (and an interdiff).

Re-rolled for current 11.x-dev.

Done in https://github.com/lyalyuk/social_auth_apple

@lyalyuk, thanks for sharing this. I was able to get it working on a Drupal 10.1 site with the following changes:

1. In services.yml, set parameters › session.storage.options › cookie_samesite: None (without that change, when Apple performs a POST request to the authorization callback, the browser doesn't include Drupal's session cookie, so the state can't be validated)
2. Apply patch https://github.com/patrickbussmann/oauth2-apple/pull/50
3. Apply patch https://github.com/lyalyuk/social_auth_apple/pull/1
4. Apply patch https://www.drupal.org/project/social_auth/issues/3399227 ✨ Support networks that POST to the authorization callback Needs review

Patch attached.

smokris → created an issue.

If I understand correctly, the remaining concerns have all been addressed:

• catch's question in #49, addressed by philipnorton42 in #54
• nlisgo's question in #59, addressed by philipnorton42 in #61
• nlisgo's question in #62, addressed by philipnorton42 in #63
• gapple's question in #64, addressed by Berdir in #65
• smustgrave's question in #67, which I addressed just now by updating the issue summary

…and the patch still applies, so I'll set this issue back to RTBC.

Updated patch to also handle regular (non-object) log messages.

Add another example implementation; add a little more detail on ComplexDataInterface

See ✨ Add support for periodically indexing arbitrary pages (views, contact forms, …) Needs review for similar functionality in search_api for Drupal 8+.

(Add another remaining task.)

Updated patch attached.

Early WIP patch attached.

smokris → created an issue.

since the datasource is now part of the Search API Solr module proper, we can just link to that instead

@drunkenmonkey, ah, I see, thanks for pointing that out.

Remove broken links to nonexistent sandbox module

Patch attached.

smokris → created an issue.

Patch attached.

smokris → created an issue.

I've attached patches (based on AdamPS's snippet above) for simplenews 3.x and 4.x.

I've confirmed that, with the combination of blazy 2.18 + slick 2.10 + slick_paragraphs 2.4, our captions are properly rendering again. Thanks, @gausarts!

Thanks for the feedback. My scenario is like this:

• I have a Content Type called "Paragraphs Page" that has an Entity Reference Revisions field that allows referencing Paragraphs
• The referenced Paragraph Type has these fields: Media (Entity Reference), Title (Text), and Link (Link)
• The Content Type uses the Slick Paragraphs Media formatter, with these Fields selected: Main Stage "Media", Title "Title", and Link "Link", with Layout "Caption bottom"

I tested the latest 2.x branch (a3186b7a, without any patches), but the Title and Link are not being rendered.

Commenting out these 2 lines fixes the problem (the Title and Link are now properly rendered): https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/src/Media/BlazyO...

I've attached a new patch that removes those lines.

Patch attached.

smokris → created an issue.

what about removing those mistaken overwrites instead?

Sure, removing unneeded code sounds good to me.

I'm not sure which lines to remove though. If I remove BlazyEntityMediaBase::withElementDetail()'s call to $this->blazyOembed->build($data);, then the paragraph content doesn't show at all. Could you clarify what you have in mind?

Patch attached.

smokris → created an issue.

On a site running Drupal Core 10.1.2, here's what I see with Arantxio's patches:

If I understand correctly, we want to re-add the "save" and "cancel" buttons to the end of the panel, so they remain in their usual positions. I think we can do that by calling .add(item) (without the index argument). I've attached a new patch that does that.

Updated issue title, as requested.

Updated for PHP 7.3 compatibility.

Test + fix patch attached; should pass.

Test-only patch attached; should fail.

smokris → created an issue.

Yay! Thanks, @fjgarlin and @drumm.

Fix + test; should pass.

Test-only patch; should fail.

Updated issue summary.

Agreed. I've attached a revised patch that adds some space between the label and list.

Thanks for the feedback. I reworked the patch for bluecheese and opened 📌 Add basic styling for the alternatives widget Fixed .

Patch attached.

smokris → created an issue.

Patch attached.

smokris → created an issue.

Since the test-only CI job failed on PHP 8.1 (as expected), and the test-and-fix CI job passed, I'll tentatively set this to RTBC.

@TR, thanks for the tip. Here's a new patch that includes a test that's a subclass of PhpMailTest, and which uses PhpMailTest's technique of creating a mock of the class being tested but with the doMail() method replaced.

smokris → created an issue.

https://www.drupal.org/pift-ci-job/2701615 → correctly failed with the Attempt to read property "server" on null error.

However, https://www.drupal.org/pift-ci-job/2701616 → failed with PHPUnit\Framework\Exception: sh: 1: /usr/sbin/sendmail: not found. Unfortunately, the PhpMail::mail() method doesn't seem to be testable, since it invokes PhpMail::doMail() which invokes PHP's built-in mail() function, without any way to override it with a mock for testing.

And here's a patch that addresses the problem by invoking the parent constructor.

What are the conditions that cause this error message?

I'm able to reproduce the above warning and error by following these steps:

1. Install Drupal 10.1.0
2. Install and enable mimemail 1.0-alpha5 + mailsystem 4.4.0
3. On /admin/config/system/mailsystem, set the default sender to Mime Mail
4. As an anonymous user, go to /user/password and request a password-reset email — ❌ Error: Call to a member function has() on null

In 🐛 Uncaught RfcComplianceException when email From name contains a comma Fixed , Drupal Core added the PhpMail::$request instance variable which gets initialized by PhpMail::__construct(). Since the MimeMail class derives from PhpMail but MimeMail::__construct() doesn't call parent::__construct();, the PhpMail::$request instance variable remains uninitialized, resulting in the above warning and error.

The automated tests of Mime Mail don't fail in Drupal 10.1.

I think that's because there isn't a test case for sending using the MimeMail class. I've attached a test that should fail.

I opened an issue fork consisting of hswong3i's patch from comment #206, plus a commit to remove another stray reference to the removed $noscript variable.

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

I successfully tested it on my site; I'll tentatively set the issue status to RTBC.

The 2.0.x branch already has hook_discourse_sso_parameters_alter, so this issue only affects the 7.x branch.

Same here. I successfully tested it on my site; I'll tentatively set the issue status to RTBC.

The 2.0.x branch already sets the Discourse external_id to the Drupal UID, so this issue only affects the 7.x branch.

Will users appreciate it more if phrase search “just works” (as most people would expect), or if we use their database storage sparingly?

For new installations, enabling it by default sounds great.

For existing installations, if this change will be included in an upcoming 1.x minor-version release, I think it might be disruptive/surprising if it were automatically enabled and suddenly the site's index size grew significantly. (Though the upcoming 2.0 major-version release ( #3126115: Create a 2.0.0 release → ) might be a suitable time to automatically enable it for existing installations too?)

I've attached an updated patch that includes a first draft of the UI for toggling support for phrase indexing/searching, and a screenshot of it with the new option highlighted in pink. It's enabled by default for new installations, and for existing installations I added a hook_update_N implementation that disables it.

Rebased patch.

Revised patch to address failure in testAutocompletion.

Patch attached.

smokris → created an issue.

I just opened https://git.drupalcode.org/project/jsonlog/-/merge_requests/7 which:

• combines the latest patches from Project Update Bot and xurizaemon
• updates the LoggerInterface::log signature to match core's RfcLoggerTrait::log
• fixes a "Deprecated function: date(): Passing null to parameter #1 ($format) of type string is deprecated" during installation
• marks the module as Drupal 10 compatible

I've briefly tested on Drupal 10 and confirmed that it's now able to log messages.

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

If the site administrator correctly follows the instructions (presses the back button, copies down all of the permissions checkbox values, reloads the page, then updates all of the permissions checkboxes again), then there is no problem — the permissions are correctly updated.

However, I do think is a usability concern with this particular form: if the site administrator overlooks the instructions and submits the current page (rather than using the browser's back button), then, with a single click, all of the site's permissions are revoked. My intention in raising this concern is to help reduce the likelihood of that incident recurring.

For many other forms (creating a node, for example), it is very obvious if the form has been emptied: by default, Drupal doesn't allow you to create a node with an empty title, and if you were to follow the same steps in the issue body with /node/add/page instead of /admin/people/permissions, then form validation fails, and there is no adverse effect. But since the permissions form is very large (and typically sparse) it's easy to overlook that the form state has been cleared, and since Drupal allows submitting a fully empty permissions form, it's easy for that form-state-clearing to unintentionally revoke all of the site's permissions.

smokris → created an issue.

smokris → created an issue.

(Fixing screenshot filename in issue summary.)