Hi,
tried this on a clean 6.15 installation with the latest wysiwyg dev, garland and tinymce 3.2.7 in FF IE8 and Chrome:
I set up a simple list with 3 items which results in

<ul>
<li>item1</li>
<li>item2</li>
<li>item3</li>
</ul>

So far no problem. When I now try to indent one item, its not being shifted to the right at all, only a bit down. Firebug shows me:

<ul>
<li>item1</li>
<ul _moz_dirty=""><li _moz_dirty="">item2</li></ul>
<li>item3</li>
</ul>

which doesnt look right.

When disabling the editor source changes to

<ul><li>item1
           <ul><li>item2</li></ul>
     </li>
     <li>item3</li>
</ul>

which has the desired result when enabling the editor again. but get even worse when I now try to outdent the item again back to its original postion
<ul><li>item1<br />item2</li>
      <li>item3</li>
</ul>

Same example works as supposed to in the full.html example editor that comes with tinymce so am guessing it must be a bug in wysiwyg? am just wondering that no one else came across this so far, at least could find anything

Comments

Status:Active» Closed (works as designed)

When I now try to indent one item, its not being shifted to the right at all, only a bit down.

This is a styling issue. If you change the profile settings under CSS to use the default editor styles it will disappear. TinyMCE's stylesheets probably contain some rule which is needed to make nested lists appear correctly inside the editor and these need to be duplicated in the theme stylesheets (or your own if using the Define CSS options).

<ul>
<li>item1</li>
<ul _moz_dirty=""><li _moz_dirty="">item2</li></ul>
<li>item3</li>
</ul>

This is how TinyMCE keeps track of that you used the indent button to create a sub-list. This is normal and happens in the examples as well. This way to nest lists is actually incorrect, as sub-lists should be inside <li> tags, which is why it's marked with _moz_dirty so the editor knows it should be fixed in the final output.

<ul><li>item1
           <ul><li>item2</li></ul>
     </li>
     <li>item3</li>
</ul>

This is what is seen if you choose the "View Source"/"HTML" button in the examples as well and is the proper way to nest lists. (Turn on source formatting to make the indentation look better.)

<ul><li>item1<br />item2</li>
      <li>item3</li>
</ul>

The same thing happens in the examples if you paste the code from the previous code box into "View Source"/"HTML" mode (Which is basically what happens when disabling/re-enabling the editor via Wysiwyg module) and then try to outdent the sub-listed item. The sub-list is removed and its contents are appended to the previous list item because the _moz_dirty attribute is no longer there so the editor doesn't know indentation was used to create the sub-list. Outdenting a sub-list only works as expected if one does not make manual changes to the code generated by the editor. Creating the nested lists, opening "View Source"/"HTML" mode, pressing update and then trying to outdent the list also produces the same result. Even though there were no apparent changes to the source, the actual markup in Wysiwyg mode no longer includes the _moz_dirty attribute as it has been overridden by the manually updated code.

Wysiwyg module does not change the editor's behavior or the contents generated by it unless any "Drupal plugins" have been enabled. The sub-list styling issue would also happen if could tell the official examples to use different stylesheets inside the editing area.

Thanks for the detailed explanation! Thought I tried it with the default theme, tried again and now its the same. Can't say I like the list behavior but thats the wrong place to discuss this. Thanks again

Version:6.x-2.x-dev» 6.x-2.4
Status:Closed (works as designed)» Active
StatusFileSize
new61.39 KB
new46.8 KB

I am re-opening this because I am seeing the same behavior inside TinyMCE, and the code is not being corrected when the node is saved. If I insert a list item, and a nested list inside that, it is closing the parent list. This is the output I see if I hit the HTML button in the editor:

<ul>
<li>item one</li>
<li>item two</li>
<ul>
<li>child item one</li>
<li>child item two</li>
</ul>
</ul>

If I use the TinyMCE example editor page, it gives a valid nested list by leaving the list item open. When I hit the HTML button in the editor I get:

<ul>
<li>item one</li>
<li>item two
<ul>
<li>child item one</li>
<li>child item two</li>
</ul>
</li>
</ul>

I am using the most recent versions of WYSIWYG, WYSIWYG Filter, and TinyMCE 3.4.4. When I view the saved node, the output is still incorrect as it is closing the parent list item. Even when I disable all input filters, I still get the same output. Not sure if I am missing something or if this is a bug. Any help would be appreciated.

I only have TinyMCE 3.4.3.2 installed ad the moment but it does appear to behave the way you describe (missing <li>). At least in IE8. (I'm at work so can't test other combos.)

I did however find a bug report for 3.4.4 saying this happens in all the major browsers:
http://www.tinymce.com/develop/bugtracker_view.php?id=4692

There's also a slightly different bug mentioning the missing <li> problem.
http://www.tinymce.com/develop/bugtracker_view.php?id=2019

Will investigate more later.

StatusFileSize
new805 bytes

I have the same bug . Lists plugin fixes there issue but in Wysiwyg module no checkbox to turn it on. This patch fixes this bug.

Status:Active» Needs work

+++ sites/all/modules/wysiwyg/editors/tinymce.inc (revision )
@@ -405,6 +405,14 @@
+      'path' => $editor['library path'] . '/plugins/lists',
+      'buttons' => array('lists' => t('Lists plugin')),
+      'extended_valid_elements' => array('li|ul|ol|'),

Since this plugin doesn't actually have any buttons, we can replace 'buttons' with 'extensions' to avoid trying to load a button that doesn't exist.

"Lists plugin" doesn't say that much about its purpose. How about "List normalizer"?
(The wiki URL is also wrong since they moved it.)

Btw, please create patches from inside the Wysiwyg folder, it makes it easier for others to apply them no matter where the module is.

Status:Needs work» Fixed
StatusFileSize
new1.14 KB

I've re-rolled the patch, changed the name, 'buttons' to 'extensions' and wrapped it in a if statement since this plugin wasn't available before TinyMCE 3.4.1.

The plugin works very well for me so in order to not delay this further I've committed this modified patch to all main branches.
The -dev snapshots will be updated within 12 hours and this will be part of the next releases.

Thank you for reporting, patching, reviewing and testing!

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:6.x-2.4» 7.x-2.x-dev
Status:Closed (fixed)» Patch (to be ported)

I just tested this on the Drupal 7 version (manually applied the patch) and it works great. Any chance of getting it included on that branch?

Version:7.x-2.x-dev» 6.x-2.4
Status:Patch (to be ported)» Closed (fixed)

It's already in all -dev snapshots, including 7.x-2.x-dev.
It'll therefore be in the next stable release as well.