Version 0.4 of the Code Revisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is out. If you used a prior version you might need to manually remove posts of the post type
code and post meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 (and super 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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
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!