On Wed, Feb 2, 2011 at 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 I by no means intended to delay release by months (or weeks for that matter). I was suggesting something like #2 in the first place. I just think it would be very confusing to users to see these areas/blocks in all 3 default themes but not have any idea what the purpose is. Having at least a simple text box that can be activated and dragged into the space at least gives them context, and that other plugins may also support this feature. ~miklb > > > -- > 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
