backdrop-contrib / paragraphs

Paragraphs module to control your content flow
https://backdropcms.org/project/paragraphs
GNU General Public License v2.0
5 stars 11 forks source link

Page Preview Not Working #136

Closed stpaultim closed 3 days ago

stpaultim commented 2 years ago

I've just noticed that the node edit PREVIEW button does not seem to be working with my paragraphs.

Is this is known limitation of Paragraphs (if so, is it documented anywhere for folks like me to find) or is this a bug?

Or am I just doing something wrong.

image

argiepiano commented 2 years ago

Can you describe "not working" in more detail please? How to reproduce?

sudipto68 commented 2 years ago

We are using different paragraph types for our content and they work perfectly when we Save and View the page but if we try the Preview button there seen nothing on that Preview page. In Simple, Paragraphs are not working on the Preview page.

stpaultim commented 2 years ago

As @sudipto68 reported. If I click on the preview I see the page title and the blocks that appear below the page content, but the page content is not visible at all - there is no preview of the content contained within the paragraphs on that page.

argiepiano commented 2 years ago

@laryn and @stpaultim, I've done a bit of debugging on why the Preview button doesn't show the Paragraph fields in a node.

So, in Backdrop, Paragraphs implements hook_field_prepare_view() (in file paragraphs.field_formatter.inc). I don't know what the purpose of this implementation is, but I suspect it's related to the experimental modal administration. The issue is that, in that hook, the function assigns a value of 'scratch_paragraph` to the Paragraph item, I think ONLY when you are in editing mode (once the node is saved, the value is actually the paragraph item ID).

So, paragraphs_field_formatter_view(), which produces the output, finds that flag scratch_paragraph and effectively skips rendering the field. Again, this only happens while editing and pressing Preview.

I commented out hook_field_prepare_view() and slightly modified paragraphs_field_formatter_view() and the Preview works, BUT I haven't tried the rest of the functionality - this may mess up the modal admin etc.

I'm not a maintainer of this module and don't quite have the time to thoroughly test, but I thought I mentioned what I've found in case someone wants to fix this.

argiepiano commented 2 years ago

Also tried leaving hook_field_prepare_view() as is, and commenting out lines 101-107 in paragraphs_field_formatter_view() and that also works for the Preview...

stpaultim commented 2 years ago

@argiepiano Thanks. I'm not sure that I'll be able to fix this. But, maybe I can recruit someone who can.

argiepiano commented 2 years ago

A couple more thoughts: scratch_paragraph is used to avoid rendering the Paragraph field. @laryn added this is #60 not too long ago. And as I suspected it was added when the modal editing was added. It's unclear to me what @laryn was trying to solve with this.

I have tested by removing BOTH paragraphs_field_prepare_view() AND lines 101-107 (see below), and the modal still works fine in my testing, and the Preview starts working now.

So the key is to figure out if there is any situation when avoiding the rendering of the field, and scratch_paragraph flag are really needed. My guess is that @laryn put it there because he adapted an unmerged D7 change that used it. The difference with that is that, that D7 patch did not use a modal, so my guess is that avoiding rendering the Paragraphs field was somehow needed in that situation.

This is what I removed in paragraphs_field_formatter_view() (in addition to the whole paragraphs_field_prepare_view() function).


      // If we are dealing with an empty paragraphs field, render an insert point.
      if ($items[0]['value'] == 'scratch_paragraph') {
        if (!empty($instance['settings']['modal_admin'])) {
          $entity_ids = entity_extract_ids($entity_type, $entity);
        }
        return $element;
      }
argiepiano commented 2 years ago

Just wanted to add that this has to be looked at carefully. I haven't tested in all situations, e.g. nested paragraphs...

laryn commented 2 years ago

@argiepiano Thanks for digging into this as much as you have. If memory serves, the scratch_paragraph was intended for front end administration in the case that we have a paragraphs field that is empty, so that we can still add the front end admin options to create a new paragraphs item from the front end. But it's worth testing to make sure it's actually doing that, or needed. You are right that the D7 patch formed the basis for this experimental feature and I'm sure there are still some bugs to be worked out.

@stpaultim I'm not sure when I'll be able to get to this so feel free to recruit someone before then if you are able.

sudipto68 commented 1 year ago

@argiepiano and @laryn thanks for figuring out this issue. We tested commenting out both the paragraphs_field_prepare_view() and lines 101-107 in paragraphs.field_formatter.inc and found preview shows all paragraphs except paragraphs which using paragraphs jquery ui accordion (I guess thats another issue). Nested paragraphs were showing perfectly. But we got some notice as below - It is a test update _ Friends of the Mississippi River

sudipto68 commented 1 year ago

I have submitted a PR Based on the solution. Here is the PR 136

herbdool commented 1 month ago

I must admit that I don't know if/how the modal admin works (which was part of https://www.drupal.org/files/issues/interdiff-2448677-20-24.txt which was merged). But I can see that the section in paragraphs_field_formatter_view() mentioned above is missing the line: $element[0]['insert_point'] = paragraphs_create_insert_point($entity_type, $entity_ids[0], 'scratch', $instance['field_name']); which calls a function which adds a contextual link. So maybe modal admin isn't working for me - no contextual link? And it returns an empty array.

At any rate, I have also removed it in testing. But I've also changed paragraphs_field_prepare_view() to this:

function paragraphs_field_prepare_view($entity_type, $entities, $field, $instances, $langcode, &$items) {
  if ($field['type'] == 'paragraphs') {
    foreach ($items as $key => $item) {
      foreach ($item as $delta => $instance) {
        if (!isset($instance['value'])) {
          $items[$key][$delta]['value'] = 'scratch_paragraph';
        }
      }
    }
  }
}

Because the node preview seems to ignore paragraphs nested in paragraphs but adding scratch_paragraph prevents it from dropping. But as it is currently it only adds scratch_paragraph to the first item. My change adds it to each item.

This is just a temporary fix though since the preview still doesn't seem to behave the same as a regular render - the preprocess functions are not running properly, somehow, that were required for some paragraphs types I've got in testing.

herbdool commented 4 weeks ago

I've now updated the PR to also prevent the modal_admin links from appearing if in node preview. (We want to prevent them from appearing because it breaks the way a preview should work - the user shouldn't be able to edit and save the content while still in preview.)

I've separately figured out the issue I had with modal_admin appearing. It now seems to be fully working for me.

@laryn @olafgrabienski would you like to take a look at the PR? Node preview should work with complex paragraphs types (such as in paragraphs_aplenty) and the modal admin links should not appear on preview.

olafgrabienski commented 3 weeks ago

@herbdool, I can probably have a look by end of the week.

olafgrabienski commented 2 weeks ago

@herbdool I've had a look at the updated PR. As far as I can see, the node preview works with Paragraphs (even complex types, e.g. Accordion, Cards, Media List). The modal admin links do not appear (as expected).

In DBlog, I see however two warnings after editing and/or saving content with a Paragraphs field:

laryn commented 2 weeks ago

Sounds like we're close here with just a few rough edges turned up by @olafgrabienski -- thanks for your work on this @herbdool and @olafgrabienski! I can do a round of testing after @herbdool sees and responds to the latest findings.

herbdool commented 2 weeks ago

@olafgrabienski do you see the same errors without the patch?

olafgrabienski commented 2 weeks ago

do you see the same errors without the patch?

Yes, I do. (Sorry for not checking before.) No idea about the reason, though. There are some contrib modules on the test site, but not many:

herbdool commented 2 weeks ago

@laryn sounds like those errors are not due to this PR.

laryn commented 2 weeks ago

@herbdool Okay, I'll try to review this soon. @olafgrabienski If you can reproduce those errors, can you open in a separate issue?