User:Michaeltwofish

From Habari Project

Revision as of 22:12, 9 December 2011 by Michaeltwofish (Talk | contribs)
Jump to: navigation, search

Blog

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

Contents

Why we should be > 5.3.1

  • We're supposed to be cutting edge.
  • Using the latest stuff is more fun for developing.
  • Namespaces would make class discovery easier and eliminate the need for HabariLocale and HabariDateTime.
  • Remove the workaround for the PHP PDO late binding bug.
  • There are several methods in DateTime that are highly convenient and only in 5.3+ that I keep using and breaking things, like in #1447 - chrismeller
  • Philosophically we should get back to using "today's technology". 5.2 is old. Let's push things forward.
  • Significantly better memory handling - probably won't mean much for a single page load, but it's something to consider
  • Debian Lenny, which ships with 5.2, is unsupported as of 7 February 2012. When Habari 0.9 ships the oldest supported Debian release will have PHP 5.3.
  • Where plugins override core functionality we could use lambda functions to execute only the plugin version and not the core version.
    • This has been called a stupid reason, and it quite possibly is, but the assertion wasn't backed up. Reasons might be, the same effect could be achieved in a way that's compatible with 5.2, the complexity added across the whole application would outweigh any performance gains in rare cases where it's useful, it might be inefficient to pass lambdas around, the added complexity might increase the possibility of bugs. Or it might be something else.

Conventions for mapping namespaces to classes.

Tasks to be done after 0.7 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.

Bits that need work.

  • Translation - This should have a user-facing page that tells people how to run a translation, a page (or pages if it gets long) that guide translators in individual languages, a Dev page about using _t() and n() etc (see this thread on -dev) and a Core page about how the translations actually happen, including what MO and PO files are and how Launchpad works (see this thread on -dev). Also Translation isn't really a good name.

Wanted Pages

Pages related to translation

  • Habari in your language - how to get locales and install and activate them.
  • Dev:Internationalization - Best practices for developing code that can be translated. Things like using _e(), _t(), _n() properly, for example with the printf functionality, don't put HTML in strings etc.
  • Dev:Translating Themes and Plugins - Specifics about allowing internationalization of plugins, such as translation contexts.

Pages analogous to Dev:Retrieving Posts

Quality Assurance

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 - parsing URLS

#1365 - deleting posts should delete associated post info

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

Well-behaved AJAX

When we use AJAX, we should manipulate the browser history and the URL so that pages are bookmarkable and don't break the back button.

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.

Plugin ideas

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.

Rules

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.

Tour

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

Correct My Typos

  • 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.
  • People with accepted regular comments could see a correction tool.

RandomGetter

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.

Menu

Owen wants menus.

  • Allow admins to create a vocabulary for each menu they want to build.
  • Provide a block that displays any menu vocabulary as a menu.
  • Provide a block for each menu that displays breadcrumbs based on a visitor's current location within a specific menu vocabulary.
  • Associate any post to a menu item and allow the admin to reorganize the menus easily.

Google Gadgets

Allow any Google gadget to be added as a block. ref.

Docs

At a URL configurable by the user and with potentially privileged access, provide the API documentation, produced from the actual Habari installation. See Lithium docs for an example. We produce our docs with Doxygen.

Tests

Run tests from within the admin.

Benchmark

Benchmark code from within the admin. Would have to be able to define tasks. See this post for some benchmarking tools.

Grid

To help people design attractive, professional themes, allow the display of a configurable grid, optionally ACL restricted. See these grid bookmarklets for examples of the sorts of grids I mean.

Admin Grid

To ensure consistency when people are manipulating the Habari admin, provide a grid to which any design changes should adhere.

Elastic Search

Index content and perform searches using Elastic Search. There's a PHP library.

Autosave

There is an autosave plugin in -extras, but there have been bad reports about it. Perhaps it should use the jquery autosave plugin.

Post Queue

Flexibly manage scheduled posts. Post on a regular configurable schedule, say once a week, and be able to reorganise posts in a sortable list.

Gist Silo

The name says it all, a media silo for Gist using the Gist API and the embed code.

<script src="https://gist.github.com/{$gist_id}.js?file=step_definitions.rb"></script>

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.

Offline support

Google Wave

  • Offer posts and comments as waves

Search

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

WYSIWYG editors

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 [1]. 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 [2].
  • 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.

Wiki Spam

We could manually confirm accounts.

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.

Things to look at

  • A comment on #1452 suggests better documentation is needed for ascend and descend.
  • Does template selection need some error checking? #1453.
  • Conflict between subpages and metaseo extras #273
  • Write an experiment for #1155. Send an AJAX request, open session data and sleep, send another AJAX request and open session data again.
  • Commits that might require release notes or documentation:
Personal tools