Thanks for this!
If I enable "Automatic text format support" on the Insert module configuration page, as described here → , then try to re-save the text format, I get this error:
The following attribute(s) can optionally be supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: Style (<img class>).
I confirmed that I don't have that attribute listed in the Manually editable HTML tags field:
<cite> <dl> <dt> <dd> <object> <param> <figcaption> <div id aria* data* class> <span id aria* data* class> <button id aria* data* class> <video controls controlslist src width height> <source src type> <iframe src allowfullscreen allow width height frameborder> <figure class> <blockquote cite> <ul type> <ol type> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id> <drupal-media title width height data-width data-height> <img title data-responsive-image-style> <a hreflang data* name>
So I think it is being added by '_insert_allowed_html_validate'. I tried commenting out the 'class' attribute in that function, just to see if it helped, and the error changed to:
The following attribute(s) are already supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: .
(i.e. The list of attributes is blank, but it still won't save.)
So I turned off "Automatic text format support" again, and it seems to work fine - I guess I already have the necessary attributes whitelisted, so I don't need it. Just mentioning it in case someone else has the same issue.
After using `ce536b42` for a week, it all seems good to me. Thanks again!
LGTM, thanks!
Great, thanks! I have installed that in production and will look out for any issues over the next week. (We were getting false-positives about once every 1-5 days before.)
Good idea.
You could remove `cursor: pointer` and `display: inline-block`, rather than duplicate them.
Otherside LGTM, thanks.
mi-dave → created an issue.
mi-dave → created an issue.
Looks good to me, thanks!
mi-dave → created an issue.
mi-dave → created an issue.
LGTM - thanks again. :-)
Great, thanks. Looks good, but I will test it properly on Monday and confirm.
Wow, thanks for the quick turnaround!
Unfortunately it seems $update = TRUE when submitting a draft, since the record already exists in the database. But I think that check is no longer needed, since the state will be WebformSubmissionInterface::STATE_UPDATED when updating an existing record.
Also, I think the default value '' should be [WebformSubmissionInterface::STATE_COMPLETED] - otherwise array_search() triggers a TypeError, and the handler not run by default.
Thanks!
mi-dave → created an issue.
I think the issue mentioned by yuehua in #12 above is fixed by 🐛 EntityCreateAnyAccessCheck::access() wrongly forbids access when the first bundle forbids access Fixed , which was released in Drupal 10.1.0 and 9.5.10 last month. (I don't know if that affects the original issue at all.)
Thanks for stepping up.
The fix in #6 worked for me too - thanks.
The orchestrator response code is 204 (No Content) not 402 (Payment Required).
mi-dave → created an issue.