Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No post format classes added for styling in the editor #10640

Open
laurelfulford opened this issue Oct 15, 2018 · 11 comments
Open

No post format classes added for styling in the editor #10640

laurelfulford opened this issue Oct 15, 2018 · 11 comments
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.

Comments

@laurelfulford
Copy link
Contributor

Describe the bug

The Classic editor includes a class on the body of the editor content, loaded in the iframe, that indicates the current post's post format (eg .post-format-aside). This is helpful to adjust styles to match how that post format looks on the front end. Gutenberg doesn't include those classes.

Twenty Thirteen is one theme that uses these classes to create a more accurate WYSIWYG experience in the classic editor. Having the same ability with Gutenberg would help create a more consistent experience in the new editor.

This came up in this ticket here: https://core.trac.wordpress.org/ticket/45041

#8948 covers a similar issue (no page template classes are added to the editor); just let me know if it would make more sense to move this report over there.

@designsimply
Copy link
Member

(Asking just in case) can the theme add the body classes it needs? I noticed there is a similar discussion recommended that at #4418 (comment) but I also see that request is for page template body classes on the rendered page, which seems different enough that I am not sure the same reply is warranted.

@designsimply designsimply added [Type] Enhancement A suggestion for improvement. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. labels Oct 17, 2018
@chrisvanpatten chrisvanpatten added the [Type] Developer Documentation Documentation for developers label Oct 17, 2018
@joyously
Copy link

The classic editor does it with whatever code it uses. The new editor should just use the same code. It's already part of WordPress. Just call it.

@laurelfulford
Copy link
Contributor Author

@designsimply It sounds like it might be possible, but I'm not sure it'd be something we'd want to do in a default theme :) #8948 is probably closer in spirit to this ticket than #4418. In #4418 they're talking about adding new body classes to posts and pages that use blocks. #8948 is about adding a existing body class that's used on the front end and classic editor to the Gutenberg editor.

I might've confused things by creating a second issue for the post format classes -- the general issue is that the body classes that are available in the Classic editor aren't available in Gutenberg. Just let me know if it makes more sense to roll this into #8948!

@designsimply
Copy link
Member

Thanks for the open discussion. Adding post_class to the editor wrapper sounds cool and (I think) should cover both cases so I'll close #8948 in favor of this one since this one has attention from the docs group.

@designsimply designsimply added the Backwards Compatibility Issues or PRs that impact backwards compatability label Oct 18, 2018
@designsimply designsimply added this to the WordPress 5.0 milestone Oct 18, 2018
@designsimply
Copy link
Member

Related: #10067 (comment)

@laurelfulford
Copy link
Contributor Author

In the same vein, something else that would be helpful (and perhaps better covered in another ticket) would be to also pull in the body/post classes that the current theme adds.

The main use case I can think of is themes that add classes like .is-sidebar when there are sidebar widgets. This class is often used to do stuff like change the content area width, which would be awesome to reflect in the editor!

@mtias mtias added the [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later label Nov 12, 2018
@youknowriad youknowriad removed this from the Documentation & Handbook milestone Mar 18, 2019
@joyously
Copy link

Can someone put a higher priority on this, please?
The theme should not have to supply JS code for editor specifics in order to get the appropriate styles. There should be a way for the theme to filter in some body classes easily, just like the old editor (editor_settings).
Those classes should be applied to the editor container (editor_styles_wrapper?), not the body of the admin page.
Every environment, not just WordPress post editor, would want to be able to specify classes on the editor container. Please make it happen!

@designsimply designsimply added Needs Decision Needs a decision to be actionable or relevant and removed [Priority] Low Used to indicate that the issue at hand isn't a top priority to address and can be handled later labels Apr 15, 2019
@gziolo gziolo added Needs Dev Ready for, and needs developer efforts and removed Needs Decision Needs a decision to be actionable or relevant [Type] Developer Documentation Documentation for developers labels May 23, 2019
@celloexpressions
Copy link

This is still broken. It is impossible for themes using this long-present feature to make editor styles resemble the front end. Including Twenty Thirteen. This is particularly problematic for the themes that use different color schemes or font sizes for different post formats.

The editor should either be based in the front end, or exactly replicate its markup, to correctly represent the result of users' work. This issue is still a regression relative to WordPress 4.9.

@dashkevych
Copy link

This functionality would be really handy for fixing style inconsistency between the Editor and the front-end.

@antonyjsmith
Copy link

This is really needed and another several hours I've wasted to end up at an open Gutenberg issue that as @celloexpressions says is a regression compared to 4.9 :(

@strarsis
Copy link
Contributor

strarsis commented May 9, 2023

Any plans for adding this in the near future?
Being able to style a page/post by its template (slug) is a feature in TinyMCE that I also would like to see in Gutenberg.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability Needs Dev Ready for, and needs developer efforts [Type] Enhancement A suggestion for improvement. [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Projects
None yet
Development

No branches or pull requests