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.

#code-revisions, #weekly-update

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.

#code-revisions, #weekly-update

Code Revisions: Week 9

Version 0.7 is tagged and I am planning to submit it to the 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..

#code-revisions, #weekly-update

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.

#code-revisions, #weekly-update

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!

#code-revisions, #weekly-update

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!

#code-revisions, #weekly-update

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.

#code-revisions, #weekly-update

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).

#code-revisions, #weekly-update

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!

#code-revisions, #weekly-update

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 😉

#code-revisions, #weekly-update