Problem/Motivation

Found multiple closed issues, but there might have been a regression somewhere?

Multiple comments in #2983137: WYSIWYG editor not saving inline images for advanced html/text editor. about having that problem and we're also seeing it on a client site with 8.x-5.x, I assume 6.x is the same.

I suspect they are never made persistent in the first place, because otherwise you only run into trouble if you use the same file elsewhere, gain a file usage and then remove it again.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#8 3198148-5.patch1.08 KBjrockowitz
#7 webform.webform.issue_3197928.yml4.74 KBjrockowitz
#5 webform_html_file-usage.png74.97 KBberdir

Comments

Berdir created an issue. See original summary.

jrockowitz’s picture

jrockowitz commented

I am not able to replicate this issue.

Below are my steps to review this functionality

  • Update the "Element text format" to use Full HTML.
  • (/admin/structure/webform/config/elements)
  • Add an image to any configuration message (/admin/structure/webform/config)
  • Confirm that the file status is 1 in the file_managed table
  • Confirm that file is tracked in the file_usage table with a count of 1

Below is the test for this functionality.

\Drupal\Tests\webform\Functional\WebformEditorTest

All the code that is handling this functionality is in webform/includes/webform.editor.inc

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

This is not for a confirmation message, it's the separate "Advanced HTML Element" that you add like a form element. I think it was nested in one or likely even multiple container-ish elements.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Also, as always I didn't expect you to be this fast and dedicated in checking this :)

Mostly, I just created this so that it's "documented", as it came up in a client support ticket and I found those forgotten comments in the referenced issue.

If it becomes an important thing for us that we want to have fixed or get paid to do so we're happy to look into it ourself :)

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
StatusFileSize
new webform_html_file-usage.png74.97 KB

Yeah, so this element is inside a fieldset inside a flexbox inside a wizard page. Because why not ;)

jrockowitz’s picture

jrockowitz commented

There should be test coverage for that too. I can do a quick manual test later.

jrockowitz’s picture

jrockowitz commented
StatusFileSize
new webform.webform.issue_3197928.yml4.74 KB

The same steps work as expected using the attached webform.

I am using Drupal 8.9.x and Webform 8.x-5.x

jrockowitz’s picture

jrockowitz commented
StatusFileSize
new 3198148-5.patch1.08 KB

The attached webform tries to mirror the example from #5 but I still can't replicate this issue.

If we can replicate this issue, it is a major or critical issue because of the data loss.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

I'm not sure. I've definitely seen the result on the client site, with broken images that point to the deleted files, but I didn't try to reproduce, we did some workarounds there for now.

I will need to see if I can reproduce it somehow. Only idea that I have left atm is that it might be related to translations? This is a multilingual site.

jrockowitz’s picture

jrockowitz commented
Status: Active » Postponed (maintainer needs more info)

Marking this as postponed until we can reproduce this issue.

jrockowitz’s picture

jrockowitz commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I am going to change this to cannot reproduce. Please reopen this ticket if the issue can be reproduced.

bburg’s picture

bburg
he/him
Location Washington, DC
commented

@Berdir, Do you happen to have a Content Security Policy enabled on the site where you were seeing this? I was getting the same report from a client, with images uploaded to text elements in webforms, having their status as "Temporary", then being purged. I checked the logs, and saw these CSP violations:

{
    "csp-report": {
        "document-uri": "about",
        "referrer": "http:\/\/localhost:8080\/",
        "violated-directive": "script-src",
        "effective-directive": "script-src",
        "original-policy": "<snipped>",
        "disposition": "enforce",
        "blocked-uri": "eval",
        "line-number": 27,
        "column-number": 23,
        "status-code": 0,
        "script-sample": ""
    }
}

I'm not sure what the document uri is about, this particular site doesn't have an /about page, and I never visited that URI, but these did seem to coincide with the testing I was doing on the webform. I checked the "unsafe-eval" option for script-src in the CSP settings, and I was about to save a webform with an uploaded image in a text field with the status set to permanent. Enabling the unsafe-eval option globally isn't ideal, but this is a similar issue I've seen before #3164287: Paragraph module content with edit mode "closed" break CKEditor.

jrockowitz’s picture

jrockowitz commented

I think this might have been addressed via #3218296: Inline image is stored as temporary file again

bburg’s picture

bburg
he/him
Location Washington, DC
commented

I think you are right, and I just hadn't cleared a cache or something.