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.
manuel.adan → created an issue.
manuel.adan → changed the visibility of the branch 3438103-request-path-condition to hidden.
manuel.adan → created an issue.
Created 3422897-coding_standards issue branch from the static patch file 3422897-2.patch.
Several reviews on top on that, ready to merge.
manuel.adan → changed the visibility of the branch 3422897-fix-the-issues to hidden.
manuel.adan → made their first commit to this issue’s fork.
Updated static patch file.
Extended the issue to the pre query method as well.
I found that current implementation calls pre query method after building the request params, so query alterations have no effects. It was fixed.
Now the active issue branch is 3435998-pre_post_query_events
manuel.adan → changed the visibility of the branch 3435998-post_query_event to hidden.
New one updated with the last fixings.
Moving to fixed since it is already committed and published into the last alpha4 release.
Patch file with static plain diff of issue 3435998-post_query_event and 8.x-7.x branches. Contains the event definition and trigger. Also deprecates the postQuery method.
manuel.adan → created an issue.
Patch file attached containing plain diff of current state of branches issue/3102388-nodespark_des_connector_data_source and origin/8.x-7.x for convenience only.
Created new branch 3102388-nodespark_des_connector_data_source in the issue fork for works on the 8.x-7.x (nodespark/des_connector based) branch only with the implementations from #3102388-8 updated to the latest base code changes.
Patch from #20 ✨ Add Search API data source implementation Needs work , which contains several changes from the lastest comments, brokes my site currently running previous patch version, probably because of the plugin ID change. We have no easy way to review changes in patches from #15 ✨ Add Search API data source implementation Needs work to #20 ✨ Add Search API data source implementation Needs work since there is no interdiff and also some patches contain more than one change. Changes from latest patch files should be commited on top of the new branch, as 1 commit per change, in order to be able to follow and review them.
manuel.adan → changed the visibility of the branch 8.x-7.x to hidden.
+1
Comparto la presentación del evento. Gracias a todas/os por vuestra asistencia!
manuel.adan → created an issue.
Thank you for the review! Committed as suggested, so now we have basic test coverage to be extended.
Going ahead with last changes to move forward. Thanks!
I have tested the solution and it is working fine, thank you all!
manuel.adan → made their first commit to this issue’s fork.
The label field is required, so after the patch, editing existing block instances forces to provide now a title. I think that it could be optional, since create new instances without a label is a admitted situation.
In addition to that, there is another "Title" field when the "Override title" options is enabled, which might cause confusion. Renaming the instance label as "Administrative title" could be a work around for that.
manuel.adan → created an issue.
manuel.adan → created an issue.
Title was replaced by the filter ID in cases that the empty PHP function evaluates as true, eg. for '0'.
It would be a more complete solution to unconditionally add the filter ID to the labels. By that way, we also cover cases like having different exposed filters with the same title.
manuel.adan → made their first commit to this issue’s fork.