#2. I'd lean more toward commonblocks, even though it is large, because the blocks it contains are more useful right out of the box.
It needs a little work, though - the categories block belongs in a categories plugin, not in it. It needs more commenting. Also, it should probably include a block wrapper as well. Let's get in touch with the original author(s) and see if it's OK to include :P On Feb 2, 10:54 pm, Owen Winkler <[email protected]> wrote: > On 2/2/2011 9:49 PM, Chris Meller wrote: > > > > > I don't like the idea of adding a new plugin that provides a block to > > core just so we can have a plugin that provides a block, that's never > > been the Habari way. If the overwhelming majority of users aren't > > going to use it it's always been our policy that it should be left in > > -extras and I don't see any of the suggested options so far (aside > > from dashboard modules) being used by the vast majority of our > > install base. > > > That said, if we wanted to provide a plugin that really used blocks > > well (ie: got block wrappers and scopes right, used the block CSS > > classes assigned, etc.) and offered some common requests (monthly > > archives, recent posts, recent comments) I wouldn't be opposed to > > that. > > I think its a good idea to ultimately switch the dashboard over to using > blocks instead of modules. However, this would once again throw a > wrench into release. > > At the same time, I think that core themes need to be augmented to make > better use of blocks if we're going to bother including block plugins in > core too. We should examine what features core themes provide currently > that could be replaced with blocks, and then change the themes to use > areas and include blocks to replace that functionality. > > My question at this point is, what we should do now?: > > 1) Release as-is without a core block plugin and immediately revisit > this whole issue for a very fast 0.8 release. > > 2) Include a simple block plugin (literally "simpleblock", or > alternatively "commonblocks" would be my suggestions) for 0.7, and then > revisit the core themes for a fast 0.8 release. > > 3) Review core themes now, replace all their block-like functionality > with areas and a new core block plugin, which may push the 0.7 release > by a month or so. > > 4) Update core themes and produce a core block plugin as in 3, and also > replace the admin dashboard with a block-enabled theme page, which will > postpone 0.7 for an indeterminate amount of time. > > My personal preference on this issue ranges from 1 through 3, with a > keener interest in option 1 corresponding to our ability to guarantee a > fast release date for 0.8 with just the additional features from option 4. > > All that said, option 2 intuitively feels like a nice compromise for > including sample block functionality in core without delaying it too > much, which is why I think this suggestion is on the table. > > I think we're way beyond the point of saying "a little longer after so > long already won't hurt". It *will* hurt to delay, and at this point > I'd rather roll out a better 0.8 in March and potentially have to rip > out a poor choice for 0.7's core block plugin than delay the 0.7 release > to April to add core dashboard blocks. > > If we wanted to, we could add a single -extras block plugin to 0.7 now, > tag it off in makaanga, and start work on the changes from option 4 for > release in 0.8. Fix bugs in branch and release the damn 0.7 already. > > Owen -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
