manuel.adan → changed the visibility of the branch 3433995-automated-drupal-11 to active.
manuel.adan → changed the visibility of the branch 3433995-automated-drupal-11 to hidden.
manuel.adan → made their first commit to this issue’s fork.
manuel.adan → created an issue.
Tests passed on D9, D10 & D11. Thanks!
Patch #2 committed. Use statements order not touched to clearly view the actual changes, it can be addressed elsewhere, e.g. CS related issue.
All right @pearls, thank you for your review. IEF compatibility was addressed by checking the signature of parent class. That way, we avoid to launch a new major version which is preferable, e.g. for easy upgrading sites using Transaction from D10 to D11.
Tests passed in D9 (PHP 8.1), D10 & D11 (PHP 8.4).
+++ b/src/PrivateShortcutSetStorage.php
@@ -200,6 +200,7 @@ class PrivateShortcutSetStorage extends ShortcutSetStorage implements PrivateSho
+ ->accessCheck(TRUE)
In this case it's a database delete query. The entity API is not involved, so access check is not applicable. Actually, there is no accessCheck method in database Connection class.
Patch moved to issue's Gitlab fork.
manuel.adan → made their first commit to this issue’s fork.
Still present in D10 with IEF 1.0.0-rc17. Patch applies and works, but needs some UX review. When using complex IEF "Update" and "Cancel" buttons shouldn't be displayed:
To ensure a proper transaction execution order the "execution_sequence" property must be set with a unique sequential number. The display order shouldn't relay on the ID since there may be more recent executed transactions than others not executed yet.
Automatic tests are now configured in GitLab CI. To be done under the new way.
I was unable to reproduce it following the provided steps in a fresh installation. Nobody else reported being affected by this issue in this time. It could be something specific of your installation. Feel free to reopen if it happens again.
I was unable to reproduce it following the provided steps to reproduce. Nobody else reported being affected by this issue in this time. It could be something specific of your installation. Feel free to reopen if it happens again.
I was unable to reproduce it. I tried to uninstall from the UI and having config_translation installed as shown in the stack trace. Nobody else reported being affected in this time. It may be something specific of your installation. Feel free to reopen if it happens again.
manuel.adan → created an issue.
It was already done as part of 📌 Automated Drupal 10 compatibility fixes Needs review . My apologies for the long time in reviewing this.
It was already done as part of 📌 Automated Drupal 10 compatibility fixes Needs review . My apologies for the long time in reviewing this.
Right, already addressed (and fixed) at 📌 Automated Drupal 10 compatibility fixes Needs review .
PHP 8.4 compatibility issues were already addressed at 🐛 PHP Deprecated: Implicitly marking parameter $entity as nullable is deprecated Active . It was just committed to 8.x-1.x and merged here. Tests pass now in D10 + PHP 8.4. I think that we can go with this. Thank you everyone!!
manuel.adan → made their first commit to this issue’s fork.
Initial simple logo proposal made with GIMP:
manuel.adan → created an issue.
Tested successfully on D10 PHP 8.1 and D11 PHP 8.3 & 8.4
manuel.adan → created an issue.
manuel.adan → created an issue.
manuel.adan → created an issue.
Tests are being affected by Drupal core issue 🐛 Undefined array key "view_mode" in block_content_theme_suggestions_block_alter Active , they pass in D9 (PHP 8.1), D10 (PHP 8.1, 8.2, 8.3 & 8.4) and D11 (PHP 8.3 & 8.4) patching core.
Let's review this
I reverted Drupal 11 compatibility to be addressed separately right after ensuring compatibility with Drupal 10. It will simplify having a D10 compatible version ASAP. E.g. the Transaction IEF submodule is not compatible with Inline Entity Form >= 2.x and it has no 1.x version compatible with Drupal 11. I prefer not to work on that here.
Tests passed on D9 with PHP 8.1 and in D10 with PHP 8.1, 8.2 and 8.3 and didn't find any issues testing it on those scenarios.
Unfortunately, it doesn't work on Drupal 10 with PHP 8.4. We need compatibility with PHP 8.4 since Drupal 10.4 can run on top of this PHP version.
Let's review this
Duplicate of 🐛 Toolbar overlap content with big pipe enabled Needs work ?
manuel.adan → created an issue.
Proposed logo:
manuel.adan → created an issue.
That could be a nice contribution!
Feature seems very specific. It can be easily achieve in a custom module using extension mechanism, such as form_alter + custom token.
No updates in a long time. Feel free to reopen if needed.
Currently, confirmations of any type (realm) are automatically removed when the lifetime is reached (if set in config). Remove confirmations related to user email changes when an user account is cancelled (or even blocked) could be a polite thing.
It is a clear bug. The patch at #3 is valid, but there are additional things to solve related to the request queueing:
- In the same line (82), comparison is made between the current time and the confirmation creation time. It should be compared with the last time the confirmation request was sent by email
- Once the main bug is fixed, the involved queue must be cleared or it would start to send old queued confirmation requests that probably are expired or already answered
- At line 17, the maximum cron processing time is set to just 5". It is a short time, in particular if an email delivery is involved. It should be at least 30"
- In case of several consecutive request attempts, all of them are queued. If an attempt is already queued for a given confirmation, following requests shouldn't be queued. There is no a good way to check if an item already exists using the Queue API, and rely on DB queue table is not an option since some sites may have another queue backend rather than the default one in core. I think that the best approach to address this is by using the Queue Unique module → which exactly provides what is needed. For now it will be just added as a suggestion in composer.json, for next major versions it could be added as a dependency.
After response URLs (confirm and cancel) must be internal paths. As pointed in the description, they should not contain any leading slash. Read more about internal paths here (D7 but conceptually it is still valid) → and Url::getInternalPath() method.
There is a feature request to allow external URLs 🐛 External Confirmation URL doesn't work RTBC .
It is an old demand to have different settings per realm → . This request goes in that direction. It is not really a bug, the Email Confirmer User submodule works that way. Anyway, despite it makes sense, we cannot introduce such modification since it would change the behaviour of existing websites. It will possible to do so in further 2.x branch.
Going deeper into this, it makes sense that the expired status also means that there was no response to the confirmation request. But according to the getStatus() method documentation, expired status is returned regardless of any other condition:
[ ... ]
* - expired: the confirmation age is over the allowed maximum, regardless
* of any other status
*
* Note that an expired confirmation could be confirmed as well. Check
* the confirmed status with the isConfirmed method.
[ ... ]
Therefore, the patch introduces changes to the API and may break any existing implementation using this method.
Postponed for the 2.x branch.
It is possible to rely on Entity API hooks and catch events related to the email_confirmer_confirmation entity type. E.g. hook_entity_create
Sure, it is explained in the module's main page
launch an email confirmation in just 1 line
\Drupal::service('email_confirmer')->confirm('somemail@example.com');
Basic tests added:
- Confirmation email is sent.
- Response form is accessible.
- Positive confirmation works.
Explicit accesCheck added on cron task fixing errors because of [#3201242]. I changed the existing behavior as well, it doesn't check access now, cron call tipically runs under anonymous user and may not have permission to list inactive subscriptions. Static patch file from current plain diff added for composer patches.
manuel.adan → created an issue.
manuel.adan → made their first commit to this issue’s fork.
manuel.adan → created an issue.
Static patch just for composer patches.
manuel.adan → created an issue. See original summary → .
manuel.adan → created an issue.
@godotislate, could you plz share your temporary workaround if possible?
Are you okay with them converting to
It may be a valid solution. In our site any CSS style uses the class name as selector.
manuel.adan → created an issue.
RTBC then, thanks!
manuel.adan → created an issue.
manuel.adan → created an issue.
Another approach made to this in branch 1255092-front_page_outbound_url_path_processor, based as well in URL processor but outside of URL alias as suggested by Berdir at #66 🐛 url() should return / when asked for the URL of the frontpage Needs work . I added outbound URL processing to the existing front page path processor.
It may fail in case of a front page path with query parameters were set, but it is also not well managed by other core parts like PathMatcher, see 🐛 Front page path with query parameters makes front path condition to fail Active . Added as related issue since support for query parameters should be added.
manuel.adan → created an issue.
manuel.adan → made their first commit to this issue’s fork.
Inbound path processor replaces response composition by sub-request the content entity canonical path when accessing the holder on its URL.
Tested aliasing both the holder path and the content entity.
manuel.adan → created an issue.
manuel.adan → created an issue.
Branch 3438332-automated-drupal-11 tested on current D11-dev. Session seems to be required in subrequest by newer synfony version used in D11.
manuel.adan → made their first commit to this issue’s fork.
manuel.adan → created an issue.