Go here: http://www.joegrossberg.com/mt-search.cgi?...Blogs=2&search=

Then search for "foobar", a term that will return no results. You will get the following error:

MT::App::Search=HASH(0x8105494) Use of uninitialized value in pattern match (m//) at lib/MT/Template/Context.pm line 437.

Am I missing something from my template? (I haven't modified the Perl files, and I noticed this on MT 2.63 and then 2.64. Plus, it seems to work fine on others' sites)

Has anyone else seen this?

I have same results on

http://frtorres.virtualave.net/cgi-bin/mt-search.cgi

when you try to look for non existing strings not on main weblog screen. ie when you repeat searches.

Hi!

Same at my site. Do you run your Blog on a Windows machine? That might be the difference...?

regards,
Kai

First question: do you have any blogs in your MT installation that have not been assigned a Local Site URL?

Reason for question: "if there are no search results, Movable Type will simply try to load a weblog from your database (the determination of the weblog that is chosen is undefined)." So you get some funky behavior when there are no search results.

Second question: are you planning to use the default search template for all blogs on your installation, or will each blog have its own (with Alternate Templates)?

Reason for question: you may need to add the IncludeBlogs input statement to your default search template:

CODE

<input type="hidden" name="IncludeBlogs" value="<$MTBlogID$>" />

replacing <$MTBlogID$> with the ID of the blog you'll be using the search template for. That should eliminate the error (since you likely have a Local Site URL set up for that blog, and MT will restrict its "no results" behavior to only that blog).

If you're using Alternate Templates, you'll want to specify the blog ID in each of them with that IncludeBlogs statement.

girlie:

I did indeed need to add that line to /search_templates/default.tmpl

Thanks so much for your help! You rule!

Joe

P.S. Why isn't that IncludeBlogs hidden field there by default?

Because the default template is intended for use in searching all blogs in your installation, so including only one by default probably would be more confusing to users (when they don't get the results they want).

I find that default behavior to be counter-intuitive, and (frankly) completely wrong-headed. I'm glad I encountered this "Use of uninitialized value in pattern match" bug before any of my visitors (to my knowledge) discovered the "feature" underlying it.

I consider it counter-intuitive because when a visitor uses the "search" function on a blog, she is going to expect it to search that blog, not every blog maintained by that copy of the content management software behind it. Seeing results from other blogs is usually going to be puzzling to the visitor. As a blogger, I would not expect it to work that way either, unless I'd chosen an option to specifically enable it.

I consider the default behavior "wrong-headed" based on my system-management background. I have blogs by more than one person in my installation, and we do not want our entries showing up in each other's searches. In particular, one of these blogs is a private one, which the blogger does not want available to the public at all; including his articles in searches of someone else's public blog is a violation of privacy (and I thank the gods that I found out about this "feature" before he or anyone else did). Having the cross-blog searching available as a operator-enabled feature is fine (I understand that some people design their sites around multiple public blogs and welcome that option), but it should not be the default behavior. A sound security model is one in which universal access is disabled by default, but can be enabled if wanted; this is the reverse of that, which violates "best practise" principles.

I agree that the default search template should be limitted to one blog, but I wouldn't bee all that hard on MT.

The software is/was supposed to be a personal blogging software. One blogger installs it and manages his/her blog(s) with it, and may have other authors contribute to the blog(s).

Some people install MT as a multi-user system where multiple people manage their own blogs (yes, I do that too). Sure it works, but it is rather insecure (you better know and trust the other bloggers or they could seriously hack your system). In this situation the search-across-multiple-blogs "feature" is potentially the least of your worries...

Having said that, I reiterate that I agree with you on the default behavior and that's why I never use the default search template as is.

I can - and do - trust the users of my MT installation not to f*** with it or each other. Heck, we all have read-level access to the private blog I referred to, and - if not for this backdoor - it's been quite well secured, if I may say so myself. It's the other 6 gigapeople out there that I'm concerned about.

But the multi-user aspect is really beside the point. The issue would be the same if I were the only user and the private blog were my own. That's an arrangement I suspect is fairly common, and one in which people would expect a reasonable level of privacy. But a search-results page that subsequently searches the contents of other blogs compromises MT's otherwise-adequate security. There's a patch for this exploit, but evidently it's up to the user to discover that the problem exists, and to apply the fix manually. I don't expect MT to be as rigorous about security as OpenBSD, but I'd rather it didn't instead emulate Microsoft.

Though I initially said the default search template was intended to search across all blogs in an installation, upon further reflection, I see it a little differently now.

I think the default template corresponds to the basic installation premise of a single user with a single blog; and the ability to use Alternate Search Templates supports MT's Multiple Blog feature.

And note that until MT added the NoOverride option to mt.cfg, all someone had to do was pass a new blog ID in a search URL to get a peek at other blogs (in fact, I discovered this about my own private blog and begged Ben for help in stopping it, so I like to think I had something to do with that option's existence ). So I think they're very quick to respond to security and privacy concerns.

But overall, for a free piece of software, I don't think it's inappropriate to expect users to do a little work on their own to get the results that they want.

And gee, posting something online that you'd rather keep private is pretty counter-intuitive if you ask me.

Well your premise is flawed, girlie, because MT installs "right out of box" loaded with multi-user, multi-blog features, all enabled and readily accessible in the management interface. "Create New Weblog" and "Add/Edit Weblog Authors" are the first two buttons on the main menu. These blog-specific search templates, by contrast, exist only in the abstract, as instructions in the help file for how to go behind the interface and hack the mt.cfg file to add that functionality. As far as I can tell, (nearly?) every other page that's presented to the visitor can be readily custom-coded on a per-blog basis, all without popping the hood. This one page is a step behind the rest of the system in that regard; despite some ductwork that's apparently been laid to allow otherwise, it still operates as you say: in single-user, single-blog mode.
That's good to know. So I trust they'll fix this bug now, rather than trying to justify it as a "feature" as you tried to do earlier.

I didn't come here to cast blame, or anything of that sort. I came here to report a bug, and to emphasise why I think it's an important bug to fix. I'm a developer, so I know as well as anyone that it's impossible to think ahead to every contingency, that things get overlooked, and that some things simply never occur to you (especially in the more obscure corners of a system such as this). And no programmer has time to go looking for things to fix; she needs to hear from the users to find the problems. To be blunt, I don't care why this bug exists, so your string of possible explanations for it is missing the point. I just want the developers to understand why I think it's in error and should be changed.
I agree wholeheartedly. I've spent countless hours over the past several weeks doing just that, and you haven't heard a peep of complaint from me over it. (Heck, it's been fun!) So I don't think it's at all unreasonable to suggest that if (for example) someone wants their search form to dig through all of the blogs on their server, that they should be expected to edit the template to activate that capability. This isn't a question of which system behavior is "right", because it depends (as you say) on the results you want. It's a question of which should be the default behavior. I'm arguing that the more secure (and, I think, least surprising) of the two should be. Is that really so unreasonable?
Maybe it's time to adjust your intuition. There's a wealth of material online that is (to varying degrees) private and confidential, and kept that way. Why do you think so many people spend their time trying to crack other people's security? The private blog I was talking about is protected with as much security as the author and I deemed appropriate. It's secured at the web-server level with password security, and with a layer of obfuscatory obscurity in front of that. That is, to access it, you'd first need to know that it exists, then figure out where, then work out a method to crack the security. Or - thanks to this wee bug - you might just happen to click on a button on the "search results" page of one of our public blogs, and find it by accident!! If I discovered a security flaw in Perl or Apache or Linux or Coyote firewall, I'd notify their developers. I'm just doing the same here for MT.

And this isn't only a privacy issue. One of my blogs is a professional one, with content appropriate for that audience. Another (on a different domain name) is more personal, with content quite inappropriate for the other site, and I would not want articles from the latter appearing in searches on the former.

The bottom line is that there are a number of reasons why the current default behavior is problematic (e.g. operating contrary to the "least surprise" principle, including a remote privacy exploit in the default installation). I see no reasons why it should remain the default. I'm suggesting that it be changed.

It doesn't sound to me like you're merely "suggesting" anything - your posts here have a very attacking tone (calling people "wrong-headed" isn't very palatable to their ears), and I'm certainly not going to waste my time debating someone who is intent on shoving their "suggestions" down my throat.

I apologise for my tone. I'm just frustrated that the only apparent response to several reports of this bug has been for you to 1) explain how to fix it ourselves (which is good), 2) think up assorted excuses for it (which is... pointless), and 3) nothing else. It's a known issue (as you've demonstrated), it has a trivial solution (ditto), and yet... you seem to be arguing against applying this to MT proper. Can you see why this might be aggravating?

Others before me had asked politely about getting this fixed. That resulted in only a lame justification (which you've since abandoned) that claimed it was a feature. I tried being assertive instead, providing actual arguments (which you've now said you won't even consider, to punish me). Maybe if you acted more like you were listening (rather than "listening"), I wouldn't feel a need to resort to "suggesting".