On Feb 3, 9:14 pm, Michael Bishop <[email protected]> wrote: > > 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
A variation on #2 would be my preference. It has been entirely too long since we had a formal release. I don't see adding a core plugin illustrating block creation as being a problem, either commonblocks or a plugin with a less extensive set of blocks covering three or four blocks that people generally use. All three core themes can use blocks now. Adding styling to the css for the blocks to one or the other shouldn't take too long. Plugin authors would have a simple example of how to create blocks that are usable by themers. Habari would have a built-in example of using blocks in a theme. We would be able to release 0.7 this month. I don't think that will lead to releasing a poorly executed 0.8 too quickly, as it would give time to do a proper update, while still not having a huge delay before 0.8 is ready. Rick -- 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
