Support for non-node entities, e.g. Media, Commerce Products, Custom 3rd-party entities

Hello,
Scheduler works by making changes to the core node property $node->status. If it's a node it can be scheduled by Scheduler. When you say 'supported' can you expand on what you mean?
Jonathan

I think @muschpusch was wondering if you could schedule panes created with https://drupal.org/project/fieldable_panels_panes.

You can see how this module is used in the https://drupal.org/project/panopoly distro.

They created custom panes(blocks that can be placed in panels pages). For instance, someone might create an linked image pane that could be placed in a sidebar. It would be cool if that instance could be scheduled for publishing.

Those are custom entities though, so I don't think it is currently possible.

Thanks gmclelland for contributing.

Closing this now, as heard nothing back from muschpusch for two months. Please re-open if you want to discuss it further.

Jonathan

I agree that this would be a nice feature to have, but I'm not promising that we will do it. It would need quite a bit of overhaul of how we do things in Scheduler. The db table reorganisation will probably be required, as simply storing a node id may not be enough. If you would like to help, please do, as that will speed up the process. We need information on how the non-node entities are stored in the db, how they are edited and how their display is controlled. I do not even know if fieldable panels have a status equivalent to the node status, so it all needs a bit of investigation.

Setting to postponed for now, as we are not actively working on this, but it may well come back to active later.

Jonathan

This will be feasible when we port the module to D8. We can make this pluggable, provide an interface, and implement the Node use case ourselves.

This is probably something that would warrant an 8.x-2.x release.

I'd probably use the Scheduled Updates module for other types of entity.

Hello! Thanks for the great module. Are there any plans to incorporate the scheduler to media types in addition to nodes? That is a feature request from people at our company and would be fantastic.

Are there any plans to incorporate the scheduler to media types in addition to nodes?

@phandolin, see this issue: Add support for media entities.

While currently work is in progress in #2981703 to add support for media entities it would make sense to make this module support more generic entities as @pfrenssen stated in #6 or we could check for EntityPublishedInterface.

@cobblestone.consulting has started work on this, and we have a new branch https://github.com/jonathan1055/scheduler/tree/2096585-entity-plugin

We have the basics of a SchedulerPluginBase and SchedulerPluginInterface, and are starting to implement these for 'node' and 'media' entity types. It is early days so far, but it looks promising.

We now have a fully operational version of entity type plugins for Scheduler, and have implemented this for 'node' and 'media'. Big thanks to @cobblestone.consulting. There are still things to do but this patch will allow anyone to test the work so far. The pull request is https://github.com/jonathan1055/scheduler/pull/10

@phandolin, @mpp are you able to test this patch and give us any feedback?

Here's an updated patch, which includes the following new work since #12

1. View of Scheduled Media within the Media tab on content admin
2. Support for Devel Generate to add scheduler dates to generated Media
3. Test coverage for Devel Generate Media
4. New permission (dynamically generated, to support future entity-type plugins)
5. hook_token_info() converted to cover all supported entity types
6. Improvements in the plugin annotation and interface
7. Converted 'NonEnabled' exception for all supported entities, with improved message
8. Scheduler admin config form now includes a drop-button for config link for each supported entity type, showing which bundles are enabled

There is still more work to do, specifically in hadling the events that Scheduler dispatches, and how to maintain support for the existing API hooks we provide that are expecting only node entities.

Any feedback on these patches is very welcome.

Patch seems to work great with media - awesome work! Perhaps it is something on my local install, but I did have a bit of a problem installing the patch with composer. Using the dev version the following hunk was rejected and had to be merged manually:

*** 111,134 ****
    $allow_date_only = $config->get('allow_date_only');
  
    // A publish_on date is required if the content type option is set and the
-   // node is being created or it is currently not published but has a
    // scheduled publishing date.
    $publishing_required = $publishing_enabled
-     && $type->getThirdPartySetting('scheduler', 'publish_required', $config->get('default_publish_required'))
-     && ($node->isNew() || (!$node->isPublished() && !empty($node->publish_on->value)));
  
    // An unpublish_on date is required if the content type option is set and the
-   // node is being created or the current status is published or the node is
    // scheduled to be published.
    $unpublishing_required = $unpublishing_enabled
-     && $type->getThirdPartySetting('scheduler', 'unpublish_required', $config->get('default_unpublish_required'))
-     && ($node->isNew() || $node->isPublished() || !empty($node->publish_on->value));
  
    // Create a 'details' field group to wrap the scheduling fields, and expand it
    // if publishing or unpublishing is required, if a date already exists or the
    // fieldset is configured to be always expanded.
-   $has_data = !empty($node->publish_on->value) || !empty($node->unpublish_on->value);
-   $always_expand = $type->getThirdPartySetting('scheduler', 'expand_fieldset', $config->get('default_expand_fieldset')) === 'always';
    $expand_details = $publishing_required || $unpublishing_required || $has_data || $always_expand;
  
    // Create the group for the fields.
--- 120,143 ----
    $allow_date_only = $config->get('allow_date_only');
  
    // A publish_on date is required if the content type option is set and the
+   // entity is being created or it is currently not published but has a
    // scheduled publishing date.
    $publishing_required = $publishing_enabled
+     && $scheduler_manager->getThirdPartySetting($entity, 'publish_required', $config->get('default_publish_required'))
+     && ($entity->isNew() || (!$entity->isPublished() && !empty($entity->publish_on->value)));
  
    // An unpublish_on date is required if the content type option is set and the
+   // entity is being created or the current status is published or the entity is
    // scheduled to be published.
    $unpublishing_required = $unpublishing_enabled
+     && $scheduler_manager->getThirdPartySetting($entity, 'unpublish_required', $config->get('default_unpublish_required'))
+     && ($entity->isNew() || $entity->isPublished() || !empty($entity->publish_on->value));
  
    // Create a 'details' field group to wrap the scheduling fields, and expand it
    // if publishing or unpublishing is required, if a date already exists or the
    // fieldset is configured to be always expanded.
+   $has_data = !empty($entity->publish_on->value) || !empty($entity->unpublish_on->value);
+   $always_expand = $scheduler_manager->getThirdPartySetting($entity, 'expand_fieldset', $config->get('default_expand_fieldset')) === 'always';
    $expand_details = $publishing_required || $unpublishing_required || $has_data || $always_expand;

Hi joel_osc,
Thanks for testing the patch, glad it is all working OK for you so far. Yes the clash is due to a recent commit to scheduler -dev since 25th Jan. You can get an always-up-to-date consolidated patch directly from github /scheduler/pull/10.diff and this should always work fine with the latest scheduler -dev

If you have things to report, you can also join the conversation on the https://github.com/jonathan1055/scheduler/pull/10

Okay, awesome. Thank-you again for your hard work!

Here's an updated patch. There's not much difference to see from the front, but we've been expanding the test coverage for Media, which is vital to demonstrate that everything is working for the new entity plugins.

The big things still not included in this patch are changes to the events that Scheduler dispatches, Rules integration and the scheduler hooks API. All of these are currently expecting only Node objects and will fail if attempted to be used on a Media item. Work is in progress on this, but if anyone else wants to help please shout out.

Strange that patch #17 has one coding standard fault

/var/lib/drupalci/workspace/jenkins-drupal8_contrib_patches-61287/source/css/style.css ✗ 1 more
line 0	Could not read file data. Is the file empty?

The patch creates several new files, all done in the same way as:

diff --git a/css/style.css b/css/style.css
new file mode 100644
index 0000000..c0840af
--- /dev/null
+++ b/css/style.css
@@ -0,0 +1,3 @@
+#scheduler-admin-form > div.dropbutton-wrapper.dropbutton-multiple {
+  width: 25%;
+}

Updated patch:

• Six scheduler events are now fully converted for all entity types
• Six Rules Integration events are done for all entity types
• More test coverage completed

Still to do:

• Rules Integration Conditions
• Rules Integration Actions
• 8 API hook functions

The test failure is in scheduler_rules_integration and it seems the new EventDeriver does not work here. The new events give the error "scheduler:new_media_is_scheduled_for_publishing" plugin does not exist. These are defined by the new lines in scheduler_rules_integration.rules.events.yml

+# Use a deriver to build the corresponding six events for all other entity
+# types that are supported by Scheduler. This will not create any node events,
+# as they need to remain unchanged as above for backwards compatibilty.
+scheduler:
+  deriver: 'Drupal\scheduler_rules_integration\Event\EventDeriver'
+  class: '\Drupal\rules\EventHandler\ConfigurableEventHandlerEntityBundle'

It works fine on the PR on gitHub (at all versions 8.8 to 9.1) and locally. The github tests use Rules -dev but it also works locally with Rules 8.x-3.0.0-alpha6. I don't know what else is different on drupal.org testing to make this not work.

Thanks @jonathan1055 for patch . any plan for next stable release with scheduling support on media?

Hi @nitesh624, No currently I do not have a date planned for the next release, but it will be right after this non-node work is completed. There are still some tasks to do, see my comment in #19. It is annoying that the Rules Integration tests fail on drupal.org as they work fine on GutHub and locally. That will be a blocker, because I can't commit code which fails the testing here. You can follow our progress on https://github.com/jonathan1055/scheduler/pull/10

Creating an issue fork branch works better than the patch. The rules integration code has not changed, but the patch still fails, but the branch test works. So this is how we will proceed from here on.

Just pushed a whole load more commits to this branch. Credit to @cobblestone.consulting for his contributions.

The last commit is an attempt to remove the coding standard error where 'style.css' file cannot be read. This is already covered for code quality using csslint, so it does not need to be read and processed by phpcs.

This is pretty exciting! Really looking forward to having this functionality.

I tried to test this by using the patch in #19.

Am I right in thinking we'll need an update process to add the new database schema and view requirements?

Hi lukus, at the moment I don't think there is a need for an update process. When a user upgrades to the new version of Scheduler the entity plugin should just work. We have base fields defined in hook_entity_base_field_info() and the settings per entity type are all handled via the internal config system. Having said that, it's been a while since I re-tested the process of going from the existing 8.x-1.x source code to the new entity branch, so there may be some things that do need an update hook. I will check that again soon.

You say "tried to test ..." - does that mean that you applied the patch but nothing worked as you expected, or you got errors? Let us know what you found out.

By the way, I probably wont be attaching any more patches here, because the latest patch file can always be generated from the merge request url. Go to https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff and save that file (or reference it directly in a script). Note the file extension on the url has to be .diff not .patch, so that you get a simplified patch with only one change per file, not each individual commit we have made. You can save it as .patch if you need to.

@jonathan1055
Thank you very much - the progress documented here sounds really promising. As I promised two month ago I would like to test your work. So I downloaded a patch file from https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff and tried to apply it locally against latest scheduler-1.x-dev using Composer. Unfortunately Composer throws the error "Could not apply patch! Skipping...“.

Do I guess right that I have to apply the patch manually?

Hi @kreatIL, thanks for the feedback. I have not tried applying the patch using composer. Did you get any specific error? Yes, try applying the same patch manually and see if that works.

Edit: Just tested locally and it seems there is a conflict in the patch for .travis.yml. I will try to fix that, not sure why the patch has that change. It was altered in 8.x-1.x dev already. So for now, download the patch, delete all the hunks for .travis.yml then apply manually. I will get that fixed.

@kreatIL, I have resolved the conflict so the consolidated patch https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff applies cleanly to 8.x-1.x so should be usable now. Don't be put off by the 166 new commits shown above, that's just an outcome of the rebase. The content of the patch is the same apart from the one change to .travis.yml.

Closed then re-opened this MR to get the live preview site following the commit and merge from #3206654: Create live preview via TugboatQA

@jonathan1055, thank you for resolving the confict. I can confirm the patch https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff applies cleanly to 8.x-1.x. This now also works well with composer.

I'm now struggling to get cleanly rid of the Scheduler Media Integration module constructed by this patch: https://www.drupal.org/project/scheduler/issues/2981703#comment-13669545

I will get back here soon.

Thanks @kreatIL, good to hear that it is all working.

Regarding getting rid of the sub-module that you applied from #2981703-18: Add support for media entities what exactly is the problem? If you completely erase your old patched scheduler code, including deleting the unwanted new directory scheduler_media_integration then use the new patch from this MR, then what still remains of the unwanted module?

If you have problems with the site config, have you seen the excellent config_update module? This can give a report by module of all differences comparing source files to loaded config in the site. Then you can easily 'revert to source'

Rebased following the commit on #3167193: Move "Scheduled" menu tab so it's a task under "Content" . Because we already had some of those changes within this branch, I did a rebase to solve the conflicts. Hence the comment above shows 165 commits.

In response to @lukus from comment #27 asking about the update process, I have now added two hook_update functions.

• scheduler_update_8103() ensures that the scheduler fields are added to an entity type after switching/upgrading to the new version.
• scheduler_update_8104() loads the scheduler views and/or refreshes the existing view.

I think these cover all of the upgrade requirements. Both of the functions should work if you had Media already enabled then upgade Scheduler, or if you upgrade Scheduler, then install Media, because the processing is also called from hook_modules_installed()

We are getting near to having this entire work finalised and ready. Please test and let me know how it goes.

@jonathan1055
Regarding getting rid of the faulty sub-module, these are the steps I perform:
1) drush pm-uninstall scheduler_media_integration
2) drush cr
3) remove old patch (faulty sub-module) from repository
4) drush cr
5) Go to page admin/content/media >works fine
6) apply patch from https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff
7) drush cr
8) Go to page admin/content/media >The website encountered an unexpected error. Please try again later.
Error log says: Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.scheduler_scheduled_media.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 208 of /[local_codebase]/web/core/lib/Drupal/Core/Routing/RouteProvider.php).

Hi @KreatIL, thanks for testing and for your feedback.

After you have applied the patch (in 6) and rebuilt the cache (in 7) when you visit the site go to /admin/reports/status and you should see that you need to run /update.php as there are two database updates required, as I said in #38 above. The status report should show the details and then you can run /update.php which will load the missing view, and add the scheduler fields to the media entity type.

Hi @jonathan1055

I've just tried to install the latest version of the patch to Scheduler dev-1.x using the link you've referenced (https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff).

I'm using composer, and it's unfortunately failing.

Gathering patches for dependencies. This might take a minute.
  - Installing drupal/scheduler (dev-1.x 39dec2b): Cloning 39dec2b454 from cache
  - Applying patches for drupal/scheduler
    https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff (https://www.drupal.org/project/scheduler/issues/2096585: Support for non-node entities, e.g. Media)
   Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff

Hi @lukus, that's odd. I have just tried the patch from https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff and does apply cleanly to the latest -dev when checked manually via git apply.

I noticed in your log there was Installing drupal/scheduler (dev-1.x 39dec2b): Cloning 39dec2b454 from cache. The commit 39dec2b454 was from 10 March and there have been a few more commits to 8.x-1.x since then. So the question is why your composer process chose that out-of-date commit. Looking at the history (attached) you can see that there have been more commits since then.

Are there any more details in your log that can help?

Hi @jonathan1055

Thanks for the quick reply! I've updated to the very latest dev release and it's now applying.

I'll test today and let you know the results.

Thanks @lukus, good to hear that after composer update to refresh your scheduler installation it is working for you.

Hit a problem related to use of content moderation. Detailed this here.

While that issue is considered, I'm going to remove media items from our content moderation workflow and retest.

Finally I managed to get it working AND to get rid of the problems described in #39

Everything functioning so far. Thank you very much for your work :-)

I'd like to note some things here that I noticed:
1) "Required" only applies on entities being newly created, but not on entities that already exist. At least from the point of view of my usecase, this makes sense. But I don't know if it might be desirable in other constellations to also apply on existing entities.
2) "Change content creation time to match the scheduled publish time" - This not only affects the content creation time, but also the updated time. I think it might confuse editors if they don't see e.g. a newly created image at the top of the list after saving (Media View: admin/content/media). This is currently the case when the release date is set by them to be in the past.

So much for now. If I notice anything else, I will report here.

Edit: lukus reported an issue about content moderation. In my usecase, content moderation is not activated.

Hi - I can also report success in applying the patch and being able to schedule publishing for a media entity bundle.

Amazing work.

Regarding content moderation;

• The site I'm working on didn't have actions available to publish / unpublish media entities.
• These actions are optional, so in most instances it doesn't cause problems if they're not available.
• With @jonathon1055's assistance I was able to ascertain these were not present - and after importing the relevant config scheduling worked as intended.

Thanks KreatIL for testing. It's good to hear that everything is working working correctly for you. In response to your points

1. The 'publishing required' option applies when creating content, but it also applies when editting content that is not published yet and still has a publish-on date. This maintains the integrity of the 'must be published by scheduler' requirement, and allows editing of other fields and also allows the date to be changed, but not removed. However, after the content has been published and no longer has a publish-on date then the option does not apply. This allows content to be adjusted after it has been published, for example to correct some text, and it does not make sense to have to re-enter a new publish-on date. This behaviour is exactly the same as for node content, there is no change for Media.
2. "The option 'Change content creation time to match the scheduled publish time' not only affects the content creation time, but also the updated time". The updated time is always changed to the scheduled publish time when the content becomes published during cron. But yes, if setting a past date for 'publish-on' and also having the 'publish immediately' option, both dates get set to the entered publish-on value on saving after edit. Again, this behaviour is exactly the same as for node content. Happy to have a discussion about this if you want to raise a separate issue and explain more fully what functionality you would like to be altered.

Thanks again for your feedback. It seems like everything is going OK and I am not aware of any problems or bugs which still need work before we can commit this.

Hi Lukus, great to hear that your testing is going well and its all working.

The Media actions are "optional" in core, but in all cases that I have tested, as soon as the media module is enabled these actions are loaded. However, following our conversation on Slack I have now added a proper exception message and a dblog entry to record the fact that the action is missing and give suggestions on how to recover it. Full details are on #3208551: Action "media_publish_action" is missing. Scheduled publishing halted

Thanks for the work on this feature, it is very useful.
Will it be possible for other modules to write plugins to enable scheduler support.
I had a go with a custom entity, and it seemed straightforward, however I got stuck with the event class, which requires it to be in the scheduler module.

$event_class = '\Drupal\scheduler\Event\Scheduler' . ucfirst($entity->getEntityTypeId()) . 'Events';

Hacking this to point to my custom entities module does work, and publishes and unpublishes as expected.
Maybe something in the plugin defination in a custom scheduler plugin that could declare where the event class was to be found.

 * @SchedulerPlugin(
 * ...
 *  schedulerEventClass = "\Drupal\my_module\Event\SchedulerMyEntityEvent",
 * )

Hi andybroomfield,
That's great that you are looking at using the plugin for custom entities. Yes the ideal solution will be that you should be able to do this, but I am aware that the code as it stands does not cater fully for it yet. Thanks for the pointer about the event class, that is a good idea. Let me know of any other things you find which you can't accomplish without hacking the scheduler code, and we'll work on getting those solved.

Are you on drupal slack? If you join the #scheduler channel https://app.slack.com/client/T06GX3JTS/C01A26AEH7T then I'll be able to discuss with you more directly any changes that are needed to fix the problems you are facing.

Testing the additional functions in production for a week now. Almost every day, Media entites are automatically published or taken offline. No problems occurred so far. Everything seems to work as expected.

Thanks kreatIL, that's good to hear. Just to let you know, the commits since your commit #52 contain nothing major that will invalidate your testing. Most of them are expanding test coverage for Media entities. Apart from tests, the changes are

1. New function to centralise the deriving of the permission name (so that 3rd party modules such as Scheduler Content Moderation Integration can easily check Scheduler permissions per entity)
2. Change to how the latest moderated revision is selected, we had been using a custom Node function that does not exist for Media
3. Remove the redundant hook_uninstall() now that the content scheduled view is automatically deleted when uninstalling

FWIW scheduled transitions supports any entity-type that works with content moderation

@andybroomfield, I have taken your suggestion and added a new property schedulerEventClass to the plugin annotation, to allow you to specify your custom module's location. The default is \Drupal\scheduler\Event\Scheduler{Type}Events to match the existing. Here is the commit

The scheduler hooks now have slightly different names, to allow a proper general/specific naming convention, but for backwards compatibility the original node hooks are still executed. Hence I have removed the idListFunctionplugin property as this is unnecessary, but that should not affect you.

Please test and let me know it goes, because as far as I know there is nothing remaining to do, and it is ready for final testing before committing.

I decided to fix some deprecation warnings for 9.1 and 9.2 within this branch.

Seems to work great on custom content entity, apart from when you do a config import with scheduling a custom content entity enabled.
When enabling the scheduler module, it tries to install a views schema for all enabled content/node types.
For this config, it only looks into the module's own config folder

foreach ($entity_types as $entity_type) {
      $name = 'scheduler_scheduled_' . ($entity_type == 'node' ? 'content' : $entity_type);
      $full_name = $definition->getConfigPrefix() . '.' . $name;

      // Read the view definition from the .yml file. First try the /optional
      // folder, then the main /config folder.
      $optional_folder = drupal_get_path('module', 'scheduler') . '/config/optional';
      $source_storage = new FileStorage($optional_folder);
      if (!$source = $source_storage->read($full_name)) {
        $install_folder = drupal_get_path('module', 'scheduler') . '/config/install';
        $source_storage = new FileStorage($install_folder);
      }
      if (!$source = $source_storage->read($full_name)) {
        throw new \Exception(sprintf('Failed to read source file for %s from either %s or %s folders', $full_name, $install_folder, $optional_folder));
      };
}

Since my custom entity has no config (and especially not in the scheduler module directory), my config import fails each time.

Enabling scheduler in a first deploy and enabling our custom content entity in a second might work, but is not really ideal.

Hi KevinVanRansbeeck,
Thanks for testing, and good to hear that the main functionality is working well for you.

Regarding the config import, yes I can see that's a problem but will be easy to fix. The viewsUpdate() function can be restricted to only update views provided by the Scheduler module and not attempt anything from custom modules. I will work on that right now.

Martin from CobblestoneConsulting has worked on a plugin implementation for the Commerce Product entity. This is a great addition, and only needed a couple of tweaks to the existing work. Credit is also due to New Target, the company who have supported this plugin addition.

@KevinVanRansbeeck I have changed the ViewsUpdate function to only process views for entity types where the provider of the plugin in Scheduler. I replicated your problem and this fixes it, but please test with the latest version to check. Thanks.

@jonathan1055seems to work fine! Thanks!

@jonathan1055 Thanks, I've just managed to check this and so far this is working as expected, using my modules event class without having to hack the module. So far so good and thanks for adding this.

Thank you @KevinVanRansbeeck and @andybroomfield for re-testing and for letting me know both of these changes solved your problem.

Here are some more commits to fully utilise the new Commerce Product plugin. There is now full Rules Integration for products, so that Rules module can be used to react and do things when a scheduled product is published, or a when a product is saved and has a scheduled date.

As far as I know this is pretty much ready to be merged and committed to 8.x-1.x-dev. Then we'll have a period of follow-up to fix anything, and work a few other issues, then I will release 8.x-1.4

Had to rebase this branch due to two recent commits on 8.x-1.x
#2941946: Hide seconds when entering scheduled date/time
#3049134: Publish/Unpublish fields do not have "is empty" and "is not empty" filter operators in views
The consolidated merge_requests/3.diff patch applies to that latest 8.x-1.x dev OK now.

Added full test coverage for Commerce Products

Just wanted to add a quick comment that I'm astonished and amazed at the work that went into this, it seems like a total rewrite of the module to be entity agnostic with bundled support for three entities. One of my coworkers was asking about scheduling changes to Paragraph Library items and this would open up the option to provide that via new plugins they'd have to write, but at least it would be possible. Kudos.

One minor suggestion would be to put this into a new v2.0.0 release instead of into the current 8.x-1.x branch, it seems like too large of a functionality jump & rewrite to become a point release.

Thanks DamienMcKenna, yes it has been a lot of work, but really adds value and expandability to Scheduler. I have made some notes on what is needed for a 3rd-party plugin. I think this should be added to the readme.md file.

Regarding the versioning, I have had mixed feedback. I agree that it is a major re-write as the changes touch so much of the codebase. But apart from the plugin capability there is no new functionality, it just does what we had before. But Scheduler is compatible with D9 so releasing 2.0.0 would mean that the same branch could do both. I do not really want to support a 1.x and 2.x branch, as it is only me doing the maintaining.

On #3150881: Plan for Scheduler 8.x-1.4 release there are many commits to 8.x-1.x so I supposed those could be released as 8.x-1.4 which would be the final 1.x release. Then the plugin work gets committed and I release 2.0. Then those who do not want or need the plugin are not forced to update to 2.0. Is that a reasonable plan?

That sounds reasonable.

Just for context, and the opposite viewpoint, here is the conversation I had on slack:

Q: "Will this feature be in the current main version, or are you planning to make a major release on the module?"

Me: "I don't know yet. Scheduler is fully D9.0 compliant already. I am not sure what I need to consider, to make that choice. If you have any opinions I'd be happy to hear. It could be 8.x-1.4, or 8.x-2.0, or even just 2.0 if we go over to semantic versioning"

Q: "Major versions usually indicate refactoring on the API too. If Scheduler's API stays same and is backwards compatible with previous version, there's no need to make it a major release. When maintainer or developers takes in new major version, it might stop think that is that major version compatible with other modules."

Me: "yes thats good thinking. The API is the same, fully compatible with previous. So having 2.0 may make admins/devs think it is not. Also I would have to maintain 8.x-1.4 and 8.x-2.0 which would be time-consuming and also no real benefit."

Though this was several months ago, before a lot of the plugin work was completed.

I agree, this does seem like a pretty major update that would warrant a 2.x release. Definitely a reasonable plan @jonathan1055!

So, for the actual committing, what is the best sequence for this? Here's my plan:

1. make a new 2.x dev branch, from the existing 8.x-1.x branch
2. change this merge request issue to use 2.x instead of 8.x-1.x
3. check that it all works
4. make one fix to travis.yml in 8.x-1.x due to new deprecation count (this is already fixed in the plugin branch)
5. tag the 8.x branch as 1.4
6. release 8.x-1.4
7. do nothing more on 8.x-1.x dev
8. commit the plugin work to 2.x
9. tag as 2.0.0-alpha1
10. do a bit more testing ...
11. release 2.0.0 when ready

Does this look OK?

Sounds reasonable!

0. tag the 8.x branch as 1.4-rc1 and make a 8.x-1.4-rc1 release [extra, not in list above, done]
1. make a new 2.x dev branch, from the existing 8.x-1.x branch [done]
2. change this merge request issue to use 2.x instead of 8.x-1.x

Manually re-queued a test at 2.x

I have realised that changing the issue branch is not enough. I need to close the MR then open again merging to 2.x not 8.x-1.x

3. check that it all works [done]
4. Fix deprecations and adjust travis.yml (already fixed in the plugin branch) [done]
5. tag the 8.x branch as 1.4 [done]
6. release 8.x-1.4 [done] - see 8.x-1.4 release and #3150881: Plan for Scheduler 8.x-1.4 release

7. do nothing more on 8.x-1.x dev [ok]
8. commit the plugin work to 2.x, i.e. Merge the MR [done]

The testing of the third plugin (commerce_product) exposed a few assumptions about how entities work which were the same for node and media, but different for products. These were simple to fix and I think the whole thing is now fairly robust.

For all the testing and feedback I thank @lukus, @joel_osc, @nitesh624, @kreatIL, @andybroomfield and @KevinVanRansbeeck. But the biggest thank you goes to Martin @cobblestone.consulting who started this whole plugin work, and without whom this would not have got off the ground. It has involved quite an overhaul of the 8.x codebase, but well worth the time and effort I think, for the future of the Scheduler module.

The two hook_update_n functions in this plugin work are named scheduler_update_8103 and 8104. But now that this will only be in the 2.x branch the numbers should be 8201 and 8202. This is according to the latest work on #3010334: Document how contrib hook_update_N() should be numbered now that modules can be compatible with multiple major branches and versioned semantically which is not complete yet.

If any test sites have already run the existing update functions it does not matter if they are run again, nothing will be done.

https://git.drupalcode.org/project/scheduler/-/merge_requests/3.diff. This no longer applies on latest scheduler 8.x-1.x-dev release. It is moved to 2.x
If yes then how can we download 2.x with composer

@nitesh624: Just edit your composer.json - Change "drupal/scheduler": "1.x-dev" to "drupal/scheduler": "2.x-dev" and execute composer update

Thanks @kreatIL.
@nitesh624 Just to be clear, you no longer need to use the patch, as I have commited it all to the new 2.x dev branch.

Thanks for all the effort spent here. There might be scenarios where it's because of dependencies not that trivial to switch to the 2.x branch.

Therefore here a rerolled patch so that it should work with 8.x-1.x again.

@maintainers Could you publish the 2.x branch? Currently it does not appear on the project page. I guess the issue can be marked as fixed as well then?

Hi szeidler,
You're welcome, it's been a good piece of work. Thanks for your interest.

There might be scenarios where it's because of dependencies not that trivial to switch to the 2.x branch

Actually, there are no extra dependencies on the 2.x branch and that will remain the case for the 2.0 release. So anyone wishing to switch to 2.x can do it immediately without any trouble. I specifically created the 2.x branch at the time in the Scheduler development where everything else ready was commited to 8.x-1.x then I released 8.x-1.4 and created 2.x. So essentially the 2.x branch is a simple continuation of 1.x with no extra requirements.

@maintainers Could you publish the 2.x branch? Currently it does not appear on the project page.

I have one issue to finish (#3196989: Rules and Scheduler events should be dispatched after the node is saved, not before ) then I will create 2.0-alpha1 release, as listed in point 9 on #71 above. This will then appear on the project from page and have a direct link to 2.x-dev. I don't think I can 'publish' a 2.x-dev release without tagging it with something. If you want the 2.x dev version now, you can visit https://www.drupal.org/project/scheduler/releases which has them all.

got this error when I installed the 2.x version.

Error: Call to undefined method Drupal\scheduler\SchedulerManager::getPluginEntityTypes() in Drupal\scheduler\SchedulerPermissions->permissions() (line 62 of modules/dev/scheduler/src/SchedulerPermissions.php).

Hi khaldoon_masud,
Can you raise a separate issue for that please? It will be better and easier to track and to help you.

Hei guys, thanks for the great work. I was surprised that the original scheduler only worked with nodes out of the box. How exactly do we get this 2.0 dev version to work with custom entities. In the config, I can only see node and additionally media, how do I get it to recognise the ones I have created? Cheers.

Edit: Does it only work for bundled entities. I tried to implement a plugin, but it seems to require a type suggesting entities need to support bundles/types. Are there other steps that need to be taken?

Hi rockaholiciam,
I have created #3249560: Write documentation for the entity plugin so that we can discuss over there how best to document the new work.

Regarding bundled entity types see #3225695: Support entity types whose entity bundle type does not end with `_type` and entities without created date

Hi jonathan1055, what about entities without any bundles. Does this support such entities? Because a custom entity can be without bundles and in my current project, we have quite a few. Cheers.

Thanks rockaholiciam. Yes after my response I realised you were asking a slightly different question. You have commented on that issue to let's follow it up there, or start a new issue as that one already has a lot going on.

I have updated the I.S. with final steps for completion of this issue.

I have released Scheduler 2.0.0-alpha1 so this issue can be marked as Fixed now. There are some other things to do before 2.0.0 is released - see #3224263: Plan for Scheduler 2.0 release for the latest issues being worked on.

Thank you again to everyone who has contributed here. I listed the main names in comment #77 but a I'd like to thank Martin @cobblestone.consulting again for his excellent work - it's been a pleasure collaborating with you.

#3317999: Set publish_state fields to be hidden by default

After updating to Scheduler ~2.0 the following hook updates drush updb.
They will Add date fields to any newly supported entity types. and on the installation too.

----------- ----------- --------------- -------------------------------------- 
  Module      Update ID   Type            Description                           
 ----------- ----------- --------------- -------------------------------------- 
  scheduler   8201        hook_update_n   8201 - Add date fields to any newly   
                                          supported entity types.               
  scheduler   8202        hook_update_n   8202 - Refresh views for supported    
                                          entity types.                         
  scheduler   8203        hook_update_n   8203 - Update entity fields and       
                                          scheduled view for Taxonomy Terms.    
  scheduler   8204        hook_update_n   8204 - Update Rules actions and       
                                          conditions to use 'entity' context.   
  scheduler   8205        hook_update_n   8205 - Add date fields to any newly   
                                          supported entity types, specifically  
                                          Paragraphs.                           
  scheduler   8207        hook_update_n   8207 - Remove Scheduler fields and    
                                          third_party_settings for Paragraph    
                                          entity types.                         
 ----------- ----------- --------------- --------------------------------------

Should they be managed from the form display? or keep them hard coded?
Not to add the fields to not active scheduler config on old or newly created entities or entity types

Thanks for reporting, but as this is a closed issue let's keep the discussion on #3317999: Set publish_state fields to be hidden by default