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 listed in the change log when it is released, but here are some highlights.

Continue reading…

Now that’s stepping up to the plate and dishing out some transparency. Excellent update!

Thanks Derek!

Will SQL Query Caching remain disabled in this new version also?

Kurt Deutscher - 15 October 2010 08:30 PM

Will SQL Query Caching remain disabled in this new version also?

Yes, though it should be noted that we recommend not enabling that for the majority of environments anyway, since even in common MySQL configuration, MySQL’s native caching is vastly superior to anything PHP can do by writing to text files on the storage array.

I’m intrigued by the Comment Module improvements. Any chance you made any developer-friendly improvements in there? Some new hooks, perhaps?

Mr. Wilson - 15 October 2010 09:09 PM

I’m intrigued by the Comment Module improvements. Any chance you made any developer-friendly improvements in there? Some new hooks, perhaps?

Actually yes, we’ve removed the comment_form_action hook, and added a parameter ($comment_ids) to the delete_comment_additional hook, which we’ve moved above the delete query.

All good things, and the DST issue is completely understandable. We worry more about the CP bugs that our clients notice, than things we can easily fix transparently.

Keep up the good work!

Good news!

And I hear you regarding the date/DST issues. The whole database/system/user locale time subject can melt brains, I have experienced it.

This doesn’t mean that it shouldn’t be fixed but from what I have seen in other frameworks and content management systems while I dealt with it back then, it didn’t seem like anyone is ‘doing it right’ at all, also regarding timezones.

Most users probably won’t care at all but if you use the (future) ‘publish time’ field for something like annual financial reports or a news entry that might affect stock exchange and something goes wrong (even by an hour), things can get really really ugly.

Glad to see the update, thanks for the heads up and the hard work you guys are putting into this.

Regarding the DST issue, this may be an oversimplification of the issue, but I am curious why a global override is not an option? The current EE behavior that I see is EE altering timestamps at the time of input to compensate for DST, and at least in my case this falsely assumes that I want this to occur. Unfortunately, with future events I don’t—I want EE to give me back the time I put in according to UNIX, regardless of whether it is winter or summer, without resorting to a hack or PHP workaround.

Since removing the feature seems unfeasible due to backward-compatibility, I would love to see an option in EE that simply says “Turn off all DST behaviors” or something to that effect. Rather than breaking any existing functionality, it would simply live as an option to override the code setting an offset, and leave the user input to be handled in whatever way the developer decides is best for his/her case.

As I said, I may be over-simplifying something that is much more fundamental and complex behavior, but it’s my 2 cents.

In any case, this update is terrific news.

Thank you Derek and the rest of Ellislab team. This is the type of discussion we want to be in. Btw, are we going to have the updated (in your hotfix) cp.publish.js added as well?

Thank you and good progress. much appreciated and very much understood. A pleasure to see positive actions and news.

Todd—“Now that’s stepping up to the plate and dishing out some transparency. Excellent update!”

Yes, very nice!

So, how about we attack the problem at the source? Let’s start a world-wide, grassroots campaign to eradicate the scourge that is DST from our planet… for the sake of our children!!

Thanks fro me also to Derek and the EllisLab Team, much appreciated, simply love EE.

Afraid I’m another user who gets caught out every time with the DST on new set ups.

Look forward to 2.1.1 dropping!!

Why not release a separate patch to “fix” the DST issue for those interested in an immediate resolution?

Sean Sperte - 16 October 2010 07:30 PM

Why not release a separate patch to “fix” the DST issue for those interested in an immediate resolution?

Or, what about putting a fix into this release which at least makes DST right for any _new_ sites constructed.

That way, new projects can move forwards, or anyone who is willing to make some manual corrections on a site that isn’t too filled up.

The overall revise-what-1.6-did sounds tricky and time-consuming, and can be a patch or even possibly an add-on at later date?

In any case, good on you for first moves to greater transparency, which are understood.

Regards,
Clive