Original patch only applied to StringFilter. I expanded it so it also applies to NumericFilter.
This might be a valid reason to leave the option in FilterPluginBase (since it's being questioned in #4).
Upgrade path + test coverage is still TODO.
mstrelan → credited rp7 → .
As I already mentioned by others, perhaps we should idd look into separating the 2 features.
Skipping unpublished content could use/benefit from the solution being worked on in
✨
Allow entities to be skipped programmatically
Needs review
.
Patch attached adds a SkipEntity-event (similar to the already present BuildHeader event) that allows entities to be skipped from link checker.
Patch attached is how a possible implementation could look like.
Experiencing the same issue on a project of ours. Running on 10.2.6. Patch fixes it, but I agree with #3 that this isn't really a long term solution.
Here's how the implementation could look like.
I was looking for a way to use feature flags within Drupal and stumbled upon this issue. I'm a bit surprised seeing modules being proposed, but I'm probably missing something obvious.
If we want the on/off state of feature flags to be deploy-able (I'm still trying to grasp exactly why - especially looking at tools like LaunchDarkly - in which feature flags are meant to be evaluated during runtime), why is a module preferred over just a true/false configuration setting? What benefit does it give us?
FWIW, the approach External Entities is taking (external entity types as config) was inspired by https://www.drupal.org/project/eck → and (IMO) is certainly something that should be kept.
But I'm pretty sure @joachim is not asking to remove that part - rather support both scenario's (through config or through code).
@jsacksick
Might be a good idea to consider!
(not entirely sure how that would play with cacheability & invalidation, something to research)
The variations can be re-saved in the background (through a queue). So that removes the performance bottleneck.
The node_revision_delete module has no concept of content moderation which could potentially make it dangerous for moderated sites where forward revisions could be drafts and an historical revision could be your current published revision (see in getCandidatesNodes in node_revision_delete).
Could it be that you are talking about the first version of the node_revision_delete module? Because the 2.x version certainly is content moderation aware.
I can't find a getCandidatesNodes() method in the 2.x version of the module, so you are probably talking about the first version?
Updating tests. Expecting them to succeed now.
Updating tests.
Updating tests.
Made a few proposed changes + tried to get the tests green.
A test for an actual asset generation path should still be added, though.
MR opened + patch attached.
Fixed deprecation notice: Deprecated function: Creation of dynamic property Drupal\\vbo_export\\Plugin\\Action\\VboExportDoc::$renderer is deprecated in Drupal\\vbo_export\\Plugin\\Action\\VboExportDoc->__construct().
Just as I created this ticket, it looks like this error is introduced by another patch we are using. Sorry for the noise. Closing this one.
This issue is also present on the 2.0.x version of the module.
It's more wide-spread than trailing slashes, though. It was malforming all kinds of URLs. A few examples:
https://www.ae.be --> https://www.ae.be/en//en//en//en/
https://www.csee-etuce.org --> https://www.csee-etuce.org/en/en/en/en/
https://famiris.brussels --> https://famiris.brussels/fr/fr/fr/fr/
https://www.vlaanderen-helpt.be --> https://www.vlaanderen-helpt.be/s//s//s//s/
https://www.liefkenshoektunnel.be --> https://www.liefkenshoektunnel.be/nl/nl/nl/nl
https://bevolkingsonderzoek.be --> https://bevolkingsonderzoek.be/nlnlnlnl
https://www.shiftzwvl.be --> https://www.shiftzwvl.be/shiftzwvl/shiftzwvl/shiftzwvl/shiftzwvl
https://www.portofoostende.be --> https://www.portofoostende.be/enenenen
https://toll4europe.eu --> https://toll4europe.eu/de/de/de/de
https://clickdimensions.com/about/privacy-policy --> https://clickdimensions.com/about/privacy-policy////
It caused about ~1.5K malformed URLs on my website. Bumping this to major as in the current state this functionality is not safe to use.
I ported the D7 patch so it now also applies to 2.0.x
Looks like this is already being fixed in 🐛 Revisions not deleted when revision_translation_affected is NULL for all languages Needs review ?
@joseph.olstad
There's no hook_cron() implementation because NRD 2.x does it processing through a queue worker. Queue workers are executed via Drupal's core cron & don't need a specific hook_cron() implementation.
I have no experience with Ultimate Cron myself, but going by the project description it has ways of configuring when queues are to be run. You'll have to look for the "node_revision_delete" queue.
A small improvement in that the field label is nog also mentioned in the error message, which makes it easier for the user to know which field is causing the error message. As mentioned before, the error reporting is still very much barebones and I expect the work done in #1327632: Support action specific status message reporting. → could help us here.
Expanded the patch to limit validation errors to only the ones that the user is able to edit, consistent with content entity forms (https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Core/Entity/ContentEntityForm.php?ref_type=heads#L212)
Patch of MR #34.
Patch in #32 works fine, but uses a deprecated method that is removed in D10. Adjusted the patch.
I can confirm that increasing the query timeout resolves the error.
Additionally, I think this cron-logic needs to be expanded to first see if the suggest request handler is enabled. You can disable it through the UI, but doing so will result in 404 Solr endpoint errors in the logs (when this cron is run).
And still noticed some issues. Next attempt. Sorry for the noise.
In re-roll of #11 I forgot to take into account that the primary key is re-added in a new update hook. Adjusting patch accordingly.
rp7 → created an issue. See original summary → .
Looks like this ticket is a duplicate of
🐛
Use core/internal.backbone lib
Needs work
.
Since that issue is older, has a patch that's verified by users - I'm closing this one.
Tested the module with version 2.2.1 and the patch works fine. Thanks!
The event dispatch syntax has changed for Drupal 10 - see #3055194: [Symfony 5] The signature of the "Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch()" method should be updated to "dispatch($event, string $eventName = null)", not doing so is deprecated since Symfony 4.3. → . Updating the patch accordingly.
It looks like this patch requires the patch in #3086214: Make modal options configurable → in order to apply. Unsure if this is necessary?
I found some more usages of deprecated (and in D10 removed) code.
Works fine on my end? (current version of the 2.x branch)
$ patch -p1 < elastic_apm-drupal_10_compatibility-3391080-2.patch
patching file composer.json
patching file elastic_apm.info.yml
Are you using the 2.x version to apply this to?
Tiny update to the patch - the sub-module now has the same core_version_requirement as the main module, effectively making the patch compatible with D10.
Tiny update to the patch. The entity usage block module now has the same core_version_requirement entry as the main entity_usage module.
Will try to make some time available in the near future to make this a separate contrib module.
Updated patch in #5:
- No longer using the JavaScript states API, logic is now in
/js/frontUi.js(as per comment in #6). - As already mentioned in #3, we could save a lot more vertical space by hiding the selection info if nothing is selected.
Committed + linked to 📌 Compatibility with CKEDITOR5 Active from the project page.
Committed. Thanks!
I suppose we can already apply this (D10 compatibility) and add a "soft" dependency on https://www.drupal.org/project/ckeditor → .
Closing this in favor of 📌 Automated Drupal 10 compatibility fixes RTBC .
Thanks & committed!
Is this issue still present? Which Drupal version are you using? I'm afraid the module is incorrectly advertising compatibility with Drupal 8.
Slightly changed the code & committed. Thanks!
I'm a bit at a loss here, can I get some more info?
Starting with the beta3 release of this module, the ContentModerationInfoBlockForm's constructor contains a call to parent::__construct and its parameters are wrong, causing a fatal error.
This is the call to the parent constructor: https://git.drupalcode.org/project/content_moderation_info_block/-/blob/...
This is the parent constructor: https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...
Looks completely OK to me?
Additionally, there are calls throughout the the form's class to ::setEntity and ::setOperation, which do not exist.
But they do exist on one of the parent classes?
::setEntity : https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...
::setOperation : https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/lib/Drupal/C...
I'm not sure how this issue has not been previously uncovered, I do not see how this could have ever worked.
Which Drupal version are you using - is it Drupal 8? Perhaps this module is not compatible with Drupal 8 anymore.
Adjusted the patch so that the "Drag to reorder"-field description (added in 🐛 Drag to re-order doesn't work without autocomplete Fixed ) is only displayed when re-ordering is not disabled.
Re-rolling patch against 4.2.x + an attempt to implement the proposal in #14.
rp7 → created an issue.
Re-rolled against 8.x-1.15
Small addition to the patch in #94: if one of the endpoints are empty, don't attempt auto login.
Changed
foreach ($client->getEndpoints() as $endpoint) {
if ($endpoint === NULL) {
return FALSE;
}
}
to
foreach ($client->getEndpoints() as $endpoint) {
if (empty($endpoint)) {
return FALSE;
}
}
Re-rolled against current dev.
Re-rolled against 3.x-dev
Re-roll.
Updated patch so that the select options are now sorted alphabetically (similar to the feature request in ✨ Sort target type select options alphabetically Needs review ).