September 2005 - Development - lists.drupal.org

[drupal-devel] author your slides with Drupal next time
by Gabor Hojtsy 21 Sep '05

21 Sep '05

Hi, Last fall, Walkah announced an S5 module in the works (http://bryght.com/node/121) which was a proof of concept, but was never actually released as far as I know. I was way too excited about the possibilities, and given that my repeated requests resulted in no code from Walkah (due to the apparent reason of not enough time), I sat down this weekend, and put together a simple module for S5 authoring with the book module. The module is now in Drupal CVS (http://drupal.org/cvs?commit=19502) I know reusing books is still not the ideal solution for slide authoring, but since only book has an outline editor in Drupal, it was the quickest to use, and I am going to have a presentation on Drupal this weekend, so I only had this much time. I have ideas for futher improvements (actually either creating a better outline editor for books, or abandoning books). Here is the README reproduced for those interested: S5 Presentation Module Suite ---------------------------- The modules in this suite are supposed to help you author and play S5 presentations. S5 is Eric Meyer's "Simple Standards-Based Slide Show System", which is based on the Opera Show format. S5 presentations work in a multitude of browsers, and also compatible with Opera Show. http://www.meyerweb.com/eric/tools/s5/ Installation requirements ------------------------- - Modules in this folder are compatible with Drupal 4.7 - S5 itself is not included. You are required to copy the contents of the 'ui' folder from your S5 download to misc/s5. That means you should have files like misc/s5/default/slides.js The s5_book module ------------------ This module allows you to play book pages as S5 presentations. Enabling this module, you will get an 'S5 Presentation' link by the side of your 'docbook export' and 'opml export' links on your book pages. This flattens your book structure, so any hierarchies will be lost. You can use hierarchies however to structure your presentation properly. Since books only allow you to distinguish 30 different page weights, if you have more slides, you need to use hierarchies to maintain proper ordering. Group your slides by topic, and give your topics starter slides. The first slide is searched for metainformation about your slides, which is injected to further slides. An example first slide is the following: <h3 class="s5-author">Name of Author</h3> <h4 class="s5-company">Company of Author</h4>  As this example shows, you will have your name and company displayed on the slide (the slide and thus the presentation title will be the first node title). Since the presentation date and location information is in HTML comments, it will not be displayed. The s5-presdate value is supposed to be something like 20050920. For more detailed information on how these values should look like, look into the S5 documentation. Other slides should contain HTML like: <ul> <li>point one</li> <li>point two</li> <li>point three</li> </ul> See the S5 documentation on what else you can use on the slides, like handout text, images, incremental display, etc. Practical usage --------------- Authoring presentations with the book module might not be the ideal solution, since it does not allow you to easily add and remove slides. For this reason, s5_book module adds an 'add book page' link to the book outline editor (look into administer >> content >> books). This way, the outline editor allows you to quickly view, add and remove slides, as well as reorder them. Possible later modules ---------------------- Since authoring slides with the book module is still not the ideal way to look at slideshow editing, there are ideas on the future direction of supporting S5 authoring. When or whether these will be implemented at all is still an open question. Contact the maintainer, if you would like to join forces. Credits ------- Thanks to Eric Meyer for this fantastic slideshow system. The s5_book module and this readme was written by Gabor Hojtsy <goba(a)php.net>.

6 8

[drupal-devel] Drupal.org hardware
by Dries Buytaert 21 Sep '05

21 Sep '05

Hello world, - Thanks to Corey Shields (OSL) and Matt Rae (OSL), the two remaining Dell 1850's are in place; they are called 'drupal2' and 'drupal3' respectively, and are humming along in OSL's server room. We're already using 'drupal1' and 'drupaldb' (aka Sun-prise). - drupal2 will act as a second web node along side drupal1, the current web node. drupal2 will be put in production shortly. At that point, drupal1 will go down for a while as they have to rebuild the machine. We need to enable NFS, LDAP, and rebuild some stuff in 32-mode because some stuff doesn't behave in 64-bit mode. We won't be running with two front-end web nodes for another week or so. - OSL has put a gigabit switch for private networks in the same rack our servers are in. The second network interface will be plugged into the gigabit switch so we'll have a very fast private network between all of our machines. Given we're going to run stuff over NFS, this will be good. From a security point of view this is great too; as all data communication remains on our private network. - drupal3 is up and running and has all the software installed to host our mailing lists and CVS repositories. Credits go to Matt for installing everything. Next up, is migrating the mailing lists and CVS repositories from the old drupal.org server to the new drupal.org infrastructure. Kjartan is going to work on this in the near future. So far the status update. -- Dries Buytaert :: http://www.buytaert.net/

2 1

[drupal-devel] [bug] Remove drupal module from core
by robertDouglass 21 Sep '05

21 Sep '05

Issue status update for http://drupal.org/node/31716 Post a follow up: http://drupal.org/project/comments/add/31716 Project: Drupal Version: cvs Component: drupal.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: robertDouglass Status: patch (code needs review) The more I think about it, the more I conclude that Drupal.org should also drop dist. auth. support, or find better security solutions. Here's an example scenerio to provoke discussion. Gerhard always logs on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on two separate servers, and therefore probably have different security profiles. Now, just as conjecture, let us suppose that the server on which drop.org is run gets compromised and someone is able to steal Gerhard's password. They now have a big cat in the bag: drupal.org. They'd be able to become site/cvs admins for drupal.org, something which we probably don't want. In the end, if we have no way to say which sites can be trusted to do authentication, it is a bad idea allowing anyone to use this in conjunction with drupal.org. Another example: http://kerneltrap.org/user/2524 What if Jeremy's server were compromised (or perhaps Jeremy is just really evil and nobody knows ;-))? In either case, someone would be able to log into drupal.org with the UnConeD username - not a really attractive idea. PLEASE TELL ME I'M WRONG! Or remove the module. robertDouglass Previous comments: ------------------------------------------------------------------------ Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB) The drupal module does two things; it implements distributed authentication and it lets you run a "directory server". These sound great in the features list, but the implementation of both features is weak and poses the real risk of exposing Drupal users to identity theft. Here is an excerpt from my writings on the module: Distributed authentication Drupal distributed authentication is a way to save site users the extra steps of creating redundant accounts on multiple sites. (snip... we know how it works :-) There are some limitations and concerns about the current implementation of distributed authentication. It would be relatively easy for someone to alter the code of their site to save a record of the passwords of users who log in. This is true of any website you visit, Drupal or otherwise. As long as the username and password only buys access to that very site, there is little incentive to do this. If, however, it would allow the malicious person to log into other sites as well, in this case any Drupal site that has the drupal module enabled, the incentive is greater and the potential loss or damage greater. The attacker would be able to masquerade on those sites using your user identity and execute actions on your behalf. CAUTION Drupal's distributed authentication is inherently insecure. If you do not know that you can trust the owner(s) of a particular site, never use your distributed authentication (Drupal id) to log into it. Running a directory server The drupal module offers a simple service by which other Drupal sites can announce their existence, or "ping" a central server on a regular basis. While there are many possible applications of such a service, the most prominent use is the now defunct Drupal sites page on Drupal.org which was simply a long list of sites that run Drupal. In practice, any site that has the drupal module enabled can function as a directory server. When another site pings the site, the remote site's name, slogan and mission are added to the list of sites. A useful application of a directory server might be on a college or university where individual labs or departments are setting up many different Drupal sites. Each one could ping a central server at the university to compile a list of all the various sites as they spring up. In its current state, the service lacks some basic features. There is no way for the administrator to block a certain site from pinging and being added to the list. Nor is there a way to limit the incoming pings to a certain set of domains or IP addresses. The potential to make a truly useful directory server service exists, though, and anyone is encouraged to participate in discussions and development at Drupal.org. ----------------------- I've come to the conclusion that a module that is this weak should be offered as a contributed module, not as core. If it weren't in core, I wouldn't bother writing about it because it is too weak, and poses a real security threat. My recommendation is that it be placed in the contributions repository as an example of how distributed auth. for those enterprising individuals who might want to improve upon it. ------------------------------------------------------------------------ Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass tasks don't send mail? Setting to bug report.

2 1

[drupal-devel] [drupal-dev] testing one, two, three
by GravyFace 21 Sep '05

21 Sep '05

Is anyone getting this? Sorry for the spam but I'm getting "Your message to Infrastructure awaits moderator approval" due to a "suspicious header" for every message I send. a) not sure why my header is "suspicious" b) I'm not even signed up for the Infrastructure mailing list.

3 2

[drupal-devel] [bug] Remove drupal module from core
by Prometheus6 21 Sep '05

21 Sep '05

Issue status update for http://drupal.org/node/31716 Post a follow up: http://drupal.org/project/comments/add/31716 Project: Drupal Version: cvs Component: drupal.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: robertDouglass Updated by: Prometheus6 Status: patch (code needs review) Hm. Pubcookie requires SSL and (possibly worse) accurate system time. http://www.pubcookie.org/docs/install-mod_pubcookie.html#req Prometheus6 Previous comments: ------------------------------------------------------------------------ Tue, 20 Sep 2005 07:14:52 +0000 : robertDouglass Attachment: http://drupal.org/files/issues/drupalmod.patch (11.15 KB) The drupal module does two things; it implements distributed authentication and it lets you run a "directory server". These sound great in the features list, but the implementation of both features is weak and poses the real risk of exposing Drupal users to identity theft. Here is an excerpt from my writings on the module: Distributed authentication Drupal distributed authentication is a way to save site users the extra steps of creating redundant accounts on multiple sites. (snip... we know how it works :-) There are some limitations and concerns about the current implementation of distributed authentication. It would be relatively easy for someone to alter the code of their site to save a record of the passwords of users who log in. This is true of any website you visit, Drupal or otherwise. As long as the username and password only buys access to that very site, there is little incentive to do this. If, however, it would allow the malicious person to log into other sites as well, in this case any Drupal site that has the drupal module enabled, the incentive is greater and the potential loss or damage greater. The attacker would be able to masquerade on those sites using your user identity and execute actions on your behalf. CAUTION Drupal's distributed authentication is inherently insecure. If you do not know that you can trust the owner(s) of a particular site, never use your distributed authentication (Drupal id) to log into it. Running a directory server The drupal module offers a simple service by which other Drupal sites can announce their existence, or "ping" a central server on a regular basis. While there are many possible applications of such a service, the most prominent use is the now defunct Drupal sites page on Drupal.org which was simply a long list of sites that run Drupal. In practice, any site that has the drupal module enabled can function as a directory server. When another site pings the site, the remote site's name, slogan and mission are added to the list of sites. A useful application of a directory server might be on a college or university where individual labs or departments are setting up many different Drupal sites. Each one could ping a central server at the university to compile a list of all the various sites as they spring up. In its current state, the service lacks some basic features. There is no way for the administrator to block a certain site from pinging and being added to the list. Nor is there a way to limit the incoming pings to a certain set of domains or IP addresses. The potential to make a truly useful directory server service exists, though, and anyone is encouraged to participate in discussions and development at Drupal.org. ----------------------- I've come to the conclusion that a module that is this weak should be offered as a contributed module, not as core. If it weren't in core, I wouldn't bother writing about it because it is too weak, and poses a real security threat. My recommendation is that it be placed in the contributions repository as an example of how distributed auth. for those enterprising individuals who might want to improve upon it. ------------------------------------------------------------------------ Tue, 20 Sep 2005 10:19:32 +0000 : robertDouglass tasks don't send mail? Setting to bug report. ------------------------------------------------------------------------ Tue, 20 Sep 2005 10:30:42 +0000 : robertDouglass The more I think about it, the more I conclude that Drupal.org should also drop dist. auth. support, or find better security solutions. Here's an example scenerio to provoke discussion. Gerhard always logs on to drupal.org as killes(a)www.drop.org. AFAIK, these sites are now on two separate servers, and therefore probably have different security profiles. Now, just as conjecture, let us suppose that the server on which drop.org is run gets compromised and someone is able to steal Gerhard's password. They now have a big cat in the bag: drupal.org. They'd be able to become site/cvs admins for drupal.org, something which we probably don't want. In the end, if we have no way to say which sites can be trusted to do authentication, it is a bad idea allowing anyone to use this in conjunction with drupal.org. Another example: http://kerneltrap.org/user/2524 What if Jeremy's server were compromised (or perhaps Jeremy is just really evil and nobody knows ;-))? In either case, someone would be able to log into drupal.org with the UnConeD username - not a really attractive idea. PLEASE TELL ME I'M WRONG! Or remove the module. ------------------------------------------------------------------------ Tue, 20 Sep 2005 11:17:00 +0000 : eldarin Robert, you make perfect sense. ;-) Other servers could get compromised like you point out, and that could let someone take control of drupal.org if a siteadmin used the compromised site with the same account login. This could especially be true if a site used an earlier Drupal version. And it's not only current sites using this, but future sites and possible future modules which can be used to compromise security. Someone could offer my-cool-module.module and distribute it through some other forums, thereby getting some backdoor access. Using the distributed login feature, they could behave like a worm. Ultimately, it's up to the users to show good thinking and NOT use the same username or password everywhere .. but that is difficult to demand. Scenario example: two websites have siteadmins which know each other well (or same person), and same person registers on both sites. If the password is very similar or a pattern can be discerned and if that person is a drupal.org siteadmin, the possibility exists that drupal.org still could get compromised. There is no way to be foolproof, but helping users along doesn't hurt. ;-) ------------------------------------------------------------------------ Tue, 20 Sep 2005 11:34:07 +0000 : chx I agree. I have looked around for better solutions and pubcookies looks good. (Google on it. I do not have too much too time to write about it.) ------------------------------------------------------------------------ Tue, 20 Sep 2005 13:53:36 +0000 : gravyface Of course, this assumes that Gerhard uses a different username and password combination for every site, which most people don't; if not, you wouldn't need to exploit the distributed authentication to get this to work -- you could take the average user's account and not only log into other Drupal sites but into Hotmail, gmail, Paypal, eBay, etc. I agree with Robert; I think that this should be removed from the core. Single Sign-on (SSO) [1] is not an easy thing to tackle and outside of a controlled, private network, it may not even be desired. Look at Microsoft's Passport failure [2] as an example; the largest software company in the world could not get this to work and apparently, nobody wanted it either. [1] http://en.wikipedia.org/wiki/Single_sign_on [2] http://yro.slashdot.org/article.pl?sid=04/12/31/1416212&tid=109&tid=158&tid… ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:04:36 +0000 : kbahey For me, I never liked distributed authentication, be it from Microsoft Passport or from Drupal or anyone else. The point here is that you are trusting others to do security for you. Those others can be malicious, or can be slack in their security, or they got get hacked by someone else. So, for me, this is something that I will likely never use, whether it stays in core or not. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:10:13 +0000 : m3avrck I agree with all said points. I never had used drupal.module and never plan to. Great idea in concept, but in reality, just doesn't work. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:15:45 +0000 : Kobus I agree with the posts before, but will this influence the drupal-sites functionality? I have a few old Drupal 4.2 sites utilizing this feature to list themselves on the drupal-sites page. Regards, Kobus ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:30:37 +0000 : Bèr Kessels 1Though potetially insecure, iSSO is one of the best features in drupal. I'd rather notsee this end in the null bin, for it will then be lost. forever. What about a revive/rewrite? Here are my thoughts: case: drop.org user 'foo' log into Drupal drupal.org pings drop.org. Drop.org retruns TRUE if the pinged details are correct. foo(a)drop.org is NOT a user nor gets a uid on drupal.org. never! For as long as the session takes, he is a 'registered' user. if foo(a)drop.org visits 'my account' and changes anything in there, he gets a uid, welcome mail and a native drupal.org user. That has, from then on, nothing to do with drop.org, drop.org will never be pinged anymore. Off course one is required to fill in a new password and an email addy. if foo(a)drop.org never visits 'my account', or does not change anything in there, the user 'foo(a)drop.org' will be lost as soon as the session terminates. drupal.org user with a lot of rights 'foo' logs into drop.org drupal.org will send TRUE when it receives correct login details. foo(a)drupal.org is NOT a user nor gets a uid on drop.org. never! For as long as the session takes, he is a 'registered' user. but drop.org knows nothing, nor saves anything on drop.org. only packet sniffers can track the user details; This is very much how it works now, with one difference: you have to actively undertake something to me changed from remote user to native user. You have to actively undertake something to get yuour details in the database of the other site. This, Icw some common sense (Dries should be aware that he must not use his drupalID on WannaHackdrupal.pr0nnet.ro) thiswill do, IMO. First rule of securit is clarity: if your users see and feel what happens, your security is much better maintainable. This is not really the case ATM. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:31:40 +0000 : killes(a)www.drop.org I am using my username only for historical reasons. drop.org is down and I've not been using distributed auth for quite a while. I agree that drupal.module's distributed auth isn't up to date any more and people shoudl be discouraged from using it. ------------------------------------------------------------------------ Tue, 20 Sep 2005 14:55:44 +0000 : Prometheus6 The module would be useful if the side that does the authentication had a list of trusted sites. That would let you have single sign-on across a range of related sites. But that still means it's more appropriately a contribution module. ------------------------------------------------------------------------ Tue, 20 Sep 2005 15:52:16 +0000 : Peter Apockotos I like the idea of the module. I just wish it wasn't tied to drupal.org itself. Perhaps a setting of which (trusted) sites to share the information with instead. ------------------------------------------------------------------------ Tue, 20 Sep 2005 16:20:59 +0000 : nedjo Thanks for bringing this issue up, Robert. See for reference the related issue "Refactor and rename drupal module", http://drupal.org/node/29826 The near consensus I'm hearing is: 1. The functionality areas covered in the drupal.module are valuable and desired. 2. But the current implementation has serious flaws, and therefore fails to meet clearly the standards for drupal core inclusion. There are probably three basic options: 1. Keep the module in core, with the commitment to fixing its flaws. 2. Temporarily (e.g,. for one release cycle) pull the module from core with the aim of refining it enough for reinclusion. 3. Remove the module from core to contributions. While I agree with the serious limitations of the current implementation, I'd hate to see this functionality area disappear from core. Projects pulled from core tend to languish. So I favour options one or - perhaps better - two. Inter-site functionality similar to what is covered in drupal.module is in increasing demand. Projects like the telecentre.org initiative centre on such functionality. CivicSpace has expressed keen interest in improving the ability of webs of related sites to discover each other, connect, and pool information. Look again at our mission, http://drupal.org/node/10250. Inter-site connections are increasingly key to "the collaborative production of online information systems and communities". Let's focus on fixing the module! ------------------------------------------------------------------------ Tue, 20 Sep 2005 17:28:34 +0000 : javanaut Just contributing some links to the discussion here. There was previous discussion on distributed auth here: http://drupal.org/node/19113 Parts of this discussion fed what became OpenID: http://openid.net/ There's a PHP implementation of OpenID here (I've never used this, though): http://www.videntity.org/openid If somebody had time/motivation to develop an auth module that used this, I think it would bode well for Drupal, whether core or contrib. It's primary benefit is that you need not trust the site that you're logging in to, just your main server. You never enter your password into a non-trusted site. ------------------------------------------------------------------------ Tue, 20 Sep 2005 19:23:47 +0000 : Boris Mann Both CivicSpace (Kieran, I think we agreed on this) and Bryght are commited to developing distributed authentication functionality. We would love if something shipped by default with Drupal core. OpenID is my current best bet, although as chx pointed out, Pubcookie looks excellent for the more corporate market. My proposal would be to make drupal auth an OpenID compliant server, and to make the "base" dist auth have the proper trust relationships/security that people could be confident in using it in most standard security situations. The current "drupal" module would actually become more of a container for dist auth in general, as it has been in the past. One of it's functions might be (for example) mapping remote information to local, as we implemented for the SXIP module.

3 2

[drupal-devel] [feature] profile.module:
by Peter Apockotos 21 Sep '05

21 Sep '05

Issue status update for http://drupal.org/node/2694 Post a follow up: http://drupal.org/project/comments/add/2694 Project: Drupal -Version: <none> +Version: 4.6.3 Component: profile.module Category: feature requests Priority: minor Assigned to: Anonymous Reported by: Anonymous Updated by: Peter Apockotos Status: fixed I have these fields setup in my profile fields. but is there a way to code the fields so that when clicked on it will launch the clients IM client to contact that user? Peter Apockotos Previous comments: ------------------------------------------------------------------------ Sun, 31 Aug 2003 09:17:01 +0000 : Anonymous It could be great that in profile you could specify your Jabber ID (as you can specify your ICQ, MSN, Yahoo or AIM messenger ID). Thanks. ------------------------------------------------------------------------ Wed, 27 Jul 2005 04:36:40 +0000 : Eric Scouten Fixed long ago. Current profile module allows admin-defined additional fields.

1 0

[drupal-devel] [feature] URL rewrite hook
by chx 21 Sep '05

21 Sep '05

Issue status update for http://drupal.org/node/29030 Post a follow up: http://drupal.org/project/comments/add/29030 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch (code needs review) Attachment: http://drupal.org/files/issues/url_rewrite.patch (1.35 KB) I need a URL rewrite hook sometimes, here is an implementation, with ample comments. I looked into arg() to see whether it needs a reset parameter, and it does not, but it contained a minor bug, which is also fixed. chx

12 55

Re: [drupal-devel] Fwd: OpenUsability Project Approved
by Bèr Kessels 21 Sep '05

21 Sep '05

Ive put all the tasks online on openusability (and frankly am quit impressed with the usability of their project/task manager :p) http://openusability.org/pm/task.php?group_project_id=9&group_id=139&func=b… For as long as it takes. I think we should take a while to think of how to get all this on drupal.org. Op dinsdag 20 september 2005 18:25, schreef Dries Buytaert: > On 19 Sep 2005, at 20:04, Bèr Kessels wrote: > > I will try to get all this onto a public taks/todo list ASAP. > > sounds like there is enough work to be done :) > > I don't really care where the tasks are put but we have to put them > somewhere, as well as define the process of getting involved. Then, > we need to market these efforts using a forum topic that can be > promoted to the front page. Making a public list of the action > points and preleminirary results is step #1. If we don't get this/us > organized, little will happen. So, make sure to coordinate with > Kieran and to keep the community up to date. > > -- > Dries Buytaert :: http://www.buytaert.net/ Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

1 0

[drupal-devel] Beginner using Tortoise CVS seeks help!
by Joel Guesclin 21 Sep '05

21 Sep '05

This is the very first time I've tried to contribute to Drupal, or use a CVS of any description, or use this list, so please bear with me if I am making mistakes or asking idiot questions. I would also like to start by saying how much I appreciate the Drupal community and all the help I've had over many months - which is why I would like to make a very modest contribution of my own. I've managed to install Tortoise CVS and after a bit of messing about succeeded in doing a "checkout", which I think uses the same commands as those in the Drupal instructions. I've also successfully created a new directory in the list of modules called "checkout" (confusingly, this is actually the name of the module I want to contribute). So I have made a start. However, there are some first questions I would like to ask: 1) My success with Tortoise so far has downloaded to my workstation what looks like the ENTIRE Drupal CVS. Apparently I could update anything in this - that makes me very nervous that I might mess up someone else's work, or Drupal core worse still. Is there any way to avoid this? 2) Do I need to keep all these directories on my workstation for the CVS to work? 3) Is there anywhere some documentation for helping a Tortoise user with Drupal to get started? 4) I seem to have managed to create a "Checkout" module (tomorrow I will try to create the project under Drupal) in the CVS, with all the appropriate files - not sure that I understand tagging and branching yet, so will have to see if it works. But every time I load a file to the CVS server I get this message in the Tortoise window: initial revision: 1.1 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Do I need to worry about this? Many thanks to all, and again my apologies if I'm wasting your time. JG ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

5 4

[drupal-devel] [feature] storage table
by chx 21 Sep '05

21 Sep '05

Issue status update for http://drupal.org/node/31811 Post a follow up: http://drupal.org/project/comments/add/31811 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch (code needs review) Attachment: http://drupal.org/files/issues/storage.patch (1.93 KB) Talk is silver, code is gold, so instead of talking about http://drupal.org/node/31801 , let's look at some code. Untested patch and needs a simple DB script, too. chx

3 3