The more this conversation goes, the more I regret voting -1. My real goal was to just get _something_ into core that would give a new user the ability to understand what blocks are and not be confused. I do not want to see this go down a road of discussion until interest wanes and we do not release for another X months.
I think from what I've been shown, commonblocks is what I'm suggesting. Can it be improved? I assume so. Can the UI for blocks be improved. Yes. I would whole heartedly revoke my -1 if commonblocks was included in core and we simply say we make that whole element a focus to improve in the .7 cycle and blocks/areas/scopes a focus in .8. (Or some relative compromise that wouldn't stop a release) 2ยข ~miklb On Thu, Feb 3, 2011 at 8:18 PM, mikelietz <[email protected]> wrote: > #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 > -- 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
