What will we actually distribute?

[EdB]

I'm going to build a reasonably smart poll into this one after reviewing some discussions that have happened in the past.

The idea has been kicked around a couple of times to have more than one downloadable with each release. Exactly how many and what they're called and what they contain is where things ain't so obvious, and possibly the whole idea isn't obvious either. So here is my cut at things, then the polling.

I propose that we plan on 3 different packages when we actually create an official product zip.

• Just The Core: would not have any plugins or widgets or templates or localizations. This product must (of course) work. That means 2 things have to change: a blog with a category must be created upon installation, and files in the templates folder must be used to create the page.
• Core Plus Stuff: this is just like JTC but adds a good selection of plugins, widgets, templates, and translations.
• Stuff Plus Posts: this is just like CPS but adds sample users and blogs and blog posts and comments, which is kinda like what we have now.

Other models can exist but I'll leave it up to others to think of them and explain the merits ... or drawbacks to this model.

This doesn't add any burden on the development side because we simply keep working with what we have, and remove all the extras when it is time to zip something up. Well ... we do have to figure out how to easily remove the sample posts thing, which means it should sort of be like a plugin or something. I think the installer with samples takes 2 files? I dunno. All I know is that is the only part in my mind right now that needs more help than simply deleting prior to zipping.

[Yabs]

Ok, here's what I'm thinking about the zips.

It'd be nice to offer the users a totally customisable zip so they can pick and mix what they want. At the same time we should have some "presets"

"default.zip" - includes sample content, selection of (popular?) templates, selection of widgets, selection of plugins
"bare.zip" - just the core files and a single template ( so we can create a single blog on install )
"full.zip" - every (core supported) template, widget, plugin
"pick 'n' mix" - core files + users choice of plugins, widgets, templates from the list of core supported ones

We'd need to work on the installer so that all "shipped with zip" plugins, templates and widgets get automatically installed. Not sure how to handle that best yet

¥

[EdB]

We'd need to work on the installer so that all "shipped with zip" plugins, templates and widgets get automatically installed. Not sure how to handle that best yet

I'm guessing that would apply to the "pick n mix" package? (For the "full" since we know what it has up front we can code it up front.) Also, I'm guessing "pick n mix" would be a checkbox form that they do before they get their very own zip file dynamagically created? If so then maybe something that runs only after install that says "I will discover plugins and templates and install them because I am very smart" then leave widget layouts up to the new owner?

Not into making it use files in the absence of a template?

The idea of sample posts would be a bitch in "pick n mix", but not so bad in "full". I wonder if we can make sample posts be an option they select during installation of "full" that makes a server call to get the posts? I wonder if server to server can pass files for sample photoblog posts?

Is pick n mix v0 material?

PS: Any wonder why I added the "4 and I'll tell you why" option?

[davidryman]

"pick 'n' mix" - core files + users choice of plugins, widgets, templates from the list of core supported ones

From my POV, as an admin, I'd like to select non-core supported items also, assuming they are available. It might be a way of finding out what people want, without actually asking them. If a particular P/W/T is popular and non-core, then 'someone' might want to take it and make it core compliant thereby expanding the catalog.

[EdB]

From my POV, as an admin, I'd like to select non-core supported items also, assuming they are available. It might be a way of finding out what people want, without actually asking them. If a particular P/W/T is popular and non-core, then 'someone' might want to take it and make it core compliant thereby expanding the catalog.

It'd be more for experienced admins doing a new install - I THINK - because - I THINK - this goes to what sort of package you put together for a download. But same thing sort of.

Anyway that touches nicely on why we should only redistribute plugins and widgets and templates that meet our exacting criteria for coolness. Because I pretty much agree with you: if the BumbleBee plugin proves to be extremely popular and a large number of "custom packages" include it then we need to seriously consider making it part of the "here is a really good package" package. To do that means it gets into "the core" and autodocs, which means it is either where we want it to be OR we have to make it be there. Much better to start with "we like it" than make it fit our footprint eh?

I was just now thinking, which is always a mistake.

"default.zip" - includes sample content, selection of (popular?) templates, selection of widgets, selection of plugins
"bare.zip" - just the core files and a single template ( so we can create a single blog on install )
"full.zip" - every (core supported) template, widget, plugin
"pick 'n' mix" - core files + users choice of plugins, widgets, templates from the list of core supported ones

Suppose PNM was actually core with one tiny bit added that dynamagically included a checklist of soft stuff to possibly grab. Plugins and widgets came with a description, templates with a screenshot. DURING installation it asks the installer what bits they want and (of course) installs them. This way we don't have to build a special zip with everything, but we still have to be able to move files from server to server. Dunno. Just thinkin and typin.

[Yabs]

Ok, maybe I should clarify p'n'm a smidge (from my pov).

The eventual goal is to have core maintained plugins/templates/widgets, core approved p/t/w's and other p/t/w's.

When the user hits the download page for the core they'll be offered *all* of the supported/approved p/t/w's as options (checkboxes probably) and then they'll hit "download packacge. The zip will be autocreated to include whatever they chose (and cached, cos I like to save cpu n shit).

If (from stats) we see that plugin foo is often chosen as part of p'n'm then plugin foo will become part of the default.zip.

That's the hard way. The *real* ideal is that the installer is just a couple of files that know how to call home ( in a none-evo mannner ) and you get to chose on install which bits n bobs you want, the installer will then grab all the relevant bits (including core files) and auto "download" and unzip them onto the server and then install them. To make that a reality we'd need write ability for wherever the users "blog root" is and we'd some form of zip extension enabled for php. This is kinda where wp (and now evo) are headed with their auto-update stuff.

It *was* something I was considering coding into bopit ages ago but I decided not to because it could encourage users to 0777 folders and I refuse to encourage that, so I'd only consider coding this ability if the user is running suphp.

Now I know EdB is gonna leap in and say that we should only run if suphp is installed but I'm quite happy for the core to run on crap hosting as long as it refuses to write files if a folder is 0777 ( ie/ chmod 0777 /media/ == You still can't upload files ). In the case of the media folder though I'm seriously considering offering alternative filemanagers that can work with flickr and stuff, but that's certainly not a 0.0.0 thing.

¥

[EdB]

I wasn't gonna leap ... but I had considered jumping On that issue, maybe we should just point out in the 'systems' check that your server is crap if it needs 777 ? Although honestly there is no gain to us to even work in that environment. Pain without gain doesn't sound like a good place to be.

Back on track: "Picking prior to creating a zip" is a choice. "Picking during installation" is another. Both reasonably similar. The third "real" way doesn't sound any different from the first to my mind, so I'm probably missing where you're at. In any case, I think david's issue is "what is considered core" or maybe more along the lines of "what about plugins and stuff that come from third parties after a release happens". To that detail I'm into making sure we only redistribute cool stuff so that making it be 'core' one day is relatively easy.

In any case and either way, some sort of stats tracking helps us learn what the "full" package should contain. We start with what we think gives good blog, then dial it in accordingly based on actual download data.

Oh and do you include sample posts in "full"? I would, but that's just me. Alternatively, never mind cuz I don't like the alternative I just came up with

I gotta run but again I'll say "just the core" should not need a template. We should be able to make it always use a set of files in /templates/ and a style sheet found in the same path. That style sheet would then be used for multiblogs and summary instead of the grossly hidden crap in /rsc/. Just thinkin before finding the business card lady.

[Tblue]

I'm a bit in a hurry right now, but I think PNM is a good idea. I think full.zip should include sample posts, because it looks like it might be of interest to new users; but on the other hand, it may be better to simply make the sample posts optional (as it is the case right now) -- PNM should be completely configurable anyway, which means sample posts should be optional here anyway.

[EdB]

Sample posts in PNM will be impossible. How can you install a post that uses, for example, bbcode plugin if the picker doesn't pick that one?

DEFAULT, BARE, FULL, PNM seems to be the idea eh? But DEFAULT is BARE if we make it use files in /templates/ when no templates actually exist. I wonder how hard that would be? FULL with an option to turn off sample posts is what we have now right?

Who voted for option one?

Plus hey dig this: setting all this up is NOT 0.0.0 material. Knowing where we're going, assuming we're going anywhere, is good to do but not having a PNM option is not a show stopper. In other words, based on the other poll we're going to open the doors soon. That, to me, means we should have a pre-release ready. Which will be v0.0.0. Which is pretty much "option one". Which will be "as is" and ongoing change at the same pace we're changing now of course, and that's the way it is and use it at your peril. hm!

[Yabs]

Agreed @ 0.0.0 should be KISS

PNM ++ default posts is doable, but certainly not 0.0.0

¥