WolaWola

えーと、一年近く更新サボってました。
いろいろと報告する内容があるのですが、それはGWに余裕があったらということで。

EntryNumber By Dayプラグインに機能を追加しました。

naoaki011/mt-plugin-entrynumber-by-day · GitHub

とある案件で、その日の連番をカテゴリー縛りでやりたいという話があり、あぁあったら使いそうだなと記憶していたのですが、先日のMTCafe Tokyo 2013 Springの帰りに藤本さんに、カテゴリーに属さないエントリーをリスティングするにはMT5.1移行以降で使えるleft joinってのを使えばいいんだと教えてもらい、早速書いてみました。

ブログ記事のプライマリーカテゴリー内で、同日何番目の記事かを出力します。記事にカテゴリーが指定されていない場合は、同日のカテゴリー指定されていない記事として何番目かを出力します。（このためにleft joinが必要だった）
「MTEntryNumberByDay」と同じく「prefix」「zeropad」「always」のモディファイアが指定できます。

「MTEntryNumberByDay」についてはダイナミック・パブリッシングに対応済みですが、「MTEntryNumberByDayOnCategory」は、まだダイナミック・パブリッシングに対応していません。

以前の記事「EntryNumberByDayプラグインを改造してみた - WolaWola」

念のため補足ですが、基本的な使い方としてはブログ記事のアーカイブマッピングで、ファイル名部分にタグを書きます。オリジナルは野田さんが書いたものです。

チョット５月はいろんなことがありまして、まぁその件はいずれやるとして、久しぶりに記事書きます。

商用サイトを作るときなどに、複数ブログを扱うことがあると思いますが、諸々の事情で（例えば、日英のコンテンツを別なパスに公開する必要があるとか）ブログの公開パスが同じ物が存在するということは、良くあると思います。

• ウェブサイト（http://www.hoge.com/）
  • ウェブサイトの日本語ウェブページ（http://www.hoge.com/・・・）
  • ウェブサイトの英語ウェブページ（http://www.hoge.com/en/・・・）
  • ブログ1（http://www.hoge.com/）
    • ブログ1の日本語アーカイブ（http://www.hoge.com/blog1/・・・）
    • ブログ1の英語アーカイブ（http://www.hoge.com/en/blog1/・・・）
  • ブログ2（http://www.hoge.com/）
    • ブログ2の日本語アーカイブ（http://www.hoge.com/blog2/・・・）
    • ブログ2の英語アーカイブ（http://www.hoge.com/en/blog2/・・・）

この様な場合に、それぞれのブログでダイナミックパブリッシングを利用しようとすると、うまく行かなくなるケースがあります。 その原因と、対応方法について説明します。

ダイナミックパブリッシングの簡略化した仕組み

動作には２つのファイルが関連してます。「.htaccess」と「mtview.php」です。

## %%%%%%% Movable Type generated this part; don't remove this line! %%%%%%%
# Disable fancy indexes, so mtview.php gets a chance...
Options -Indexes +SymLinksIfOwnerMatch
  <IfModule mod_rewrite.c>
  # The mod_rewrite solution is the preferred way to invoke
  # dynamic pages, because of its flexibility.

  # Add mtview.php to the list of DirectoryIndex options, listing it last,
  # so it is invoked only if the common choices aren't present...
  <IfModule mod_dir.c>
    DirectoryIndex index.php index.html index.htm default.htm default.html default.asp /test/mtview.php
  </IfModule>

  RewriteEngine on

  # don't serve mtview.php if the request is for a real directory
  # (allows the DirectoryIndex lookup to function)
  RewriteCond %{REQUEST_FILENAME} !-d

  # don't serve mtview.php if the request is for a real file
  # (allows the actual file to be served)
  RewriteCond %{REQUEST_FILENAME} !-f
  # anything else is handed to mtview.php for resolution
  # passthrough query parameters
  RewriteRule ^(.*)(\?.*)?$ /test/mtview.php$2 [L,QSA]
</IfModule>

<IfModule !mod_rewrite.c>
  # if mod_rewrite is unavailable, we forward any missing page
  # or unresolved directory index requests to mtview
  # if mtview.php can resolve the request, it returns a 200
  # result code which prevents any 4xx error code from going
  # to the server's access logs. However, an error will be
  # reported in the error log file. If this is your only choice,
  # and you want to suppress these messages, adding a "LogLevel crit"
  # directive within your VirtualHost or root configuration for
  # Apache will turn them off.
  ErrorDocument 404 /test/mtview.php
  ErrorDocument 403 /test/mtview.php
</IfModule>
## ******* Movable Type generated this part; don't remove this line! *******

ダイナミックパブリッシングを利用するようにした場合、ブログルート（この例ではブログの公開パスは/test/です。）のこんな感じの内容の「.htaccess」が書き出されてると思います。いっぱい書いてあるように見えますが、大半がコメントとフェイルセーフのための内容です。 Apacheでmod_rewriteとmod_dirが有効の場合、意味を持つのは、次の6行だけです。

Options -Indexes +SymLinksIfOwnerMatch
DirectoryIndex index.php index.html index.htm default.htm default.html default.asp /test/mtview.php
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)(\?.*)?$ /test/mtview.php$2 [L,QSA]

3行目でリライト処理を有効にし、4・5行目でファイルが存在しない場合のみ処理を限定し、6行目でクエリを引き継ぎながら処理をmtview.phpに渡しています。

<?php
    include('/usr/local/httpd/cgi-bin/MT/php/mt.php');
    $mt = MT::get_instance(90, '/usr/local/httpd/cgi-bin/MT/mt-config.cgi');
    $mt->view();
?>

「mtview.php」も同じくブログルートにこの様な内容で書き出されていると思いますが、この中で注意するのは、MT::get_instanceの最初の因数の「90」の部分です。これはこのブログのブログIDになります。 ここからは、このブログIDを頼りに、MTが管理している（バーチャルな）ファイルかを判断（実ファイルを持たないアーカイブパスも「mt_fileinfo」のテーブルに保存されてます）して、コンテクストに応じた処理を返すようになっています。

パスが同じブログが複数ある場合の問題と対応

ここまで読めば、気づいたと思いますが、このブログIDを元に判断するというのがキモで、その為、複数ブログが同じ公開パスを持っていた場合、それぞれのブログから「mtview.php」が書き出され、ファイルが存在するか判断する為のブログIDが、正しく与えられずにダイナミックパブリッシングの処理としてエラーになります。

この問題を解決するには、適切なブログIDをそれぞれ対象ごとに渡すようにする事が必要です。

異なる階層にそれぞれを設置する場合

最初に上げた例のような構造の場合は、公開パスは一緒でも、実際にファイルを書き出すパスは、それぞれ違っているので、各階層に「.htaccess」と「mtview.php」を置いてやれば解決します。mtview.phpの中で、それぞれ対応するブログIDを指定すれば解決です。

同一階層で処理を分ける場合

あまりないとは思いますが、複数ブログで権限を持つユーザーが異なり、それぞれが管理するウェブページがルートに書き出される場合、「.htaccess」をそれぞれで設置は出来なくなります。その要な場合は「mtview.php」はリネームしても動作するので、「mtview1.php」と「mtview2.php」を用意してそれぞれに対応するブログIDを書き、以下の様な「.htaccess」で振り分け処理をすれば大丈夫です。「file1.html」は「mtview1.php」で、「file2.html」は「mtview2.php」でそれぞれ処理されます。どちらにも合致しないファイルリクエストは、「mtview.php」で処理されます。

Options -Indexes +SymLinksIfOwnerMatch
DirectoryIndex index.php index.html index.htm default.htm default.html default.asp /test/mtview.php
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(file1\.html)(\?.*)?$ /mtview1.php$2 [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(file2\.html)(\?.*)?$ /mtview2.php$2 [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)(\?.*)?$ /mtview.php$2 [L,QSA]

おまけ

リクエストのエラーページをApacheで設定している場合でも、ダイナミックパブリッシングが有効なパス以下では、ダイナミックパブリッシングのエラーページが表示されます（システムテンプレートの「ダイナミックパブリッシングエラー」の内容）。存在しない全てのファイルのリクエストをダイナミック・パブリッシングが処理するからです。

対象とするパスが明確な場合は、特定のリクエストのみダイナミック・パブリッシングが有効になるように「.htaccess」を書いたほうがリクエストに対する反応時間や、ダイナミックパブリッシングの起動時間（ファイルがないことを返すまでに時間）を節約できます。例えばブログ記事（標準のアーカイブマップ）のみをダイナミック・パブリッシングの対象にする場合は、以下のようにすれば、でたらめなリクエストを投げられた時のエラー表示までの時間が短縮されます。

Options -Indexes +SymLinksIfOwnerMatch
DirectoryIndex index.php index.html index.htm default.htm default.html default.asp /test/mtview.php
RewriteEngine on
RewriteRule ^\d{4}/\d{2}/(.*)(\?.*)?$ /mtview.php$2 [L,QSA]

DynamicMTMLの場合も基本的な考え方は一緒ですが、「.htaccess」と「.mtview.php（DynamicMTMLの場合はmtview.phpではない）」の内容が、もう少し複雑になるので書き換えに注意が必要です。

アーカイブのページ分割には今まで、ダイナミックパブリッシングを利用したページ分割や、検索CGIを使ったページ分割、それにPagerやPageButeなどのプラグインを利用したページ分割などがありました。あ、あと実は未だに使っているMTPaginateなんてのもありましたね。

しかしこれらは、それぞれに長所と共に短所があり、必ずしもどれがベストな選択とは言えないところがありました。
ダイナミックパブリッシングはPHPによる動的生成、検索CGIはPerlによる動的生成であり、それぞれ表示するたびにそれなりの負荷がかかります。
それに対して、プラグインによるアーカイブ生成は、表示はスタティックファイルなので高速ですが、再構築時にページ数に応じて負荷が高くなり、継続的にコンテンツを投入されるサイトでの、カテゴリーアーカイブを分割するような場合には、TimeOutエラーなどで処理できなくなる確率が高くなります。

DynamicMTMLを利用することで、再構築時の負荷もが低いまま、表示時の負荷もそれほど高くならない、ページ分割処理が可能になります。（最近はほとんどこの方法でページ分割をこなしてる気がする）

アーカイブを作成

例として、カテゴリーアーカイブとアイテム一覧をアーカイブとして出力するようにしてみます。

カテゴリーアーカイブのページ分割

DynamicMTMLでのアーカイブは、スタティックなHTMLファイルとして出力されます。そのHTML内に書かれたMTMLを動的に処理することで、内容を出し分けます。

以下カテゴリーアーカイブのページング処理部分の内容です。ヘッダやフッタ、その他装飾のスタティックな部分は省略してます。MTEntriesループ内で表示されるものは、「ブログ記事概要」テンプレートモジュールの内容になります。
URLの後ろに「?p=2」などとすることで2ページ以降が表示されます。MTQueryというDynamicMTMLのタグでkey指定して受け取っているので、そこを変更すれば「?page=2」等に変更もできます。

クエリで受け取ったページからもろもろの変数設定する部分


<<MTRawMTML>MTSetVar</MTRawMTML> name="blog_id" value="<$MTBlogID$>">
<<MTRawMTML>MTSetVar</MTRawMTML> name="total_entry" value="<$MTCategoryCount$>">
<MTDynamicMTML>
<MTSetVar name="limit" value="20">
<MTQuery key="p" setvar="current_page">
<MTUnless name="current_page"><MTSetVar name="current_page" value="1"></MTUnless>
<MTVar name="current_page" op="*" value="$limit" setvar="last_entry">
<MTVar name="last_entry" op="-" value="$limit" setvar="first_entry">
<MTVar name="total_entry" op="/" value="$limit" regex_replace="/\.\d+\$/","" setvar="total_pages">
<MTIf name="total_entry" op="mod" value="$limit"><MTSetVar name="total_pages" op="++"></MTIf>
</MTDynamicMTML>


ココがMTEntriesループ部分


<<MTRawMTML>MTEntries</MTRawMTML> include_blogs="$blog_id" categories="<$MTCategoryLabel$>" limit="$limit" offset="$first_entry">
<MTRawMTML><$MTInclude module="ブログ記事概要" blog_id="$blog_id"$></MTRawMTML>
<MTML tag="/MTEntries">


ココからPager用コード


<MTDynamicMTML>
<MTIf name="total_pages" gt="1">
<MTUnless name="current_page" eq="1"><a href="<$MTCurrentArchiveURL$>?p=<$MTVar name="current_page" op="--"$>">前へ</a></MTUnless>
<MTFor var="x" from="1" to="$total_pages">
<MTIf name="x" eq="1">
<MTIf name="current_page" eq="1">
<span class="current">1</span>
<MTElse>
<a href="<$MTCurrentArchiveURL$>"><$MTVar name="x"$></a>
</MTIf>
<MTElse>
<MTIf name="current_page" eq="$x">
<span class="current"><$MTVar name="x"$></span>
<MTElse>
<a href="<$MTCurrentArchiveURL$>?p=<$MTVar name="x"$>"><$MTVar name="x"$></a>
</MTIf>
</MTIf>
</MTFor>
<MTUnless name="current_page" eq="$total_pages"><a href="<$MTCurrentArchiveURL$>?p=<$MTVar name="current_page" op="++"$>">次へ</a></MTUnless>
</MTIf>
</MTDynamicMTML>

first_entryはMTEntriesに渡すオフセット値になっていて、この値に1を足すとそのページに表示される最初の記事が、記事全体での何番目かという数字になります。last_entryはそのページに表示される最後の記事が、全体で何番目の記事かという数字になりますが、厳密には最終ページなどで分割数に満たない時はこの数字より小さくなります。
よくある「21ページ中7ページ（121～140）」の様な表示は以下のコードで表示できます。

<MTDynamicMTML>
<$MTVar name="total_pages"$>ページ中<$MTVar name="current_page"$>ページ（<$MTVar name="first_entry" op="++"$>～<MTIf name="current_page" eq="$total_pages"><$MTVar name="total_entry"$><MTElse><$MTVar name="last_entry"$></MTIf>）
</MTDynamicMTML>

アイテム一覧ページ

さてアイテムの場合はと言うと、基本的にはブログ記事と一緒で、こんな感じになります。assets_per_rowモディファイアなどと組み合わせると、それっぽいアーカイブページが作成できるものと思います。

クエリで受け取ったページからもろもろの変数設定する部分


<<MTRawMTML>MTSetVar</MTRawMTML> name="blog_id" value="<$MTBlogID$>">
<<MTRawMTML>MTSetVar</MTRawMTML> name="total_asset" value="<$MTAssetCount$>">
<MTDynamicMTML>
<MTSetVar name="limit" value="20">
<MTQuery key="p" setvar="current_page">
<MTUnless name="current_page"><MTSetVar name="current_page" value="1"></MTUnless>
<MTVar name="current_page" op="*" value="$limit" setvar="last_asset">
<MTVar name="last_asset" op="-" value="$limit" setvar="first_asset">
<MTVar name="total_asset" op="/" value="$limit" regex_replace="/\.\d+\$/","" setvar="total_pages">
<MTIf name="total_asset" op="mod" value="$limit"><MTSetVar name="total_pages" op="++"></MTIf>
</MTDynamicMTML>


ココがMTAssetsループ部分


<<MTRawMTML>MTAssets</MTRawMTML> include_blogs="$blog_id" sort_by="created_on" lastn="$limit" offset="$first_asset">
<MTRawMTML><$MTAssetThumnbnailLink width="200"$></MTRawMTML>
<MTML tag="/MTAssets">


ココからPager用コード


<MTDynamicMTML>
<MTIf name="total_pages" gt="1">
<MTUnless name="current_page" eq="1"><a href="<$MTCurrentArchiveURL$>?p=<$MTVar name="current_page" op="--"$>">前へ</a></MTUnless>
<MTFor var="x" from="1" to="$total_pages">
<MTIf name="x" eq="1">
<MTIf name="current_page" eq="1">
<span class="current">1</span>
<MTElse>
<a href="<$MTCurrentArchiveURL$>"><$MTVar name="x"$></a>
</MTIf>
<MTElse>
<MTIf name="current_page" eq="$x">
<span class="current"><$MTVar name="x"$></span>
<MTElse>
<a href="<$MTCurrentArchiveURL$>?p=<$MTVar name="x"$>"><$MTVar name="x"$></a>
</MTIf>
</MTIf>
</MTFor>
<MTUnless name="current_page" eq="$total_pages"><a href="<$MTCurrentArchiveURL$>?p=<$MTVar name="current_page" op="++"$>">次へ</a></MTUnless>
</MTIf>
</MTDynamicMTML>

他にも使い方が沢山

ダイナミックパブリッシングで動作するループタグで、limit指定やoffset指定が使えるものなら、応用可能です。
例えば、SearchEntriesを使うことで、簡単に複雑なクエリを処理する（DynamicMTMLのSearchEntriesタグは、フィールドの部分一致で指定が可能です）検索ページを作成できます。

この方法での負荷の発生は、主に表示時にダイナミックパブリッシング部分を動的に生成する部分になるはずです。
パラメータ部分に複雑ななクエリが必要な場合は、パラメータ生成までを静的に済ませられないかを検討したり、ブロック表示部の処理が複雑な場合は、別ファイルとして処理させておく等の手段が有効です。
単純なブロック表示の場合なら、さほど負荷は発生しませんので、そのページがダイナミックパブリッシングで処理されていると気づかないこともあります。

とある案件用に、カスタムフィールドプラグイン（あるウェブサイト上のフォルダを、管理画面の並び順（sort_by="user_custom"）に選択肢として出力する）を作ってみました。

MTタグ上では、「sort_by="user_custom"」を指定（というかSubCategoriesのデフォルトになりましたね）すれば良いわけですが、プラグインコード内で、以下のように書いてもまるで並び替わる様子がありませんでした。

my @folders = MT->model( 'folder' )->load(
            {   blog_id => $blog_id,
                parent  => '0'
            },
            {   'sort' => 'user_custom',
                direction => 'ascend',
            }
        );

そういえば、この並び替えデータってどこに保存されてるんだっけと、「mt_category」や「mt_category_meta」を見てみても、特に拡張されていません。ありそうなところを一通り見ていって、やっと場所がわかりました。「mt_blog_meta」に「category_order」や「folder_order」が保存されてました。値を見るとカンマ区切りのカテゴリーIDのようです。

コレをどうするんだか解らないので、やむを得ず、「MT::Template::Tags::Category」のコードを読んでみていくと、なんかおかしな事書いてあります。

        @cats = $class->load(
            {   blog_id => $ctx->stash('blog_id'),
                parent  => '0'
            },
            {   (     ( 'user_custom' eq $sort_by )
                    ? ( sort => 'label' )
                    : ( sort => $sort_by )
                ),
                direction => $sort_order,
            }
        );

$sort_byは指定されてるsort_byなわけですが、何故かそれが「user_custom」の時に、「sort => 'label'」を設定してます。え、なんで「label」とか思ったわけですが、その後を読んでいくとやっと理由がわかりました。

    elsif ( 'user_custom' eq $sort_by ) {
        my $blog = $ctx->stash('blog');
        my $meta = $class_type . '_order';
        my $text = $blog->$meta || '';
        @$cats = MT::Category::_sort_by_id_list( $text, \@cats );
        @$cats = reverse @$cats if $sort_order eq 'descend';
    }

あぁなるほど、「sort_by="user_custom"」の場合は別に処理するわけですね。それでどうやら先ほど見つけた「category_order」を、Categoryオブジェクト（上の@cats）と一緒に、MT::Category::_sort_by_id_listに渡すことで、並べ替えが行われるみたいです。

my @folders = MT->model( 'folder' )->load(
            {   blog_id => $blog_id,
                parent  => '0'
            }
        );
my $meta = 'folder_order';
my $text = $blog->$meta || '';
@$folders = MT::Category::_sort_by_id_list( $text, \@folders );
@$folders = reverse @$folders if $sort_order eq 'descend';

こうすりゃいいってことですね。　うまくいきました。

現在進行中の案件では、コミュニティ・ソリューションをベースに構築を行なってます。

ユーザーに対してカスタムフィールドで情報を追加してやって、それを記事一覧や、コメント一覧で表示しようと思っても、実はそれを行うブロックタグはMTには存在しません。

ユーザーコンテクストを生成するプラグイン

ブログ記事の投稿ユーザーに関するMTMLタグは「<$MTEntryAuthor$>」「<$MTEntryAuthorDisplayName$>」「<$MTEntryAuthorEmail$>」「<$MTEntryAuthorID$>」「<$MTEntryAuthorLink$>」「<$MTEntryAuthorNickName$>」「<$MTEntryAuthorURL$>」「<$MTEntryAuthorUsername$>」「<$MTEntryAuthorUserpic$>」「<MTEntryAuthorUserpicAsset>」「<$MTEntryAuthorUserpicURL$>」です。沢山あるのに大半はファンクションタグであり、ブロックタグとして登録ユーザーのコンテクストを生成するタグは存在しません。
「Movable Typeでブログ記事投稿ユーザーの情報を取得するEntryAuthorDataプラグイン: 小粋空間」を使うことで、ブログ記事投稿ユーザーのコンテクストが生成できます。

記事内には、MTタグで投稿ユーザーのコンテクストを生成する方法として、以下が書いてありますが、コレは必ずしもうまくいかないのではと思います。

<mt:Entries>
 <$mt:EntryAuthorDisplayName setvar="name"$>
 <mt:Authors display_name="$name">
  <$mt:AuthorBasename$>
 </mt:Authors>
</mt:Entries>

[Movable Typeでブログ記事投稿ユーザーの情報を取得するEntryAuthorDataプラグイン: 小粋空間:(2012年4月22日 18:56:31 引用)]

コレが成り立つためには、EntryAuthorDisplayNameがNULLを許容せずに、かつuniqueである必要があるものと思いますが、同一の表示名を登録可能なようですし、説明文にもあるように入力しないことも可能なようです。

セキュリティ上の理由により、ユーザー設定で表示名の設定が無い場合、何も表示されません。

[MTEntryAuthorDisplayName | テンプレートタグリファレンス:(2012年4月22日 19:19:00 引用)]

さてコメント投稿ユーザーのコンテクストは以下のプラグインで取得できます。
「Comment Author Context | MovableType.org - Home of the MT Community」

入手元が「plugins.movabletype.org」だけなので、そのうち入手できなくなるかも知れませんね。

また詳細は不明（詳しい追跡調査を行なっていませんが）なのですが、どうもこのプラグインを入れると、パスワードの変更に影響が出るようですし、「ユーザー」メニューを開く操作もおかしな動きになってしまうようです。特に後の方は、MT5.1への対応の問題ではないでしょうか。（最終的には後述の方法を使いプラグインは使用しなくなりました。）

ダイナミックパブリッシングでうまくいかない

さて、とりあえず、プラグインで処理する方向で進めていたのですが、途中でアーカイブの分割処理（DynamicMTMLによるアーカイブのページ分割・これは後日別エントリーにします）や、コメント欄でのログイン中のカレントユーザーの表示部分など、幾つかダイナミックパブリッシングで処理する箇所が出てきて、上記プラグインで対応できない部分があることが発覚しました。

まぁ、ダイナミックパブリッシングプラグインを書くという選択肢もあるわけですが、もう一度標準のMTタグだけで同じ処理ができないか考えてみました。
ユーザーのコンテクストはやはり、MTAuthorsを使って出力する以外なさそうです。
またMTAuthorsには残念ながら、特定のユーザーを指定するのにid指定を行うなどは出来ないようで、display_name指定で読む以外の方法はなさそうでした。
会社のエンジニアから指摘されましたが、MTAuthorsにはアンドキュメンテッドなモディファイアとしてidが指定できるっぽいです。確かに動作しました。だとしたら、EntryAuthorIDで取得したユーザーIDを使って、直接MTAuhorsでユーザーのコンテクストになりますね。
という訳で、MTAuthorsでdispaly_name（＋追加指定）を指定し、ユーザー候補を読み込んだ後で、ユーザーのID（ブログ記事投稿者のIDやコメント投稿者のIDを取得するタグは存在する）により、対象ユーザーを確定する方法を取ることにしました。まぁ今回の案件では表示名の設定が必須になるように、登録画面に制限を加えていることもあり、display_nameである程度の絞り込みが出来るわけですが、これを指定しない状態で1000ユーザーや10000ユーザーを対象とした場合に、実用に耐えられるかはチョット問題ありそうですね。やはり最初のブロックタグである程度件数が絞り込めてないと、スケールアップしていった時に対応できなくなりそうです。（そういや、このモディファイア「display_name=""」とした場合は表示名を設定していないユーザーのみの絞込みになるんだろうか？）

<MTEntryAuthorID setvar="author_id">
<MTEntryAuthorDisplayName setvar="display_name">
<MTAuthors need_entry="1" display_name="$display_name">
 <MTIf tag="AuthorID" eq="$author_id">
  <$mt:AuthorBasename$>
 </MTIf>
</MTAuthors>

こんな感じでどうにかなるのではないかと。
投稿された記事を表示するコンテクスト内で使用するものなので、少しでも対象を絞り込めるように「need_entry="1"」も指定してあります。その他ロールなど特定の条件が存在するならそれも追加したほうがよさそうですね。ここは、いかにMTAuthorsブロック内のループ回数を減らすかが、安定運用のキモになってくるはずです。

<MTCommenterID setvar="commnter_id">
<MTCommentAuthor setvar="commenter_name">
<MTAuthors display_name="$commenter_name" need_entry="0" any_type="1">
 <MTIf tag="AuthorID" eq="$commnter_id">
  <$mt:AuthorBasename$>
 </MTIf>
</MTAuthors>

コメントの方も同じくこんな感じで処理できると思います。ただ、まだるっこしいですね。

MT5.2への要望

という訳で、MT5.2への要望です。
上記のように、実は基本的なMTタグで欠けているものがあります。MT5.1でのMTEntryPrimaryCategoryの様に、コレを待ち望んでいたんだというのが多々あるはずです。
ぜひ、ブログ記事の投稿ユーザーのコンテクストを生成する、MTEntryAuthorContextタグと、同じくコメントの投稿ユーザーコンテクストを生成する、MTCommnetUserContextの、MT本体への実装をご検討ください。