Home › Forums › Feature Requests › WYSIWYG Height

This should be a feature, as simple as that. Please please please add this. It was a request since the dawn of time when ACF started and there are various topics and posts on it and the feature request was marked as solved because someone came up with a code fix.
However that shouldn’t be needed. It should be possible to do it in the ACF UI.
It’s incredibly inconsistent to have a textarea field allowing a height setting and not the WYSIWYG field.
Please do the decent thing and get this tiny change implemented, it will save so much time!

Requests really need to go to the devs, they don’t frequent this forum. You can use the contact form or you can open a ticket in your account.
@hube2 your contributions to ACF and this forum have been monumental. I’ve been an ACF member since ~2014 and your name has always come up with wonderful answers and suggestions
…but this request has been made countless times to the devs. Since the inception. People are resorting to this because it falls on deaf ears.
Obviously with blocks and ACF Blocks, the need for a WYSIWYG editor has gotten smaller and smaller but after creating themes/blocks for countless clients, I can tell you, the demand for a clean interface and minimal WYSIWYG rich text editor is just as meaningful now.
I still use this snippet to tackle this issue:
function PREFIX_apply_acf_modifications() {
?>
<style>
.acf-editor-wrap iframe {
min-height: 0;
}
</style>
<script>
(function($) {
acf.add_filter('wysiwyg_tinymce_settings', function(mceInit, id, $field) {
mceInit.wp_autoresize_on = true;
return mceInit;
});
acf.add_action('wysiwyg_tinymce_init', function(ed, id, mceInit, $field) {
ed.settings.autoresize_min_height = 100;
$('.acf-editor-wrap iframe').css('height', '100px');
});
})(jQuery)
</script>
<?php
}
add_action('acf/input/admin_footer', 'PREFIX_apply_acf_modifications');
and it works great in most cases. However, one quirk still persists.
If I add a repeater row, the WYSIWYG is the correct height and the fields are all condensed to be the height of the largest field within that row.
If I save and refresh the page, every field within the row is given a minimum height which I believe is being set based on the size ACF *thinks* the WYSIWYG field is. There ends up being a fair amount of white space below the WYSIWYG editor and each .acf-field has been given a minimum height CSS value.
If I add a new row, or delete a row, it resizes all of the field heights to the correct minimum height and everything nice and tight.
So the action to evaluate the current height of the fields, get the largest field height and set them all to that seems to be firing 1) when a new row is added or 2) when a row is deleted, but not when the page first loads.
I’ve tried to modify when the action is called, whether init or admin_head, etc.
Perhaps you can provide some insight as to when that hook/action gets called and if there’s another method to ensure that when ACF evaluates the field heights and sets their minimum, it’s accounting for the modified WYSIWYG field height on page load.
Thanks.
It’s now been over three years since this thread was marked as “Solving”, yet there hasn’t really been any update or ETA.
At this point, I’m starting to wonder whether this is ever going to be addressed.
On the surface, this seems like a relatively small feature request, but it has a surprisingly large impact on the editing experience for sites that make heavy use of WYSIWYG fields—especially when they’re nested inside groups or repeaters, where the interface quickly becomes cluttered due to the minimum height.
Could we please get an update on the status?
This would actually be fairly straightforward to work around in PHP using acf_update_user_setting(), if it wasn’t for the hardcoded minimum height of 300px in advanced-custom-fields-pro/fields/wysiwyg.php:
$height = max($height, 300);
There are even forum posts dating back to 2016 from users asking for a simple way to customize the WYSIWYG height. Ten years later, there’s still no built-in solution.
As an immediate improvement, simply removing the max() call would allow developers to set smaller heights themselves, while remaining fully backwards compatible for anyone who doesn’t override the value.
Longer term, the ideal solution would of course be to expose the editor height as a field setting, allowing everyone to configure it without writing custom code.
Either way, it would be great to know whether this is still actively being considered or if it’s no longer on the roadmap.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.