Release Notes: SiteTree 1.3.1 and 1.3.2
These updates are recommended to all users of SiteTree 1.3 mainly because they address an issue that caused a security warning to show up as soon as a post or page was sent to (or restored from) the trash.
Note: this post has been updated on 27 September 2012.
Along with some bug fixes and minor changes, I improved how the plugin reacts to WordPress action events (such as a post publishing, the updating of an author’s profile and so on): now, SiteTree schedules the rebuilding process only if it catches an action event related to a kind of content actually included into one of the Sitemaps.
About the “304 HTTP Response” feature just added: you don’t need any setup to enable this functionality, however, your server must support the “If-Modified-Since” HTTP header to make it work.
Full List of Changes
- New: if the Google Sitemap has not been rebuilt since the last remote request, the plugin sends back a “304 Not Modified” response.
- New: the modification date of the page where the HTML5 Sitemap is shown it’s updated whenever the Sitemap is rebuilt.
- New: the version number and the date of installation are displayed in the upper-right corner of the settings page.
- Updated POT file.
- Update: the available screen options change according to the plugin setup.
- Update: modified the “Powered by” notice from “Sitemap Powered by SiteTree” to “Powered by SiteTree”.
- Update: the ‘View’ button in the settings page no longer triggers the opening of a new browser tab on every click.
- Enhancement: halved the size of the plugin folder.
- Enhancement: improved events handling.
- Fix: if a post (or page) revision was restored, the Sitemaps were rebuilt.
- Fix: if a custom post type was trashed, the Sitemaps were rebuilt.
- Fix: a security warning was displayed every time a post or page was trashed or restored from the trash.
A Side Note on SiteTree 1.3.2
I pushed out this second minor update to fix another security warning and to adjust the newly added web caching functionality — a missed HTTP header prevented the cache validation to work as expected.
Please, let me know in the comments below if you encounter any bugs that might be introduced in version 1.3.2
3 Comments
After the plugin update, I got this error message:
Hi, thank you for the note. That
error_log()should definitely not be there! :) I’ll publish a patch within a few hours to fix it.If you continue to see this warning after the update, feel free to reply here or to post in the support forum.
Thanks for the fast response. The latest update works. TQ