Apparently nTag is like a badge for expo attendees, crossed with one of those radio tags you stick to bear’s ears in the wild. It tracks the attendees and records which kiosks they were interested in. So in this story a guy named Whit Diffie hacked his nTag to tell everyone else’s to go to sleep.
I’m completing the “future-proofing” of MT individual archives. This involves using the Regex plugin, but also potentially modifying the “trackback” and “comments” portions of MT- I have to change these in a way which doesn’t break all the other blogs on the system.It must be possible to implement these changes in a way such that:
- doesn’t generate too much per-blog manual work for new blogs- blogs using the default setup should not have to deal with my insanity
- affects other existing blogs as little as possible
- when possible, separates the server address (the machine hosting MT) from the individual blog (zeromachine) – there should be no references to the server machine in the blog. This is to hide implementation as well as making the blog easier to move to alternate servers.
- The Search library included with Movable Type actually does have logic in it which looks for user-specified blogs in which to search… but they don’t include that flag in the generated search page returned by the search! So if you do more than one search, suddenly you will be searching in every blog on the system….
- The form field in question is “IncludeBlogs”
- I was about to go buck-wild and have the script remember the value of the previous search… but it’s easier (and more sensible) to change the default template so that searches automatically search only the blog you are on at the beginning of the search. Like, I can’t think of an example of why I would want to enable searching every blog on our server, since they all belong to different people. Obnoxiously, this is an intentional feature with a simple solution: add the hidden “IncludeBlogs” element to the default search template!
- Still a problem- the CGI location is still the general one, listing the server’s name, which does not match the blog’s domain name. To solve this problem originally, shac and I set our scripts to name the root apache cgi-bin directory, so our cgi location was /cgi-bin/mt … but I wonder if it wouldn’t be better to alias the MT directory inside that one to our “cgi-bin”s in the Apache httpd.conf so we could just use it as if it’s at cgi-bin. Then we could change the default search template (action is previously <$MTCGIPath$><$MTSearchScript$>) to name “/cgi-bin/search” etc and wouldn’t have to worry about changing it for every blog in the future. Okay, I’ll do that.
- actually no I won’t- I’ll just set it to the empty string, “”. That is because the template is always returned by the search cgi URL, and so sending the new result to the same location will be to the same executable.
- This is a problem also for Comments because of the “Preview” button- MT returns a page from the base level general to all the blogs on the installation. Fortunately, unlike the search page, the comments pages are modifyable on a per-blog level.
- Installing the Regex into the templates- pretty easy.
- Tweaking the comments- not so easy, and it does (temporarily) break everyone’s comment links- if someone saved a link to a particular comment on a particular page, it will no longer work. I am not worrying about this on mine because I’m breaking their links anyway (the locations of all the individual archives have changed!), but it will break other people’s comment links on their non-future-proof blogs.. However, judging from the access logs not many people are looking at the blogs on our system, let alone the comments, so not a big. This will resolve itself when everyone does a rebuild. I changed Comments.pm.
- Wait a second… No one on this system is even USING comment permalinks. Gah why am I doing this? Ah whatever, I’ll put it in anyway.
- the future-proofing guy points out that it is not necessary to change instances of MTEntryPermalink because they will just have the index.html in them and that will still work. However, I did it anyway, because I am mental like that.
- Trackbacks- once the trackbacks are registered on the foreign system, they use the permalink- so the 5 or so trackbacks I got already will be broken. Ah well…
- Trackback sends a URL to the foreign blog being pinged. That URL is the permanent URL of the new posting, on the local blog. Now that we have
taken such pains to future-proof this URL, we may as well make sure it is accurate! The modified code is in Entry.pm and does two things:
- strips out the “index.html” from the permalink, if it’s there (this is important because as I mentioned we don’t want to mess up anyone else’s unaltered blog)
- makes long-ass named anchors in permanent entries in multi-entry archives, such as Monthly or Category archives. Again, people aren’t yet using these anchors as links, so we should be ok still.
Even if these break, it’s just the “#” part of the URL and the same page will still appear, so it’s not a big deal.
- while we’re separating the blog from its host server name, we have to change the template for the Trackback popup.
It by default uses “<MTEntryTrackbackLink>” which is a global variable and will contain the name of the server, like “http://servername/cgi-bin/mt/mt-tb.cgi/673”.
So I’m changing this to “<$MTBlogURL$>cgi-bin/mt-tb.cgi/<$MTEntryID$>” which is a direct link to the trackback for this blog.
- line 40 was totally wrong, naming a nonexistent variable $header rather than its actual name, $headerData
- error messages for header/footer macro definitions are returned by the subroutines, but then they show up in the page.
So I guess you are intended to put the defs within a comment block in the template’s HTML… to make this easier I had them print out inside their own comment blocks