Images of this draft of project proposal are not shown properly in the content of the proposal, however they are visible in the "edit" mode.
Steps to reproduce
Open the proposal draft.
Select the Edit tab and see the images (inserted in the description section).
What is the current bug behavior?
Images are not shown after saving uploading them in the edit mode.
What is the expected correct behavior?
Images added in edit mode should be visible in the drafted proposal, or at least the user should be warned about the issue that is preventing the PMI to show the images.
I reverted my changes because this allows people to use the <img> to inject XSS to the site. We need to figure out a better way to allow the <img> tag to be used within body tags of the site.
Adding more context: I was sick for the last few days and I was not around when this change was made.
I asked Eric to revert this change since there are some security risks in allowing the img tag to all authenticated users on our sites.
The default "Filtered HTML" text filter that ships with Drupal do not allow the <img> tag because image tags can contain attributes that allow for XSS attacks.
If this is a feature that we need, there might be a way as long as we prevent untrusted users from using images as a vector for XSS attacks.
@cguindon I guess project proposals could work without images, although I do find images to be important (7) when explaining for example a platform software architecture.
In any case, if images are not supported for drafting project proposals this should be made clear to the users avoiding them to upload resources that will not be available for the community to access.
In any case, if images are not supported for drafting project proposals this should be made clear to the users avoiding them to upload resources that will not be available for the community to access.
I took a look and you are right, the filter HTML text format was including an icon that allowed users to insert images even if that feature is not supported by that text filter.
This was caused by a conflict in our WYSIWYG configs. I deleted all duplicates. Now both the Filter HTML and Filtered HTML (Covert line breaks into HTML) filters are displaying the same options:
There is also a link under each section where the text filter is used that links to a page where we explain the limitation of each text filter: https://projects.eclipse.org/filter/tips
In any case, if images are not supported for drafting project proposals this should be made clear to the users avoiding them to upload resources that will not be available for the community to access.
An alternative solution would be to add a new screenshot field on the project proposal form where we allow users to upload image/screenshots. We can then display them under a new screenshot section on the page.
SELECT d.entity_id as nid, n.title, n.type, d.body_value as description
from dev_drupal7_projects.field_data_body as d
LEFT JOIN dev_drupal7_projects.node as n on d.entity_id = n.nid
where body_value LIKE '%<img%'
AND n.type = "project";
Here is the new query with the same result of 59 projects.
SELECT d.entity_id as nid, n.title, n.type, d.body_value as description
from dev_drupal7_projects.field_revision_body as r
LEFT JOIN dev_drupal7_projects.field_data_body as d on d.revision_id = r.revision_id
LEFT JOIN dev_drupal7_projects.node as n on d.entity_id = n.nid
where r.body_value LIKE '%<img%'
AND n.type = "project";
The content in your report does not match what I see on production (wich is expected since your first query did not look up revisions). More importantly, I don't see any images in the description or scope of https://projects.eclipse.org/projects/modeling.emft.ecoretools/edit
SELECT d.entity_id AS nid, n.title, n.type, d.body_value AS descriptionFROM dev_drupal7_projects.field_revision_body AS r LEFT JOIN dev_drupal7_projects.field_data_body AS d ON d.revision_id = r.revision_id LEFT JOIN dev_drupal7_projects.node AS n ON d.entity_id = n.nidWHERE r.body_value LIKE '%<img%' AND n.type = "project";
This is your last query. I formatted it to make it easier to read for me.
This query is looking up all the field_revision_body values.
SELECT n.nid, b.body_value as descriptionFROM dev_drupal7_projects.node as nLEFT JOIN dev_drupal7_projects.field_data_body as b on b.entity_id = n.nid and n.vid = b.revision_idwhere b.body_value LIKE '%<img%'AND n.type = "project";
@cguindon I tested the WYSIWYG Filter module locally and it does what we expect it to do.
You select attributes you'd like to whitelist and the rest of the attributes are stripped out on save. So the unwanted attributes are not saved in the database. Not sure this is a good thing or not since we try to always save whatever the user add to the form.
The plugin allows us to create a list of tags and their attributes that we want to whitelist. So in other words we need to add all the tags that are listed in the "Allowed HTML tags" section.
Here is a screenshot of the settings I have locally. For this example I whitelisted the src, width and height attributes for the img tag.
I like that this module prevents us to add HTML tags that could have security issues (see in the Additional Notes of the screenshot).
Perfect! I think the next step would be to install this on staging so that @mdelgado624 and I can test the behaviour to allow us to make a decision on the best path forward.
Can you push this on staging before the end of next week, please?