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:
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.
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:
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.
@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:
Blockquote
…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.
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.
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.
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.
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.
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
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:
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.
