Custom CSS: allow access to full-width CSS editor

[jeherve]

WordPress now includes its own CSS editor, in the Customizer: https://wordpress.org/news/2016/12/vaughan/

If you use Jetpack 4.4.2+ and WordPress 4.7+, Jetpack plays nice with the new editor: Jetpack's old full-width CSS editor redirects to the new customizer tab, where you can edit your CSS. We've also ported our own special features (CSS Preprocessing, Custom content width, Revisions, ...) into the customizer, inside that tab.

However, for some site owners it might not always be easy to edit CSS in that customizer tab: as your CSS becomes long, and as you start using advanced CSS that requires extra indentation (like SCSS or CSS media queries), editing CSS in a relatively small editor becomes difficult. You need to scroll a lot, indentation gets tricky, and you miss the larger view you'd get with a full editor.

For those site owners, it would be nice if the old full-width editor remained available. It could be a link in the new customizer tab to open the CSS editor in a new screen, for example. It could also be a filter allowing you to stop redirecting the "Edit CSS" menu item to the customizer, and leading you to the old editor instead.

[jeherve]

A few reports:

• https://twitter.com/robert_c_martin/status/806573670340722688
• https://twitter.com/stebancastro/status/806344660318875649
• 2951101-t

[jenhooks]

2950116-t

[jeherve]

Also in https://wordpress.org/support/topic/custom-css-lost-on-upgrade-to-4-7/

[mossifer]

For someone who codes all day and uses the CUSTOM CSS a LOT, changing it to a narrow sidebar window is excruciating. I did not experience any loss in CSS, but I can't edit in such a narrow window and have the "whole picture" with all the media sections. PLEASE change it back or give us the choice of a full editing screen. Thank you!

[kosmicbird]

I appreciate how you are wanting to improve the editor's functionality, and thank you for putting time and effort into make a great plugin for everyone to use! ...but as you mentioned, it is not easy to make modifications in the new customizer format for some of us. I can see this being good for people who only have a few lines of custom css, but for the majority of us, we will have many lines of css code. For instance, I have ~12000 lines of custom css on just one of my websites. My biggest issue is that the more lines of code there are for the customizer to process, the longer it takes to actually render and (later) save the edits.

Typically with the old css full screen editor, when I made css mods to a particular element, I would hit save and then immediately be able to view my edits on my site by opening another browser window. Now with this customizer css editor, I have to wait forever just for my additions/changes to finish loading on the preview screen, then I have to wait forever again after I hit save & publish. You can imagine how time consuming this can become (having to wait every time for rendering and saving) especially if you're like me and want to double check the live site (in different browsers) after every modification is made. It is really a nightmare for me.

Not only that, but as mossifer mentioned... it is a headache to be forced to work in such a short and narrow window. Please, please bring back the old editor as an option.

[kosmicbird]

I also want to point out that this update you did with the editor may have caused many people to lose their custom css modifications that were made in the Jetpack css editor (Permanently in some situations, if they did not have them backed up locally or unable to restore their site to an appropriate time state). Fortunately I had 90% of my css mods backed up to my hard drive, but I did however lose a lot of my most recent work that I had not thought to save to HD yet (before the new changes). Subsequently, I had to have my webhost restore my website files to an earlier state so that I could recover everything, which ended up being a big pain in the ***. Why the big change to something that was working fine overall? I'm not sure if you guys thought this one through all the way... :/

[jeherve]

many people to lose their custom css modifications that were made in the Jetpack css editor

We've had a few reports from folks losing their CSS during the migration, but we haven't been able to figure out what caused it yet. If you'd like to help us understand what happened on your site, could you tell us more about your setup and the steps you followed that lead to that problem in #5843?

Thanks!

[jeherve]

Commenting here with a possible work-around for those who need a large CSS editing area, right now.

You can use CSS to customize the look of your WordPress dashboard. A few plugins like this one allow you to add Custom CSS to your dashboard. Another option, if you always work from the same browser, would be to use a browser extension like Stylish to apply custom CSS to some sites and URLs you visit. In practice, that means that you could add custom CSS to the Customizer area of your site like so:

For example, with the following CSS:

.wp-full-overlay.expanded {
    margin-left: 900px;
}

.wp-full-overlay-sidebar,
#customize-control-custom_css {
    width: 900px;
}

You can turn your Custom CSS area into this:

[mossifer]

THANK YOU! Lifesaver. Is there any chance it can go back to the main menu? This takes three extra extra clicks, too. And like I said, those of us who customize all day find it really klugey for it to be moved to the customizer.

[jeherve]

Is there any chance it can go back to the main menu? This takes three extra extra clicks, too.

I'm not sure I understand. Once you activate Jetpack's Custom CSS module, you should see an "Edit CSS" menu item under Appearance, like before. If you click on that link, you'll be redirected to the custom CSS editor.

Could you give that a try?

[biberkopf]

+1 for a full-width option (as explained here: https://wordpress.org/support/topic/the-evil-mutilation-of-jetpack-custom-css/#post-8545295) Thanx for the work-around, jeherve.

[jeherve]

Instead of bringing the old Jetpack CSS editor back, another alternative would be to add a full-width option to the new core CSS editor. That's been suggested here by @folletto.

The ability to pop-out the editor in a separate window for a more comfortable editing experience

@folletto I think the feedback above provides a few good examples as to why that option should be interesting for Core.

[folletto]

Thanks! I keep getting confirmations for that, so I'll keep pointing that out. 👍

We can probably prioritize that bit earlier than the others. Whoever comes first, as both Jetpack and Core are building the same UI there... ;)

[JoanMorci]

In a world at a time better communicated and with so many options to comment ... people become vague to do so and expect 4 complaints to solve a problem as fat as this.

Like other problems committed by WordPress, removing comfort options natively (underlined button) and without fixing security failure in URL Author post (there are several plugins that solve this).

Why do I make this introduction? Very simple. WordPress also gets it wrong. It started being a simple CMS for ordinary people, and its great base is that. The same for which it now turns its back. Why? For not providing convenience to write.

The same comfort that has sacrificed Jetpack, following the steps of WordPress. Wrong strategy.

We are only apparently 4 or 5 people in different forums, which we complain about this error in the CSS editor. But we really represent more.

I have 900 (nine hundred) lines of rewritten code.

Very far from the 12,000 lines that @kosmicbird has. And yet she quotes that there are many problems to process that amount from 'Additional CSS'.

I consider myself a nomad of knowledge, and each time this term is more used by more people. What does this mean? Many people learn self-taught and devour information, desire to learn and motivation to overcome.

Jetpack, the big window of its editor, allowed that. To make the imagination fly and make a theme with a specific function be changed visually completely thanks to the editing of a lot of CSS code.

Jetpack has cut those wings, by removing the large CSS edit window. The nomads of knowledge, will stop flying and dream thanks to that mutilation that has made their tool in the new version of WordPress.

Congratulations, you have ruined the dreams of many people, including mine.

Jetpack without that great option, is no longer a plugin to consider.

[JoanMorci]

What is the problem to include the 2 options?

From Appearance > Edit CSS > New section with 2 options:

1. Casual user: link take the customizer (Additional CSS), little code to write.
2. Expert user: link to a section equal to the original. Where there is no constant preview (not necessary to work that continuously), only when we want (to avoid the problems that quotes @kosmicbird).

Having more than one CSS in WordPress should not be a problem. I have 2. Jetpack itself and SiteOrigin. The latter allows me in real time how to modify the CSS, but there are things I don´t like how it works and that's why I keep the Jetpack, because I like the preview (of the original).

'SiteOrigin CSS' with big window.

'SiteOrigin CSS' is a much more complete plugin that allows you to visually easily change the CSS from a very intuitive control panel.

Greetings!

[georgestephanis]

Howdy @mossifer, @kosmicbird, @biberkopf, and @JoanMorci (and anyone else reading this), and thanks for your feedback here!

I'm the person who handled the bulk of the migration effort here, and rebuilt the Custom CSS interface and additional options into the Customizer. So please, feel free to direct specific feedback to me directly, I'm delighted to get it and see what I can do to improve Jetpack for everyone's needs.

The current plan is that I'm expecting to ship by the end of the week a plugin that adds back in the legacy full-width editor as an addon plugin to Jetpack. There's two main reasons why we're doing it this way instead of re-adding it back into Jetpack itself --

1. Release scheduling. Jetpack 4.5 is already in Beta release -- as of December 9th -- so if the full width editor were added back into Jetpack directly, it probably wouldn't be merged and released until Jetpack 4.6 -- which is probably about two months down the road. We'd like to get you something you can use a bit quicker.
2. Try to keep Jetpack a bit leaner. By shipping it as a separate plugin, we can easily get data on how many folks want the legacy editor back -- and if it's enough users, we may merge it back in to Jetpack in a future release. If it's niche and helpful for a small pocket of users (in the grand scheme) it can live on its own going forward. :)

It was not an arbitrary decision to drop the legacy editor -- the underlying data structure had changed significantly from the Jetpack implementation to the WordPress Core implementation, and modifying the legacy editor to support the new post type's structure and new methods of saving things like preprocessors or custom content widths would have required a significant investment of time, so in the interest of having the release ready and polished by the time WordPress 4.7 launched -- as well as to follow Core's lead in UI, we opted to drop it.

Subsequently, I had to have my webhost restore my website files to an earlier state so that I could recover everything, which ended up being a big pain in the ***

@kosmicbird -- regarding the perceived loss of data during the migration -- I'm terribly sorry about that! I wish we'd have known, because the legacy Custom CSS wasn't actually lost! It was still in your database, just not exposed in the new Jetpack UI. I'd intentionally not deleted the database records when writing the migration process for just this reason -- in case something went wrong, the legacy data should still be stored, even if it's not exposed directly in the UI.

If anyone else finds this later and needs to get their old Jetpack CSS pre-migration out, just look for the one post of post_type = 'safecss' in your wp_posts table -- that should have your content saved on it. All revisions -- posts with post_type = 'revision' and post_parent = POST_ID where POST_ID is the safecss post -- are also there in your database.

Why the big change to something that was working fine overall? I'm not sure if you guys thought this one through all the way... :/

In regard to your question about why we changed Jetpack CSS at all -- the answer is that we didn't want to. However, WordPress Core was shipping it's own implementation of Custom CSS, and our options were to --

1. Do Nothing. Both the legacy Jetpack CSS Editor and the WordPress CSS Editor exist in different places in the WordPress Admin. This can be confusing to users, as the data behind them is not the same. What is saved in one place does not show in the other. What is changed in one can be overridden by the other. Sad times all around.
2. Nerf the Core implementation, keep our Legacy editor. This would result in other problems -- for example, if a user is actively using the Core CSS Editor, and then activates Jetpack, their data is suddenly inaccessible! Alternately, if they actively use Jetpack, and then deactivate Jetpack (I know, I know, who would do such a thing...) -- their data would also be inaccessible, as it's stored in different post types using different structures. Also, users would lose the ability to live preview.
3. Drop the Jetpack Editor from Jetpack, let folks use the Core implementation. This would result in more problems -- anyone using the extra options we offer -- Sass or LESS preprocessing, customizing the content width, dropping the original theme's style.css -- those would be lost. As would the ability to view prior revisions. Also, code syntax highlighting. Oh, and in multisite environments, the Core CSS Editor only works if you're a superadmin. So if you just run a single site in a WordPress Multi Site environment, you can't even do Custom CSS any longer! Sad times, indeed!
4. Synchronize the two implementations. Migrate legacy Jetpack revisions over to the new Core Custom Post Type, so legacy data is still accessible (which worked smoothly in most cases -- I'm investigating what went wrong in reported cases where it didn't). Implement our sanitization of the saved CSS, code syntax highlighting, preprocessing and other options on top of the new Core data store. Everything works smoothly together, and as an added benefit, if someone chooses to deactivate Jetpack (yes, yes, I know) -- all the changes they'd made with Jetpack is still saved for them and fully operational.

I hope this helps you understand our rationale for pursuing things in the direction that we had. My door is always open, so if you have more feedback, by all means, let me have it!

[JoanMorci]

The explanation is appreciated but the problem persists.

Finally 2 months is a long time and everywhere professional I see advised against using Jetpack (unprofessional and heavy plugin). I defended its use a lot of time, mainly for editing CSS (in a big window) and Preview that worked very well.

Now I will have to use 'SiteOrigin CSS' exclusively, which isn´t a bad option, in fact it's very good, but sometimes it don´t find the exact path from the visual control panel, so you have to go to the Browser element inspector web. Ah and Firefox don't work very well with WordPress (leaves ugly code when saving post reviews).

Sorry, for all these codex problems WordPress but Jetpack has hurt, in one of your best options (Edit CSS).

For @kosmicbird, it isn't a solution to use the thin version (Additional CSS), since it takes a long time to process. I recommend 'SiteOrigin CSS', which has preview before saving CSS (button in the bottom left, not seen in screen capture).

I recommend this option of SiteOrigin, because it truly is a feasible solution to this disaster caused, and I repeat as on Twitter I said to @georgestephanis, programmers don´t touch much CSS, you don´t understand what it is to move through a window so small with 900 lines of code in my case, but in the case of @kosmicbird, it's even worse. For painful vision and wear time processing.

All the modifications I make, I give an explanation of what was retouched, and that also takes up space.

If @georgestephanis (judging by what we talked about on Twitter) doesn´t understand the difference between narrow and wide window, has a problem. And obviously it seems that you touch little or nothing in CSS (your web proves it), then this option doesn´t seem important to solve it quickly.

Greetings and all my respect to your work @georgestephanis! But I believe that you don't value the work that we do, here present, retouching CSS exhaustively.

[samhotchkiss]

Thank you for your feedback @JoanMorci (and everyone else).

At this point, we have a full understanding of people's frustrations around the CSS editor width in the customizer. @georgestephanis has committed to having a plugin to restore this option by the end of the week, which will allow you to use the old or new interface. For what it's worth, it was my call to discontinue the old interface-- George was on board with keeping it from day one, so any frustration should be directed at me.

Rest assured, there will be an option to get the old interface back very soon, and the adoption rate of that functionality will drive our decision as to whether or not to bring it back into the core Jetpack plugin.

[janiani]

Following with great interest. Thanks for all your help in the issues that came up for my site with the WP update too. I look forward to hearing about your work-around, clearly there's a demand :)

[JoanMorci]

Thanks for the clarification @samhotchkiss, I understood that it was 2 months because the solution was not very clear in the short term.

I hope this week finds a solution, it would be grateful and admire that Jetpack team really cares about this issue.

I want you to understand that I personally like Jetpack, for more features and it was certainly my first plugin to install.

Now I leave a little of the particular event, to say because more things I like Jetpack and to improve, if possible (taking advantage of this new update).

Jetpack for non-professional people?

Many people from the web profession say that it is a heavy plugin and subtracts web upload speed or saturates server requests hosting (shared). I use it from the web hosting 'STRATO' (hosted in Germany), I have 5,000 neighbors (shared server) fact that I know because I analyze it and despite being too many neighbors (normal are 10 to 200), they allow me to use Jetpack. I know it thanks to DNSQueries(.com)

One user saw a video of me on YouTube (about an article) and told me that the hosting service 'WebEmpresa' (used by many Hispanic people), didn´t directly install Jetpack on the company's own themes. This is a high fee... I'm aware that 'GoDaddy', years ago, don´t allow it either. I don't know, if allows it today.

I would like to know exactly, if Jetpack is as unprofessional as they say and if the load is so high. If so, how can it be counteracted.

Buttons sharing on networks, put up too?

Thanks to the 'SiteOrigin CSS' plugin I was able to redesign shared button colors (Jetpack). Now they are a reflection of my personal brand. Note: the email box isn´t responsive on vertical mobile (stick outs).

Even so, it would be interesting to include the option of putting them up and down an article (now only possible down).

Why? Many people don´t have time to read and sometimes prefer to save on their social networks, hoping to read later. Would you be able to implement this in the new update?

Conclusion

I don´t really know the effort of being a programmer, I´m aware of the struggle that is always between designer and programmer, I never say that I´m this last, but if I get into the work of HTML and CSS (something I already did before there was WordPress at the web level, not blog only). Now PHP, I´m not so 'Indiana Jones' and aware of my limitations.

Even so, despite what my web guild says about Jetpack, it seems to me a very useful plugin, both for beginners and for those who take time.

Because WordPress(com) has 21 plugins, all from the same author, and like Jetpack, I emphasize that if so many mini-plugins are inside a great plugin, it's good, because they are by the same author and there is no conflict between them. Am I unprofessional for making this statement?

Greetings from Spain!

[jeherve]

@JoanMorci There are quite a few questions in your last comment, and none of them are related to the issue being discussed here. I consequently followed up with you via email. Check your inbox!

[JoanMorci]

Ok. Thanks @jeherve.

I was born in forums in 2002 and I'm aware of the rules of each post, but I'm new to GitHub and I barely have time to look at everything, translate in a language that I can handle, and I'm sorry change the course of the post (I myself bothered when someone did that in a post forum).

Sorry guys.

Let's wait for a weekend solution to the original CSS Jetpack or similar to the original :)

Greetings!

[alexjgustafson]

2958975-t

[mossifer]

The other alternative to the CSS problem is to create a child theme with a custom styles.css. That way, you can update other files too like Header/Footer and enable regular theme updates.

[georgestephanis]

v0.1.1 of the editor is up in the plugins repository --

https://wordpress.org/plugins/legacy-jetpack-custom-css-editor/

The one main feature that isn't working (yet) is Previewing the CSS on your site before publishing it. I'm currently looking into retooling how it's done to match more closely with modern WordPress development practices. (the old way was written quite some time ago -- I'm planning on rewriting it to basically use the Customizer data store and changeset system, without the customizer UI, to better handle clicking around throughout the site)

cc: @mossifer, @kosmicbird, @biberkopf, and @JoanMorci ^^ if any of y'all would like to give this a spin while I'm still actively working on it and provide feedback, it'd be much appreciated.

[biberkopf]

@georgestephanis Thanx for the effort. I'll see if I can take it for a spin soon. Just a thought: To me it seems we are dealing with 2-3 slightly different UX situations.

1. The typical Customizer user is likely a less experienced CSS-user and might just make smaller and fewer adjustments to the look of the theme.

2. The full-width/legacy-Custom-CSS-user is more likely to use Chrome Developer to perfect the CSS-overwrites, and he/she will already know the effect of the code.

3. The full stack coder that will never degrade himself by using a custom CSS functionality.

So in short, I'm not sure the preview is as important in the legacy version as in the Customizer scenario. That said, I guess you're right in maintaining some sort of a preview as long as it's optional or flexible. To me preview is less important. I would rather have some of the DOM-wise drill-down functionality, that we know from Chrome Dev.

I know we are talking about a whole different beast here. It's so easy to want to build a long list of features:

• minifying on/off
• SASS/LESS support
• auto-completion of CSS attributes
• balancing and analysis of syntax
• overview of existing selectors for a given DOM-element
• highlighting, shorthand and generally 'just' smart editor responsiveness

A lot, and arguably too many, of these features have been bundled into Siteorigin CSS. Perhaps you want to take a look at that to learn from their efforts.

Bottomline to me: The old editor was really good as it was. So if you can just bring that back, I think a lot of people will want to marry you. :-)

[georgestephanis]

Just pushed v0.9 of the plugin -- Preview works! Brought to you by late night coding binges fueled by euphoria from seeing Rogue One earlier in the evening, and sponsored by the ability to work undisturbed whilst the children are asleep!

[georgestephanis]

@biberkopf We already have Sass/LESS support and syntax highlighting, and have had them for years. 👍

Minifying is tricky, we had previously done some optimization when we handled the output in the Jetpack one -- we even had some careful balancing where if the size got over a certain number of bytes, we started embedding it from a link tag, instead of printing it directly in the head on every page load -- so it could be more easily cached. Core isn't doing that currently, but we're talking about adding that back soon as a Jetpack enhancement (and potentially even cloud-hosting it from WP.com CDN servers if available? Just musings on my part for that last bit, but it could be fun)

Autocompletion is interesting. We use CodeMirror already, so I think it's just an extra module that gets included. I'd need to check and see how much bulk that would add to our download size! The downside is you need to do a keyboard shortcut to get it to autocomplete -- https://codemirror.net/demo/complete.html -- it doesn't just "happen" as you type.

The Customizer implementation does have some nag that happens when your braces aren't balanced.

Existing selectors of a given DOM element would be interesting, I'm not sure how helpful. I'd sooner see it as an addon plugin, not in Jetpack directly -- something that analyzes used selectors and recommends consolidations and optimizations -- maybe even stuff like curtailing #dddddd to #ddd or mentioning when a box model shorthand can be used, changing margin: 5px 0 5px 0; to margin: 5px 0; -- or changing padding: 0 0 0 0; to padding: 0; -- I know a lot of people have a hard time remembering the exact order of arguments to pass in to that sort of thing, so they just write everything out by hand.

Anyway, good to consider! Thanks for the input!

[alexjgustafson]

2952251-t

[rodbauer]

I really need the ability to turn off the CSS preview and to have the option for full screen editing of the custom CSS. Also, the CSS does not seem to be applied any longer to the JetPack minileven mobile theme. I am currently trying to debug this problem. Is that intended?

[alexjgustafson]

@rodbauer there's a separate issue (and a quick fix) for CSS being applied to the mobile theme here: https://github.com/Automattic/jetpack/issues/5815

Until this gets fixed, a quick fix is to install this little plugin: https://github.com/jeherve/jetpack-addons/archive/mobile-custom-css.zip

[rodbauer]

@alexjgustafson Thanks. The plugin worked to restore the application of custom CSS to the JetPack mobile theme.

[biberkopf]

@georgestephanis wrote:

@biberkopf We already have Sass/LESS support and syntax highlighting, and have had them for years.

Yes, I know. ;-) My list was mainly to exemplify a wishlist of features. And to let you know, that I'm quite happy with what's already there. And although I haven't yet stuck my toes into preprocessing CSS, I'm really, really happy it's included. It will make it so much easier to get started, than if I had to implement the necessary libraries myself. So +10 for that!

I still think Google Chrome Developer is a good source of inspiration. And if I should add just one more thing to a wishlist: multiline indention of selected text when pressing the TAB-key - like in many good text editors (like BBEdit).

Again, I trust your justment and I have the greatest respect for the difficult decisions you guys have to make to keep the ungrateful millions happy. ;-D

[jamesdcormier]

Just wanted to echo what others have said regarding moving the Custom CSS editor to Customizer: I'm not a fan. I used the Jetpack edit CSS feature heavily to modify all of my websites, and my custom CSS is quite extensive. Not having access to a full-sized editor is very frustrating. I realize there are other ways to do this (e.g., adding it directly to the stylesheet or using another custom CSS plugin), but I had come to rely on the Jetpack plugin and preferred its reliability and ease of use. Please bring it back! It's not redundant! Customizer's tiny little box is fine for minor tweaks for those who want to see live changes, but for extensive changes it's just not a good fit.

[JoanMorci]

Hello and Happy New Year 2017 for everyone!

Let's start ...

@mossifer I already have a child theme with its own style sheet. But ... it don't perform as well as the original Jetpack CSS editor. I don't know who made the original and why it was removed, but it was a bad idea. Not only because it was a large window, but also because it was more efficient (even with Preview).

@georgestephanis without depreciating your work with the new plugin, there is already a more recognized option, called: Simple Custom CSS. But this plugin don't have Preview, something that I do value. So ... Preview works in your plugin (version 0.9)?

One option that would be very interesting to add, would be the possibility of including a 'code search'. Why? Because when we write a lot of code, sometimes you don't remember if you changed a certain characteristic or not.

And when you don't remember, you start to misuse the !important statement and it isn't good to abuse. In fact, it should be used to return to the original values, not those that we want to modify.

Why rating Preview @biberkopf? Because if you make a mistake or don't like how something remains, nobody else has to see it except you. And therefore there is no need to put a maintenance screen.

We could work locally this, yes, but usually the comfortable thing is to do it online. Why check in 2 different sites (local or online)? If we can do it comfortably online. The present is more uncomfortable than the past (Jetpack).

Greetings ladies & gentlemens! :)

[jeherve]

Also suggested here: https://wordpress.org/support/topic/customizer-6/

[kiaseven]

Quick note for anyone still looking for a solution: I installed Simple Customs CSS and migrated all my code into there. It works just as the old full-width editor did.

[prontoboss]

Do we still have a chance to have the old style of Custom CSS editor? No one from our front-end developer happy with this tiny editor. They would be happy if we can effort them 21:9 monitor for this current version of editor T-T

[jeherve]

Do we still have a chance to have the old style of Custom CSS editor?

@prontoboss You can install this plugin to get the full-width CSS editor back: https://wordpress.org/plugins/legacy-jetpack-custom-css-editor/

[prontoboss]

@jeherve We already try that one. It does not work. It cannot compile LESS CSS. Everytime we update while using LESS preprocessor, it'll automatically add / in front of '.

[jeherve]

@prontoboss Thanks for the report! Could you create a new issue here and include an example of the code one can use to reproduce this issue? We'll take a look and see if we can get this fixed.

[westonruter]

CodeMirror has also just landed in core. See #7776.

In terms of having a wide editor, see also this core ticket which proposes that the editor be able to be popped out into a separate window: https://core.trac.wordpress.org/ticket/38707

Also, the fullscreen mode in CodeMirror may also be an option: https://github.com/WordPress/better-code-editing/issues/70

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[kraftbj]

Going through some older tickets and I'm going to close this as a wontfix. With us deferring to Core's Additional CSS feature, the long-term route would be to see any UI changes added to Core.