CKEditor allows you to create a table. It also allows you to vertically align the cell contents (Top Middle Bottom). However, those changes (although saved) are not reflected when the table is rendered. We should make sure that all acceptable HTML tags that CKEditor might use are included in the filtered HTML filter/input formats.


you doing


is what gets rendered and works with full html

Comments

david.moore.ipg’s picture

david.moore.ipg commented 
<td style="vertical-align: bottom;">you doing</td>
ezra-g’s picture

ezra-g commented
Title: filtered HTML needs more tags to match CKEditor » filtered HTML should allow TD, TR tags to match CKEditor
crimsondryad’s picture

crimsondryad commented

I disagree ezra-g. TD and TR tags are a security risk. If you want filtered HTML to match what CKEditor allows, then you should add those tags to *your* filtered html text format on your site. Not everyone wants those tags implemented by default.

david.moore.ipg’s picture

david.moore.ipg commented

Then we need to remove the table button from CKEditor. All I am saying is that they ought to align. The filtered HTML and CKEditor ought to allow/disallow the same things. I know you can tweak CKEditor's interface. I'don't know if you can have one CKeditor implementation for filtered HTML and one for full HTML--with only trusted users (community or content managers) having access to full HTML and an editor that supports it.

If CKEditor lets you do things that look right in the editor window, but disappear when filtered out by drupal, you will have frustrated users.

crimsondryad’s picture

crimsondryad commented

The fundamental difference here is that text formats ( or input filters ) are a feature of core. CKEditor is a contrib module. If anything, CKEditor should conform to core, not the other way around.

And yes, you can set up multiple profiles for CKEditor based on role to use different input formats. There are a variety of documentation sources available, both on the CKEditor ( or Wysiwyg module...I'm not sure which Commons uses ) and on CKEditor.com. Please read the manual before recommending sweeping changes.

david.moore.ipg’s picture

david.moore.ipg commented

No, I think the issue is the default setting for the wysiwyg and wysiwyg_filter modules and the specific configuration of filters and other variables that come in the commons profile distribution. The commons feature modules (commons_core.info, commons_core.install, commons_core.module and commons_core.strongarm) all have settings that need to be consistent with the way CKEditor is implemented in commons. It has nothing to do with core.

For example, if tables and iframes are not not included in filtered HTML (through the wysiwyg filter), then the settings for CKEditor should not make them visible by default.

crimsondryad’s picture

crimsondryad commented

Ok, you're saying several different things here. First, let's agree on terminology because "wysiwyg" describes a multitude of things, including another Drupal module. In D6, filtered HTML is an "input filter." In D7, those are called "Text formats". I'm going to assume we're talking about D7.

So, Commons could indeed add table / td tags to the default filtered HTML text format, or they could choose to add an entirely new default text format ( called CKEDitor or wysiwyg filter?). I see why they are leaving these enabled to prevent restricting features for as many folks as possible. But as a dev, tables and iframes are typically crimes against nature that shouldn't be used unless one knows exactly what they're doing. Not to mention the security risk, which exists because divs and td can take background style attributes, which could lead to the injection of malware via css for a faked out image file.

What you said in #6 makes sense...ie, turning these off in CKeditor so they match the implemented text format.

lsolesen’s picture

lsolesen commented
Version: » 6.x-2.x-dev
Issue summary: View changes