prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
IMHO an user with admin role is basically the same thing as a super user (except the UID is not hardcoded).
A role that has is_admin: true in its config automatically has every permission.
Also, it's quite a different attack surface to edit a super user, compared to an admin role, which may or may not be super users per se.
I am not sure the attack surface is different.
Getting control of user 1 gives every permission.
Getting control of a user with an admin role (a role that has the is_admin flag) gives every permission.
prudloff → created an issue.
I just noticed that I did not have the error on another website.
Turns out Drush usually provides a current request but I was using
this patch →
that somehow removed the request from the request stack (I am not sure how honestly).
I am keep the MR open because it might still be worth it to make Renderer::getCurrentRenderContext() more robust when there is no request.
prudloff → created an issue.
prudloff → created an issue.
prudloff → created an issue. See original summary → .
prudloff → made their first commit to this issue’s fork.
I am using Drupal 11.0.9 with symfony_mailer 1.5.0.
I don't have the problem with the reset link reported by @ot1201. But I have a double encoding problem when the site name contains a ' character.
I am attaching screenshots of the problem.
I am getting a similar problem when using symfony_mailer and sending a password reset mail containing the [site:name] token.
The LegacyEmailBuilder from symfony_mailer seems to assume that all core email are plain text.
But user_mail() adds an HTML body to the email (because it uses Token::replace() and not Token::replacePlain().
When using core to send emails you don't notice it because PhpMail::format() then removes the HTML.
But when using symfony_mailer, this HTML is double encoded.
LegacyMailerHelper::formatBody() from symfony_mailer converts the message body to a #processed_text element without specifying a format, so the default format is used.
On most websites, the default form will be plain_text with the FilterHtmlEscape filter enabled.
This means if the website name contains a ', user_mail() will convert the token to a string containing ' and FilterHtmlEscape will double escape it as '.
Is symfony_mailer correct to assume all core emails are plain text? If so, user_mail() should add a plain text body to the message.
@ot1201 instead of using PlainTextOutput::renderFromHtml($token_service->replace()), it is probably cleaner to use $token->replacePlain().
prudloff → made their first commit to this issue’s fork.
prudloff → made their first commit to this issue’s fork.
prudloff → changed the visibility of the branch 3494490-cas-3-compatibility to active.
prudloff → changed the visibility of the branch 3494490-cas-3-compatibility to hidden.
It is IMHO a better practice to specify the required version in the info.yml file instead of composer.json.
This way it is used both by Drupal to validate the constraint when enabling the module and by drupal.org when generating the Composer package.
prudloff → created an issue.
I think only the creator of the MR, the person who started the thread or the maintainers of the module can mark threads as resolved.
prudloff → changed the visibility of the branch 3026636-allow-ajax-links to hidden.
prudloff → changed the visibility of the branch 11.x to hidden.
prudloff → changed the visibility of the branch 9.3.x to hidden.
prudloff → created an issue.
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
Thanks!
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
I did some tests with phpspreadsheet 3.5 and everything seems to work correctly.
The PHP requirements are the same as 2.3 so I don't think we need to keep supporting 2.3 alongside 3.5.
Sorry, I read the description too quickly. I can indeed reproduce when forcing a batch and can confirm the patch fixes the error.
webform_xlsx_export will now prevent users from using 2.2 (because no 2.2 release is secure).
Note however that it is the responsibility of devs using this module to use secure versions of dependencies.
I could not reproduce the error but the change seems harmless so I merged it.
prudloff → made their first commit to this issue’s fork.
berdir → credited prudloff → .
@jess thank you for reporting this but I think it would be better handled in a separate issue.
If you are able to provide a full stack trace for the error, it would be easier to see what happens exactly.
duaelfr → credited prudloff → .
prudloff → changed the visibility of the branch 11.x to hidden.
prudloff → changed the visibility of the branch 10.0.x to hidden.
prudloff → created an issue.
prudloff → created an issue.
Sorry, I think this is a duplicate of 🐛 TypeError: array_values(): Argument #1 ($array) must be of type array, null given Active .
prudloff → created an issue.
prudloff → created an issue.
prudloff → created an issue.
prudloff → created an issue.
Would it be possible to publish a new release with the ^11 fix?
Currently version 2.1.0 forces using Drupal 11.0.0.
Duplicate of 📌 Automated Drupal 11 compatibility fixes for webform_xlsx_export Needs review
prudloff → made their first commit to this issue’s fork.
prudloff → created an issue.
We noticed it is dangerous to use this property because the entity ID is not always added to the cache keys (eva_entity_view() only adds it if the entity ID is used as view argument).
So if for example you have the same eva view on the same page but for different entities and your code uses the current_entity property to change the output of the view, the view render will only be cached once for the first entity and reused for the other entities.
prudloff → created an issue.
prudloff → made their first commit to this issue’s fork.
prudloff → changed the visibility of the branch 9.3.x to hidden.
prudloff → changed the visibility of the branch 11.x to hidden.
prudloff → made their first commit to this issue’s fork.
prudloff → made their first commit to this issue’s fork.
prudloff → made their first commit to this issue’s fork.
Duplicate of 📌 Automated Drupal 11 compatibility fixes for webform_xlsx_export Needs review ?
mr.baileys → credited prudloff → .
There is a remaining problem: if the image already has a link on it, uploading a file does not change this link (in the data model).
I'm not entirely sure this is the best approach but it seems to work for us.
prudloff → created an issue.
The draft MR fixes the file link insert on images and generates whats seems like a valid data model and correct UI, however there is a remaining problem with the downcast: it generates two <a> tags.
I think one comes from drupalfileediting.js and the other from downcastBlockImageLink().
prudloff → created an issue.
However, the patch in #11 (with Drupal 10.2) throws this error when rebuilding the cache:
The patch will probably not work without 📌 Convert CacheTagsInvalidator to use a service collector Fixed (committed in 10.3).