note

The idea of Drupal Guilds are being championed by Aaron Winborn. They have clear compatibility with Dan's Drupal work collectives idea and many of the principles that define Agaric Design Collective.

http://aaronwinborn.com/blogs/aaron/transcript-drupal-guilds-presentation

wget -O - http://example.org/testfix.patch | patch -p0

From http://groups.drupal.org/node/91424

where deviantintegral suggested
curl http://drupal.org/files/1234_fix.patch | patch -p0

This fix is being done from a remote repository, because stuff was pushed there that shouldn't have been. However, this repository is only supposed to be cloned and not pushed to (one way one time), so we can destructively set it back to the way it should be.

cd /srv/git/agaric/siteproj.git
git reset add42b74103a4c756d7d55c4abf3d5b0ff914b0c

where that is the last good commit.

And that's it.

File this under do not do this at home.

catch telling chrisshattuck in IRC: I keep one checkout + db, reset the checkout with cvs -q diff | patch -p0 -R and usually re-use the database until it's completely dead.

We (the Drupal community) cannot expect webchick to look even once at anything that isn't truly needed for D7's release at this point.

But i think we cannot tell exportables and other developer experience issues to go to hell for the next year or three either.

1. Title must be optional.
2. Saving must be automatic.
3. Must allow multiple edit tabs to be open at once.
4. Tagging and crossreferencing preferred.

For me, it should be the one place for everything. This implies, if done with one content type, possibly having an optional date field, a private textarea...

Background:

Ideally the tabs would be vertical, and somehow in the application, but really it can just use the browser's tabs.

"About Agaric Design Collective"

Related links:
http://data.agaric.com/agaric-design-collective-profiled-academic-paper-snapshot-local-business-start

Full steps to take a new site live:

Create a project in git: https://agariclabs.net/gitweb?p=agaric/scripts.git;a=blob;f=agc.sh;hb=HEAD

Start a MayFirst project.

As root:
aptitude
Find drush under PHP.

At the bottom of the information about the drush package, there's an i that means installed next to 2.0 and a p that means no packages or config files or anything are present next to drush 3.3.

Type + when the drush 3.3 line is highlighted.

Then type g to upgrade (twice, first it takes us to a confirmation page).

Note: On Agaric's servers the package list is updated daily by a cron job, but updating the package list can be invoked by hitting u if necessary.

Castaways from the writing process:

Of course we should have an API or three. We know Jeff Eaton would stick APIs in a novelty module called Eldorado Superfly. No, actually, he didn't. From this we can learn that if our module is simple enough and uses enough of Drupal's APIs, it doesn't need to create its own.

[Eaton] drawing on his experience with VotingAPI, which, we might note, puts API right in the name of the module, and if that doesn't mean something, what does?