Hello world, there are two existing modules I'd like to see added to Drupal 6: 1. OpenID 2. Actions I think both are important 'enablers' for many future things. I already talked to James (OpenID) and John Vandyck (Actions) and they are supporting the idea and willing to help make that happen. Of course, I'd still like to see better image and forum handling in core too, but more about that later. (I believe webhick was working on some forum module improvements but I haven't checked with her yet.) -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
Hello world, there are two existing modules I'd like to see added to Drupal 6:
1. OpenID
Great! How is this related to possibly removing the distributed auth implementation of drupal.module?
2. Actions
Great! Is something on the table to be able to use actions with Drupal core out of the box? Some UI stuff to tie actions to Drupal core events? Gabor
On 01 May 2007, at 13:48, Gabor Hojtsy wrote:
there are two existing modules I'd like to see added to Drupal 6: 1. OpenID
Great! How is this related to possibly removing the distributed auth implementation of drupal.module?
It means we'll remove the distributed authentication implementation of drupal.module. We'll want to move it to a contributed module for legacy reasons (or maybe we let both systems co-exist for one release).
2. Actions
Great! Is something on the table to be able to use actions with Drupal core out of the box? Some UI stuff to tie actions to Drupal core events?
Yes. Maybe John itself can shed some additional light on his recent UI adventures ... ;-) -- Dries Buytaert :: http://www.buytaert.net/
Am Dienstag, den 01.05.2007, 13:48 +0200 schrieb Gabor Hojtsy:
Dries Buytaert wrote:
Hello world, there are two existing modules I'd like to see added to Drupal 6:
1. OpenID
Great! How is this related to possibly removing the distributed auth implementation of drupal.module?
2. Actions
Great! Is something on the table to be able to use actions with Drupal core out of the box? Some UI stuff to tie actions to Drupal core events?
That's really interesting. I'd be too eager to hear more about the plans for drupal 6 & actions. Is it going towards reacting on core events with actions? I'm currently working on workflow-ng as my bachelor thesis, but I'm concentrating on the API itself not on the UI design. Unfortunately I'm not as far as I wanted to be already, because I'm busy with working on other stuff, but I'll give it a kick in the next days. In contrast to workflow I try to focus on 1. providing easy programmatic use, build the UI on top of that 2. decoupling from nodes to various supported "entities" (nodes, users, comments) 3. moving from workflow's transition to flexible events & conditions Actually, the design of 3. is intended to also fit for the use case of assigning actions to various events (no, no calendar! ;) - so this also enables people to customize stuff. In short some other design aspects are * every module may define events, to which different (defined) arguments may be passed * every module may configure conditions for these events with associated actions So the actions are only fired if the conditions are matched for the event. Short use case: Send out different welcome mails based on different registration details. The concept of a workflow like known is provided with the help of the states module - a simple state machine API (code: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/fago/workflow-ng/) In conjunction with the other stuff I described above, this is intended to offer flexible publishing workflows. Read more at http://more.zites.net/node/3030 The design concept also mentions actions-ng, which major difference to actions is that it should work not only for nodes, but like as events and conditions should be able to work on top of different "entities" as well as on top of multiple (possible different) arguments. So perhaps there might be an overlap with the existing plans for drupal 6. If so I'd be happy to help working on this... regards, fago
Op 1-mei-2007, om 13:44 heeft Dries Buytaert het volgende geschreven:
Hello world, there are two existing modules I'd like to see added to Drupal 6:
1. OpenID 2. Actions
Of course, I'd still like to see better image and forum handling in core too, but more about that later. (I believe webhick was working on some forum module improvements but I haven't checked with her yet.)
I'm particularly interested in the better image handling part. The questions remainaining are: What is image handling exactly and how are we going to use it? What needs to be done? Whats the best way to do/implement it? I'm not very familiar with actions.module, but I think it _could_ be a big help for better image handling capabilities. Secondly, I think something like craqbox.module (http://drupal.org/ project/craqbox) is pretty unavoidable for core either. Also when we focus on image handling, this is sort of a must imo because cluttering our node/add/* pages even more with all kind of options than we currently do, would be a pretty bad thing usability-wise. Just dropping in some thoughts which are keeping me awake for quite some time now.. Stefan
Stefan Nagtegaal a ecrit le 01/05/2007 14:56:
Op 1-mei-2007, om 13:44 heeft Dries Buytaert het volgende geschreven:
Secondly, I think something like craqbox.module (http://drupal.org/project/craqbox) is pretty unavoidable for core either.
+1 also on a js popup library. This would be a big usability boost on various UI spots : confirm forms, 'small edits' (menu items, aliases) ... Steven MKenzie states on http://drupal.org/project/craqbox that it's targetted for core inclusion, but I don't know what's the state of this right now. I'd also advocate for HTML corrector (http://drupal.org/project/htmlcorrector) in core - and enabled by default for HTML filters. A vanilla drupal install allowing tags inside posts but then trimming teasers and producing invalid markup / broken layouts does seem like a bug to me. There are several overly long issue threads about that. Drupal.org issue queue could also benefit from this, BTW (how many 'attempt to fix broken HTML' posts ?) I can try to provide a patch if this is approved. Yves
I'd also advocate for HTML corrector (http://drupal.org/project/htmlcorrector) in core - and enabled by default for HTML filters. A vanilla drupal install allowing tags inside posts but then trimming teasers and producing invalid markup / broken layouts does seem like a bug to me. There are several overly long issue threads about that. Drupal.org issue queue could also benefit from this, BTW (how many 'attempt to fix broken HTML' posts ?)
that makes sense to me. i would think that Steven's opinion on this is crucial.
On May 5, 2007, at 6:48 AM, Yves Chedemois wrote:
I'd also advocate for HTML corrector (http://drupal.org/project/ htmlcorrector) in core - and enabled by default for HTML filters. ...
yes, please!
Drupal.org issue queue could also benefit from this, BTW (how many 'attempt to fix broken HTML' posts ?)
right. FYI: it was *impossible* to fix open tags from one follow-up in another comment. :( all of those attempts were in vain. the only solutions to this problem were HTML corrector (at long last, finally running on d.o [1]) or to make it so admins can edit follow-ups, which requires a ton of work to do it right ([2]). putting HTML corrector in core and turning it on by default on filtered HTML makes a ton of sense, IMHO. thanks, -derek [1] http://drupal.org/node/69516 [2] http://drupal.org/node/18920
On May 1, 2007, at 6:44 AM, Dries Buytaert wrote:
there are two existing modules I'd like to see added to Drupal 6:
1. OpenID 2. Actions
this is great! glad to hear it -- i'm sure both will be excellent additions to core. however, you forgot the one me and merlin have been working towards: update_status.module. ;) (true, the plan is it'll just go into system.module, not be a new stand-alone module)... just warning the rest of the development team that this, too, is slated for D6 core if we can finish in time. however, with merlin v2.0 about to be (already?) released, it's going to be falling almost entirely on to my shoulders unless some other folks can help. in particular: http://drupal.org/node/136172 which is what's blocking: http://drupal.org/node/128827 http://drupal.org/node/125742 both of which should ideally be done before this turns into a patch against system.module. there's an extensive roadmap of what needs to happen in #136172, and it certainly can be split up if anyone else wants to help. so, (familiar scene) dww comes pleading for help... ;) please reply to #136172 with your intention (if any) to help, and we can sort out the details. thanks! -derek p.s. anyone with sponsorship money lying around that would love drupal core to be able to tell you when your site is out of date or running a known-to-be-insecure release; and/or would love it if drupal.org could accurately tell us how many sites (that volunteer to share anonymously) are running any given module, theme, translation, etc; should contact me about funding this to ensure it ends up in D6, not D7... ;)
On 01 May 2007, at 15:33, Derek Wright wrote:
however, you forgot the one me and merlin have been working towards: update_status.module. ;) (true, the plan is it'll just go into system.module, not be a new stand-alone module)...
Ah, we certainly want that included in core -- probably as part of the system.module, or not, because the module is loaded on every page request. It would be great if we could focus on the update system while James and John prepare their modules. All: help review, test and brainstorm about these issues -- we need your help to make this a success, and time is limited! Thanks. :)
http://drupal.org/node/136172 http://drupal.org/node/128827 http://drupal.org/node/125742
-- Dries Buytaert :: http://www.buytaert.net/
Dries, I completely agree with your decision to add OpenID to core. I'd like to see OpenID be a part of a generally improved user authentication and security story for D6. My "wipe open sessions on password-change" patch has already been committed (thanks!). Other changes I suggest: 1. Require (instead of request) a password change after one-time login (http://drupal.org/node/138805). I will finish up this patch and mark needs-review soon. 2. Add the Persistent Login (aka "Remember Me"; http://drupal.org/project/persistent_login) module to core. Persistent Login is *more secure* than long-life session cookies in addition to providing a better user experience. There are a couple non-security related issues for this module I will clean up. 3. Change the default PHP session cookie lifetime to 0 (browser lifetime only). Once Persistent Login is in place, the security risk and database overhead of long-life PHP sessions is no longer necessary. Thoughts? Thanks, Barry
On 01 May 2007 10:30:28 -0400, Barry Jaspan <barry@jaspan.org> wrote:
2. Add the Persistent Login (aka "Remember Me"; http://drupal.org/project/persistent_login) module to core.
3. Change the default PHP session cookie lifetime to 0 (browser lifetime only).
+1 -- persistent login and the return of the "remember me" button has pretty much become part of my "standard load" for site builds. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Jaspan wrote:
Dries,
I completely agree with your decision to add OpenID to core. I'd like to see OpenID be a part of a generally improved user authentication and security story for D6. My "wipe open sessions on password-change" patch has already been committed (thanks!). Other changes I suggest:
1. Require (instead of request) a password change after one-time login (http://drupal.org/node/138805). I will finish up this patch and mark needs-review soon.
2. Add the Persistent Login (aka "Remember Me"; http://drupal.org/project/persistent_login) module to core. Persistent Login is *more secure* than long-life session cookies in addition to providing a better user experience. There are a couple non-security related issues for this module I will clean up.
3. Change the default PHP session cookie lifetime to 0 (browser lifetime only). Once Persistent Login is in place, the security risk and database overhead of long-life PHP sessions is no longer necessary.
Thoughts?
Thanks,
Barry
+1 to each of the above! Susan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN8mzvWyNbJGZcawRAjuJAJ4rnI6MfNMGw7sNpudkJ2K6hePMWQCfZwtR moKGBCMwCI2Tdxfa48Dszhs= =v699 -----END PGP SIGNATURE-----
Dries Buytaert wrote:
Hello world, there are two existing modules I'd like to see added to Drupal 6:
1. OpenID Adding OpenID to D6 core would be huge. Having D6 client and server would really open things up.
There are a couple of existing OpenID implementations for Drupal. The ones I'm aware of are http://drupal.org/project/openid and http://jirwin.net/. I believe the one hosted on drupal.org is running on planet-soc.com and delegation does not work. I know the jirwin.net version does properly handle delegation. The jirwin.net version requires the JanRain library, and I'm not sure about the drupal.org version. If any version gets in to D6 core, can I assume that it will not require an external lib? ~Rob -- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion
On 5/1/07, Robert Wohleb <rob@techsanctuary.com> wrote:
Dries Buytaert wrote:
Hello world, there are two existing modules I'd like to see added to Drupal 6:
1. OpenID Adding OpenID to D6 core would be huge. Having D6 client and server would really open things up.
There are a couple of existing OpenID implementations for Drupal. The ones I'm aware of are http://drupal.org/project/openid and http://jirwin.net/. I believe the one hosted on drupal.org is running on planet-soc.com and delegation does not work. I know the jirwin.net version does properly handle delegation.
The project on Drupal is the correct place. There is, I believe, some 6+ level code that still needs to be checked / attached as a patch.....that is the code that will lead us to the future, it won't rely on an external library, and it's actually OpenID 2.x and 1.x compliant. The 4.7-2 dev code does allow delegation. File issues, please :P -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
In addition to these modules i'd like to see token module's .inc file included into core. Haven't heard/read anything about this happening other than a quick chat to Eaton about the possibility. -- Sammy Spets Synerger Pty Ltd http://synerger.com On 01-May-07 13:44, Dries Buytaert wrote:
Hello world, there are two existing modules I'd like to see added to Drupal 6:
1. OpenID 2. Actions
I think both are important 'enablers' for many future things. I already talked to James (OpenID) and John Vandyck (Actions) and they are supporting the idea and willing to help make that happen.
Of course, I'd still like to see better image and forum handling in core too, but more about that later. (I believe webhick was working on some forum module improvements but I haven't checked with her yet.)
-- Dries Buytaert :: http://www.buytaert.net/
On 5/3/07, Sammy Spets <sammys-drupal@synerger.com> wrote:
In addition to these modules i'd like to see token module's .inc file included into core. Haven't heard/read anything about this happening other than a quick chat to Eaton about the possibility.
I can't speak to whether or not token should be included in core. I can only say that if it's not, it will quickly be the most downloaded contributed module. More and more modules are beginning to depend on token. Auto nodetitle, parts of ecommerce, custom breadcrumbs, and pathauto currently depend on it. Moshe has committed code to cvs that requires token into Organic Groups. I imagine other projects are seeing the benefit and will require it shortly. Personally the upgrade between Drupal versions (e.g. 5->6) is a time where I add in features that I've been meaning to add. I think that's pretty common and that between 5 and 6 more modules will start depending on token. There are few pieces of code (including core) that wouldn't benefit from using token. Based upon the January download data, 3 of the top 35 modules either currently rely on token or are in progress towards that. All of the modules that depend on token were downloaded 8,588 times in January. 8.588 downloads would put token at the top of the contrib module download list (beating views by 185). If I forecast a few modules that would benefit from token the number of downloads that would also require token quickly jumps to over 15,000 (project*, casetracker, signup, troll, subscriptions, notify, spam). For comparison, total downloads of the Drupal core tarball were 57,509. To be my own devil's advocate...if we use "number of downloads" as a motivation for which modules should be included in core, then views, tinymce, and cck are the top suspects in that order. */me shudders at tinymce* In terms of a path to core for token - I don't know what it would be, but there are actually several inc files in token. I believe eaton has ideas on how that could work if it were desirable and if we the idea were to merge it into an existing module instead of just including the module itself. And now I'm putting away my pivot tables... Regards, Greg
Just my small +1 for some/all of token module in core. This is easily one of the nicer innovations to have come from contrib recently. -Robert
On 5/3/07, Robert Douglass <rob@robshouse.net> wrote:
Just my small +1 for some/all of token module in core. This is easily one of the nicer innovations to have come from contrib recently.
A good start is looking at the places in core which use tokens already (e.g. the user registration / approval email). -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
On Thu, 3 May 2007 07:31:50 -0600, "Greg Knaddison - GVS" <Greg@GrowingVentureSolutions.com> wrote:
On 5/3/07, Sammy Spets <sammys-drupal@synerger.com> wrote:
In addition to these modules i'd like to see token module's .inc file included into core. Haven't heard/read anything about this happening other than a quick chat to Eaton about the possibility.
I can't speak to whether or not token should be included in core. I can only say that if it's not, it will quickly be the most downloaded contributed module.
More and more modules are beginning to depend on token. Auto nodetitle, parts of ecommerce, custom breadcrumbs, and pathauto currently depend on it. Moshe has committed code to cvs that requires token into Organic Groups. I imagine other projects are seeing the benefit and will require it shortly. Personally the upgrade between Drupal versions (e.g. 5->6) is a time where I add in features that I've been meaning to add. I think that's pretty common and that between 5 and 6 more modules will start depending on token. There are few pieces of code (including core) that wouldn't benefit from using token.
As soon as I posted UploadPath[1], the first question someone asked was "can this be in core?" Since it depends on token module, it currently can't. If token module moves into core, moving uploadpath's functionality into core should be fairly simple but a big boost to core's flexibility. [1] http://drupal.org/project/uploadpath --Larry Garfield
Including token.inc in core will allow me to migrate the mail template stuff I implemented in ecommerce to core as well for D6. For those that don't know anything about the mail templating in ecommerce, read on. We saw a need in ecommerce for a mail templating API/module making it possible to centralise the mail template storage, editing, token substitution and sending. I'll give you an example. In core now you have a welcome email that is sent to a user once their registration is complete. The system stores the subject and body of the mail in variables (a la variable_get/set() ). The changes I made means the variable table now only stores the mail template ID meaning a large downsize in variable loading and fantastic reusability when sending those mails from other modules. As this is about another topic i'll leave it there. Was a good time for me to introduce this to the list so people know my intent and to perhaps get some comments going in the forum post: http://drupal.org/node/141595 Cheers, -- Sammy Spets Synerger Pty Ltd http://synerger.com On 03-May-07 07:31, Greg Knaddison - GVS wrote:
On 5/3/07, Sammy Spets <sammys-drupal@synerger.com> wrote:
In addition to these modules i'd like to see token module's .inc file included into core. Haven't heard/read anything about this happening other than a quick chat to Eaton about the possibility.
I can't speak to whether or not token should be included in core. I can only say that if it's not, it will quickly be the most downloaded contributed module.
More and more modules are beginning to depend on token. Auto nodetitle, parts of ecommerce, custom breadcrumbs, and pathauto currently depend on it. Moshe has committed code to cvs that requires token into Organic Groups. I imagine other projects are seeing the benefit and will require it shortly. Personally the upgrade between Drupal versions (e.g. 5->6) is a time where I add in features that I've been meaning to add. I think that's pretty common and that between 5 and 6 more modules will start depending on token. There are few pieces of code (including core) that wouldn't benefit from using token.
Based upon the January download data, 3 of the top 35 modules either currently rely on token or are in progress towards that. All of the modules that depend on token were downloaded 8,588 times in January. 8.588 downloads would put token at the top of the contrib module download list (beating views by 185). If I forecast a few modules that would benefit from token the number of downloads that would also require token quickly jumps to over 15,000 (project*, casetracker, signup, troll, subscriptions, notify, spam). For comparison, total downloads of the Drupal core tarball were 57,509.
To be my own devil's advocate...if we use "number of downloads" as a motivation for which modules should be included in core, then views, tinymce, and cck are the top suspects in that order.
*/me shudders at tinymce*
In terms of a path to core for token - I don't know what it would be, but there are actually several inc files in token. I believe eaton has ideas on how that could work if it were desirable and if we the idea were to merge it into an existing module instead of just including the module itself.
And now I'm putting away my pivot tables...
Regards, Greg
participants (15)
-
Barry Jaspan -
Boris Mann -
Derek Wright -
Dries Buytaert -
fago -
Gabor Hojtsy -
Greg Knaddison - GVS -
Larry Garfield -
Moshe Weitzman -
Robert Douglass -
Robert Wohleb -
Sammy Spets -
Stefan Nagtegaal -
Susan Stewart -
Yves Chedemois