Why do I want to do it? One word - "multigroups". If you haven't tried them yet in CCK (currently in version 3.x), then you're missing out! When I get in to work tomorrow, I'll show a screenshot of what I'm working with. But for now, I was able to find a work around of sorts.

First, there was a bit of code which specified the height of all WYSIWYG boxes to be 400px, which I commented out. This has the result of using the fckeditor default height of 200px, which was better for me.

Second, since there is code which I mentioned before that specifically disallows the changing of the height/width of a WYSIWYG box, I instead made the text areas the last item in the multigroup row and then specified the widths of all of the items before it. This allowed the text area to fill the remaining space. I would imagine though, that there could be times where it is not convenient to reorder form elements to make this accommodation.

If you don't know what code I'm referring to when I say that there is a function that disallows the changing of the width and height, I'll look it up for you. There is actually a comment there in the code that says 'prevent', or 'don't allow', or 'disallow' or something like that. You could do a search. I don't recall whether that was in fckeditor itself or WYSIWYG. I think it was in fckeditor since the dimensions are supposed to be passed in as constructor parameters. So... what I really need is a way to set the constructor parameters for each instance of the WYSIWYG.

obviously, you give them the default that now exists. But really, yes, I do think admins want this, which is why most of the basic CCK fields have width/length settings. I mean, the standard text area allows you to set the height, which this module also doesn't honor.

I realize that others haven't chimed in on this, but then again, this post isn't very visible. Without multigroups, which is in the 3.x version of CCK now and will be official soon, one can always move the text area to another line. With multigroups, you can't.

Configuring the height of fields is very important. If you need to create a CCK field which needs to contain a small amount of formatting information, you'll want to be able to keep those fields from blowing up your edit form vertically.

On every site we do, I configure at least five additional filtered-text fields for every node that is ever rendered as a page:

"Kicker" or "eyebrow" headline, to be displayed above the title, which must be able to include markup and special characters.

Alternate "formatted title", for cases where the Title needs to include markup or characters that can't be included in the standard node TITTLE field.

Secondary headline, displayed below the Title, which must be able to include markup and special characters.

Side Content field, to be displayed in the sidebar.

Abstract (Teaser) field, to serve as a teaser.

The first three need to be shorter than body copy fields, or you have the following problems with users:

Users are already intimidated by the many-page vertical scroll of a node edit form that includes extra fields and features; if you can't shorten the edit box, it gets even worse.

There's also a usability issue in that with fields having related function (e.g., the Formatted Title over-rides the Title), the very large boxes tend to force the fields onto different screens from one another.

They are liable to see the large size of textareas as a tacit encouragement to add too much text or do formatting that's not appropriate to the layout.

Short version: This is just something people need to do. Other editor modules support it. It's a significant usability problem to not have it. WYSIWYG is not a viable option for any site my company implements until this feature is included.

Just to add to the discussion... being able to set the dimensions of each field is quite an important feature. I often have textarea's that should only be 2 lines long, and others that should be significantly more, depending on the context.

"And why can't you use CSS to adjust the width of the surrounding container?"

@sun - I'm not sure how to make this work. I'm using fckeditor and have been playing around with the CSS for quite awhile to get it to the right height. In FF this isn't a problem, but in Safari the scroll bar goes far beyond the end of the textarea when I do this. Basically the surrounding container's height is shorter, but the inner container isn't respecting that in Safari at least. How can the height be set properly using CSS? I can attach a screenshot if that would help.

I think I mentioned in another issue that a bug related to FCKeditor not always respecting the textarea's height got fixed recently in the FCKeditor library. Could you try with the latest version and report back?

im using the latest version of fck editor - http://ckeditor.com/download, ckeditor is not supported right? or i should say with imce. i want whatever editor is going to work with imce or some kind of image uploader

I can change the width by overriding CSS values for CCK text area's which get a unique id e.g. #edit-field-textarea-0-value-wrapper.
But this will give problems with multiple content types that need different widths.

edit: created a unique body class for each content type which allows me to target each individual content type.

I have a similar issue, which perhaps could fall into a different request, but I'll put it here and leave it for you to decide.

I'm using WYSWYG with CKEditor

A project I'm working on requires very customized node edit displays, that differ substantially per cck node type. Substantially not just in CSS look and feel, but in layout and additional form elements.

I want to be able to customize each CKEditor depending on what the node type is, and again depending on what display that is.

I'm using

module_wysiwyg_editor_settings_alter(&$settings, &$context)

to alter the width and height settings using arg(n) checks to see where I am.

But one would think you could add a 'node' index to the $context array - so that a coder can more cleanly make adjustments to the size and shape of the editor depending on node values.

Maybe we should do this calculation in the editor implementations and just store the number of rows here?
The reason being we don't know how many toolbar rows there will be. (Actually, the implementations don't know that either yet, so I think we could change that later if needed.)

1) We should make sure that modules that are altering profile settings can override this value. Not sure when the drupal_alter() actually happens, but ideally of course, the pre-calculated height should be contained already (i.e., making the alter come afterwards).

2) Looks like $field['#rows'] is presumed and required to exist? Possibly the test should have been !empty().

3) Do I need to understand the -1 (minus one)? A field having 1 row will lead to a height of 0 (zero).

The methodology in #22 is mostly working for me with ckeditor. My only problem right now is that a CCK multi-line text field is not honoring the number of rows in a node creation form. I'm using the Rubik theme if that matters (not sure why it would). The strange thing is that TinyMCE seems to honor the number of rows properly within the same form.\

This also doesn't seem to be working if there are multiple fields on a single form w/ different row values. For instance, I have 4 textareas on a single form, but wysiwyg_ckeditor_settings is only being called for the first one (and the rest of the textareas are using the same settings).

It's caching by format, not by a particular field's format. Since these could each be unique, and fields shouldn't repeat, this needs to be rewritten so that it works on a per-field basis and not a per-format basis.

Thanks for working on this! However, it seems like this patch is now touching logic that is essential for all editors. It doesn't look like it has been tested with any other editor than (F)CKEditor. Those changes require some careful review, but also testing all other supported editors.

It seems to work for me using CKEditor. I am only using it for 1 field and I dont allow them to add another. It is also very limited with buttons like bold, italic, underline, etc. I haven't seen any issues yet but haven't tried to do anything out of the normal for a basic user.

@Dave, would you mind moving the hard-coded constants added to the calculations out to the editor implementation files while you're at it? That way the height/width can accomodate for variations in toolbar heights etc between editors.

I haven't tried the patch in #30 yet, but one of the things worrying me is that on a page with a lot of format-fields, Drupal.settings.wysiwyg.configs might become huge as all format settings are duplicated per field, except for the width/height. (Sorry if I'm misinterpreting the patch.)
I would rather have per-field settings stored somewhere separate (maybe Drupal.settings.wysiwyg.configs.fields[field][editor], if they aren't going to be different per format). Or something like the global per-editor settings, so these can be merged together from "normalized data pools" (thinking of normalized SQL tables here) with as little duplication as possible.

Sidenote:
That reminds me of a possible issue in D7 now that formats have machine-names... currently they are all stored with a 'format'-prefix, but if we eliminate that we'll get issues if someone names their format "global". Maybe we should keep prefixes after all...

@highrockmedia, the easiest way to determine that is by looking at the status and version fields. We roll new features/fixes for 7.x-2.x-dev when an issue reaches RTBC, then we backport to 6.x-2.x-dev (if this doesn't happen immediately the issue is marked "patch (to be ported)") and finally mark it "fixed" once committed to all relevant branches.
So, this patch has not made it to CVS for any version yet, because of the problems mentioned in #45 and #46.

Those recommending to use CSS for width, can you please elaborate which id / class it could be applied to for CKEditor? I successfully adjusted the height by the following (making editor less bulky for the comment entry):

.comment-form .cke_contents {
height: 150px !important;
}

But this does not work for width, and there are so many layers of encapsulation, divs upon divs, and I may be missing something - applying width to some elements does not help, applying it to others breaks the editor.

@DrupalRevisited -- Just curious about your solution in #57. Where and how do you implement this? Is it a module, in template.php or are you hacking an existing piece of code that could get overwritten later?

#65 worked for me on standard node fields, but caused problems when using Field Collection module.

Say I have a field collection defined with a long text field and using WYSIWYG formatter. I can create a node and fill out the first field collection entity. When I click to 'add another item', the WYSIWYG editor disappears and the field blanks out.

It turns out they don't play nice together, but if you apply the additional patch I've attached here, that makes it so they do. (Since that other issue looks like it will probably be committed soon, the attached patch will need to be merged into this issue's main patch once that happens. But for now, it's only needed if you're trying to make both patches work together correctly.)

Patches in #65 and #70 failed to apply with git. Had to use patch -p1 < wysiwyg_per_field.patch to pull in the code from #70. Re-rolled the patch in #70 against the latest 7.x-2.x branch. Patch generated with git diff > wysiwyg_height_per_field-507696-75.patch and confirmed that it applies correctly using git.

This functionality is great...no more gigantic wysiwyg editors that completely ignore the field's rows setting.

While I had to apply the changes in the patch manually, adjusting for some code shifts, the code in patch #75 also appears to work with CKEDITOR on version 6.x-2.4. I did not patch the other editor include files.

#75 is working-ish for me, but there are some issues with Field collections as mentioned in #71 and #73. This might be an issue for all fields where number of values are set to "unlimited" (so you get the "add another item" button), but haven't tested that.

* The editor is there when you start, but after you click "add another item" the textarea (with content) for the first item disappears completely
* The new textfield in the new collection is there, but with no editor
* I am not able to add a third collection after this
* ..however, I can save the node and the two first collections are saved. On editing the node again I can add one two more, save, add two more etc..

So I tried my hand at debugging the issue in #86 - Text Fields in Field Collections with WYSIWYG editors.

I wasn't able to fully figure it out, but I think I have some good observations that someone may be able to leverage in narrowing down a solution.

The problem seems to be that in the UI, the data is not transferring between the WYSIWYG editor and the actual text field in the background. So if I enter "Hello World" into the WYSIWYG, and then switch to "plain text" mode which displays the text field (an <input> control) the value is empty. Further, if I enter "My name is Joe" into the text field, and then switch back to the WYSIWYG editor, it will still display "Hello World" instead of my new value. If I save the node, "My name is Joe" will be successfully saved from the text field. On viewing the node again, it will appear that the value is not there if I am looking at the WYSIWYG editor, but if I switch to plain text mode the value will indeed be there.

So as I said before, it appears the issue is with communication of the value between the WYSIWYG editor and the text field. I think a very indicative symptom of the problem is something I noticed in the HTML (using firebug) after modifying the value in the WYSIWYG editor and then switching to plain text mode. Though the "value" of the <input> field is not updated to match the WYSIWYG editor value, the value of the WYSIWYG editor is inserted as a node to the <input> tag. i.e. instead of <input value="val from wysiwyg"/>, I get <input value="old value">val from wysiwyg</input>

So something in ckeditor is making it think that it gets and sets the value of the Text Field by getting/setting the innerHTML of the node instead of the "value" attribute. When I look at the ckeditor.js library (I have 3.6.3) I see some code that leads me to believe this is indeed happening - i.e. l=m.is('textarea')?m.getValue():m.getHtml(); Note that this field is an 'input', not a 'textarea', so this logic will indeed pull the innerHTML instead of the value.

This is as far as I am able to take it at this point, due to time constraints and the fact that I dont have the time to try to figure out how to generate an uncompressed version of ckeditor.js to better debug. I'm hoping these clues can help someone else figure it out.

For all Drupal 6.x'ers still around: I can confirm that you can apply modifications from #75 patch on 6.x-dev "manually".
That is, looking at the patch code, and change wysiwyg.js,wysiwyg.module and ckeditor.inc.

Update: patch #96 no longer applies to latest dev, and patch #106 (as mentioned) was created from Drupal root instead of the wysiwyg directory (it also causes a fatal whitespace error from last file line).

From a functional perspective I can also conform that this applies and works well. However, given that it makes adjustments for multiple wysiwyg editor flavors (ckeditor, fckeditor, tinymce) it might be useful to the maintainers if we can confirm that #114 works correctly for each. It does not look like the confirming reviews above note which editors have been checked. Currently I can confirm that things work great for ckeditor, and a look at the patch makes me pretty confident things are fine for the other editors (after all they each appear to just take a px "height" config param), but it might not hurt to confirm that.

From a code perspective the changes seem pretty innocuous, though it's not clear to me why a couple conditional checks were removed from wysiwyg_add_editor_settings(). Comment #29 alludes to the changes in this function, but it does not explain the final changes made. Perhaps there were just a couple unneeded sanity checks in there that were safely pulled out?

Hummmm, looking more it's not clear if the issue about Field collections was resolved (#71, #73, #86-89, etc.), or even if that would be a show stopper for this.

Also, I assume the concerns from #45 are non-issues now? I think that was back when this was against D6, so maybe it's irrelevant? This issue is so old it's really hard to keep track of things and do a comprehensive review.

I'm not going to change the status, but wanted to raise these questions in hope that they can be addressed before becoming commit-blockers.

Hmm, the patch is no longer passing settings through the new processObjectTypes(), so it would no longer be possible to use settings which require Function references or RegExp values. For example, TinyMCE 4 changed their file browser callback setting from being a string in TinyMCE 3 to an actual Function reference, so we need this for the TinyMCE 4 support patch to not break compatibility with IMCE Wysiwyg bridge, and thus IMCE.

Also, I'm starting to think that it would be much handier to have this implemented in the .js files, in the attach methods specifically. That way, the calculations can be done based on the actual height of the textfield, even if it has been resized while the editor was disabled (resizing the hidden field in when the editor resizes is trickier since few of them seem to fire events for that).

It would make the patch smaller, and not require all profile settings to be duplicated for each field. That is still relevant for D7 because Drupal.settings grows quickly with the current approach and has to be regenerated on each page load.

Sorry, bumping this back to "Needs work", but I also promise I'll have a look at respinning the patch tonight (at work now).

These editors automatically adapt their height on attach:
jWysiwyg, markItUp, NicEdit, TinyMCE, Whizzywig, YUI.
Didn't verify if all of them actually provide height settings, but I don't think that really matters since they auto adjust.

These editors needed "manual" height adjustment:
CKEditor, EpicEditor, FCKeditor.
Some hardcoded height values in our implementation were removed but can be altered back in to override automatic adaptation.

Others:
WYMeditor: NOK; height completely controlled by skin. Forcibly override with inline styles on its iframe?
I only had v0.5-rc1, which is several years old, to test with. Looks like the project switched away from its old site and is now working from github and closing in on their 1.0.0 relase: https://github.com/wymeditor/wymeditor/releases
I completely lost track of this editor so I created #2273635: WYMeditor 1.0.0 release to deal with its newer versions instead.

Now, I know the name of the issue says "width/height", but the patches and discussions so far have focused on just the height, which seems to be the main issue. This patch only adjusts the heights, but could easily extended to widths as well. From what I could tell, all editors appeared to use the textarea width though (or the width of its container), but I can add widths in too now, or later, if desired.

I agree about FCKeditor, but I don't mind keeping the implementation "alive" until a major version change. I know a few people are still using it and it's not been that difficult so far.

Pushed the patch to 7.x-2.x and 6.x-2.x, gave credit to the people who put most work into this from the beginning since they were so patient with me. ;)

One small note: This patch will also adjust heights for summary fields, but it's still not possible to set an explicit height for summary fields which is different from the main field. That can be added later though.