Cancel

Sarah Gooding

WordPress 4.9 to Focus on Code Editing and Customization Improvements, Targeted for November 14

photo credit: Sophie Ollis

WordPress core contributors have set a tentative schedule for the upcoming 4.9 release, which will be co-led by Mel Choyce and Weston Ruter. The development cycle kicked off in early August with Beta 1 scheduled for early October and the official release targeted for November 14.

Choyce published a list of goals today that outlines what they will be aiming for in 4.9. WordPress users can expect to see some existing features polished up to be more user-friendly, including some long-awaited updates to the experience of editing theme and plugin files in the admin.

Contributors are looking at adding a nested folder structure that will offer access to files deeper than two levels. They are also aiming to add better warnings for users who are editing themes and plugins, an improvement which Choyce described as “graduating from cowboy coding school.” This could help prevent users from unknowingly making small errors that could have a negative impact on their sites.

Another goal for 4.9 is to improve the code editing experience by adding syntax highlighting. Contributors are examining the possibility of incorporating CodeMirror functionality into the Customizer’s custom CSS box as well as the plugin and theme file editors. An experimental Syntax Highlighting Code Editor for WordPress Core plugin is currently being developed on GitHub as a potential solution for a seven-year-old trac ticket for code editor improvements.

Customizer improvements are also one of the main focuses for 4.9. Contributors to the Customize Snapshots feature plugin have been steadily refining the ability to draft and schedule changesets in the Customizer. They are also looking at providing a better experience for widget and menu mapping when switching between themes, improving homepage settings (“Page on Front“), and displaying responsive images in the Customizer sidebar.

This list of goals for 4.9 includes many more items and the release leads are approaching it with the understanding that some features and improvements may not be ready in time. One item on the list is getting in API endpoints that Gutenberg requires.

Looking ahead to WordPress 5.0, new Gutenberg design lead Tammie Lister has proposed a revised, tentative roadmap that anticipates having the new editor ready for a merge proposal in December 2017. Lister said the outline is not set in stone and Gutenberg’s path to 5.0 would be dependent on the success of the merge proposal.

Category: ,
Tags: ,
34

34 responses to “WordPress 4.9 to Focus on Code Editing and Customization Improvements, Targeted for November 14”

  2. I wonder how others feel about these goals? Being able to edit code inside admin is more bad than good security-wise.
    In general, my feeling is that WP is adding more and more unimportant things to core without giving users chance to turn these things off. Nowadays, I have to unhook so many things to speedup a fresh WP instance.

    • My thought exactly. The in-admin code editor is a huge, gaping security hole. I get it that it lets the users learn to play, but it is also highly destructive.

    • The security argument is largely a moot point, only administrators see the code editor and administrators by definition can do all kinds of things to their installation that are secure or insecure – like installing plugins that they haven’t inspected. Pros that are handing off sites to their clients can very easily create separate roles or hide the area altogether.

      I rarely use the code editor, but it does come in handy when I want to explore some plugin code to do some code quality inspection or do some preliminary debugging inspections.

      I like that the code editor is there because it might be the first step for some users to get interested on a code level. It’s an open invitation to learn and signals that WordPress is something anyone can start coding for.

      But somewhere down the road it is going to be rather nice to be able to code without having to install separate tools on a machine. There would need to be some sandboxing functionality to prevent against crashes and the like, but it’s a worthy long term goal in which little steps that polish up the current experience are small, useful stepping stones. From plugging in some lines that remove or add functionality via action hooks and filters, to perhaps doing more serious theme stuff. But right now, just getting better readability of the code of plugins and themes is valuable in and of itself.

      I don’t think people fully appreciate the different ways that WordPress welcomes people to start playing with the platform and how that benefits the entire user base. Many theme developers, plugin developers and contributors start their WordPress journey with small steps probing how easy it might be to implement some customisation. That journey might start in the built-in code editor and why not.

      • By security I do not mean simply hackers getting in although that is a major component. I’ve seen the code editor used in a hijacking before to modify the theme to start injecting malvertising. The admins would go to bed one night and then wake up the next morning to e-mails reporting the problem. Wash, rinse, repeat. It’s the reason one of my former employers now bans WordPress 100% across the board sans one site.

        But part of security is maintaining integrity of the site. Allowing destructive editors with no safety whatsoever is just asking for trouble, especially if it is a site managed by one entity but maintained by another.

        I get that a lot of people learn to mess with WordPress this way, but it doesn’t change the fact it is not an advisable method. Do we teach people how to drive by simply putting them in the driver’s seat of a car on the high way and say “Good luck”? No.

        They’re better off being encouraged to download a *AMPP program, WordPress, and a theme and go to town on that where there’s no possible way to damage a live site or worse.

      • What you’re describing sounds like a scenario in which malicious code has access to a logged in instance of an admin account. Code editor or not, any malicious code will be able to do some damage with that much access. It does sound like an uncommon attack vector to me, I’m not aware of any major security breaches involving the code editor in that way. Any WP security experts willing to shed some light on that?

      • I agree with you and also with others who say code integrity or version control is important. Personally, I always turn it off.

        Yes, administrator by definition has the highest privileges to do anything. But consider a scenario when some minor plugin has a XSS vulnerability and it is used to place backdoors (demonstrated here https://ibreak.software/xss-to-rce-using-wordpress-as-an-example/).

        Yes using XSS, attackers could just steal admin’s session and upload a plugin of their own anyway. But it’s the convenience of WP code editor which makes it easier to place stealthy backdoors. Much easier to scale and automate attacks in my opinion.

      • But somewhere down the road it is going to be rather nice to be able to code without having to install separate tools on a machine. There would need to be some sandboxing functionality to prevent against crashes and the like, but it’s a worthy long term goal

        No it’s not. No professional developer codes on the live site. If someone does, they’re internalizing bad practices and WP should not encourage those.

        The bottom line is that altering code on a live site simply is never good practice. In rare instances it might be necessary to fix a crashing, site disabling bug. But developers should always, absent those circumstances, code on a development installation and move those changes to live once tested.

      • Rick what you mean with “live site”? Do anybody on the Earth code the site without possibilities to see an output? What is the opposite of live site? It does not exist.
        If code editor or theme customization or whatever is in the WP, it does not mean, that you have to do it on a production site. It just give you a possibility to do some changes without external software like ftp client or editor directly in the browser inside your application.

        Millions and probably majority of WP sites are blogs and simple websites without a huge audience. With feature like code editor, all these people will be able to make their small changes easier now.

      • No it’s not. No professional developer codes on the live site. If someone does, they’re internalizing bad practices and WP should not encourage those.

        @RickGregory I think you’re missing the point because all you can think of this is in terms of ‘cowboy coding’, which is not what I’m advocating at all. The reason not to ‘code on a live site’ is that it directly affects the functioning of the site with mistakes showing up instantly to all users. What I’m suggesting is that down the road having the ability to safely write some theme code might be completely feasible and worthwhile. This is not something that is around the corner but who knows what happens down the line.

        The customizer architecture is doing a lot of legwork already for operations that normally would have to take place on a dev or staging site. With changesets all types of WordPress users, from devs to novices will be able to stage changes to their site without affecting the front-end. That’s moving WordPress to a better place.

        Having the ability to write some code without necessarily affecting the front-end directly could be a logical step to happen at a later stage. I personally see a lot of value in that, because it’s generally a good thing to make things that are hard to do today easier tomorrow. And it’s hard/burdensome to have to create an entire staging or dev site just to write a few lines of code. And if an admin is already working from a staging or dev site, an in-app editor might be very attractive because it lowers the barrier to entry. If a host provides a staging site easily, they can write some code without having to setup tooling on their machine.

        ps. In my experience the group of users most likely to code on a live site are pro devs, those that state otherwise are likely lying :)

  3. Can someone please explain to me how editing plugin and theme files falls into the realm of the WP REST API, Customizer, or Editor (meaning the post/page editor)?

    Telemetry has exponentially more people backing it than syntax highlighting. I mean seriously.

    • I’d say that if you’re dealing with code, might as well also add the support to deal with them in different folders too. Isn’t the Editor also the Appearance > Editor, where you could edit theme files (edit the child theme, not the parent theme).

      It’s not a biggie, but I’ve had to install a plugin WP Editor to currently deal with browsing a few more folder levels deep e.g. /inc/snippets/snippet-featured-banner.php.

      Kind regards,

      Mic

  4. I’m definitely down for syntax highlighting. I don’t see a lot of drawbacks from a user perspective. It’s something we’ve had to add in custom on a number of client sites.

  6. Code editing from within the WP admin should be discouraged / removed. There’s too much risk to make a mistake and crash a site (even for high experienced people). It’s dangerous! I am not against readonly though.

  7. including some long-awaited updates to the experience of editing theme and plugin files in the admin.

    Contributors are looking at adding a nested folder structure that will offer access to files deeper than two levels. They are also aiming to add better warnings for users who are editing themes and plugins, an improvement which Choyce described as “graduating from cowboy coding school.”

    Sigh. Users shouldn’t be editing their theme files anyway and no developer worthy of the name should be doing so on the live site. The entire feature should be scrapped.

    It’s ironic to the point of self-parody that a feature that makes it easier to edit the code of a live site is described as “graduating from cowboy coding school.” when developing on a live site is precisely one of those things that defines cowboy coding.

    Code on a dev server. Test. Deploy to Live.

    • Yup. Why is this a focus. There are a million better things the team could spend their time on.

  8. The first thing I do when I install WordPress is to add the following to wp-config.php:

    define('DISALLOW_FILE_EDIT', true);

    It’s sad that a dangerous feature like this is not removed from core altogether but “improved” and encouraged to be used, just because that’s how some core dev learnt to code in WordPress.

    • Yep. That should be the default in core. Then if people want to enable it, they should have actually have to add something like this to their config…

      [code]define(‘FILE_EDITING_ENABLED’, true);[/code]

  9. Bad bad bad bad idea. The code editor doesnt need to be improved. It needs to be removed. Why on earth do we go to all the trouble of having version control, deployment via version control etc. If we are going to allow clients/users who may or may not (most probably not) have access to and edit code?

    No no no. Bad bad bad.

      • You can’t remove it. You can HIDE it from clients but what I, at least, mean by ‘remove’ is to actually remove the code from the codebase. There’s no good reason to have a code editor in core. No dev in their right mind edits code on a live site if they can help it and if they have to, they can SFTP in and get at the code that way. Spending resources on make code editing within a CMS is just a waste of those resources.

        I’d *really* like core to drop a lot of things that it seems to insist on having in the core code itself and let those be modular. For example, drop the editor as a part of core and have it be hooked in as a plugin. Want the current editor? Activate that plugin. Want to replace it? Install and activate another plugin whether that’s the Gutenberg plugin or another.

        That way, if someone *really* wants a code editor in WP they can install a plugin to do it but core itself doesn’t include the code and the core team doesn’t spend time or effort on it.

      • You can disable it with a constant. The file editor becomes inaccessible (403 Forbidden), not just “hidden”.

        Or you only allow clients to have the Editor role, or a custom admin role without ‘edit_plugins’ and ‘edit_files” capabilities

        All my clients have this constant set, and some a custom role.

        If this was removed from core any admin (with ‘install_plugins’ capability) could install a plugin with such functionality, or even database editing.

      • We’re talking past one another. The CODE is still in core. Yes, you can remove it so it’s not accessible by clients but the code for the editor is still in core, it’s still being worked on etc. To me, core needs to be as light as possible with any non-essential code being removed. Also, if the prudent move is to disable it for clients why have the code there? You might say “well my clients don’t have admin rights” but that’s a tricky stance since, from a client perspective, they don’t have full control over their site if the developer stops responding, goes out of business, etc. So all of my clients usually do have one admin account.

        Could a site admin simply install a plugin to do this if the code was really removed from core? Sure. But so what? Site admins, by definition, can do almost anything to their site. That doesn’t mean core should encourage those things by providing them.

  10. It’s cool. I don’t understand that fear from it. Admin of a website has full access to site, files anyway. This is just extra feature what can help in some scenarios. It’s helpful to be able edit nicely WP files without needs of ftp client, text editor or any other external tool. Sometimes admin need just small change – a color, analytics code, change footer. It’s not more dangerous than editing a file via ftp, but gives the possibility to do some changes very fast in a browser.

    • Exactly.

      While I understand the fears of some of us, I still think this shouldn’t develop to the point of phobia.

      Let me give an example:
      Let’s say you are editing some HTML and you have forgotten a tag, should you reupload the whole plugin with all the steps that involves ? I would say no, just add that tag, save, refresh the other tab and be done with it.

      • And then, since you haven’t made the change in your source files on your development machine the next time you push that code, it undoes this change.

        Editing a live site is cowboy dev. It’s irresponsible and should be avoided except in cases of emergency. “Oh but it’s a hassle to edit on dev, then test and then have to FTP it…” No, it’s professional.

    • Ha, ha. Ok. Understand this then. WordPress provides the noose so that clients can hang themselves with it. Then when they do, the site is down because of a botched edit. Now this the noose is going to be that much more alluring. Bad idea.

      Who gets to fix it or get the frantic calls? Not the client. Disabling it in the config can prevent it all from going to heck and then since it’s disabled, these new features will never be see or used. Total waste of core dev team time IMO.

      For those that still want to use it and know how to enable it, it should require editing of the php config file.

  11. Waste of time and resources.

    If someone wants to edit core code, they should have to purchase a Plugin from WordPress to do that. And they should have to show ID, if you know what I mean.

    It’s like giving a master key for all Chevy cars, to unidentified people, that’s what this is!

    I love WordPress though!

    I’d much rather have a simple administrative function that lets me put my social media icons or Search widget (or both) in the header photo. Now that would be useful for many users.

    Cheers! JBS

    • The built-in code editor does not give users the ability to edit core code.

      The comment quiz plugin might have prevented the above comment spam…

  12. I think some features for developing should have a hook to switch on/off. They shouldn’t be enabled by default in core because of security and performance.

    • Actually, you can deactivate the plugin/theme editor using the constant

      define( ‘DISALLOW_FILE_EDIT’, true );

      Also, you can completely disable file modifications (including plugin, themes, and core updates) with

      define( ‘DISALLOW_FILE_MODS’, true );

  13. This discussion about the code editing (and gutenberg in many ways) boils down to wordpress just not wanting to grow up and be a CMS used by professionals, and it prefers to be more of a fronpage/dreamweaver clone :(

    Can anyone imagine a webmaster of a portal just decide to “fix” something in WC code and just goes and does it?

    And the “admin can do everything in any case” argument is just not realistic. I heard of at least one site in which there are more than 20 admins, and as long as wordpress to not force the separation of admin role from authoring related roles, I can see this practice continuing since obviously it is easier to give admin right to people than putting effort into properly configuring capabilities.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: