Yes, this is one of the more 'drastic' changes we found necessary for
the app. It was improper to be storing such a value in the
'created_on' column to begin with, so we're correcting that now. It
will be covered in the developer release notes, but thank you for
bringing it up.

Also noteworthy: the modified_on columns are changing from a
timestamp in MySQL to a simple datetime type. This gives the CMS the
option to update this column when appropriate. Otherwise, when some
upgrade process has to touch all existing entries, they all show as
modified as of the date of the upgrade. This makes the modified_on
column value far more reliable and useful for publishing.

-Brad


On Jun 26, 2007, at 12:45 PM, Kevin Shay wrote:

> Hi all,
>
> A user of my old DateTags plugin reported that part of it
> (MTNextNEntries) wasn't working under the MT 4 beta. Investigating
> this, I realized that mt_entry now has an "entry_authored_on" column
> in addition to entry_created_on. It appears that when you change the
> "Publish Date" of an entry in the CMS, it will actually update
> authored_on rather than created_on. Presumably, created_on will now
> always contain the timestamp that an entry was actually created, as
> it does with other objects that have the "audit" flag.
>
> I can see the benefits of this change, but just wanted to give other
> developers a heads-up. (If this was documented or discussed somewhere
> already, I missed it.) I'm guessing there's quite a bit of plugin
> code out there, in custom and one-off plugins as well as publicly
> released ones, that assumes that created_on stores the publication
> date and acts accordingly.
>
> Cheers,
> --Kevin
>
>

--
http://bradchoate.com/