MT5: Mutliblog, MT:Websites, blog_ids, include_blogs: new attributes and modifiers

You say that as if you just got some illicit drugs or something ;)

Anyways good find, and clears up how I would structure my site if I were to move to mt5. Thanks,

Ken

That was deliberate because that's exactly what it felt like! Sidle into FogBugz, snoop around a search, slink into a post, sneak down the message body and do a quick grab-and-run.

All very furtive, cloak-and-dagger stuff.

Actually, I'm pretty disgruntled.

<MTWebsites> and the modifiers/attributes for <MTMultiblog> are pretty critical to the entire MT5 paradigm. Developing something that is such a huge conceptual shift, how difficult could it have been to grab a pencil and paper and make a note of this new stuff and just stick it onto the documentation page? What's the point in keeping it hidden?

This like releasing a brand new car without the ignition key.

I agree. I am putting together my thoughts on MT5 for a post on my blog. The Website Object and the parent/child/sibling syntax is a game changer.

Here is a big issue for me upgrading. Since upgraded installs put each blog into its own website, wouldn't it have been a good idea to offer some "blog mover" functionality?

Yes, "blog mover" functionality would be awesome, and seems like it should be pretty straight forward.

WEBSITES VS BLOGS

Some discussion on FogBugz, the gist of which seems to be this:

1. One view is that users should be given the choice of using MT5 to run a simple blog (Vanilla, for our purposes);
and
2. The view that succeeded was that from MT5 onwards, any "blog" must be subordinate to a "website"

So question: how do you get the two to unite, so your blog/website both have the same paths and, effectively, you get a simple blog?

Simple answer seems to be set up a website with no publishing paths, and set the subordinate blog's publishing paths to the root. Voilà, it works.

MIGRATION

Migration actually happens during an upgrade, when existing blogs are "moved" into something called a "current website" (or some such), which has no publishing paths of its own.

I do not know if it's possible to migrate an entire blog in and out of a website. Theoretically, there should be no issue.

PAGES V ENTRIES; FOLDERS V CATEGORIES

Incidentally Ken, I have to say I love the logic and structural neatness of MT5. Till now we had a bunch of blogs and then ran around figuring out ways to cobble them together to make a website. That was hardly the most efficient approach. MT5 clears a lot of the air especially as regards the (hitherto, non-) difference between entries and pages, and now gives that difference a real distinction.

Simply put, pages link to folders; entries to categories. Physically, there's no difference. Categories generate as folders on the server, too, just like folders. Entries generate as html or php files, just like pages. So what's the difference?

Entries are fundamentally date-based and follow a chronological order; pages are not. That's all.

I find date-based stuff idiotic, unless you're reading someone's journal which, AFAIK, nobody who hasn't hours to waste does.

In MT5, websites can only create pages, never entries. Think "About Us"; "Contact"; etc. Stuff that doesn't need to be updated. Blogs are large containers of stuff that gets updated regularly (entries), which may be in categories if you like or totally disordered. Blogs can also have pages.

All that the website does, or is supposed to do, is to drag in the entries from the subordinate blogs.

Which is why this documentation is so critical. There we go, squaring the circle.

It's great that websites and blogs have been distinguished, but there does not seem to be a way to access widget sets, template modules, assets, etc created in an associated blog(s) via the websites "Design" tab. I.e. if I want to include a module from the main website in my blogs, or vise versa, I have to recreate that module and assets for each and every blog. Unless I am missing something.

Nope, you're right. Inheritance is a big issue. I've worked around that for now by linking templates, including widget templates, to files. That way I only have to set the paths to the files slightly differently in the blogs, but don't have to recreate them from scratch.

For instance, let's say I have a widget called "MyWidget". I link it in the website to templates/mywidget.txt

The website is located at the root.

BlogA is at root/bloga/

So in BlogA, I also have MyWidget, but link it to something like ../templates/mywidget.txt ... basically up one level, then down into templates and to the file.

Agreed, this does not fully address your question, but it's the best I can do for now.