User:michaeltwofish

From Habari Project

Jump to: navigation, search

Blog

Feel free to ping me about any of this stuff on #habari.

Contents

Releasing 0.7

  • Current status of merge trunk to makaanga: next merge r4276 to ??
  • Continue to work on defect tickets left in 0.7 (some may be deferred) [1].
  • Improve Release 0.7 notes.
  • Follow the Release Checklist.

Tasks that can happen after release

Documentation

Important wiki pages that need to be integrated:

Pages I've asked people to work on:

  • Core:Benchmarking - BigJibby, throw some stuff in about benchmarking with xdebug
  • Caching - BigJibby, this is a user page, and there probably should be dev and core pages too, but anything that's dumped here would be good.

Wanted Pages

A bunch of pages analogous to Dev:Retrieving Posts:

Quality Assurance

  • Unit Testing
  • Continuous integration (Phing, Cruise Control, phpUnderControl, Capistrano, Xinc, Bamboo($$))
  • Number of operations, http://pecl.php.net/package/vld
  • Benchmarking 
15:19 < rick_c> turn on db profiling
15:20 < rick_c> or xdebug's profiling
15:20 < BigJibby> and your query logs
15:20 < BigJibby> in mysql
15:20 < BigJibby> it will give you times
15:20 < BigJibby> then write a script to parse, and average
  • Testing plugins. There should be a way to easily add and run tests for plugins.

Possible Tests

#537

Crash reporter

Error class to phone home with a stack.

Code Changes

Refactoring the Installer

The installer has to know too much about supported databases and servers. See #1022.

Some very draft code ideas are at User:michaeltwofish/installer_refactor.

API Improvements

  • Posts::count_all() is poorly named, as it actually counts posts retrieved by the last call to Posts::get() that didn't return a single Post. Rename to Posts::count_retrieved()? Other suggestions?
  • Controller, Site, URL feel mixed together. Maybe refactor some into oblivion, moving functions into ActionHandler, RewriteRules.

Comments as a content type

-dev discussion

Atom and AtomPub

Implementation notes

  • We save categories as tags. I'm not sure that we should blindly do this. What if the user has a categories plugin?
  • We should return a suitable header when trying to PUT to a non-existent post.

Habari File Manager

  • Access interface through Manage -> Files
  • Drag and drop file movement
  • Click to rename
  • Click to edit metadata
  • Multiple file uploads
  • Upload zip files
  • Preferably manage media from all silos, not just the Habari Silo.

Plugin states

Ideas for plugin states.

active
As now.
hold
All active plugins can be moved en masse to be on hold. Plugins won't run, but their data is intact. They can be bulk moved back to active. This is useful for upgrading or seeing if a particular behaviour is caused by a plugin or core.
deactivate
The plugin won't run, but its data is not touched.
clean
Remove all the plugin's data. Data can be registered so that the user can clean them, even if the plugin's directory has been deleted. See #346.

Here's some discussion on IRC. People don't like 'hold' or 'clean'. 'snapshot' was suggested to replace 'hold', which is probably better. 'uninstall' was suggested for 'clean' but then people think we're deleting the plugin directories as well.

Rules plugin

A plugin that allows administrators (via ACL token) to define chainable rules with associated actions. It would be most interesting when combined with other plugins. This would be useful as the basis for all notification type plugins, such as if post X has a comment send an XMPP notification to user Y. It would also be useful for defining workflows, such as if Y saves a post, an email should be sent to Z, who can publish it.

Need to find possible triggers and possible actions. Triggers are calls to Plugins::{act,filter} (how can these be found?). Actions can be found by reflecting classes that descend from Pluggable.

Search

  • Should be entirely replaceable
  • Index IsContent ?
  • Use index for related posts, tag suggestions

WYSIWYG editors

A tour plugin

  • To be used where a site is built for a client
  • Outline capabilities based on the logged-in user's permissions

Offline support

Google Wave

  • Offer posts and comments as waves

Correct My Typos plugin

  • Allow readers to highlight spelling and grammar errors on a post and write corrections.
  • Readers who submit corrections would see the corrections (store that they should in a cookie)
  • The admin and/or author would get a comment (a new 'correction' comment type?).
  • The correction could be rejected (and deleted) or accepted.
  • An accepted correction would patch a post.
  • Those who submitted the correction could configurably be notified.

RandomGetter plugin

I'm not sure how this might work, but a plugin that provides an interface for getting random objects. An example would be $theme->get_random('image'). The idea is that you could drop in an implementation that returns a random thing, a quote from a database, a random post, whatever.

So, maybe, an interface RandomGetter and you could drop getters, which is just a class that implements RandomGetter, into a getters directory.

Admin niggles

  • Tabular data should be in tables (manage pages).
  • Drop buttons hide actions. The button says 'Edit' and hides 'View' and 'Delete'. The button the user can see should reflect everything in the drop down. In this case, it should say 'Actions'.
  • Sub menus. See [2]. The user should have the option of using sub menus, but they should default to expanded. Better still, the whole menu should be configurable by the user, with its own vocabulary. Currently adding menu items is less than easy to do anywhere but at the bottom. Slicing (as per the wiki) doesn't look right.
  • The use of colour to denote status on the manage comments page is ugly. We should just write what the status is. The drop buttons are also particulary ugly here as they're very wide.
  • The tags page needs serious thought. Who uses it, and how? Is there a better way to manage your tags?
  • The themes page should be redesigned, as being discussed here [3].
  • It's likely the HTML and CSS should be cleaned up.
  • Progressive enhancement is likely to help with said cleanup, and probably simplify the Javascript.
  • More layout elements/classes should be available to plugin authors for making admin interfaces/pages.

Miscellaneous

  • Form mailer
  • OpenID
  • Taxonomy
  • XMPP integration, notification
  • OMB support
  • Automatically create a FormUI CRUD form from QueryRecord classes.
  • Comments as content types, with a comment type taxonomy that plugins can add to (site, pingback, wavelet, whatever).
  • Dashboard modules as blocks/areas.

Ziada Project

An unofficial community repository for Habari

For themes and plugins that can be licensed with the Apache Software License, there's the Habari Extras repository.

Some things don't belong in there, but we'd still like to collaborate on them. That's what this project is for.

Retrieved from "http://wiki.habariproject.org/en/User:michaeltwofish"
Personal tools