Make WordPress Core

Updates from Alex Toggle Comment Threads | Keyboard Shortcuts

  • Alex 10:02 pm on September 17, 2013 Permalink
    Tags: ,   

    Code Revisions: Last Week 

    The code revisions plugin reached version 0.95 – just leaving enough space for some final readme updates and hopefully no more bugfixes (because of no more bugs).

    But still, some final important enhancements got into this update. Mainly to ensure that all related revision data is removed when a package (theme or plugin) is uninstalled (#395).

    Last week now is about creating a screencast for you, the community and wrap up the documentation.

  • Alex 11:49 pm on August 27, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 10 

    First double-digit week. Most notable change this week: Code Revisions is now available in the plugin repository0.8 finally brings a uninstall automatism, fixes some bugs (#335, #351)  and cleans the code up (#325). The ticket list is actually getting quite short by now with primarily aesthetic stuff being left over.

    So I hope to get some people to test it now it’s in the repository. Maybe this will get me some more feedback to address in the weeks to come.

  • Alex 6:00 pm on August 21, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 9 

    Version 0.7 is tagged and I am planning to submit it to the WordPress.org plugin directory later today or tomorrow.


    Viewing code revisions now feels much more native: By default WordPress makes use of normalize_whitespace() before comparing two posts to one another. This results in loss of blank lines and missing multi-space indention as often seen in css files. I fixed this by plugging into the wp_text_diff() function (#302). Further more you now get the correct menu item expanded when viewing code revisions (#316).

    Besides those I am still struggeling with syntax checking (#335). Looks like I will be settling for just using ‘php -l’ if available. Problem there is I am still not able to get a reliable path to the php binary. Since PHP 5.4 there is the PHP_BINARY constant, so I need a way to get it manually in PHP versions lower than 5.4..

    • Aaron D. Campbell 6:20 pm on August 21, 2013 Permalink | Log in to Reply

      You might be able to try PHP_BINDIR and use the most common bin name (php or php.exe). If you really want to go out of your way, you could check the whole path for the binary using something like https://gist.github.com/aaroncampbell/6294506 but I don’t really think that’s necessary assuming that PHP_BINDIR is pretty common. Past that, just fail gracefully

    • Bryan Petty 6:36 pm on August 21, 2013 Permalink | Log in to Reply

      Yeah, I tend to agree with @aaroncampbell. Not so much worried about automatically finding it as much as just making it possible to manually define it within wp-config.php if necessary.

    • Andrew Nacin 6:48 pm on August 21, 2013 Permalink | Log in to Reply

      We seem to do okay without using the binary in terms of sandboxing plugins and showing any syntax errors.

  • Alex 3:09 pm on August 13, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 8 

    I skipped some weeks here; sorry for that. WordPress 3.6 was released and now there is quite some talk about 3.7 and 3.8 ongoing here – I really like the plugin approach! It actually is the same approach recommended to us GSoC students for the projects. Many features which can be put together by core developers when they team up might be essential to WordPress while maybe still not essential as part of core. This way WordPress development could get much more dynamic for the future.

    As of the discussion on my last post 0.6 the plugin now primarily uses php -l for syntax checking – if available. If not, I am still falling back to eval (#335).

    For the next weeks the plan is now to bring a more code-editor-like look to the code revision viewer: Show indention and lower the line spacing etc. This will need some not so pretty overwriting of pluggable functions because most spaces are stripped for diff-creation.

    Further more I will discuss releasing the plugin to the plugin repository with my mentors as preparation to final considerations if or if not this or part of this should get into core.

    • Ryan Bayne 3:27 pm on August 13, 2013 Permalink | Log in to Reply

      Great. Looking forward to the code editor improvement. While I’m still learning the core and the ways of WordPress. Things like that will make it just a little easier to take it all in and eventually contribute, eventually 🙂

    • Shea Bunge 9:40 pm on August 13, 2013 Permalink | Log in to Reply

      I recommend that you use CodeMirror for the code editor.

  • Alex 6:23 pm on July 25, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 5 

    Week 5. Two days late.. I wasn’t happy with what I got on Tuesday and did not want to post yesterday because of other internship posts. Well, I’m still not happy with my progress on syntax checking. Maybe I can get some constructive feedback on this: When I initially proposed this project the idea of preventing faulty code of being saved came up. It is easy to break an installation with some bad changes to a php file of an active theme or plugin. Obviously, a broken installation is a bad user experience.

    The problem I ran into when investigating this is that it is not that easy to check php syntax from within php. There was a function in php core itself which got removed some versions ago. The current implementation of this in version 0.5 of my plugin uses eval – I know eval is evil, but it doesn’t matter because you can do what ever evil you want to when you’ve got access to the editors:

    var_dump(eval("return true; if(0){?>{$code}?><?php };"));
    $error = error_get_last();

    This still does not catch all errors, but it at least gives me the ability to notify about  unbalanced brackets and missing quotes. The problem here is that some shared hosts might have it disabled by default.. Any thoughts on alternatives?

    Next week is evaluation time and I will be doing some testing on different installs. Because this functionality for the moment is intended to only work with WordPress 3.6 this shouldn’t bring up to many problems. Happy WordCamp everyone in SF!

    • Mike Bijon 6:41 pm on July 25, 2013 Permalink | Log in to Reply

      I don’t know if there are any ‘good’ alternatives to eval(). But some functional ones might be call_user_func() or ReflectionFunction::invokeArgs().

      Both will require a little refactoring to get working on PHP 5.2.4.

      You may run across suggestions to pass your $new via a closure, but that would require PHP 5.3+.

    • J.D. Grimes 6:50 pm on July 25, 2013 Permalink | Log in to Reply

      You could write it to a temporary file and then call exec( 'php -l ' ) but I’m sure you have already thought of that. The extra file write makes it unappealing. And I don’t know about the cross-server compatibility. I also don’t know if it’s possible to get the error(s) either.

    • Samuel Wood (Otto) 8:23 pm on July 25, 2013 Permalink | Log in to Reply

      Yikes. Can you write this to check to see if maybe system(‘php -l …’); will work instead, before doing it this way? I realize that this is technically not dangerous, but frankly I’d be far more trusting of a php -l call. Nothing else is going to do a proper parse, really.

    • Nashwan Doaqan 8:42 pm on July 25, 2013 Permalink | Log in to Reply

      hmm, I don’t know about any good proper function to check the broken code… but even if you found it, I suggest to make the idea more simple 🙂

      One idea is to create something like “WordPress Silent Mode” a way to lunch the WordPress without the plugins/themes functionality .. by this way it’s simple to recover the invalid files.

    • Tom J Nowell 9:02 am on July 26, 2013 Permalink | Log in to Reply

      If PECL runkit >= 0.7.0 is available you can try runkit_lint


    • ahoereth 4:44 pm on July 28, 2013 Permalink | Log in to Reply

      Responding to the others ^ here. Thanks for the ideas! Just had a chat with @ocean90. I will be pursuing an API approach which checks which functionality is available in the given environment and acts appropriately. 3.5 is doing something similar for image manipulation.

    • Simon 8:41 pm on July 28, 2013 Permalink | Log in to Reply

      What about using a code of this kind to catch the error and reverting the file.

      function fatal_error()
      $last_error = error_get_last();
      if ($last_error) {
      #On fatal errors this will fire. revert the the latest working version of: $last_error[file]
      # and use the rest of the array to describe the error to the user.


      • Alexander Hoereth 10:51 am on August 11, 2013 Permalink | Log in to Reply

        This would only help if the changed code is executed on the code editor page. This is for example not the case when editing a theme’s 404.php..
        Seems pretty difficult to do, but thanks!

    • Denis de Bernardy 8:43 am on August 7, 2013 Permalink | Log in to Reply

      For a more proper test, and a fail-safe one at that, look into the plugin activation logic. The procedure in there amounts to running a new WP process and checking if there’s an error, then rolling back the change if there is.

      • Alexander Hoereth 10:55 am on August 11, 2013 Permalink | Log in to Reply

        Thanks. I also already thought about that. The PHPdoc of the activate_plugin function says the following
        It should be noted that in no way the below code will actually prevent errors within the file. The code should not be used elsewhere to replicate the "sandbox", which uses redirection to work.

        While I still considered replicating it I do not think it would do what I am interested in here. It only checks if the plugin activation results in errors – which I wont manipulate. But a theme activation for example does not involve all files being executed..

  • Alex 8:09 pm on July 16, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 4 

    Version 0.4 of the Code Revisions plugin is out. If you used a prior version you might need to manually remove posts of the post type code and post meta fields with the key _code_revisions. Uninstall and upgrade functionailty which removes/refreshes this stuff automatially will of course be integraded in later versions.

    Main new feature this week: Taking direct file changes through ftp or plugin/theme updates into account (#303). A new revision is automatically created and the user is notified with an admin notice:

    This file changed in the meantime.Not sure about the text there yet 😉 But this can be changed later on. A problem I ran into here was that I need to approach this from a plugin point of view and cannot hook into core in all places I would possibly like to. The intial idea was to save a file’s last modified timestamp (using filemtime) and check it when ever viewing the file in the editor again. Problem is the file is written right before the page is redirected – which is why I cannot get the file modified time after the file was written. So now I am using md5-checksums of the file’s content instead. This results in an additional file read to generate the checksum (using md5_file) every time an editor is being viewed – again, this could be avoided if I could check the sum after the file is read for being used in the editor. If this functionality gets into core I will need to move to one of the more direct approaches.

    Another thing which did cost me quite some time to find out: The time points revisions are created by core changed. I mostly try to stick to core functionality and for creating revisions only used wp_insert_post and wp_update_post – revisions were created automatically. Now this behavior was changed for wp_insert_post (#24708) and I did need to adjust a little bit (#324). This now results in a new problem because the first two revisions are created in the same second and therefore considered to both be the currently “live” revision (#326). Most simplest way might be to apply some JS to reactivate the button. Need to look into this.

    Midterm and with it “feature completeness” is moving closer. Next on my list is to prevent user’s from breaking their installation through fatal errors.

    See you next week, I would appreciate testing and maybe some bug reports! Thanks!

  • Alex 4:59 pm on July 9, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 3 

    Week 3 of GSoC: Half-way to midterm and half-way to feature complete beta.

    The last week was about restoring code revisions (#296). There again the problamatic part was how differently WordPress handles themes (#306) and plugins (#307). By now I am actually considering to streamline the two editor files (theme-editor.php and plugin-editor.php) using a general code editor class. Espacially plugin-editor.php does some weird stuff: The plugin query var for example often contains the last viewed file instead of the plugin’s main file. There are actually already multiple trac tickets regarding stuff like this. But this would be out of scope of my project – maybe something for after midterm, depending on the project’s progress.

    Until next tuesday I will teach the plugin to pay attention to direct file changes through ftp or theme/plugin updates (#303). Users should be able to see how their own changes were overwritten. This is of special interest when the user intends to reimplement his own changes or wants to check if bugs he fixed are now fixed officially.

    If you are interested you can test version 0.3, report bugs and follow on further progress on trac.

    • George Stephanis 5:04 pm on July 9, 2013 Permalink | Log in to Reply

      Apologies if it’s already been asked and answered, but do you intend to distinguish between file changes due to upgrading a plugin, and the user changing the file on their own somehow?

      • ahoereth 8:40 pm on July 9, 2013 Permalink | Log in to Reply

        It is not intended to create a revision of every file edit. The revisions are intended for in-editor edits only. But to keep a clean record of changes the plugin will check if the file has changed since the last edit and if thats the case it will create a new revision of the file and notify the user.

        So no, no distinguishing between direct and in-editor file changes. But we only log them if there has been in-editor changes to this file before.

  • Alex 4:58 pm on July 2, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 2 

    What’s going on here? Thought tuesday is code revisions day here on make core.. 😉

    Well, doesn’t matter that much, not much to report today. Version 0.2 gives you a metabox below the code editors listing all revisions as you know it from the post and page editor (#286). The metabox tries to replicate the original as close as possible. A difference here is that it is created using JS and an AJAX request. This ensures that I don’t have to edit core files but it also results in no metabox with JS disabled. As it looks at the moment the latter won’t be a problem because revision viewing will be JS-only starting with 3.6. Furthermore from now on you get redirected to the corresponding code editor when trying to access the post editor for posts of the code custom post type (#289). This is especially helpful when clicking the title displayed at the top of wp-admin/revisions.php

    At the moment I am closely following the final pre 3.6 changes in the revisions component. The next steps for the project is to introduce restoring (#296) and to pay attention to direct file changes (#303).

    • Ryan McCue 7:15 am on July 3, 2013 Permalink | Log in to Reply

      Sorry about the slightly early post on my behalf, I always forget how far ahead we are in Australia (it was technically Wednesday here when I posted). 🙂

      • ahoereth 11:05 am on July 3, 2013 Permalink | Log in to Reply

        Ugh didn’t think about the possible 12h time difference either 😀 But I don’t care actually. Just reporting what one could also read on trac.

  • Alex 4:33 pm on June 25, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 1 

    My initial post did get quite some feedback – not overall good. I expected the negative feedback. I did not take part in the discussion, but I think others did a nice job there (thanks Jen & Aaron). Also thanks to the developers who offered to give support when I might get stuck.

    To make it short:  I already prepared myself for this project before the official coding phase started and could skip the initial “warm up phase”. At the moment I am ahead of the timeline.

    This week mostly was on the connection between a file and a post (#284), the initial creation of a post when a file is edited for the first time (#285) and the updating of the corresponding post on every edit (#287). I also chatted with my mentors about the brought up security worries. We will definitely look into those and discuss them (and possible solutions) with lead developers – the code resulting from this project will not make it into core if it introduces security flaws!

    The next week will be about viewing code revisions. This on the one hand includes a revisions list which needs to be added below the editors (#286) and on the other hand fixing possible problems with the revisions view on revisions.php (e.g. #289). I will take the negative feedback as a challenge and still hope to get code revisions into core. Till next week then.. Comments are open!

    • George Stephanis 4:39 pm on June 25, 2013 Permalink | Log in to Reply

      Sounds good!

      RE: Viewing Code Revisions, this is already mostly functional in things like the Custom CSS module in Jetpack, which stores the data as a Custom Post Type.


      It’s probably a quick win, for the moment at least.

      • ahoereth 11:01 pm on June 25, 2013 Permalink | Log in to Reply

        Thanks! Didn’t know jetpack already does something similar. I guess most of the actual revision viewing won’t need any specific changes. Thats exactly why this project is about “WordPress native” code revisions: Most stuff is already there and just needs some adjusting.

        • George Stephanis 11:25 pm on June 25, 2013 Permalink | Log in to Reply

          Yup. The Jetpack Custom CSS module just stores it in the DB and then enqueues something that outputs it in the header — no files required.

          The Revisions formatting is new in 3.6, @westi and @ethitter led the charge on that front.

          It may be nice to use something to do syntax highlighting on the diffs and such, though, for the revisions.

    • Nile Flores 6:03 pm on June 25, 2013 Permalink | Log in to Reply

      I’ve got a concern on the permalink structure. This was actually brought up originally in my FB group All About WordPress – https://www.facebook.com/groups/AllAboutWP/permalink/630256080319512/ . One of the users has 3.6 installed on her live site and is saying that WordPress is automatically editing the permalink structure for the user.

      This is not web etiquette. I don’t like my permalink structure to be altered automatically and its a pain if I have to alter them to add words, rather than just cut out what I don’t want.

      It seems I am not the only one with this concern. NOW, if there were an option to disable or enable it in the feature, this would be great because at the moment there are none.

      In fact, I am confused where I should be saying this, but it is obviously something that needs addressed.

    • Nile Flores 6:07 pm on June 25, 2013 Permalink | Log in to Reply

      I apologize… 3.5.2 this is occurring. And no plugins are installed that have this ability in it. Strange? Or should I submit this to the support forums?

    • Erlend Sogge Heggen 8:55 pm on June 25, 2013 Permalink | Log in to Reply

      For the record I think this is a brilliant project, and I’m pretty sure the majority of WP users would agree with me. From what I could tell, the criticism you have received is poorly misguided and only represents a very small minority.

      The only thing that worries me about code revisions is that child theme shops like Studiopress can now make a stronger argument for premium child themes. The devs better be weary of that trend.

      • ahoereth 11:02 pm on June 25, 2013 Permalink | Log in to Reply

        Thanks for the support 🙂 Why do you think code revisions give theme shops stronger arguments for premium child themes? Not sure I get what you are referring to.

      • Aaron D. Campbell 2:29 pm on June 26, 2013 Permalink | Log in to Reply

        I’m not sure what you mean about premium child themes. As far as I know, that’s all StudioPress does. I think all their premium themes are built as child themes for their Genesis framework. I don’t think it’s a trend to be wary of, I actually think it’s a great way to do premium themes.

      • Ipstenu (Mika E.) 3:31 pm on June 26, 2013 Permalink | Log in to Reply

        What’s wrong with it? A theme is a theme, and if you edit someone else’s child theme (by the way, StudioPress -rarely- changes theirs) then you’re in a less-worse spot, since you have your code changes saved as revisions now. yay! 🙂 Isn’t that the goal?

  • Alex 2:37 pm on June 14, 2013 Permalink
    Tags: ,   

    Summer of Code Revisions 

    Hey everyone! I’m Alex, one of the Google Summer of Code interns who will be hanging around here for the next couple of months. I currently study Cognitive Science at the University of Osnabrück in Germany — not too obvious to see the connection to web development there. Cognitive Science is actually splitted into 8 different modules. Neurobiology, Neuroinformatics, Philosophy, Psychology, Linguistics, Mathematics, Artificial Intelligence and Computer Science. I’m mostly focussing on the last two and even consider switching to a dual bachelor setup with Cognitive Science + Computer Science.

    So, web development and WordPress are mostly just hobbies of mine — I hope to change this in the future. I did a couple of paid jobs creating WordPress websites and also have a couple of plugins in the repository. I really like the idea of open code and bringing web publishing forward this way. Not having one brand control so many websites directly is a huge advantage in comparison to other web publishing tools.

    My project will be bringing WordPress native revisions to the theme and plugin editors. Some developers are of the opinion that it would be best to strip the code editors from WordPress core. I think they are an important launch pad for average WordPress users to get into touch with their site’s code base. It’s a first step on the way to submitting a first patch to core.

    An obvious problem when enabling users to edit their websites code is that they might break things. Changes can result in fatal errors which might break their whole site. With code revisions it will be easy to reverse to a specific version of a faulty site when something breaks. The idea here is not to make the editors interesting to developers but to make them more comfortable to use for website owners.

    Happy to work with you guys and to get some feedback. With enough eyes, all bugs are shallow 😉

    • Jen Mylo 2:42 pm on June 14, 2013 Permalink | Log in to Reply

      Great introduction, welcome to the team!

    • Roscius 2:48 pm on June 14, 2013 Permalink | Log in to Reply

      Great idea…looking forward to seeing the progress!

    • Tom J Nowell 3:15 pm on June 14, 2013 Permalink | Log in to Reply

      I’m sorry, you’re new and full of motivation and enthusiasm, but what you’re planning is just plain wrong. You’re giving the tools to the people most unable to comprehend the security risk of being able to modify code via the backend, the very tools to do so.

      Many developers would consider such an effort a vast waste of time and effort, and we already have plugins that are far more powerful than what you suggest, e.g. https://wordpress.org/plugins/wpide/

      Instead, if you’re wanting to help newer users get into the code, I’d suggest:

      • Read only syntax highlighted view of the code. Editing is bad, but looking at the code is still useful
      • Directions to enable or view the error log to dispel the mysterious and incredibly frustrating white screens of death that new users can face
      • Indications of things such as which plugins etc are svn versioned
      • Fixing the inconsistencies inside core, e.g. default WP Settings not using their own Settings APIs correctly

      And if you must modify the editor, add:

      • Auto-indenting via something such as behave.js
      • Blood red highlighting of things like eval and query_posts
      • Aaron D. Campbell 4:13 pm on June 14, 2013 Permalink | Log in to Reply

        As much as I discourage clients from using these tools, the truth is that they are extremely useful to many users so they won’t be getting removed from core any time soon. So adding in some additional safe guards to allow for rolling back, and even adding in some checking for fatal errors before saving would be extremely useful. If done right, I can definitely see this being brought into core.

        Also, all the mentors for this program (several core devs and plenty of core contributors) rated all the projects, and this one made the cut. I don’t think trying to discourage a student at this point in the game is very useful.

        • Tom J Nowell 4:27 pm on June 14, 2013 Permalink | Log in to Reply

          This isn’t a game, and while these changes are user friendly, that comes at a very real security cost. There are more effective ways of improving the situation, and I named several so I hardly consider it discouragement

      • George Stephanis 6:39 pm on June 15, 2013 Permalink | Log in to Reply

        Tom, if you’re really so concerned about people being able to edit the code from the theme/plugin editors, you can make them read only by simply adding define( 'DISALLOW_FILE_EDIT', true ); to your wp-config.php — this project isn’t going to change that.

        • lovingboth 10:34 pm on June 27, 2013 Permalink | Log in to Reply

          The problem with that is that it means it partially breaks at least one widely used plugin, Quick Cache. With it set to true, QC’s settings are unavailable, and its button doesn’t display in the admin screen or bar.

          It would be very useful to have a setting – not a plugin, because those are easy to deactivate – that just hides the editors.

    • Marcus 3:30 pm on June 14, 2013 Permalink | Log in to Reply

      Firstly, welcome and good luck!

      I sort of agree with Tom’s opinion on your efforts possibly being more valuable directed toward something else, but the fact that there’s a plugin won’t matter when a user screws up a file and then wonders how to fix it.

      How useful revisions would be is also debatable. Once you get a fatal error, revisions can’t be accessed anyway and an ‘average’ user probalby won’t know how to undo what they did.

      Personally, I find the editors to be dangerous, and they should be enabled by a setting and disabled by default, but that’s for another discussion I think 🙂

      • Tom J Nowell 3:40 pm on June 14, 2013 Permalink | Log in to Reply

        One could save the edits to a temporary file and run the PHP syntax checking param over the file before saving to the actual file, using php_check_syntax. Either way it encourages bad practices, and it also raises the problem of how these revisions are going to be saved.

        If they’re saved on the file system that’s clutter and a potential security risk. if they’re saved as posts in the database that’s an even greater risk, as it both exposes code to lucky attacks, and gives them an avenue to modify the filesystem.

        • VegasKev 5:45 pm on June 14, 2013 Permalink | Log in to Reply

          As much as I’m all for finding ways to get the ‘average’ user more involved and engrained in “how and why” wordpress is so effing awesome….I have to say that Tom has expressed some core concerns here that should definitely be discussed.

          While I know basic (and a few advanced) security measures, I’m by no means an security expert, so I can’t backup what Tom is saying is “risky”, but I’m sure that it’s worth taking the time to consider some safety mechanisms for what @ahoereth is proposing.

          I’ve been working with WP for the last 4 years and I still have new clients that are extremely fearful of using WordPress for all the security issues that have been brought to light over the years. Everyone that has worked to make WP so much more secure in the most recent versions deserves a pat on the back for helping all WP advocates regain credibility. It would be a damn shame if we take a step backwards in security over something like a “cool neat feature” for the untrained (and sometimes uncontrollable) mouse clicks of a noob looking to “check stuff out”….just saying.

        • userabuser 4:02 am on June 15, 2013 Permalink | Log in to Reply

          Introducing revisions to the inbuilt editors is a good idea, but the idea of inbuilt editors in itself is completely flawed to begin with. So while I support the will to introduce fail safe mechanisms, I agree with you outright that this introduces yet another potential security risk.

          Of recent times and on average I fix two infected, hacked, what-have-you sites per week and maybe one site if its a slow week.

          Can this idea be proven not to introduce any new security risks and vulnerabilities?

          If so, then go for it…

          If not, then do we really need another way for sites to get all jacked up by malicious users?

          • Jen Mylo 12:00 pm on June 15, 2013 Permalink | Log in to Reply

            There are two situations where having the built-in editors cause problems. 1. People give away admin rights like logo-encrusted keychains at a car show and then the new admins abuse the power. 2. Someone who has admin rights deservedly but doesn’t know code makes a mistake. We don’t need to take away this important stepping-stone tool to avoid bad actors.

            Some people make bad decisions about who to give admin roles. See years of Club Penguin support forum exchanges… they go something like this:

            “My site’s been hacked!”
            “This person is an admin.”
            “I know, I made them an admin, but I didn’t want them to kick me out or do this stuff!”
            “Next time, don’t make them admins, make them authors.”
            “I want to make them admins so I get more points!”
            “If you make someone an admin on your site, you are giving them the same power you have, and it’s effectively not just your site anymore. Stop it.”

            If people don’t listen, they don’t listen. There’s only so much we can do.

            Some clients aren’t professional WordPress developers, and shockingly they might make a mistake if they try to edit code on their own. I see two types of pros on the other end of this scenario:

            “What happened, Client?”
            “I don’t know, Pro Developer. I thought I could fix this thing and then I was in the editor, and then suddenly it was broken. Can you please fix it?”
            “It’ll take me a few hours to undo this, so I’ll have to charge you, but yes.”

            cut to IRC:

            prodeveloper19: My client is so stupid I can’t stand it, now I have to spend 3 hours fixing what they broke.
            jenmylo: Please don’t call your clients stupid, it’s mean-spirited at best. For *most* of your life you didn’t know how to do this stuff, either. Anyway, this is what they are paying you for, so complaining about getting 3 more hours of billable work is ridiculous.
            jenmylo: The standard of professional practice here would be to keep a backup of the original files yourself. If you had your own backups in your client files, fixing the mistake would take you a few minutes instead of a few hours to re-code from scratch.

            “What happened, Client?”
            “I don’t know, Pro Developer. I thought I could fix this thing and then I was in the editor, and then suddenly it was broken. Can you please fix it?”
            “Sure, I can fix it for you. I’d like to suggest we use a plugin to hide those editors moving forward to prevent this from accidentally happening again, though. If you get to a point where someone in-house takes over the site and knows the ins and outs of the code, it’s a simple matter to turn off the plugin and restore access to the code editors. What do you think?”
            “Sounds good, thanks.”

            cut to IRC:

            prodeveloper28: I love plugins. Love them.
            jenmylo: Me too! Any one in particular?
            prodeveloper28: One that hides the code editors from admins so my client can’t break the site again by accident.
            jenmylo: Free plugin on wordpress.org?
            prodeveloper28: Yep. Free software rocks!
            jenmylo: Maybe today would be a good day to donate to the plugin developer. 🙂

            When we have code revisions, even these scenarios will be simple to resolve.

            • Franz Josef Kaiser 9:07 am on June 26, 2013 Permalink

              So, @jane how does this fix the problem? If our “prodeveloper28” adds a plugin that denies access to the Theme/Plugin Editor, whom does the editor again help then? The developer surely won’t use it and the client can’t access it.

              But if our “prodeveloper28” himself would use the built in editor, then the things will happen:

              1. Her/His changes will be gone on update.
              2. Her/His changes won’t get added to the themes/plugins real svn/git/hg history.
              3. If he pulls in the changes (which were saved to the posts table) s/he made in the Theme/Plugin Editor after an update erased them, then there’s a high chance that the code is outdated and won’t play nice with the updated version.
              4. No one will call her/him “developer” again. Not to mention the lost status of “pro”.

              If people don’t listen, they don’t listen.

              I’m not sure who’s not listening here. Whipping valid concerns off the table with posting fictional and sarcastic, reddit-style chat discussions instead of a real answer, isn’t helpful either.

        • Nashwan Doaqan 6:42 am on June 16, 2013 Permalink | Log in to Reply

          I agree with you @Tom J Nowell … even if “Code Revisions” feature looks helpful for users but It need to think about it more deeply.

      • Nashwan Doaqan 6:34 am on June 16, 2013 Permalink | Log in to Reply

        “Personally, I find the editors to be dangerous, and they should be enabled by a setting and disabled by default, but that’s for another discussion I think”

        I agree with you, So what about introducing “WP Developer Mode” like the Android 🙂

    • WPsites 4:15 pm on June 14, 2013 Permalink | Log in to Reply

      I added syntax checking to the WPide plugin. I didn’t go with the PHP php_check_syntax() function I think because of issues on different web server setups. Instead I used the PHP-Parser library to check syntax.

      Maybe PHP-Parser should be added to core to reduce the chance of breaking a site when editing a PHP file with the inbuilt editor.

      On WPide a backup/revision is saved once an hour. Which is generally enough to recover from a disaster as you’ll notice it straight away because the editor will not save, the site won’t work. If the average user did a similar change with the built in editor then the only way to fix it is through SSH or SFTP. With WPide the automatically saved backups stand as independent files and can be restored from the editor without touching the back end WordPress install. You can see an example of the restore code that is automatically added to the file backup here https://gist.github.com/WPsites/5783087

      ahoereth: good luck with this. Feel free to get in touch if you want to discuss anything with me.

      • Bryan Petty 5:27 pm on June 14, 2013 Permalink | Log in to Reply

        I’m not sure Tom is aware of this either, but you likely didn’t go with php_check_syntax() because it was only ever available in PHP 5.0, and promptly removed from PHP before 5.1. You can only use built-in PHP syntax checking from the command line, so that brings obvious limitations that make it impossible to use from the core WordPress editors.

        You were on the right path to look for something like PHP-Parser, but that’s definitely also something we would never bundle with WP core.

        • Ryan McCue 8:01 am on June 17, 2013 Permalink | Log in to Reply

          Not to mention, PHP-Parser is PHP 5.3+ only (it uses namespaces). Not something that should be in core in any case.

      • ahoereth 2:31 pm on June 17, 2013 Permalink | Log in to Reply

        Thanks for the support 🙂 WordPress is actually doing some basic error checking when saving files edited in the plugin editor. Just by including & activating (it is deactivated on-save) the plugin and checking for any unexpected output in the buffer. I am not planning to use an external class for it and, as Bryan said, `php_check_syntax()` is not available.

    • Bainternet 8:15 am on June 16, 2013 Permalink | Log in to Reply

      When I added a sort of revision control to my plugin Advanced code editor I actually felt like using the posts table to store the revisions would be an Overkill, So I created a file “meta” table and used the Metadata API. But the more i think about it the more i see that using the posts table would do the job just fine.

      Also feel free to contact me if you need and Good Luck.

    • adamsilverstein 7:38 pm on June 17, 2013 Permalink | Log in to Reply

      glad to see your project was selected – bravo! hope you do use the new core revisions code – happy to assist in development, if it doesn’t make it into code maybe good plugin territory.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar