2.1.1 Release - What Will Be There, What Will Not
Next week we will be releasing (finally) ExpressionEngine 2.1.1 to you. It has a great deal of enhancements and bug fixes, as well as improved security. The full details will be found in the change log when it is released, but here are some highlights.
- Improved version update notification, to indicate normal vs. high priority releases
- show_empty= parameter of the Channel Categories tag is now ::drum roll:: channel specific!
- Added a {last_segment} global variable
- The Comment Module has a number of improvements, including it’s own control panel with better comment moderation, new variables and parameters, built-in inline editing for commenters, and smart notifications.
- Moblog module now works with POP3 over SSL (hello, GMail!)
- Improvements and bug fixes to the Channel Entries API, primarily for third party developers
- Over 50 bug fixes
In order to prevent even further delays, though, there is some bad news: the date bug dealing with entries jumping an hour when you are editing an entry that is dated in the opposing DST will not make this release. This bears explanation, because it wasn’t ignored; on the contrary, it’s had significant attention from the team for the last three weeks, but the fixes simply weren’t good enough. There’s been a recent outcry for increased transparency from us, and we’re committed to providing it, so here it goes:
The issue is that in the summer, when you post an entry dated for the winter, the system compensates for the one hour difference so that the 7pm you input in the summer still means 7pm when winter rolls around and that entry needs to be published.
In 1.x, this calculation was forced, and it worked (mostly) because 1.x’s dates were not real UTC/GMT dates. They were relative to the server time, and the localization faked it so that it seemed like real GMT dates, but if you ever moved an installation to a server in another time zone, there was potential that all of your dates would be wrong. We fixed this in 2.x, one of the largest database changes in the updater, fixing every timestamp in your installation to be a real GMT date.
What got overlooked is this hack from 1.x to handle summer/winter entry dates described above, which remained hidden during beta and 2.1’s launch, undoubtedly because everyone’s system clocks were set for the winter (users and testers included), where this problem doesn’t exist. As soon as DST was back on, then it became noticeable.
So it would seem like the fix is simple. 2.x uses real GMT dates, so this arbitrary addition/subtraction of one hour to make 7pm = 7pm at any time of the year shouldn’t be necessary anymore. And that’s true. But now we are at the complicated part that is a unique problem to ExpressionEngine and to 2.x: the “DST Active on Entry” and “Honor the Daylight Saving Time setting associated with each channel entry” settings.
These two settings existed in 1.x to add fine grain control over time display between DST seasons. However, they’ve always been confusing for developers and users, and we’re pretty sure that most people don’t understand what they’re for, when to use them, and what the effects are of the combinations of those settings. If 2.x were a stand-alone product and we didn’t have to worry about upgrades from 1.x, we’d just remove these two settings. But alas, that’s not an option. There are both 1.x sites and 2.1 sites where publishers have fiddled with these settings to get the results they are looking for on the front end, but the actual date stored in the database is not modified.
So the “correct” fix has the very negative impact of having all entries that publishers have used those settings to be off by an hour after updating to 2.1.1. Weighed in the balance, we’d rather have publishers continue watching dates closely on edit and working around this bug than we would suddenly breaking the dates for all of the entries on an entire site. So the fix for this issue is out until we can come up with a satisfactory way of determining not just what the date stored in the database is, but the intent the publisher had from when they edited the entry, and what settings they employed to achieve that. By reversing the old logic from those settings, we hope to bring those dates back to reality so that the simple correct fix to the problem works flawlessly.
It’s doable, but it means lots and lots of testing on real world sites. Hence, we are releasing what we have now while continuing to work on this fix, so that other fixes and enhancements aren’t held hostage by this one bug.
If there’s a small glimmer of light with respect to 2.x’s date issues this summer, it’s that the AM/PM bug is fixed. Small victories. In all seriousness, though, this release has significant improvements and many great new things, and we hope it marks an improvement and a beginning of restoration of trust, and we thank you for your patience with us on the DST entry date issue.
