🇨🇦Canada @joel_osc

Tested latest dev and it works great!

Oh cool, that is a nice approach! I will give a test. Thank-you!!!

Here is a patch that seems to fix the issue.

joel_osc → created an issue.

In NodeRevisionDelete.php:

**
* {@inheritdoc}
*/
public function getCandidatesRevisions(string $content_type, int $number = PHP_INT_MAX): array {
// @todo check if the method can be improved.

If you can find a way to configure / patch the node_revision_delete module to keep published revisions then we can shut down this module.

Cheers.

Awesome, thank-you kindly!

Here is a patch that fixes the issue.

joel_osc → created an issue.

Did you add and enable the module better_normalizers?

Great patch everyone! Necessary on my site in order to use this module. I noticed that some nodes could not be found by alias, in looking at it I found the queueing code was storing paths that it had already done and checking that before queueing. They key the code used did not have the langcode of the path so I was only getting each node in one of two languages. Small fix committed above.

joel_osc → made their first commit to this issue’s fork.

The node_revision_delete module is a really great module, this module applies a lot of the same logic. The difference is that this module is content moderation state aware, so you can do things like only delete non-published historical revisions. 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).

Cheers!

Massive one line patch here. :)

joel_osc → created an issue.

Okay, sounds great. An example would be if a user wants to export nid's 10,15,23 and all of the taxonomy references, media references with them but not the node references because they don't want any other local node updates exported other than 10,15,23. In this case you would want the ability to export nodes, but not any referenced nodes. Does this make sense?

Hi and thank-you for your work on the module!!!

I think this patch is different than the --skip-entity-type option in that it is add the ability to skip referenced entities by type. Our business requirement is that no referenced nodes are exported. I think, but am not 100% sure, that if we use --skip_entity_type=node then we wouldn't get any nodes at all? Cheers!

Patch looks good, worked for us in an odd situation the $url->access() properly failed on the French version of a custom page so the fr key was properly removed from the $link array.

Ran into this exact issue and it was as a result of the message_subscribe module... grabbing the latest dev version of it fixed the problem. This line here: #9 /var/www/html/ehss_stage/web/modules/contrib/message_subscribe/message_subscribe_email/message_subscribe_email.module(24): Drupal\flag\FlagService->getAllEntityFlaggings() in the stack trace indicates this as well. Basically the message_subscribe_email code was not checking whether or not the $flagging entity was complete before trying to get all flaggings, so on a new node you would get this error. The maintainers has since added a check for $flagging->id() before getAllEntityFlaggings() now which prevents the issue.

++1, we have more than one client requesting this feature.

Here is a patch that fixes the issue.

joel_osc → created an issue.

Just ran into this problem, patch in 139 fixed it for me! Thank-you @budalokko and @TR!

Agreed, this is really complex. On sites that use moderation we started using this module: https://www.drupal.org/project/scheduled_transitions → which works well. Maybe best thing to do would be to put a note on this project stating it that content moderation is not supported? Then this issue can be closed off.

Here is a patch that just mimics what core RSS style does, not sure if this is correct but it does seem to fix the issue.

joel_osc → created an issue.

Fixed long comment line... thx!

Not sure what happened to the first patch, here is a properly formatted one.

Here is a patch that will invoke the filters prior to linkchecking.

joel_osc → created an issue.

Sad to see you go, I have been an admirer of your contributions and work in the Drupal community for many years. Best of luck and I am sure if things change for you the community will always welcome you back with open arms.

Here is a patch that adds this functionality.

joel_osc → created an issue.

Patch is confirmed working on multiple sites... rbtc.

Awesome, thank-you!

Here is a patch that implements the translatable configuration. Cheers!

joel_osc → created an issue.

Patch works perfectly, +1 RBTC. Thank-you all.

Thanks @joseph.olstad, appreciate you bringing this to our attention!

joel_osc → created an issue.

Withdrawing this issue, code is working as designed. In case anyone else sees this error in php8.1 you may want to look at your twig and add a check to see if the field value is empty before rendering a "Text (formatted, long)" field in this manner:

  {% if not node.field_my_textarea.value is empty %}
      {% set my_processed_text = {
        '#type':   'processed_text',
        '#text':    node.field_my_textarea.value,
        '#format': 'rich_text',
      } %}
      {{ my_processed_text }}
  {% endif %}

Cheers!

Withdrawing this issue, code is working as designed. In case anyone else sees this error in php8.1 you may want to look at your twig and add a check to see if the field value is empty before rendering a "Text (formatted, long)" field in this manner:

  {% if not node.field_my_textarea.value is empty %}
      {% set my_processed_text = {
        '#type':   'processed_text',
        '#text':    node.field_my_textarea.value,
        '#format': 'rich_text',
      } %}
      {{ my_processed_text }}
  {% endif %}

Here is a patch that fixes the issue.

joel_osc → created an issue. See original summary → .

Here is a patch that fixes the issue.

joel_osc → created an issue. See original summary → .

Here is a patch.

joel_osc → created an issue.

Also as an FYI we are experiencing performance issues due to revisions and wanted to use the well-written node_revision_delete module, but found that not only was multilingual problematic, things got worse with content moderation and trying to ensure that you don't prune forward revisions. Also, we had a requirement to preserve all historic 'published' revisions in all languages. We have contributed this module: https://www.drupal.org/project/cm_revision_delete → to help meet these requirements. Cheers!

Here is a patch that adds that cache invalidation. Cheers!

joel_osc → created an issue.

I have tested the above patch and it seems to work. I would like at least one more set of eyes on it before bringing it in so i will leave this as needs review for now. Thanks everyone for all of your work.

Attempt #2, fixing missing DevelForm.php in previous patch.

Re-rolling this patch because it does provide some nice functionality, but removing the changes to cm_revision_delete_get_latest_default_revision as from my testing the previous code was working properly and the new code was definitely broken.

We are using this feature now provided by facets out of the box without any contribs. I would recommend looking at what facets provides for date hierarchy and see if this module is now redundant or still provides added value.

FYI - the code in #66 is againt 7.14 and I have tested it and it seems to work great! Thanks @freelock.