Making Posts editor client friendly

This was something I brought up a while back but, due to how Cwicly presents the block editing environment, all content fills up the entire writing window. So we end up with super long sentences, and then images that only fit a certain amount of the space, etc. See below:

This is fine when we’re designing pages and templates, but for ease of use for marketers/clients who may need to write blog posts (specifically), it would be helpful if we can present it in a more intuitive way.

My main request right now would be to be able to simply limit the width of the editing environment on posts. Potentially a little bit of CSS is sufficient, but I haven’t been able to figure out how to hook into the backend to make CSS tweaks. See below as how I prefer it to look:

I simply added

.edit-post-visual-editor {
max-width: 60em;
margin: 0 auto;

Maybe there’s a way to add custom css to the backend for certain users?

Any solutions here?

Maybe you can take advantage of this:

Thanks a lot for the link. Will check now.

Having looked at it, it’s not really the answer to my particular issue.
It’s just that writing plain-jane blog posts in Cwicly is not very nice. It’s not an environment that would feel good to a non-developer, or someone not familiar with Cwicly.

The only way to present a reasonable writing environment is to use ACF, but this removes the extra functionality that blocks have.

@owynter Conditionally enqueue the css file hosting your editor tweaks for particular user or user role via php. I do the same.

May be the role editor can allow us to set fixed width for the backend editor in the future.

1 Like

It is a valid answer that addresses your issue you explained in your initial post.

How is it possible, your issue suddenly changed significantly?

I don’t say it is the solution, but it is a way to improve the clients experience, since the templates’ styles now show properly inside the back-end, so the client knows exactly what to expect on the live site.

If you check my original post, it was the point I reiterated at the end.
I think you misunderstood what I’m trying to accomplish.

In any event, I’ve had made some progress removing styling from the back-end post editor via some code snippets that I can load conditionally using user roles (or specific users). So I’m closer to a solution to my problem than I was earlier this morning.

I’ve taken this route, and making some progress. Given the blocks a max-width which solves the first part of my issue.

What I’ve realized is that in the editor environment, there are styles being applied to various html elements. Example, an issue I kept seeing was that my paragraphs were not spaced as specified in my custom css. Due to this:

.is-root-container p {
    margin: 0;

Which looks like this:

I have overridden as follows:

.is-root-container p {
    margin: revert !important;

This then applies the paragraph margins I have set up in my CSS. Did the same with the spacing on the headings as well.

Now it looks like this:

We can all agree that this just looks better for someone who is not technical. It’s not 1:1 with front-end, yet, but closer.
I’m sure there’s a reason it was set to 0, but it was making my life a bit more difficult than I needed.

There are some other tweaks I will be making, to revert all this other CSS being applied, so we can get the backend looking more like the frontend.

Hopefully this is something that will continue to be improved as time goes by. I will post my results at the end.


@owynter just suggested a possible way to improve things. This was exactly my wording.

I don’t think there was a misunderstanding, since my main point matched your main point from the original post - the max width content.

What you brought up in your other post - the general blog post environment - is something entirely different.

@dranzer pointed you the right direction, that’s the proper way with max flexibility.

1 Like

@Marius, unsure why you’re telling me what my original point was, because I have been consistent.

In my original post, I said as follows:

…but for ease of use for marketers/clients who may need to write blog posts (specifically), it would be helpful if we can present it in a more intuitive way…

I’ll leave it at this, though, as I’ve found a workaround that solves the problem for now, and I won’t feel uncomfortable handing over to them to create their own posts.

1 Like

Hi there @owynter,

I do think @Marius’ point here is valid.

It seems that you apply a considerable amount of defaults through global stylesheets. Might I ask why paragraph padding/margin isn’t applied through the Cwicly global styles?
They would immediately be shown in the Post Editor, removing the necessity to create unnecessary stylesheets to make your backend look like the frontend, when all Cwicly global styles are automatically applied to the backend styles and take that headache away.

As for max-width, simply applying that property (using Cwicly’s design tab) to the Post Content block, will achieve what you’re looking for.

Or am I missing something here?



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.

1 Like

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.

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.

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.