| Project: | Wysiwyg |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
I don't mind writing this myself if I can make the time. What I'd like to do is add a section to the config for each profile that lists the textarea fields and then provides width and height boxes to fill in. I would save the values along with the others in the DB. I see where the current module sets all widths to 100% (in wysiwyg_fckeditor_settings). And I see that there is a '$config' variable being passed in. But I'm having trouble figuring out where the wysiwyg_fckeditor_settings function is called and also whether anything is passed in which identifies the field itself that could be used to key off of the width and height settings I want to save.
Some things that might help me figure this out:
What function makes the call to wysiwyg_fckeditor_settings?
What calls that function, and what calls that one, all the way on up? I think a function call tree would help here. That way, I'd be able to figure out how to get a field identifier and pass it on down.
Make sense? Why do it? There is a function in fckeditor or in wysiwyg (I don't recall which) that prevents changing any style elements of the iframe in which the editor is placed.
Could this be generalized somehow for the other editors? I don't know.
Comments
#1
Looking at wysiwyg.module this is what I find:
wysiwyg_process_form(&$form)wysiwyg_add_editor_settings($profile, $theme)
$config = wysiwyg_get_editor_config($profile, $theme)
$settings = $editor['settings callback']($editor, $profile->settings, $theme)
Hope that helps a bit.
#2
Why do you want to configure the width and height per field in the first place?
And why can't you use CSS to adjust the width of the surrounding container?
#3
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.
Make sense?
#4
well, multigroup or not - do you think that admins will (and want to) configure editors separately for every single field in their Drupal site?
#5
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.
Try multigroups before you decide one way or the other.
#6
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:
The first three need to be shorter than body copy fields, or you have the following problems with users:
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.
#7
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.
- Scott
#8
Also, I notice that this has been set to "postponed (maintainer needs more info)" for quite a while. What info do you need for this to move forward?
#9
Here's a patch that's basically just a quick hack using the $rows attribute of the textarea field. I'm not sure how reliable converting rows into pixels is, but it seemed to work ok for me.
#10
#11
Any headway on this? It seems like the FCK editor should adjust height based on the number of rows in the textarea so we don't have to do this granular adjustment.
#12
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?
#13
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
#14
If you ask that, then you are at least not using the latest version of Wysiwyg module. ;)
#15
I'm using version 6.x-2.1, what am I supposed to be using?
#16
Subscribing.
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.
#17
subscribe (using ckeditor)
#18
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.
#19
Thought about this more.
Would actually be smarter to append the $form object somehow to the $context, as that would deal with more situations.
#20
I agreee with #11, the editors heigth (and possibly width) should adjust to the nr of rows (cols) provided in cck.
#21
#9 works for me with TinyMCE editor. Thank you! I am attaching modified #9 patch for TinyMCE and FCKEeditor.
#22
This approach makes sense to me - rather than deciding all textareas must and shall be 420 pixels high, why not estimate based on #rows?
I'm attaching a reroll that adds ckeditor support and fixes minor code style issues.
#23
+++ wysiwyg.module 23 Jun 2010 00:44:35 -0000@@ -170,6 +170,10 @@ function wysiwyg_process_form(&$form) {
+ $profile->settings['height'] = $field['#rows'] ? 40 + 29 + 15 * ($field['#rows'] - 1) : 400;
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.)
+++ wysiwyg.module 23 Jun 2010 00:44:35 -0000@@ -170,6 +170,10 @@ function wysiwyg_process_form(&$form) {
+ ¶
Tab. ;)
No need to reroll for that.
Powered by Dreditor.
#24
+++ wysiwyg.module 23 Jun 2010 00:44:35 -0000@@ -170,6 +170,10 @@ function wysiwyg_process_form(&$form) {
+ // Rough estimate of textarea height in pixels:
+ // 40 for the toolbar, 29 for the first row, and 15 for the rest.
+ $profile->settings['height'] = $field['#rows'] ? 40 + 29 + 15 * ($field['#rows'] - 1) : 400;
+ ¶
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).
4) MONSTERTABMONSTER.
Powered by Dreditor.
#25
1) I assumed the alter hook would be called after this, I might be wrong though, need to check the code.
2) You're right.
3) "29 for the first row", 1 row means 40+29+(15*0) pixels. This is part why I wanted to move this calculation to the implementations, those constants may not be valid for all editors.
4) =P
EDIT: Had missed a quite important little word, see highlight above.
#26
subscribing
#27
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.\
Any thoughts?
#28
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).
#29
Oh, this is happening because of this function:
function wysiwyg_add_editor_settings($profile, $theme) {
static $formats = array();
if (!isset($formats[$profile->format])) {
$config = wysiwyg_get_editor_config($profile, $theme);
// drupal_to_js() does not properly convert numeric array keys, so we need
// to use a string instead of the format id.
drupal_add_js(array('wysiwyg' => array('configs' => array($profile->editor => array('format' . $profile->format => $config)))), 'setting');
$formats[$profile->format] = TRUE;
}
}
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.
#30
OK, here's a patch that addresses the issue I mentioned in #29.
Re: sun's first issue in #24: the drupal_alter comes after the height computation here, so it's not an issue.
#31
@mcarbone, thanks!! initial testing with your #30 patch seems to be working great.
#32
This patch in #30 worked with ckeditor.
Thank you!
#33
#30 works with ckeditor for me too. Thanks a lot!!!!
#34
#30 works nice (tested for FCKeditor 2.6.6. so far), resolved my strong headache, thank you!!!
#35
#30 <-- works perfekt!
This is the fourth test and considered to be rtbc.
I tested this with ckeditor and fckeditor.
Very good patch!
#36
patch #30 worked for me. I'm using recommended version 6.x-2.1. Had some offset's show up when running the patch but it still worked. Thanks a lot
#37
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.
#38
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.
#39
Hmm, this is not good..
If we need this feature, it sould eliminate the wysiwyg profile cache system complete, if the a field has #row attribute.
This happens, if preview something: #939258: ckeditor disappears if pressing preview
I don't know, what would be the best, maybe a checkbox in profile edit form, to enable resize editor made on textarea #row settings..
#40
For CCK fields there is this patch for the standalone CKEditor - it adjusts the height of editor by CCK field setting http://drupal.org/node/869116
#41
Seeing same issue mention in #39 (CKEditor disappear when user is previewing a node as a consequence of patch at #30)....:-(
#42
I can confirm this problem. Any suggestions for how to get around this? The width patch is very important but so is this issue of the node preview. Thanks for your help.
#43
#30 worked like a charm but crucial to note that it only worked against 6.x-2.1. This solved a lot of headaches for me. thanks.
#44
Subscribe this is really useful. I'll work on re-rolling this for 7.x-2.x tonight.
#45
@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.configsmight 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...
#46
I share the concern about duplicating the entire editor settings.
Long-term, we need an inheritance cascade of
global » format » fieldsettings. For this issue, we need to introduceformat » fieldoverrides.#47
Is there a way to tell if the patch has been rolled into the latest 6.x dev version?
#48
@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.
#49
@TwoD - thanks for the info. :)
#50
subscribe
#51
I tried to fix the issues, but failed. We need some help from an experienced maintainer. #46 is not enough clear to me.
#52
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.
Thanks for any help!
#53
Subscribe
#54
+++
#55
Subscribing
#56
I've manually applied the patch in #30 to Wysiwyg 6.x-2.4 with CKEditor and encounter this error on any page with a Wysiwyg field:
Fatal error: Cannot use object of type stdClass as array in .../sites/all/modules/wysiwyg/wysiwyg.module on line 367
That's the line:
drupal_add_js(array('wysiwyg' => array('configs' => array($profile->editor => array('format' . $profile->format => array($field['#id'] => $config))))), 'setting');
The patch appeared to be designed with Drupal 6.x. Have I overlooked something, or does this not work with the 2.4 version?
#57
My quick and dirty solution:
$form['MYTEXTAREA'] = array('#type' => 'text_format',
'#attached' => array(
'js' => array(
'MYTEXTAREA = setInterval(function() {
if (jQuery("#cke_contents_edit-MYTEXTAREA-value").length == 1) {
jq("#cke_contents_edit-MYTEXTAREA-value").css("height", "100px");
clearInterval(waiter);
}
},1);' => array('type' => 'inline', 'scope' => 'footer', 'weight' => 5)
)
)
);
Change '100px' to your desired height.
#58
subscribe
#59
Subscribe. (Using ckeditor and 7.x and could really use this feature.)
#60
Subscribe... for D7 and CKeditor
#61
Ditto.
#62
@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?
#63
Yep, patch #30 alone works for me! Using D6.22, wysiwyg-6.x-2.4, CKEditor library 3.6.2
Serious thanks mcarbone. Ups the usability 10fold!
#64
Patch #30 works, though as stated above it breaks the node preview, but that's not an issue for me. Many thanks!
Attaching the same patch, but made with git and slightly modified to work with wysiwyg-6.x-2.4.
#65
I understand and agree with the maintainers' concerns in #45 and #46 but I don't know the module well enough to do that kind of refactoring. So in the meantime here's a version of #30 rerolled for Drupal 7, for those who need it. Conveniently it doesn't break node previews anymore. I'm guessing that's because #208611: Add drupal_array_merge_deep() and drupal_array_merge_deep_array() to stop drupal_add_js() from adding settings twice got fixed in core. So the only problem I see with the D7 version of the patch is the architectural concern.
#66
Check the following posts for a solution:
http://drupal.org/node/1332210 -> D7 version for http://drupal.org/project/textarea_expander
And this issue from the D8 core: http://drupal.org/node/432730