570483 - Filtered vs. unfiltered HTML issues causing formatting havoc site-wide

Status: RESOLVED FIXED

(Websites Graveyard :: drumbeat.org, defect)

Description

[Salve J. Nilsen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.38 Safari/533.4
Build Identifier: 

The "Detailed Description" field allows max 500 characters and before displayed, strips useful HTML elements like <p> and <br>.

Please either remove the unused/stripped elements from the wysiwyg editor, or add at least the useful ones.

I'm guessing the 500-char limit was related to the old layout. Maybe it's time to increase it too?

Allowing <p> and <br> would at least be nice.

Reproducible: Always

Steps to Reproduce:
1. Edit project front page
2. Add text that contains a few paragraphs to the "Detailed Description" field, and save
3. Check that the changes are visible (they're not, and a page source code inspection shows that the elements have been stripped.)
Actual Results:  
No paragraph breaks.

Expected Results:  
Paragraph breaks.

Comment 1

[Matt Thompson]

This is our #1 complaint on the site right now, for this and the "about" page. Have elevated priority.

Paul and Ned: let's figure out the best way to address this in our meeting today.

Comment 2

[Ned Schwartz]

see also: https://bugzilla.mozilla.org/show_bug.cgi?id=569933

Comment 4

[Paul Booker]

Exploring this problem ..

Comment 5

[Paul Booker]

If we want to increase the maximum length for the "Detailed description" field this can be on the CCK administrative page @ admin/content/node-type/project/fields/field_p_description

On this page i can see that the "TEXT PROCESSING" is set to "Filtered text (user selects input format)" 

You can adjust the "ALLOWED HTML TAGS" for "Filtered HTML"
@ admin/settings/filters/1/configure to include <br> & <p>

Best,  Paul

Comment 6

[Ned Schwartz]

Sounds good - Paul do you want to take care of implementing this?

Comment 7

[Paul Booker]

Hi Ned ,

I'll take this one but it'll probably be Monday before i can continue working on it.

Best, Paul

Comment 8

[Matt Thompson]

Great, thanks Paul! Still getting lots of complaints from users about this one. Any help much appreciated!

Comment 9

[Paul Booker]

Hi Matt, I'll get this fixed on our stage server ..

Comment 10

[Matt Thompson]

Thanks Paul.

Just now I was trying to fix the formatting in this imported blog post, for example.

Note that it looks ok here:
http://www.drumbeat.org/project/feed-item/change-web-made-movies-focus

But there are no paragraph breaks showing when it appears on the project front page:
http://www.drumbeat.org/project/webmademovie

We're getting a lot of complaints about people unable to style their text and weird formatting. Any help you can provide will make the community very happy!

Comment 11

[/\/\arcio Galli]

My notes - not sure if relates to this. Basically one cannot add embed code to blog posts - youtube does not get added. Let me know how I can help.

Comment 12

[Paul Booker]

@Matt

We need to adjust the "input format" to "filtered html" OR "full html" instead of "messaging plain text" for the "Planet Mozilla" feed @ https://www.drumbeat.org/feeds/planet-mozilla

I have changed the "input format" setting on stage to "filtered html" and run cron.php from the browser and and generated the new feed-item content node ..

https://drumbeat.stage.mozilla.com/feed-item/jay-sullivan-your-firefox-cloud-firefox-sync-and-firefox-home(In reply to comment #10)

.. which looks to be formatted much better. 

On i <3theopenweb i use the "full html" as my "input format" as i trust all my aggregated sources.

Just giving some thought how best to proceed ..



> Thanks Paul.
> 
> Just now I was trying to fix the formatting in this imported blog post, for
> example.
> 
> Note that it looks ok here:
> http://www.drumbeat.org/project/feed-item/change-web-made-movies-focus
> 
> But there are no paragraph breaks showing when it appears on the project front
> page:
> http://www.drumbeat.org/project/webmademovie
> 
> We're getting a lot of complaints about people unable to style their text and
> weird formatting. Any help you can provide will make the community very happy!

Comment 13

[Paul Booker]

@Matt

The problem here was more to do with the fact that we have two filters (WYSIWIG & HTML) that are being used together which should probably be used exclusively. 

To correct the problem i have disabled the HTML filter. 

https://www.drumbeat.org/admin/settings/filters/1

However not sure if this is the end of the problem. If we have content types that don't use the WYSIWIG editor we will need  to specify two seaerate filters for 1. filtered HTML with WYSIYWIG and 2 filtered HTML without WYSIWIG with the first using the "HTML filter" and the latter using the "WYSIWIG filter" 

Best, 
Paul Booker
Appcoast

Comment 14

[Paul Booker]

@Matt 

Shall we set the "Maximum length" to some arbitrarily large number or leave blank for unlimited ?

https://www.drumbeat.org/admin/content/node-type/project/fields/field_p_description

Best,
Paul Booker
Appcoast

Comment 15

[Salve J. Nilsen]

@Paul, @Matt,

The 500-letters max length was quite annoying, but also VERY USEFUL. One of the most difficult aspects of writing a good introductory text to any project is that it tends to become too long very quickly!

I probably spent 3-4 hours trying to figure out what to remove from my project intro for it to be small enough while still being able to convey the most important points.

It was REALLY difficult, especially for someone like me who isn't used to writing compact high-signal texts, but the exercise was still very useful and in the end the description became much better than what my first try was.

If you increase it, please do it just a _little_ (e.g. to 600 letters.) Having the limit there forces us to write better/tighter texts, which (hopefully) leads to more people bothering reading all of it, and hence get an idea if the project is worth joining/supporting. :)

Comment 16

[Ned Schwartz]

(In reply to comment #13)

Okay, I am going to create a bug to do just this - we need a non-WYSIWYG filter for things like comments. 

I am going to create a new bug to track that and assign it to myself.

https://bugzilla.mozilla.org/show_bug.cgi?id=580040

Comment 17

[Ned Schwartz]

I fixed a syntax error (a missing comma) in the list of allowed tags at https://www.drumbeat.org/admin/settings/filters/1/configure that was preventing imgs from showing in input fields that are set to 'filtered HTML'.

I suspect the same syntax error would have been preventing headings as well as they followed the syntax error.

Comment 18

[Ned Schwartz]

looks like the filtered html input allows li tags but not li!

Comment 19

[Ned Schwartz]

Paul Booker,

I see you have unassigned yourself here. Does this indicate that the bug is resolved in your opinion?

Comment 20

[Paul Booker]

@Ned

No, it just indicates that i'm not working on the bug right now & allows for the possibility that others can pick it up and maintain momentum 


Best,
Paul Booker
Appcoast

Comment 21

[Ned Schwartz]

coolio

Comment 22

[Matt Thompson]

Let's check in on this one -- what further formatting issues do we need to fix so that project leads can get their content looking how they want?

Comment 23

[Ned Schwartz]

Hi Matt, 

I did a bunch of work on this and think I am on my way to having it sorted. 

1) there was a syntax error in the html filter for blog posts that was preventing img and a few other tags from rendering. I have fixed that and noted it on this bug.

2) I created a new input filter called 'Simple Filtered HTML' that never receives a WYSIWYG editor and is more locked down in terms of not allowing embedable html tag types etc. This is, along with outstanding issues is  described in bug 580040.

I have assigned this new filter to project comments for now, but we can further implement it anywhere where the input is public facing or we otherwise want to lock down the input (such as blog comments or short project descriptions that we want to keep text only etc.) It might be good to make a list of these other inputs and collect it in a bug... I have just created that bug: bug 584426

Unfortunately there is a notice on the input filters module that  "Defaults only affect NEW content NOT existing content." That means that all existing projects have the input filter (Filtered HTML *with WYSIWYG*) -- that means that the changes are not in effect for projects that are older then say, July 23rd.

There may be a work-around but I have not found it.

Again, this is all described in bug 580040.

At any rate, I am happy to mark this RESOLVED and move the work that is outstanding either to bug 580040, or to new bugs when and if further input issues come up.

Comment 24

[Matt Thompson]

Great! Let's check in with Paul and decide on final steps.