This is a follow-up from #3259200: [REVERTED] Plugin to support Paragraph entity type which added plugin support for Paragraph entity types, but had to be reverted.

Steps to test with Paragraphs

  1. Install the module: composer require drupal/paragraphs && drush en paragraphs -y
  2. Create a paragraph type through Structure > Paragraph types > Add Paragraphs Type, and enable Scheduler as you would with node types. Add at least one field to the paragraph type
  3. Create a node type and add a field of type Reference revisions / Paragraph
  4. Add the field, use default reference method, tick 'include the selected below' and tick the paragraph type
  5. Create a node of the type with paragraphs. Set the scheduler dates as usual and test with Cron
  6. Edit the node, change dates and test again, etc ...

Tasks done

  • Define the paragraph plugin
  • Define the paragraph events
  • Add schema for third-party-settings
  • Do not show "modify created time" option if that functionality is not available
  • Process hook_form_alter when the node is being editted, achieved using hook_field_widget_complete_paragraphs_form_alter()

Still to do

  • Process hook_form_alter when adding a new node which contains paragraphs
  • Move the scheduler publish_on and unpublish_on fields into the parent 'scheduler options' group in the paragraph edit form
  • Automatically disable the scheduler fields in form display if the paragraph type is not enabled for Scheduler
  • Add test coverage

Here is the documentation on how to write a Scheduler plugin and provide test coverage https://project.pages.drupalcode.org/scheduler/plugin/

Issue fork scheduler-3312200

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

Zevarix created an issue. See original summary.

zevarix’s picture

Component: Scheduler Rules Integration » Plugin
Priority: Major » Normal
zevarix’s picture

Issue summary: View changes
jonathan1055’s picture

Hi Zevarix,
Thanks for reporting this, and uploading the screen shots. The two fields always appear on the admin 'manage form display' page, as they are automatically defined for the entity bundles that are supported by Scheduler (this is not ideal but that's how it has been done).

When you actually create or edit a paragraph they should be hidden/disabled on the edit form if the paragraph type is not enabled for Scheduler. But I have just tried this locally and the scheduler fields are not hidden. So yes this is a problem. It is probably because the paragraph form structure is diffent from how the other entity types are laid out, so Scheduler's attempt to hide the field fails.

I will look into how it can be fixed.

jonathan1055’s picture

Issue summary: View changes
Status: Active » Needs review

All of the form manipulation (hiding fields, setting defaults, adjusting the 'required' setting, etc) are done in Scheduler's _scheduler_entity_form_alter which is normally called from the standard hook_form_alter(). However, this does not automatically cater for the referenced paragraph entities because it is only the top-level node (or media or product) which goes through the hook_form_alter. So none of those settings and options were being applied to paragraphs.

The paragraph widgets can be altered via hook_field_widget_complete_WIDGET_form_alter() and from within this we can get all paragraph entities and for each one we can call the existing _scheduler_entity_form_alter on the sub-form. I have made this addition in the merge request above.

This may not be the final solution, and more work is required, but this does now respect the majority of the scheduler settings for the paragraph type. Things that do work: enable/disable for scheduling, require publishing/unpublishing, allow date only with default time, hide seconds, publishing advanced options, hide scheduler message.

Things that do not work yet, or may not be applicable for Paragraphs: Change creation time to match publish time, choice of vertical tab/fieldset, auto-expand fieldset. Also I have not checked how the 'create new version on publishing' interacts with how Paragraphs are updated.

Please can you test this, and let me know how you get on. If you require a patch file use the plain diff link for mr61 in the MR box.

jonathan1055’s picture

Paragraphs do have a getCreatedTime() method, but not a setCreatedTime() method. It is the setCreated which Scheduler uses to modify the time, so the check needs to be on that method. All supported entity types so far have had both methods or neither of them, so it did not make any difference.

jonathan1055’s picture

Title: Scheduler not enabled on Pargraph bundles, yet fields still appear » Paragraph scheduler plugin
Version: 2.0.0-rc5 » 2.x-dev
Issue summary: View changes
Parent issue: #3259200: [REVERTED] Plugin to support Paragraph entity type »
Related issues: +#3259200: [REVERTED] Plugin to support Paragraph entity type

Now that the original plugin definition has been removed in #3259200: [REVERTED] Plugin to support Paragraph entity type this issue will re-add those files and we can work on fixing the other problems. This will not be in the intial release of Scheduler 2.0 (unless someone finds a good solution really quickly).

jonathan1055’s picture

Issue summary: View changes

Added test steps.

dieterholvoet’s picture

Issue summary: View changes
Status: Needs review » Needs work

This doesn't work for me. Seems like _scheduler_entity_form_alter is not triggered from scheduler_field_widget_complete_paragraphs_form_alter. I created a new paragraph type with a field, didn't enable scheduling, but the scheduling fields are still appearing.

dieterholvoet’s picture

The problem is that the field item list contains empty field items without entities when the hook is called, which means that ->referencedEntities() returns an empty array. I know this was working before because I have a bunch of hook_field_widget_single_element_form_alter implementations in this project and they are encountering the same problem. Are you using the latest Drupal core & Paragraphs versions? Maybe something broke in a recent version of one of those two.

jonathan1055’s picture

Hi @DieterHolvoet

I am using the latest core 9.5 dev and latest paragraphs, and cannot replicate your problem.

#12 you said "didn't enable scheduling, but the scheduling fields are still appearing"
This was fixed in #3320341: Disable fields in form displays by default and I wrote a hook_update function to amend any existing configs. So I do not know why you are getting this problem. Are you sure you have the latest scheduler dev, before patching? Or are you using the issue branch of this MR directly?

In #13 you say "field item list contains empty field items without entities when the hook is called"
The _scheduler_entity_form_alter() is called when an existing node with paragraphs is editted. But it is not yet working on first creating a new node. Look at the Still to do list in the issue summary, you'll see that this work is not complete yet.

jonathan1055’s picture

The rebase above should not have affected anything in the paragraph testing. The commits from #3320341: Disable fields in form displays by default were already merged in here on 19th November

osopolar’s picture

Thank you @jonathan1055 for working on this.

What about caching? I saw the issue: Paragraph does not invalidate parent cache tags if it wasn't published yet. Did you experience the same? If so, maybe the issue summary or some other prominent place should point to that issue to make developers aware of that issue.

The Todo list (Still to do) says:

Move the scheduler publish_on and unpublish_on fields into the parent 'scheduler options' group in the paragraph edit form

This should be optional or maybe also additional. Adding more and more paragraphs having scheduler options to the entity, the parent's 'scheduler options' group may quickly become overloaded.

dieterholvoet’s picture

I rebased against 2.x.

jonathan1055’s picture

Category: Bug report » Feature request
Issue summary: View changes

First draft at adding the Paragraph entity type into the full Scheduler test set. Many tests fail and there is lots of work to do. Some of it I don't know how to test, because the paragraph entity process is quite different from Node / Media / Commerce Product / Taxonomy.

jonathan1055’s picture

Hi DieterHolvoet,
Thanks for looking at this again. When does that error show? It has not been mentioned yet in this thead.

I think the approach to phpunit testing will have to be different from the normal plugin tests. The structure of a paragraph entity within a node/other entity is different from the usual node/media/product/term and I can't see a simple way to get all the failing tests to work. I'd like to hear if anyone has some good ideas. We need fairly full test coverage if the plugin is going to be added into Scheduler.

giuseppe87’s picture

Hi, I've tried this patch but I'm facing several problems\errors.

I also replicated them on a clean Drupal 10 instance with just paragraphs, scheduler and ultimate_cron as contrib modules.

1. I can see the "scheduler" fields on the paragraph add form; those fields however are missing in the edit form of an existing one.
2. When running the cron, I get the error "Drupal\Core\Entity\Query\QueryException: 'publish_on' not found in Drupal\Core\Entity\Query\Sql\Tables->ensureEntityTable() (line 369 of /var/www/html/web/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php)." and the paragraphs aren't actually published.
On the other hand, if I set the option "Action to be taken for publication dates in the past" as "Publish the Paragraph immediately after saving", the paragraph is published on form submit.
3. It's possible to submit the form with the (un)published field empty, even in the case it was set up as required.

franc0205’s picture

Hi, after the latest update on this patch it seems to have an issue with composer

- Applying patches for drupal/scheduler

    https://git.drupalcode.org/project/scheduler/-/merge_requests/61.diff (Support paragraphs in scheduler)
   Could not apply patch! Skipping. The error was: The process "patch '-p0' --no-backup-if-mismatch -d 'web/modules/contrib/scheduler' < '/var/folders/fz/70t6kvv90g9g9p6n0f_xk8rc0000gq/T/6646c6a1eb12f.patch'" exceeded the timeout of 300 seconds.

In Patches.php line 331:

  Cannot apply patch Support paragraphs in scheduler (https://git.drupalcode.org/project/scheduler/-/merge_requests/61.diff)!

Here's how I apply the patch in composer.json:

"drupal/scheduler": {
               "Support paragraphs in scheduler.": "https://git.drupalcode.org/project/scheduler/-/merge_requests/61.diff"
     }
misterdidi’s picture

Latest patch applied successfully for me on D10 with Scheduler 2.0.3 (tested with dev branch as well).

The main publish/unpublish workflow is functional but I noticed some issues with the admin UI:
As per comment #20 - point 1, it is with "Paragraphs (stable)" form display widget that the publish/unpublish date fields disappear once the node is saved.
With "Paragraphs (stable)":

  1. Scheduling options are not shown anymore once the node is saved, no matter how the scheduler fields are displayed (Vertical tab / Separate fieldset)
  2. If the node itself has scheduling options, the paragraphs scheduling sections are displayed but empty, either above the node scheduling options section ("Vertical tab" display, see attached screenshot for example) or in the paragraph edition section ("Separate fieldset" display) and each paragraph displays scheduling fields according to node scheduler configuration (i.e. If node is configured to use scheduler for "Publishing" only whereas Paragraphs are configured for both "Publishing"/"Unpublishing", only "Publishing" field will be shown in paragraphs.

With "Paragraphs Legacy" form display, none of the above happens and everything works well.

daveiano made their first commit to this issue’s fork.

daveiano’s picture

I updated the MR to address the issues in #22.

  1. The $display from here
    if (!$display = $form_state->getFormObject()->getFormDisplay($param)) {
      return;
    }
    

    is not the actual form_display of the paragraph, it is the display of the parent node (at least when editing a page with an entity_reference_revisions field - I guess for the paragraphs library it's not the case). I solved this by getting the display from the storage in _scheduler_entity_form_alter.

  2. The grouping seems not work in the context of paragraphs. For me, it was adding an empty details element with the publish_on and unpublish_on fields underneath. This could be related to #2190333: Make #group FAPI / render feature work on all form/render #types out of the box. I solved this via changing the structure of the fapi elements, see https://git.drupalcode.org/issue/scheduler-3312200/-/commit/b4efce038bc1...
daveiano’s picture

Another change on scheduler_field_widget_complete_paragraphs_form_alter:

$paragraphs = $context['items']->referencedEntities(); does only get the already saved paragprahs, If you add a new paragraph to the form, _scheduler_entity_form_alter won't be called, since $paragraphs = $context['items']->referencedEntities(); only gets the already created and saved items.

I solved this (very dirty) by creating a new, temporary paragraph:

$entity = $paragraph['target_id'] ? Paragraph::load($paragraph['target_id']) : Paragraph::create([
  'type' => $field_widget_complete_form["widget"][$key]["#paragraph_type"],
]);
jonathan1055’s picture

Hi daveiano
Thanks for working on this. The merge request pipeline failed probably because the branch is 64 commits behind 2.x as no one has been keeping it up to date. You can try a rebase, by entering /rebase as a comment in the MR. If that does not work, you will need to merge locally and push.

daveiano’s picture

Hi @jonathan1055

I did the rebase locally, but Pipeline is still failing (phpcs and phpstan tasks).

The MR still needs work, especially this part causes me headaches:

$entity = $paragraph['target_id'] ? Paragraph::load($paragraph['target_id']) : Paragraph::create([
  'type' => $field_widget_complete_form["widget"][$key]["#paragraph_type"],
]);
_scheduler_entity_form_alter($subform, $form_state, '', $entity, $form_display);
jonathan1055’s picture

Issue summary: View changes

Thanks daveiano,
I pushed one change to address a comment in the MR. I have not kept up to date with the Tasks done and Still to-do as listed in the issue summary.

Another thing we've not discussed is whether this plugin would be part of the Scheduler codebase or added to the Paragraphs project. If it is stored in Scheduler then there is a much bigger overhead/barrier to getting it committed because I would want full test coverage. Currently this MR provides no test coverage at all for the new plugin, so we have no firm idea how well it performs.

I am writing documentation on how to provide a new plugin and test coverage - see #3249560: Write documentation for the entity plugin
The pages are here - https://project.pages.drupalcode.org/scheduler/plugin/

ruvus’s picture

I encountered an issue where the Paragraph Library forms throw an error if field_modules is not present in the form state.

I was able to fix the error by adding a check to verify if field_modules exists before proceeding. Here is the code snippet I used:

if(!isset($form_state->getStorage()["field_storage"]["#parents"]["#fields"]["field_modules"])){
    return;
}
$form_display = $form_state->getStorage()["field_storage"]["#parents"]["#fields"]["field_modules"]["paragraphs"][$key]["display"];

duncancm made their first commit to this issue’s fork.

daveiano’s picture

I encountered an issue where the Paragraph Library forms throw an error if field_modules is not present in the form state.

@ruvus The field_modules is a mistake which I introduced.

field_modules should be the actual field name of the paragraphs field.

qzmenko’s picture

didebru’s picture

MR needs to be updated it does not apply as patch against 2.2.1

eelkeblok’s picture

I am currently testing this. I think the option of showing the planner options in a vertical tab needs to be removed fort paragraphs, as it has the effect of completely hiding the scheduler options (also, if it didn't, it still does not make sense in this context).