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.
- Search:
- 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.
- “Future-proofing“:
- 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.
- CategoryHeaderFooter:
- 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
Hi there…
I have a question with this statement:
I’m currently trying to future-proof my Blog as well, but I would like to create TB URLs that do NOT use Entry ID #’s — these change if entries are Imported into a new database that does not start on the same ID # as the old Blog DB. (Or am I missing something?)
Doesn’t <$MTEntryID$> refer to the DB ID? Wouldn’t this work better if it could reference the future-proofed URL?
I guess I am confused about how using the Entry ID will be future-proof. Could you spare a second to explain it to me?
Thank you!
ok, that is a good question.
It’s confusing because the EntryID is, as you point out, inherently NOT future-proof. If the entries are moved to a non MT database, or made static, they will not retain their entry number.
So why would I deliberately replace the future-unsound link with another future-unsound link which is nearly identical to the original?
The reason is, the trackback link is not a link which needs to be future-proof, because it is not recorded anywhere. It is only used in that single “trackback” transaction, where you are writing a new entry that refers to my entry.
If you make a trackback to my blog, you will notice that nowhere does that trackback URL appear on your blog or in your database. Once you use that URL, the one with the mt-tb.cgi in it, the URL never appears ever again. Likewise, my system doesn’t remember the trackback URL either; it only knows the URL of your new entry, which you sent to that CGI URL using whatever blogging mechanism you use to make new entries.
What your trackback “ping” is doing is using that URL just the once, to send my blog the URL of your entry which refers to my article. The URL of your entry, in turn, is not related to TrackBack at all.
It’s exactly as if you took the URL of the new entry on your blog and mailed it to me, and then I manually placed that URL in my blog. Well, except that when you write a new entry, you don’t know the URL in advance, but you get the picture.
When you make the other changes to the URLs of your archived entries as I detailed above, the URL sent to my trackback CGI will be that new, future-proofed URL.
Ok that was a little needlessly detailed, but I think I answered your question… I am extremely caffeinated this morning.