But you need to check the status (as you do in your patch) too juste before deleting it. An order can be locked after being added in the queue expiration
Hello. Better to do this at the query level no ?
In the commerce_cart.cron service
protected function getOrderIds($order_type_id, Interval $interval) {
$current_date = new DrupalDateTime('now');
$expiration_date = $interval->subtract($current_date);
$ids = $this->orderStorage->getQuery()
->condition('type', $order_type_id)
->condition('changed', $expiration_date->getTimestamp(), '<=')
->condition('cart', TRUE)
->range(0, 250)
->accessCheck(FALSE)
->addTag('commerce_cart_expiration')
->execute();
return $ids;
}
Youhou ! My older issue I believe :-) Thanks !
Committed. Thanks.
This patch should resolve this issue.
Patch done on /2.x-dev / 2.1.0 version.
Could you give a try ?
Thanks everyone. Committed.
flocondetoile → created an issue.
This module uses the node access system. So it can only control access to node, not on others entity types, as media.
I 'don't understand the issue reported. Need reformulation and/or actionnable elements.
There is already a patch in 📌 Automated Drupal 11 compatibility fixes for pbf Needs work and it looks nobody has test it yet.
You can write your own custom field widget for the pdf field and use it instead of the default one provided.
May be you just don't need this module if it don't meet your need.
Without error message we can't do anything. Please provide more actionnable elements about this crash.
flocondetoile → created an issue.
This module should not altering this behavior. It's not its responsabilities to add the user.roles context for local action links. Your fix does the job, but doesn't fix the root cause I think. The best way would be (perhaps) to stop overriding route.route_provider and start using addExtraCacheKeyPart() (as domain did it see https://www.drupal.org/project/domain/issues/3359253 ✨ Use core route provider with addExtraCacheKeyPart for route caching? Needs review ).
But is this override which is the root cause ? What happens if this module stop to override the Class of the router.route_provider service ?
No. Already on it...
What impact of such change if content_moderation is not enabled on a project with micro_site ?
I don't understand why micro_site is involved with the /admin/content page (it only provide site entity and related features, and don't change change the node behaviors). This module don't change this page, and don't change any permissions. You should have same bug without micro_site enabled ?
MR11 is not mergeable.
Also you changed the entity type definition for the Site entity.
So you need to update this definition too for existing sites, with a hook_update_N. See https://git.drupalcode.org/project/commerce/-/blob/3.0.x/modules/order/c... (commerce_order_update_8210()
) as an example.
flocondetoile → created an issue.
Hope the module works fine on D11, as you tell here. I didn't test it on D11 yet.
The new release is coming
So I close this issue. Anyway I plan to release a D11 compatible version of the module soon.
flocondetoile → created an issue.
There's no hurry. It can wait if other small bug fixes crop up soon. I'll let you decide.
Yes. Thanks. Forgot there is the 3.1.x branch
flocondetoile → created an issue. See original summary → .
flocondetoile → created an issue.
Thanks for the reminder
Another patch with the value TRUE for TemplateLanguage this time.
Given the doc (https://dev.mailjet.com/email/guides/send-api-v31) not sure the value of the TemplateLanguage should be the language id, but instead just the value TRUE ?
Does this patch fix your issue ?
Hello. Thanks for reporting and the patch. I'll commit it with a slight change.
flocondetoile → created an issue.
flocondetoile → created an issue.
flocondetoile → created an issue.
Looks good and fix the issue
Hello,
Just updated Gin.
Looks like the value of
$widget_type = $form['status']['widget']['#type'] ?? FALSE;
is alsways false in my case.
Because the #type to check is in $form['status']['widget']['value']['#type']
and not in $form['status']['widget']['#type']
.
And so the status checkbox doesn't go into the gin sticky actions / status container.
Am I alone ?
A field formatter is not in the scope of this module. It's not the right way to support this.
No thanks. I should manage it, I think.
There is a parameter in simplenews.settings.yml named "hash_expiration" which is hardcoded with 86400 value (so 24h).
This settings expires subscribe / unsubscribe links sent in a newsletter.
This parameter is not configurable in the settings UI.
I guess that make this setting configurable would allow to set the period after which the links are not valid anymore. But 24h (the default value) seems really short for newsletters.
A simple workaround is to change this settings in the config file, and then reimport this configuration (drush cim).
It's because you have request one time the -dev version of the module. So composer search always for the .git directory. Simply run composer remove drupal/toc_js and then composer require drupal/toc_js ^3.0 and you then will fetch the tarball version.
flocondetoile → created an issue.
flocondetoile → created an issue.
flocondetoile → created an issue.
Not sure this is the job of this module. Should be more relevant to improve form ids for view exposed form no ? And to have, as for node form for example, a base form id (the current one) and a specific form id for the given view. But this is a core issue.
Hello,
Could you be more explicit on the why "The module should update the composer dependencies to support html2text/html2text (^4.3.1)" ? Did you encounter conflict ? You just want the latest version of the lib ? Other reason ?
I just want to have more context.
flocondetoile → created an issue.
Looks good and works fine.
I guess you choose to apply a scroll-margin-top to each heading of the TOC, instead of a global scroll-padding-top to the html element (and so simpler), because it's let us more control to vary (if needed) this behavior per heading (via theme or other magic css) ?
Hello @netsilver,
The "only" D10 compatibility patch for this module doesn't really make sens, as simple_sitemap module is compatible D10 with its 4.x version. And 4.x version is a major rewrite (again) of the module. So this module needs too to have a major rewrite to be compatible with 4.x version of simple_sitemap.
I am a bit tired of theses successives major rewrites for each major version of simple_sitemap module. I don't want rewrite this module to be compatible with 4.x version, and then have to rewrite it again in a few years to be compatible with the next 5.x version. If you want do it I can give you maintener access.
If this module must be rewrite again, I want to do it without any dependencies on any others modules. In others words, the next major rewrite of this module (if it happens one day) would be a module which generates for each microsite a sitempap.xml in an independant way.
flocondetoile → created an issue.
Need to know which field generate this issue. Please provide steps to reproduce this error.
Nice. My TOCs are now fixed.
Yes thanks
as a dirty fix, this resolve the case
diff --git a/assets/js/tocjs.js b/assets/js/tocjs.js
index 443728a7cf..7c3af11e05 100644
--- a/assets/js/tocjs.js
+++ b/assets/js/tocjs.js
@@ -385,6 +385,15 @@
lastLi = li;
currentLevel = level;
}
+ else {
+ const ul = document.createElement(opts.listType);
+ currentLevel = level;
+ ul.level = level;
+ ul.appendChild(li);
+ lastLi.appendChild(ul);
+ currentList = ul;
+ lastLi = li;
+ }
});
}
But defaulting to level 1 is good.
flocondetoile → created an issue.