杀死'nav-commenters.gif'

Movable Type 3.0 and later contain a feature with a curious implementation — a tiny little thing that’s been irritating me (and others) 自从。

What happens is that each time you rebuild any of your weblogs, MT creates a file named “nav-commenters.gif” at the root level of the weblog例如,如果您的博客位于http://example.com/, MT will create this file athttp://example.com/nav-commenters.gif

这是一个小小的文件 - 22×15像素,仅为91字节It looks like this:MT的nav-commenters.gif图标。

MT uses this file as an icon to indicate which comments were written by users who authenticated via Six Apart’sTypeKeyservice. If you see this icon next to the name of a commenter, you can click it to see that user’s TypeKey profile.

What’s so curious/irritating about it is that (a) the file is created at the root level of every single weblog in your MT installation; (b) it’s created whether you use TypeKey or not, and whether you甚至是否显示评论; and (c) if you delete it by hand, MT will keep re-creating it.

The presence of “nav-commenters.gif” is in fact a half-decent way to tell whether a given site is powered by Movable Type 3.0 or later. E.g., each of the weblogs that constitute the different sections of the new Six Apart web site has its own copy:

(但奇怪的是,不是http://www.sixapart.com/livejournal/nav-commenters.gif。)

MT在没有其他此类图像的情况下乱丢您的网络空间Just “nav-commenters.gif”In the grand scheme of things, this is, obviously, not a big dealBut to me, it was maddening, like a sliver of popcorn caught in my teeth.

所以,我用插件修复了它。

更新:2005年4月26日

Movable Type 3.16 obviates the need for this plug-in, supplying its own built-in means of suppressing the creation of the “nav-commenters.gif” fileIf you’re already using my plug-in, you can remove itTo use MT’s new built-in suppression, add the following line to your “mt.cfg” file:

PublishCommenterIcon 0

下载和安装

下载:Kill-nav-commenters-gif.zip(2 KB) - 2005年2月28日

  1. Copy the “Kill-nav-commenters-gif.pl” file into your Movable Type “plugins” folderThe “plugins” folder should be in the same directory as “mt.cgi”; if the “plugins” directory doesn’t already exist, use your FTP program to create itYour installation should look like this:

    (mt home)/plugins/Kill-nav-commenters-gif.pl
  2. 重建您的每个博客。

而已Uninstallation is just as easy: remove “Kill-nav-commenters-gif.pl” from your “plugins” folder, then rebuild.

这个怎么运作

Part of what’s so maddening about MT’s “let’s keep generating copies of ‘nav-commenters.gif’” behavior is that this filealready exists, in the static images directory of the Movable Type application itselfThat’s the folder where you can find all the images that constitute the MT web app user interface. “nav-commenters.gif” is in fact one of the icons in the MT web app interface:

MT web UI中使用的'nav-commenters.gif'

Hence the name of the fileThe icon for the entries button is “nav-entries.gif”; for categories, “nav-categories.gif”, etcSo my guess is that when Six Apart was developing the TypeKey integration for MT 3.0, they decided to re-use the “nav-commenters.gif” icon rather than create a new one到现在为止还挺好。

The problem is that Movable Type has no built-in means of linking to an item in your static “images” folder, which is where the existing copy of “nav-commenters.gif” livesThis folder was meant to contain images used by the MT web application, not for images referenced by the weblogs it publishesIn fact, the default templates for MT don’t use any images; their designs consist entirely of XHTML and CSSThere is no default “images” folder for the weblogs published by Movable Type.

Hence the decision to recreate a copy of this folder in the root public folder of each and every weblogThis way, MT can always generate a link to “nav-commenters.gif” using:

<img src =“/ nav-commenters.gif”......

Kill-nav-commenters-gif.pl patches two of MT’s built-in routines. First, it patchesMT ::重建, which is the routine that generates the copies of nav-commenters.gifTechnically, this plug-in doesn’t suppress MT’s creation/re-creation of “nav-commenters.gif”, but rather, each time MT creates it, the plug-in deletes itThis way the plug-in doesn’t need to更换the built-in MT routine, but rather just supplement it.

其次,它重新定义了<$ MTCommentAuthorIdentity $>template tag. (This tag is used in MT 3.0’s default templates, but as far as I can tell它没有记录在MT用户手册中.) The handler for this tag is where MT makes the assumption that “nav-commenters.gif” is located at the root level of every weblog.

Again, instead of re-implementing MT’s internal handler, we call the original, then look in the output for an<IMG>标签的SRCattribute contains “/nav-commenters.gif”; if we find it, we substitute a reference to the copy of “nav-commenters.gif” in your static images folderBuilding a reference to this folder is the ever-so-vaguely tricky part.

插件与修补MT的来源

Ever since MT 1.x, I’ve been wary of any advice that instructs one to modify MT’s source codeOnce you start down that path, you end up needing to re-apply all such patches一切time you upgrade Movable TypeUsing plug-ins is a much cleaner way to hack MT’s internalsThis way, instead of modifying MT’s source code, you’re simply modifying MT’s behaviorThe benefits to patching via plug-ins rather than directly modifying MT’s source are thus:

  • You should be able to upgrade to future version of MT as usual, by simply replacing the old version of MT’s source with the new versionThere’s no need to re-apply your patches with each revision.

  • 如果要卸载修补程序,只需删除插件即可。

谢谢

谢谢你布拉德乔特Erik Barzeski,和本哈默斯利用于测试此插件(以及像往常一样,用于改进代码本身的建议。)

以前: 火线歇斯底里
下一个: 神经接触