Support for block content entity

MR created.

I have update some tests by searching for occurrences of Media.

In previous comment is attached screenshots showing the result.

Thanks a lot for the service to update entity definition, really helpful.

I guess there will be other stuff to update, tests?

I tested the fork, but the only way that I could get this to work properly was to also enable the content moderation workflow and add a content block type to the workflow. I'm assuming this is is related to ✨ UI for publishing/unpublishing block_content blocks Needs work because blocks don't expose the publish status checkbox and are always published. Am I correct in this assumption and setting this up or did I miss something somewhere?

Hi,

I have retested on a fresh Drupal install (10.3, standard profile).

I have applied patch from MR then enabled the module and I confirm that I was able to enable scheduling features on the basic block type without needing to have the Content Moderation module.

@r0nn1ef after checkout the fork, did you have the Scheduler module already enabled? If yes, have you executed the update?

Thanks for your work on this, it looks promising. It will need full test coverage, and I have attached some notes I wrote the last time I did a new plugin (taxonomy term). You can check what you've done, and then also add the test steps. When you have some basic test entity, push it to the MR and we can see how many of the tests may need adjusting. Each time a new entity plugin is added there are always tweaks/additions to the test set-up.

It would be good if this document was available within this project, ready for use by anyone. I will see what options there are for doing that.

Thanks for your reply.

I will give a look at the document.

Great document!

I have added and fixed stuffed based on it. Not tested.

I have one question, I put in MR code review.

And here are feedbacks I noted along the changes.

Step 3:
typeFieldName is not mandatory.

Step 4:
This entire step is already covered by SchedulerPluginBase.

Step 6:
Why not creating a new schema type for the default third party settings, and so it can be reused without YAML aliases?

Step 11:
nothing to do in scheduler.routing.yml

Step 19:
+ copy SchedulerBasicMediaTest?

In the document nothing is said about copying methods like the following for the new entity type:
- scheduler_extras_query_scheduler_media_publish_alter
- scheduler_api_test_scheduler_media_list
Is it something forgotten or not needed?

Thanks for using the document and for the feedback. I wrote that a while ago, and there have been some changes to the plugin and process since then, but I did not re-visit the document, so it is great that you have gone through it.

• Step 3 - you are right 'typeFieldName' is not mandatory.
• Step 4 - I think you are right, there are no implementations of these functions in the four plugins so far. Maybe I was thinking that a new entity type might need a custom one, but I can remove that step until proven otherwise.
• Step 6 - Would you like to do that, and propose the change here so I can see how it works.
• Step 11 - Yes this can be removed. Previously there were changes necessary, but #3224340: Hardcoded local task dependency on view scheduler_scheduled_content → removed this and made it automatic.
• Step 19 - yes we need a new SchedulerBasic{Type}Test.php

I will take a look at scheduler_extras_query_scheduler_media_publish_alter() and scheduler_api_test_scheduler_media_list() and get back to you.

The progress on tests is good. Now that the linting jobs pass, I will make a change skip those jobs and opt out of the variant testing. No point in wasting resources until the actual phpunit tests pass.

Hi,

I am still working on the tests to pass.

I will unassign when finished :)

Ok, I saw the small commit, thank you!

This is it for me.

I fixed all I could fixed.

Changes in config schema done.

I let you review in case some skipped case should be reworked and also for the point I didn't know what was to be done.