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:
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_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!