MTEntryModifiedDate tag bug

| 3 Comments | 2 TrackBacks

On the MT Forums, I documented the bug that causes the <$MTEntryModifiedDate$> tag to always display the same date as <$MTEntryDate$>, even if the two dates were different. This tag has never worked correctly since its release with MT 2.65 (Dec. 2003).

Here's how to fix <$MTEntryModifiedDate$> so it works correctly:

Change line 784 in (line 780 in MT 2.65

` $args->{ts} = $args->{modification_timestamp}; the following:

` $args->{ts} = $[0]->{modificationtimestamp};

Save the modified, upload to the server in ASCII mode, and the MTEntryModifiedDate tag should now function correctly. (You'll need to rebuild your templates to see the new code take effect.)

Here is why MTEntryModifiedDate did not work:

When an MTEntries tag is processed, MT stores the modified_on date within the context of the entry.

(Line 690 in

for my $e (@entries) {
    local $ctx->{__stash}{entry} = $e;
    local $ctx->{current_timestamp} = $e->created_on;
    local $ctx->{modification_timestamp} = $e->modified_on;

This is the code that specifically handles MTEntryModifiedDate tags (starting at line 782 in

sub _hdlr_entry_mod_date {
    my $args = $_[1];
    $args->{ts} = $args->{modification_timestamp};
    _hdlr_date($_[0], $args);

What this code is supposed to do is read the entry modified date from the entry, store it as a 'ts' (timestamp) argument in the argument list, then pass the entry context and the argument list (including the new 'ts' argument) to the code that handles MT's date tags.

Line 784 fails to correctly read the entry modified date:

    $args->{ts} = $args->{modification_timestamp};

...because it is trying to read the entry modified date from the list of arguments ($args), instead obtaining it from the entry context where it was stored (which can be accessed via $_[0]).

In MT's date handler code (line 1068 in

sub _hdlr_date {
    my $args = $_[1];
    my $ts = $args->{ts} || $_[0]->{current_timestamp};

...MT then picks up the createdon date instead (3rd line above), because the MTEntryModifiedDate code failed to properly read the modifiedon date (the 'ts' argument here will be empty/undefined). Note that MT picks up the createdon date here from $[0] (the entry context), not $args (the argument list).

Update 06-Jun-2004: Phil Ringnalda reminds me in the comments that there's one other place where the MT code needs to be fixed to make the MTEntryModifiedDate tag to work in individual archives:

lib/, after line 495 [MT3D], add

$ctx-&gt;{modification_imestamp} = $entry-&gt;modified_on;

(individual entries don't get their context set up in, they get it there).

I believe line 319 is the equivalent line in MT 2.661 lib/ to insert the above code after.

Thanks, Phil!

2 TrackBacks

Tweezer's Edge 1st Anniversary ! Tweezer's Edge made one year's old April 28th, Happy Blogday! I remember when TweezerMan first started "dinking" around with his blog. Read More

According to the Movable Type support desk it's a known bug that <MTEntryModifiedDate> sometimes returns the original publishing date rather than the modification date when used in a dynamic template. I think this must be a regression of the same... Read More


I believe Ezra fixed this in MT3.0D as well.

I did not know that at the time I wrote this post, but I found this out later - see "MTEntryModifiedDate tag and MT3"

Though inquiring minds want to know whether or not it's fixed in MT3.0E for individual entries, which get their context set up in instead.