Announcing DRUPAL-7-0-UNSTABLE-2
I just rolled the second in the series of Drupal 7 unstable releases for developers (see http://lists.drupal.org/pipermail/development/2008-October/031094.html for more info). Among the highlights this release are: * Several awesome File API improvements. Files are now "first-class objects" like nodes and users are, the API has been dramatically cleaned up for better consistency, AND there are a slew of new hooks like hook_file_load() and hook_file_validate() for contrib modules to react to when stuff happens to files. This is a great enabler for some awesome stuff in core like image handling and document management. See http://api.drupal.org/api/search/7/hook_file for more info. A HUGE shout-out to Andrew Morton (drewish) for sticking with this patch throughout its long, LONG development cycle. :) * Also in additional hooks, hooks are now fired whenever modules are installed, uninstalled, enabled, or disabled. See http://api.drupal.org/api/search/7/hook_modules for more info. This should pave the way for some nice DX patches in future unstable releases. * In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op parameters are now gone. Instead of having to switch on $op and figure out what in the world '$arg1' is in the 'load' context (UGH), you instead implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what you're dealing with. * Permission names are now localizable, which gives permissions human-friendly names in addition to descriptions. This changed the hook_perm() array somewhat. See http://drupal.org/node/224333#descriptions-permissions for more details. * Better security! Drupal 7 is now caught up to Drupal 6 on security patches. Now you can setup a Drupal 7 test site with far less pwnage! ;) Incidentally, for those brave contrib module authors who want to chase HEAD, the Updating Modules page is now broken down by unstable release so you can make changes incrementally: http://drupal.org/node/224333. One thing there is *not* in this release is a lot of major usability enhancements. I'd really like to see this change over the next couple of unstable releases. Drupal 7's API is shaping up nicely, and we're getting tons of patches in that enable new things for our developers as well as clean up silly crap that's been annoying us collectively for a long time. But I'd like to get some focus on real "Wow-factor" things for our end users, too... and sooner than later so we can test them ahead of release and make sure they actually /do/ make things easier to use. :) The Usability team has identified 3 top usability issues to focus on at http://groups.drupal.org/node/7074. If any of you out there have "make Drupal 7 kick ass" as one of their todos, they would really appreciate help on how to break down these major issues into smaller, actionable items, and need some folks to write and test patches to get them addressed. There are also a number of smaller, more bite-sized issues that would be nice improvements, and new features that would make Drupal easier to use. http://groups.drupal.org/patch-spotlight is where this sort of "bubbling up" of important issues is being organized. Since UNSTABLE-1 was released on the 1st, and UNSTABLE-2 on the 12th, let's shoot for UNSTABLE-3 to be towards the end of the month, hopefully with some nice usability improvements in addition to more goodies for developers. Looking forward to reviewing and committing your patches! :) -Angie
On Mon, Oct 13, 2008 at 12:05 AM, Angela Byron <drupal-devel@webchick.net> wrote:
Incidentally, for those brave contrib module authors who want to chase HEAD, the Updating Modules page is now broken down by unstable release so you can make changes incrementally: http://drupal.org/node/224333.
Well, this is all great. Except that I modified the existing hook_perm() docs (there were changes to hook_perm() in UNSTABLE_1 and UNSTABLE_2 as well). I thought it would be best to have docs carry over people from Drupal 6 to 7 all at once, but this goes somewhat against the grouping you intend. What I did now, is that I've included the link to the _perm() changes in both sections and modified the perm intro to say this: <a href="http://drupal.org/node/30984">(issue)</a> released in UNSTABLE_1 and <a href="http://drupal.org/node/313213">(issue)</a> released in UNSTABLE_2. If you know something better to make cross-UNSTABLE changes documented with a single doc, it would be great to put forward :) Gabor
Gábor Hojtsy wrote:
On Mon, Oct 13, 2008 at 12:05 AM, Angela Byron <drupal-devel@webchick.net> wrote:
Incidentally, for those brave contrib module authors who want to chase HEAD, the Updating Modules page is now broken down by unstable release so you can make changes incrementally: http://drupal.org/node/224333.
Well, this is all great. Except that I modified the existing hook_perm() docs (there were changes to hook_perm() in UNSTABLE_1 and UNSTABLE_2 as well). I thought it would be best to have docs carry over people from Drupal 6 to 7 all at once, but this goes somewhat against the grouping you intend.
What I did now, is that I've included the link to the _perm() changes in both sections and modified the perm intro to say this:
<a href="http://drupal.org/node/30984">(issue)</a> released in UNSTABLE_1 and <a href="http://drupal.org/node/313213">(issue)</a> released in UNSTABLE_2.
If you know something better to make cross-UNSTABLE changes documented with a single doc, it would be great to put forward :)
Ah, this is how I would handle this: * Keep the text of the page geared toward people updating 6 to 7 all at once. (issue) and (issue); no need to specify when it was added. * In the table of contents though, under UNSTABLE-2, add the permission change with a link to the place that talks about both. This way, the ToC can be for incremental updaters, but the text can be for the "all-at-once" folks. Make sense? -Angie
On Mon, Oct 13, 2008 at 7:00 PM, Angela Byron <drupal-devel@webchick.net> wrote:
Ah, this is how I would handle this:
* Keep the text of the page geared toward people updating 6 to 7 all at once. (issue) and (issue); no need to specify when it was added.
* In the table of contents though, under UNSTABLE-2, add the permission change with a link to the place that talks about both.
"Place that talks about both" would be the same as in the * before, right? Somehow we'd still need to point people on what changed in that section from one UNSTABLE to the other, right? Or did I miss something? Gabor
I don't think we should maintain documentation for API changes between UNSTABLE versions, that seems like a recipe for a huge mess to me and lots and lots of duplicate work. There seems to be two ways you'd upgrade a contrib module: 1. Every time there's an unstable release, upgrade your contrib module 2. wait a while, then upgrade to the latest UNSTABLE (or beta, or 7.0) Maintaining two sets of upgrade documentation seems to be accounting for 3. Wait a while, then go through UNSTABLE-1, UNSTABLE-2, UNSTABLE-3 one at a time. 3. just looks like a lot of work for no gain to me. Therefore, if an API changes between UNSTABLE-1 and UNSTABLE-2 - then we should document the 6.x - 7.x upgrade in UNSTABLE-2 as 'this is the most recent unstable release where this particular API was changed'. If UNSTABLE-2 is out, no-one should be trying to upgrade to UNSTABLE-1 at all. If you're upgrading from UNSTABLE-1 to UNSTABLE-2, then the fact that (in this example) permissions changes are there again, means you ought to be able to work out what to do. In the same way we don't provide database updates for different versions of HEAD, I don't think we should provide API updates for different versions of HEAD either. Or have I missed something really obvious? Nat On Mon, Oct 13, 2008 at 6:02 PM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
On Mon, Oct 13, 2008 at 7:00 PM, Angela Byron <drupal-devel@webchick.net> wrote:
Ah, this is how I would handle this:
* Keep the text of the page geared toward people updating 6 to 7 all at once. (issue) and (issue); no need to specify when it was added.
* In the table of contents though, under UNSTABLE-2, add the permission change with a link to the place that talks about both.
"Place that talks about both" would be the same as in the * before, right? Somehow we'd still need to point people on what changed in that section from one UNSTABLE to the other, right? Or did I miss something?
Gabor
On Mon, Oct 13, 2008 at 7:13 PM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
Therefore, if an API changes between UNSTABLE-1 and UNSTABLE-2 - then we should document the 6.x - 7.x upgrade in UNSTABLE-2 as 'this is the most recent unstable release where this particular API was changed'. If UNSTABLE-2 is out, no-one should be trying to upgrade to UNSTABLE-1 at all. If you're upgrading from UNSTABLE-1 to UNSTABLE-2, then the fact that (in this example) permissions changes are there again, means you ought to be able to work out what to do.
You say we should just move these sections around as if no hook_perm() change would have happened in UNSTABLE_1? Gábor
On Mon, Oct 13, 2008 at 6:16 PM, Gábor Hojtsywrote:
You say we should just move these sections around as if no hook_perm() change would have happened in UNSTABLE_1?
Gábor
That's exactly what I mean yes. Once UNSTABLE_2 comes out, there should be no need for specific documentation for UNSTABLE_1 (except it's useful to have the division there for people upgrading from UNSTABLE_1 to UNSTABLE_2. Upgrading from 6.x to UNSTABLE_1 to UNSTABLE_2 all in one go doesn't need to be supported - same as we don't support that for sites either. Nat
On Mon, 13 Oct 2008 18:29:06 +0100, "Nathaniel Catchpole" <catch56@googlemail.com> wrote:
On Mon, Oct 13, 2008 at 6:16 PM, Gábor Hojtsywrote:
You say we should just move these sections around as if no hook_perm() change would have happened in UNSTABLE_1?
Gábor
That's exactly what I mean yes. Once UNSTABLE_2 comes out, there should be no need for specific documentation for UNSTABLE_1 (except it's useful to have the division there for people upgrading from UNSTABLE_1 to UNSTABLE_2. Upgrading from 6.x to UNSTABLE_1 to UNSTABLE_2 all in one go doesn't need to be supported - same as we don't support that for sites either.
Nat
In principle I'd agree with Nat here. Once UNSTABLE-2 is out, there's no reason for anyone to upgrade specifically to UNSTABLE-1. They can and should "chase unstable", as that's exactly what we want them to be doing. --Larry Garfield
On Oct 13, 2008, at 12:23 PM, Larry Garfield wrote:
They can and should "chase unstable", as that's exactly what we want them to be doing.
The point of having upgrade docs split up by UNSTABLE-N is precisely to make it easier for contrib maintainers to "chase unstable". cvs_deploy is currently ported to UNSTABLE-1. It'd be nice if I could just look somewhere and see what APIs changed between UNSTABLE-1 and UNSTABLE-2 that would require further porting to keep cvs_deploy working in UNSTABLE-2. Anyone "chasing unstable" is in the same boat. Yes, I could figure it out via reading through all the CVS log messages since UNSTABLE-1, but that's time consuming and contains a lot of noise if the signal I'm looking for are API changes that would break my module(s). Since there's no release node for UNSTABLE-2, and webchick decided not to mess with documenting these things by unstable version in CHANGELOG.txt, there's no good place to see the relevant changes since UNSTABLE-1. While we were hashing all this out in IRC, webchick suggested splitting up the module upgrade docs by UNSTABLE version, so at least there'd be somewhere (where contrib authors are looking anyway) to see all API changes between each unstable. If this high-signal info is not in CHANGELOG.txt, there's not a release node, and it's not in the upgrade docs, where do y'all propose to put it? If there's no such high-signal info anywhere, it makes "chasing unstable" more of a chore, and you can bet fewer contrib maintainers will bother. Cheers, -Derek (dww)
On Oct 14, 2008, at 1:00 AM, Derek Wright wrote:
If this high-signal info is not in CHANGELOG.txt, there's not a release node, and it's not in the upgrade docs, where do y'all propose to put it?
p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an unstable, it'd sure suck if the upgrade docs have all been "merged" again except for unstable2 => unstable3. I don't see any value in destroying this information once we have it. If we think the upgrade docs will get too confusing if the table of contents (TOC) is organized by unstable, then we need a different solution. But we need something that preserves the high-signal info about API changes for each unstable, since we can't be sure who needs which parts of it. I don't see anything wrong with keeping the TOC organized by unstable during the entire lifecycle of unstable. Once we hit beta1, we can move the per-unstable TOC stuff to the bottom of the page as an appendix, and make a new merged TOC organized by importance or subsystem or however else people think the info should be merged for the "final" doc. Cheers, -Derek (dww)
The idea wasn't to merge everything, but it's to only keep the most recent version of any particular API. For example, hook_nodeapi just got split up, there's a chance the $a3 and $a4 arguments might get removed too. I don't see that having a single 'hook_nodeapi has changed' entry makes things any more confusing than having two separate entries with somewhat conflicting information if it's a bit different between two unstable versions. Similarly when dbtng was first committed, people were encouraged to use ? placeholders and :named placeholders interchangeably - we now only recommend :named placeholders due to query logging - surely it's better to have a single line on this than have the docs change all the way through. Same for permissions arrays getting the extra 'title' index etc. I can't think of many other things where a particular upgrade instruction would have to change between one unstable release and another - so IMO it's better to have one block of documentation in those (fairly rare) cases than two contradictory and partial ones. Everything else would still be grouped by unstable release. So far, the differences have all be pretty minor, we could always leave a note in the earlier documentation saying 'this change was subsequently revised, see below and '#issue'. Nat On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright <drupal@dwwright.net> wrote:
On Oct 14, 2008, at 1:00 AM, Derek Wright wrote:
If this high-signal info is not in CHANGELOG.txt, there's not a release
node, and it's not in the upgrade docs, where do y'all propose to put it?
p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an unstable, it'd sure suck if the upgrade docs have all been "merged" again except for unstable2 => unstable3. I don't see any value in destroying this information once we have it. If we think the upgrade docs will get too confusing if the table of contents (TOC) is organized by unstable, then we need a different solution. But we need something that preserves the high-signal info about API changes for each unstable, since we can't be sure who needs which parts of it.
I don't see anything wrong with keeping the TOC organized by unstable during the entire lifecycle of unstable. Once we hit beta1, we can move the per-unstable TOC stuff to the bottom of the page as an appendix, and make a new merged TOC organized by importance or subsystem or however else people think the info should be merged for the "final" doc.
Cheers, -Derek (dww)
Maybe I wasn't clear enough in my first response, or I'm confused by the follow-ups. I really don't think this needs to be that complicated. UNSTABLE-1: - <a href="#blah-dee-blah">Blah-dee-blah got a new foo thingy</a> ... UNSTABLE-2: - <a href="#blah-dee-blah">Blah-dee-blah got a new bar thingy</a> ... <h2 id="blah-dee-blah">Blah-dee-blah has changed</h2> (issue) and (issue) Blah-dee-blah has changed since Drupal 6, in that it has a new FOO and a BAR thingy. Here's the before/after code: ... --- The body of the document is written for people who are not chasing stable, so that we don't need to make huge changes to it before release. The ToC is organized by unstable releases so that someone chasing HEAD can get a quick summary of the changes since the last time they updated. If they already added a foo thingy, it's pretty easy to read the code and see that they need a bar thingy too. Agreed? -Angie Nathaniel Catchpole wrote:
The idea wasn't to merge everything, but it's to only keep the most recent version of any particular API.
For example, hook_nodeapi just got split up, there's a chance the $a3 and $a4 arguments might get removed too. I don't see that having a single 'hook_nodeapi has changed' entry makes things any more confusing than having two separate entries with somewhat conflicting information if it's a bit different between two unstable versions.
Similarly when dbtng was first committed, people were encouraged to use ? placeholders and :named placeholders interchangeably - we now only recommend :named placeholders due to query logging - surely it's better to have a single line on this than have the docs change all the way through. Same for permissions arrays getting the extra 'title' index etc.
I can't think of many other things where a particular upgrade instruction would have to change between one unstable release and another - so IMO it's better to have one block of documentation in those (fairly rare) cases than two contradictory and partial ones. Everything else would still be grouped by unstable release. So far, the differences have all be pretty minor, we could always leave a note in the earlier documentation saying 'this change was subsequently revised, see below and '#issue'.
Nat
On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright <drupal@dwwright.net <mailto:drupal@dwwright.net>> wrote:
On Oct 14, 2008, at 1:00 AM, Derek Wright wrote:
If this high-signal info is not in CHANGELOG.txt, there's not a release node, and it's not in the upgrade docs, where do y'all propose to put it?
p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an unstable, it'd sure suck if the upgrade docs have all been "merged" again except for unstable2 => unstable3. I don't see any value in destroying this information once we have it. If we think the upgrade docs will get too confusing if the table of contents (TOC) is organized by unstable, then we need a different solution. But we need something that preserves the high-signal info about API changes for each unstable, since we can't be sure who needs which parts of it.
I don't see anything wrong with keeping the TOC organized by unstable during the entire lifecycle of unstable. Once we hit beta1, we can move the per-unstable TOC stuff to the bottom of the page as an appendix, and make a new merged TOC organized by importance or subsystem or however else people think the info should be merged for the "final" doc.
Cheers, -Derek (dww)
Yeah, that's what I meant, thanks for putting it so clearly :) Nat On Tue, Oct 14, 2008 at 12:07 PM, Angela Byron wrote:
Maybe I wasn't clear enough in my first response, or I'm confused by the follow-ups. I really don't think this needs to be that complicated.
UNSTABLE-1: - <a href="#blah-dee-blah">Blah-dee-blah got a new foo thingy</a> ...
UNSTABLE-2: - <a href="#blah-dee-blah">Blah-dee-blah got a new bar thingy</a> ...
<h2 id="blah-dee-blah">Blah-dee-blah has changed</h2>
(issue) and (issue) Blah-dee-blah has changed since Drupal 6, in that it has a new FOO and a BAR thingy. Here's the before/after code:
...
---
The body of the document is written for people who are not chasing stable, so that we don't need to make huge changes to it before release. The ToC is organized by unstable releases so that someone chasing HEAD can get a quick summary of the changes since the last time they updated. If they already added a foo thingy, it's pretty easy to read the code and see that they need a bar thingy too.
Agreed?
-Angie
Nathaniel Catchpole wrote:
The idea wasn't to merge everything, but it's to only keep the most recent version of any particular API.
For example, hook_nodeapi just got split up, there's a chance the $a3 and $a4 arguments might get removed too. I don't see that having a single 'hook_nodeapi has changed' entry makes things any more confusing than having two separate entries with somewhat conflicting information if it's a bit different between two unstable versions.
Similarly when dbtng was first committed, people were encouraged to use ? placeholders and :named placeholders interchangeably - we now only recommend :named placeholders due to query logging - surely it's better to have a single line on this than have the docs change all the way through. Same for permissions arrays getting the extra 'title' index etc.
I can't think of many other things where a particular upgrade instruction would have to change between one unstable release and another - so IMO it's better to have one block of documentation in those (fairly rare) cases than two contradictory and partial ones. Everything else would still be grouped by unstable release. So far, the differences have all be pretty minor, we could always leave a note in the earlier documentation saying 'this change was subsequently revised, see below and '#issue'.
Nat
On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright wrote:
On Oct 14, 2008, at 1:00 AM, Derek Wright wrote:
If this high-signal info is not in CHANGELOG.txt, there's not a release node, and it's not in the upgrade docs, where do y'all propose to put it?
p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an unstable, it'd sure suck if the upgrade docs have all been "merged" again except for unstable2 => unstable3. I don't see any value in destroying this information once we have it. If we think the upgrade docs will get too confusing if the table of contents (TOC) is organized by unstable, then we need a different solution. But we need something that preserves the high-signal info about API changes for each unstable, since we can't be sure who needs which parts of it.
I don't see anything wrong with keeping the TOC organized by unstable during the entire lifecycle of unstable. Once we hit beta1, we can move the per-unstable TOC stuff to the bottom of the page as an appendix, and make a new merged TOC organized by importance or subsystem or however else people think the info should be merged for the "final" doc.
Cheers, -Derek (dww)
Only in Drupal would "blah-dee-blah" be "putting it so clearly". :-) That said, what webchick says below (when she's supposed to be on vacation) makes sense. My point earlier wasn't that we shouldn't split the TOC by unstable tag, but that once unstable-2 is out, we really shouldn't expect anyone to *then* port anything to unstable-1. We want them to be going to unstable-2. Also, for the record, ? for DB placeholders was considered bad form (at least by me) even before DBTNG was committed as it is less self-documenting. Although the code does not currently forbid it, ? was not included in any of the documentation for DBTNG since, um, the original Barcelona presentation a year ago. :-) Certainly never in anything official. On Tuesday 14 October 2008 6:37:23 am Nathaniel Catchpole wrote:
Yeah, that's what I meant, thanks for putting it so clearly :)
Nat
On Tue, Oct 14, 2008 at 12:07 PM, Angela Byron wrote:
Maybe I wasn't clear enough in my first response, or I'm confused by the follow-ups. I really don't think this needs to be that complicated.
UNSTABLE-1: - <a href="#blah-dee-blah">Blah-dee-blah got a new foo thingy</a> ...
UNSTABLE-2: - <a href="#blah-dee-blah">Blah-dee-blah got a new bar thingy</a> ...
<h2 id="blah-dee-blah">Blah-dee-blah has changed</h2>
(issue) and (issue) Blah-dee-blah has changed since Drupal 6, in that it has a new FOO and a BAR thingy. Here's the before/after code:
...
---
The body of the document is written for people who are not chasing stable, so that we don't need to make huge changes to it before release. The ToC is organized by unstable releases so that someone chasing HEAD can get a quick summary of the changes since the last time they updated. If they already added a foo thingy, it's pretty easy to read the code and see that they need a bar thingy too.
Agreed?
-Angie
Nathaniel Catchpole wrote:
The idea wasn't to merge everything, but it's to only keep the most recent version of any particular API.
For example, hook_nodeapi just got split up, there's a chance the $a3 and $a4 arguments might get removed too. I don't see that having a single 'hook_nodeapi has changed' entry makes things any more confusing than having two separate entries with somewhat conflicting information if it's a bit different between two unstable versions.
Similarly when dbtng was first committed, people were encouraged to use ? placeholders and :named placeholders interchangeably - we now only recommend
:named placeholders due to query logging - surely it's better to have a
single line on this than have the docs change all the way through. Same for permissions arrays getting the extra 'title' index etc.
I can't think of many other things where a particular upgrade instruction would have to change between one unstable release and another - so IMO it's better to have one block of documentation in those (fairly rare) cases than two contradictory and partial ones. Everything else would still be grouped by unstable release. So far, the differences have all be pretty minor, we could always leave a note in the earlier documentation saying 'this change was subsequently revised, see below and '#issue'.
Nat
On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright wrote:
On Oct 14, 2008, at 1:00 AM, Derek Wright wrote:
If this high-signal info is not in CHANGELOG.txt, there's not a release node, and it's not in the upgrade docs, where do y'all propose to put it?
p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an unstable, it'd sure suck if the upgrade docs have all been "merged" again except for unstable2 => unstable3. I don't see any value in destroying this information once we have it. If we think the upgrade docs will get too confusing if the table of contents (TOC) is organized by unstable, then we need a different solution. But we need something that preserves the high-signal info about API changes for each unstable, since we can't be sure who needs which parts of it.
I don't see anything wrong with keeping the TOC organized by unstable during the entire lifecycle of unstable. Once we hit beta1, we can move the per-unstable TOC stuff to the bottom of the page as an appendix, and make a new merged TOC organized by importance or subsystem or however else people think the info should be merged for the "final" doc.
Cheers, -Derek (dww)
-- Larry Garfield larry@garfieldtech.com
Uh, DX? What does that mean? ..chris On Sun, Oct 12, 2008 at 5:05 PM, Angela Byron <drupal-devel@webchick.net>wrote:
I just rolled the second in the series of Drupal 7 unstable releases for developers (see http://lists.drupal.org/pipermail/development/2008-October/031094.html for more info). Among the highlights this release are:
* Also in additional hooks, hooks are now fired whenever modules are installed, uninstalled, enabled, or disabled. See http://api.drupal.org/api/search/7/hook_modules for more info. This should pave the way for some nice DX patches in future unstable releases.
* In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op parameters are now gone. Instead of having to switch on $op and figure out what in the world '$arg1' is in the 'load' context (UGH), you instead implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what you're dealing with.
DX == Developer Experience http://groups.drupal.org/node/15368 Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Mon, Oct 13, 2008 at 8:02 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
Uh, DX? What does that mean? ..chris
On Sun, Oct 12, 2008 at 5:05 PM, Angela Byron <drupal-devel@webchick.net>wrote:
I just rolled the second in the series of Drupal 7 unstable releases for developers (see http://lists.drupal.org/pipermail/development/2008-October/031094.htmlfor more info). Among the highlights this release are:
* Also in additional hooks, hooks are now fired whenever modules are installed, uninstalled, enabled, or disabled. See http://api.drupal.org/api/search/7/hook_modules for more info. This should pave the way for some nice DX patches in future unstable releases.
* In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op parameters are now gone. Instead of having to switch on $op and figure out what in the world '$arg1' is in the 'load' context (UGH), you instead implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what you're dealing with.
Sample DX fix for D7 -- though not yet patched. Developers will no longer need to uninstall their own schemas, permissions, or (hopefully) variables when their module is uninstalled. system_modules_uninstalled() can now handle all that for you, which means less for you to worry about and less redundancy in the code. See http://drupal.org/node/306027 for example. On Mon, Oct 13, 2008 at 10:04 AM, Kyle Mathews <mathews.kyle@gmail.com> wrote:
DX == Developer Experience http://groups.drupal.org/node/15368
Kyle
Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog
On Mon, Oct 13, 2008 at 8:02 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
Uh, DX? What does that mean? ..chris
On Sun, Oct 12, 2008 at 5:05 PM, Angela Byron <drupal-devel@webchick.net> wrote:
I just rolled the second in the series of Drupal 7 unstable releases for developers (see http://lists.drupal.org/pipermail/development/2008-October/031094.html for more info). Among the highlights this release are:
* Also in additional hooks, hooks are now fired whenever modules are installed, uninstalled, enabled, or disabled. See http://api.drupal.org/api/search/7/hook_modules for more info. This should pave the way for some nice DX patches in future unstable releases.
* In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op parameters are now gone. Instead of having to switch on $op and figure out what in the world '$arg1' is in the 'load' context (UGH), you instead implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what you're dealing with.
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
participants (9)
-
Angela Byron -
Chris Johnson -
Daniel F. Kudwien -
Derek Wright -
Gábor Hojtsy -
Ken Rickard -
Kyle Mathews -
Larry Garfield -
Nathaniel Catchpole