FCKeditor: Breaks on CCK textfield (not textarea)

I'm not able to replicate this issue.

Do you have Popups API module installed?

If Wysiwyg API does not work as expected, please

1) Remove all buttons/plugins from your Wysiwyg profile except bold+italic buttons
2) Test whether the editor appears
3) If not, temporarily disable (all) other contrib modules
4) Test again
5) If the editor appears, re-enable other contrib modules step-by-step to see who's guilty.

That's possible. I suspect that only a minority of people try to run Drupal and/or FCKeditor on IIS. All I know is that Drupal's installation instructions contain some additional required steps for setting up IIS for Drupal. And honestly, I have little interest in testing or debugging this. I'm inclined to mark this issue won't fix.

Note that I've marked another issue about an editor not working on a virtualized box as won't fix recently. It looks like some editors simply don't support that.

Sorry, without further information this issue can only be marked as won't fix.

Feel free to re-open this issue if you want to provide further information. Thanks.

ok, that I can confirm. Better title.

FCKeditor does not seem to be able to handle INPUT elements (only TEXTAREA elements). I'm not sure how fckeditor.module handles that, but perhaps it is doing it the dirty way.

We should look up in FCKeditor's manual whether handling of INPUT elements is supported in any way.

oh, now I see that you wrote that FCKeditor ignores textfields.

To clarify: Having client-side editor support on textfields is a perfectly valid use-case. We will not ignore them, but instead fix FCKeditor to handle them properly.

Had the same issue with FCKeditor for users with permission to choose the input format and had to switch to plain text input format for affected textfields.

Having the same issues.

I just noticed that I'm being propted for an input format on the field that causes the error, the problem is not really with fckeditor but why is it prompting for input format on a plain text field? Wrong queue I know but maybe someone else has had this same issue and resolved it?

No, the problem is with FCKeditor. Some editor libraries automatically convert a textfield into a textarea. FCKeditor does not, and it's possible that some other editors don't either.

In my case, #17 was the issue, switching to plain text fixed. For me, I can't really think of a situation where formatted text is appropriate for a textfield, so this is not a big bug.

Regarding a possible use case for including formatted text in a TEXTFIELD, I encountered this problem with a site currently being built. Fields needed to be created for a Point of Contact and an Information Flyer. For the POC, this needed to support "mailto" functionality and the flyer needed to link to a file for download or link to an external file. Having the field set for plain text results in the display of the HTML code rather than appropriate links.

If you need an email field and a link field, why not use Email Field and Link for CCK? Or do you mean that those fields will not always contain emails/links?

That is correct. They could contain email address or links, but that depends upon the user.

I am having the same problem as stated in comment #17, but I disagree with dafeder that this isn't a big bug. I need some of my fields to be formatted for the same reasons stated in comment #20. The link field module is not an option because sometimes there is no link input into the field. WYSIWYG has disabled the ability to disable fckeditor per number of lines or on specific fields—I really think this functionality is a necessary component and should not be overridden.

Rant on "email/link"-field and "content types"
This is really a specific case of the original issue, but I find the reasoning behind not using existing solutions for this problem curious so here it goes.

At the moment I can't imagine why anyone would not want to separate emails and links into two distinct fields, unless a combined field is required by some interaction with third party code already having this behavior.
The use case in #20 doesn't seem a valid reason to use markup in a textfield. It's clearly stated that two fields need to be created for "Point of Contact" and "Information Flyer". POC field needs "mailto:", so an email field could be used. The IF needs to be a link, so use a link field. This gets around the problem with it showing up as plain text. #22 adds that email or link data may or may not be provided by the user. Simple, just don't make the fields required and they won't be displayed if empty. #23 again repeats that inputting a link is optional in their use case. Again, there's no need to force the link field to be required.

If link or email is required, use a custom validation function to make sure at least one is filled in instead of using the #required flag (or unset it and hide the * on the other field with some PHP/JavaScript when one is no longer empty).

'If using a combined link/email field, you could for example not easily list all the nodes which have an actual email address, or an actual link, without additional processing to first parse the text and figure out what type of content it is. Isn't avoiding situations like this part of why those two types of fields were created? No markup to be messed up by accident by users, and each field always has a single meaning/"content type", both in editing and presentation.

Using regular textfields for markup can be useful when it's understood that this is a small piece of text which is allowed to use a small set of tags to make it a bit more interesting and unique, like a header or other eye-catching page elements with "regular" text. As only a few tags/styles are allowed, this implies that a different (and unique) input format is to be used for these fields. If all you need is <strong><em><u>, you probably don't even need an editor for that format. With more tags, or fewer markup-speaking users, an editor may be needed. No problem, you can set the profile to only show the buttons needed to use the available tags.
If you don't want an editor on your textfield, don't attach one to the input format used on textfields.
If you do want an editor, and it happens to be FCKeditor, then I'm sorry but you'll have to switch to a different one for now as this is a missing feature in FCKeditor (or reconsider why you're using a textfield).
What Sun mentions in #12, #13 and #18 boils down to us having to work around this by temporarily converting that textfield into a textarea before loading FCKeditor.
Endrant

WYSIWYG has disabled the ability to disable fckeditor per number of lines or on specific fields—I really think this functionality is a necessary component and should not be overridden.
Wysiwyg module has not disabled or overridden any such abilities as there are none to begin with. The editors just try to replace the element with the id/name sent to them by Wysiwyg, they don't really have much "to be or not to be"-logic on their own. In the case of FCKeditor, all it cares about is that the element is an actual textarea, because that's all it can handle. We may be able to get around this by using a temporary textarea, but I have not yet had time to look into this due to other priorities. This issue has a pretty low priority on my todo list because the case when FCKeditor must be used on a textfield seems quite rare.

Same bug observed here. I just used the cck 'link' module as explained above. The 'link' module provides options to allow the node creator to display text with or without a hyperlink. Satified my needs.

I had the same problem, and explanations from #17 helped me : don't check "filtered text" on a textfield or it will fire FCKeditor on this same field even if it's not a textarea (generating the error alert).

The same problem, #17 was the solution, but it is a bug anyway; textfield with filtered text makes sense in some cases.

Since FCKEditor has been replaced by CKEditor, I'll mark this a duplicate of #971632: CKeditor breaks on text field (not on field type Long Text). Once I get around to implementing a workaround for this problem, it'll be applied to both editors.