Account created on 11 April 2017, over 7 years ago
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States briantschu

I updated the patch from #9 to be compatible with version 1.5.0, which matches the latest 1.x-dev.

πŸ‡ΊπŸ‡ΈUnited States briantschu

@cjsingle, can you confirm that you're using version 4.0.0 of the module? When I look at line 207 of the password_policy.module file, it's a comment.

πŸ‡ΊπŸ‡ΈUnited States briantschu

If a user doesn't have the permission 'manage password reset', then the code is setting #access to the 3 password policy fields on the user edit form to false.

During validation, the code will still update these fields (even though #access is false), but the values aren't saved because the user doesn't have access to the fields. The field that needs to be updated, but isn't, is `field_password_expiration`. Since this value isn't getting re-set to '0' when the user changes their password, they're getting stuck in a password reset loop.

The only approach that I found that works is changing the 3 fields to be hidden fields, rather than setting #access to false. This allows the fields to be hidden from the user, but still get updated when the user saves the form with their updated password.

I tried a few different approaches to fixing this, including using setValueForElement in the _password_policy_user_profile_form_update_fields validation method, but that didn't seem to work.

πŸ‡ΊπŸ‡ΈUnited States briantschu

This was happening on one of my sites and it was being caused by applying the uniqueid Twig filter to the id of the form. In form.html.twig we had this code: <form{{ attributes.setAttribute('id', attributes.id|unique_id) }}>.

By creating template overrides for the user login, password reset, and user registration forms, we were able to resolve this issue by removing the uniqueid filter, resulting in <form{{ attributes}}>.

I didn't look into the javascript of the antibot module at all to see if it can be adjusted to support forms that use the uniqueid filter, but wanted to share in case it helps anyone else.

πŸ‡ΊπŸ‡ΈUnited States briantschu

Looks like `hook_requirements()` is returning NULL in some cases when it needs to return an array.

I'm attaching a patch that resolves this.

πŸ‡ΊπŸ‡ΈUnited States briantschu

I think this is a duplicate of πŸ› PHP 8.1.x. compaitibility Fixed , which was merged into version 1.3.x-dev. Does using the dev version of the module, or applying the patches mentioned in comment #4 on that issue ( #3324392-4: PHP 8.1.x. compaitibility β†’ ) fix the error for you?

πŸ‡ΊπŸ‡ΈUnited States briantschu

When testing this locally, I noticed that if I enter a value in the "Header styles" and turn on "Exclude admin", I started seeing warnings: "Warning: Undefined array key 1 in Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processHtmlHead() (line 396 of core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php)."

I didn't test much further, because I'm only planning to use this to add scripts. Adding scripts didn't seem to cause the same warning.

πŸ‡ΊπŸ‡ΈUnited States briantschu

It turns out we only need to set the OVERWRITE flag when we're constructing the ZipArchive during the export process. Setting it every time we constructed the ZipArchive caused the import to fail; the contents of the ZipArchive were emptied.

This patch along with the core patch I linked to in #3 should allow imports and exports to work successfully with no warning messages.

πŸ‡ΊπŸ‡ΈUnited States briantschu

It looks like a change to the underlying zip library causes this. Adding a flag ZipArchive::OVERWRITE when constructing the ZipArchive seems to resolve the warning.

In order to pass the flag, Core needed to update the ZipArchive constructor. Luckily, that's available in this issue: πŸ› Unable to open Zip archive using ArchiverZip Fixed .

Applying the patch from #51 in the Core issue along with the attached patch resolved this for me.

πŸ‡ΊπŸ‡ΈUnited States briantschu

I'm attaching a patch that should cause Facebook embeds to match the language of the page the content is embedded on.

I used some code that oscarotero shared in an Issue in the Embed repository to provide an 'Accept-Language' header as a starting point:

$embed = new Embed();
$embed->getCrawler()->addDefaultHeaders(['Accept-Language' => 'it-IT']);

This patch uses the Language Manager service to get the content language and pass the value in the header.

Production build 0.71.5 2024