20 Comments


  1. we have a proposal to add automatic updates to core, with the reasoning that it will allow rapid fixing of security flaws, and that is better than leaving upgrades to be checked by site managers on a testbed to make sure they won’t break a site.
    now its being suggested it may be worth adding further functionality that may increase security risks in core?

    seems inconsistent to me – I’d leave this as a plugin. Editting the code is probably not a requirement for the majority of users, and for those that want to do it it’ll probably be on a testbed machine anyway.

    Reply

  2. The one advantage of this would be for the average user. There are so many tutorial blog posts that recommend changing or adding to the functions.php file to get some added functionality. Or to remove it. I see so many users following the directions, changing their mind, and then not remembering what they did. Just a thought.

    Reply

  3. I tested ahoreth’s plugin a couple of times this summer and I’ve got to say that it’s everything I would expect core to do if they introduced revisions to the theme and plugin editors. It has the added benefit of preventing breakage while editing files, just like Core guards against activating plugins that would error out.

    That said, should code revisions be added to the WordPress Core? I say yes, but not yet. This is one of those features that should probably soak as a plugin for a while to gauge interest. However, It seems like a logical next step in the progression of unifying the admin experience for users.

    It’s important to remember that most non-developers probably have no idea what versioning is, so the idea of “cowboy coding” is beyond them. Integrating something like revisions in this space could prove to be nothing but a good thing for all involved.

    Reply


  4. Isn’t this more of a debate about whether plugin/theme editing should be allowed at all? It’s already allowed by default and this plugin seems to improve on that, not make it worse.

    So from what I can see, the plugin is a suitable candidate for inclusion (assuming it is good code – I haven’t looked), but only if we continue allowing the code editors.

    I’ve never thought including code editors in core was a good idea. I’ve only seen that causing carnage, not solving any problems. But if it’s going to be there, then it may as well be made useful via a code revision system.

    Reply

  5. @Ryan Hellyer – In the past I’ve found it to be really convenient when I don’t have FTP access for a site. But then again making any edits in the dashboard editors can be risky business if you don’t have FTP access. ;) I guess that’s where revisions might come in handy.

    Reply

  6. @Ryan Hellyer – I was going to write about this not being a ‘great’ idea and that it should stay out of core then you went and made a great point. We already have this in core so we should make it safer to provide the best experience to most users (which aren’t developers of any huge experience).

    So I say add it but make sure we can just turn off the editors with filter. That may exist already, I just haven’t looked.

    Reply

  7. @Sarah Gooding -I don’t think using FTP is very good idea either :P It’s horridly insecure.

    If I don’t have a secure way to edit files on the server, then I just don’t do it. Editing via the admin panel would scare the bajeesus out of me.

    @curtismchale -There are constants for turning the editors on and off. I always recommend turning them off. The worst situations I’ve seen are when clients are given access to their site as administrators and go on an editing spree and mess up sites they have paid lots of money to have built.

    Reply

  8. I would prefer to see the editors pulled out of core and placed into a separate plugin, along with this revisioning system and a syntax highlighter. I’m not holding my breathe on that though.

    Reply

  9. @Ryan Hellyer -

    I would prefer to see the editors pulled out of core and placed into a separate plugin, along with this revisioning system and a syntax highlighter.

    Agreed. (I was thinking of adding a post along those lines.)
    When WordPress was used mainly by developers seeing what it could do, and didn’t have a mature plugin system and repository, then it made sense that editting capability went with the product. Its a bit ;) more mature now, and the percentage of users (even administrators) who will actually want to edit the core is much smaller. Rather than adding stuff to the core that is of use only to a smaller percentage of uses, maybe a better choice is to streamline the core by moving stuff that’s purely of interest to developers into plugins. If a user can’t find and install an editting and versioning system, maybe they’re not ready to edit a live system anyway.

    Reply

  10. Admin code editing should be moved into a Plugin altogether.

    It remains in core because it scratches an itch of those who could otherwise decide to remove it – but that’s a double standard of the “80% rule” to which every other feature/option is held.

    Reply

  11. @Chip Bennett -It’s also something which can easily be removed without causing any problems. It can be set to auto-install much like the importer did when it was removed to avoid confusion on the part of users.

    Reply
  12. Albert

    Like the core devs love to say, this is “plugin territory”. Is astounding that this feature, which not much common people will use, is being contemplated for inclusion in core while others ( see http://wordpress.org/ideas/view/top-rated ) are repeatedly ignored for years. Sad.

    Reply

  13. I love the idea of this project. I just don’t love it as a part of core because I want to see the theme/plugin editor removed altogether for all the reasons others have stated above.

    Take the editor out of core. Mix it with this plugin. Create an awesome plugin for anyone who wants to modify code from their admin.

    Reply
  14. John

    Allow me to be the voice of reason….

    This is a terrible idea. The very fact that WordPress has a built-in code editor is a terrible idea. People posting saying that we should do things to benefit “Cowboy Coders” are wrong. People approvingly saying they like “Cowboy Coding” and could benefit from that feature are dumb.

    WordPress needs to be moving in exactly the opposite direction. Make it EASIER to be smart. HARDER to be stupid. Simple to use does not have to equal simple to be stupid. WordPress should encourage separation of concerns, a security-first mindset, and use of version control.

    People who don’t know how to write code don’t care if those things exist. But they’ll benefit behind the scenes. People who do know how to write code will be encouraged and incentivized to develop for a platform that is in bad need of good developers. And people who think features like this are a good idea will hopefully learn they are wrong. Either that or just stop writing code.

    Reply

  15. Jaap

    Until the theme editor improves – that is – line numbering, ajax saves, editing of files in sub-folders, the ability to create and remove files etc.. until it becomes a decent dev suite, then the theme editor won’t be the code-editing method of choice for anyone who is proficient enough to develop themes. This seems like a waste of energy until the theme editing environment becomes more like an IDE.

    Reply

Leave a Reply