By eezz on

Hello,

I have just installed the latest version of Drupal 6.12. I also have installed all the modules required to post images using the new wysiwyg api with ImageCache, Tinymce (and all the other required libraries).

All is working well, however with the HTML filtering off (all filters off for that matter) I cant get the closing slash to stay on the end of an image tag. I searched and searched and found this node... http://drupal.org/node/27230. However the code is in the current version.

Maybe another module is breaking this... I have tried disabling all wysiwyg modules and even with a completely vanilla input gui the image tag still turns into <img {...} > instead of <img {...} />.

I am very interested to know if this has been reported elsewhere so I can validate my site. Let me know if I have provided enough info and appreciate any assistance you may provide.

Cheers, eezz

⋅ Categories: Drupal 6.x

Comments

eezz’s picture

eezz commented

Update,

I downloaded and installed a completely fresh Drupal 6.12 and created a page from scratch... the same behaviour occurs.

Strangely, when I attempt to edit the content the /> is present, but once the content is saved the slash is removed.

One positive is that the /> is stored in the node_revisions table.

Cheers, eezz

PS: Let me know if this is the right forum to be addressing this issue

dman’s picture

dman commented

First guess is that you are not genuinely "Viewing Source" but using some DOM tool like firebug. it lies to you about the actual code, what you see is the interpreted DOM. As does "View selection source". I hope you are aware of this.

If this bug report really is the case, I'd be worried, but I think someone would have noticed the XHTML validation problems long before now.
- A quick test : using FCKEditor and image embed button, and 'Full HTML'. = OK
- : using no WYSIWYG and 'PHP format' (almost raw HTML) = OK.
(FF3, OSX)

So... I'm thinking that something may be wrong with the tool you are doing the measuring with.

View the actual source.
Run it through the validator.
Save as and inspect the code.

Really - confirm it's really happening like you think it is.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

eezz’s picture

eezz commented

Thanks for the heads-up with FF, I was using View Selection Source when I was replicating the issue. I now admit that my test was flawed using a vanilla install and using FF to examine the selected source... the full source did, as you say, validate perfectly.

Now to my further testing...

This it my set of conditions that result in the stripped />...

1. Create New Content > Blog
2. Use an Input format with all filters off.
3. Upload then insert image via file field inset.
4. Save... check source (all good... closing / is there )
5. Edit the same content item but select an input format with html filter enabled (img permited), save it.
6. Now the closing / is stripped
7. Edit the item again and change to an input format without the html filter...
8. The /> is returned to the output html

I am using Image Resize FIlter, and IMCE...

On my instance it appears that the condition is present when opening an existing content item that was initially created using a non-filtered input type then re-opening and saving it using a html filtered input format type...

I feel certain that I am going mad again

eezz’s picture

eezz commented

Also, if I initally create an item using a html filtered input format (img allowed), then insert an image using IMCE, the resulting img tag has no closing slash.

I appreciate your intrest in this issue, I have just started to crack into Drupal after may years in Joomlalalaland and Sharepointhell ;)

dman’s picture

dman commented

Well, that sounds like a useful sort of troubleshooting, but I just had a quick go and still can't replicate.
An input format with just the HTML filter including img tag works as expected for me.
Have you tried turning the other filters off?

.dan. is the New Zealand Drupal Developer working on Government Web Standards

eezz’s picture

eezz commented

Thanks for your interest dman, I expect there is a conflict with a module or tinymce plugin that I'll just have to find by a process of elimination. Given that the issue still is apparent when I create a fresh item using only a html filtered input format. I'll have to check it out tomorrow and report my findings.

Cheers, eezz

eezz’s picture

eezz commented

After spending too many hours trying to nail the specific conditions required to replicate this issue 100%, I have found the answer:

The problem lies in the "Teaser break" plugin in the WYSIWYG api for tinymce.

If I create a content item using an input format with the "Teaser break" option de-selected, the img tag is valid

If I enable the "Teaser break" plugin in the WYSIWYG api settings for the specific input format, then go back and edit the item and save it, the img tag is rendered invalid.

I'm going to have to find out what this "Teaser break" plugin does and why...

Thanks dman for prompting me to undergo deeper analysis of the issue.

dman’s picture

dman commented

Beware of geeks bearing gifts, and
NEVER trust a WYSIWYG.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

eezz’s picture

eezz commented

I want to ensure that when users create content, they can comply with strict validation without having to pick through the code. WYSIWYG editors are a necessary evil in my world, so I try to make them do the right thing without end user interaction.

I'll bring this up with the developers of the module to see it there is something I can do to fix it. Disabling the Teaser is fine as a workaround for now.

Cheers, eezz

dude4linux’s picture

dude4linux commented

I've confirmed this behavior of 'Teaser break' after installing the latest Drupal update to 5.21. The update introduced problems with the TinyMCE module. Since that module is being deprecated in favor of Wysiwyg, I decided to remove TinyMCE and install Wysiwyg instead. Everything seemed to be working fine, but while troubleshooting an unrelated problem, I noticed the missing closing tags for img and br. I found this thread while searching for a solution. Fortunately I had only edited a couple of pages with "Teaser break" enabled so it was easy to correct.

Information is free, knowledge is acquired, but wisdom is earned.

dude4linux’s picture

dude4linux commented

I applied TwoD's wysiwyg-break-regexp-test.patch from thread 'Teaser break causes invalid HTML' at http://drupal.org/node/573878, although I had to manually edit the break.js file to apply the changes. The patch seems to fix the missing closing tags for images and paragraphs, but did not help with the missing < /div> tags that were causing my problems. Following a tip from sun, I installed the HTML Corrector module for 5.x. Apparently this module has been moved to core in Drupal 6. I hadn't seen the note, so assumed the module had been discontinued. After installing and enabling the module, you need to check it's box for each of the input types you want corrected. I haven't tested it extensively, but it worked for all the pages on my site that were giving me problems.

Information is free, knowledge is acquired, but wisdom is earned.