Making Posts editor client friendly

I think you only need to apply such css @owynter if your use case requires a full width template on the front-end but you need to limit the size in the back-end for the clients for better readability.


I will add, anything we can do improve to make things easier for users who are creating content is very important to me, your points are put down in my feature tracker. So I’ll definitely be looking at your suggestions and see how we can achieve better results all around.


Back-end only custom CSS per block basis is something I would find quite useful @Louis.

I know we can currently take advantage of e.g. the .editor-styles-wrapper, but that would also load on front-end inside the stylesheets then.

I think that’s what @owynter was looking for (in general) as well, just in a more specific way.

No @Louis , I wouldn’t say you’re missing anything. Having some of my boilerplate styles defined in a stylesheet has been a more efficient way of working, certainly before many of the improvements to Cwicly were made (such as to global styles). In some instances, it still is. Fiddling with the GUI is often not the quickest way to get certain things done.

I think I can move a lot more of my workflow over to Cwicly now, but this hasn’t always been the case. I’ve had to deliver a number of production sites over the past few months, while Cwicly has been maturing and adding features.

So, on the plus side, it seems I can streamline some more within the native environment, but this will have to come later on when I’m not under the current time pressures. Maybe a holiday project.

This isn’t functionality I was aware of, so thank you for that. I never use the block editor for template post content - mainly just for client ease of use - until now, so how this affected the backend has never been a consideration. This is very good to know.

I think we can consider my issue solved.

If you need to limit the CSS to backend, you’re looking for it to load in admin_head
I use Advanced Scripts, which allows to specify where code runs. Other script plugins would offer the same.

1 Like

I don’t do many projects that require clients add content, and certainly not use the block editor, but this one will be a good case study for me. I will report any feedback from them.

Typically, I just keep things very simple in ACF, so they’re just entering text and images, and not having to be concerned about formatting and design, which they appreciate.

1 Like

I am referring to an in-built block option, just like the custom css option inside the advanced tab.
The Cwicly code block is the route I would prefer currently.
Won’t leave FSE for something which is placed inside the canvas to make tweaks inside a custom code plugin.

Thanks for the suggestion.

Fair, but in the case of a backend tweak, you’d need to have the block editor open to access your code, no? Or maybe I’ve misunderstood what you’re trying to accomplish.

@owynter yes, exactly.
But not sure if I can follow you either :smiley:

Currently, when making tweaks to a block inside the block inspector’s custom CSS area, making it to the back-end exclusive, you need to write something like:

.editor-styles-wrapper.blockclass {
/*your styles here*/

Even though the styles only apply on backend, the rule will load inside your stylesheet on front-end as well.

Something like a toggle that enables a 2nd code editor area below the blocks’ custom CSS area without the necessity to prepend the editor-styles-wrapper class and won’t load and apply the rules on front-end was my original idea.

Hope that makes sense.

I would add to this topic, that would be good to pass in the backend the classes applied to the post content.

So for example if for a post type, at the template level, on the Post Content block I add a global class (let’s say .post), in the post edit in the backend, everything will be wrapped inside that class.

Then everything inside a global stylesheet that targets that .post class will reflect also in the backend.


Hey there @Louis , I am working to make my client’s experience as smooth as possible as well and, as you know, I am more of a project manager and less of a developer. So, while I have been building Wordpress sites for 20ish years and I understand the infrastructure of a WP site and theme I still am being introduced to many intricacies of that construct daily by using Cwicly. So thank you for that!

As I read through your reply to @owynter in an attempt to create a useable space for my own clients I receive my first gold nugget and that is that within the Global Styles section of Cwicly (and, therefore, I imagine a properly coded wordpress theme) there is not only your basic ‘style sheet’ section ie: Typography tab but also Elements including Block Typography and deeper styling options for site elements (paragraph, links, images etc …).

So, if I understand correctly, the Block Typography section allow us to create style types for text components that we can apply to our pages and posts as we build them - similar to the ‘Styles’ component in Word. Is that basically a UI-enabled class?

I was today years old when I learned that and I am so pleased to know it now and I absolutely want you to correct me on this if I am wrong.

What I don’t see here is a way to make the content in the post edit screen not fill the entire width of the screen.

The way this reads for me is that you are suggesting we style the Post Content Block on the template which, I imagine, will have an impact on the front end rendering of the content. However, I fail to see how it will have any impact on the back end, data entry area. Also, I don’t see where I can enter that in the Global Syles section.

I am eager to understand better how I can address this matter. And I thank you and everyone else in this fantastic community for their time :sunglasses:

Screenshot below is of the data entry area I am referring to, the content is jammed up against the sides of the data entry container in a way that makes the content entry process very uncomfortable:

Hi @smontreuil ,

As I happily found out myself, through doing exactly what @Louis described, yes, any styles you apply to the post content block are indeed reflected perfectly in the admin interface.

This allows you to customise each post types editing experience individually to reflect the front-end display. Cwicly global styles are also automatically applied to the editor, so you don’t need to do anything special or extra to make that work.

One trick that I recommend that really worked well (if it is applicable to the blocks you are using in the post content), is to use a universal relative style on the post content block that sets the max-width on all direct children (rather than on the post content block itself).

By doing this, it allows whatever background colour you have applied to the post content block to fill the entire editor, while correctly constraining the blocks inside.

Here are the settings I used to centre the content within the editor to a max-width using a relative style (named All elements).

Screenshot 2023-03-29 at 01.33.56

I hope this gives you some inspiration.

The obvious caveat is that any styles, including max-width you set must also work correctly on the front-end. This is relatively straightforward because the intention is usually to match the editing experience to the front-end display, so as long as you apply those styles using the post content block, everything just works in both places.

1 Like

Also, it goes without saying that, if you want to right align your content instead of centring it, you can just remove the auto value from the right margin style.

Wow, @StrangeTech , this is kind of blowing my mind :face_with_peeking_eye:

I am trying very hard to understand exactly what is going on so that I can integrate and adapt … I see that you have definitions for each of your Header styles and also Paragraph … I replicated your All elements definition and that worked flawlessly to center everything in my data entry screen … except for my paragraph content.

So, I am guessing that I need to create a similar definition for that but I can’t quite wrap my head around how to do it. Would you be so kind as to share a screenshot of that definition?

This is what my data entry screen currently looks like:

Have you set a max-width on your Post Content element in the template?

(Don’t forget to set margin: auto for your left and right margins, so that the content is centered).

Edit: sorry, I totally misread your post!

1 Like

The power of Cwicly! With so many other website tools having so many frustrating limitations, it is a pleasant surprise to use one as flexible as Cwicly.

There is an issue with style overrides in the Post editor as mentioned by @owynter earlier in this thread:

If you experience this issue, as @sunny mentioned, the solution is to apply the auto value to the left and right margin for the specific element in the relative styles. Add the following to your relative style for paragraphs and it should resolve it:

1 Like

I apologize for being obtuse but this is exactly the part that I need the guidance on

This is where I am getting stuck:

Watch Video

No problem, once you get your head around it, it becomes a lot easier to follow.

When you set up the Relative Style you need to add the rule that targets the p tag.

  1. First click on the Rules button for the Relative style:

  1. Then you can configure the rule to target the p tag:

Relative Style Rules


Awesome @StrangeTech , thank you!

Hi @owynter,

I’m also concerned about clients editing posts, and after some trials and errors, I finally ended up with this simple CSS for post/page editing:

.is-root-container.wp-block-post-content {
    max-width: 80ch;
    margin: 0 auto;
    padding: 1em;

I tried to find something like this before in vain, but today it looked obvious with the ‘.wp-block-post-content’ added to ‘.is-root-container’ only for posts and not for templates.

Maybe this class has been added in some recent WP update or maybe I had not seen it before :wink:

Note that you can restrain this to certain post types if you need so:

.post-type-TYPE .is-root-container.wp-block-post-content {
    max-width: 80ch;
    margin: 0 auto;
    padding: 1em;

Where TYPE can be ‘page’ or any CPT slug.

Also note that you CAN’T use the second method in Cwicly stylesheets because ‘.editor-style-wrapper’ will be added at the beginning of the rule, so before ‘.post-type-TYPE’, which is a <body> class, so the selector will be invalid.
So you’ll have to include the CSS a different way.
(But the first one is OK if you don’t need specificity.)

1 Like