The rebuild box should use checkboxes instead of the dropdown box to let you select the extent of a rebuild.

The selected boxes would carry over from reuild to rebuild until changed.

I think that would be a much better -- faster, more meaningful -- interface than the current one, and would save a lot of clicking. The current box is already big enough for that.

I'm doing lots of quick rebuilds and want to do only the indexes. It really should be able to remember that, and not make me select it every time. Rebuilds are frustrating enuf as it is.

If you're only rebuilding indexes, then select them from the listing(where there are already checkboxes), and use the Rebuild Templates option in the dropdown above and to the right.

Honestly, having the pop-up remember what you did last time seems a bit silly and should be reserved for a plugin at best. There's absolutely no guarantee or even reasonable likelihood that the next rebuild you do is going to be for the same things as previous.

Thanks, but I'm not sure what makes it "silly." The last who-knows-how-many rebuilds I've done were ALL index only. The "reasonable likelihood" is that the next who-knows-how-many will be too.

I'm developing linked index templates in Dreamweaver, which I upload to the folder specified in the template's linked file field. The only thing I'm actually using the MT interface for is rebuilding those templates after uploading them from DW. So the only part of MT I need for this is the Rebuild window (which I typically keep opened in the browser's sidebar, adjacent to the rendered page, so it doesn't get lost behind other windows.)

Rebuild's default is Rebuild All Files. Would be nice to not have to keep selecting the same option over and over. Doesn't seem too "silly" to me to want to save repetitive mouse-grab-n-clicks.

I imagine (though I don't know for sure) that user preferences such as this could be handled rather easily with a cookie, rather than a full fledged plugin.

In the meantime, does anyone know if there's a way to change the default to Rebuild Indexes Only, by changing one of MT's interface template files?

Thanks.

"Edit" tmpl/rebuild_confirm.tmpl and put your changed copy in the alt-tmpl directory.

Don't read too much into the plugin suggestion. This same effect can be managed with a transformer plugin, which was my point, and it would be trivial to create a transformer that resulted in your cookie idea. "Full-fledged plugin" != application.

Cool!

Thanks for the pointer to the Rebuild template!

While I can see how a plugin that remembered the setting would be helpful, my first thought is that maybe you're going down the wrong road--at least if you're doing what I think you're doing: designing your site, and need to rebuild to see what those changes yielded? Personally, I just put together the HTML/CSS to build the pages and use dummy copy as placeholders. Working locally and refreshing saves any rebuilding at all. Once I've got it right, I'll strip the dummy copy and add MT's tags and logic. ...If that helps.

"silly?" You're (rudely) making a gratuitous assumption -- I rebuild exactly the same way each time I update my blog. I think checkboxs would be a GREAT idea.

I don't want to waste my time fighting with some "geeky" poorly developed, undersupported "free" 3rd party plug -- these 3rd party plug-ins are sometimes dicey, at best, styleCatcher is a case in point, i.e., it was not compatible with any perl version except the most recent. What a shame -- it was a headache and waste of a lot of people's time...

Erm. StyleCatcher is a first-party plugin. Whatever its Perl requirements may be(though I don't think I see anything in its code suggesting they're different from MT's own) are a choice of the developers. Software has requirements; it's a fact of life. If you consider that "dicey," then there's nothing anyone can do to help you. If you don't like it, uninstall it. That rebuild pop-up hasn't changed in a long time; if this desired behavior were common enough, you'd think it might've happened sometime in the last five years due to requests. I guess not. Sounds perfect for a plugin to me.
Which is not to discount making the request now, either, but I don't think it's too likely to happen for the next release. Which brings us back to the primary practical option: plugin.

Incidentally, ifyou don't like plugins, you're going to be unpleasantly surprised by how the next version of MT works. You might want to do a little examination of that position.

Not sure that makes as much sense as it might seem to. We get used to and learn to live with workflow speedbumps in many, probably most, of the apps we use regularly. And update after update, they remain.

Also, by that reasoning, it would follow, for example, that the change (introduced some versions back) to the page where MTs templates are selected for editing, which placed the Index, Archive, System, and Modules lists each under its own tab, rather than being always visible in its own section on a single page, was the result of user requests. But I find it hard to imagine a substantial number of users would have requested that change, since it makes navigating the templates more cumbersome.

Seems more likely changes like that come from someone on the inside getting the idea that it would be a cool thing to do, and then convincing someone else to let them do it. But it really adds nothing to the experience of using the app.

Given how dynamic some of MT's interface pages are, I can easily imagine getting rid of the Rebuild popup window altogether, and allowing rebuilding (and the selection of rebuild specs) from whatever page you're on.

The separate Rebuild window really has little to recommend it. I find it always gets lost, which is why I open it, via a Firefox shortcut, in the browser's sidebar. Takes up more room that way, but at least it's always there. Much nicer workflow.

The QuickPost window is similar in some respects, popping up under the triggering browser, and even when the MT installation has only a single blog, it requires that you select it from a drop down. I doubt that will change anytime soon. It works. It's done. It's good enough. So we'll live with it. Ya know?




That’s usually what I try to do. But sometimes it helps to see the rendered tags, especially when I'm using MTIincludes and calling modules. And also to verify the tag values (e.g., sorting, lastn, etc.) are working as they should.

I must admit, this is the first time I have heard this feature request, but the logic seems straight forward enough. The challenge with this, speaking as the Product Manager, is that it really is hard to predict how "most" people will want to rebuild index templates the majority of the time. And in past experience, features like this invariably result in a user preference like "Remember my last rebuild options? yes/no" or something similar.

It is this preference, theoretically speaking that worries me. Features that are not desired by the majority of people, or that will not (in our eyes) benefit the majority of people are features I want to be very cautious in implementing.

You do make a good point about the chicken/egg paradox of a feature... some features most people won't ask for, because they don't know they need it!

It is my philosophy that features like this should be tested using a plugin (as a proof of concept) and if they plugin is popular, or demonstrates an innovative ideas, then fold it into the core of MT.

Granted: most people can't write a plugin. I wonder if you could join ProNet (http://www.sixapart.com/pronet/) and its mailing list and then send an email to pronet@sixapart.com (you have to be a member first) and see if you can't inspire a developer there to create this plugin for you?

[quote name='Su-' date='Apr 14 2007, 09:51 AM' post='250874']
[quote name='ChristopherNYC' post='250870' date='Apr 14 2007, 07:55 AM']
Incidentally, ifyou don't like plugins, you're going to be unpleasantly surprised by how the next version of MT works. You might want to do a little examination of that position.
[/quote]

Other CMS are looking better and better, then. Buggy, poorly designed, difficult to implement plug-ins have been the source of the majority of my MT headaches, lately. Can't get plugin manager to install or work right, can't get iconomatic to work right, can get amazon media manager to work right. Sux.

You're not talking about the same thing I am. Every single plugin you list is third-party, and whatever issues you're having are more to do with the plugins themselves than the fact that they are plugins.
What I was hinting at is that for a while now, work on the plugin system has been progressing to the point where they are pretty much indistinguishable from being an immediate part of the application, and if anyone's had doubts of it, the next version will be driving that point home.

On the other hand, yes, if a plugin is poorly-built that's a bad thing. But it's the plugin's fault, not MT's. The same is true of any system that allows plugins.

What's wrong with Icon-o-matic? If you're having trouble, I'd like to know about it. I do my best to write plugins that are not "buggy, poorly designed, difficult to implement," but I'll never be able to help you with it (or fix problems you're encountering) if you don't contact me.