- last update
over 1 year ago 261 pass - 🇩🇪Germany osopolar 🇩🇪 GER 🌐
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 🐛 Paragraph does not invalidate parent cache tags if it wasn't published yet Needs work . Did you experience the same? If so, maybe the issue summary should point to that issue.
- last update
over 1 year ago 223 pass - last update
over 1 year ago 61 pass, 30 fail - 🇬🇧United Kingdom jonathan1055
First draft at adding the Paragraph entity type into the full Scheduler test set. May 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.
- last update
over 1 year ago 57 pass, 30 fail - last update
over 1 year ago 57 pass, 30 fail - 🇬🇧United Kingdom jonathan1055
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.
- 🇮🇹Italy Giuseppe87
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. - last update
9 months ago 227 pass 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" }
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)":- Scheduling options are not shown anymore once the node is saved, no matter how the scheduler fields are displayed (Vertical tab / Separate fieldset)
- 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.
- First commit to issue fork.
- 🇩🇪Germany daveiano
I updated the MR to address the issues in #22.
-
The
$display
from hereif (!$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
. - 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 📌 Make #group FAPI / render feature work on all form/render #types out of the box Needs work . I solved this via changing the structure of the fapi elements, see https://git.drupalcode.org/issue/scheduler-3312200/-/commit/b4efce038bc1...
-
The
- 🇩🇪Germany daveiano
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"], ]);
- 🇬🇧United Kingdom jonathan1055
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. - 🇩🇪Germany daveiano
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);
- 🇬🇧United Kingdom jonathan1055
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/ - 🇨🇭Switzerland ruvus Chur
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"];