Couple of nits that I would have probably noticed, if I was stealing it for my own use: hello.pm’s missing the “sub ” before init, and the tmpl doesn’t need the end tags for body and html, since footer.tmpl already closes them.

Also, depending on your app, you might want to add script_url => MT::ConfigMgr->instance->AdminScript to %param in hello.pm, so that the “Main menu” and “Logout” links in the header go to mt.cgi, instead of mt-hello.cgi. Since you’re an MT::App, you can certainly handle them, but it looks weird when hours later you are posting an entry through mt-hello.cgi.

As for the script_url, I went back to Notifier to see how Chad did it, and saw that he defined a sub uri that does the same thing. It has the advantage that it gets picked by anything else we might add to &app->add_methods. Now that I know what it’s for, I’ll put it back in.

However, in at least one case, you’ll actually want to use your script name instead. Otherwise it will end up calling mt.cgi, which isn’t what you want.

This case occurs when you have not yet logged into your MT install and want to go directly to mt-hello.cgi. When that is the case, you’ll notice that the redirect info will send you back to mt.cgi, which means you’ll need to select your script again. Having logged in, it should work that time. But it’s an extra step, and oh how I hate extra steps.

For this particular plugin, it may not matter. For MT-Notifier, I like to be able to go straight there, instead of having to go back to the menu and select to go to MT-Notifier again – I already told it that!

Here’s that code (contents of sub uri):

$[0]->path . ($[0]->{author} ? MT::ConfigMgr->instance->AdminScript : $_[0]->script);

To get around this particular case, I use a condition in that statement. Specifically, I checked to see if the author is set. If it is, it means someone is logged in. In that case, use the AdminScript. If it is not set, then someone is not logged in, which means I’d actually want to use my script for the redirect. Hope that makes sense to everyone.

Also, I believe config_link => ‘../mt-hello.cgi’ in hello.pl will cause the config link to appear as “http://yoursite/mt/plugins/../mt-hello.cgi”, which ought not to work for most web servers. (If it does work, it’s a security hazard, because then people can reach around your filesystem for files.) Because of this limitation, MT 3.01 requires that CGIs be under the plugins/ directory somewhere, which means hard-coding a relative path to the MT root directory (which means the plugins/ directory must be in the MT app root, which I consider undesirable).

That said, the idea of putting all plugin files, be they CGIs, libraries, or whatever, under plugins/ is appealing to me, as opposed to plastering files all over the MT directory structure. Make the plugin author work to find the files he needs, not the poor end-user!

As for putting everything in the plugins directory, my point is that nothing should be in a web servable directory that isn’t intended to be served. Without special configuration, most web hosting installations would serve *.pl files as if they were text files, and exposing their contents is a potential security risk. A site admin who knew what they were doing could explicitly configure their web server to prevent plugin source files from being served, but for most users, we have to assume they won’t or can’t take such precautions. Most people won’t know that these files are servable, and not knowing could lead to problems. I can imagine a developer building a site with custom plugins that access a database, with the database login and password embedded in the *.pl file. In general, it’s just an unnecessary security burden that the admin needs to keep track of, and I believe it could be avoided.

The same could be said about mt.cfg, but I’m willing to concede that because it will always be just the one file, the instructions to secure it are in the MT installation instructions, and most alternatives would be complicated and platform specific. For my site, I also lock out the template directories, lib, extlib, and anything else that I don’t explicitly want dished up by the server.

I agree that it’s appealing to package and distribute plugins with instructions that just say, “Put all this in the plugins directory.” (And similarly as an admin, so plugin files are scattered everywhere.) I just want the option for admins to be able to move the not-to-be-served stuff, so as an admin I have the choice, and as a plugin developer I don’t have to worry about it.

My apologies for getting off topic. Thanks for the hello-world MT::App, this will be useful to many.

instead of if ($0 =~ m!(.*[/])!) {

should be \n\n …

PapaScott » Hello World as an MT::App CGI…