Changing the metabox style on the classic editor and other default metaboxes

• timbr

• November 4, 2020 at 12:43 am

Hi. I’m building a WooCommerce site and found… an opportunity to make things prettier.

ACF introduced (I believe) the seamless meta box style, and it’s great! It matches the tinymce editor much better. But, if there’s a lot of ACF field groups I sometimes choose the standard metabox, for the collapsing function. That still looks good, because the tinymce editor content is usually fairly detached from the custom fields content.

Now I’m doing Woo, and I get this: https://i.imgur.com/7p9hv5L.png

In a Woo product the tinymce editor saves the full description. The new short description is however just as important, if not more, and that’s a standard style metabox. I dragged it up, just below the full description so it is less likely to be skipped, and it is right below it’s big brother.

These two are handling very similar content, but look different. That is what I want to improve. Can this be improved?

I have a few suggestions, but I don’t know if they are possible. If you have any ideas on this please reply.

A. Make the short description seamless.
With this change the two description fields look similar. The product data metabox probably needs to remain standard. The custom field groups can be left standard, or made seamless. The reviews metabox can be made seamless by adding .acf-postbox.seamless. (edit) This may work for the short desc but needs tweaking.

B. Make the classic editor have a standard metabox around it.
If everything has a standard metabox, that’s nice looking too.

C. Hide default the classic editor and re-add it to a field group.
This way we can give it a standard style, and it all looks the same. Or we can make it seamless, and perform the CSS seamless hack on short description and reviews. It has the added benefit of being able to move the classic editor to any position. It still needs to function with the same data, not a new custom field, so it may be harder.

Is any of this possible? Lots of complexity for little gain, I know.

• John Huebner

• November 4, 2020 at 5:08 am

Not sure if this will help you, and I have not done this with WC.

Some time ago I decided, not long after guberbug gutenberg was released that I would not be using it. I also at that time decided that I will not be using the standard “Classic Editor” area for content. The reason for this is that there is no guarantee that classic editor will continue to be supported. However, I believe that ACF will always include a WYSIWYG field that uses tinyMCE. I also believe that there will always likely be a way to disable the new editor.

So, I remove all editors. I am currently using classic editor to disable the new editor and I use ACF to hide the default content field and I create my own custom fields that includes a field for the content if the post type calls for such a field.

Depending on what I am doing I either just show this field in the template instead of “the_content()” or I create an acf/save_post action that copies this content into “post_content”. For use with WC I would likely go with the second option of copying the content to the standard location because that way I would not need to mess about with WC templates in order to use my custom field.

In your case I would likely have two fields in one group, “Full Descriptiosn” and “Short Description”

• timbr

• November 4, 2020 at 6:58 am

Hey @hube2 . That sounds like a variation on C. I like it.

-edit-

• timbr

• November 4, 2020 at 7:55 am

Alright I got it working! I can get behind your choices, and this hook even feels like a future proof method, compared to modifying the DOM with JS.

For future readers: I’m still curious if there’s a (solid) method of adding a std metabox around the editor, and/or making native std metabox fields seamless.