So after a good deal of experimentation, I still can’t reliably put an image inline when first creating a node or filing a comment. The only times I can reliably do it is when I paste the tag into a textarea after it has failed once already. Submitting the textarea with *hand-entered* HTML fails/succeeds under the same circumstances.
I think I’ve ruled some things out, though:
- the WYSIWYG editor is probably not the source of the problem (having it enabled or not seems to have no predictable effect on the ability to have inline tags stick). When WYSIWYG is turned on, the img_assist dialog won’t even post its tag into the textarea, though.
- the various input types seem to have no predictable effect on stickiness
- the input format corrective filters seem to have no effect (I turned them all off and had the same problem)
- the order of input format corrective filters seems to have no effect either. Plus, it seems clear that some correction happens upon submission and others (like converting the [img_assist] tag into HTML happens upon display.
- the form of the tag select (Filter Tag, HTML Tag) in the img_assist dialog has no effect on stickiness.
One finding that seems significant: if you have a working set of copy/tags in your post, and you go to edit it, and you use img_assist to add an image to the bottom, that tag – and JUST that tag – will be deleted upon submission. This also happens when you add straight HTML, even if the tags are on the “allowed” list.
My current theory is that this is CSS class/ID related. It wouldn’t be surprising that all my mucking about with styles has renamed the textarea reference point substantially enough that the img_assist dialog can’t find the correct textarea when WYSIWIG is on. It may be that when the error result from a given post comes back, the classes and id tags are slightly different, which explains why it’s easier to insert a tag the next time. But why this would result in a form submission deleting just the tag I entered (or any other HTML I just entered) has me mystified. Maybe, Gregory House-style, we’re dealing with two parallel problems here.
I think I’ll continue to experiment with simple hand-entered tags under various circumstances and see what is allowed and what isn’t.
Straight HTML, hand typed: <span>value!</span>
The above was converted into & gt; and & lt; tags upon submission.
Test test2 <b>bold</b> boldwithouthtml <strong>strongwithhtml</strong>
test <b>boldwithhtml</b> boldwithouthtml <strong>strongwithhtml</strong>
Test
Turned on all WYSIWYG settings that were off.
Test
Link
[img_assist|nid=61|title=|desc=|link=popup|align=left|width=640|height=145]
[img_assist|nid=61|title=|desc=|link=popup|align=left|width=640|height=145]
Additional text
Enabled by default, then turned off, then text posted – FAIL
[img_assist|nid=61|title=|desc=|link=popup|align=left|width=640|height=145]
Conclusions:
I think the form submitter is somehow ignoring the javascript-edited textarea somehow, posting only what is typed or pasted into the form field.
Maybe we can create an input type that wouldn’t have an editor in it, but that would do some correction to your posts once submitted to clean them up. Then you wouldn’t be mucking around with the DIV hierarchy when you turned WYSIWYG on/off.
Experimental No-Editor
text
text
[img_assist|nid=61|title=|desc=|link=popup|align=left|width=200|height=45]
[img_assist|nid=66|title=|desc=|link=popup|align=left|width=640|height=422]
[img_assist|nid=66|title=|desc=|link=popup|align=left|width=200|height=132]
When I type normally into this field, I can do all sorts of things.
html
Maybe it is the WYSIWYG editor. When it’s included it mucks up the DIVs, when it’s off things are okay?
Okay – Filtered HTML, but with the editor out of the picture
text
bold
strong
[img_assist|nid=67|title=|desc=|link=popup|align=left|width=197|height=200]
Text entered two line-returns below the picture
More text two line-returns below that.
Text on line one
Text after two carriage returns
More text after another two returns
Still
Not
Quite
Sure
Why
These
Lines
Don’t
break
value!
[img_assist|nid=45|title=|desc=|link=popup|align=left|width=200|height=200]
I had the most wonderful time at the Champagne Rooms. Spent the night dancing with Mr. Melnik (who, it turns out, is a marvelous dance partner). Blackberry’s musical selections were both wonderful and unexpected — at least for me, a newcomer to New Babbage. But, the highlight of the evening, I think, was Stargirl dancing on the bar in the poofy (very poofy, very very poofy) dress!
It seems that a few people were confused about Music Appreciation and thought I was putting on a burlesque show. Music Appreciation is hosted by a whole bunch of different people, and it’s an out-of-character showcase for the host to share some fun and interesting music with everyone.
[img_assist|nid=61|title=|desc=|link=popup|align=left|width=200|height=45]
STUPID, STUPID. http://drupal.org/node/328218 says that img_assist will only work with TinyMCE as a WYSIWYG editor.
I’m uploading it now and will switch over. Hopefully this will solve our problem.
Test
[img_assist|nid=61|title=|desc=|link=popup|align=left|width=200|height=45]
This is a text comment being done in a TinyMCE editor. I’m about to embed an image:
[img_assist|nid=64|title=|desc=|link=popup|align=left|width=200|height=121]
And then type a bit more copy words. This is much better than it has been for some time.
Let’s see what happens when I add HTML:
<strong>STRONG</strong>
<span>value!</span>
<ul>
<li>Item one</li>
</ul>
STRONG
WOOHOO! It works! It even looks passable, and the img_assist icon is in the menu bar where it belongs.
I think we’re ready for more rigorous testing.