Yes, catch, with you.
The basic line: now, if we install Drupal Core, then add a node in any way, and delete it, it's gone forever (except if it was saved in the last backup).
We are happy with the current status, it is so nice in Drupal CMS now (Having this space for restoring deleted content) -
Thanks to the Drupal CMS team for pushing for stable data trash management.
Moving to adopt this logic in our products.
I landed on this issue as a part of my research and experimentation to follow up with this logic.
But it has issues with workflows, workspaces, and autosave.
As we worked on:
- 📌 [META] Track 13: Proposal for content publishing workflows Active
- 📌 Create Basic Content Publishing recipe Active
Noticed the move of logic to workspaces.
Having these extra fields in the database tables from the starting point of the site could ease many issues with contribs.
Also, the editorial UX/UI or API CRUD calls for JSON:API endpoints could be safer.
Noted;
Thanks for following up on this issue. As I said, we have a big stack of modules.
I did not change the status of the issue to needs review yet, but you started reviewing. ( Thank you for being on the spot )
For sure, Next time, I will add the Steps to reproduce when filing issues. I thought that when I sat on the final fix, I would add them.
Let's rest this issue. ( We manage a local patching system in all projects, only shared to make it public for search)
We added the Modeler API module to our products. with ECA.
It is the standard for my team to Managing Only Local Patches for Projects
When working with Drupal, it's common to patch core or contrib modules to fix bugs or review code changes before they're officially released. While applying patches via patch files is straightforward, using GitLab's merge request (MR) feature presents a challenge due to unstable diff URLs.
As multiple commits are added to an MR, generating a stable patch file becomes complex. To create a static patch file for an MR at a specific point in time, simply set up a 'patches' folder next to your root composer.json. Download the .diff or .patch into this folder and utilize composer-patches to apply it seamlessly.
Varbase Patches has the list of needed patches for Varbase used packages with Composer Patches.
I attended a number of TUF meetings in the past couple of years and asked Trishank, and Marina about the best options to manage patches, which they listed ( Local Patches, Private/public patching storage - but with stamped key/permittion, or add them in the patches branch )
No PRs/MRs, and you are right about other hosted patches in Drupal.
Better to move all to Local Patches, or private patching storage system.
Varbase has the Drush Command to Clean up Any Merge Request Patches
Drupal CMS switched to use Local Patching system!! too
https://git.drupalcode.org/project/drupal_cms/-/tree/2.x/patches?ref_typ...
https://git.drupalcode.org/project/drupal_cms/-/commit/318f64b7126208d15...
https://git.drupalcode.org/project/drupal_cms/-/blob/2.x/dev.composer.js...
Thanks, Adam, for your work on this.
Noticed that on the spot.
Switching to Drupal Core next Export content method.
The code in Core is very much cleaner, and the Default Content will no longer be needed.
rajab natshah → made their first commit to this issue’s fork.
rajab natshah → made their first commit to this issue’s fork.
Would the Trash → module be added to Drupal Core, or was it settled on only having it in Drupal CMS?
rajab natshah → created an issue.
rajab natshah → created an issue.
Attached a static modeler_api--2025-07-24--3537810--mr-8.patch file, for this point of MR8.
To be used with Composer Patches and Drupal ~11.2.0
Impressive module, by the way (thanks for working on it).
Could a new 2.0.x branch help?
So we don't manage old and new ways within the same codebase.
Drupal ~11.2.0 is doing things a new way, and contrib modules haven't caught up to it yet.
Trying to find a smoother mechanism and method for the update process.
I have a big stack of modules and CIs.
+ multiple languages
For exmaple scheduler, paragraphs, consumer.
Fined out
In Container.php line 147:
Circular reference detected for service "Drupal\Core\Logger\LoggerChannelFactoryInterface", path: "scheduler.manager -> logger.channel.scheduler -> Drupal\Core\Logger\Logger
ChannelFactoryInterface -> logger.syslog -> Drupal\modeler_api\Hook\EntityHooks -> modeler_api.service -> router.route_provider -> cache_tags.invalidator -> plugin.manager.b
lock -> logger.channel.default".
In DefinitionErrorExceptionPass.php line 48:
[Symfony\Component\DependencyInjection\Exception\RuntimeException]
Cannot autowire service "Drupal\modeler_api\Hook\EntityHooks": argument "$modelerApiService" of method "__construct()" references class "Drupal\modeler_api\Api" but no such
service exists. You should maybe alias this class to the existing "modeler_api.service" service.
In DefinitionErrorExceptionPass.php line 48:
[Symfony\Component\DependencyInjection\Exception\RuntimeException]
Cannot autowire service "Drupal\modeler_api\Hook\EntityHooks": argument "$modelerApiService" of method "__construct()" references class "Drupal\modeler_api\Api" but no such
service exists. You should maybe alias this class to the existing "modeler_api.service" service.
Still testing the first draft fix with AI
rajab natshah → created an issue. See original summary → .
rajab natshah → changed the visibility of the branch 3.0.x to hidden.
✅ Released varbase_core-10.0.50 →
✅ Released varbase_core-10.1.52 →
✅ Released varbase_core-10.1.52 →
✅ Released varbase_core-10.1.52 →
Not to enable any ECA modules in the 10.0.x branch
I agree, it was not changed after forking.
The name of the file DrimageImprovedServiceProvider.php and class name!
Thank you :)
I see it now
grep -r "DrimageStageFileProxySubscriber" .
./docroot/modules/contrib/drimage_improved/src/DrimageServiceProvider.php:use Drupal\drimage_improved\EventSubscriber\DrimageStageFileProxySubscriber;
./docroot/modules/contrib/drimage_improved/src/EventSubscriber/DrimageStageFileProxySubscriber.php:class DrimageStageFileProxySubscriber implements EventSubscriberInterface {
./docroot/modules/contrib/drimage_improved/src/EventSubscriber/DrimageStageFileProxySubscriber.php: * Constructs a new DrimageStageFileProxySubscriber.
Drupal 11.2 || 10.5 or <=11.1 || <=10.4
Do we need a new branch to manage that?
rajab natshah → created an issue.
✅ Released varbase_ai_default-1.0.2 →
✅ Released varbase_ai_default-1.0.2 →
rajab natshah → created an issue.
rajab natshah → created an issue.
Do we need the token module for [date:custom:Y]-[date:custom:m]?
Or just Drupal Core only
✅ Released drimage_improved-1.0.8 →
✅ Released drimage_improved-1.0.8 →
Thank you, Andreas, for filing and the MR for this issue.
Facing the same issue