• Hi,

    I’ve run into an issue with the ACF WYSIWYG field height that I believe should be reconsidered.

    By default, the WYSIWYG height is set to 300px, which is perfectly reasonable as a default. The problem is that while ACF provides mechanisms to override this value (such as acf_update_user_setting() and various field filters), the source code ultimately enforces a minimum height through:

    $height = max($height, 300);

    This means developers can increase the height, but can never reduce it below 300px.

    I genuinely don’t understand the purpose of this limitation. If a developer is knowledgeable enough to use ACF filters and user settings to customize editor behavior, they’re certainly capable of choosing an appropriate height for their project.

    This restriction has been frustrating developers for many years. While researching the issue, I found discussions dating back to 2016 where people were already trying to work around this limitation. The available solutions are all hacks of varying quality:

    • JavaScript overrides (which can be unreliable with delayed TinyMCE initialization, repeaters, AJAX-loaded fields, etc.)
    • Output buffering and string replacement
    • CSS workarounds
    • Other fragile approaches that shouldn’t be necessary

    In many projects, especially when editing content on smaller screens or laptops, a 300px editor can be unnecessarily large and consume a significant amount of vertical space. There are valid use cases for much smaller editors, such as short descriptions, button text with formatting, teasers, notices, and similar content.

    Would you consider removing the minimum-height restriction entirely, or at least making it filterable?

    Removing the max() call would not introduce any breaking changes for existing sites because the default would remain 300px. It would simply allow developers who explicitly opt into customization to choose a smaller height when appropriate.

    Thank you for considering it.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Hi @boutzamat,

    ACF Support Team here.

    Thank you for taking the time to write up such a detailed and well-reasoned feature request! You make an excellent point regarding the max($height, 300) limitation and how it forces unnecessary CSS or JS workarounds for perfectly valid use cases like short notices or teasers.

    I completely agree that developers should have the ultimate flexibility to override this minimum. I have logged this directly with our product team lead for review. Additionally, I highly recommend submitting this to our official feature request board at feature requests. Adding it there allows the rest of the community to upvote it, which greatly helps our engineers prioritize updates on the roadmap!

    We truly appreciate you bringing this to our attention and sharing the historical context. Please keep an eye on our future release changelogs.

    Best regards,
    Patroba

    Thread Starter boutzamat

    (@boutzamat)

    Hi @patroba , thank you for taking the time to answer this.

    Yes, that is exactly the case where it makes sense to have a minimal height Wysiwyg field. CSS requires the use of !important, meaning even if the user tries to resize it, it it’s now a fixed height. JS is somewhat better, but still not ideal for dynamically initiated fields like in a flexible content or repeater field.

    I understand that you won’t just remove the max function overnight, but it will really be a huge W when/if you add a filter to override the value of 300. It’s basically 1 line of code 😀

    Since you have already forwarded this to your product team for review, does it still make sense for me to create a feature request? I feel that the feature requests isn’t something people see that often, causing the request to not have many upvotes, and ultimately, won’t be prioritized by the product team. I could be wrong though.

    Once again, thanks a lot for the time to reply.

    Hi @boutzamat,

    Totally get your point about the CSS !important hack ruining the manual resize ability; definitely not an ideal workaround when dealing with flexible content!

    To answer your question: yes, I would still highly recommend dropping it on the feature request board. Even though I’ve already put it directly in front of the product team, having it on the public board creates a permanent, trackable request. Other developers searching for this exact workaround will be able to find it and add their upvotes. Plus, our team actively monitors that board for “quick wins,” and since adding a simple filter is really straightforward, having it logged publicly only boosts its visibility and chances of getting patched in sooner rather than later.

    Thanks again for pushing for this, it’s feedback like this that helps make ACF better for everyone!

    Best,
    Patroba

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.