From dries.buytaert at gmail.com Sun Feb 1 09:53:32 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sun, 1 Feb 2009 10:53:32 +0100 Subject: [development] Fields in core patch Message-ID: <61bca48a0902010153m4304a9b3s9be4e2ca27f6e24e@mail.gmail.com> Hello all, I will commit the initial Fields in Core patch for D7 (http://drupal.org/node/361683) on Tuesday at 5pm CET (11am EST). Read: two days left, act now ... -- Dries Buytaert :: http://buytaert.net/ From news at unleashedmind.com Sun Feb 1 17:17:07 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Sun, 1 Feb 2009 18:17:07 +0100 Subject: [development] Remove top-level admin menu items Message-ID: <006401c98490$e9234690$0200a8c0@structworks.com> This goes out to some maintainers, specifically related to - Notifications / Messaging - Organic Groups - Panels Those and related/dependent modules are implementing top-level menu items, e.g. - admin/messaging - admin/og - admin/panels in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. If the only thing that prevents this from changing are patches, then I'll happily submit some. Thanks, Daniel [1] http://drupal.org/node/366489 From wdlists at optonline.net Sun Feb 1 17:31:44 2009 From: wdlists at optonline.net (Walt Daniels) Date: Sun, 01 Feb 2009 12:31:44 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <006401c98490$e9234690$0200a8c0@structworks.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: <4B7EC3688D334881934A3396232A4C46@Squirt> +100 on these comments There are many other modules that are badly classified making them hard to find. Every maintainer should take a quick look at where their modules wind up and fix them. After all it is in your best interest. If they can't be found they won't be used. -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org] On Behalf Of Daniel F. Kudwien Sent: Sunday, February 01, 2009 12:17 PM To: development at drupal.org Subject: [development] Remove top-level admin menu items This goes out to some maintainers, specifically related to - Notifications / Messaging - Organic Groups - Panels Those and related/dependent modules are implementing top-level menu items, e.g. - admin/messaging - admin/og - admin/panels in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. If the only thing that prevents this from changing are patches, then I'll happily submit some. Thanks, Daniel [1] http://drupal.org/node/366489 From tomi at vacilando.org Sun Feb 1 18:45:22 2009 From: tomi at vacilando.org (=?UTF-8?B?VG9tw6HFoSBGw7xsw7ZwcCAodmFjaWxhbmRvLm9yZyk=?=) Date: Sun, 1 Feb 2009 19:45:22 +0100 Subject: [development] Weird D5-D6 upgrade accident - need for taxonomy ninja feedback Message-ID: <593475f90902011045o226bef66y71a0d7f7a70e032a@mail.gmail.com> Hi, I'd hate to bump an issue via this list but I am stuck in what was to be a straightforward upgrade and my critical issue at http://drupal.org/node/365664 * has not received any reply for a number of days * might point to a generic problem people encounter when upgrading from D5 to D6 * does not seem to be answered by any post in the upgrade or other forums (or I haven't found one) Basically, after upgrade the ID of the Forum's vocabulary has, for mysterious reasons, changed... and the new ID has no terms in it, which means the Forum is empty and all issues that were posted in the D5 version are stranded in limbo. Why did this happen in the first place? / Can it happen to others? And how to fix it? It probably won't take more than 3 minutes of attention for a Drupal taxonomy (or upgrade?) ninja. Thanks! Tom?? PS: For your convenience, here's a copy of what I posted in the above issue, but please answer via the above post (http://drupal.org/node/365664) (if your answer does not benefit the development thread). *I've upgraded from 5.15 to 6.9 but there is nothing in my forum. I've found out that the vocabulary containing forum categories is there, but it is NOT ATTACHED to the vocabulary of the upgraded D6 forum! Practically, my D5 vocabulary had name 'Forum' and ID 1 and it is still there in D6, but in D6 the forum is using newly created vocabulary (also called 'Forum') with ID 15! As result the /forum shows nothing and all our old forum messages are still there, but because they are tagged in the old forum, they do not show anywhere. Why did this happen - anybody knows? And how to rectify it... I guess all that could help would be a way to assign vocabulary 1 to the forum in D6 -- but how to do this? Please help... * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090201/a05867a8/attachment.htm From dragonwize at gmail.com Sun Feb 1 18:58:08 2009 From: dragonwize at gmail.com (dragonwize) Date: Sun, 1 Feb 2009 13:58:08 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <006401c98490$e9234690$0200a8c0@structworks.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: 100% Agreed. Another module I would lump into this category is Embedded Media Field. EMF has its configuration under Content Management when it is clearly entirely configuration. So much so that the menu link item is actually named "Embedded Media Field configuration". -- Alan On Sun, Feb 1, 2009 at 12:17, Daniel F. Kudwien wrote: > This goes out to some maintainers, specifically related to > > - Notifications / Messaging > - Organic Groups > - Panels > > Those and related/dependent modules are implementing top-level menu items, e.g. > > - admin/messaging > - admin/og > - admin/panels > > in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. > > I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". > > In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". > > Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. > > If the only thing that prevents this from changing are patches, then I'll happily submit some. > > > Thanks, > Daniel > > [1] http://drupal.org/node/366489 > > From mroswell at gmail.com Sun Feb 1 19:15:17 2009 From: mroswell at gmail.com (Margie Roswell) Date: Sun, 1 Feb 2009 14:15:17 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: References: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: What to do when the Admin menu gets too long under configuration? Small fonts of course, one option, but these bespectacled eyes have a tough time seeing them. Margie On Sun, Feb 1, 2009 at 1:58 PM, dragonwize wrote: > 100% Agreed. Another module I would lump into this category is > Embedded Media Field. EMF has its configuration under Content > Management when it is clearly entirely configuration. So much so that > the menu link item is actually named "Embedded Media Field > configuration". > > -- > Alan > > > On Sun, Feb 1, 2009 at 12:17, Daniel F. Kudwien wrote: >> This goes out to some maintainers, specifically related to >> >> - Notifications / Messaging >> - Organic Groups >> - Panels >> >> Those and related/dependent modules are implementing top-level menu items, e.g. >> >> - admin/messaging >> - admin/og >> - admin/panels >> >> in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. >> >> I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". >> >> In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". >> >> Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. >> >> If the only thing that prevents this from changing are patches, then I'll happily submit some. >> >> >> Thanks, >> Daniel >> >> [1] http://drupal.org/node/366489 >> >> > From nan_wich at bellsouth.net Mon Feb 2 00:12:02 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sun, 1 Feb 2009 19:12:02 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: I don't think this applies to any of the modules I maintain, but if you open an issue on mine, I will definitely consider it. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 0 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090201/4f2d2354/attachment.bin -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.16/1928 - Release Date: 1/31/2009 8:03 PM From merlin at logrus.com Mon Feb 2 04:19:53 2009 From: merlin at logrus.com (Earl Miles) Date: Sun, 01 Feb 2009 20:19:53 -0800 Subject: [development] Remove top-level admin menu items In-Reply-To: <006401c98490$e9234690$0200a8c0@structworks.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: <49867469.7090807@logrus.com> Daniel F. Kudwien wrote: > This goes out to some maintainers, specifically related to > > - Notifications / Messaging - Organic Groups - Panels > > Those and related/dependent modules are implementing top-level menu > items, e.g. > > - admin/messaging - admin/og - admin/panels > > in the style of Drupal 4.7, instead of using the new administrative > categories and structure we have since Drupal 5.x. This is not only > confusing, but also clutters the administrative interface - > especially, if Administration menu module is installed. I, uh, actually am kind of offended at this line, because I actually did most of the work on the patch to create the new admin system and set it up in this manner. Opening with this actually made me inclined to just ignore the thread entirely but because of who you are, you get an answer anyway. But sincerely, this is *not* in the style of 4.7: 1) Panels implements everything necessary to have a block in the new admin system, including the descriptions and functions below it. 2) Panels has several administrative options that, in the normal system, would be kind of scattered and difficult to find. I know this because I originally had set things up that way, and it was frustrating. 3) Panels has a modular nature and keeps getting items added, which would be even more frustrating. 4) Keeping things together would force Panels down to admin/site-building/panels/* -- 4 levels down before it actually gets any information in the URL for itself leaves only 3 more path items before you hit the argument limits in the menu system. And worse, you now have an extra click needed to get to every Panels item, relegating it to a second class administrative system. > I see no reason why it needs to be this way. Clearly, for example, > Organic Groups and Panels are both tools to build a Drupal site -- > the proper location would thus be below "Site building". I see no reason why admin_menu can't just cope with this the same way the menu system does. From dragonwize at gmail.com Mon Feb 2 05:58:13 2009 From: dragonwize at gmail.com (dragonwize) Date: Mon, 2 Feb 2009 00:58:13 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <49867469.7090807@logrus.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> <49867469.7090807@logrus.com> Message-ID: To me the true nature of Daniel's request is not really about admin_menu. The placement of menu items affects all of our sites. Because of this we need some kind of standard that we can hold modules to. Because of our great menu system we can choose to move menu items to where we would personally like them on our own site. However, we still need to hold the default position to some kind of standard. If the only reason for moving to the higher level is personal preference of how may levels you have to go then it should be placed by default in the standard configuration and can be moved by all those that use it enough that they would like it at a higher level. The argument limit could be an issue, maybe we need to consider upping that limit. But I think that the vast majority of modules do not have non-dynamic argument handling that would prevent the menu item from functioning when moved. -- Alan > I, uh, actually am kind of offended at this line, because I actually did > most of the work on the patch to create the new admin system and set it up > in this manner. Opening with this actually made me inclined to just ignore > the thread entirely but because of who you are, you get an answer anyway. > But sincerely, this is *not* in the style of 4.7: > 1) Panels implements everything necessary to have a block in the new > admin system, including the descriptions and functions below it. > 2) Panels has several administrative options that, in the normal system, > would be kind of scattered and difficult to find. I know this because > I originally had set things up that way, and it was frustrating. > 3) Panels has a modular nature and keeps getting items added, which > would be even more frustrating. > 4) Keeping things together would force Panels down to > admin/site-building/panels/* -- 4 levels down before it actually > gets any information in the URL for itself leaves only 3 more path > items before you hit the argument limits in the menu system. And > worse, you now have an extra click needed to get to every Panels > item, relegating it to a second class administrative system. From merlin at logrus.com Mon Feb 2 06:13:17 2009 From: merlin at logrus.com (Earl Miles) Date: Sun, 01 Feb 2009 22:13:17 -0800 Subject: [development] Remove top-level admin menu items In-Reply-To: References: <006401c98490$e9234690$0200a8c0@structworks.com> <49867469.7090807@logrus.com> Message-ID: <49868EFD.70503@logrus.com> dragonwize wrote: > To me the true nature of Daniel's request is not really about > admin_menu. The placement of menu items affects all of our sites. > Because of this we need some kind of standard that we can hold modules > to. > > Because of our great menu system we can choose to move menu items to > where we would personally like them on our own site. However, we still > need to hold the default position to some kind of standard. I honestly felt like I established and held to some kind of standard with this system. > If the only reason for moving to the higher level is personal > preference of how may levels you have to go then it should be placed > by default in the standard configuration and can be moved by all those > that use it enough that they would like it at a higher level. If the only reason for disliking my choices of administration, you're also welcome not to use the module. I gave several reasons why it is the way it is, and it wasn't personal preference. From dragonwize at gmail.com Mon Feb 2 07:15:03 2009 From: dragonwize at gmail.com (dragonwize) Date: Mon, 2 Feb 2009 02:15:03 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <49868EFD.70503@logrus.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> <49867469.7090807@logrus.com> <49868EFD.70503@logrus.com> Message-ID: Earl, I was trying to be amenable but I failed horribly. I am sorry for that. My statements were never directed at you but at the conversation in general. If Panels is the exception for valid reasons, than I am perfectly ok with that. There is rarely a standard that doesn't have a few exceptions. You a good developer and by the fact that you have other modules including Views which do not break with the norm I would say you probably have very good reasons for doing so. However, many modules do not give it such thought and I believe that is where the meat of this thread lies. -- Alan On Mon, Feb 2, 2009 at 01:13, Earl Miles wrote: > dragonwize wrote: >> >> To me the true nature of Daniel's request is not really about >> admin_menu. The placement of menu items affects all of our sites. >> Because of this we need some kind of standard that we can hold modules >> to. >> >> Because of our great menu system we can choose to move menu items to >> where we would personally like them on our own site. However, we still >> need to hold the default position to some kind of standard. > > I honestly felt like I established and held to some kind of standard with > this system. > >> If the only reason for moving to the higher level is personal >> preference of how may levels you have to go then it should be placed >> by default in the standard configuration and can be moved by all those >> that use it enough that they would like it at a higher level. > > If the only reason for disliking my choices of administration, you're also > welcome not to use the module. I gave several reasons why it is the way it > is, and it wasn't personal preference. > > From catch56 at googlemail.com Mon Feb 2 10:42:27 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 2 Feb 2009 10:42:27 +0000 Subject: [development] Remove top-level admin menu items In-Reply-To: References: <006401c98490$e9234690$0200a8c0@structworks.com> <49867469.7090807@logrus.com> <49868EFD.70503@logrus.com> Message-ID: It's not related to contributed modules so much, but I'd actually like to see us have more top level admin sections rather than less - the current split between content, building, reports, users and configuration doesn't really work out in practice. Several core menu items are mis-placed - 'post settings' in content, and simpletest in site building, for example. So while there may well be contrib modules which are abusing this (and I definitely think panels /doesn't/ abuse it), core could do a lot better to provide homes for some of these menu items. See http://drupal.org/node/228236 for the core issue dealing with this. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090202/6e54e2b1/attachment.htm From earnie at users.sourceforge.net Mon Feb 2 13:54:13 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 02 Feb 2009 08:54:13 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <4B7EC3688D334881934A3396232A4C46@Squirt> References: <006401c98490$e9234690$0200a8c0@structworks.com> <4B7EC3688D334881934A3396232A4C46@Squirt> Message-ID: <20090202085413.e24uyhjyrxj4swg8@mail.progw.org> Quoting Walt Daniels : > +100 on these comments > > There are many other modules that are badly classified making them hard to > find. Every maintainer should take a quick look at where their modules wind > up and fix them. After all it is in your best interest. If they can't be > found they won't be used. > And if you find one that is annoying open a bug issue in the issue queue of the project. I usually prefer the admin/by-module UI if I'm concerned with administration of one particular module. I also create an Administration menu and rearrange the menu items to my liking. So, regardless of who does what, I use the dynamic menu to suit my needs. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From wdlists at optonline.net Mon Feb 2 15:23:51 2009 From: wdlists at optonline.net (Walt Daniels) Date: Mon, 02 Feb 2009 10:23:51 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <20090202085413.e24uyhjyrxj4swg8@mail.progw.org> References: <006401c98490$e9234690$0200a8c0@structworks.com> <4B7EC3688D334881934A3396232A4C46@Squirt> <20090202085413.e24uyhjyrxj4swg8@mail.progw.org> Message-ID: <2C29486FF30F462CBEB84876FFBE963C@Squirt> This brings up a related issue, namely translating the name you see on the module screen to the module name and the project name. Pet peave, a module whose purpose is to add a new field type to CCK but doesn't have CCK in its name and doesn't come up in the group of CCK stuff on the Update status screen. -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org] On Behalf Of Earnie Boyd Sent: Monday, February 02, 2009 8:54 AM To: development at drupal.org Subject: Re: [development] Remove top-level admin menu items Quoting Walt Daniels : > +100 on these comments > > There are many other modules that are badly classified making them hard to > find. Every maintainer should take a quick look at where their modules wind > up and fix them. After all it is in your best interest. If they can't be > found they won't be used. > And if you find one that is annoying open a bug issue in the issue queue of the project. I usually prefer the admin/by-module UI if I'm concerned with administration of one particular module. I also create an Administration menu and rearrange the menu items to my liking. So, regardless of who does what, I use the dynamic menu to suit my needs. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From drupal at reyero.net Mon Feb 2 17:35:52 2009 From: drupal at reyero.net (Jose A. Reyero) Date: Mon, 02 Feb 2009 18:35:52 +0100 Subject: [development] Remove top-level admin menu items In-Reply-To: <006401c98490$e9234690$0200a8c0@structworks.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: <49872EF8.8030808@reyero.net> I strongly disagree with this proposal because: (And btw I'm the maintainer of Messaging and Notifications mentioned below) 1. For complex packages, scattered pages around the admin interface really make it difficult for users to grasp the whole set of options sometimes needed to set them up. 2. The 'per module' option is no replacement for some grouping as this is a 'code oriented' concept but not a user friendly one at all. In this case, Messaging & Notifications can be a dozen modules, this won't help at all. So, unless we have in D7 some 'Per package' tab for the admin UI, that would make more sense from a usability perspective than the 'per module' idea, I'm afraid these modules' admin UI will stay the same. That said, I think guidelines are fine, so if you want to set up this one as a guideline and find some consensus, ok. But enforcing guidelines upon module maintainers, when they think they have a specific reason to skip this one or this other guideline is bad (and mostly a waste of time). So thanks for the heads up, I appreciate it, but really the reasons to keep the admin menu as it is are stated on the issue, which I'm afraid will stay as 'won't fix'... It is here, btw, http://drupal.org/node/366489 (not that I want to spend more time on this one) Jose Daniel F. Kudwien wrote: > This goes out to some maintainers, specifically related to > > - Notifications / Messaging > - Organic Groups > - Panels > > Those and related/dependent modules are implementing top-level menu items, e.g. > > - admin/messaging > - admin/og > - admin/panels > > in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. > > I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". > > In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". > > Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. > > If the only thing that prevents this from changing are patches, then I'll happily submit some. > > > Thanks, > Daniel > > [1] http://drupal.org/node/366489 > > > From gabor at hojtsy.hu Mon Feb 2 17:50:25 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Mon, 2 Feb 2009 18:50:25 +0100 Subject: [development] Remove top-level admin menu items In-Reply-To: <006401c98490$e9234690$0200a8c0@structworks.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> Message-ID: <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> On Sun, Feb 1, 2009 at 6:17 PM, Daniel F. Kudwien wrote: > This goes out to some maintainers, specifically related to > > - Notifications / Messaging > - Organic Groups > - Panels > > Those and related/dependent modules are implementing top-level menu items, e.g. > > - admin/messaging > - admin/og > - admin/panels > > in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. Although my fine module was not mentioned here, l10n_server does this same thing, so I am kind of feel like called out :) Others from Panels and Notifications/Messaging provided their opinion, so I'd not chip in, if I'd say the same. But maybe I am saying the same. For the l10n_server case, the separate high level item makes sense, since the l10n_server is a kind of standalone software. It does not help you track users, enter content, vote on content or whatever, but in a sense it does all of these. it has a highly specialized storage and UI system for translation editing and reuses Drupal capabilities to set up users, languages, organic groups, panels, blocks, whatever around itself. The module in itself is not related to site building, configuration, users or reports. It is merely a "high level tool" on your site you'd use. Now that I said it, I might have said the same things as others said on Panels and Notifications/Messaging, maybe in a more general way. And yes, I am an admin_menu user. I was the guy, who pushed it to be used on d6.drupal.org last week :) And yes, I appreciate high level tools highlighted on the highest level in my admin_menu. And yes, I understand that Panels, or Notifications/Messaging or l10n_server might not have the highest importance to people *once* they set up everything, and would instead only focus on core site management such as user, content and logs. G?bor From kb at 2bits.com Mon Feb 2 18:02:11 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Mon, 2 Feb 2009 13:02:11 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> Message-ID: <4a9fdc630902021002m2b0c4bcdr138500014ae61268@mail.gmail.com> On Mon, Feb 2, 2009 at 12:50 PM, G?bor Hojtsy wrote: > On Sun, Feb 1, 2009 at 6:17 PM, Daniel F. Kudwien > wrote: > > This goes out to some maintainers, specifically related to > > > > - Notifications / Messaging > > - Organic Groups > > - Panels > > > > Those and related/dependent modules are implementing top-level menu > items, e.g. > > > > - admin/messaging > > - admin/og > > - admin/panels > > > Here is an idea. Perhaps what we need is admin/applications/ above all the modules that do not readily fit under the rest of the existing hierarchy (Content, Build, Settings, ...). - admin/applications/messaging - admin/applications/og - admin/applications/panels i18n would not fit under there, but it could have a "Languages" heading with others going under it. - admin/languages/i18n - admin/languages/locale - admin/languages/translation This would solve the issue for admin_menu, and also the clutter. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090202/be07528f/attachment.htm From Greg at GrowingVentureSolutions.com Mon Feb 2 18:07:19 2009 From: Greg at GrowingVentureSolutions.com (Greg Knaddison) Date: Mon, 2 Feb 2009 11:07:19 -0700 Subject: [development] Remove top-level admin menu items In-Reply-To: <49872EF8.8030808@reyero.net> References: <006401c98490$e9234690$0200a8c0@structworks.com> <49872EF8.8030808@reyero.net> Message-ID: <3861c6770902021007k38fc7710v13ab2402b7f4d123@mail.gmail.com> On Mon, Feb 2, 2009 at 10:35 AM, Jose A. Reyero wrote: > That said, I think guidelines are fine, so if you want to set up this one as > a guideline and find some consensus, ok. But enforcing guidelines upon > module maintainers, when they think they have a specific reason to skip this > one or this other guideline is bad (and mostly a waste of time). I agree with Jose here. A UI guideline that I've heard about grouping items. * If a group is bigger than 12 consider splitting it * If a group is smaller than 5 consider merging it into another Obviously there has to be room for some compromises, but this provides a basic concept that we can apply to lots of areas like items in menus and the "Package" names at Admin > Site building > Modules (package names with only 1 or 2 items in the package area waste of fieldset). On a default site the "Site configuration" area begins at 14 items. Any proposal that pushes more items there immediately finds itself in violation of the guideline. Similarly, a module without many extension modules has no business creating packages nor creating top level menu items. If we look at the modules that started this thread: - Notifications / Messaging - Organic Groups - Panels On a typical site I think it's reasonable to assume that these modules will be installed alongside other modules that extend them and therefore they should provide their own top level navigation. More specifically: -Notifications / Messaging, as Jose pointed out, are part of a big package of their own which merits this. They also get more extensions regularly. - OG has it's own category of 58 items http://drupal.org/project/Modules/category/90 - Panels provides many menu items itself which probably justifies this top level status without any sub-items. Perhaps it could be moved to some sub level like "Administer > Display" that could hold other "Display" related items. As Daniel proposed, we could push these top level items into an existing top level items and let the menus nest a level deeper. I don't think that will work. If you think our hierarchical menu system is good think about how you and other power users navigate Drupal's admin area: by mouse or by URL bar. We use the URL bar much more often which, IMO, points to a general "Menu system fail" (see https://video.devseed.s3.amazonaws.com/spaces_features_final.mp4 for recent evidence of URL bar navigation). Admin_menu "solves" this problem, but as much as I love admin_menu there is plenty of research that dynamic dropdown menus are too difficult for most users which means that simply pushing the menu hierarchy deeper is not a solution. ** Proposed guideline: If your module is part of a commonly configured package of modules consider creating a new top level menu under admin/ and consolidating related items under that menu. If your module will likely have fewer than 5 items at that level consider reconfiguring the screens to reduce menu items or merging it into an existing menu. Regards, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com From catch56 at googlemail.com Mon Feb 2 18:09:27 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 2 Feb 2009 18:09:27 +0000 Subject: [development] Remove top-level admin menu items In-Reply-To: <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> Message-ID: Seems to me that we should move locale.module and translation.module to a new top-level menu item, then contrib modules like i10n_server could add themselves there - opened a core issue for this here: http://drupal.org/node/368064 (and similar for simpletest/devel - http://drupal.org/node/368067) Nat > > For the l10n_server case, the separate high level item makes sense, > since the l10n_server is a kind of standalone software. It does not > help you track users, enter content, vote on content or whatever, but > in a sense it does all of these. > > G?bor > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090202/6507892d/attachment.htm From weitzman at tejasa.com Mon Feb 2 18:13:13 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Mon, 2 Feb 2009 13:13:13 -0500 Subject: [development] Remove top-level admin menu items In-Reply-To: <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> References: <006401c98490$e9234690$0200a8c0@structworks.com> <86ca3ccb0902020950u3ff133fch1616e0145fc66c87@mail.gmail.com> Message-ID: <6117a7500902021013w3ffe2d1an9c2ae91c3c0a7eea@mail.gmail.com> these are just menu links. if you don't like where they are, move them. there are good arguments on both sides. hardly merits a long discussion, IMO. On Mon, Feb 2, 2009 at 12:50 PM, G?bor Hojtsy wrote: > On Sun, Feb 1, 2009 at 6:17 PM, Daniel F. Kudwien > wrote: >> This goes out to some maintainers, specifically related to >> >> - Notifications / Messaging >> - Organic Groups >> - Panels >> >> Those and related/dependent modules are implementing top-level menu items, e.g. >> >> - admin/messaging >> - admin/og >> - admin/panels >> >> in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. > > Although my fine module was not mentioned here, l10n_server does this > same thing, so I am kind of feel like called out :) Others from Panels > and Notifications/Messaging provided their opinion, so I'd not chip > in, if I'd say the same. But maybe I am saying the same. > > For the l10n_server case, the separate high level item makes sense, > since the l10n_server is a kind of standalone software. It does not > help you track users, enter content, vote on content or whatever, but > in a sense it does all of these. it has a highly specialized storage > and UI system for translation editing and reuses Drupal capabilities > to set up users, languages, organic groups, panels, blocks, whatever > around itself. The module in itself is not related to site building, > configuration, users or reports. It is merely a "high level tool" on > your site you'd use. > > Now that I said it, I might have said the same things as others said > on Panels and Notifications/Messaging, maybe in a more general way. > > And yes, I am an admin_menu user. I was the guy, who pushed it to be > used on d6.drupal.org last week :) And yes, I appreciate high level > tools highlighted on the highest level in my admin_menu. And yes, I > understand that Panels, or Notifications/Messaging or l10n_server > might not have the highest importance to people *once* they set up > everything, and would instead only focus on core site management such > as user, content and logs. > > G?bor > From danithaca at gmail.com Mon Feb 2 22:12:52 2009 From: danithaca at gmail.com (Daniel Zhou) Date: Mon, 2 Feb 2009 22:12:52 +0000 Subject: [development] Join me on Bebo Message-ID: <20090202221255.408E110B836@whitealder.osuosl.org> I think you will like it. Click to find out why You also have the following outstanding friend requests: Jason Nunnelley You can accept or reject all of these invitations at once by clicking below: http://www.bebo.com/in/5390459004a252527358b135 ...................................................................... This email was sent to you at the direct request of Daniel Zhou . You have not been added to a mailing list. If you would prefer not to receive invitations from ANY Bebo members please click here - http://www.bebo.com/unsub/5390459004a252527358 Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA. From danithaca at gmail.com Mon Feb 2 23:38:54 2009 From: danithaca at gmail.com (Daniel Xiaodan Zhou) Date: Mon, 2 Feb 2009 18:38:54 -0500 Subject: [development] Join me on Bebo In-Reply-To: <20090202221255.408E110B836@whitealder.osuosl.org> References: <20090202221255.408E110B836@whitealder.osuosl.org> Message-ID: i'm very sorry for the mistake. it was an unintended mistake.... sorry! On Mon, Feb 2, 2009 at 5:12 PM, Daniel Zhou wrote: > > I think you will like it. > > Click to find out why > > You also have the following outstanding friend requests: > > Jason Nunnelley > > You can accept or reject all of these invitations at once by clicking > below: > http://www.bebo.com/in/5390459004a252527358b135 > > ...................................................................... > > > This email was sent to you at the direct request of Daniel Zhou < > danithaca at gmail.com>. You have not been added to a mailing list. > > If you would prefer not to receive invitations from ANY Bebo members please > click here - http://www.bebo.com/unsub/5390459004a252527358 > > Bebo, Inc., 795 Folsom St, 6th Floor, San Francisco, CA 94107, USA. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090202/8053d87a/attachment.htm From karoly at negyesi.net Tue Feb 3 04:14:02 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 2 Feb 2009 20:14:02 -0800 Subject: [development] SQLite and Drupal 7 Message-ID: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> Hi, In case you do not know, SQLite is a one-file database which Drupal 7 supports. One thing we can do, and this is easy, to ship with Drupal install in a read-only SQLite database, say, in the Drupal root. This would allow install.php to become much cleaner and also make install profiles pretty much regular modules with an access to the whole Drupal system. This will make Drupal require SQLite, but I ran a poll, I ran a challenge and seemingly every site that has PHP 5.2 and PDO has SQLite as well. Now, there is more. We could SQLite as a sort of SQL cache. We could put the following tables into SQLite: a) system b) registry* c) menu_router d) variables e) some cache tables (caution: SQLite is not that good at concurrent writing. It works but only up to a certain point as it locks the whole database.) f) any other table that's read often and written not-so-often. The first two needs some security hardening but that's ongoing. The advantages are somewhat clear: very very early we have access to these things, in a standard, smooth SQL accessible way. On, say, registry rebuild or module enable, DBTNG could easily copy the relevant table from MySQL. There is a disadvantage, however on every site that uses multiple webfrontends against the same MySQL database. There are two kinds of these, high performance sites and development sites. Development sites can put the SQLite database on a network share -- this is neither performant nor safe because both Unix and Windows has bugs with shared FS file locks. But, it will do for development. We could say that for high performance sites you only change system or the registry when you deploy and thus the SQLite file is just one more to be deployed. Otherwise you will end up with a bad situation, where the frontend that handled the rebuild will have its SQLite databases properly updated while others wont. Of course, there are other ways. We can store a "table version number" in a MySQL table for the tables that sit in SQLite and on every request compare and if necessary, copy the table from MySQL to SQLite. if we happen to have a setup where you can serve cached pages from SQlite without touching MySQL then there might be a slight lag with this method. Questions are 1) Are we OK with making Drupal rely on SQLite for every request? 2) Do we want "deploy your SQLite table and be done"? 3) Do we want table versions? 4) Should I just shut up and go back into my corner? Karoly "chx" Negyesi From larry at garfieldtech.com Tue Feb 3 04:39:10 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Mon, 2 Feb 2009 22:39:10 -0600 Subject: [development] SQLite and Drupal 7 In-Reply-To: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> Message-ID: <200902022239.10627.larry@garfieldtech.com> On Monday 02 February 2009 10:14:02 pm Karoly Negyesi wrote: > Questions are > > 1) Are we OK with making Drupal rely on SQLite for every request? No. > 2) Do we want "deploy your SQLite table and be done"? I don't get what this means exactly, so I will say no. :-) > 3) Do we want table versions? Seems like a lot of extra tracking we don't want to have to deal with. > 4) Should I just shut up and go back into my corner? Of course not. :-P For those playing our home game, the approach that I have been envisioning here has been to, as chx alludes to above, introduce a "clone table" operation within the DB layer. The implementation shouldn't be overly complex; it's just a select, multi-insert, delete, execute multi-insert. (Give or take some performance tuning.) The race condition window would be quite small. Then on certain operations, particularly things like menu rebuild or registry rebuild, after the main DB table is rebuilt we check if there is a "system" target defined and if so, run the clone table operation from the "default" target to the "system" target. (Probably that would be checked within the clone method on the database layer itself, which internally becomes a no-op if the target is not defined.) The "system" target then *need not be SQLite*. It could be any supported database, on whatever system. Optimize your site as needed. We then set queries that rely just on those tables to use the the "system" target. If it's defined, it gets used. If not, the default database still has all of the data so the query falls back to that and everything keeps working. -- Larry Garfield larry at garfieldtech.com From larry at garfieldtech.com Tue Feb 3 06:13:37 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 3 Feb 2009 00:13:37 -0600 Subject: [development] SQLite and Drupal 7 In-Reply-To: <200902022239.10627.larry@garfieldtech.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> <200902022239.10627.larry@garfieldtech.com> Message-ID: <200902030013.37206.larry@garfieldtech.com> On Monday 02 February 2009 10:39:10 pm Larry Garfield wrote: > On Monday 02 February 2009 10:14:02 pm Karoly Negyesi wrote: > > Questions are > > > > 1) Are we OK with making Drupal rely on SQLite for every request? > > No. > > > 2) Do we want "deploy your SQLite table and be done"? > > I don't get what this means exactly, so I will say no. :-) OK, on further review I get this. The idea would be to require uploading the sqlite file to a live server from a dev server at the same time you upload your main database dump (or however you do it). That would be a required part of site migration. Put me in the -1 column there. -- Larry Garfield larry at garfieldtech.com From drupal at dwwright.net Tue Feb 3 06:38:34 2009 From: drupal at dwwright.net (Derek Wright) Date: Mon, 2 Feb 2009 22:38:34 -0800 Subject: [development] FYI: "Assigned to: foo" is now opt-in for [#12345] issue link filter Message-ID: Hello world, As most of you hopefully already know, if you type: [#367423] into any page on drupal.org, it will automagically be replaced with: #367423: Make "assigned to" on issue links opt-in (by appending '@') where the whole thing is a link to http://drupal.org/node/367423 If you want to reference comment 15 in the issue, you do this: [#367423-15] and you get a link to: http://drupal.org/node/367423#comment-1233127 Recently, there was a change to the theme on d.o to color the whole thing by the issue status (yay) and to append "Assigned to: foo" afterwards (occasionally yay, mostly boo). This was causing lots of clutter, and some people have either stopped using the filter, or stopped assigning issues, just to avoid the extra noise. This behavior is now opt-in when you write the issue reference. If you want "Assigned to:" to display, you include an '@' after the issue or comment number, like so: [#367423@] Which would yield: #367423: Make "assigned to" on issue links opt-in (by appending '@') Assigned to: dww Otherwise, you get the old behavior (plus the new per-status coloring). Oh, and if you leave off the '@', if the issue is assigned to someone, that's visible in the title attribute if you mouse over the link. Enjoy, -Derek (dww) From dragonwize at gmail.com Tue Feb 3 08:03:44 2009 From: dragonwize at gmail.com (dragonwize) Date: Tue, 3 Feb 2009 03:03:44 -0500 Subject: [development] FYI: "Assigned to: foo" is now opt-in for [#12345] issue link filter In-Reply-To: References: Message-ID: Awesome! Great stuff Derek and company. Thanks for all the hard work. -- Alan Doucette On Tue, Feb 3, 2009 at 01:38, Derek Wright wrote: > Hello world, > > As most of you hopefully already know, if you type: > > [#367423] > > into any page on drupal.org, it will automagically be replaced with: > > #367423: Make "assigned to" on issue links opt-in (by appending '@') > > where the whole thing is a link to http://drupal.org/node/367423 > > > If you want to reference comment 15 in the issue, you do this: > > [#367423-15] > > and you get a link to: http://drupal.org/node/367423#comment-1233127 > > > Recently, there was a change to the theme on d.o to color the whole thing by > the issue status (yay) and to append "Assigned to: foo" afterwards > (occasionally yay, mostly boo). This was causing lots of clutter, and some > people have either stopped using the filter, or stopped assigning issues, > just to avoid the extra noise. > > This behavior is now opt-in when you write the issue reference. If you want > "Assigned to:" to display, you include an '@' after the issue or comment > number, like so: > > [#367423@] > > Which would yield: > > #367423: Make "assigned to" on issue links opt-in (by appending '@') > Assigned to: dww > > Otherwise, you get the old behavior (plus the new per-status coloring). Oh, > and if you leave off the '@', if the issue is assigned to someone, that's > visible in the title attribute if you mouse over the link. > > > Enjoy, > -Derek (dww) > > > > From cooperq at cooperq.com Tue Feb 3 10:34:35 2009 From: cooperq at cooperq.com (cooper Quintin) Date: Tue, 03 Feb 2009 02:34:35 -0800 Subject: [development] url as callback argument Message-ID: <49881DBB.8050301@cooperq.com> Hello all, I am writing a module and I am trying to use a url as a callback argument, but it does not work. Here is the code: $items[] = array( 'path' => 'admin/settings/featured-comments/feature', 'title' => t('featured comment'), 'callback' => 'feature_comment', 'callback_args' => $_GET['cid'], 'access' => user_access('administer comments'), 'type' => MENU_CALLBACK ); and the callback function: function feature_comment($cid) { $comment = _comment_load($cid); db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", $cid); drupal_goto("node/$comment->nid"); } going to an example url: http://example.com/admin/settings/featured-comments/feature?cid=10840 gives the following error: warning: Missing argument 1 for feature_comment() in /var/www/html/sites/all/modules/featured_comments/featured_comments.module on line 149. So my question is, what is the best way to use parts of the linked url as a callback argument for a function, because obviously it is not what I am doing! Thanks, -- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382 From robrechtj+drupal at gmail.com Tue Feb 3 10:46:21 2009 From: robrechtj+drupal at gmail.com (Robrecht Jacques) Date: Tue, 3 Feb 2009 11:46:21 +0100 Subject: [development] url as callback argument In-Reply-To: <49881DBB.8050301@cooperq.com> References: <49881DBB.8050301@cooperq.com> Message-ID: You'll want to use http://example.com/admin/settings/featured-comments/feature/10840 as url. But also: function feature_comment($cid = NULL) { if (!isset($cid)) { // Do something else. drupal_goto(...); } $comment = _comment_load($cid); db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", $cid); drupal_goto("node/$comment->nid"); } On Tue, Feb 3, 2009 at 11:34 AM, cooper Quintin wrote: > Hello all, > I am writing a module and I am trying to use a url as a callback > argument, but it does not work. Here is the code: > > $items[] = array( > 'path' => 'admin/settings/featured-comments/feature', > 'title' => t('featured comment'), > 'callback' => 'feature_comment', > 'callback_args' => $_GET['cid'], > 'access' => user_access('administer comments'), > 'type' => MENU_CALLBACK > ); > > and the callback function: > function feature_comment($cid) { > $comment = _comment_load($cid); > db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", $cid); > drupal_goto("node/$comment->nid"); > } > > going to an example url: > http://example.com/admin/settings/featured-comments/feature?cid=10840 > gives the following error: warning: Missing argument 1 for > feature_comment() in > /var/www/html/sites/all/modules/featured_comments/featured_comments.module > on line 149. > > > So my question is, what is the best way to use parts of the linked url > as a callback argument for a function, because obviously it is not what > I am doing! > Thanks, > > -- > Cooper Quintin > Freelance Programmer, Indymedia Journalist > http://CooperQ.com > (510) 827-5382 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090203/541db3fd/attachment.htm From drupal at reyero.net Tue Feb 3 11:26:45 2009 From: drupal at reyero.net (Jose A. Reyero) Date: Tue, 03 Feb 2009 12:26:45 +0100 Subject: [development] Virtual Code Sprint on Internationalization in Drupal core (starting today) Message-ID: <498829F5.4080903@reyero.net> Hi all, Just in case you don't know yet, we'll be having a Virtual Code Sprint on Internationalization in Drupal core. We are going to focus our efforts for a short period of time on trying to move on with a lot of critical issues and features to get better multilingual support in Drupal 7. It starts today (Tuesday) at 16:00 UTM. It will take place on Feb. 3 - 4 and Feb 10 - 11. The list of issues we'll be focusing on (tagged with 'i18n sprint') is here, http://drupal.org/project/issues/3060/term/301 So if you are interested on multilingual Drupal and want to participate, please sign up for http://groups.drupal.org/node/18443 ============= Sprint logistics ============= The sprint will be held in IRC in #drupal-i18n. We'll also move at times into #drupal-devel when we need to find other developers to get tips on particular problems. The sprint will begin at 16:00 UTM on both Tuesday Feb. 3. This timing is to enable the organizers, located in Europe and North America, to get things going. We'll continue past midnight UTM, partly to enable Angie Byron (the D7 core maintainer) to check in when she's available. You're welcome to participate for as much or as little of the sprint as you can fit in. During the sprint we'll agree on a time to start on Feb. 4 and post this to the event post. It may be earlier than 16:00 UTM to make it easier for participants in Europe, with North American participants joining in later. If you're new to IRC, see this page: http://drupal.org/irc Cheers, Jose From paolomainardi at gmail.com Tue Feb 3 11:37:29 2009 From: paolomainardi at gmail.com (Paolo Mainardi) Date: Tue, 3 Feb 2009 12:37:29 +0100 Subject: [development] url as callback argument In-Reply-To: <49881DBB.8050301@cooperq.com> References: <49881DBB.8050301@cooperq.com> Message-ID: On Tue, Feb 3, 2009 at 11:34 AM, cooper Quintin wrote: > Hello all, > I am writing a module and I am trying to use a url as a callback > argument, but it does not work. Here is the code: > > $items[] = array( > 'path' => 'admin/settings/featured-comments/feature', > 'title' => t('featured comment'), > 'callback' => 'feature_comment', > 'callback_args' => $_GET['cid'], > 'access' => user_access('administer comments'), > 'type' => MENU_CALLBACK > ); > > and the callback function: > function feature_comment($cid) { > $comment = _comment_load($cid); > db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", $cid); > drupal_goto("node/$comment->nid"); > } > I think you can bypass the problem loading the $_GET in feature_comment function and obviously setting $cid = NULL, so: function feature_comment($cid = NULL) { if (!isset($cid)) { if (!$cid = $_GET['cid']) { drupal_goto(); } } $comment = _comment_load($cid); db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", $cid); drupal_goto("node/$comment->nid"); } -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090203/eb1f5d03/attachment.htm From darthsteven at gmail.com Tue Feb 3 11:46:15 2009 From: darthsteven at gmail.com (Steven Jones) Date: Tue, 3 Feb 2009 11:46:15 +0000 Subject: [development] url as callback argument In-Reply-To: <49881DBB.8050301@cooperq.com> References: <49881DBB.8050301@cooperq.com> Message-ID: I'm not how to relates to development of Drupal, so I'll try to kill this thread, here's the main issue: Your hook_menu returns an item with a 'callback_args', key, that key should be: 'callback arguments' and the value should be an array of arguments to pass to the callback. http://api.drupal.org/api/function/hook_menu/5 Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 0121 288 0434 Mobile : 07951 270 026 http://www.computerminds.co.uk 2009/2/3 cooper Quintin : > Hello all, > I am writing a module and I am trying to use a url as a callback > argument, but it does not work. Here is the code: > > $items[] = array( > 'path' => 'admin/settings/featured-comments/feature', > 'title' => t('featured comment'), > 'callback' => 'feature_comment', > 'callback_args' => $_GET['cid'], > 'access' => user_access('administer comments'), > 'type' => MENU_CALLBACK > ); > > and the callback function: > function feature_comment($cid) { > $comment = _comment_load($cid); > db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", $cid); > drupal_goto("node/$comment->nid"); > } > > going to an example url: > http://example.com/admin/settings/featured-comments/feature?cid=10840 > gives the following error: warning: Missing argument 1 for > feature_comment() in > /var/www/html/sites/all/modules/featured_comments/featured_comments.module > on line 149. > > > So my question is, what is the best way to use parts of the linked url > as a callback argument for a function, because obviously it is not what > I am doing! > Thanks, > > -- > Cooper Quintin > Freelance Programmer, Indymedia Journalist > http://CooperQ.com > (510) 827-5382 > > From inaki.lopez at gmail.com Tue Feb 3 15:08:11 2009 From: inaki.lopez at gmail.com (=?ISO-8859-1?Q?I=F1aki_Lopez?=) Date: Tue, 3 Feb 2009 16:08:11 +0100 Subject: [development] url as callback argument In-Reply-To: References: <49881DBB.8050301@cooperq.com> Message-ID: <4f097c7f0902030708h191659fekbc602dd71105a492@mail.gmail.com> $items[] = array( 'path' => 'admin/settings/featured-comments/feature', 'title' => t('featured comment'), 'callback' => 'feature_comment', 'callback_args' => $_GET['cid'], should be.. $items[] = array( 'path' => 'admin/settings/featured-comments/feature/%', 'title' => t('featured comment'), 'callback' => 'feature_comment', 'callback_args' =>array(4), ... try this.. On Tue, Feb 3, 2009 at 12:46 PM, Steven Jones wrote: > I'm not how to relates to development of Drupal, so I'll try to kill > this thread, here's the main issue: > > Your hook_menu returns an item with a 'callback_args', key, that key > should be: 'callback arguments' and the value should be an array of > arguments to pass to the callback. > > http://api.drupal.org/api/function/hook_menu/5 > > Regards > Steven Jones > ComputerMinds ltd - Perfect Drupal Websites > > Phone : 0121 288 0434 > Mobile : 07951 270 026 > http://www.computerminds.co.uk > > > > 2009/2/3 cooper Quintin : > > Hello all, > > I am writing a module and I am trying to use a url as a callback > > argument, but it does not work. Here is the code: > > > > $items[] = array( > > 'path' => 'admin/settings/featured-comments/feature', > > 'title' => t('featured comment'), > > 'callback' => 'feature_comment', > > 'callback_args' => $_GET['cid'], > > 'access' => user_access('administer comments'), > > 'type' => MENU_CALLBACK > > ); > > > > and the callback function: > > function feature_comment($cid) { > > $comment = _comment_load($cid); > > db_query("UPDATE {featured_comments} SET featured=1 WHERE cid=%d", > $cid); > > drupal_goto("node/$comment->nid"); > > } > > > > going to an example url: > > http://example.com/admin/settings/featured-comments/feature?cid=10840 > > gives the following error: warning: Missing argument 1 for > > feature_comment() in > > > /var/www/html/sites/all/modules/featured_comments/featured_comments.module > > on line 149. > > > > > > So my question is, what is the best way to use parts of the linked url > > as a callback argument for a function, because obviously it is not what > > I am doing! > > Thanks, > > > > -- > > Cooper Quintin > > Freelance Programmer, Indymedia Journalist > > http://CooperQ.com > > (510) 827-5382 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090203/4dd464b7/attachment.htm From syscrusher at 4th.com Tue Feb 3 15:09:11 2009 From: syscrusher at 4th.com (Syscrusher) Date: Tue, 03 Feb 2009 10:09:11 -0500 Subject: [development] SQLite and Drupal 7 In-Reply-To: <200902022239.10627.larry@garfieldtech.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> <200902022239.10627.larry@garfieldtech.com> Message-ID: <1233673751.10209.114.camel@marcus> On Mon, 2009-02-02 at 22:39 -0600, Larry Garfield wrote: > > 4) Should I just shut up and go back into my corner? > > Of course not. :-P Heartily agreed. Whether or not we adopt chx's suggestions, it is an idea worthy of discussion. Having a read-only initial conditions database in SQLite also offers us the potential for an administrative "reset entire site to defaults" option, which could reset all settings but not delete nodes or users (or could offer the admin the option of these two things). This would be a great last-resort recovery option for confused novices, and it would be a fine testing aid for us developers. I am not yet ready to say +1 to adopting chx's suggestion, but I'm ready to say +1 for discussing it seriously. Scott -- Syscrusher From syscrusher at 4th.com Tue Feb 3 15:11:30 2009 From: syscrusher at 4th.com (Syscrusher) Date: Tue, 03 Feb 2009 10:11:30 -0500 Subject: [development] FYI: "Assigned to: foo" is now opt-in for [#12345] issue link filter In-Reply-To: References: Message-ID: <1233673890.10209.116.camel@marcus> On Mon, 2009-02-02 at 22:38 -0800, Derek Wright wrote: > Otherwise, you get the old behavior (plus the new per-status > coloring). Oh, and if you leave off the '@', if the issue is > assigned > to someone, that's visible in the title attribute if you mouse over > the link. Best of both worlds! Nice work. Scott -- Syscrusher From weitzman at tejasa.com Tue Feb 3 15:12:24 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Tue, 3 Feb 2009 10:12:24 -0500 Subject: [development] SQLite and Drupal 7 In-Reply-To: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> Message-ID: <6117a7500902030712s31b4d82csf92ed5cb5742e795@mail.gmail.com> To me, this creates as many problems as it solves. Not a fan at this time. From larry at garfieldtech.com Tue Feb 3 18:29:33 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 3 Feb 2009 12:29:33 -0600 Subject: [development] SQLite and Drupal 7 In-Reply-To: <1233673751.10209.114.camel@marcus> References: <1233673751.10209.114.camel@marcus> Message-ID: On Tue, 03 Feb 2009 10:09:11 -0500, Syscrusher wrote: > On Mon, 2009-02-02 at 22:39 -0600, Larry Garfield wrote: >> > 4) Should I just shut up and go back into my corner? >> >> Of course not. :-P > > > Heartily agreed. Whether or not we adopt chx's suggestions, it is an > idea worthy of discussion. > > Having a read-only initial conditions database in SQLite also offers us > the potential for an administrative "reset entire site to defaults" > option, which could reset all settings but not delete nodes or users (or > could offer the admin the option of these two things). This would be a > great last-resort recovery option for confused novices, and it would be > a fine testing aid for us developers. > > I am not yet ready to say +1 to adopting chx's suggestion, but I'm ready > to say +1 for discussing it seriously. > > Scott To clarify, I am not against an SQLite DB as a "Safe mode" fallback, or as an install mechanism. Those are both definitely worth considering. It's making a secondary DB required for normal operation that I do not believe is a good idea. --Larry Garfield From aldo at caonao.cu Tue Feb 3 18:38:15 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Tue, 3 Feb 2009 13:38:15 -0500 Subject: [development] how can i customize the og default view Message-ID: <200902031338.15755.aldo@caonao.cu> i know with the og_ghp_ prefix can i create other view for use in groups homepage, but i want this can be optional, i mean, some groups with one view and others with other view, it's this possible??? -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From mathews.kyle at gmail.com Tue Feb 3 18:51:50 2009 From: mathews.kyle at gmail.com (Kyle Mathews) Date: Tue, 3 Feb 2009 11:51:50 -0700 Subject: [development] SQLite and Drupal 7 In-Reply-To: References: <1233673751.10209.114.camel@marcus> Message-ID: A thought as well -- install profiles could ship with an sqllite db with all the customized site configuration. Then as part of the regular installation, the info from that db would be copied to the regular mysql db. Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Tue, Feb 3, 2009 at 11:29 AM, Larry Garfield wrote: > > On Tue, 03 Feb 2009 10:09:11 -0500, Syscrusher wrote: > > On Mon, 2009-02-02 at 22:39 -0600, Larry Garfield wrote: > >> > 4) Should I just shut up and go back into my corner? > >> > >> Of course not. :-P > > > > > > Heartily agreed. Whether or not we adopt chx's suggestions, it is an > > idea worthy of discussion. > > > > Having a read-only initial conditions database in SQLite also offers us > > the potential for an administrative "reset entire site to defaults" > > option, which could reset all settings but not delete nodes or users (or > > could offer the admin the option of these two things). This would be a > > great last-resort recovery option for confused novices, and it would be > > a fine testing aid for us developers. > > > > I am not yet ready to say +1 to adopting chx's suggestion, but I'm ready > > to say +1 for discussing it seriously. > > > > Scott > > To clarify, I am not against an SQLite DB as a "Safe mode" fallback, or as > an install mechanism. Those are both definitely worth considering. It's > making a secondary DB required for normal operation that I do not believe is > a good idea. > > --Larry Garfield > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090203/aeb62d1f/attachment.htm From michael at favias.org Tue Feb 3 19:04:45 2009 From: michael at favias.org (Michael Favia) Date: Tue, 03 Feb 2009 13:04:45 -0600 Subject: [development] how can i customize the og default view In-Reply-To: <200902031338.15755.aldo@caonao.cu> References: <200902031338.15755.aldo@caonao.cu> Message-ID: <4988954D.8050405@favias.org> Aldo Martinez Selleras wrote: > i know with the og_ghp_ prefix can i create other view for use in groups > homepage, but i want this can be optional, i mean, some groups with one view > and others with other view, it's this possible??? > Your support request is best handled in the OG issue queue located here: http://drupal.org/project/issues/og Best wishes, -- Michael Favia www.favias.org From lstroobant at gmail.com Tue Feb 3 20:36:19 2009 From: lstroobant at gmail.com (Luc Stroobant) Date: Tue, 03 Feb 2009 21:36:19 +0100 Subject: [development] SQLite and Drupal 7 In-Reply-To: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> Message-ID: <4988AAC3.9050101@gmail.com> Karoly Negyesi wrote: > Hi, > > In case you do not know, SQLite is a one-file database which Drupal 7 supports. > > One thing we can do, and this is easy, to ship with Drupal install in > a read-only SQLite database, say, in the Drupal root. This would allow > install.php to become much cleaner and also make install profiles > pretty much regular modules with an access to the whole Drupal system. > This will make Drupal require SQLite, but I ran a poll, I ran a > challenge and seemingly every site that has PHP 5.2 and PDO has SQLite > as well. I don't think it's a good idea to add such a requirement for something you only use at install time. > Now, there is more. We could SQLite as a sort of SQL cache. We could > put the following tables into SQLite: > > a) system > b) registry* > c) menu_router > d) variables > e) some cache tables (caution: SQLite is not that good at concurrent > writing. It works but only up to a certain point as it locks the whole > database.) > f) any other table that's read often and written not-so-often. > > The first two needs some security hardening but that's ongoing. > > The advantages are somewhat clear: very very early we have access to > these things, in a standard, smooth SQL accessible way. On, say, > registry rebuild or module enable, DBTNG could easily copy the > relevant table from MySQL. > > There is a disadvantage, however on every site that uses multiple > webfrontends against the same MySQL database. There are two kinds of > these, high performance sites and development sites. I've been managing a few Drupal enterprise sites and this sounds like a nightmare to me. People who have a dedicated database server and an highly optimized setup don't want to add extra overhead and make things more complicated with a database in a file. You won't find sqlite support in properly configured servers for high performance sites. And another example: in Debian PHP5 doesn't have sqlite support by default while it has pdo (you have to install a separate package for sqlite support). So I don't think it's that safe to say that everybody with pdo support also has sqlite... Luc From sam at treslerdesigns.com Tue Feb 3 21:32:08 2009 From: sam at treslerdesigns.com (Sam Tresler) Date: Tue, 03 Feb 2009 16:32:08 -0500 Subject: [development] SQLite and Drupal 7 In-Reply-To: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> Message-ID: <1233696728.5648.38.camel@localhost> On Mon, 2009-02-02 at 20:14 -0800, Karoly Negyesi wrote: > We could say that for > high performance sites you only change system or the registry when you > deploy and thus the SQLite file is just one more to be deployed. This is not a viable solution for content heavy sites such as newpapers and radio stations. If I understand it correctly it would involve pausing the entire content creation staff while development pushed the new db file live. It would also entail having site admins, that might not be administrators required to either know what was a safe change in a clustered environment and what wasn't, or attempting to restrict the access of site-admins in complex ways. I'm not shut off to the idea, but I don't see it working well in a clustered environment. -Sam Tresler From prometheus6 at gmail.com Tue Feb 3 22:45:53 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Tue, 3 Feb 2009 17:45:53 -0500 Subject: [development] SQLite and Drupal 7 In-Reply-To: <1233696728.5648.38.camel@localhost> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> <1233696728.5648.38.camel@localhost> Message-ID: chx: Was your basic idea to isolate the more static parts of the database from the more active parts? It strikes me that could be done without SQLite. On Tue, Feb 3, 2009 at 4:32 PM, Sam Tresler wrote: > > > > On Mon, 2009-02-02 at 20:14 -0800, Karoly Negyesi wrote: > > We could say that for > > high performance sites you only change system or the registry when you > > deploy and thus the SQLite file is just one more to be deployed. > > This is not a viable solution for content heavy sites such as newpapers > and radio stations. If I understand it correctly it would involve > pausing the entire content creation staff while development pushed the > new db file live. > > It would also entail having site admins, that might not be > administrators required to either know what was a safe change in a > clustered environment and what wasn't, or attempting to restrict the > access of site-admins in complex ways. > > I'm not shut off to the idea, but I don't see it working well in a > clustered environment. > > -Sam Tresler > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090203/55b34f12/attachment.htm From jpetso at gmx.at Tue Feb 3 23:32:37 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Wed, 4 Feb 2009 00:32:37 +0100 Subject: [development] url as callback argument In-Reply-To: <4f097c7f0902030708h191659fekbc602dd71105a492@mail.gmail.com> References: <49881DBB.8050301@cooperq.com> <4f097c7f0902030708h191659fekbc602dd71105a492@mail.gmail.com> Message-ID: <200902040032.38848.jpetso@gmx.at> On Tuesday 03 February 2009, I?aki Lopez wrote: > $items[] = array( > 'path' => 'admin/settings/featured-comments/feature', > 'title' => t('featured comment'), > 'callback' => 'feature_comment', > 'callback_args' => $_GET['cid'], > > should be.. > > $items[] = array( > 'path' => 'admin/settings/featured-comments/feature/%', > 'title' => t('featured comment'), > 'callback' => 'feature_comment', > 'callback_args' =>array(4), > ... Bad advice: 1. There is no '%' wildcard in Drupal 5, and Drupal 6 puts the path as array key instead of having a separate 'path' element. 2. There is no 'callback_args' property. array(...) is correct, but it also needs to be renamed to 'callback arguments' for Drupal to do anything with it. In Drupal 5, that would be "'callback arguments' => array($_GET['cid'])". (Or 'page callback' and 'page arguments' in Drupal 6, which I understand the original poster is not using at this time.) Maybe the thread is better off dead - http://api.drupal.org/api/function/hook_menu/5 has been posted already - but it's hard to leave the above example uncommented as is. Cheers, j From mroswell at gmail.com Tue Feb 3 23:58:41 2009 From: mroswell at gmail.com (Margie Roswell) Date: Tue, 3 Feb 2009 18:58:41 -0500 Subject: [development] Drupal API Page with Comments? Message-ID: Hi, I think it would be enormously helpful to drupal users if a core and contributed modules API site enabled comments. Something like this: http://us.php.net/manual/en/function.is-array.php Is there any reason this couldn't be done? Throwing the idea out there. Is this the right place to post this idea, or is it better discussed somewhere else? Any technical or social reasons we shouldn't do this? I think it would expose so much helpful code to struggling drupalers! There's always wheat and chaff, but people are pretty good at sorting out that stuff. For now, it's tough climbing the learning Drupal learning curve without an annotated functions page like the one on the PHP site. BTW, I'm a huge fan of the contributed module API site at http://api.freestylesystems.co.uk/ Best Regards, Margie From drupal-devel at webchick.net Wed Feb 4 00:03:02 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Tue, 3 Feb 2009 19:03:02 -0500 Subject: [development] Drupal API Page with Comments? In-Reply-To: References: Message-ID: <0C0790C3-3A08-45C0-B917-26A10B3BDE4B@webchick.net> On 3-Feb-09, at 6:58 PM, Margie Roswell wrote: > Hi, > > I think it would be enormously helpful to drupal users if a core and > contributed modules API site enabled comments. > > Something like this: > http://us.php.net/manual/en/function.is-array.php > > Is there any reason this couldn't be done? Throwing the idea out > there. Is this the right place to post this idea, or is it better > discussed somewhere else? Any technical or social reasons we shouldn't > do this? Technical reasons, yes. See: http://drupal.org/node/101308, which is postponed pending more important bug fixes like http://drupal.org/node/300031 and http://drupal.org/node/100680 and http://drupal.org/node/84207. In other words, if you want to see this happen, API module needs some love. :) -Angie From cxjohnson at gmail.com Wed Feb 4 00:24:05 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 3 Feb 2009 18:24:05 -0600 Subject: [development] SQLite and Drupal 7 In-Reply-To: <6117a7500902030712s31b4d82csf92ed5cb5742e795@mail.gmail.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> <6117a7500902030712s31b4d82csf92ed5cb5742e795@mail.gmail.com> Message-ID: <9ea8d6030902031624p6aa5c8a2jb54ad9cf8057c591@mail.gmail.com> Deploying, maintaining and developing in my environment (100 sites sharing 3 version of source code, load-balanced front end, LDAP, Jabber, etc.) is complex enough. Adding this makes it quite a bit more complex. Depending on SQLite for each request is almost a certain nail in the coffin. Very opposed to that idea. Installing from or falling back to an install "profile/config" in SQLite -- now that's doable. ..chris On Tue, Feb 3, 2009 at 9:12 AM, Moshe Weitzman wrote: > To me, this creates as many problems as it solves. Not a fan at this time. > From dmitrig01 at gmail.com Wed Feb 4 03:27:49 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Tue, 3 Feb 2009 19:27:49 -0800 Subject: [development] SQLite and Drupal 7 In-Reply-To: <4988AAC3.9050101@gmail.com> References: <7e270cea0902022014l5f01748eg6a73be37d56462d2@mail.gmail.com> <4988AAC3.9050101@gmail.com> Message-ID: <9AE4B184-F5E7-43BF-AB24-FC0B86F03655@gmail.com> On Feb 3, 2009, at 12:36 PM, Luc Stroobant wrote: > Karoly Negyesi wrote: >> Hi, >> In case you do not know, SQLite is a one-file database which Drupal >> 7 supports. >> One thing we can do, and this is easy, to ship with Drupal install in >> a read-only SQLite database, say, in the Drupal root. This would >> allow >> install.php to become much cleaner and also make install profiles >> pretty much regular modules with an access to the whole Drupal >> system. >> This will make Drupal require SQLite, but I ran a poll, I ran a >> challenge and seemingly every site that has PHP 5.2 and PDO has >> SQLite >> as well. > > I don't think it's a good idea to add such a requirement for > something you only use at install time. > >> Now, there is more. We could SQLite as a sort of SQL cache. We could >> put the following tables into SQLite: >> a) system >> b) registry* >> c) menu_router >> d) variables >> e) some cache tables (caution: SQLite is not that good at concurrent >> writing. It works but only up to a certain point as it locks the >> whole >> database.) >> f) any other table that's read often and written not-so-often. >> The first two needs some security hardening but that's ongoing. >> The advantages are somewhat clear: very very early we have access to >> these things, in a standard, smooth SQL accessible way. On, say, >> registry rebuild or module enable, DBTNG could easily copy the >> relevant table from MySQL. >> There is a disadvantage, however on every site that uses multiple >> webfrontends against the same MySQL database. There are two kinds of >> these, high performance sites and development sites. > > > I've been managing a few Drupal enterprise sites and this sounds > like a nightmare to me. People who have a dedicated database server > and an highly optimized setup don't want to add extra overhead and > make things more complicated with a database in a file. You won't > find sqlite support in properly configured servers for high > performance sites. I think this functionality may be disabled, but for most it's a performance boost. > > > And another example: in Debian PHP5 doesn't have sqlite support by > default while it has pdo (you have to install a separate package for > sqlite support). So I don't think it's that safe to say that > everybody with pdo support also has sqlite... > > Luc From karoly at negyesi.net Wed Feb 4 04:09:13 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Tue, 3 Feb 2009 20:09:13 -0800 Subject: [development] SQLite and Drupal 7 -- let's try this again Message-ID: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> Hi, Apparently despite my intentions, I did not manage to express myself clearly so let's try this again. Drupal 7 has a very interesting new feature which we call the registry. The registry holds information about which function, class and interface lives in which file. This information never changes if you do not change your modules and themes. Drupal always had a system table which holds information on available themes and modules. This information never changes if you do not add new modules nor new themes. If we put these tables in an SQLite table then the only time this file changes is when your code changes. Therefore, when people with high performance sites deploy their new code, they can deploy the new database. There is no new procedure to be created, just one more file added to the roster. Now, if I ask this way, are people still against putting registry and system into an SQLite database? NK From morbus at disobey.com Wed Feb 4 04:26:13 2009 From: morbus at disobey.com (Morbus Iff) Date: Tue, 03 Feb 2009 23:26:13 -0500 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> Message-ID: <498918E5.6050109@disobey.com> > Drupal 7 has a very interesting new feature which we call the > registry. The registry holds information about which function, class > and interface lives in which file. This information never changes if > you do not change your modules and themes. > > Drupal always had a system table which holds information on available > themes and modules. This information never changes if you do not add > new modules nor new themes. > > If we put these tables in an SQLite table then the only time this file > changes is when your code changes. Therefore, when people with high > performance sites deploy their new code, they can deploy the new > database. There is no new procedure to be created, just one more file So, what you're roughly saying is: * the speed of a file read/parse of a SQLite table is always going to be faster than a MySQL/etc. read? Even if the above is true, I'm not a huge, huge fan of it myself. Is there an automatic backup in place - something that, if SQLite is enabled, but the SQLite database isn't there (or can't be created), we'd fall back to the MySQL version? Random comments and reasons for disliking it: * Not immediately easy to explain. What's this file doing here? Why is Drupal the only application I know that requires both SQLite and a MySQL store? Why isn't everything in MySQL? Why aren't more things in SQLite? * Generally speaking, "backup your databases" and "backup your site" happen in two separate mental processes (and usually technical processes too). Unless the feature handles a failsafe when the SQLite database goes missing, I'm not too happy with the idea of "ok, to backup the 'database' now requires a mysqldump AND a copy of this SQLite database." * Aesthetically, I like being able to see what's in a database. I don't personally know how to access a SQLite database, nor do I want to. * Similarly, in Drupal 6 (I dunno about Drupal 7), the system table is also NOT UPDATED when I *remove* modules or themes. I regularly am pruning it manually, because it bugs me. I'm obsessive about cleanliness and organization. Unless I move the DELETE FROM {system} code to a module, you're implying I can't do that anymore? * When I'm debugging, it tends to be useful to quickly modify up/down the weight of a module stored in, yep, the system table. Would I still be able to do that here, from a MySQL prompt? Or would I have to devolve into learning SQLite again, when I've never ever had to use SQLite ever? * Are the gains *really* so incredibly huge that SQLite is the only solution, as opposed to "just" throwing the same ol' chainsaws at the problem: memcached, opcode cache, etc.? If this is so great for high-profile sites, they've probably already got their own specific set of tweaks for improving things, no? (I know I do.) * "Therefore, when people with high performance sites deploy their new code, they can deploy the new database." Where is this new SQLite file being created? This particular comment, I dunno, feels ooky to me. When I deploy code, I want to, you know, deploy *code*, not a set of caches (for the same reason that I don't deploy memcache instances or previously opcoded cache files). -- Morbus Iff ( cheese and rice saves ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From karoly at negyesi.net Wed Feb 4 04:44:35 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 04 Feb 2009 05:44:35 +0100 (CET) Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <498918E5.6050109@disobey.com> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <498918E5.6050109@disobey.com> Message-ID: > So, what you're roughly saying is: > > * the speed of a file read/parse of a SQLite table > is always going to be faster than a MySQL/etc. read? That's likely but that's not the big win here. Read on. > * Aesthetically, I like being able to see what's in a database. I don't > personally know how to access a SQLite database, nor do I want to. Well, there is a command line utility but sure. > * When I'm debugging, it tends to be useful to quickly modify up/down > the weight of a module stored in, yep, the system table. Would I > still be able to do that here, from a MySQL prompt? >From a sqlite prompt. Not a big difference IMO. The changes from SQLite will not, however, automatically sync back to MySQL so I admit this is not ideal. It seems I need to make sure that Drupal can pull together itself enough to rebuild the missing SQLite database by copying the tables from MySQL. And then reload itself in a useable state. This means that actually deploy is a lot lot easier than I originally thought. (See this is why I am not too fond of emails, I like the issue queue a lot better) > * Are the gains *really* so incredibly huge that SQLite is the only > solution, as opposed to "just" throwing the same ol' chainsaws at > the problem: memcached, opcode cache, etc.? If this is so great > for high-profile sites, they've probably already got their own > specific set of tweaks for improving things, no? (I know I do.) Here we go. The big win is NOT performance. The big win is nice code. I forgot to mention this, silly me. So the problem is that currently we have a fairly ugly way to allow pluggable subsystems and they are not really flexible. You can pick one cache subsystem, that's it. We are planning something called handlers which will let you pick cache subsystems by the table for example. For this, we will change the cache implementations to become a class. However, if we want -- and yes, we want -- to serve cached pages without touching MySQL then we need to somehow specify the pathes to the cache and session implementation. If we have the registry available immediately then autoload just works. > * "Therefore, when people with high performance sites deploy their > new code, they can deploy the new database." Where is this new SQLite > file being created? In your files directory because it needs to be Apache writeable but it's kinda irrevelant here. From prakash.c-k at hp.com Wed Feb 4 05:16:55 2009 From: prakash.c-k at hp.com (Kesavan, Prakash C) Date: Wed, 4 Feb 2009 05:16:55 +0000 Subject: [development] Drupal Module Message-ID: Hi , I was trying to implement a question bank , A customer need to choose questions from the bank for different streams like mysql,php,rhcs etc...and fill the mandatory part of it ,also they may need to add additional questions if they want and submit. I was tiring to do so with webform but I think it doesn't support to call from question bank. It just creates the multiple questions. I tried with taxonomy also but I could not integrate with the same and it doesn't work for me.. If there is any other module currently present ,it would be grate for me. or some help for how to create a module. I am new to Drupal. It will be grate if somebody provide me good document for developing a drupal module which came out of there real experience. +hp=everything is possible Thanks In Advance PrakashCKesavan RHCE,OCA,CSA Technology Consultant OpenSource And Linux HP GDAS +91 9972047746 From inaki.lopez at gmail.com Wed Feb 4 06:09:05 2009 From: inaki.lopez at gmail.com (=?ISO-8859-1?Q?I=F1aki_Lopez?=) Date: Wed, 4 Feb 2009 07:09:05 +0100 Subject: [development] url as callback argument In-Reply-To: <200902040032.38848.jpetso@gmx.at> References: <49881DBB.8050301@cooperq.com> <4f097c7f0902030708h191659fekbc602dd71105a492@mail.gmail.com> <200902040032.38848.jpetso@gmx.at> Message-ID: <4f097c7f0902032209t3d37de11me791e0d20f9e84c8@mail.gmail.com> sorry, I don't know how did I realize the drupal version was six, and my reply was a "finish-porting-this-to-d6".. Now I see, only half of the menu entry is 'ported' as well.. Indeed, a very bad advice at all.. where the hell is my head?.. brbr On Wed, Feb 4, 2009 at 12:32 AM, Jakob Petsovits wrote: > On Tuesday 03 February 2009, I?aki Lopez wrote: > > $items[] = array( > > 'path' => 'admin/settings/featured-comments/feature', > > 'title' => t('featured comment'), > > 'callback' => 'feature_comment', > > 'callback_args' => $_GET['cid'], > > > > should be.. > > > > $items[] = array( > > 'path' => 'admin/settings/featured-comments/feature/%', > > 'title' => t('featured comment'), > > 'callback' => 'feature_comment', > > 'callback_args' =>array(4), > > ... > > Bad advice: > > 1. There is no '%' wildcard in Drupal 5, and Drupal 6 puts the path as > array > key instead of having a separate 'path' element. > > 2. There is no 'callback_args' property. array(...) is correct, but it also > needs to be renamed to 'callback arguments' for Drupal to do anything with > it. > In Drupal 5, that would be "'callback arguments' => array($_GET['cid'])". > (Or 'page callback' and 'page arguments' in Drupal 6, which I understand > the > original poster is not using at this time.) > > Maybe the thread is better off dead - > http://api.drupal.org/api/function/hook_menu/5 has been posted already - > but it's hard to leave the above example uncommented as is. > > Cheers, > j > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/3dc48548/attachment-0001.htm From nevets at tds.net Wed Feb 4 04:15:56 2009 From: nevets at tds.net (Steve Ringwood) Date: Tue, 03 Feb 2009 22:15:56 -0600 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> Message-ID: <4989167C.5060504@mailbag.com> I thought one of the goals is to make Drupal database independent so requiring SQLite seems to run counter to this. My development box does not have SQLite and some of the hosts I have used do not include it The bottom line requiring SQLite seems like more that could prevent or at least keep people from deploying Drupal and that does not seem like the right direction for Drupal. So personally I vote against requiring SQLite Steve Ringwood aka nevets From drupal.beginner at wechange.org Wed Feb 4 07:36:18 2009 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Wed, 4 Feb 2009 15:36:18 +0800 Subject: [development] node type not listed at node/add Message-ID: <200902041536.18995.drupal.beginner@wechange.org> Hello, With a module implementing its own node type, the said node type is not listed at node/add. Is this a feature or a bug? http://drupal.org/node/368924 Everywhere, it is said that the menu item is automatically created from hook_node_info() but having read the documentation and followed the tutorials, it just doesn't work for me. Thanks, Augustin. From jpetso at gmx.at Wed Feb 4 07:49:47 2009 From: jpetso at gmx.at (Jakob Petsovits) Date: Wed, 4 Feb 2009 08:49:47 +0100 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> Message-ID: <200902040849.48286.jpetso@gmx.at> On Wednesday 04 February 2009, Karoly Negyesi wrote: > If we put these tables in an SQLite table then the only time this file > changes is when your code changes. Therefore, when people with high > performance sites deploy their new code, they can deploy the new > database. There is no new procedure to be created, just one more file > added to the roster. > > Now, if I ask this way, are people still against putting registry and > system into an SQLite database? If settings.php just specifies the SQLite file for the system and registry tables, and the MySQL database for the other tables, wouldn't that solve the issue and make it an optional feature for people who want this? Or is there something more to be gained by hardcoding SQLite access? JP From stewsnooze at gmail.com Wed Feb 4 08:11:42 2009 From: stewsnooze at gmail.com (Stewart Robinson) Date: Wed, 4 Feb 2009 08:11:42 +0000 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <200902040849.48286.jpetso@gmx.at> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <200902040849.48286.jpetso@gmx.at> Message-ID: Why does it have to be SQLLite? You are effectively proposing to split the datastore. Why hardcode it to SQLLite? Potentially I would put it in another MySQL database on a different server or a pgsql db somewhere. PDO let's me do that. In general I am against this idea. Drupal already, mainly because of MyISAM on MYSQL I suppose, falls behind on fundamental good database design ideas; like foreign keys for example. Splitting the data into two stores just does more to reduce the referencial integrity and safe state of our data. Drupal definitely doesn't achieve second normal form. I am not sure whether we could argue it achieves first normal form. In my opinion this is a non starter in hardcoding to SQLLite and a slow starter even if you let people choose a second data store for certain schemas/tables Stew -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/06024fd7/attachment.htm From drupal.beginner at wechange.org Wed Feb 4 08:47:08 2009 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Wed, 4 Feb 2009 16:47:08 +0800 Subject: [development] [fixed: worksform] never mind (Re: node type not listed at node/add In-Reply-To: <200902041536.18995.drupal.beginner@wechange.org> References: <200902041536.18995.drupal.beginner@wechange.org> Message-ID: <200902041647.08969.drupal.beginner@wechange.org> Hmmm. Apparently it was something to do with a faulty D5 => D6 upgrade. Menu items were duplicated and some hidden. The problem does not occur on a clean DB. Issue closed. Thanks. A. From rob at robshouse.net Wed Feb 4 10:41:30 2009 From: rob at robshouse.net (Robert Douglass) Date: Wed, 4 Feb 2009 11:41:30 +0100 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <200902040849.48286.jpetso@gmx.at> Message-ID: <99CCAE87-BFE2-4C3C-B415-DE9C6212ED2B@robshouse.net> chx, are there also implications for how one would deploy sites in your suggestion? Would it make it easier or harder to move stuff from staging to production, for example? I'm fascinated by your idea and think that if it can be made an optional requirement (yes intentional wording), then it could be very interesting. I encourage people to keep asking questions until they understand the full idea, because so far I think a lot of people essentially stopped reading at "Should we require SQLite?" -Robert From mistknight at gmail.com Wed Feb 4 11:05:41 2009 From: mistknight at gmail.com (Ashraf Amayreh) Date: Wed, 4 Feb 2009 13:05:41 +0200 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <99CCAE87-BFE2-4C3C-B415-DE9C6212ED2B@robshouse.net> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <200902040849.48286.jpetso@gmx.at> <99CCAE87-BFE2-4C3C-B415-DE9C6212ED2B@robshouse.net> Message-ID: Trying my best to understand the benefits of this. What benefits are to be gained from moving these tables to an SQLite database? Performance improvements? Does it ease anything for developers? What exactly are the pros and cons? Whatever they are, they just don't hit me as intuitive. On Wed, Feb 4, 2009 at 12:41 PM, Robert Douglass wrote: > chx, are there also implications for how one would deploy sites in your > suggestion? Would it make it easier or harder to move stuff from staging to > production, for example? I'm fascinated by your idea and think that if it > can be made an optional requirement (yes intentional wording), then it could > be very interesting. I encourage people to keep asking questions until they > understand the full idea, because so far I think a lot of people essentially > stopped reading at "Should we require SQLite?" > > -Robert > -- Ashraf Amayreh http://aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/a35d2243/attachment.htm From stewsnooze at gmail.com Wed Feb 4 11:37:45 2009 From: stewsnooze at gmail.com (Stewart Robinson) Date: Wed, 4 Feb 2009 11:37:45 +0000 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <200902040849.48286.jpetso@gmx.at> <99CCAE87-BFE2-4C3C-B415-DE9C6212ED2B@robshouse.net> Message-ID: Also commercial support of SQLite is sparse. I mailed my hosting provider and they won't support SQLite and have no plans to. They'll let us use it but won't own it. All of my websites live under a managed service agreement so that the hosting company can simply look after them. This could be a step in the wrong direction for corporate adoption if SQLite is forced. Stew On Wed, Feb 4, 2009 at 11:05 AM, Ashraf Amayreh wrote: > Trying my best to understand the benefits of this. What benefits are to be > gained from moving these tables to an SQLite database? Performance > improvements? Does it ease anything for developers? What exactly are the > pros and cons? Whatever they are, they just don't hit me as intuitive. > > On Wed, Feb 4, 2009 at 12:41 PM, Robert Douglass wrote: > >> chx, are there also implications for how one would deploy sites in your >> suggestion? Would it make it easier or harder to move stuff from staging to >> production, for example? I'm fascinated by your idea and think that if it >> can be made an optional requirement (yes intentional wording), then it could >> be very interesting. I encourage people to keep asking questions until they >> understand the full idea, because so far I think a lot of people essentially >> stopped reading at "Should we require SQLite?" >> >> -Robert >> > > > > -- > Ashraf Amayreh > http://aamayreh.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/e12dc7c1/attachment-0001.htm From stella at stellapower.net Wed Feb 4 11:43:30 2009 From: stella at stellapower.net (Stella Power) Date: Wed, 4 Feb 2009 11:43:30 +0000 Subject: [development] Drupal Module In-Reply-To: References: Message-ID: I'm not entirely sure what you're looking for, but maybe check out the FAQ ( http://drupal.org/project/faq) and FAQ Ask ( http://drupal.org/project/faq_ask) modules. Cheers, Stella On Wed, Feb 4, 2009 at 5:16 AM, Kesavan, Prakash C wrote: > Hi , > > I was trying to implement a question bank , A customer need to choose > questions from the bank for different streams like mysql,php,rhcs etc...and > fill the mandatory part of it ,also they may need to add additional > questions if they want and submit. I was tiring to do so with webform but I > think it doesn't support to call from question bank. It just creates the > multiple questions. I tried with taxonomy also but I could not integrate > with the same and it doesn't work for me.. > > If there is any other module currently present ,it would be grate for me. > or some help for how to create a module. I am new to Drupal. It will be > grate if somebody provide me good document for developing a drupal module > which came out of there real experience. > > > +hp=everything is possible > Thanks In Advance > PrakashCKesavan > RHCE,OCA,CSA > Technology Consultant > OpenSource And Linux > HP GDAS > +91 9972047746 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/c73468f6/attachment.htm From morbus at disobey.com Wed Feb 4 12:58:00 2009 From: morbus at disobey.com (Morbus Iff) Date: Wed, 04 Feb 2009 07:58:00 -0500 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <498918E5.6050109@disobey.com> Message-ID: <498990D8.70609@disobey.com> > It seems I need to make sure that Drupal can pull together itself > enough to rebuild the missing SQLite database by copying the tables > from MySQL. And then reload itself in a useable state. This means > that actually deploy is a lot lot easier than I originally thought. Yep, that'd be great. But, I'm still iffy on REQUIRING SQLite. I'd be a lot happier if it was a non-interactive *optional* thing. * If SQLite is built into PHP, use it (so, you'd do your function exists around relevant pieces of code). Anything we continue to build will have to support reading from MySQL in the absence of. This would also stop all the whiners who are complaining about SQLite without actually understanding the point of it (as well as the *very real* lack of support for SQLite in some hosting environments). * Since it's a cache, it should probably end up in files/db, similarly to files/css and files/js. Likewise, that means it should also be deleted when one Clears the cache under the Performance page in admin. This, along with your "rebuild when it disappears" change, would allow me to continue to do my MySQL {system} modifications without the cache getting too heavily in the way. -- Morbus Iff ( if god is my witness, god must be blind ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From sam at treslerdesigns.com Wed Feb 4 15:01:57 2009 From: sam at treslerdesigns.com (Sam Tresler) Date: Wed, 04 Feb 2009 10:01:57 -0500 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <200902040849.48286.jpetso@gmx.at> <99CCAE87-BFE2-4C3C-B415-DE9C6212ED2B@robshouse.net> Message-ID: <1233759717.6470.1.camel@localhost> If I understand chx correctly having the database in a deployable file would make installation even smoother AND install profiles would be able to come 'fully deployed' as all the modules will have been already set up in the system table. This isn't really a huge performance increase (although, a file read is faster than a db query). It will make deploying from staging a little trickier in multi server environments. -Sam chx correct me if I am wrong, but are those the main goals of this? On Wed, 2009-02-04 at 13:05 +0200, Ashraf Amayreh wrote: > Trying my best to understand the benefits of this. What benefits are > to be gained from moving these tables to an SQLite database? > Performance improvements? Does it ease anything for developers? What > exactly are the pros and cons? Whatever they are, they just don't hit > me as intuitive. > > On Wed, Feb 4, 2009 at 12:41 PM, Robert Douglass > wrote: > chx, are there also implications for how one would deploy > sites in your suggestion? Would it make it easier or harder to > move stuff from staging to production, for example? I'm > fascinated by your idea and think that if it can be made an > optional requirement (yes intentional wording), then it could > be very interesting. I encourage people to keep asking > questions until they understand the full idea, because so far > I think a lot of people essentially stopped reading at "Should > we require SQLite?" > > -Robert > > > > -- > Ashraf Amayreh > http://aamayreh.org > From karoly at negyesi.net Wed Feb 4 15:12:46 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 4 Feb 2009 07:12:46 -0800 Subject: [development] SQLite and Drupal 7 -- third coming Message-ID: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> Hi, Every morning, I am distilling the discussion. *) SQLite is not supported. If you have Drupal 5.2 and PDO which are already requirements then you have SQLite unless it's explicitly disabled and so far noone was able to answer the challenge at http://drupal4hu.com/node/177 . It's embedded into PHP so "supporting" it is like supporting the SimpleXML extension. Unlike MySQL where you need to run a separate server, here we have an embedded SQL engine right inside PDO. Also note that if we want (and I think we want) easier and more powerful install profiles then we will require SQLite for the install anyways. *) Deployment and rebuild. As it stands, now I believe that Drupal should be able to boot up enough to be able to copy the tables from MySQL to SQLite. I am not saying I am expecting it to be functional. After the tables are copied back into SQLite, it should either restart the bootstrap process or reload at the same URL. This solves deployment. *) Why do I want this? Once again, nicer code, especially for caching. Various pluggable subsystems (cache, session and path being the biggest wins here) will just work instead of ugly hacking. But in general, instead of trying to figure out during bootstrap coding "do we have a DB connection yet" the answer is always yes. Kind regards NK From mail at webthatworks.it Wed Feb 4 15:29:16 2009 From: mail at webthatworks.it (Ivan Sergio Borgonovo) Date: Wed, 4 Feb 2009 16:29:16 +0100 Subject: [development] kudos for change in api.drupal.org Message-ID: <20090204162916.2d4a0cf2@dawn.webthatworks.it> Nice job. Best thing is api comparison. It will make much easier to port. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it From ronald at istos.it Wed Feb 4 15:32:28 2009 From: ronald at istos.it (Ronald Ashri) Date: Wed, 04 Feb 2009 16:32:28 +0100 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> Message-ID: <4989B50C.1050602@istos.it> Hi, I think the main issue here is that chx is viewing things from the side of a Drupal Core developer while others are seeing it from the side of a user. The users don't particularly care that the code that bootstraps Drupal is nice (although they propably should!) so are mostly concerned about what's in it for them... 1. If I am a new Drupal user that just wants to install the thing and do usual stuff will this SQLite issue ever cross my radar? Will I notice it exists? (let's assume that my host setup supports it and I don't have to change anything myself) 2. If I am a web developer putting together Drupal sites everyday will this help me put them together sites any faster? 3. Will it help me save a site if a user messes things up? Will it help with upgrading to a new version of Drupal? 4. Will I need to touch it when I add or remove a module? If this affects ends users (in that it makes things more complex) then it needs to be seriously considered and it has a lot going against it. If it does not affect end users but makes the core code nicer and easier to handle then it has a lot going for it. One last note, anything that could make deploying a Drupal profile easier with the profile being as completely set-up as possible would be a huge bonus for Drupal. Best, Ronald Karoly Negyesi wrote: > Hi, > > Every morning, I am distilling the discussion. > > *) SQLite is not supported. If you have Drupal 5.2 and PDO which are > already requirements then you have SQLite unless it's explicitly > disabled and so far noone was able to answer the challenge at > http://drupal4hu.com/node/177 . It's embedded into PHP so "supporting" > it is like supporting the SimpleXML extension. Unlike MySQL where you > need to run a separate server, here we have an embedded SQL engine > right inside PDO. Also note that if we want (and I think we want) > easier and more powerful install profiles then we will require SQLite > for the install anyways. > > *) Deployment and rebuild. As it stands, now I believe that Drupal > should be able to boot up enough to be able to copy the tables from > MySQL to SQLite. I am not saying I am expecting it to be functional. > After the tables are copied back into SQLite, it should either restart > the bootstrap process or reload at the same URL. This solves > deployment. > > *) Why do I want this? Once again, nicer code, especially for caching. > Various pluggable subsystems (cache, session and path being the > biggest wins here) will just work instead of ugly hacking. But in > general, instead of trying to figure out during bootstrap coding "do > we have a DB connection yet" the answer is always yes. > > Kind regards > > NK > From damz at prealable.org Wed Feb 4 16:02:04 2009 From: damz at prealable.org (Damien Tournoud) Date: Wed, 4 Feb 2009 17:02:04 +0100 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <4989B50C.1050602@istos.it> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> Message-ID: Hi all, I'm all with chx on this one, supposing we manage to actually make it works. Main advantages: - the registry is local, we don't need to retrieve a big blob of cached data at each request. This is far more efficient for cluster scenarios, (by the way, the same could/should apply to the locale cache, which is currently nearly a 1MB blob of data, fetch from the database server at *each* request) - the bootstrap process will be simpler and more efficient. Currently, we can't guarantee that users or developpers will not see difficult to debug error messages or exceptions. Our autoloader is just not robust enough, because it has to fetch registry data from the database - hence initialize the database) before anything else. - we will be able to design database less scenarios. Drupal available right out of the box, with advanced installation profiles. That could lower a lot the barrier to entry of the software. Now to more answers: On Wed, Feb 4, 2009 at 4:32 PM, Ronald Ashri wrote: > 1. If I am a new Drupal user that just wants to install the thing and do > usual stuff will this SQLite issue ever cross my radar? Will I notice it > exists? (let's assume that my host setup supports it and I don't have to > change anything myself) No. That should be perfectly transparent to you. Just properly configure the files directory and everything will be done for you. > 2. If I am a web developer putting together Drupal sites everyday will this > help me put them together sites any faster? Yes. See above. 3. Will it help me save a site if a user messes things up? Will it help with > upgrading to a new version of Drupal? Not really. > 4. Will I need to touch it when I add or remove a module? No. The process should be completely transparent to you. Damien Tournoud -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/e7fcf184/attachment-0001.htm From cxjohnson at gmail.com Wed Feb 4 16:13:12 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 4 Feb 2009 10:13:12 -0600 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <498918E5.6050109@disobey.com> Message-ID: <9ea8d6030902040813o70497edcsa2ab93d849d03bb0@mail.gmail.com> It's a very interesting idea, as Robert said. Can you explain a bit further how the code is improved, and maybe a couple things which are enabled, by this idea? Which larger problem is being solved by this solution -- that is, where is the code really troublesome right now in handlers and implementing pluggable subsystems? ..chris On Tue, Feb 3, 2009 at 10:44 PM, Karoly Negyesi wrote: > Here we go. The big win is NOT performance. The big win is nice code. I forgot to mention this, silly me. So the problem is that currently we have a fairly ugly way to allow pluggable subsystems and they are not really flexible. You can pick one cache subsystem, that's it. We are planning something called handlers which will let you pick cache subsystems by the table for example. For this, we will change the cache implementations to become a class. However, if we want -- and yes, we want -- to serve cached pages without touching MySQL then we need to somehow specify the pathes to the cache and session implementation. If we have the registry available immediately then autoload just works. From cxjohnson at gmail.com Wed Feb 4 16:23:08 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 4 Feb 2009 10:23:08 -0600 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> Message-ID: <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> >From a security point of view, any time the web server process has write access to any directory or file, it makes me nervous. For this SQLite scheme to work, obviously the web server process will have to be able to create and update the file in which the SQLite database resides. This seems like it provides another possible vector for exploits. Tell me how we will protect against such attacks. ..chris On Wed, Feb 4, 2009 at 10:02 AM, Damien Tournoud wrote: > Hi all, > > I'm all with chx on this one, supposing we manage to actually make it works. > Main advantages: > > - the registry is local, we don't need to retrieve a big blob of cached data > at each request. This is far more efficient for cluster scenarios, (by the > way, the same could/should apply to the locale cache, which is currently > nearly a 1MB blob of data, fetch from the database server at *each* request) > > - the bootstrap process will be simpler and more efficient. Currently, we > can't guarantee that users or developpers will not see difficult to debug > error messages or exceptions. Our autoloader is just not robust enough, > because it has to fetch registry data from the database - hence initialize > the database) before anything else. > > - we will be able to design database less scenarios. Drupal available right > out of the box, with advanced installation profiles. That could lower a lot > the barrier to entry of the software. > > Now to more answers: > > On Wed, Feb 4, 2009 at 4:32 PM, Ronald Ashri wrote: >> >> 1. If I am a new Drupal user that just wants to install the thing and do >> usual stuff will this SQLite issue ever cross my radar? Will I notice it >> exists? (let's assume that my host setup supports it and I don't have to >> change anything myself) > > No. That should be perfectly transparent to you. Just properly configure the > files directory and everything will be done for you. > >> >> 2. If I am a web developer putting together Drupal sites everyday will >> this help me put them together sites any faster? > > Yes. See above. > >> 3. Will it help me save a site if a user messes things up? Will it help >> with upgrading to a new version of Drupal? > > Not really. > >> >> 4. Will I need to touch it when I add or remove a module? > > No. The process should be completely transparent to you. > > Damien Tournoud > > From drumm at delocalizedham.com Wed Feb 4 16:35:56 2009 From: drumm at delocalizedham.com (Neil Drumm) Date: Wed, 4 Feb 2009 11:35:56 -0500 Subject: [development] Drupal API Page with Comments? In-Reply-To: <0C0790C3-3A08-45C0-B917-26A10B3BDE4B@webchick.net> References: <0C0790C3-3A08-45C0-B917-26A10B3BDE4B@webchick.net> Message-ID: Excellent response. Basically, I want to fix the gaping holes in documentation, like objects not being documented, before adding new features. Additionally, some infrastructure issues need to be solved. api.drupal.org is currently a separate site. There is no way I am making another place to log in. We need to get single sign on working or merge sites first. We will be tackling this at the redesign sprint in Paris (http://drupal.org/node/356002). I will work with the documentation team to set the comment policy. A new place to add comments means we will also get spam, useless comments and comments that should be incorporated into the main documentation. -Neil On Tue, Feb 3, 2009 at 7:03 PM, Angela Byron wrote: > > On 3-Feb-09, at 6:58 PM, Margie Roswell wrote: > >> Hi, >> >> I think it would be enormously helpful to drupal users if a core and >> contributed modules API site enabled comments. >> >> Something like this: >> http://us.php.net/manual/en/function.is-array.php >> >> Is there any reason this couldn't be done? Throwing the idea out >> there. Is this the right place to post this idea, or is it better >> discussed somewhere else? Any technical or social reasons we shouldn't >> do this? > > Technical reasons, yes. See: http://drupal.org/node/101308, which is > postponed pending more important bug fixes like > http://drupal.org/node/300031 and http://drupal.org/node/100680 and > http://drupal.org/node/84207. > > In other words, if you want to see this happen, API module needs some love. > :) > > -Angie > > -- Neil Drumm http://delocalizedham.com From drumm at delocalizedham.com Wed Feb 4 16:40:09 2009 From: drumm at delocalizedham.com (Neil Drumm) Date: Wed, 4 Feb 2009 11:40:09 -0500 Subject: [development] kudos for change in api.drupal.org In-Reply-To: <20090204162916.2d4a0cf2@dawn.webthatworks.it> References: <20090204162916.2d4a0cf2@dawn.webthatworks.it> Message-ID: Thanks, more changes to make upgrading easier are coming after I fix more-pressing issues, like objects not being documented. Anything to make upgrading modules easier is a priority for me, Drupal 7 needs to be adopted faster than Drupal 6 has. -Neil On Wed, Feb 4, 2009 at 10:29 AM, Ivan Sergio Borgonovo wrote: > Nice job. > Best thing is api comparison. > It will make much easier to port. > > thanks > > -- > Ivan Sergio Borgonovo > http://www.webthatworks.it > > -- Neil Drumm http://delocalizedham.com From morbus at disobey.com Wed Feb 4 17:00:13 2009 From: morbus at disobey.com (Morbus Iff) Date: Wed, 04 Feb 2009 12:00:13 -0500 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> Message-ID: <4989C99D.1010807@disobey.com> >>From a security point of view, any time the web server process has > write access to any directory or file, it makes me nervous. For this > SQLite scheme to work, obviously the web server process will have to > be able to create and update the file in which the SQLite database > resides. This seems like it provides another possible vector for > exploits. Tell me how we will protect against such attacks. This brings up a good point, I believe. One potential avenue would be a webuser rewriting the file to point to a different directory for, say, the user.module, and then capturing all entered passwords in his own custom code. This isn't on the same mentality/vein as "well, we have to *trust* that the MySQL database is secure too, don't we?", because databases almost always get their own username and password - but the Apache webserver is most often run as a single user, without suexec'ing. -- Morbus Iff ( *splutch* ... /me respawns ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From andrewberry at sentex.net Wed Feb 4 17:15:23 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Wed, 4 Feb 2009 12:15:23 -0500 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <498990D8.70609@disobey.com> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <498918E5.6050109@disobey.com> <498990D8.70609@disobey.com> Message-ID: <9CC3C2E6-DC3D-4D51-AD2C-ADB728FBE3A4@sentex.net> On 4-Feb-09, at 7:58 AM, Morbus Iff wrote: > * If SQLite is built into PHP, use it (so, you'd do your function > exists around relevant pieces of code) Also important to ensure that in the case of migrating a site between systems that you don't have to do anything if SQLite isn't present. I'm sure most developers have SQLite on their own machines, and it would lead to significant confusion for newbies if they had to "prepare" their site before deploying on a host without SQLite. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090204/a6ac8e0b/attachment.bin From damz at prealable.org Wed Feb 4 17:18:35 2009 From: damz at prealable.org (Damien Tournoud) Date: Wed, 4 Feb 2009 18:18:35 +0100 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> Message-ID: On Wed, Feb 4, 2009 at 5:23 PM, Chris Johnson wrote: > From a security point of view, any time the web server process has > write access to any directory or file, it makes me nervous. For this > SQLite scheme to work, obviously the web server process will have to > be able to create and update the file in which the SQLite database > resides. This seems like it provides another possible vector for > exploits. Tell me how we will protect against such attacks. That's an excellent point. It has been chx' concern from the beginning. If you read http://drupal.org/node/367660, you will see that a whitelist of paths retrieved from the registry has been made just for that. Damien Tournoud -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/82e15fe4/attachment-0001.htm From andrewberry at sentex.net Wed Feb 4 17:20:48 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Wed, 4 Feb 2009 12:20:48 -0500 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <4989C99D.1010807@disobey.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> <4989C99D.1010807@disobey.com> Message-ID: <0CFFE891-697E-4ED4-96FF-0FA90EE06AE1@sentex.net> On 4-Feb-09, at 12:00 PM, Morbus Iff wrote: > This isn't on the same mentality/vein as "well, we have to *trust* > that the MySQL database is secure too, don't we?", because databases > almost always get their own username and password - but the Apache > webserver is most often run as a single user, without suexec'ing. Since the web server can read settings.php, presumably the SQL DB password could be extracted as well. So the same user module attack could be executed regardless of SQLite? --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090204/6dab887f/attachment.bin From morbus at disobey.com Wed Feb 4 17:25:17 2009 From: morbus at disobey.com (Morbus Iff) Date: Wed, 04 Feb 2009 12:25:17 -0500 Subject: [development] SQLite and Drupal 7 -- let's try this again In-Reply-To: <9CC3C2E6-DC3D-4D51-AD2C-ADB728FBE3A4@sentex.net> References: <7e270cea0902032009j77d26f01r68d14e706113d43b@mail.gmail.com> <498918E5.6050109@disobey.com> <498990D8.70609@disobey.com> <9CC3C2E6-DC3D-4D51-AD2C-ADB728FBE3A4@sentex.net> Message-ID: <4989CF7D.6000009@disobey.com> I retract any security concerns I had. The ones mentioned aren't. -- Morbus Iff ( i've no more shoulders, only chips ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From karoly at negyesi.net Wed Feb 4 17:55:09 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 04 Feb 2009 18:55:09 +0100 (CET) Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> Message-ID: > >From a security point of view, any time the web server process has > write access to any directory or file, it makes me nervous. For this > SQLite scheme to work, obviously the web server process will have to > be able to create and update the file in which the SQLite database > resides. This seems like it provides another possible vector for > exploits. Tell me how we will protect against such attacks. I find your lack of faith disturbing :P For two months I am aware http://drupal.org/node/332303#comment-1145308 of this problem and I have only brought the question of SQLite to the greater public now that I have http://drupal.org/node/367660 a solution. From cxjohnson at gmail.com Wed Feb 4 19:08:18 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 4 Feb 2009 13:08:18 -0600 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <4989B50C.1050602@istos.it> <9ea8d6030902040823n53b4c5f9h6b8fe781a17cdc94@mail.gmail.com> Message-ID: <9ea8d6030902041108p1788d3a9k774c614e37e79987@mail.gmail.com> Heh. I have plenty of faith in your, Karoly. I just like to make sure everything is covered. Humans sometimes overlook obvious things. :-) I like the whitelist idea for paths. Nice. ..chris On Wed, Feb 4, 2009 at 11:55 AM, Karoly Negyesi wrote: >> >From a security point of view, any time the web server process has >> write access to any directory or file, it makes me nervous. For this >> SQLite scheme to work, obviously the web server process will have to >> be able to create and update the file in which the SQLite database >> resides. This seems like it provides another possible vector for >> exploits. Tell me how we will protect against such attacks. > > I find your lack of faith disturbing :P For two months I am aware http://drupal.org/node/332303#comment-1145308 of this problem and I have only brought the question of SQLite to the greater public now that I have http://drupal.org/node/367660 a solution. > From cooperq at cooperq.com Wed Feb 4 20:24:47 2009 From: cooperq at cooperq.com (cooper Quintin) Date: Wed, 04 Feb 2009 12:24:47 -0800 Subject: [development] url as callback argument In-Reply-To: <4f097c7f0902032209t3d37de11me791e0d20f9e84c8@mail.gmail.com> References: <49881DBB.8050301@cooperq.com> <4f097c7f0902030708h191659fekbc602dd71105a492@mail.gmail.com> <200902040032.38848.jpetso@gmx.at> <4f097c7f0902032209t3d37de11me791e0d20f9e84c8@mail.gmail.com> Message-ID: <4989F98F.4070907@cooperq.com> Since I started this thread I feel it is my duty to put it to rest. The problem was indeed that I had callback_args instead of callback arguments, sorry to bother this list with my stupid typo. Additionally the below poster is correct, there is no wildcard in paths in drupal 5 which was also giving me some interesting problems. I thought that the development list was intended for all development of drupal and its modules but I guess its only for drupal core development, sorry about that! Anyway, I declare this thread closed, thanks everyone for your help. Cooper I?aki Lopez wrote: > sorry, I don't know how did I realize the drupal version was six, and > my reply was a "finish-porting-this-to-d6".. > Now I see, only half of the menu entry is 'ported' as well.. > > Indeed, a very bad advice at all.. where the hell is my head?.. brbr > > On Wed, Feb 4, 2009 at 12:32 AM, Jakob Petsovits > wrote: > > On Tuesday 03 February 2009, I?aki Lopez wrote: > > $items[] = array( > > 'path' => 'admin/settings/featured-comments/feature', > > 'title' => t('featured comment'), > > 'callback' => 'feature_comment', > > 'callback_args' => $_GET['cid'], > > > > should be.. > > > > $items[] = array( > > 'path' => 'admin/settings/featured-comments/feature/%', > > 'title' => t('featured comment'), > > 'callback' => 'feature_comment', > > 'callback_args' =>array(4), > > ... > > Bad advice: > > 1. There is no '%' wildcard in Drupal 5, and Drupal 6 puts the > path as array > key instead of having a separate 'path' element. > > 2. There is no 'callback_args' property. array(...) is correct, > but it also > needs to be renamed to 'callback arguments' for Drupal to do > anything with it. > In Drupal 5, that would be "'callback arguments' => > array($_GET['cid'])". > (Or 'page callback' and 'page arguments' in Drupal 6, which I > understand the > original poster is not using at this time.) > > Maybe the thread is better off dead - > http://api.drupal.org/api/function/hook_menu/5 has been posted > already - > but it's hard to leave the above example uncommented as is. > > Cheers, > j > > -- Cooper Quintin Freelance Programmer, Indymedia Journalist http://CooperQ.com (510) 827-5382 From kb at 2bits.com Wed Feb 4 21:28:19 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Wed, 4 Feb 2009 16:28:19 -0500 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> Message-ID: <4a9fdc630902041328p4af4b7c8rb470bf9b0c4e7927@mail.gmail.com> My concerns are extra dependencies, complexity of deployment, making it mandatory, ...etc. But now I am starting to see the benefits of this now, having been a bit skeptical at first. On Wed, Feb 4, 2009 at 10:12 AM, Karoly Negyesi wrote: > If you have Drupal 5.2 and PDO which are already requirements then you > have SQLite unless it's explicitly disabled You mean *PHP* 5.2, right? Which is the minimum for Drupal 7.x. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/3aec35b4/attachment.htm From larry at garfieldtech.com Wed Feb 4 23:03:34 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Wed, 4 Feb 2009 17:03:34 -0600 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> Message-ID: <94ed0337c8594452daf376472cdb374d@localhost> So I am still -1 on requiring SQLite in order for Drupal to function. However, I am leaning more and more toward automatically using it if available. I am still not convinced that we can always assume PHP 5.2 => SQLite with no further effort. Some distros do weird things (eg, Debian as someone mentioned already). I also think the ability to do a complete migration or backup just using the primary DB is a critically important feature for maintainability, and having to migrate a magical file on disk as well is a major WTF for users used to WordPress. (And let's face it, that's a major market we need to be able to hit.) However, the idea of treating it as a cache-like system has a lot of merit, especially as it is possible to then run without it. It's possible (although not recommended) to run without the CSS compressor, clean URLs, etc. A "system cache SQLite database" could be treated in the same way. That is, the logic in bootstrap would be something like: if (we can open the magic DB) { Open it and assign it to connection key default, target "system". } elseif (it doesn't exist) { Try to create it. Populate it off of the main DB. Open it and assign it to connection key default, target "system". } elseif (we can't create the DB) { Do nothing. Queries run against the "system" target will just run against the main DB on their own. } OK, we'll probably want to speed optimize that somewhat since it's on the critical path, but you get the idea. Then a drupal_flush_caches() would simply delete that DB. On the installer front, what if installers do not REQUIRE an SQLite to work, but require them for certain features? So "advanced" install profiles can require SQLite, but the basic ones don't. --Larry Garfield On Wed, 4 Feb 2009 07:12:46 -0800, Karoly Negyesi wrote: > Hi, > > Every morning, I am distilling the discussion. > > *) SQLite is not supported. If you have Drupal 5.2 and PDO which are > already requirements then you have SQLite unless it's explicitly > disabled and so far noone was able to answer the challenge at > http://drupal4hu.com/node/177 . It's embedded into PHP so "supporting" > it is like supporting the SimpleXML extension. Unlike MySQL where you > need to run a separate server, here we have an embedded SQL engine > right inside PDO. Also note that if we want (and I think we want) > easier and more powerful install profiles then we will require SQLite > for the install anyways. > > *) Deployment and rebuild. As it stands, now I believe that Drupal > should be able to boot up enough to be able to copy the tables from > MySQL to SQLite. I am not saying I am expecting it to be functional. > After the tables are copied back into SQLite, it should either restart > the bootstrap process or reload at the same URL. This solves > deployment. > > *) Why do I want this? Once again, nicer code, especially for caching. > Various pluggable subsystems (cache, session and path being the > biggest wins here) will just work instead of ugly hacking. But in > general, instead of trying to figure out during bootstrap coding "do > we have a DB connection yet" the answer is always yes. > > Kind regards > > NK From hovercrafter at earthlink.net Wed Feb 4 23:16:55 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Wed, 04 Feb 2009 18:16:55 -0500 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <94ed0337c8594452daf376472cdb374d@localhost> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> Message-ID: <498A21E7.1070106@earthlink.net> What impact would this have on sites utilizing multiple Apache/PHP servers? I'm not that up on SQLite, but I was always under the impression it was more or less designed for a single server scenario (though I guess you could put the file on a shared file system, which of course opens up a whole new can of worms). Jamie Holly Larry Garfield wrote: > So I am still -1 on requiring SQLite in order for Drupal to function. However, I am leaning more and more toward automatically using it if available. > > I am still not convinced that we can always assume PHP 5.2 => SQLite with no further effort. Some distros do weird things (eg, Debian as someone mentioned already). I also think the ability to do a complete migration or backup just using the primary DB is a critically important feature for maintainability, and having to migrate a magical file on disk as well is a major WTF for users used to WordPress. (And let's face it, that's a major market we need to be able to hit.) > > However, the idea of treating it as a cache-like system has a lot of merit, especially as it is possible to then run without it. It's possible (although not recommended) to run without the CSS compressor, clean URLs, etc. A "system cache SQLite database" could be treated in the same way. > > That is, the logic in bootstrap would be something like: > > if (we can open the magic DB) { > Open it and assign it to connection key default, target "system". > } > elseif (it doesn't exist) { > Try to create it. > Populate it off of the main DB. > Open it and assign it to connection key default, target "system". > } > elseif (we can't create the DB) { > Do nothing. Queries run against the "system" target will just run against the main DB on their own. > } > > OK, we'll probably want to speed optimize that somewhat since it's on the critical path, but you get the idea. Then a drupal_flush_caches() would simply delete that DB. > > On the installer front, what if installers do not REQUIRE an SQLite to work, but require them for certain features? So "advanced" install profiles can require SQLite, but the basic ones don't. > > --Larry Garfield > > On Wed, 4 Feb 2009 07:12:46 -0800, Karoly Negyesi wrote: > > Hi, > > > > Every morning, I am distilling the discussion. > > > > *) SQLite is not supported. If you have Drupal 5.2 and PDO which are > > already requirements then you have SQLite unless it's explicitly > > disabled and so far noone was able to answer the challenge at > > http://drupal4hu.com/node/177 . It's embedded into PHP so "supporting" > > it is like supporting the SimpleXML extension. Unlike MySQL where you > > need to run a separate server, here we have an embedded SQL engine > > right inside PDO. Also note that if we want (and I think we want) > > easier and more powerful install profiles then we will require SQLite > > for the install anyways. > > > > *) Deployment and rebuild. As it stands, now I believe that Drupal > > should be able to boot up enough to be able to copy the tables from > > MySQL to SQLite. I am not saying I am expecting it to be functional. > > After the tables are copied back into SQLite, it should either restart > > the bootstrap process or reload at the same URL. This solves > > deployment. > > > > *) Why do I want this? Once again, nicer code, especially for caching. > > Various pluggable subsystems (cache, session and path being the > > biggest wins here) will just work instead of ugly hacking. But in > > general, instead of trying to figure out during bootstrap coding "do > > we have a DB connection yet" the answer is always yes. > > > > Kind regards > > > > NK > > > From victorkane at gmail.com Wed Feb 4 23:26:00 2009 From: victorkane at gmail.com (Victor Kane) Date: Wed, 4 Feb 2009 21:26:00 -0200 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <498A21E7.1070106@earthlink.net> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> <498A21E7.1070106@earthlink.net> Message-ID: Drupal Lite! On Wed, Feb 4, 2009 at 9:16 PM, Jamie Holly wrote: > What impact would this have on sites utilizing multiple Apache/PHP servers? > I'm not that up on SQLite, but I was always under the impression it was more > or less designed for a single server scenario (though I guess you could put > the file on a shared file system, which of course opens up a whole new can > of worms). > > Jamie Holly > > > > > > Larry Garfield wrote: > >> So I am still -1 on requiring SQLite in order for Drupal to function. >> However, I am leaning more and more toward automatically using it if >> available. >> >> I am still not convinced that we can always assume PHP 5.2 => SQLite with >> no further effort. Some distros do weird things (eg, Debian as someone >> mentioned already). I also think the ability to do a complete migration or >> backup just using the primary DB is a critically important feature for >> maintainability, and having to migrate a magical file on disk as well is a >> major WTF for users used to WordPress. (And let's face it, that's a major >> market we need to be able to hit.) >> >> However, the idea of treating it as a cache-like system has a lot of >> merit, especially as it is possible to then run without it. It's possible >> (although not recommended) to run without the CSS compressor, clean URLs, >> etc. A "system cache SQLite database" could be treated in the same way. >> >> That is, the logic in bootstrap would be something like: >> >> if (we can open the magic DB) { >> Open it and assign it to connection key default, target "system". >> } >> elseif (it doesn't exist) { >> Try to create it. >> Populate it off of the main DB. >> Open it and assign it to connection key default, target "system". >> } >> elseif (we can't create the DB) { >> Do nothing. Queries run against the "system" target will just run >> against the main DB on their own. >> } >> >> OK, we'll probably want to speed optimize that somewhat since it's on the >> critical path, but you get the idea. Then a drupal_flush_caches() would >> simply delete that DB. >> >> On the installer front, what if installers do not REQUIRE an SQLite to >> work, but require them for certain features? So "advanced" install profiles >> can require SQLite, but the basic ones don't. >> >> --Larry Garfield >> >> On Wed, 4 Feb 2009 07:12:46 -0800, Karoly Negyesi >> wrote: >> > Hi, >> > > Every morning, I am distilling the discussion. >> > > *) SQLite is not supported. If you have Drupal 5.2 and PDO which are >> > already requirements then you have SQLite unless it's explicitly >> > disabled and so far noone was able to answer the challenge at >> > http://drupal4hu.com/node/177 . It's embedded into PHP so "supporting" >> > it is like supporting the SimpleXML extension. Unlike MySQL where you >> > need to run a separate server, here we have an embedded SQL engine >> > right inside PDO. Also note that if we want (and I think we want) >> > easier and more powerful install profiles then we will require SQLite >> > for the install anyways. >> > > *) Deployment and rebuild. As it stands, now I believe that Drupal >> > should be able to boot up enough to be able to copy the tables from >> > MySQL to SQLite. I am not saying I am expecting it to be functional. >> > After the tables are copied back into SQLite, it should either restart >> > the bootstrap process or reload at the same URL. This solves >> > deployment. >> > > *) Why do I want this? Once again, nicer code, especially for caching. >> > Various pluggable subsystems (cache, session and path being the >> > biggest wins here) will just work instead of ugly hacking. But in >> > general, instead of trying to figure out during bootstrap coding "do >> > we have a DB connection yet" the answer is always yes. >> > > Kind regards >> > > NK >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090204/0943e54d/attachment.htm From damz at prealable.org Wed Feb 4 23:45:31 2009 From: damz at prealable.org (Damien Tournoud) Date: Thu, 5 Feb 2009 00:45:31 +0100 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <94ed0337c8594452daf376472cdb374d@localhost> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> Message-ID: On Thu, Feb 5, 2009 at 12:03 AM, Larry Garfield wrote: > > So I am still -1 on requiring SQLite in order for Drupal to function. > However, I am leaning more and more toward automatically using it if > available. > > [...] > However, the idea of treating it as a cache-like system has a lot of merit, > especially as it is possible to then run without it. It's possible > (although not recommended) to run without the CSS compressor, clean URLs, > etc. A "system cache SQLite database" could be treated in the same way. Apparently you are completely missing the point chx is trying to make. Damien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/3fa22912/attachment.htm From weitzman at tejasa.com Thu Feb 5 00:28:27 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed, 4 Feb 2009 19:28:27 -0500 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <94ed0337c8594452daf376472cdb374d@localhost> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> Message-ID: <6117a7500902041628s67ab8851o756a0a6803584d4f@mail.gmail.com> > So I am still -1 on requiring SQLite in order for Drupal to function. However, I am leaning more and more toward automatically using it if available. Stop. Read. We only get the primary benefit (code cleanliness) if we *require* SQLite. There is no point in doing this half-way. If you know of web hosts where Drupal would no longer work, please take the challenge at http://drupal4hu.com/node/177. So far, no such place is known. Also, Lets stop talking about deployment. chx solved that (no code yet). Apache would write SQLite file when it needs to. Site admins can be oblivious. From dmitrig01 at gmail.com Thu Feb 5 00:39:28 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Wed, 4 Feb 2009 16:39:28 -0800 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <6117a7500902041628s67ab8851o756a0a6803584d4f@mail.gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> <6117a7500902041628s67ab8851o756a0a6803584d4f@mail.gmail.com> Message-ID: <23C4F660-D8CA-4121-A45F-30D38FEC2E1E@gmail.com> I understand how this improves installation, and i think it's fine to require it for installation, however I think that it should be optional after installation. Dmitri On Feb 4, 2009, at 4:28 PM, Moshe Weitzman wrote: >> So I am still -1 on requiring SQLite in order for Drupal to >> function. However, I am leaning more and more toward automatically >> using it if available. > > Stop. Read. We only get the primary benefit (code cleanliness) if we > *require* SQLite. There is no point in doing this half-way. If you > know of web hosts where Drupal would no longer work, please take the > challenge at http://drupal4hu.com/node/177. So far, no such place is > known. > > Also, Lets stop talking about deployment. chx solved that (no code > yet). Apache would write SQLite file when it needs to. Site admins can > be oblivious. From swateekarpe at gmail.com Thu Feb 5 08:11:23 2009 From: swateekarpe at gmail.com (Swatee Karpe) Date: Thu, 5 Feb 2009 13:41:23 +0530 Subject: [development] phpbbforum module into drupal settings are not displaying fully Message-ID: <556cd02b0902050011s13dcddbck4d2281e354e4c45a@mail.gmail.com> Hi all, I have one problem while installing phpbbforum into drupal as follow : (if possible give me the solutions ) I use drupal 6x and phpBB3 I install phpBB3 into drupal directory. and now i m trying to add phpforum module into drupal for integrating phpBB3 to my drupal site. But my problem is that when i enable the module and go to phpbbforum module settings it not display phpBBforum status options : it display only errors as follows : Error locating phpBB installation. Please fix your settings! Error locating . Please fix your settings! Unable to connect to the phpBB database. Please fix your settings! and next display phpBB location settings phpBB forum root path: [ 1 textbox here ] where we have to give Path to forum directory. Enter the full directory path where phpBB is installed. so please help me, how to solved following problem phpBBforum status options : it display only errors as follows : Error locating phpBB installation. Please fix your settings! Error locating . Please fix your settings! Unable to connect to the phpBB database. Please fix your settings! is any settings was wrong into my installation?? thx in adv. -- Regards Swatee Amit Karpe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/e6f169e9/attachment-0001.htm From naheemzaffar at gmail.com Thu Feb 5 11:34:13 2009 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 5 Feb 2009 11:34:13 +0000 Subject: [development] phpbbforum module into drupal settings are not displaying fully In-Reply-To: <556cd02b0902050011s13dcddbck4d2281e354e4c45a@mail.gmail.com> References: <556cd02b0902050011s13dcddbck4d2281e354e4c45a@mail.gmail.com> Message-ID: <3adc77210902050334u6646ae59r725c82752e6c7b5e@mail.gmail.com> Hi, Have you considered simply importing the data and using the default drupal forums? (maybe with Advanced_forums to return the more traditional look)? the phpbb2drupal module should handle the necessary data conversion. Alternatively, it maybe a good idea to raise a support request on the phpbbforum module's issue queue. Kind Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/bf686618/attachment.htm From martin at siarp.de Thu Feb 5 12:46:07 2009 From: martin at siarp.de (Martin Stadler) Date: Thu, 5 Feb 2009 13:46:07 +0100 Subject: [development] Curl-based content generation Message-ID: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Hi! I'm working on a small curl-based script to add content to a drupal-6 site. Logging-in (getting cookie etc) works fine but when I try to add content I get a validation error. I guess it's about security. Is it at all possible to do what I'm trying? Is there documention how these form tokens actually work and what is required? I couldn't find that in the formAPI docs. Here's the code: # login curl http://localhost/USA08/user \ -F 'name=Martin' \ -F 'pass=pass' \ -F 'form_id=user_login' \ -F 'op=Log in' \ --output /Users/martin/response.html \ -s \ -c /tmp/curl-cookies.txt \ -b /tmp/curl-cookies.txt # -> works: response.html says I'm logged-in # add page curl http://localhost/USA08/node/add/page \ -F 'title=xyz' \ -F 'teaser_include=1' \ -F 'body=abc' \ -F 'format=1' \ -F 'changed=' \ -F 'form_id=page_node_form' \ -F 'log=' \ -F 'comment=0' \ -F 'name=Martin' \ -F 'date=' \ -F 'status=1' \ -F 'op=Save' \ --output /Users/martin/response2.html \ -s \ -c /tmp/curl-cookies.txt \ -b /tmp/curl-cookies.txt # -> does not work: response2.html says 'Validation error, please try again. If this error persists, please contact the site administrator.' Regards, Martin From mfioretti at nexaima.net Thu Feb 5 13:03:59 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 5 Feb 2009 14:03:59 +0100 Subject: [development] Curl-based content generation In-Reply-To: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Message-ID: <20090205130359.GC8831@nexaima.net> On Thu, Feb 05, 2009 13:46:07 PM +0100, Martin Stadler wrote: > Hi! > > I'm working on a small curl-based script to add content to a drupal-6 > site. Logging-in (getting cookie etc) works fine but when I try to add > content I get a validation error. I guess it's about security. Is it at > all possible to do what I'm trying? Martin, possible, it's possible. I *had* made something like this work with Drupal 4.x. Then I abandoned that project but asked here about the best way to resurrect it just one month ago (the "Info needed to add content to Drupal via shell/curl script"). Due to more urgent tasks I have had to abandon that project again for the moment, but I'm still very interested, so please keep me posted even off list if you succeed, please. This said, > Is there documention how these form tokens actually work and what is > required? I couldn't find that in the formAPI docs. this is the same problem I had, IIRC. The basic flow is simple, conceptually. The problem is: 1) how does one know in advance what is the exact sequence of pages to visit, that is of Urls to pass to curl? 2) how does one know **in advance**, without going by trial and error, what are all the fields one should pass to curl each time, via -F? 3) how can one know **in advance** the list of admissible values for each field of each form (especially taxonomy terms??)? 4) can we be confident minor upgrades won't break the script, that is that the answers above won't change going from 6.x to 6.x+1? 5) Am I missing something else here? As a wild, really wild guess, I **believe** that this problem you have: > # -> does not work: response2.html says 'Validation error, please try > again. If this error persists, please contact the site administrator.' may be due to point 1 above, that is you didn't call all the pages Drupal wants you to visit, in the right order. One part of the problem is that answers to questions 2 and 3 are different for each site, that is they depend on which modules and node types you have active, how many categories there are and how many values they have, if you can upload attachments or not, etc... For me, what would be great would be to have some simple method to know these information via mysql. In other words, what is/are the mysql query(es) on the server that would return a lists of all the parameters asked by questions 2 and 3 above? So, I have no specific answers, but I hope that this post helps us to get them from the developers. HTH, Marco -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From martin at siarp.de Thu Feb 5 14:41:15 2009 From: martin at siarp.de (Martin Stadler) Date: Thu, 5 Feb 2009 15:41:15 +0100 Subject: [development] Curl-based content generation In-Reply-To: <20090205130359.GC8831@nexaima.net> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090205130359.GC8831@nexaima.net> Message-ID: <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> This cannot be a general approach to add content to an arbitrary Drupal site. Your points are valid and if you need that you need to write a module providing an API or use SQL directly. What I'm trying to do is writing a very custom one-time script to add content automatically to a certain site. So I can find out about the form details once in advance and that should be it. Yes, it may depend on what modules you have enabled and form details may change even in minor Drupal versions (security fixes i.e.). I'm aware of that and I'd adjust my script accordingly in that case. I just want to know what I need to send to add content to the default page content type with no modifications for the latest stable Drupal 6 release. Martin Am 05.02.2009 um 14:03 schrieb M. Fioretti: > On Thu, Feb 05, 2009 13:46:07 PM +0100, Martin Stadler wrote: >> Hi! >> >> I'm working on a small curl-based script to add content to a drupal-6 >> site. Logging-in (getting cookie etc) works fine but when I try to >> add >> content I get a validation error. I guess it's about security. Is >> it at >> all possible to do what I'm trying? > > Martin, > > possible, it's possible. I *had* made something like this work with > Drupal 4.x. Then I abandoned that project but asked here about the > best way to resurrect it just one month ago (the "Info needed to add > content to Drupal via shell/curl script"). Due to more urgent tasks I > have had to abandon that project again for the moment, but I'm still > very interested, so please keep me posted even off list if you > succeed, please. This said, > >> Is there documention how these form tokens actually work and what is >> required? I couldn't find that in the formAPI docs. > > this is the same problem I had, IIRC. The basic flow is simple, > conceptually. The problem is: > > 1) how does one know in advance what is the exact sequence of pages to > visit, that is of Urls to pass to curl? > > 2) how does one know **in advance**, without going by trial and error, > what are all the fields one should pass to curl each time, via -F? > > 3) how can one know **in advance** the list of admissible values for > each field of each form (especially taxonomy terms??)? > > 4) can we be confident minor upgrades won't break the script, that is > that the answers above won't change going from 6.x to 6.x+1? > > 5) Am I missing something else here? > > As a wild, really wild guess, I **believe** that this problem you > have: > >> # -> does not work: response2.html says 'Validation error, please try >> again. If this error persists, please contact the site >> administrator.' > > may be due to point 1 above, that is you didn't call all the pages > Drupal wants you to visit, in the right order. > > One part of the problem is that answers to questions 2 and 3 are > different for each site, that is they depend on which modules and node > types you have active, how many categories there are and how many > values they have, if you can upload attachments or not, etc... For me, > what would be great would be to have some simple method to know these > information via mysql. In other words, what is/are the mysql query(es) > on the server that would return a lists of all the parameters asked by > questions 2 and 3 above? > > So, I have no specific answers, but I hope that this post helps us to > get them from the developers. > > HTH, > Marco > -- > Your own civil rights and the quality of your life heavily depend on > how > software is used *around* you: http://digifreedom.net/node/84 > From darthsteven at gmail.com Thu Feb 5 14:47:40 2009 From: darthsteven at gmail.com (Steven Jones) Date: Thu, 5 Feb 2009 14:47:40 +0000 Subject: [development] Curl-based content generation In-Reply-To: <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090205130359.GC8831@nexaima.net> <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> Message-ID: Hi Martin, The FormAPI generates a security token, I'm not sure if it's something in the session or returned in the form iteself (the latter I think). So you'll probably want to visit the page your form is on, grab the variables and post them back in your submission. Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 0121 288 0434 Mobile : 07951 270 026 http://www.computerminds.co.uk 2009/2/5 Martin Stadler : > This cannot be a general approach to add content to an arbitrary Drupal > site. Your points are valid and if you need that you need to write a module > providing an API or use SQL directly. > > What I'm trying to do is writing a very custom one-time script to add > content automatically to a certain site. So I can find out about the form > details once in advance and that should be it. Yes, it may depend on what > modules you have enabled and form details may change even in minor Drupal > versions (security fixes i.e.). I'm aware of that and I'd adjust my script > accordingly in that case. > > I just want to know what I need to send to add content to the default page > content type with no modifications for the latest stable Drupal 6 release. > > Martin > > > Am 05.02.2009 um 14:03 schrieb M. Fioretti: > >> On Thu, Feb 05, 2009 13:46:07 PM +0100, Martin Stadler wrote: >>> >>> Hi! >>> >>> I'm working on a small curl-based script to add content to a drupal-6 >>> site. Logging-in (getting cookie etc) works fine but when I try to add >>> content I get a validation error. I guess it's about security. Is it at >>> all possible to do what I'm trying? >> >> Martin, >> >> possible, it's possible. I *had* made something like this work with >> Drupal 4.x. Then I abandoned that project but asked here about the >> best way to resurrect it just one month ago (the "Info needed to add >> content to Drupal via shell/curl script"). Due to more urgent tasks I >> have had to abandon that project again for the moment, but I'm still >> very interested, so please keep me posted even off list if you >> succeed, please. This said, >> >>> Is there documention how these form tokens actually work and what is >>> required? I couldn't find that in the formAPI docs. >> >> this is the same problem I had, IIRC. The basic flow is simple, >> conceptually. The problem is: >> >> 1) how does one know in advance what is the exact sequence of pages to >> visit, that is of Urls to pass to curl? >> >> 2) how does one know **in advance**, without going by trial and error, >> what are all the fields one should pass to curl each time, via -F? >> >> 3) how can one know **in advance** the list of admissible values for >> each field of each form (especially taxonomy terms??)? >> >> 4) can we be confident minor upgrades won't break the script, that is >> that the answers above won't change going from 6.x to 6.x+1? >> >> 5) Am I missing something else here? >> >> As a wild, really wild guess, I **believe** that this problem you have: >> >>> # -> does not work: response2.html says 'Validation error, please try >>> again. If this error persists, please contact the site administrator.' >> >> may be due to point 1 above, that is you didn't call all the pages >> Drupal wants you to visit, in the right order. >> >> One part of the problem is that answers to questions 2 and 3 are >> different for each site, that is they depend on which modules and node >> types you have active, how many categories there are and how many >> values they have, if you can upload attachments or not, etc... For me, >> what would be great would be to have some simple method to know these >> information via mysql. In other words, what is/are the mysql query(es) >> on the server that would return a lists of all the parameters asked by >> questions 2 and 3 above? >> >> So, I have no specific answers, but I hope that this post helps us to >> get them from the developers. >> >> HTH, >> Marco >> -- >> Your own civil rights and the quality of your life heavily depend on how >> software is used *around* you: http://digifreedom.net/node/84 >> > > From darrenoh at sidepotsinternational.com Thu Feb 5 14:56:29 2009 From: darrenoh at sidepotsinternational.com (Darren Oh) Date: Thu, 5 Feb 2009 09:56:29 -0500 Subject: [development] Curl-based content generation Message-ID: This may be easiest to do with XMLRPC. See http://drupal.org/node/82114. On Feb 5, 2009, at 9:41 AM, Martin Stadler wrote: > What I'm trying to do is writing a very custom one-time script to add > content automatically to a certain site. So I can find out about the > form details once in advance and that should be it. Yes, it may depend > on what modules you have enabled and form details may change even in > minor Drupal versions (security fixes i.e.). I'm aware of that and I'd > adjust my script accordingly in that case. > > I just want to know what I need to send to add content to the default > page content type with no modifications for the latest stable Drupal 6 > release. > > Martin From mfioretti at nexaima.net Thu Feb 5 15:02:40 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 5 Feb 2009 16:02:40 +0100 Subject: [development] Curl-based content generation In-Reply-To: <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090205130359.GC8831@nexaima.net> <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> Message-ID: <20090205150240.GM8831@nexaima.net> On Thu, Feb 05, 2009 15:41:15 PM +0100, Martin Stadler wrote: > This cannot be a general approach to add content to an arbitrary Drupal > site. Your points are valid and if you need that you need to write a > module providing an API or use SQL directly. I am well aware that this job must be (partly) redone for each Drupal site one needs to work. I'm fine with that, but I want a solution which works even if I have no shell access to the server where Drupal runs, or if I cannot install modules there. > What I'm trying to do is writing a very custom one-time script to > add content automatically to a certain site. same for me, really. Ditto for the rest of your reply. So we agree (I think) that the problem is not writing scripts manually for each site we want to access, is to avoid, if possible, lots of guesses and blind trials just to know what we should write in those scripts. This is where, I think, we'd both need help from the core developers who knows Drupal sql tables in detail. Important: at least for me, there is no problem to run sql queries on the server to get all the fields I should fill via Curl. That is a one-time job I can do myself or ask the webmaster to do for me. When I said above "solution which works even without shell access" I refer to when I _use_ the script (**) which I'd write using the info which I hope to find through this list. (**) Once written, a curl script would only need the http port open, so it would work behind any firewall I've come across so far. Whereas to run scripts on the server, even if I had a shell account, I would need the ssh port to use them, which may or may not be open in some places. Marco -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From earnie at users.sourceforge.net Thu Feb 5 15:45:29 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 05 Feb 2009 10:45:29 -0500 Subject: [development] Curl-based content generation In-Reply-To: <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090205130359.GC8831@nexaima.net> <25CA1A4F-5FBC-45F2-85CC-136ACFF3DB49@siarp.de> Message-ID: <20090205104529.uh567uz3m9es0swo@mail.progw.org> Quoting Martin Stadler : > This cannot be a general approach to add content to an arbitrary > Drupal site. Your points are valid and if you need that you need to > write a module providing an API or use SQL directly. > > What I'm trying to do is writing a very custom one-time script to add > content automatically to a certain site. So I can find out about the > form details once in advance and that should be it. Yes, it may > depend on what modules you have enabled and form details may change > even in minor Drupal versions (security fixes i.e.). I'm aware of > that and I'd adjust my script accordingly in that case. > > I just want to know what I need to send to add content to the default > page content type with no modifications for the latest stable Drupal > 6 release. > I build a node object and pass it to node_save [1] and execute cron batch style. [1] http://api.drupal.org/api/function/node_save -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From andrewberry at sentex.net Thu Feb 5 16:02:50 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Thu, 5 Feb 2009 11:02:50 -0500 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <23C4F660-D8CA-4121-A45F-30D38FEC2E1E@gmail.com> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> <6117a7500902041628s67ab8851o756a0a6803584d4f@mail.gmail.com> <23C4F660-D8CA-4121-A45F-30D38FEC2E1E@gmail.com> Message-ID: <7CDD8E64-7EEA-42D6-91E6-9F80A8D6E979@sentex.net> Has anyone looked into version compatibility between the different versions of sqlite? For example, on the same ISP, one server I checked has sqlite2, the other has sqlite3. Neither server has both drivers installed. Neither server actually has the sqlite binaries installed, though I assume that isn't common, but worth checking on other SQLite supporting hosts. The SQLite site mentions using the command line tools to dump and restore the DB, and I haven't found anything about doing that from pure PHP. This probably wouldn't be an issue for caches and such, since an incompatible DB can just be recreated. I could see it causing headaches for "Drupal Lite" scenarios. http://www.sqlite.org/formatchng.html On 4-Feb-09, at 7:39 PM, Dmitri Gaskin wrote: > I understand how this improves installation, and i think it's fine > to require it for installation, however I think that it should be > optional after installation. > > Dmitri > > On Feb 4, 2009, at 4:28 PM, Moshe Weitzman wrote: > >>> So I am still -1 on requiring SQLite in order for Drupal to >>> function. However, I am leaning more and more toward >>> automatically using it if available. >> >> Stop. Read. We only get the primary benefit (code cleanliness) if we >> *require* SQLite. There is no point in doing this half-way. If you >> know of web hosts where Drupal would no longer work, please take the >> challenge at http://drupal4hu.com/node/177. So far, no such place is >> known. >> >> Also, Lets stop talking about deployment. chx solved that (no code >> yet). Apache would write SQLite file when it needs to. Site admins >> can >> be oblivious. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090205/d070c26c/attachment.bin From damz at prealable.org Thu Feb 5 16:15:14 2009 From: damz at prealable.org (Damien Tournoud) Date: Thu, 5 Feb 2009 17:15:14 +0100 Subject: [development] SQLite and Drupal 7 -- third coming In-Reply-To: <7CDD8E64-7EEA-42D6-91E6-9F80A8D6E979@sentex.net> References: <7e270cea0902040712w70e9afa0ifdef9dcf04419cb7@mail.gmail.com> <94ed0337c8594452daf376472cdb374d@localhost> <6117a7500902041628s67ab8851o756a0a6803584d4f@mail.gmail.com> <23C4F660-D8CA-4121-A45F-30D38FEC2E1E@gmail.com> <7CDD8E64-7EEA-42D6-91E6-9F80A8D6E979@sentex.net> Message-ID: Hi Andrew, On Thu, Feb 5, 2009 at 5:02 PM, Andrew Berry wrote: > Has anyone looked into version compatibility between the different versions > of sqlite? For example, on the same ISP, one server I checked has sqlite2, > the other has sqlite3. Neither server has both drivers installed. Neither > server actually has the sqlite binaries installed, though I assume that > isn't common, but worth checking on other SQLite supporting hosts. Drupal 7 only supports SQLite 3, that is the only version supported by PDO. > The SQLite site mentions using the command line tools to dump and restore > the DB, and I haven't found anything about doing that from pure PHP. This > probably wouldn't be an issue for caches and such, since an incompatible DB > can just be recreated. I could see it causing headaches for "Drupal Lite" > scenarios. Pure-PHP solutions (like the Backup and Migrate module) should work in that scenarios. This module is easy enough to install. Damien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/6be81748/attachment.htm From prometheus6 at gmail.com Thu Feb 5 18:50:46 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Thu, 5 Feb 2009 13:50:46 -0500 Subject: [development] Curl-based content generation In-Reply-To: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Message-ID: Use drupal_execute(). http://api.drupal.org/api/function/drupal_execute/6 On Thu, Feb 5, 2009 at 7:46 AM, Martin Stadler wrote: > Hi! > > I'm working on a small curl-based script to add content to a drupal-6 site. > Logging-in (getting cookie etc) works fine but when I try to add content I > get a validation error. I guess it's about security. Is it at all possible > to do what I'm trying? Is there documention how these form tokens actually > work and what is required? I couldn't find that in the formAPI docs. > > Here's the code: > > > # login > curl http://localhost/USA08/user \ > -F 'name=Martin' \ > -F 'pass=pass' \ > -F 'form_id=user_login' \ > -F 'op=Log in' \ > --output /Users/martin/response.html \ > -s \ > -c /tmp/curl-cookies.txt \ > -b /tmp/curl-cookies.txt > > # -> works: response.html says I'm logged-in > > # add page > curl http://localhost/USA08/node/add/page \ > -F 'title=xyz' \ > -F 'teaser_include=1' \ > -F 'body=abc' \ > -F 'format=1' \ > -F 'changed=' \ > -F 'form_id=page_node_form' \ > -F 'log=' \ > -F 'comment=0' \ > -F 'name=Martin' \ > -F 'date=' \ > -F 'status=1' \ > -F 'op=Save' \ > --output /Users/martin/response2.html \ > -s \ > -c /tmp/curl-cookies.txt \ > -b /tmp/curl-cookies.txt > > # -> does not work: response2.html says 'Validation error, please try > again. If this error persists, please contact the site administrator.' > > Regards, > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/f2f8b163/attachment.htm From jimmy at boombatower.com Thu Feb 5 19:05:02 2009 From: jimmy at boombatower.com (Jimmy Berry) Date: Thu, 5 Feb 2009 13:05:02 -0600 Subject: [development] Curl-based content generation Message-ID: I haven't read all the comments, but it seems like abstracting the core SimpleTest browser may be of interest to you. The code is quite far along and details can be seen http://drupal.org/node/366978. My plan was to port the code back to Drupal 6 as a module which seems like it might be useful for you. Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/3ae3996b/attachment.htm From mfioretti at nexaima.net Thu Feb 5 20:37:09 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 5 Feb 2009 21:37:09 +0100 Subject: [development] Curl-based content generation In-Reply-To: References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Message-ID: <20090205203709.GC13253@nexaima.net> On Thu, Feb 05, 2009 13:50:46 PM -0500, Earl Dunovant wrote: > Use drupal_execute(). > > http://api.drupal.org/api/function/drupal_execute/6 I don't know about Martin, but as far as I'm concerned, this goes hand in hand with Jimmy's suggestion to use the SimpleTest browser. Both are elegant solutions but require shell access to the server and/or changes/additions to the Drupal installation and/or a working PHP command line interpreter to do things remotely: all things much harder to have or set up than a bash/curl script running from home or even the barest Live Linux distro on a USB key The only problem is that to write such a script one needs to know in advance: - the exact sequence of URLs to call (isn't this documented anywhere but in the source code itself?) - a list of the names and admissible values of all the form variables to pass to curl when it calls each one of those URLs. (**) With all respect, can it really be that getting/providing just this information is such a complex task that it's simpler to learn the drupal API or set up a full Drupal testing environment? Thanks in advance for any pointer to a shell+curl-only solution to this problem. Marco (**) as I already said previously, I'd have no problem to extract those lists myself with a mysql query to the database, if only I knew what query(es) to make to get all and only that information. Is this documented somewhere? -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From prometheus6 at gmail.com Thu Feb 5 21:14:11 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Thu, 5 Feb 2009 16:14:11 -0500 Subject: [development] Curl-based content generation In-Reply-To: <20090205203709.GC13253@nexaima.net> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090205203709.GC13253@nexaima.net> Message-ID: On Thu, Feb 5, 2009 at 3:37 PM, M. Fioretti wrote: > On Thu, Feb 05, 2009 13:50:46 PM -0500, Earl Dunovant wrote: > > Use drupal_execute(). > > > > http://api.drupal.org/api/function/drupal_execute/6 > > > The only problem is that to write such a script one needs to know in > advance: > > - the exact sequence of URLs to call (isn't this documented anywhere > but in the source code itself?) > - a list of the names and admissible values of all the form variables > to pass to curl when it calls each one of those URLs. (**) > > You need to know the fields in the form to create the node type you want to create. You put the data in $form_state['values'], just as is passed into, hook_form_alter(). You can get that by writing a hook_form_alter() function that calls var_export($form_state['values'], 1); Then, 1: call drupal_get+form() to get the from-defining array 2: populate your $form_state['values'} array with your new node data 3: call drupal_execute($form_id, $form, $form_state); Lather, rinse, repeat until you're done. No URLs involved. Stick it in a module and call it from your script or a menu as you prefer. Read the docs and you'll see how it's done. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/2f88b4b2/attachment.htm From gerhard at killesreiter.de Thu Feb 5 21:31:41 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Thu, 05 Feb 2009 22:31:41 +0100 Subject: [development] Curl-based content generation In-Reply-To: References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090205203709.GC13253@nexaima.net> Message-ID: <498B5ABD.7050608@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Earl Dunovant schrieb: > On Thu, Feb 5, 2009 at 3:37 PM, M. Fioretti wrote: > >> On Thu, Feb 05, 2009 13:50:46 PM -0500, Earl Dunovant wrote: >>> Use drupal_execute(). >>> >>> http://api.drupal.org/api/function/drupal_execute/6 >> >> The only problem is that to write such a script one needs to know in >> advance: >> >> - the exact sequence of URLs to call (isn't this documented anywhere >> but in the source code itself?) >> - a list of the names and admissible values of all the form variables >> to pass to curl when it calls each one of those URLs. (**) >> >> You need to know the fields in the form to create the node type you want to > create. You put the data in $form_state['values'], just as is passed into, > hook_form_alter(). You can get that by writing a hook_form_alter() function > that calls var_export($form_state['values'], 1); > > Then, > 1: call drupal_get+form() to get the from-defining array > 2: populate your $form_state['values'} array with your new node data > 3: call drupal_execute($form_id, $form, $form_state); > > Lather, rinse, repeat until you're done. No URLs involved. Stick it in a > module and call it from your script or a menu as you prefer. > > Read the docs and you'll see how it's done. > While I agree that this is the right approach, it also has some problems. The most important one is that access permissions for the forms aren't checked. You can get around that by checking yourself in hook_form_alter (you also need to unset #programmed in case you want to deny access for some reason). I've not gotten field level cck permissions to work. Also be careful to set #redirect to false in case you want to get useful feedback (e.g. from the services module). Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmLWr0ACgkQfg6TFvELooTREwCeL+A73ohtJIc19yT153Ww0UAe FvoAn3t19iG65vhqS1m6JaR0gINrcyBH =pNtf -----END PGP SIGNATURE----- From andrewberry at sentex.net Thu Feb 5 21:34:11 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Thu, 5 Feb 2009 16:34:11 -0500 Subject: [development] Curl-based content generation In-Reply-To: References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Message-ID: <53458098-3E9E-43FE-A2CA-552F429D03EA@sentex.net> On 5-Feb-09, at 1:50 PM, Earl Dunovant wrote: > Use drupal_execute(). > > http://api.drupal.org/api/function/drupal_execute/6 Unfortunately, there are some static caches which can cause problems when you call drupal_execute() multiple times in one request. You don't say what content type you're using, but there are some specific issues with the book module and the menu system. If you do end up using drupal_execute(), either do one node add per POST, or look at applying and reviewing the following patches: http://drupal.org/node/360377 book_get_books() cache becomes stale when batch-inserting book pages http://drupal.org/node/364529 menu_tree_all_data() static cache can become stale --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090205/3a99b657/attachment.bin From gerhard at killesreiter.de Thu Feb 5 21:43:11 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Thu, 05 Feb 2009 22:43:11 +0100 Subject: [development] Curl-based content generation In-Reply-To: <53458098-3E9E-43FE-A2CA-552F429D03EA@sentex.net> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <53458098-3E9E-43FE-A2CA-552F429D03EA@sentex.net> Message-ID: <498B5D6F.7080505@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Berry schrieb: > On 5-Feb-09, at 1:50 PM, Earl Dunovant wrote: > >> Use drupal_execute(). >> >> http://api.drupal.org/api/function/drupal_execute/6 > > Unfortunately, there are some static caches which can cause problems > when you call drupal_execute() multiple times in one request. Ah, yes, I should have mentioned that. hook_forms is your friend there (but you will have to re-attach taxonomy in hook_form_alter and other things might be a bit strange too). Another problem is that you will need a lot of memory if you have either a lot of forms or quite complicated ones. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmLXW8ACgkQfg6TFvELooS/hgCgvZTlIaXOCJyzhGuB6f3pVTN/ HmAAn1mh/XnHCOnmZ9QYFbSNTSGcD1uj =cXIa -----END PGP SIGNATURE----- From jimmy at boombatower.com Thu Feb 5 22:46:39 2009 From: jimmy at boombatower.com (Jimmy Berry) Date: Thu, 5 Feb 2009 16:46:39 -0600 Subject: [development] Curl-based content generation Message-ID: @Marco: If you used a the abstract browser and a script you could programmatically access any feature provided through Drupal's web interface from a script on a local machine. The script could login to the remote server and perform any action the user can. Using the core browser you only need to specify the values you would as a user...all the default values are already picked up and sent as a standard broswer does (ie. checkbox states, hidden values, etc). Having such a tool would allow you to programmatically perform numerous operations on any number of remote servers with a single command. I see a great use being the update script that would allow you to run it on any number of sites at once, instead of navigating to each manually. This method requires no additional setup or configuration of the server. Just run the script and it will act as though it were a standard user browsing the site. To create a node you would need something like this: $edit = array( 'title' => 'New node', 'body' => 'Some text' ); $browser->post('http://example.com/node/add/page', $edit, 'Submit'); You can see how simple it would be to perform just about any operation as it already deals with cookies and such. Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/539c7777/attachment.htm From prometheus6 at gmail.com Fri Feb 6 01:55:42 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Thu, 5 Feb 2009 20:55:42 -0500 Subject: [development] Curl-based content generation In-Reply-To: References: Message-ID: That would be a good tool to have. Sounds like it wouldn't even be limited to Drupal sites. But Martin is just looking to post unmodified page nodes. As a one shot thing, the standard drupal_execute() should be fine. If, for some reason you want it as an ongoing process, Gerhard and Andrew's concerns become important. On Thu, Feb 5, 2009 at 5:46 PM, Jimmy Berry wrote: > @Marco: > > If you used a the abstract browser and a script you could programmatically > access any feature provided through Drupal's web interface from a script on > a local machine. The script could login to the remote server and perform any > action the user can. > > Using the core browser you only need to specify the values you would as a > user...all the default values are already picked up and sent as a standard > broswer does (ie. checkbox states, hidden values, etc). > > Having such a tool would allow you to programmatically perform numerous > operations on any number of remote servers with a single command. I see a > great use being the update script that would allow you to run it on any > number of sites at once, instead of navigating to each manually. > > This method requires no additional setup or configuration of the server. > Just run the script and it will act as though it were a standard user > browsing the site. To create a node you would need something like this: > > $edit = array( > 'title' => 'New node', > 'body' => 'Some text' > ); > $browser->post('http://example.com/node/add/page', $edit, 'Submit'); > > You can see how simple it would be to perform just about any operation as > it already deals with cookies and such. > > Jimmy > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/b24c80e5/attachment-0001.htm From darrel.opry at gmail.com Fri Feb 6 02:16:55 2009 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Thu, 5 Feb 2009 21:16:55 -0500 Subject: [development] ahah, drupal_json, file_uploads.... Message-ID: So I've ran into an interesting issue, and wanted to solicit feedback from people more involved with ahah/ajax development for drupal than I.... http://malsup.com/jquery/form/#code-samples -- see the file uploads tab and the information regarding json/javascript responses. The concrete issue I'm dealing with is the Add another item button for CCK... For Filefield if you've selected a file to upload and press the 'Add Another Item' button you get an error. You get this error because drupal_json sets the text/javascript header, and the iframe doesn't accept that... This issue can be solved easily just by having CCK's ahah handler simply print drupal_to_js instead of using drupal json. This however will not solve more systemic issues with people adding file uploads to other ajax handled forms. There are a couple solutions I can think of... 1) have ahah set the iframe option to true and use iframes, and add the textarea to drupal_json. 2) check the _SERVER['HTTP_ACCEPT'] and decide which header to set whether to wrap output in a textarea 3) hack around it on a case by case basis I was hoping some of the more jquery ahah astute might have better suggestions for achieveing some kind of consistency. We should probably add $_GLOBAL['devel_shutdown'] = FALSE to drupal_json regardless... .darrel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090205/94120cff/attachment.htm From dmitrig01 at gmail.com Fri Feb 6 02:46:33 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Thu, 5 Feb 2009 18:46:33 -0800 Subject: [development] Curl-based content generation In-Reply-To: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Message-ID: You can look at the name attributes of the input elements in the source page. The thing you won't get is the form token: the form token is a mechanism designed to prevent exactly what you're trying to do. Form token is an input field that is generated with the rest of the form and stored server side. If you send a valid token back to the server, it process your request. otherwise it doesn't because it thinks you're a spammer. Dmitri On Feb 5, 2009, at 4:46 AM, Martin Stadler wrote: > Hi! > > I'm working on a small curl-based script to add content to a > drupal-6 site. Logging-in (getting cookie etc) works fine but when I > try to add content I get a validation error. I guess it's about > security. Is it at all possible to do what I'm trying? Is there > documention how these form tokens actually work and what is > required? I couldn't find that in the formAPI docs. > > Here's the code: > > > # login > curl http://localhost/USA08/user \ > -F 'name=Martin' \ > -F 'pass=pass' \ > -F 'form_id=user_login' \ > -F 'op=Log in' \ > --output /Users/martin/response.html \ > -s \ > -c /tmp/curl-cookies.txt \ > -b /tmp/curl-cookies.txt > > # -> works: response.html says I'm logged-in > > # add page > curl http://localhost/USA08/node/add/page \ > -F 'title=xyz' \ > -F 'teaser_include=1' \ > -F 'body=abc' \ > -F 'format=1' \ > -F 'changed=' \ > -F 'form_id=page_node_form' \ > -F 'log=' \ > -F 'comment=0' \ > -F 'name=Martin' \ > -F 'date=' \ > -F 'status=1' \ > -F 'op=Save' \ > --output /Users/martin/response2.html \ > -s \ > -c /tmp/curl-cookies.txt \ > -b /tmp/curl-cookies.txt > > # -> does not work: response2.html says 'Validation error, please > try again. If this error persists, please contact the site > administrator.' > > Regards, > Martin > From fofovi72 at gmail.com Fri Feb 6 06:57:03 2009 From: fofovi72 at gmail.com (Sam Golchi FOLI-AWLI) Date: Fri, 6 Feb 2009 12:27:03 +0530 Subject: [development] phpbbforum module into drupal settings are not displaying fully In-Reply-To: <3adc77210902050334u6646ae59r725c82752e6c7b5e@mail.gmail.com> References: <556cd02b0902050011s13dcddbck4d2281e354e4c45a@mail.gmail.com> <3adc77210902050334u6646ae59r725c82752e6c7b5e@mail.gmail.com> Message-ID: <870d8d110902052257r1aba816dt83fdd0c4945f91ce@mail.gmail.com> Hi, Can you give more details about the versions (of drupal and phpbb) you are using ? I'll like to check the error. Regards, Sam 2009/2/5 Naheem Zaffar > Hi, > > Have you considered simply importing the data and using the default drupal > forums? (maybe with Advanced_forums to return the more traditional look)? > the phpbb2drupal module should handle the necessary data conversion. > > Alternatively, it maybe a good idea to raise a support request on the > phpbbforum module's issue queue. > > Kind Regards > -- FOLI-AWLI Mawusee Komla (Sam) +91 99 49 541 594 http://golchi.blogspot.com/ http://golchitech.blogspot.com/ Le monde en grandissant de jour en jour devient plus petit... ----- ---- Ne m'envoyez pas de fichiers attach?s au format Micro$oft (.DOC, .PPT) svp! Merci de lire http://www.gnu.org/philosophy/no-word-attachments.html Mes format pr?f?r?s : .PDF, ODF, .TXT, ABW Merci d'ajouter ce texte ? votre signature. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090206/9592e8da/attachment.htm From earnie at users.sourceforge.net Fri Feb 6 13:01:46 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Fri, 06 Feb 2009 08:01:46 -0500 Subject: [development] Curl-based content generation In-Reply-To: References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> Message-ID: <20090206080146.mck3ovotg3wo00wk@mail.progw.org> Quoting Dmitri Gaskin : > You can look at the name attributes of the input elements in the > source page. > The devel module will give you this on the form itself. > The thing you won't get is the form token: the form token is a > mechanism designed to prevent exactly what you're trying to do. > Unfortunately, the devel module doesn't give you this, either that I've been able to find. I tend to create a hook_form_alter and display it in the log table. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From victorkane at gmail.com Fri Feb 6 16:21:17 2009 From: victorkane at gmail.com (Victor Kane) Date: Fri, 6 Feb 2009 14:21:17 -0200 Subject: [development] Way to have one content type "inherit" from another Message-ID: Hi all, Looking for some feedback on using CCK fields as a way of emulating object inheritance in Drupal. Pseudo-inheritance via CCK field re-use. I am developing Project Flow and Tracker, an agile-based project management system built for and by Drupal, and will be presenting it (and making it available) at DrupalCon DC. Using Drupal 6.x, I have a "core" content type, "Card" (based on the Kanban "visual card" display approach - http://www.infoq.com/articles/hiranabe-lean-agile-kanban). A Card is a User Story, but could also be a project, a release, an iteration, a task... any kind of token that could be put on a 3x5 card and stuck on the wall to reflect project status. In an object oriented environment, I would create class Card, and then extend it into the other classes. I could do that in PHP, of course, but I want users of the PFT to be able to create their own work tokens or easily modify existing ones via CCK. So, is there any reason why making Card a superclass content type, with a superset of defined CCK fields, and defining a subclass by creating a content type and then adding in already defined fields, wouldn't work? I know it would work, of course, but is there a performance, or other caveat I should look out for? Also, how will this tie in with the new Field API in Drupal 7? Thanks in advance for your feedback, Victor Kane http://awebfactory.com.ar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090206/dedea5c0/attachment.htm From merlin at logrus.com Fri Feb 6 19:44:31 2009 From: merlin at logrus.com (Earl Miles) Date: Fri, 06 Feb 2009 11:44:31 -0800 Subject: [development] Way to have one content type "inherit" from another In-Reply-To: References: Message-ID: <498C931F.1060905@logrus.com> Victor Kane wrote: > Hi all, > > Looking for some feedback on using CCK fields as a way of emulating > object inheritance in Drupal. > > Pseudo-inheritance via CCK field re-use. See: http://drupal.org/project/inherit From victorkane at gmail.com Fri Feb 6 20:10:12 2009 From: victorkane at gmail.com (Victor Kane) Date: Fri, 6 Feb 2009 18:10:12 -0200 Subject: [development] Way to have one content type "inherit" from another In-Reply-To: <498C931F.1060905@logrus.com> References: <498C931F.1060905@logrus.com> Message-ID: Thanks Earl, will definitely check this out. Victor Kane http://awebfactory.com.ar On Fri, Feb 6, 2009 at 5:44 PM, Earl Miles wrote: > Victor Kane wrote: > >> Hi all, >> >> Looking for some feedback on using CCK fields as a way of emulating object >> inheritance in Drupal. >> >> Pseudo-inheritance via CCK field re-use. >> > > See: http://drupal.org/project/inherit > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090206/9a074bff/attachment-0001.htm From winborn at advomatic.com Fri Feb 6 19:50:27 2009 From: winborn at advomatic.com (Aaron Winborn) Date: Fri, 06 Feb 2009 14:50:27 -0500 Subject: [development] Way to have one content type "inherit" from another In-Reply-To: <498C931F.1060905@logrus.com> References: <498C931F.1060905@logrus.com> Message-ID: <498C9483.4090305@advomatic.com> also see http://drupal.org/node/100925 Earl Miles wrote: > Victor Kane wrote: >> Hi all, >> >> Looking for some feedback on using CCK fields as a way of emulating >> object inheritance in Drupal. >> >> Pseudo-inheritance via CCK field re-use. > > See: http://drupal.org/project/inherit -- Aaron Winborn Advomatic, LLC http://advomatic.com/ Drupal Multimedia available in September! http://www.packtpub.com/create-multimedia-website-with-drupal/book My blog: http://aaronwinborn.com/ From a.velios at gmail.com Sat Feb 7 10:15:42 2009 From: a.velios at gmail.com (Athanasios Velios) Date: Sat, 07 Feb 2009 10:15:42 +0000 Subject: [development] Limited hierarchy generations in Book module Message-ID: <1234001742.7248.4.camel@linux-vaio> Hello, I am a little confused with the limitation of 9 generations in the hierarchies of book structure in D6. Such limitation did not exist in D5 and relevant discussions have taken place here: http://drupal.org/node/274270 http://drupal.org/node/236866 Personally I think it is not reasonable to assume that every drupal website will require less than 10 generations in a hierarchical structure and I would like to know what your opinions on this are. As far as I can see, there are two arguments for limiting the number of generations: 1) Hierarchies without limits can be built with the Taxonomy module. 2) Speed when building the menu. Arguments in reply: 1) Yes, taxonomy can be used. But then why are we given the option to build hierarchies with the book module as well? Why allow two different ways of doing the same thing especially when one of them is not quite right? The obvious reason is because taxonomy terms are not nodes and we want hierarchies of nodes - not vocabulary terms. But why only 9 generations of nodes and unlimited generations of terms? And yes, modules that can link terms and nodes do exist, but they are rather heavy and probably risky to use. Also, what happens to backwards compatibility for websites that already use the book module for far deeper hierarchies? How do they upgrade to drupal 6? Also, the choice of 9 as a limit is completely arbitrary. Why not 29 or 39? 2) Speed is a problem which is encountered in every aspect of the development. And the answer to it as was suggested in the discussions is often caching. Why isn't caching an option here? I do not think it is reasonable to reduce the functionality of a module because of this. I have also heard that a block with so many generations in a menu will not "look right". The answer to this is of course easy: a) Why do we assume that multiple generations of nodes will all require a menu entry? Maybe navigation is only required to top level children of the hierarchy. b) Why do we assume that a menu is always in the sidebar (or why do we assume that the sidebar is too narrow to fit it). I have more than one examples when the "menu" is the main content of a page? And this is a theming issue anyway. Also, my feeling is that the major changes in the Book module for 6 started when a decision was made to combine the code for the book module with the menu system. I appreciate that there is quite a lot of code in common between these two modules - and excuse my ignorance here - but isn't there common code for hierarchy building between the taxonomy and the book module? Or at least wasn't that the case in 5? And how come and the code for the taxonomy module is free of the 9 generations limitation? Why couldn't the book module share code with the taxonomy module when it comes to hierarchy handling so that this limitation is removed? And as a proposal, in the short term the 9 generations limitation needs to be lifted. In the long term, I think a reasonable option would be to merge the book module with the hierarchy functionality of the taxonomy module. How? By introducing a setting for vocabularies to force a one-to-one relationship with nodes. In other words, for a given vocabulary, allow only one node to be associated with one term. I have recently joined the mailing list to be able to bring this issue up, because I think it is a critical one. So forgive me if this has already been discussed and point me to the discussion if this is the case - I could not find anything helpful apart from these links. Also, forgive me if these ideas sound naive. It would be good to have it explained and published out there as other people share my confusion. All the best, natuk From dag at wieers.com Sat Feb 7 15:05:23 2009 From: dag at wieers.com (Dag Wieers) Date: Sat, 7 Feb 2009 16:05:23 +0100 (CET) Subject: [development] Development snapshot not updateing Message-ID: Hi, Can someone tell me why the tarball of my development snapshot of HEAD is not being updated at: http://drupal.org/project/warning I updated it a few time the past days, but the page still says 2009-Feb-05. Is there something I can do to reissue the tarball ? -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From martin at siarp.de Sat Feb 7 15:34:54 2009 From: martin at siarp.de (Martin Stadler) Date: Sat, 7 Feb 2009 16:34:54 +0100 Subject: [development] Curl-based content generation In-Reply-To: <20090206080146.mck3ovotg3wo00wk@mail.progw.org> References: <63351214-C0D7-405E-B32C-37DD2FF11D07@siarp.de> <20090206080146.mck3ovotg3wo00wk@mail.progw.org> Message-ID: <6DDB255C-8BDB-4448-B1F2-618A13284120@siarp.de> I was pretty close. I needed to add the security token and the form ID. What I was really searching for was this documentation about cURL and Drupal: http://drupal.org/node/80548 . I'm basically using this now but originally I wanted to get along with a shell script only. Actually I'm trying to export images from iPhoto to Drupal using AppleScript as I didn't want to dive into plugin development and you can call shell scripts from AppleScript. What I learned: The security token (form_token) depends on the session ID (plus form ID and private key) and thus you need to create a session with the client you want to use to create the content (or create a cookie with such session ID). Just send a request for the add- page and extract the token from the HTML form. This token can be used from now on to add content using a tool like cURL. Checking the resulting HTML pages I also got confused because the redirect did not work with cURL so I didn't get the success message I expected though the creation was successful. Here's my working cURL code: # login curl http://localhost/drupal/?q=user \ -s \ -c cookie.txt \ -b cookie.txt \ -F 'name=user' \ -F 'pass=pass' \ -F 'form_id=user_login' \ -F 'op=Log in' \ --output response0.html # get form curl http://localhost/drupal/?q=node/add/page \ -s \ -c cookie.txt \ -b cookie.txt \ --output response1.html # -> extract token from response1.html (/edit-page-node-form-form- token" *value="([^"]*)"/) # add page # -> use extracted token curl http://localhost/drupal/?q=node/add/page \ -s \ -c cookie.txt \ -b cookie.txt \ -F 'title=xyz' \ -F 'body=abc' \ -F 'form_id=page_node_form' \ -F 'form_token=63fe773e820d2a4565720ab3bd0fc991' \ -F 'status=1' \ -F 'revision=1' \ -F 'op=Save' \ --output response2.html From merlin at logrus.com Sat Feb 7 16:58:54 2009 From: merlin at logrus.com (Earl Miles) Date: Sat, 07 Feb 2009 08:58:54 -0800 Subject: [development] Development snapshot not updateing In-Reply-To: References: Message-ID: <498DBDCE.9000303@logrus.com> Dag Wieers wrote: > Hi, > > Can someone tell me why the tarball of my development snapshot of HEAD > is not being updated at: > > http://drupal.org/project/warning > > I updated it a few time the past days, but the page still says > 2009-Feb-05. Is there something I can do to reissue the tarball ? > The problem is that you have a release snapshot built on the DRUPAL-6--1 branch but your updates have gone directly into the main branch, aka HEAD. You either need to create a new release node for head and unpublish the existing one OR re-check your changes into DRUPAL-6--1. From drewish at katherinehouse.com Sat Feb 7 19:28:36 2009 From: drewish at katherinehouse.com (andrew morton) Date: Sat, 7 Feb 2009 11:28:36 -0800 Subject: [development] Limited hierarchy generations in Book module In-Reply-To: <1234001742.7248.4.camel@linux-vaio> References: <1234001742.7248.4.camel@linux-vaio> Message-ID: I'm not sure how easy this would be to do because the book module uses the menu system for it's hierarchy and the menu system has a hard depth of nine. It definitely won't change in D6 but you make a good case for an adjustment in D7. andrew On Sat, Feb 7, 2009 at 2:15 AM, Athanasios Velios wrote: > Hello, > > I am a little confused with the limitation of 9 generations in the > hierarchies of book structure in D6. Such limitation did not exist in D5 > and relevant discussions have taken place here: > > http://drupal.org/node/274270 > http://drupal.org/node/236866 > > Personally I think it is not reasonable to assume that every drupal > website will require less than 10 generations in a hierarchical > structure and I would like to know what your opinions on this are. > > As far as I can see, there are two arguments for limiting the number of > generations: > > 1) Hierarchies without limits can be built with the Taxonomy module. > 2) Speed when building the menu. > > Arguments in reply: > 1) Yes, taxonomy can be used. But then why are we given the option to > build hierarchies with the book module as well? Why allow two different > ways of doing the same thing especially when one of them is not quite > right? The obvious reason is because taxonomy terms are not nodes and we > want hierarchies of nodes - not vocabulary terms. But why only 9 > generations of nodes and unlimited generations of terms? And yes, > modules that can link terms and nodes do exist, but they are rather > heavy and probably risky to use. Also, what happens to backwards > compatibility for websites that already use the book module for far > deeper hierarchies? How do they upgrade to drupal 6? Also, the choice of > 9 as a limit is completely arbitrary. Why not 29 or 39? > > 2) Speed is a problem which is encountered in every aspect of the > development. And the answer to it as was suggested in the discussions is > often caching. Why isn't caching an option here? I do not think it is > reasonable to reduce the functionality of a module because of this. I > have also heard that a block with so many generations in a menu will not > "look right". The answer to this is of course easy: > a) Why do we assume that multiple generations of nodes will all require > a menu entry? Maybe navigation is only required to top level children of > the hierarchy. > b) Why do we assume that a menu is always in the sidebar (or why do we > assume that the sidebar is too narrow to fit it). I have more than one > examples when the "menu" is the main content of a page? And this is a > theming issue anyway. > > Also, my feeling is that the major changes in the Book module for 6 > started when a decision was made to combine the code for the book module > with the menu system. I appreciate that there is quite a lot of code in > common between these two modules - and excuse my ignorance here - but > isn't there common code for hierarchy building between the taxonomy and > the book module? Or at least wasn't that the case in 5? And how come and > the code for the taxonomy module is free of the 9 generations > limitation? Why couldn't the book module share code with the taxonomy > module when it comes to hierarchy handling so that this limitation is > removed? > > And as a proposal, in the short term the 9 generations limitation needs > to be lifted. In the long term, I think a reasonable option would be to > merge the book module with the hierarchy functionality of the taxonomy > module. How? By introducing a setting for vocabularies to force a > one-to-one relationship with nodes. In other words, for a given > vocabulary, allow only one node to be associated with one term. > > I have recently joined the mailing list to be able to bring this issue > up, because I think it is a critical one. So forgive me if this has > already been discussed and point me to the discussion if this is the > case - I could not find anything helpful apart from these links. Also, > forgive me if these ideas sound naive. It would be good to have it > explained and published out there as other people share my confusion. > > All the best, > > natuk > From karoly at negyesi.net Sat Feb 7 19:44:39 2009 From: karoly at negyesi.net (Karoly Negyesi) Date: Sat, 7 Feb 2009 11:44:39 -0800 Subject: [development] SQLite and Drupal 7 -- how to earn a quick buck Message-ID: <7e270cea0902071144i1a9815d9s56a68fc9e2c5ace0@mail.gmail.com> Hi, First there is a tremendous confusion about SQLite and PHP and drivers. What we need is NOT the sqlite extension NOR sqlite3 from PECL/PHP 5.3 What we DO need is PDO_SQLite. If we want to clean up the installer and make maintenance nicer, we must require this driver to be available. Once we did that we can re-use it for the registry tables provided I can make it so that it is able to rebuild itself from MySQL. I have put up the challenge to http://drupal4hu.com/node/177 months ago. I will present the contenders to Dries in Washington DC. If there are no contenders then I will present that. Speak now or forever hold your peace. Thanks NK From catch56 at googlemail.com Sat Feb 7 20:48:09 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Sat, 7 Feb 2009 20:48:09 +0000 Subject: [development] Limited hierarchy generations in Book module In-Reply-To: References: <1234001742.7248.4.camel@linux-vaio> Message-ID: The current menu system method of handing hierarchy, materialised path, has to had a hard depth (not necessarily 9, but something). Taxonomy doesn't have a hard depth, but it's also very inefficient to do any queries based on depth in taxonomy module. If you want fast handling of hierarchy in Drupal 7 without limits, the number one place you can help is at http://drupal.org/node/344019 - which would add a very advanced method for storing trees to Drupal, and also make it pluggable with different methods from contrib. Nat On Sat, Feb 7, 2009 at 7:28 PM, andrew morton wrote: > I'm not sure how easy this would be to do because the book module uses > the menu system for it's hierarchy and the menu system has a hard > depth of nine. It definitely won't change in D6 but you make a good > case for an adjustment in D7. > > andrew > > On Sat, Feb 7, 2009 at 2:15 AM, Athanasios Velios < wrote: > > Hello, > > > > I am a little confused with the limitation of 9 generations in the > > hierarchies of book structure in D6. Such limitation did not exist in D5 > > and relevant discussions have taken place here: > > > > http://drupal.org/node/274270 > > http://drupal.org/node/236866 > > > > Personally I think it is not reasonable to assume that every drupal > > website will require less than 10 generations in a hierarchical > > structure and I would like to know what your opinions on this are. > > > > As far as I can see, there are two arguments for limiting the number of > > generations: > > > > 1) Hierarchies without limits can be built with the Taxonomy module. > > 2) Speed when building the menu. > > > > Arguments in reply: > > 1) Yes, taxonomy can be used. But then why are we given the option to > > build hierarchies with the book module as well? Why allow two different > > ways of doing the same thing especially when one of them is not quite > > right? The obvious reason is because taxonomy terms are not nodes and we > > want hierarchies of nodes - not vocabulary terms. But why only 9 > > generations of nodes and unlimited generations of terms? And yes, > > modules that can link terms and nodes do exist, but they are rather > > heavy and probably risky to use. Also, what happens to backwards > > compatibility for websites that already use the book module for far > > deeper hierarchies? How do they upgrade to drupal 6? Also, the choice of > > 9 as a limit is completely arbitrary. Why not 29 or 39? > > > > 2) Speed is a problem which is encountered in every aspect of the > > development. And the answer to it as was suggested in the discussions is > > often caching. Why isn't caching an option here? I do not think it is > > reasonable to reduce the functionality of a module because of this. I > > have also heard that a block with so many generations in a menu will not > > "look right". The answer to this is of course easy: > > a) Why do we assume that multiple generations of nodes will all require > > a menu entry? Maybe navigation is only required to top level children of > > the hierarchy. > > b) Why do we assume that a menu is always in the sidebar (or why do we > > assume that the sidebar is too narrow to fit it). I have more than one > > examples when the "menu" is the main content of a page? And this is a > > theming issue anyway. > > > > Also, my feeling is that the major changes in the Book module for 6 > > started when a decision was made to combine the code for the book module > > with the menu system. I appreciate that there is quite a lot of code in > > common between these two modules - and excuse my ignorance here - but > > isn't there common code for hierarchy building between the taxonomy and > > the book module? Or at least wasn't that the case in 5? And how come and > > the code for the taxonomy module is free of the 9 generations > > limitation? Why couldn't the book module share code with the taxonomy > > module when it comes to hierarchy handling so that this limitation is > > removed? > > > > And as a proposal, in the short term the 9 generations limitation needs > > to be lifted. In the long term, I think a reasonable option would be to > > merge the book module with the hierarchy functionality of the taxonomy > > module. How? By introducing a setting for vocabularies to force a > > one-to-one relationship with nodes. In other words, for a given > > vocabulary, allow only one node to be associated with one term. > > > > I have recently joined the mailing list to be able to bring this issue > > up, because I think it is a critical one. So forgive me if this has > > already been discussed and point me to the discussion if this is the > > case - I could not find anything helpful apart from these links. Also, > > forgive me if these ideas sound naive. It would be good to have it > > explained and published out there as other people share my confusion. > > > > All the best, > > > > natuk > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090207/9769601e/attachment-0001.htm From dag at wieers.com Sat Feb 7 22:47:51 2009 From: dag at wieers.com (Dag Wieers) Date: Sat, 7 Feb 2009 23:47:51 +0100 (CET) Subject: [development] Development snapshot not updateing In-Reply-To: <498DBDCE.9000303@logrus.com> References: <498DBDCE.9000303@logrus.com> Message-ID: On Sat, 7 Feb 2009, Earl Miles wrote: > Dag Wieers wrote: > >> Can someone tell me why the tarball of my development snapshot of HEAD is >> not being updated at: >> >> http://drupal.org/project/warning >> >> I updated it a few time the past days, but the page still says >> 2009-Feb-05. Is there something I can do to reissue the tarball ? > > The problem is that you have a release snapshot built on the DRUPAL-6--1 > branch but your updates have gone directly into the main branch, aka HEAD. > You either need to create a new release node for head and unpublish the > existing one OR re-check your changes into DRUPAL-6--1. Thanks for that :) I am confused coming from subversion back to CVS. I expected to see a seperate tree for DRUPAL-6--1 and since it wasn't there I thought my release was directly from HEAD. I now checked out the DRUPAL-6--1 seperatel next to HEAD. Thanks again, -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From mroswell at gmail.com Sun Feb 8 10:24:38 2009 From: mroswell at gmail.com (Margie Roswell) Date: Sun, 8 Feb 2009 05:24:38 -0500 Subject: [development] kudos for change in api.drupal.org In-Reply-To: References: <20090204162916.2d4a0cf2@dawn.webthatworks.it> Message-ID: Also appreciating the changes. Good work! I'd much prefer, though, if links such as "? 219 functions call theme()" appeared higher on the page--either "above the fold" or (preferred) right on top. Best Regards, Margie On Wed, Feb 4, 2009 at 11:40 AM, Neil Drumm wrote: > Thanks, more changes to make upgrading easier are coming after I fix > more-pressing issues, like objects not being documented. Anything to > make upgrading modules easier is a priority for me, Drupal 7 needs to > be adopted faster than Drupal 6 has. > > -Neil > > On Wed, Feb 4, 2009 at 10:29 AM, Ivan Sergio Borgonovo > wrote: >> Nice job. >> Best thing is api comparison. >> It will make much easier to port. >> >> thanks >> >> -- >> Ivan Sergio Borgonovo >> http://www.webthatworks.it >> >> > > > > -- > Neil Drumm > http://delocalizedham.com > From drumm at delocalizedham.com Sun Feb 8 22:37:39 2009 From: drumm at delocalizedham.com (Neil Drumm) Date: Sun, 8 Feb 2009 23:37:39 +0100 Subject: [development] kudos for change in api.drupal.org In-Reply-To: References: <20090204162916.2d4a0cf2@dawn.webthatworks.it> Message-ID: I think most people are wondering how to use a function when they use api.drupal.org. The most important thing on the page is the function signature, so I want that too be up top. I moved the file and line number to above the code in the development version. Out of all page views on the site, approximately 85% are api/function/*. Before I merged in the function references page, that got 16.6% of all page views. This is actually a bit higher than I was expecting, I personally do not use the references much. Right now the main area of the documentation is a big text block. The second phase of the parser rewrite goal is break that up into more normalized data so it can be moved around more on the page. The first phase is fixing lots of PHP parser bugs and adding objects. -Neil On Sun, Feb 8, 2009 at 11:24 AM, Margie Roswell wrote: > Also appreciating the changes. Good work! > > I'd much prefer, though, if links such as "? 219 functions call > theme()" appeared higher on the page--either "above the fold" or > (preferred) right on top. > > Best Regards, > > Margie > > > > On Wed, Feb 4, 2009 at 11:40 AM, Neil Drumm wrote: >> Thanks, more changes to make upgrading easier are coming after I fix >> more-pressing issues, like objects not being documented. Anything to >> make upgrading modules easier is a priority for me, Drupal 7 needs to >> be adopted faster than Drupal 6 has. >> >> -Neil >> >> On Wed, Feb 4, 2009 at 10:29 AM, Ivan Sergio Borgonovo >> wrote: >>> Nice job. >>> Best thing is api comparison. >>> It will make much easier to port. >>> >>> thanks >>> >>> -- >>> Ivan Sergio Borgonovo >>> http://www.webthatworks.it >>> >>> >> >> >> >> -- >> Neil Drumm >> http://delocalizedham.com >> > -- Neil Drumm http://delocalizedham.com From drupal-devel at webchick.net Mon Feb 9 05:27:01 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 9 Feb 2009 00:27:01 -0500 Subject: [development] New "novice" issue tag Message-ID: <67F4906D-B9B6-4EA1-8360-A7B9C4624423@webchick.net> If you ever come across an issue and you think to yourself, "Gee, it sure would be nice to fix that, and it would probably only take me a couple of minutes..." then please *don't* fix it -- instead tag it with the issue tag "novice" so that it shows up at: http://drupal.org/patch/novice (all "novice" issues across all projects) and http://drupal.org/patch/novice/core (all Drupal core "novice" issues) Why? * There are lots of eager people out there who want to contribute more to Drupal and get started with patching, or with documentation, or whatever. But you point them at an issue queue with 5,000+ active issues and they get overwhelmed and don't know where to start. By specifically identifying "novice" issues, we give them a nice short- list of "low-hanging fruit" that they can use to get their feet wet. * If you already know how to patch, we could use your smarts elsewhere. Like, for example, mentoring the new contributors taking on these patches. :) If you find yourself with 15 minutes you don't know what else to do with, please find more novice patches rather than solving these. * New contributors are the perfect people to help us refine our documentation so that it makes more sense to other new contributors. So I'd love for there to be an army of folks in #drupal on-hand to help people tackling novice issues get past the initial bumps in the road, and helping to guide these folks toward doing documentation improvements. Those of you who've been on this list a long time might remember previous attempts at this with the "patchnewbie" user (http://lists.drupal.org/pipermail/development/2007-October/026945.html ), but this is a much more workable way to identify easier issues because anyone can add this tag. So, please do! I'll make a blog post in a week or two once we start getting this list fleshed out that will hopefully lead to some new faces in the queues. :) -Angie From metzlerd at metzlerd.com Mon Feb 9 05:40:21 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Sun, 8 Feb 2009 21:40:21 -0800 Subject: [development] Flex API, XML API modules are they needed? Message-ID: <24176E58-9D36-430B-A6AB-EDB685CE1D3E@metzlerd.com> Hey all, I work for The Evergreen State College a small liberal arts college in Olympia, WA USA. We're using Drupal as a portal system connected to our student information system, and also as a community networking tool centered around governance activities. I also have a side job developing assessment analysis software (for public school systems) using flex, php and postgres. For the last two years + we've been developing home grown Flex applications that use REST XML web services, as well as drupal modules that consume the same web services. This has become the primary architecture for developing applications at our campus. For those who don't know me, I'm also the maintainer of the CAS (Single sign on for universities) and Form Defaults modules. I'm trying to decide whether to take the time to push out new modules associated with the way we do development, or whether people would rather just use existing frameworks. My question is, which if any of the following apis/modules might be of interest to the community? Here's a summary of what's been developed so far: Flex-api: A quick way to leverage FLEX applications in Drupal. The FLEX applications currently get embedded in a page, but we're thinking of extending this to blocks as well. The generated code tells the flex app what url it should use as a web service, so that it can get data. When the data service gets called it looks for a class file includes it an allows only methods of that class to be called. It also looks for an auth method to see if the flex app is allowed. Anyway, it's a nice way to bundle flex/flash applications with modules. XML Forms Binding: This api uses SimpleXML and php DOM apis to convert XML to drupal form_values style arrays so that you can basically get data from a web service and make a form using (tree=true) that will directly edit the XML that was passed to you provided you sprinkle a couple of functions in your form functions and submit handlers. Includes conversion API for converting nested arrays (like forms) into XML and back. XML-enabled DB Binding: Write sql binding syntax that looks like SELECT * from table where name={xpathtofield}. The XPATH entry can also be an index to a field array. I find this more intuitive than the %1, %2 ,etc syntax that's used in drupal, cause you can reference the same bind variable more than once in an SQL statement. Are these to specific to my way of doing development or are they drupal.org worthy. Really I'm ok either way, (got plenty of work to do) so don't feel like you need to encourage me if you aren't interested in using it. Dave From news at unleashedmind.com Mon Feb 9 09:10:31 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 9 Feb 2009 10:10:31 +0100 Subject: [development] New "novice" issue tag In-Reply-To: <67F4906D-B9B6-4EA1-8360-A7B9C4624423@webchick.net> Message-ID: <064f01c98a96$4296db00$0200a8c0@structworks.com> > If you ever come across an issue and you think to yourself, > "Gee, it sure would be nice to fix that, and it would > probably only take me a couple of minutes..." then please > *don't* fix it -- instead tag it with the issue tag "novice" > so that it shows up at: > > http://drupal.org/patch/novice (all "novice" issues across > all projects) and http://drupal.org/patch/novice/core (all > Drupal core "novice" issues) Additionally, I'd like to especially note that *you* should ask novice? in Drupal's IRC channels whenever a newbie shows up and asks for how to contribute. Thanks, Daniel P.S.: "you" means you, not webchick. From morbus at disobey.com Mon Feb 9 12:21:30 2009 From: morbus at disobey.com (Morbus Iff) Date: Mon, 09 Feb 2009 07:21:30 -0500 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: <24176E58-9D36-430B-A6AB-EDB685CE1D3E@metzlerd.com> References: <24176E58-9D36-430B-A6AB-EDB685CE1D3E@metzlerd.com> Message-ID: <49901FCA.6040800@disobey.com> > My question is, which if any of the following apis/modules might be > > XML Forms Binding: This api uses SimpleXML and php DOM apis to > convert XML to drupal form_values style arrays so that you can > basically get data from a web service and make a form using > (tree=true) that will directly edit the XML that was passed to you > provided you sprinkle a couple of functions in your form functions > and submit handlers. Includes conversion API for converting nested > arrays (like forms) into XML and back. I like this one. -- Morbus Iff ( notice how he deftly sidesteps the panty issue. ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From earnie at users.sourceforge.net Mon Feb 9 14:39:45 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 09 Feb 2009 09:39:45 -0500 Subject: [development] Limited hierarchy generations in Book module In-Reply-To: <1234001742.7248.4.camel@linux-vaio> References: <1234001742.7248.4.camel@linux-vaio> Message-ID: <20090209093945.129advklwcn40cck@mail.progw.org> Quoting Athanasios Velios : > Hello, > > I am a little confused with the limitation of 9 generations in the > hierarchies of book structure in D6. Such limitation did not exist in D5 > and relevant discussions have taken place here: > > http://drupal.org/node/274270 > http://drupal.org/node/236866 > > Personally I think it is not reasonable to assume that every drupal > website will require less than 10 generations in a hierarchical > structure and I would like to know what your opinions on this are. > > As far as I can see, there are two arguments for limiting the number of > generations: > > 1) Hierarchies without limits can be built with the Taxonomy module. > 2) Speed when building the menu. > For outlining I like to use the node relativity module [1]. It allows you to bind other nodes or create new nodes as children of a parent node. The UI of the node display provides a menu of the children and parents. A node can be a child of more than one parent. [1] http://drupal.org/project/relativity -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From andrewberry at sentex.net Mon Feb 9 17:16:12 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Mon, 9 Feb 2009 12:16:12 -0500 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: <24176E58-9D36-430B-A6AB-EDB685CE1D3E@metzlerd.com> References: <24176E58-9D36-430B-A6AB-EDB685CE1D3E@metzlerd.com> Message-ID: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> On 9-Feb-09, at 12:40 AM, David Metzler wrote: > XML-enabled DB Binding: Write sql binding syntax that looks like > SELECT * from table where name={xpathtofield}. The XPATH entry can > also be an index to a field array. I find this more intuitive than > the %1, %2 ,etc syntax that's used in drupal, cause you can > reference the same bind variable more than once in an SQL statement. I believe this is solved in DB:TNG, now in Drupal 7. Calls to db_query() now have array keys, which can be used instead of the traditional ordered placeholders. http://api.drupal.org/api/function/db_query/7 --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090209/147ec2b4/attachment.bin From larry at garfieldtech.com Mon Feb 9 22:00:54 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Mon, 9 Feb 2009 16:00:54 -0600 Subject: [development] =?utf-8?q?Flex_API=2C__XML_API_modules_are_they_nee?= =?utf-8?q?ded=3F?= In-Reply-To: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> References: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> Message-ID: On Mon, 9 Feb 2009 12:16:12 -0500, Andrew Berry wrote: > On 9-Feb-09, at 12:40 AM, David Metzler wrote: > >> XML-enabled DB Binding: Write sql binding syntax that looks like >> SELECT * from table where name={xpathtofield}. The XPATH entry can >> also be an index to a field array. I find this more intuitive than >> the %1, %2 ,etc syntax that's used in drupal, cause you can >> reference the same bind variable more than once in an SQL statement. > > I believe this is solved in DB:TNG, now in Drupal 7. Calls to > db_query() now have array keys, which can be used instead of the > traditional ordered placeholders. > > http://api.drupal.org/api/function/db_query/7 > > --Andrew That's a different question, I think. DBTNG uses arrays and named placeholders. It sounds like David is talking about XPath based queries, which are another animal entirely and not DB portable. David, can you elaborate here? DBTNG does not allow the reuse of placeholders within the same query, because PDO doesn't either. --Larry Garfield From a.velios at gmail.com Tue Feb 10 09:11:24 2009 From: a.velios at gmail.com (Athanasios Velios) Date: Tue, 10 Feb 2009 09:11:24 +0000 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: <49901FCA.6040800@disobey.com> References: <24176E58-9D36-430B-A6AB-EDB685CE1D3E@metzlerd.com> <49901FCA.6040800@disobey.com> Message-ID: <1234257084.7330.0.camel@linux-vaio> On Mon, 2009-02-09 at 07:21 -0500, Morbus Iff wrote: > > My question is, which if any of the following apis/modules might be > > > > XML Forms Binding: This api uses SimpleXML and php DOM apis to > > convert XML to drupal form_values style arrays so that you can > > basically get data from a web service and make a form using > > (tree=true) that will directly edit the XML that was passed to you > > provided you sprinkle a couple of functions in your form functions > > and submit handlers. Includes conversion API for converting nested > > arrays (like forms) into XML and back. > > I like this one. > Same here. From drewish at katherinehouse.com Tue Feb 10 20:23:30 2009 From: drewish at katherinehouse.com (andrew morton) Date: Tue, 10 Feb 2009 12:23:30 -0800 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: References: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> Message-ID: On Mon, Feb 9, 2009 at 2:00 PM, Larry Garfield wrote: > > That's a different question, I think. DBTNG uses arrays and named placeholders. It sounds like David is talking about XPath based queries, which are another animal entirely and not DB portable. David, can you elaborate here? > > DBTNG does not allow the reuse of placeholders within the same query, because PDO doesn't either. > > --Larry Garfield Well technically only certain versions of the PDO don't allow it: http://paul-m-jones.com/?p=243 I can't find the php.net issue for this but I seem to remember that the change was eventually reverted leaving a band of versions that don't allow it. andrew From metzlerd at metzlerd.com Wed Feb 11 03:22:26 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Tue, 10 Feb 2009 19:22:26 -0800 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: References: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> Message-ID: <025F0983-1603-460C-8C5E-4937327059AD@metzlerd.com> Actually not quite, in it's simplest form a key into an associative array and a xpath into a simpleXML object are achieving the same goal. $xml_row->xpath('column_name') $array_row['column_name'] All I did was make my binding layer work with either, so you could pass an associative array OR a parsed SimpleXML object into the db_query call as the parameter set. Since I used a bracketed syntax rather than one like %d, I did a simple thing of saying if is_object ($parms) then assume its xml and call an xpath method returning the first value to get the string replacement. > DBTNG does not allow the reuse of placeholders within the same > query, because PDO doesn't either. This was a primary concern for me. I still haven't figured out why database drivers never do this....? It seems so straightforward to think of parameters as key value pairs. What I did here was to rewrite the parameters array into one that was numerically based because hey the postgres driver needed numerical bind arguments. I just got tired of hand rolling arrays arrays as parameters when I had a perfectly good $form_values array or simplexml object to use as the parameter source. If DBTNG allows extra parameters to be passed that don't get used in the query then it's probably close enough for what most people need, and the XML to array conversion api would get you the rest of the way there anyway. Anyway thus far what I'm hearing is the xml_to_array conversion utility is the most desirable. And I haven't heard of anyone talking much Flex. At one point Dries seemed pretty interested (back in 2007) but I haven't heard much recently on this front. Does that make things clearer? Dave On Feb 9, 2009, at 2:00 PM, Larry Garfield wrote: > > On Mon, 9 Feb 2009 12:16:12 -0500, Andrew Berry > wrote: >> On 9-Feb-09, at 12:40 AM, David Metzler wrote: >> >>> XML-enabled DB Binding: Write sql binding syntax that looks like >>> SELECT * from table where name={xpathtofield}. The XPATH entry can >>> also be an index to a field array. I find this more intuitive than >>> the %1, %2 ,etc syntax that's used in drupal, cause you can >>> reference the same bind variable more than once in an SQL statement. >> >> I believe this is solved in DB:TNG, now in Drupal 7. Calls to >> db_query() now have array keys, which can be used instead of the >> traditional ordered placeholders. >> >> http://api.drupal.org/api/function/db_query/7 >> >> --Andrew > > That's a different question, I think. DBTNG uses arrays and named > placeholders. It sounds like David is talking about XPath based > queries, which are another animal entirely and not DB portable. > David, can you elaborate here? > > DBTNG does not allow the reuse of placeholders within the same > query, because PDO doesn't either. > > --Larry Garfield > From antoinesolutions at gmail.com Wed Feb 11 03:50:13 2009 From: antoinesolutions at gmail.com (Jon Antoine) Date: Tue, 10 Feb 2009 19:50:13 -0800 Subject: [development] File Security Module Message-ID: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> After installing Drupal many times and having to check file permissions to make sure the site was secure, I got to thinking about how to automate this process. I started by writing a script to take care of this, but eventually I thought a Drupal module might be the way to go. The module could provide a hook, say hook_file_security, that would take an array of files names and their suggested security parameters. This could work very similar to the updates module providing information on the admin/reports/status page and an admin/reports/file-security page that displayed all installed modules, their files, the suggested security settings, and the current security settings. Well, that is the base idea I had. I think something like this would really help new users of Drupal and I'm pretty sure it's possible since the installation script reports on the security settings of the files directory and the settings.php file. Any thoughts, ideas, suggestions are welcome. Cheers, Jon From barry at jaspan.org Wed Feb 11 04:20:18 2009 From: barry at jaspan.org (Barry Jaspan) Date: Tue, 10 Feb 2009 23:20:18 -0500 Subject: [development] Body and teaser as fields Message-ID: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> Now that Field API is in core it is time to start using it. I have an initial suggestion: change node body and teaser from special cases to normal fields. I suspect this is going to be quite controversial so I thought I'd get some feedback here before evening bothering to start looking at the code. This message is not about the details of the implementation; I'm sure there will be subtleties and complexities to work. I'm just asking about the concept. Concept: Remove all special processing for $node->body and $node->teaser. Create two fields, body and teaser, both text fields. Assign both fields to every existing content type with a "body field" using the textarea widget. For existing nodes, as part of the upgrade path, initialize the teaser field value with whatever teaser would normally be generated automatically from the body. Random thoughts: - We will get to remove a bunch of code, much of it quite ugly, from node.module. - Sites that really want an auto-generated teaser can remove the teaser field from a content type and use the text field's teaser Display Formatter in the teaser context. - This will mean removing the body field from the node and node_revision tables, and creating a field_data_body table for it instead. Don't worry about database query efficiency; that is a solved problem (see http://drupal.org/node/368674). - With $node->body and $node->teaser being normal fields, they will not be available for overloaded use as the complete rendered output of the node. Hurray! We can use $node->content = drupal_render($node) or something like that. - We might want to think about adding other fields to our default content types. Perhaps Article should have a Subtitle field, etc. This is a whole topic in itself. Comments? Thanks, Barry From matt at mattfarina.com Wed Feb 11 04:45:04 2009 From: matt at mattfarina.com (Matt Farina) Date: Tue, 10 Feb 2009 23:45:04 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> Message-ID: On the UI side including the teaser splitter JavaScript might be ugly. How would we handle this special case? Or, do we get rid of the teaser splitter? On Feb 10, 2009, at 11:20 PM, Barry Jaspan wrote: > Now that Field API is in core it is time to start using it. I have > an initial suggestion: change node body and teaser from special > cases to normal fields. I suspect this is going to be quite > controversial so I thought I'd get some feedback here before evening > bothering to start looking at the code. > > This message is not about the details of the implementation; I'm > sure there will be subtleties and complexities to work. I'm just > asking about the concept. > > Concept: > > Remove all special processing for $node->body and $node->teaser. > Create two fields, body and teaser, both text fields. Assign both > fields to every existing content type with a "body field" using the > textarea widget. For existing nodes, as part of the upgrade path, > initialize the teaser field value with whatever teaser would > normally be generated automatically from the body. > > Random thoughts: > > - We will get to remove a bunch of code, much of it quite ugly, from > node.module. > > - Sites that really want an auto-generated teaser can remove the > teaser field from a content type and use the text field's teaser > Display Formatter in the teaser context. > > - This will mean removing the body field from the node and > node_revision tables, and creating a field_data_body table for it > instead. Don't worry about database query efficiency; that is a > solved problem (see http://drupal.org/node/368674). > > - With $node->body and $node->teaser being normal fields, they will > not be available for overloaded use as the complete rendered output > of the node. Hurray! We can use $node->content = > drupal_render($node) or something like that. > > - We might want to think about adding other fields to our default > content types. Perhaps Article should have a Subtitle field, etc. > This is a whole topic in itself. > > Comments? > > Thanks, > > Barry > From metzlerd at metzlerd.com Wed Feb 11 05:18:19 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Tue, 10 Feb 2009 21:18:19 -0800 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: References: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> Message-ID: The article alludes to a security issue. Anyone know what it is? I get the stability concerns, which is why I coded in an extra layer at my end. The SQL statements get rewritten into a numeric variable bind syntax before passing to the db layer in my implementation for just this reason. A band of versions that include php 5.2.2 might be fatal to that idea :). If this makes it in it sounds like it should be part of an XML specific db wrapper, but it sure doesn't sound like it make sense to focus my energies there. Dave On Feb 10, 2009, at 12:23 PM, andrew morton wrote: > On Mon, Feb 9, 2009 at 2:00 PM, Larry Garfield > wrote: >> >> That's a different question, I think. DBTNG uses arrays and named >> placeholders. It sounds like David is talking about XPath based >> queries, which are another animal entirely and not DB portable. >> David, can you elaborate here? >> >> DBTNG does not allow the reuse of placeholders within the same >> query, because PDO doesn't either. >> >> --Larry Garfield > > Well technically only certain versions of the PDO don't allow it: > http://paul-m-jones.com/?p=243 > > I can't find the php.net issue for this but I seem to remember that > the change was eventually reverted leaving a band of versions that > don't allow it. > > andrew From weitzman at tejasa.com Wed Feb 11 05:20:39 2009 From: weitzman at tejasa.com (Moshe Weitzman) Date: Wed, 11 Feb 2009 00:20:39 -0500 Subject: [development] Body and teaser as fields In-Reply-To: References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> Message-ID: <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> core would get rid of it. and there will be much rejoicing in usabilty land. On Tue, Feb 10, 2009 at 11:45 PM, Matt Farina wrote: > On the UI side including the teaser splitter JavaScript might be ugly. How > would we handle this special case? Or, do we get rid of the teaser splitter? > > > On Feb 10, 2009, at 11:20 PM, Barry Jaspan wrote: > >> Now that Field API is in core it is time to start using it. I have an >> initial suggestion: change node body and teaser from special cases to normal >> fields. I suspect this is going to be quite controversial so I thought I'd >> get some feedback here before evening bothering to start looking at the >> code. >> >> This message is not about the details of the implementation; I'm sure >> there will be subtleties and complexities to work. I'm just asking about >> the concept. >> >> Concept: >> >> Remove all special processing for $node->body and $node->teaser. Create >> two fields, body and teaser, both text fields. Assign both fields to every >> existing content type with a "body field" using the textarea widget. For >> existing nodes, as part of the upgrade path, initialize the teaser field >> value with whatever teaser would normally be generated automatically from >> the body. >> >> Random thoughts: >> >> - We will get to remove a bunch of code, much of it quite ugly, from >> node.module. >> >> - Sites that really want an auto-generated teaser can remove the teaser >> field from a content type and use the text field's teaser Display Formatter >> in the teaser context. >> >> - This will mean removing the body field from the node and node_revision >> tables, and creating a field_data_body table for it instead. Don't worry >> about database query efficiency; that is a solved problem (see >> http://drupal.org/node/368674). >> >> - With $node->body and $node->teaser being normal fields, they will not be >> available for overloaded use as the complete rendered output of the node. >> Hurray! We can use $node->content = drupal_render($node) or something like >> that. >> >> - We might want to think about adding other fields to our default content >> types. Perhaps Article should have a Subtitle field, etc. This is a whole >> topic in itself. >> >> Comments? >> >> Thanks, >> >> Barry >> > > From ronald at istos.it Wed Feb 11 05:41:22 2009 From: ronald at istos.it (Ronald Ashri) Date: Wed, 11 Feb 2009 06:41:22 +0100 Subject: [development] Body and teaser as fields In-Reply-To: <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> Message-ID: <49926502.3080607@istos.it> Absolutely makes sense for me to remove Body and Teaser - talking from a user's/developer's perspective I've spent enough time trying to remove them already - they almost never quite work for what I am trying to do. Based on how we use Drupal at times even Title is an inconvenience, but I guess removing that as well would create more problems than solve. What we could then do is provide more useful content types for users to start with - in the case of Page and Story simply changing the field names would be enough to help people. For example a page could be a Title and Content, but a story would be Title, Post (a more blog-like name), Teaser (as a separate field - because although the js divider idea is a nice one it is confusing to people and does not fit the needs of a story too often). We could then also add other types as examples for people. Anyway, I am sure the far more sophisticated usability testing going on is going to throw up all these issues. Best, Ronald Moshe Weitzman wrote: > core would get rid of it. and there will be much rejoicing in usabilty land. > > On Tue, Feb 10, 2009 at 11:45 PM, Matt Farina wrote: > >> On the UI side including the teaser splitter JavaScript might be ugly. How >> would we handle this special case? Or, do we get rid of the teaser splitter? >> >> >> On Feb 10, 2009, at 11:20 PM, Barry Jaspan wrote: >> >> >>> Now that Field API is in core it is time to start using it. I have an >>> initial suggestion: change node body and teaser from special cases to normal >>> fields. I suspect this is going to be quite controversial so I thought I'd >>> get some feedback here before evening bothering to start looking at the >>> code. >>> >>> This message is not about the details of the implementation; I'm sure >>> there will be subtleties and complexities to work. I'm just asking about >>> the concept. >>> >>> Concept: >>> >>> Remove all special processing for $node->body and $node->teaser. Create >>> two fields, body and teaser, both text fields. Assign both fields to every >>> existing content type with a "body field" using the textarea widget. For >>> existing nodes, as part of the upgrade path, initialize the teaser field >>> value with whatever teaser would normally be generated automatically from >>> the body. >>> >>> Random thoughts: >>> >>> - We will get to remove a bunch of code, much of it quite ugly, from >>> node.module. >>> >>> - Sites that really want an auto-generated teaser can remove the teaser >>> field from a content type and use the text field's teaser Display Formatter >>> in the teaser context. >>> >>> - This will mean removing the body field from the node and node_revision >>> tables, and creating a field_data_body table for it instead. Don't worry >>> about database query efficiency; that is a solved problem (see >>> http://drupal.org/node/368674). >>> >>> - With $node->body and $node->teaser being normal fields, they will not be >>> available for overloaded use as the complete rendered output of the node. >>> Hurray! We can use $node->content = drupal_render($node) or something like >>> that. >>> >>> - We might want to think about adding other fields to our default content >>> types. Perhaps Article should have a Subtitle field, etc. This is a whole >>> topic in itself. >>> >>> Comments? >>> >>> Thanks, >>> >>> Barry >>> >>> >> From larry at garfieldtech.com Wed Feb 11 07:02:31 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Wed, 11 Feb 2009 01:02:31 -0600 Subject: [development] Flex API, XML API modules are they needed? In-Reply-To: <025F0983-1603-460C-8C5E-4937327059AD@metzlerd.com> References: <238CA5C3-4EAC-4E07-AF87-28DDE781A70E@sentex.net> <025F0983-1603-460C-8C5E-4937327059AD@metzlerd.com> Message-ID: <200902110102.31480.larry@garfieldtech.com> On Tuesday 10 February 2009 9:22:26 pm David Metzler wrote: > This was a primary concern for me. I still haven't figured out why > database drivers never do this....? It seems so straightforward to > think of parameters as key value pairs. What I did here was to > rewrite the parameters array into one that was numerically based > because hey the postgres driver needed numerical bind arguments. I > just got tired of hand rolling arrays arrays as parameters when I had > a perfectly good $form_values array or simplexml object to use as the > parameter source. > > If DBTNG allows extra parameters to be passed that don't get used in > the query then it's probably close enough for what most people need, > and the XML to array conversion api would get you the rest of the way > there anyway. PDO gets cranky if your argument count does not exactly match your placeholder count. DBTNG doesn't do any extra checking on top of that for you, so yes you do need to make sure you pass in only those values that you need and nothing else. Some databases support reusing placeholders. Some do not. Who knows why; database vendors are silly people. PDO has gone back and forth on whether it tries to emulate reuse on databases that don't natively support it or not (a process that was frequently buggy, according to PDO's principal author, Wez Furlong), creating a situation where unless you know your precise version down to the .z level you can't reliably assume that it's going to work. So we assume that you can't reuse placeholders. Any XML-to-array conversion should happen outside the DB layer, IMO. -- Larry Garfield larry at garfieldtech.com From larry at garfieldtech.com Wed Feb 11 07:11:41 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Wed, 11 Feb 2009 01:11:41 -0600 Subject: [development] Body and teaser as fields In-Reply-To: <49926502.3080607@istos.it> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> Message-ID: <200902110111.41894.larry@garfieldtech.com> The special case handling that body gets right now is more properly "old legacy crappy way of doing things". It's a special case only by virtue of being old and non-updated, and it makes life much harder for themers, for Views, etc. The last several sites I've spec'ed out have involved removing the body field on *all* node types completely and replacing them with a shared CCK field just to avoid the nonsense that is the core body field. In other words, huge +1 on making body just another "FiC field". I also use teasers almost never. They're slow, difficult to configure, and the teaser splitter dojobby ranks as one of our dumbest "usability improvements" ever IMO. :-) (Yeah, come on Larry, tell us how you really feel.) The one and only place I ever use it is on my blog, where I manually set myself TYVM. For a real site I'm building for someone, I virtually never use teasers. If I want a list of something, I give the node a "Lead" CCK field and make a list view of it, as that's about 10x faster since it avoids the node load, and gives me much much much more theming flexibility to boot. If anything, I can see "teaser" becoming, get this, an alternate formatter for *any* textfield to just stop at the tag or at some number of characters, whichever comes first. That's effectively what we do now in a horribly hacky way. If you want a separate field instead, you add a separate textfield/textarea and use that. Problem solved. In other words, forge on, McJaspan! May the wind be at your back in your quest to exterminate crufty old crap from node.module. (OK, it's after 1 am, I'm tired...) On Tuesday 10 February 2009 11:41:22 pm Ronald Ashri wrote: > Absolutely makes sense for me to remove Body and Teaser - talking from a > user's/developer's perspective I've spent enough time trying to remove > them already - they almost never quite work for what I am trying to do. > Based on how we use Drupal at times even Title is an inconvenience, but > I guess removing that as well would create more problems than solve. > > What we could then do is provide more useful content types for users to > start with - in the case of Page and Story simply changing the field > names would be enough to help people. > > For example a page could be a Title and Content, but a story would be > Title, Post (a more blog-like name), Teaser (as a separate field - > because although the js divider idea is a nice one it is confusing to > people and does not fit the needs of a story too often). We could then > also add other types as examples for people. > > Anyway, I am sure the far more sophisticated usability testing going on > is going to throw up all these issues. > > Best, > > Ronald > > Moshe Weitzman wrote: > > core would get rid of it. and there will be much rejoicing in usabilty > > land. > > > > On Tue, Feb 10, 2009 at 11:45 PM, Matt Farina wrote: > >> On the UI side including the teaser splitter JavaScript might be ugly. > >> How would we handle this special case? Or, do we get rid of the teaser > >> splitter? > >> > >> On Feb 10, 2009, at 11:20 PM, Barry Jaspan wrote: > >>> Now that Field API is in core it is time to start using it. I have an > >>> initial suggestion: change node body and teaser from special cases to > >>> normal fields. I suspect this is going to be quite controversial so I > >>> thought I'd get some feedback here before evening bothering to start > >>> looking at the code. > >>> > >>> This message is not about the details of the implementation; I'm sure > >>> there will be subtleties and complexities to work. I'm just asking > >>> about the concept. > >>> > >>> Concept: > >>> > >>> Remove all special processing for $node->body and $node->teaser. > >>> Create two fields, body and teaser, both text fields. Assign both > >>> fields to every existing content type with a "body field" using the > >>> textarea widget. For existing nodes, as part of the upgrade path, > >>> initialize the teaser field value with whatever teaser would normally > >>> be generated automatically from the body. > >>> > >>> Random thoughts: > >>> > >>> - We will get to remove a bunch of code, much of it quite ugly, from > >>> node.module. > >>> > >>> - Sites that really want an auto-generated teaser can remove the teaser > >>> field from a content type and use the text field's teaser Display > >>> Formatter in the teaser context. > >>> > >>> - This will mean removing the body field from the node and > >>> node_revision tables, and creating a field_data_body table for it > >>> instead. Don't worry about database query efficiency; that is a solved > >>> problem (see http://drupal.org/node/368674). > >>> > >>> - With $node->body and $node->teaser being normal fields, they will not > >>> be available for overloaded use as the complete rendered output of the > >>> node. Hurray! We can use $node->content = drupal_render($node) or > >>> something like that. > >>> > >>> - We might want to think about adding other fields to our default > >>> content types. Perhaps Article should have a Subtitle field, etc. > >>> This is a whole topic in itself. > >>> > >>> Comments? > >>> > >>> Thanks, > >>> > >>> Barry -- Larry Garfield larry at garfieldtech.com From kvantomme at gmail.com Wed Feb 11 07:42:58 2009 From: kvantomme at gmail.com (Kristof Van Tomme) Date: Wed, 11 Feb 2009 08:42:58 +0100 Subject: [development] Body and teaser as fields In-Reply-To: <200902110111.41894.larry@garfieldtech.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <200902110111.41894.larry@garfieldtech.com> Message-ID: +1 that just makes sense From victorkane at gmail.com Wed Feb 11 08:15:31 2009 From: victorkane at gmail.com (Victor Kane) Date: Wed, 11 Feb 2009 06:15:31 -0200 Subject: [development] File Security Module In-Reply-To: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> References: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> Message-ID: oooh, sounds like a candidate for a drush extension. See http://drupal.org/project/drush and http://drupal.org/project/drush_extras In its version two in Drupal 6, for example, drush exists entirely outside of Drupal, so on a production server with several different sites, or on your own development box or testing machine, you can install once and run many times. Moreover, it is not a module, but a self-contained system. And the cool part is that in your home user directory you can store easy-to-write extensions, starting with drush_extras (./home/drush). Victor Kane http://awebfactory.com.ar On Wed, Feb 11, 2009 at 1:50 AM, Jon Antoine wrote: > After installing Drupal many times and having to check file > permissions to make sure the site was secure, I got to thinking about > how to automate this process. I started by writing a script to take > care of this, but eventually I thought a Drupal module might be the > way to go. The module could provide a hook, say hook_file_security, > that would take an array of files names and their suggested security > parameters. This could work very similar to the updates module > providing information on the admin/reports/status page and an > admin/reports/file-security page that displayed all installed modules, > their files, the suggested security settings, and the current security > settings. > > Well, that is the base idea I had. I think something like this would > really help new users of Drupal and I'm pretty sure it's possible > since the installation script reports on the security settings of the > files directory and the settings.php file. Any thoughts, ideas, > suggestions are welcome. > > Cheers, > > Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/5194b382/attachment.htm From steev at initsix.co.uk Wed Feb 11 07:49:43 2009 From: steev at initsix.co.uk (Steve Power) Date: Wed, 11 Feb 2009 07:49:43 +0000 Subject: [development] File Security Module In-Reply-To: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> References: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> Message-ID: <651c6d110902102349p1a6fb3bdm5728f20de7ff7f3c@mail.gmail.com> Its a great idea. An extensible security module would be great. Im happy to lend a hand in design or code. There is lots more it could do (feed into IDS etc) but just basic file security (and maybe .htaccess checking) would be a great boon. steev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/5e57fc96/attachment.htm From steev at initsix.co.uk Wed Feb 11 07:52:40 2009 From: steev at initsix.co.uk (Steve Power) Date: Wed, 11 Feb 2009 07:52:40 +0000 Subject: [development] Body and teaser as fields In-Reply-To: References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <200902110111.41894.larry@garfieldtech.com> Message-ID: <651c6d110902102352l6ca8f6bq5b80b8ce8eaa3ed2@mail.gmail.com> +1 - although im dismayed to find im the only one who likes the js teaser break thing - if anything this is what has impressed a lot of users more than anything in my experience!. havent used body for aaaages tho. steev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/5ffffc10/attachment.htm From stella at stellapower.net Wed Feb 11 09:36:33 2009 From: stella at stellapower.net (Stella Power) Date: Wed, 11 Feb 2009 09:36:33 +0000 Subject: [development] Body and teaser as fields In-Reply-To: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> Message-ID: Yep, I'm definitely in favour of this. It would make things a lot cleaner and more usable. So +1 from me. Cheers, Stella On Wed, Feb 11, 2009 at 4:20 AM, Barry Jaspan wrote: > Now that Field API is in core it is time to start using it. I have an > initial suggestion: change node body and teaser from special cases to normal > fields. I suspect this is going to be quite controversial so I thought I'd > get some feedback here before evening bothering to start looking at the > code. > > This message is not about the details of the implementation; I'm sure there > will be subtleties and complexities to work. I'm just asking about the > concept. > > Concept: > > Remove all special processing for $node->body and $node->teaser. Create > two fields, body and teaser, both text fields. Assign both fields to every > existing content type with a "body field" using the textarea widget. For > existing nodes, as part of the upgrade path, initialize the teaser field > value with whatever teaser would normally be generated automatically from > the body. > > Random thoughts: > > - We will get to remove a bunch of code, much of it quite ugly, from > node.module. > > - Sites that really want an auto-generated teaser can remove the teaser > field from a content type and use the text field's teaser Display Formatter > in the teaser context. > > - This will mean removing the body field from the node and node_revision > tables, and creating a field_data_body table for it instead. Don't worry > about database query efficiency; that is a solved problem (see > http://drupal.org/node/368674). > > - With $node->body and $node->teaser being normal fields, they will not be > available for overloaded use as the complete rendered output of the node. > Hurray! We can use $node->content = drupal_render($node) or something like > that. > > - We might want to think about adding other fields to our default content > types. Perhaps Article should have a Subtitle field, etc. This is a whole > topic in itself. > > Comments? > > Thanks, > > Barry > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/2ecaf49b/attachment.htm From catch56 at googlemail.com Wed Feb 11 10:32:04 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 11 Feb 2009 10:32:04 +0000 Subject: [development] Body and teaser as fields In-Reply-To: References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> Message-ID: - This will mean removing the body field from the node and node_revision tables, and creating a field_data_body table for it instead. Don't worry about database query efficiency; that is a solved problem (see http://drupal.org/node/368674) > > . Since Drupal 5 or 6 there's not been a body column in the node table anyway, so at the very worst we'd be looking at an extra select - which would be a cache_get() 90% of the time anyway. Would be nice to skip the join to node_revision for the title field (node.title doesn't get used in node_load()), then we actually lose a join in the default case. If anything it'll make our base query more efficient (and I've got plans to remove the join on users elsewhere, although a different issue of course). So +1, the teaser splitter definitely comes down as a DrupalWTF and could be happily moved into contrib, have you posted the issue yet? Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/bd402123/attachment.htm From ojacquet at jax.be Wed Feb 11 11:46:49 2009 From: ojacquet at jax.be (Olivier Jacquet) Date: Wed, 11 Feb 2009 12:46:49 +0100 Subject: [development] RFC: Module checksum module Message-ID: <4992BAA9.7090306@jax.be> Hi, When developing with Drupal you often use contrib modules. When using contrib modules it happens that you find a bug or need it to behave differently than what was intended. So you modify the module. Now you have to have a method for knowing that this module is no longer the stock contrib module. I've seen different shops hande this in different ways but never really in a robust way. That's why I want to suggest the "module checksum" module. When you activate a module, the directory it is in is checksummed and the result stored. The module then allows you to rerun the checksum against all modules and shows for which modules the new checksum no longer matches. These are the modules that have been modified. With this list you can make sure you have the necessary patches before you upgrade said modules. I've briefly looked around and have not found anything like this. Is there? Any other suggestions or remarks? If not, I think I'll go ahead and make it. Best regards, Olivier From gabor at hojtsy.hu Wed Feb 11 12:31:12 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Wed, 11 Feb 2009 13:31:12 +0100 Subject: [development] RFC: Module checksum module In-Reply-To: <4992BAA9.7090306@jax.be> References: <4992BAA9.7090306@jax.be> Message-ID: <86ca3ccb0902110431t6db3a28fyb688820e904bcbea@mail.gmail.com> Hi Olivier, Many of us just use straight CVS checkouts of the modules. Then you can just do a CVS diff and see what kinds of changes you made to the module, if you did. G?bor On Wed, Feb 11, 2009 at 12:46 PM, Olivier Jacquet wrote: > Hi, > > > When developing with Drupal you often use contrib modules. When using > contrib modules it happens that you find a bug or need it to behave > differently than what was intended. So you modify the module. > > Now you have to have a method for knowing that this module is no longer the > stock contrib module. I've seen different shops hande this in different ways > but never really in a robust way. > > That's why I want to suggest the "module checksum" module. When you activate > a module, the directory it is in is checksummed and the result stored. The > module then allows you to rerun the checksum against all modules and shows > for which modules the new checksum no longer matches. These are the modules > that have been modified. With this list you can make sure you have the > necessary patches before you upgrade said modules. > > I've briefly looked around and have not found anything like this. Is there? > Any other suggestions or remarks? If not, I think I'll go ahead and make it. > > > Best regards, > Olivier > From news at unleashedmind.com Wed Feb 11 12:42:39 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Wed, 11 Feb 2009 13:42:39 +0100 Subject: [development] RFC: Module checksum module In-Reply-To: <4992BAA9.7090306@jax.be> Message-ID: <08b101c98c46$3963c910$0200a8c0@structworks.com> > That's why I want to suggest the "module checksum" module. > When you activate a module, the directory it is in is > checksummed and the result stored. The module then allows you > to rerun the checksum against all modules and shows for which > modules the new checksum no longer matches. > These are the modules that have been modified. With this list > you can make sure you have the necessary patches before you > upgrade said modules. > > Best regards, > Olivier Just indicating that a module has been altered is too limited, IMO. Journal module (http://drupal.org/project/journal) recently implemented a "Patch log" feature (only available in latest dev snapshot currently), which allows you to keep track of any patches and hacks you applied to the modules on your site. This means you can lookup whether you can safely update to a later version of a module (given the possibility that your patch has been committed). Daniel From karen at elderweb.com Wed Feb 11 13:13:11 2009 From: karen at elderweb.com (Karen Stevenson) Date: Wed, 11 Feb 2009 07:13:11 -0600 Subject: [development] Body and teaser as fields In-Reply-To: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> Message-ID: <5b489e7b0902110513p3d8ae525ya53cd260744bb166@mail.gmail.com> +1 on getting rid of the teaser splitter -- I've been using css to hide it :) The teaser splitter could become a contrib field module, if anyone wants to save it. On auto-creating both a body and a teaser field -- is there a way to skip creating a second field for all the sites where the teaser is just a subset of the body? We really only need two fields if they have different content. I suppose it's a lot simpler to just automatically create it in all cases, so maybe simplicity wins out. The only other question I have is what happens when there is no official 'body' field that other modules might expect to find. I guess we've already made the body optional so they should not be expecting that anyway. Is there any reason why losing a field that has had special meaning could be a problem to contrib modules? Karen On Tue, Feb 10, 2009 at 10:20 PM, Barry Jaspan wrote: > Now that Field API is in core it is time to start using it. I have an > initial suggestion: change node body and teaser from special cases to normal > fields. I suspect this is going to be quite controversial so I thought I'd > get some feedback here before evening bothering to start looking at the > code. > > This message is not about the details of the implementation; I'm sure there > will be subtleties and complexities to work. I'm just asking about the > concept. > > Concept: > > Remove all special processing for $node->body and $node->teaser. Create > two fields, body and teaser, both text fields. Assign both fields to every > existing content type with a "body field" using the textarea widget. For > existing nodes, as part of the upgrade path, initialize the teaser field > value with whatever teaser would normally be generated automatically from > the body. > > Random thoughts: > > - We will get to remove a bunch of code, much of it quite ugly, from > node.module. > > - Sites that really want an auto-generated teaser can remove the teaser > field from a content type and use the text field's teaser Display Formatter > in the teaser context. > > - This will mean removing the body field from the node and node_revision > tables, and creating a field_data_body table for it instead. Don't worry > about database query efficiency; that is a solved problem (see > http://drupal.org/node/368674). > > - With $node->body and $node->teaser being normal fields, they will not be > available for overloaded use as the complete rendered output of the node. > Hurray! We can use $node->content = drupal_render($node) or something like > that. > > - We might want to think about adding other fields to our default content > types. Perhaps Article should have a Subtitle field, etc. This is a whole > topic in itself. > > Comments? > > Thanks, > > Barry > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/1f892cfe/attachment.htm From syscrusher at 4th.com Wed Feb 11 13:17:54 2009 From: syscrusher at 4th.com (Syscrusher) Date: Wed, 11 Feb 2009 08:17:54 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <49926502.3080607@istos.it> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> Message-ID: <1234358274.12234.32.camel@marcus.gateway.2wire.net> On Wed, 2009-02-11 at 06:41 +0100, Ronald Ashri wrote: > For example a page could be a Title and Content, but a story would be > Title, Post (a more blog-like name), I respectfully disagree. "Content" is a nice generic term, and I think that the same field should be called the same thing across all the standard Drupal-default node types. Also, many Drupal sites are not blogs nor blog-like sites, so we should not assume that blog-ish terminology will be familiar to all Drupal content creators. Kind regards, Scott -- Syscrusher From victorkane at gmail.com Wed Feb 11 13:21:22 2009 From: victorkane at gmail.com (Victor Kane) Date: Wed, 11 Feb 2009 11:21:22 -0200 Subject: [development] Body and teaser as fields In-Reply-To: <1234358274.12234.32.camel@marcus.gateway.2wire.net> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> Message-ID: If there are any improvements at all to be gained here, it is that there should be NO default Drupal content types, except maybe by way of example. Therefore, _nothing_ should be assumed about sub-class terms, they will be up to the end user in each case. So rather than argue in favor or against "post" as opposed to whatever, something like "content" (i.e. generic) is what should go. Victor Kane http://awebfactory.com.ar On Wed, Feb 11, 2009 at 11:17 AM, Syscrusher wrote: > On Wed, 2009-02-11 at 06:41 +0100, Ronald Ashri wrote: > > For example a page could be a Title and Content, but a story would be > > Title, Post (a more blog-like name), > > > I respectfully disagree. "Content" is a nice generic term, and I think > that the same field should be called the same thing across all the > standard Drupal-default node types. Also, many Drupal sites are not > blogs nor blog-like sites, so we should not assume that blog-ish > terminology will be familiar to all Drupal content creators. > > Kind regards, > > Scott > -- > Syscrusher > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/e07c8506/attachment.htm From ojacquet at jax.be Wed Feb 11 14:00:52 2009 From: ojacquet at jax.be (Olivier Jacquet) Date: Wed, 11 Feb 2009 15:00:52 +0100 Subject: [development] RFC: Module checksum module In-Reply-To: <86ca3ccb0902110431t6db3a28fyb688820e904bcbea@mail.gmail.com> References: <4992BAA9.7090306@jax.be> <86ca3ccb0902110431t6db3a28fyb688820e904bcbea@mail.gmail.com> Message-ID: <4992DA14.3080602@jax.be> G?bor Hojtsy wrote, On 11/02/2009 13:31: > Hi Olivier, > > Many of us just use straight CVS checkouts of the modules. Then you > can just do a CVS diff and see what kinds of changes you made to the > module, if you did. > > G?bor > Thanks for the tip. I've tried it and I'll be using that method from now on. Even updates to a new version work that way and if your custom changes do not interfere they stay active. From dragonwize at gmail.com Wed Feb 11 15:03:46 2009 From: dragonwize at gmail.com (dragonwize) Date: Wed, 11 Feb 2009 10:03:46 -0500 Subject: [development] RFC: Module checksum module In-Reply-To: <4992DA14.3080602@jax.be> References: <4992BAA9.7090306@jax.be> <86ca3ccb0902110431t6db3a28fyb688820e904bcbea@mail.gmail.com> <4992DA14.3080602@jax.be> Message-ID: There also this module attempting a solution: http://drupal.org/project/file_integrity -- Alan Doucette From arancaytar.ilyaran at gmail.com Wed Feb 11 15:28:30 2009 From: arancaytar.ilyaran at gmail.com (Arancaytar Ilyaran) Date: Wed, 11 Feb 2009 16:28:30 +0100 Subject: [development] RFC: Module checksum module In-Reply-To: <4992BAA9.7090306@jax.be> References: <4992BAA9.7090306@jax.be> Message-ID: <4992EE9E.4000507@gmail.com> Olivier Jacquet wrote: > > When developing with Drupal you often use contrib modules. When using > contrib modules it happens that you find a bug or need it to behave > differently than what was intended. So you modify the module. > > Now you have to have a method for knowing that this module is no longer > the stock contrib module. I've seen different shops hande this in > different ways but never really in a robust way. Your mileage may vary, but I've found that checking code out from CVS helps a lot when tracking local modifications. I deploy all my sites this way. If you don't want to use the dev branch, you can check out a sticky release tag, too - you won't get updates via "cvs update" that way, but you'll still be able to see all your local modifications. That doesn't mean yours is not a good idea, of course. :) -- Arancaytar ---------------------- Nothing beside remains: Round the decay Of that colossal wreck, boundless and bare The lone and level sands stretch far away... ---------------------- PGP: http://ermarian.net/downloads/0x27CA5C74 XMPP: arancaytar.ilyaran at gmail.com AOL: 282026638 / RealArancaytar URL: http://ermarian.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.drupal.org/pipermail/development/attachments/20090211/db788780/attachment-0001.pgp From arancaytar.ilyaran at gmail.com Wed Feb 11 15:32:22 2009 From: arancaytar.ilyaran at gmail.com (Arancaytar Ilyaran) Date: Wed, 11 Feb 2009 16:32:22 +0100 Subject: [development] RFC: Module checksum module In-Reply-To: <4992EE9E.4000507@gmail.com> References: <4992BAA9.7090306@jax.be> <4992EE9E.4000507@gmail.com> Message-ID: <4992EF86.9080609@gmail.com> Arancaytar Ilyaran wrote: > Olivier Jacquet wrote: >> When developing with Drupal you often use contrib modules. When using >> contrib modules it happens that you find a bug or need it to behave >> differently than what was intended. So you modify the module. >> >> Now you have to have a method for knowing that this module is no longer >> the stock contrib module. I've seen different shops hande this in >> different ways but never really in a robust way. > > Your mileage may vary, but I've found that checking code out from CVS helps a > lot when tracking local modifications. I deploy all my sites this way. If you > don't want to use the dev branch, you can check out a sticky release tag, too - > you won't get updates via "cvs update" that way, but you'll still be able to see > all your local modifications. > > That doesn't mean yours is not a good idea, of course. :) > Apologies for the redundancy, my mail client had only downloaded the first message of this thread for some reason. Of course this has been said before by now. :) -- Arancaytar ---------------------- Nothing beside remains: Round the decay Of that colossal wreck, boundless and bare The lone and level sands stretch far away... ---------------------- PGP: http://ermarian.net/downloads/0x27CA5C74 XMPP: arancaytar.ilyaran at gmail.com AOL: 282026638 / RealArancaytar URL: http://ermarian.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://lists.drupal.org/pipermail/development/attachments/20090211/71025fe4/attachment.pgp From ronald at istos.it Wed Feb 11 17:16:36 2009 From: ronald at istos.it (Ronald Ashri) Date: Wed, 11 Feb 2009 18:16:36 +0100 Subject: [development] Body and teaser as fields In-Reply-To: References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> Message-ID: <499307F4.1000403@istos.it> Hi, syscrusher: I was simply giving an example - as I said more thorough usability testing will give these answers. If "content" is the way to go then that's great. victor: As for having default content types I think there are two levels - Drupal as a system/framework should not assume anything but a fresh installation should give a user(especially a new one that is probably just exploring the system) some types to work with, even if it is just a way to illustrate that different types that are possible. If the first thing a new user has to do is actually create a content type then we lost them right there... Best, Ronald Victor Kane wrote: > If there are any improvements at all to be gained here, it is that > there should be NO default Drupal content types, except maybe by way > of example. > > Therefore, _nothing_ should be assumed about sub-class terms, they > will be up to the end user in each case. > > So rather than argue in favor or against "post" as opposed to > whatever, something like "content" (i.e. generic) is what should go. > > Victor Kane > http://awebfactory.com.ar > > On Wed, Feb 11, 2009 at 11:17 AM, Syscrusher > wrote: > > On Wed, 2009-02-11 at 06:41 +0100, Ronald Ashri wrote: > > For example a page could be a Title and Content, but a story > would be > > Title, Post (a more blog-like name), > > > I respectfully disagree. "Content" is a nice generic term, and I think > that the same field should be called the same thing across all the > standard Drupal-default node types. Also, many Drupal sites are not > blogs nor blog-like sites, so we should not assume that blog-ish > terminology will be familiar to all Drupal content creators. > > Kind regards, > > Scott > -- > Syscrusher > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/64baebb8/attachment.htm From andrewberry at sentex.net Wed Feb 11 17:01:59 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Wed, 11 Feb 2009 12:01:59 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <200902110111.41894.larry@garfieldtech.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <200902110111.41894.larry@garfieldtech.com> Message-ID: <35C2A421-9EB4-40CD-B8FC-CB9049EC405B@sentex.net> On 11-Feb-09, at 2:11 AM, Larry Garfield wrote: > I also use teasers almost never. They're slow, difficult to > configure, and the > teaser splitter dojobby ranks as one of our dumbest "usability > improvements" > ever IMO I'm surprised that there are many here who aren't using teasers. I think it's much more likely for users to use teasers and not developers, because they wouldn't encounter the benefits of replacing the teaser with a CCK field. The main problem I encounter with teasers is the name. "Summary" or "Introduction" is how I explain it to my users, and when they understand that, they're quite happy to use it in its intended manner. JS-splitter and all! > On auto-creating both a body and a teaser field -- is there a way to > skip creating a second field for all the sites where the teaser is > just a subset of the body? It'd have to catch the case where the teaser is a subset, but the default position of has moved as well. I'd support only creating a teaser field on site upgrades, and having just a body field on new installs. --Andrew From larry at garfieldtech.com Wed Feb 11 17:49:37 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Wed, 11 Feb 2009 11:49:37 -0600 Subject: [development] RFC: Module checksum module In-Reply-To: <4992BAA9.7090306@jax.be> References: <4992BAA9.7090306@jax.be> Message-ID: For this to be really useful, it would need to integrate into update.module. Doesn't Acquia Drupal include something like this already? Could that be generalized? (Many of us check modules out from CVS directly, but many of us don't. I don't, generally.) --Larry Garfield On Wed, 11 Feb 2009 12:46:49 +0100, Olivier Jacquet wrote: > Hi, > > > When developing with Drupal you often use contrib modules. When using > contrib modules it happens that you find a bug or need it to behave > differently than what was intended. So you modify the module. > > Now you have to have a method for knowing that this module is no longer > the stock contrib module. I've seen different shops hande this in > different ways but never really in a robust way. > > That's why I want to suggest the "module checksum" module. When you > activate a module, the directory it is in is checksummed and the result > stored. The module then allows you to rerun the checksum against all > modules and shows for which modules the new checksum no longer matches. > These are the modules that have been modified. With this list you can > make sure you have the necessary patches before you upgrade said modules. > > I've briefly looked around and have not found anything like this. Is > there? Any other suggestions or remarks? If not, I think I'll go ahead > and make it. > > > Best regards, > Olivier From syscrusher at 4th.com Thu Feb 12 00:23:34 2009 From: syscrusher at 4th.com (Syscrusher) Date: Wed, 11 Feb 2009 19:23:34 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <499307F4.1000403@istos.it> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> Message-ID: <1234398214.12234.34.camel@marcus.gateway.2wire.net> On Wed, 2009-02-11 at 18:16 +0100, Ronald Ashri wrote: > syscrusher: I was simply giving an example - as I said more thorough > usability testing will give these answers. If "content" is the way to > go then that's great. Understood, and I didn't mean to sound unduly critical. > > victor: As for having default content types I think there are two > levels - Drupal as a system/framework should not assume anything but a > fresh installation should give a user(especially a new one that is > probably just exploring the system) some types to work with, even if > it is just a way to illustrate that different types that are possible. > If the first thing a new user has to do is actually create a content > type then we lost them right there... I heartily concur. Kind regards, Scott -- Syscrusher From kb at 2bits.com Thu Feb 12 00:38:57 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Wed, 11 Feb 2009 19:38:57 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <1234398214.12234.34.camel@marcus.gateway.2wire.net> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> <1234398214.12234.34.camel@marcus.gateway.2wire.net> Message-ID: <4a9fdc630902111638l3e430931k1e53ceb45d83b49b@mail.gmail.com> > > > > > victor: As for having default content types I think there are two > > levels - Drupal as a system/framework should not assume anything but a > > fresh installation should give a user(especially a new one that is > > probably just exploring the system) some types to work with, even if > > it is just a way to illustrate that different types that are possible. > > If the first thing a new user has to do is actually create a content > > type then we lost them right there... > > I heartily concur. > > It should be up to the default install profile to create the two default types we have (page and article). Other install profiles can do what they want, including no content types at all. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090211/8e16f254/attachment.htm From wilco at nurf.com Thu Feb 12 01:01:53 2009 From: wilco at nurf.com (william roboly) Date: Wed, 11 Feb 2009 20:01:53 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <4a9fdc630902111638l3e430931k1e53ceb45d83b49b@mail.gmail.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> <1234398214.12234.34.camel@marcus.gateway.2wire.net> <4a9fdc630902111638l3e430931k1e53ceb45d83b49b@mail.gmail.com> Message-ID: <49937501.1040100@nurf.com> +1 removing default content types +1 getting rid of $node->body & $node->teaser +1 on offing the js-splitter +1 on field formatter that handles sizing or splitting content from the "display field" tab where it would seem more logical to handle this sort of thing. From victorkane at gmail.com Thu Feb 12 02:34:27 2009 From: victorkane at gmail.com (Victor Kane) Date: Thu, 12 Feb 2009 00:34:27 -0200 Subject: [development] Body and teaser as fields In-Reply-To: <499307F4.1000403@istos.it> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> Message-ID: On Wed, Feb 11, 2009 at 3:16 PM, Ronald Ashri wrote: Agreed, absolutely. But these example content types should be constructed in the same way anyone would construct one, and there should be no magical behavior associated with any of their fields that are not associated with any others anyone might make. Victor victor: As for having default content types I think there are two levels - > Drupal as a system/framework should not assume anything but a fresh > installation should give a user(especially a new one that is probably just > exploring the system) some types to work with, even if it is just a way to > illustrate that different types that are possible. If the first thing a new > user has to do is actually create a content type then we lost them right > there... > > Best, > > Ronald > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/db2aec31/attachment.htm From antoinesolutions at gmail.com Thu Feb 12 02:50:02 2009 From: antoinesolutions at gmail.com (Jon Antoine) Date: Wed, 11 Feb 2009 18:50:02 -0800 Subject: [development] File Security Module In-Reply-To: <651c6d110902102349p1a6fb3bdm5728f20de7ff7f3c@mail.gmail.com> References: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> <651c6d110902102349p1a6fb3bdm5728f20de7ff7f3c@mail.gmail.com> Message-ID: <445719130902111850l4c3a72edif23e16a47f0ede81@mail.gmail.com> Victor, Thanks for your interest. I read up a little on drush and it seems like a really powerful system, but I'm not quite sure its the right way to go with this. Here are some more specifics of what I had in mind. Let me know if you disagree. 1. My first thought was that this would eventually make it into Drupal core. I know that's a long shot, but there are always new web developers getting thier feet wet and this would help ensure a safe and secure Drupal site. drush is a system in itself and would require new users to first, know about it, and second, know how to use it. Not really a newbie thing. 2. I wanted this module to provide a hook that other modules could use to define the files in their module and specify default permissions for those files. If this were a drush extension, it would require that others know about drush and know how to use drush in order to take advantage of the functionality which in the long run I think would mean not as wide an addoption. Steve, I agree, this module could be a lot more than what I had initially thought of. I haven't developed a module that defined it's own hook yet, so I am going to look into what that entails. I would appreciate any up-front design help and code help later on. Cheers, Jon Antoine Antoine Solutions Open Source Development Tutorials & Documentation dev.antoinesolutions.com On Tue, Feb 10, 2009 at 11:49 PM, Steve Power wrote: > Its a great idea. An extensible security module would be great. Im happy to > lend a hand in design or code. > > There is lots more it could do (feed into IDS etc) but just basic file > security (and maybe .htaccess checking) would be a great boon. > > steev > > From victorkane at gmail.com Thu Feb 12 09:20:13 2009 From: victorkane at gmail.com (Victor Kane) Date: Thu, 12 Feb 2009 07:20:13 -0200 Subject: [development] File Security Module In-Reply-To: <445719130902111850l4c3a72edif23e16a47f0ede81@mail.gmail.com> References: <445719130902101950l75645138p4f715a82eff9c289@mail.gmail.com> <651c6d110902102349p1a6fb3bdm5728f20de7ff7f3c@mail.gmail.com> <445719130902111850l4c3a72edif23e16a47f0ede81@mail.gmail.com> Message-ID: I see where you are going, in that case, full speed ahead! On Thu, Feb 12, 2009 at 12:50 AM, Jon Antoine wrote: > Victor, > > Thanks for your interest. I read up a little on drush and it seems > like a really powerful system, but I'm not quite sure its the right > way to go with this. Here are some more specifics of what I had in > mind. Let me know if you disagree. > > 1. My first thought was that this would eventually make it into > Drupal core. I know that's a long shot, but there are always new web > developers getting thier feet wet and this would help ensure a safe > and secure Drupal site. drush is a system in itself and would require > new users to first, know about it, and second, know how to use it. > Not really a newbie thing. > 2. I wanted this module to provide a hook that other modules could > use to define the files in their module and specify default > permissions for those files. If this were a drush extension, it would > require that others know about drush and know how to use drush in > order to take advantage of the functionality which in the long run I > think would mean not as wide an addoption. > > Steve, > > I agree, this module could be a lot more than what I had initially > thought of. I haven't developed a module that defined it's own hook > yet, so I am going to look into what that entails. I would appreciate > any up-front design help and code help later on. > > Cheers, > > Jon Antoine > Antoine Solutions > Open Source Development Tutorials & Documentation > dev.antoinesolutions.com > > > > On Tue, Feb 10, 2009 at 11:49 PM, Steve Power wrote: > > Its a great idea. An extensible security module would be great. Im happy > to > > lend a hand in design or code. > > > > There is lots more it could do (feed into IDS etc) but just basic file > > security (and maybe .htaccess checking) would be a great boon. > > > > steev > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/61bc5b60/attachment.htm From dries at buytaert.net Thu Feb 12 11:40:57 2009 From: dries at buytaert.net (Dries Buytaert) Date: Thu, 12 Feb 2009 12:40:57 +0100 Subject: [development] New project vocabularies Message-ID: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> Hello all, in participation of the new project pages and navigation as envisioned by Mark Boulton (see [1] and [2]), we added two new vocabularies to the project pages on drupal.org. We decided to add these in preparation of the new design so that we'd have enough data by the time we launch the new drupal.org (and so we can do proper performance testing of the Solr integration). If you edit your project(s), you'll see the two new vocabularies that I'm talking about, and how they relate to the designs in [1] and [2]. [1] http://drupal.markboultondesign.com/iteration11/download.html [2] http://drupal.markboultondesign.com/iteration11/modules.html Thanks! -- Dries Buytaert :: http://buytaert.net/ From drupal at rocktreesky.com Thu Feb 12 12:44:50 2009 From: drupal at rocktreesky.com (Addison Berry) Date: Thu, 12 Feb 2009 07:44:50 -0500 Subject: [development] New project vocabularies In-Reply-To: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> Message-ID: Hm, while I get trying to categorize, I just want to point out that a vast majority of modules will select very single "Type of site" so I'm not sure that list is all that helpful. :-/ Most modules good for an E- learning site are probably good for lots of other kinds of sites too. Just curious are we going to "maintain" the tags list of just let module owners do what they will. I can see people doing weird things like --menus, nice, dropdown, CSS, "add1suns modules", "best module evar", "must have" -- etc. It will say something about the maintainer, dependng what they put so I'm not that pressed, but others may get in a froth over it. ;-) - Addi (rulAr of teh nIce Menus Universe) On Feb 12, 2009, at 6:40 AM, Dries Buytaert wrote: > Hello all, > > in participation of the new project pages and navigation as envisioned > by Mark Boulton (see [1] and [2]), we added two new vocabularies to > the project pages on drupal.org. > > We decided to add these in preparation of the new design so that we'd > have enough data by the time we launch the new drupal.org (and so we > can do proper performance testing of the Solr integration). > > If you edit your project(s), you'll see the two new vocabularies that > I'm talking about, and how they relate to the designs in [1] and [2]. > > [1] http://drupal.markboultondesign.com/iteration11/download.html > [2] http://drupal.markboultondesign.com/iteration11/modules.html > > Thanks! > > -- > Dries Buytaert :: http://buytaert.net/ From aldo at caonao.cu Thu Feb 12 12:36:39 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Thu, 12 Feb 2009 07:36:39 -0500 Subject: [development] custom style for content type Message-ID: <200902120736.39800.aldo@caonao.cu> may i apply a custom style sheet to some content type, ex: forums, blogs ?? what i need to modify for this!? thks in advanced -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From kathleen at ceardach.com Thu Feb 12 12:52:31 2009 From: kathleen at ceardach.com (Kathleen Murtagh) Date: Thu, 12 Feb 2009 07:52:31 -0500 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> Message-ID: <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> I completely agree with Addison's sentiments here. With many modules being appropriate for all types of sites, we'll end up with a lot of noise in those categories preventing people from really finding modules that are specifically appropriate for their type of website. How about separating the "always applicable" modules from the type-specific modules? I found the tags a bit confusing. I wasn't quite sure what to put. Help text that is specific to this context would be good, instead of the default general help for freetagging. -- Kathleen Murtagh On Thu, Feb 12, 2009 at 7:44 AM, Addison Berry wrote: > Hm, while I get trying to categorize, I just want to point out that a vast > majority of modules will select very single "Type of site" so I'm not sure > that list is all that helpful. :-/ Most modules good for an E-learning site > are probably good for lots of other kinds of sites too. > > Just curious are we going to "maintain" the tags list of just let module > owners do what they will. I can see people doing weird things like --menus, > nice, dropdown, CSS, "add1suns modules", "best module evar", "must have" -- > etc. It will say something about the maintainer, dependng what they put so > I'm not that pressed, but others may get in a froth over it. ;-) > > - Addi (rulAr of teh nIce Menus Universe) > > > On Feb 12, 2009, at 6:40 AM, Dries Buytaert wrote: > > Hello all, >> >> in participation of the new project pages and navigation as envisioned >> by Mark Boulton (see [1] and [2]), we added two new vocabularies to >> the project pages on drupal.org. >> >> We decided to add these in preparation of the new design so that we'd >> have enough data by the time we launch the new drupal.org (and so we >> can do proper performance testing of the Solr integration). >> >> If you edit your project(s), you'll see the two new vocabularies that >> I'm talking about, and how they relate to the designs in [1] and [2]. >> >> [1] http://drupal.markboultondesign.com/iteration11/download.html >> [2] http://drupal.markboultondesign.com/iteration11/modules.html >> >> Thanks! >> >> -- >> Dries Buytaert :: http://buytaert.net/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/160d71bb/attachment-0001.htm From drupal at ryancross.com Thu Feb 12 13:02:15 2009 From: drupal at ryancross.com (Ryan Cross) Date: Fri, 13 Feb 2009 00:02:15 +1100 Subject: [development] New project vocabularies In-Reply-To: <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> Message-ID: <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> +1 to addison & kathleen's sentiments. I don't think this really has benefits, compared to the downsides. I also think it takes away some of the creativity with using modules for different purposes. On Thu, Feb 12, 2009 at 11:52 PM, Kathleen Murtagh wrote: > I completely agree with Addison's sentiments here. > > With many modules being appropriate for all types of sites, we'll end up > with a lot of noise in those categories preventing people from really > finding modules that are specifically appropriate for their type of > website. How about separating the "always applicable" modules from the > type-specific modules? > > I found the tags a bit confusing. I wasn't quite sure what to put. Help > text that is specific to this context would be good, instead of the default > general help for freetagging. > > -- > Kathleen Murtagh > > > > On Thu, Feb 12, 2009 at 7:44 AM, Addison Berry wrote: > >> Hm, while I get trying to categorize, I just want to point out that a vast >> majority of modules will select very single "Type of site" so I'm not sure >> that list is all that helpful. :-/ Most modules good for an E-learning site >> are probably good for lots of other kinds of sites too. >> >> Just curious are we going to "maintain" the tags list of just let module >> owners do what they will. I can see people doing weird things like --menus, >> nice, dropdown, CSS, "add1suns modules", "best module evar", "must have" -- >> etc. It will say something about the maintainer, dependng what they put so >> I'm not that pressed, but others may get in a froth over it. ;-) >> >> - Addi (rulAr of teh nIce Menus Universe) >> >> >> On Feb 12, 2009, at 6:40 AM, Dries Buytaert wrote: >> >> Hello all, >>> >>> in participation of the new project pages and navigation as envisioned >>> by Mark Boulton (see [1] and [2]), we added two new vocabularies to >>> the project pages on drupal.org. >>> >>> We decided to add these in preparation of the new design so that we'd >>> have enough data by the time we launch the new drupal.org (and so we >>> can do proper performance testing of the Solr integration). >>> >>> If you edit your project(s), you'll see the two new vocabularies that >>> I'm talking about, and how they relate to the designs in [1] and [2]. >>> >>> [1] http://drupal.markboultondesign.com/iteration11/download.html >>> [2] http://drupal.markboultondesign.com/iteration11/modules.html >>> >>> Thanks! >>> >>> -- >>> Dries Buytaert :: http://buytaert.net/ >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090213/52b0f3e3/attachment.htm From ckwu at ck-erp.net Thu Feb 12 12:59:28 2009 From: ckwu at ck-erp.net (C K Wu) Date: Thu, 12 Feb 2009 20:59:28 +0800 Subject: [development] CK-ERP (Open Source ERP / CRM / MRP) v.0.29.1 released (with Drupal 6.8 connector) Message-ID: <49941D30.6070109@ck-erp.net> Hi, folks, I have posted a new release, v.0.29.1, of CK-ERP, at SourceForge.Net, http://sourceforge.net/projects/ck-erp . New features include, new access control module, import of Zencart customer and product records, improved backup/restore process, CK-ERP is an open source accounting/MRP/ERP/CRM system that runs on top of multiple middlewares. It comprises 24 modules - Administration, Data Import, Access Control, i18n, Contact Management, Customer Relationship, Customer Self Service, Vendor Relationship, Ledger, Bank Reconciliation, MRP, Warehouse, Inventory, Service, AP, AR, PO, SO, Quotation, POS for Cashier, POS for Manager, HR, Staff Self Service and Payroll. It provides accounting and back office functionalities to SMEs and utilizes the underlying middleware to administer accounts/groups. Please report error and suggestion to the discussion group / mailing list, CK-ERP-en(at)googlegroups.com or CK-ERP-zh_CN(at)googlegroups.com . General history and expected development is available at the discussion group's Archive. Supported MiddleWares: Centre/SIS, ClaSS; OpenBiblio; CATS; php-residence, phpScheduleIT; AssetMan; Coppermine, Gallery2; phpMyTicket; phpMySport; PSCafePOS, MyHandyRestaurant; FreightFleetManagementSystem; OpenX, LandShop, Open-Realty, FreeRealty; IRM; LegalCase; ClearHealth, OpenEMR, Care2X; eGroupWare, Horde-GroupWare; Zencart, osCommerce; Drupal, Joomla, Mambo, e107, XOOPS, Xaraya; Moodle, Atutor; vTiger; WordPress, b2evolution; TikiWiki; phpBB. Information/Demo Websites: http://ck-erp.org http://ck-erp.net Download is available from, http://sourceforge.net/projects/ck-erp http://gforge.oss.org.cn/projects/ck-erp http://gro.clinux.org/projects/ck-ledger Cheers, Wu Chiu Kay, aka CK Wu, aka CK (CK is the preferred alias) Hong Kong From catch56 at googlemail.com Thu Feb 12 13:15:49 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 12 Feb 2009 13:15:49 +0000 Subject: [development] New project vocabularies In-Reply-To: <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> Message-ID: In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'. You could then show showcases and site recipes next to modules, and modules next to showcases and site recipes in a structured way (and with some data munging, get aggregate data if needed). Was this discussed as an option? Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/70d5224d/attachment.htm From kvantomme at gmail.com Thu Feb 12 13:21:51 2009 From: kvantomme at gmail.com (Kristof Van Tomme) Date: Thu, 12 Feb 2009 14:21:51 +0100 Subject: [development] custom style for content type In-Reply-To: <200902120736.39800.aldo@caonao.cu> References: <200902120736.39800.aldo@caonao.cu> Message-ID: Hi Aldo, What you are looking for is either: -page specific templates http://drupal.org/node/268911 -check out theme components and settings for D6 at http://drupal.org/node/337173 Theming is extensively covered in the theming section on http://drupal.org/theme-guide This is a pretty basic question, that I'm sure you can find lots of information with some strategic Google searches, so the developer mailinglist is probably not the best place to ask this (you might get flamed) ;) Hope this helps! Cheers, Kristof ***************************** I blog at http://www.pronovix.com/blog Twitter at http://twitter.com/kvantomme You can find my profiles on LinkedIn at http://www.linkedin.com/in/kvantomme XING at https://www.xing.com/profile/Kristof_VanTomme and Facebook at http://www.facebook.com/people/Kristof-Van-Tomme/618847872 2009/2/12 Aldo Martinez Selleras : > may i apply a custom style sheet to some content type, ex: forums, blogs ?? > > what i need to modify for this!? > > thks in advanced > > -- > ---------------------- > Aldo Martinez Selleras > Especialista en Telematica > CITMATEL GND Camaguey > Tel: 53 32 291661 > Linux User #364356 > From earnie at users.sourceforge.net Thu Feb 12 13:24:31 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 12 Feb 2009 08:24:31 -0500 Subject: [development] Body and teaser as fields In-Reply-To: References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> Message-ID: <20090212082431.e7gczzcr1hlsgc4s@mail.progw.org> Quoting Victor Kane : > On Wed, Feb 11, 2009 at 3:16 PM, Ronald Ashri wrote: > > Agreed, absolutely. But these example content types should be constructed in > the same way anyone would construct one, and there should be no magical > behavior associated with any of their fields that are not associated with > any others anyone might make. > > Victor > > victor: As for having default content types I think there are two levels - >> Drupal as a system/framework should not assume anything but a fresh >> installation should give a user(especially a new one that is probably just >> exploring the system) some types to work with, even if it is just a way to >> illustrate that different types that are possible. If the first thing a new >> user has to do is actually create a content type then we lost them right >> there... >> How about making the default content types a configurable item for the install profile? -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From drupal at ryancross.com Thu Feb 12 13:24:56 2009 From: drupal at ryancross.com (Ryan Cross) Date: Fri, 13 Feb 2009 00:24:56 +1100 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> Message-ID: <4e983be00902120524s55d5845cu4d3c893cf9ef33e9@mail.gmail.com> THAT sounds *much* cooler (and more useful) than having another vocabulary for modules to try slotting themselves into. +++1 for implementing that instead. On Fri, Feb 13, 2009 at 12:15 AM, Nathaniel Catchpole < catch56 at googlemail.com> wrote: > In the redesign discussions, we'd discussed having nodereferences between > case studies, site recipes and projects for this purpose rather than tags. > That way, people documenting how particular types of sites are built could > show which modules they used - as opposed to project owners saying 'I think > this might be useful for'. You could then show showcases and site recipes > next to modules, and modules next to showcases and site recipes in a > structured way (and with some data munging, get aggregate data if needed). > Was this discussed as an option? > > Nat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090213/dca1714c/attachment.htm From galooph at gmail.com Thu Feb 12 13:45:21 2009 From: galooph at gmail.com (Dan Smith) Date: Thu, 12 Feb 2009 13:45:21 +0000 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> Message-ID: 2009/2/12 Nathaniel Catchpole : > In the redesign discussions, we'd discussed having nodereferences between > case studies, site recipes and projects for this purpose rather than tags. > That way, people documenting how particular types of sites are built could > show which modules they used - as opposed to project owners saying 'I think > this might be useful for'. That sounds really useful! Dan From ronald at istos.it Thu Feb 12 14:00:24 2009 From: ronald at istos.it (Ronald Ashri) Date: Thu, 12 Feb 2009 15:00:24 +0100 Subject: [development] Body and teaser as fields In-Reply-To: <20090212082431.e7gczzcr1hlsgc4s@mail.progw.org> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> <20090212082431.e7gczzcr1hlsgc4s@mail.progw.org> Message-ID: <49942B78.9010406@istos.it> Earnie Boyd wrote: > > How about making the default content types a configurable item for the > install profile? > I think the default install should be zero-configuration to start with (beyond obvious DB name, user, etc). A lot of people are going to give Drupal about 4-5 minutes initally. They will download, unzip, visit install page on browser and fire away. They will assume that any issues will be dealt with and they don't want to learn anything about Drupal before Drupal is actually running on their system because that is the first hurdle. If I can't install it why should I even learn about it. If you ask them "do you want to create content types Page and Story" - already they have to learn something, as in "what are content types then?". Other profiles already assume some familiarity with Drupal and some purpose in what you are trying to achieve so they can happily ask all sorts of questiosn. Best, Ronald From mathews.kyle at gmail.com Thu Feb 12 14:50:48 2009 From: mathews.kyle at gmail.com (Kyle Mathews) Date: Thu, 12 Feb 2009 07:50:48 -0700 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> Message-ID: This is the conversation Catch was referring to: http://groups.drupal.org/node/16732 Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Thu, Feb 12, 2009 at 6:45 AM, Dan Smith wrote: > 2009/2/12 Nathaniel Catchpole : > > In the redesign discussions, we'd discussed having nodereferences between > > case studies, site recipes and projects for this purpose rather than > tags. > > That way, people documenting how particular types of sites are built > could > > show which modules they used - as opposed to project owners saying 'I > think > > this might be useful for'. > > That sounds really useful! > > Dan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/ddad920c/attachment.htm From hovercrafter at earthlink.net Thu Feb 12 15:02:21 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Thu, 12 Feb 2009 10:02:21 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <49942B78.9010406@istos.it> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> <20090212082431.e7gczzcr1hlsgc4s@mail.progw.org> <49942B78.9010406@istos.it> Message-ID: <499439FD.2010606@earthlink.net> I was actually thinking about this a few weeks ago, but don't know how feasible it would be (it probably wouldn't be that bad), but what if we had a multi-option download page? Basically you have the option of just downloading Drupal, but also have a few prepackaged options. So if I am looking at Drupal and want to blog I would select the "blogger package", then I would get an installation profile installing the blog module, plus maybe views with monthly archives, pathauto (and token), and possible a WYSIWYG editor. It could be something like "your flavor" of Drupal - similar to the custom downloads on jQuery UI. The hardest part I would see is keeping these single download packages up to date with releases of the modules they incorporate, but a work around on that shouldn't be too bad. It would also let the user, who doesn't really know what Drupal is, see that Drupal is actually all these things, and we even made it super easy for them to get going on whichever path they want. I think it would go good in the redesign, plus it would also go hand in hand with the content type creation based upon installation method (ie: installing would be simple like Ronald points out, yet content type is created based upon the "package" they download.) Jamie Holly http://www.intoxination.net Skype:intoxination Phone: 1-513-252-2919 Ronald Ashri wrote: > Earnie Boyd wrote: > > > > How about making the default content types a configurable item for the > > install profile? > > > > I think the default install should be zero-configuration to start with > (beyond obvious DB name, user, etc). A lot of people are going to give > Drupal about 4-5 minutes initally. They will download, unzip, visit > install page on browser and fire away. They will assume that any issues > will be dealt with and they don't want to learn anything about Drupal > before Drupal is actually running on their system because that is the > first hurdle. If I can't install it why should I even learn about it. > > If you ask them "do you want to create content types Page and Story" - > already they have to learn something, as in "what are content types then?". > > Other profiles already assume some familiarity with Drupal and some > purpose in what you are trying to achieve so they can happily ask all > sorts of questiosn. > > Best, > > Ronald > > From gabor at hojtsy.hu Thu Feb 12 15:11:03 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Thu, 12 Feb 2009 16:11:03 +0100 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> Message-ID: <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> Then instead of referencing the nodes from the case studies attaching taxonomy terms to the references, we can tag the case studies themselves, and just have taxonomy lists of case studies on those links, can't we? I mean if you'd use this data from actual case studies, then why not show the modules in context, where the usage is actually described? Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well. G?bor On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole wrote: > In the redesign discussions, we'd discussed having nodereferences between > case studies, site recipes and projects for this purpose rather than tags. > That way, people documenting how particular types of sites are built could > show which modules they used - as opposed to project owners saying 'I think > this might be useful for'. You could then show showcases and site recipes > next to modules, and modules next to showcases and site recipes in a > structured way (and with some data munging, get aggregate data if needed). > Was this discussed as an option? > > Nat > > From Greg at GrowingVentureSolutions.com Thu Feb 12 15:25:17 2009 From: Greg at GrowingVentureSolutions.com (Greg Knaddison) Date: Thu, 12 Feb 2009 08:25:17 -0700 Subject: [development] New project vocabularies In-Reply-To: <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> Message-ID: <3861c6770902120725r19b9bf70q83942c387b3bc5ca@mail.gmail.com> On Thu, Feb 12, 2009 at 8:11 AM, G?bor Hojtsy wrote: > Note: IMHO we can remove the types of sites vocabulary always, if we > find it is not working well. I agree. Sure, some modules are useful on all sites and will select that, but some modules really are applicable to only a few kinds of sites. The tag issues will cause some additional maintenance problems but we have tools for dealing with it. Let's try this out long enough to see how it works with a faceted search interface. Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com From victorkane at gmail.com Thu Feb 12 15:48:36 2009 From: victorkane at gmail.com (Victor Kane) Date: Thu, 12 Feb 2009 13:48:36 -0200 Subject: [development] New project vocabularies In-Reply-To: <3861c6770902120725r19b9bf70q83942c387b3bc5ca@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <3861c6770902120725r19b9bf70q83942c387b3bc5ca@mail.gmail.com> Message-ID: Remember folks, these are usability experts focusing on people coming to drupal.org. That means, the main concern in our minds is, given a pressing need, how can I obtain a list of modules that might be just what I'm looking for! Cool! So if we stop analyzing it from the module author's point of view (another chore to do in creating/updating a project, having to pick out tags) and start analyzing it from the "how can I do what I need to do with contributed modules real quick" point of view, the tags start making sense as a basis for building that kind of functionality. Victor Kane http://awebfactory.com.ar On Thu, Feb 12, 2009 at 1:25 PM, Greg Knaddison < Greg at growingventuresolutions.com> wrote: > On Thu, Feb 12, 2009 at 8:11 AM, G?bor Hojtsy wrote: > > Note: IMHO we can remove the types of sites vocabulary always, if we > > find it is not working well. > > I agree. Sure, some modules are useful on all sites and will select > that, but some modules really are applicable to only a few kinds of > sites. The tag issues will cause some additional maintenance problems > but we have tools for dealing with it. Let's try this out long enough > to see how it works with a faceted search interface. > > Greg > > -- > Greg Knaddison > http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/8123caf8/attachment.htm From catch56 at googlemail.com Thu Feb 12 16:14:14 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 12 Feb 2009 16:14:14 +0000 Subject: [development] New project vocabularies In-Reply-To: <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> Message-ID: Tagging case studies - yes that makes sense - so then the hard node reference to the actual project (as opposed to a mention) means you could have a view of case studies showing all the modules used with direct links, browsable by tag. So in the right sidebar of the download and extend page, you still have a list like: Media Government Technology Upon clicking media, you'd see: - Warner Bros. | Views, CCK, Embedded Media Field | some other tags | date posted (or whatever) Some Record label | Audio, Panels Photo gallery site building howto | imagefield, imagecache, lightbox etc. etc. The advantage there is you get lists of modules which are actually used / documented, rather than lists of modules who's authors could be bothered to tag them. And yeah there's definitely no harm in having the vocabulary and trying it out for a while, I was just very fond of the showcase idea and didn't want it to get lost ;) Nat On Thu, Feb 12, 2009 at 3:11 PM, G?bor Hojtsy wrote: > Then instead of referencing the nodes from the case studies attaching > taxonomy terms to the references, we can tag the case studies > themselves, and just have taxonomy lists of case studies on those > links, can't we? I mean if you'd use this data from actual case > studies, then why not show the modules in context, where the usage is > actually described? > > Note: IMHO we can remove the types of sites vocabulary always, if we > find it is not working well. > > G?bor > > On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole > wrote: > > In the redesign discussions, we'd discussed having nodereferences between > > case studies, site recipes and projects for this purpose rather than > tags. > > That way, people documenting how particular types of sites are built > could > > show which modules they used - as opposed to project owners saying 'I > think > > this might be useful for'. You could then show showcases and site recipes > > next to modules, and modules next to showcases and site recipes in a > > structured way (and with some data munging, get aggregate data if > needed). > > Was this discussed as an option? > > > > Nat > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/7f3d5686/attachment-0001.htm From drupal at rocktreesky.com Thu Feb 12 16:16:33 2009 From: drupal at rocktreesky.com (Addison Berry) Date: Thu, 12 Feb 2009 11:16:33 -0500 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <3861c6770902120725r19b9bf70q83942c387b3bc5ca@mail.gmail.com> Message-ID: On Feb 12, 2009, at 10:48 AM, Victor Kane wrote: > Remember folks, these are usability experts focusing on people > coming to drupal.org. > > That means, the main concern in our minds is, given a pressing need, > how can I obtain a list of modules that might be just what I'm > looking for! Cool! > > So if we stop analyzing it from the module author's point of view > (another chore to do in creating/updating a project, having to pick > out tags) and start analyzing it from the "how can I do what I need > to do with contributed modules real quick" point of view, the tags > start making sense as a basis for building that kind of functionality. My concern is simply what Kathleen articulated. That if 90% of modules pick every category, then usability is greatly reduced. It would be *much* more useful if all modules are assumed useful for all sites, except for ones that are specifically limited to a niche category. I'd rather get 5 results for E-learning for modules that only apply to that category rather than 4000 modules, 3995 of which apply to all sites plus 5 for E-learning. That said, I'm not opposed to just turning it on and seeing how it goes, but I know that all of my modules are applicable to all sites and there aren't many that I use when site building that aren't used everywhere as well. - Addi > > > Victor Kane > http://awebfactory.com.ar > > On Thu, Feb 12, 2009 at 1:25 PM, Greg Knaddison > wrote: > On Thu, Feb 12, 2009 at 8:11 AM, G?bor Hojtsy wrote: > > Note: IMHO we can remove the types of sites vocabulary always, if we > > find it is not working well. > > I agree. Sure, some modules are useful on all sites and will select > that, but some modules really are applicable to only a few kinds of > sites. The tag issues will cause some additional maintenance problems > but we have tools for dealing with it. Let's try this out long enough > to see how it works with a faceted search interface. > > Greg > > -- > Greg Knaddison > http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/c0d9d31d/attachment.htm From sdimass at gmail.com Thu Feb 12 16:31:33 2009 From: sdimass at gmail.com (Dmytro Solodovnyk) Date: Thu, 12 Feb 2009 18:31:33 +0200 Subject: [development] Re[]: In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <3861c6770902120725r19b9bf70q83942c387b3bc5ca@mail.gmail.com> Message-ID: <1339668827.20090212183133@gmail.com> An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/fa0f0620/attachment.htm From kieran at acquia.com Thu Feb 12 16:35:06 2009 From: kieran at acquia.com (Kieran Lal) Date: Thu, 12 Feb 2009 08:35:06 -0800 Subject: [development] Re[]: In-Reply-To: <1339668827.20090212183133@gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <3861c6770902120725r19b9bf70q83942c387b3bc5ca@mail.gmail.com> <1339668827.20090212183133@gmail.com> Message-ID: http://lists.drupal.org/listinfo/development Kieran On Thu, Feb 12, 2009 at 8:31 AM, Dmytro Solodovnyk wrote: > Sorry, people, how can I unsubscribe from this mailing list? From bill at funnymonkey.com Thu Feb 12 17:11:11 2009 From: bill at funnymonkey.com (Bill Fitzgerald) Date: Thu, 12 Feb 2009 09:11:11 -0800 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> Message-ID: <4994582F.4060305@funnymonkey.com> Case studies referencing projects via a nodereference provides a nice way of contextualizing how a module is used. While improved tagging (and active maintenance of the tagging structure) would also be helpful, seeing links to case studies that incorporate a particular module from the project page would be very useful. Of course, this list would be very long on project pages for views and cck, but that can be managed. An aside here: the mention of e-learning as a category points at both a shortcoming of the tagging system, and (IMO) a misunderstanding of e-learning. Many modules on d.o have applications within online learning, even if it's not immediately obvious -- and the purpose of the categorization system should be to extend what is immediately obvious. While modules like quiz and gradebook have a specific elearning component, they are the exception. Pathauto and token are pretty critical for online learning sites, for exactly the same reason they are useful outside of a learning context. Cheers, Bill Nathaniel Catchpole wrote: > Tagging case studies - yes that makes sense - so then the hard node > reference to the actual project (as opposed to a mention) means you could > have a view of case studies showing all the modules used with direct links, > browsable by tag. > > So in the right sidebar of the download and extend page, you still have a > list like: > > Media > Government > Technology > > Upon clicking media, you'd see: > - > Warner Bros. | Views, CCK, Embedded Media Field | some other tags | date > posted (or whatever) > Some Record label | Audio, Panels > Photo gallery site building howto | imagefield, imagecache, lightbox > > etc. etc. > > The advantage there is you get lists of modules which are actually used / > documented, rather than lists of modules who's authors could be bothered to > tag them. > > And yeah there's definitely no harm in having the vocabulary and trying it > out for a while, I was just very fond of the showcase idea and didn't want > it to get lost ;) > > Nat > > > > On Thu, Feb 12, 2009 at 3:11 PM, G?bor Hojtsy wrote: > > >> Then instead of referencing the nodes from the case studies attaching >> taxonomy terms to the references, we can tag the case studies >> themselves, and just have taxonomy lists of case studies on those >> links, can't we? I mean if you'd use this data from actual case >> studies, then why not show the modules in context, where the usage is >> actually described? >> >> Note: IMHO we can remove the types of sites vocabulary always, if we >> find it is not working well. >> >> G?bor >> >> On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole >> wrote: >> >>> In the redesign discussions, we'd discussed having nodereferences between >>> case studies, site recipes and projects for this purpose rather than >>> >> tags. >> >>> That way, people documenting how particular types of sites are built >>> >> could >> >>> show which modules they used - as opposed to project owners saying 'I >>> >> think >> >>> this might be useful for'. You could then show showcases and site recipes >>> next to modules, and modules next to showcases and site recipes in a >>> structured way (and with some data munging, get aggregate data if >>> >> needed). >> >>> Was this discussed as an option? >>> >>> Nat >>> >>> >>> > > -- Bill Fitzgerald http://funnymonkey.com FunnyMonkey -- Click. Connect. Learn. ph. 503 897 7160 From cxjohnson at gmail.com Thu Feb 12 17:14:32 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Thu, 12 Feb 2009 11:14:32 -0600 Subject: [development] Body and teaser as fields In-Reply-To: <49942B78.9010406@istos.it> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <6117a7500902102120x5123277fy4987966dbc0ea035@mail.gmail.com> <49926502.3080607@istos.it> <1234358274.12234.32.camel@marcus.gateway.2wire.net> <499307F4.1000403@istos.it> <20090212082431.e7gczzcr1hlsgc4s@mail.progw.org> <49942B78.9010406@istos.it> Message-ID: <9ea8d6030902120914j3306f727ncca7bc9ed97372c5@mail.gmail.com> Here's my suggestions: (a) The install package should include a small number of highly useful, pre-configured content types that *can* be installed/enabled. (b) The user at install time is given, say, three choices: 1. Install the basic CMS version of Drupal. This will install the core Drupal framework, plus 2 or 3 content types as appropriate, e.g. story, blog and event. 2. Install the basic blogging platform version of Drupal. This will install the core Drupal framekwork, plus 2 or 3 content types as appropriate, e.g. blog and user profile node. 3. Customize your Drupal install -- for experts. This will provide a list of all content types included in the basic Drupal download package with checkboxes which can be ticked off. Those types should be something like: story, page, blog, event, profile. This sort of install arrangement should address most of the issues brought up here. Of course, additional contrib modules can be added later -- perhaps even suggested during install, or at least referenced with a "for more functionality, see the large repository of contrib modules." ..chris On Thu, Feb 12, 2009 at 8:00 AM, Ronald Ashri wrote: > > > Earnie Boyd wrote: >> >> How about making the default content types a configurable item for the >> install profile? >> > > I think the default install should be zero-configuration to start with > (beyond obvious DB name, user, etc). A lot of people are going to give > Drupal about 4-5 minutes initally. They will download, unzip, visit install > page on browser and fire away. They will assume that any issues will be > dealt with and they don't want to learn anything about Drupal before Drupal > is actually running on their system because that is the first hurdle. If I > can't install it why should I even learn about it. > > If you ask them "do you want to create content types Page and Story" - > already they have to learn something, as in "what are content types then?". > > Other profiles already assume some familiarity with Drupal and some purpose > in what you are trying to achieve so they can happily ask all sorts of > questiosn. > > Best, > > Ronald > From darrel.opry at gmail.com Thu Feb 12 20:32:47 2009 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Thu, 12 Feb 2009 15:32:47 -0500 Subject: [development] Body and teaser as fields In-Reply-To: <5b489e7b0902110513p3d8ae525ya53cd260744bb166@mail.gmail.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <5b489e7b0902110513p3d8ae525ya53cd260744bb166@mail.gmail.com> Message-ID: Maybe teaser is just a formatter for body? On Wed, Feb 11, 2009 at 8:13 AM, Karen Stevenson wrote: > +1 on getting rid of the teaser splitter -- I've been using css to hide it > :) The teaser splitter could become a contrib field module, if anyone wants > to save it. > > On auto-creating both a body and a teaser field -- is there a way to skip > creating a second field for all the sites where the teaser is just a subset > of the body? We really only need two fields if they have different content. > I suppose it's a lot simpler to just automatically create it in all cases, > so maybe simplicity wins out. > > The only other question I have is what happens when there is no official > 'body' field that other modules might expect to find. I guess we've already > made the body optional so they should not be expecting that anyway. Is there > any reason why losing a field that has had special meaning could be a > problem to contrib modules? > > Karen > > > On Tue, Feb 10, 2009 at 10:20 PM, Barry Jaspan wrote: > >> Now that Field API is in core it is time to start using it. I have an >> initial suggestion: change node body and teaser from special cases to normal >> fields. I suspect this is going to be quite controversial so I thought I'd >> get some feedback here before evening bothering to start looking at the >> code. >> >> This message is not about the details of the implementation; I'm sure >> there will be subtleties and complexities to work. I'm just asking about >> the concept. >> >> Concept: >> >> Remove all special processing for $node->body and $node->teaser. Create >> two fields, body and teaser, both text fields. Assign both fields to every >> existing content type with a "body field" using the textarea widget. For >> existing nodes, as part of the upgrade path, initialize the teaser field >> value with whatever teaser would normally be generated automatically from >> the body. >> >> Random thoughts: >> >> - We will get to remove a bunch of code, much of it quite ugly, from >> node.module. >> >> - Sites that really want an auto-generated teaser can remove the teaser >> field from a content type and use the text field's teaser Display Formatter >> in the teaser context. >> >> - This will mean removing the body field from the node and node_revision >> tables, and creating a field_data_body table for it instead. Don't worry >> about database query efficiency; that is a solved problem (see >> http://drupal.org/node/368674). >> >> - With $node->body and $node->teaser being normal fields, they will not be >> available for overloaded use as the complete rendered output of the node. >> Hurray! We can use $node->content = drupal_render($node) or something like >> that. >> >> - We might want to think about adding other fields to our default content >> types. Perhaps Article should have a Subtitle field, etc. This is a whole >> topic in itself. >> >> Comments? >> >> Thanks, >> >> Barry >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090212/f5f26a4e/attachment-0001.htm From gabor at hojtsy.hu Thu Feb 12 22:28:15 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Thu, 12 Feb 2009 23:28:15 +0100 Subject: [development] New project vocabularies In-Reply-To: <4994582F.4060305@funnymonkey.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <4994582F.4060305@funnymonkey.com> Message-ID: <86ca3ccb0902121428h13e0b8d7l8d7690a3120b2726@mail.gmail.com> On Thu, Feb 12, 2009 at 6:11 PM, Bill Fitzgerald wrote: > An aside here: the mention of e-learning as a category points at both a > shortcoming of the tagging system, and (IMO) a misunderstanding of > e-learning. Many modules on d.o have applications within online learning, > even if it's not immediately obvious -- and the purpose of the > categorization system should be to extend what is immediately obvious. While > modules like quiz and gradebook have a specific elearning component, they > are the exception. Pathauto and token are pretty critical for online > learning sites, for exactly the same reason they are useful outside of a > learning context. How would ecommerce be different for example? Pathauto and token would equally apply. Or blogs. There are definitely modules applying for all site types for sure. Drupal by nature has more of these modules then specific ones IMHO. G?bor From drupal.beginner at wechange.org Fri Feb 13 05:08:25 2009 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Fri, 13 Feb 2009 13:08:25 +0800 Subject: [development] Is "SELECT * FROM ..." ok? Message-ID: <200902131308.25603.drupal.beginner@wechange.org> Hello, A while ago, someone (not me!) brought down our collocation server with a home made script which had many queries like this: SELECT * FROM ... I.e. the script was indiscriminately selecting everything from the table even though he might have needed only a few fields. This created heavy traffic between the SQL server and the web server which overwhelmed the platform. To be honest, I don't know the details (he might have been needlessly transferring whole images stored in the DB or something like this!) In Drupal 6.9, I count 120 occurrences of SELECT * FROM ... , not including SELECT COUNT(*) but including variations of SELECT n.*, pi.* FROM ... . Wouldn't it be a good idea to explicitly tell which fields are needed, in order to minimize traffic between SQL server and web server? The SQL coding standards say nothing about this: http://drupal.org/node/2497 Should SELECT * FROM be considered a kind of bug? Should this whole discussion be a 'won't fix' ? (why?) Or is this something worth considering in the issue queue? Blessings, Augustin. From gordon at heydon.com.au Fri Feb 13 05:21:59 2009 From: gordon at heydon.com.au (Gordon Heydon) Date: Fri, 13 Feb 2009 16:21:59 +1100 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <200902131308.25603.drupal.beginner@wechange.org> References: <200902131308.25603.drupal.beginner@wechange.org> Message-ID: <92FAA694-93E3-4CEC-9D4F-6A5397AA5A98@heydon.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, No actually in e-Commerce I have set standards where we do this where ever we can. this means that with very little code an external module can extend a table. Give that we use drupal_write_record() to write all records someone can use the hook_schema_alter() and the hook_form_alter() to add columns to a table. Take the ec_product table, we do a SELECT * from {ec_product} WHERE vid = %d. Then using the hook_form_alter() to add additional fields to the form to capture data. Other than validating that the field is correct when e-Commerce calls drupal_write_record() then entire node is past, which means no additional processing needs to be done, and the new custom fields will get saved as required. But you can have problems like what you describe is there number of columns is a large number. So if you are joining 20 odd tables with a SELECT * to return all fields can cause problems. It is really up to the developer to make sure they implement it correctly. Gordon. On 13/02/2009, at 4:08 PM, augustin (beginner) wrote: > Hello, > > > A while ago, someone (not me!) brought down our collocation server > with a home > made script which had many queries like this: > > SELECT * FROM ... > > I.e. the script was indiscriminately selecting everything from the > table even > though he might have needed only a few fields. > This created heavy traffic between the SQL server and the web server > which > overwhelmed the platform. To be honest, I don't know the details (he > might > have been needlessly transferring whole images stored in the DB or > something > like this!) > > > In Drupal 6.9, I count 120 occurrences of SELECT * FROM ... , not > including > SELECT COUNT(*) but including variations of SELECT n.*, pi.* > FROM ... . > > Wouldn't it be a good idea to explicitly tell which fields are > needed, in > order to minimize traffic between SQL server and web server? > > The SQL coding standards say nothing about this: > http://drupal.org/node/2497 > > Should SELECT * FROM be considered a kind of bug? > Should this whole discussion be a 'won't fix' ? (why?) > Or is this something worth considering in the issue queue? > > > > Blessings, > > > Augustin. > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmVA3cACgkQngavurZvkryJJwCgip4b17BquRwlmoLUeMX3ZrKK yGkAmQGe4YusD6sU9umm0E1AEJvdgu5M =RKUH -----END PGP SIGNATURE----- From nevets at tds.net Fri Feb 13 05:25:14 2009 From: nevets at tds.net (Steve Ringwood) Date: Thu, 12 Feb 2009 23:25:14 -0600 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <200902131308.25603.drupal.beginner@wechange.org> References: <200902131308.25603.drupal.beginner@wechange.org> Message-ID: <4995043A.4010307@mailbag.com> I would say "SELECT * FROM ..." is not a bug. While it wise to consider selecting only a set of fields if that is all that is needed, there are times when one wants all the fields in the table. This is particularly true when building an object/array from data in the database where on row represents all or part of the object/array. A good example are node objects where as developers we expect it to completely represent the node. Nevets From larry at garfieldtech.com Fri Feb 13 06:55:23 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 13 Feb 2009 00:55:23 -0600 Subject: [development] Body and teaser as fields In-Reply-To: References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <5b489e7b0902110513p3d8ae525ya53cd260744bb166@mail.gmail.com> Message-ID: <200902130055.23533.larry@garfieldtech.com> Yes. I suggested that earlier in this thread. Good to know we're still reaching the same conclusions. ;-) (Arguably then we may need caching for formatter results, but I hardly see that as a bad thing to have anyway.) On Thursday 12 February 2009 2:32:47 pm Darrel O'Pry wrote: > Maybe teaser is just a formatter for body? > > On Wed, Feb 11, 2009 at 8:13 AM, Karen Stevenson wrote: > > +1 on getting rid of the teaser splitter -- I've been using css to hide > > it -- Larry Garfield larry at garfieldtech.com From larry at garfieldtech.com Fri Feb 13 07:01:55 2009 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 13 Feb 2009 01:01:55 -0600 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <200902131308.25603.drupal.beginner@wechange.org> References: <200902131308.25603.drupal.beginner@wechange.org> Message-ID: <200902130101.56036.larry@garfieldtech.com> SELECT * is slower than listing out fields explicitly, because the database then needs to take the time to expand * out into the available fields before compiling the query. However, it's not so much slower that its use would kill the DB server unless you have a table with hundreds of fields that you're not using (or lots and lots of very large BLOB or LOB fields), in which case you have a bad database design to start with. So I don't believe that SELECT * would be solely responsible for melting your server. That said, for both that performance reason and for maintainability/readability of the code I generally discourage SELECT *, and try to avoid it myself. The D7 database layer allows it in static queries (which are almost entirely un-interpolated) and has a mechanism for supporting them in dynamic queries (fields('tablename') with no second parameter), but I still avoid it myself and encourage others to do so as well. So no, not a bug, but I do agree with discouraging it in most cases. The only time you'd want it is if you have a table where you expect the columns to be dynamic, which has all sorts of other maintenance issues anyway. On Thursday 12 February 2009 11:08:25 pm augustin (beginner) wrote: > Hello, > > > A while ago, someone (not me!) brought down our collocation server with a > home made script which had many queries like this: > > SELECT * FROM ... > > I.e. the script was indiscriminately selecting everything from the table > even though he might have needed only a few fields. > This created heavy traffic between the SQL server and the web server which > overwhelmed the platform. To be honest, I don't know the details (he might > have been needlessly transferring whole images stored in the DB or > something like this!) > > > In Drupal 6.9, I count 120 occurrences of SELECT * FROM ... , not including > SELECT COUNT(*) but including variations of SELECT n.*, pi.* FROM ... . > > Wouldn't it be a good idea to explicitly tell which fields are needed, in > order to minimize traffic between SQL server and web server? > > The SQL coding standards say nothing about this: > http://drupal.org/node/2497 > > Should SELECT * FROM be considered a kind of bug? > Should this whole discussion be a 'won't fix' ? (why?) > Or is this something worth considering in the issue queue? > > > > Blessings, > > > Augustin. -- Larry Garfield larry at garfieldtech.com From drupal at dwwright.net Fri Feb 13 08:28:19 2009 From: drupal at dwwright.net (Derek Wright) Date: Fri, 13 Feb 2009 00:28:19 -0800 Subject: [development] New project vocabularies In-Reply-To: <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> Message-ID: <866C425A-686B-48C9-9DCC-5AC61EE3B705@dwwright.net> On Feb 12, 2009, at 7:11 AM, G?bor Hojtsy wrote: > Note: IMHO we can remove the types of sites vocabulary always, if we > find it is not working well. Can we at least make it not a required field in the short term? I just tried to edit one of my project pages (signup[1]), didn't see any "Types of sites" terms that really seemed appropriate ("collaboration", "community"?), and now I have to come up with some half-baked term association to be able to edit anything about this project. Furthermore, what am we supposed to do for modules like CVS deploy[2] and/or Update status[3] that have nothing to do with the "type of site"? Should we add an "" option? Or, are these other good use- cases for making it not required and not having any terms selected? If I select all a) it's noise in each category, b) I'll have to keep remembering to select all as new terms are added, c) the project page (assuming it will list all the site type terms) will get ugly and busy. Thanks, -Derek (dww) p.s. For the record, I'm vastly more in favor of the case study + node reference approach catch is advocating. ;) [1] http://drupal.org/project/signup [2] http://drupal.org/project/cvs_deploy [3] http://drupal.org/project/update_status From dries.buytaert at gmail.com Fri Feb 13 10:03:15 2009 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri, 13 Feb 2009 11:03:15 +0100 Subject: [development] Drupal Trademark Policy Draft Message-ID: <61bca48a0902130203i1ee0040cg5e02a3895ef59230@mail.gmail.com> Hello all, See http://groups.drupal.org/node/19068 if you're interested in Drupal's upcoming trademark policy. Please refrain from replying to this e-mail. Let's centralize all the feedback in the comments of http://groups.drupal.org/node/19068. Thanks! -- Dries Buytaert :: http://buytaert.net/ From mail at webthatworks.it Fri Feb 13 10:30:25 2009 From: mail at webthatworks.it (Ivan Sergio Borgonovo) Date: Fri, 13 Feb 2009 11:30:25 +0100 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <200902130101.56036.larry@garfieldtech.com> References: <200902131308.25603.drupal.beginner@wechange.org> <200902130101.56036.larry@garfieldtech.com> Message-ID: <20090213113025.5f7fe621@dawn.webthatworks.it> On Fri, 13 Feb 2009 01:01:55 -0600 Larry Garfield wrote: > So no, not a bug, but I do agree with discouraging it in most > cases. The only time you'd want it is if you have a table where > you expect the columns to be dynamic, which has all sorts of other > maintenance issues anyway. +1 It's always a risky bargain between extensibility, maintenance, performance and clean design. Tables should be as small as possible. It helps to keep a clear hierarchy of data and helps performances because it exploit more locality of the data. *Somehow* good design tend to produce queries that return most of the columns. When you extend tables defined upstream it means you don't trust upstream design decisions (and it will bite you) or you're very very tight with resources and you've been bitten by performance problems. Ideally I don't want to know why Drupal core decided to put those columns in users. I'd expect they made a general choice that help extend the user object and keep the base user object as thin as possible. I don't want to mess with their decisions, their API, their responsibility of the cost of building up a base user object, upgrading it to newer Drupal versions... *Dynamically* extended tables makes the cost of a service unpredictable. Service x add column A, B, C. Service y add column D, E, F. ... wooohp. Explicitly naming columns make refactoring apparently more boring but definitively more under control. It promotes better coding making people more aware of what they're doing. It makes easier to deploy tests and it makes easier to find places where you've to refactor. As with set/get methods in OOP it makes easier to hide where data are actually coming from. It gives an order to columns making select easier to reuse correctly. Not only it helps to spot errors, but it spots them earlier. The first time you'll have to refactor 100 places where you had to add a column (say you moved from name -> name + surname) it will give you a clue there is something that doesn't work with your design... but at least it will tell you all the 100 places you've to refactor. Every time you write a SELECT * it is a missed chance to use grep as a debugging tool. This alone is worth getting rid of all the SELECT * and even n.* And if it is not for debugging purposes it helps to understand the code (especially for contrib). Where does this stuff come from/is used...? let's grep it. -- Ivan Sergio Borgonovo http://www.webthatworks.it From drupal at rocktreesky.com Fri Feb 13 10:50:23 2009 From: drupal at rocktreesky.com (Addison Berry) Date: Fri, 13 Feb 2009 05:50:23 -0500 Subject: [development] New project vocabularies In-Reply-To: <866C425A-686B-48C9-9DCC-5AC61EE3B705@dwwright.net> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <866C425A-686B-48C9-9DCC-5AC61EE3B705@dwwright.net> Message-ID: <3CCD00B9-1A41-4CE1-96DF-5F005CCD8913@rocktreesky.com> On Feb 13, 2009, at 3:28 AM, Derek Wright wrote: > > On Feb 12, 2009, at 7:11 AM, G?bor Hojtsy wrote: > >> Note: IMHO we can remove the types of sites vocabulary always, if >> we find it is not working well. > > Can we at least make it not a required field in the short term? Please yes. I just tried to reset the format on a project back to filtered HTML for someone and got the angry read required category. It's not my module, but looks to me like one that can be used anywhere so I selected all. Not really my place to decide that though and I still hold that this won't be helpful forcing everyone to pick all of them. As Derek suggested, if it is required, please add an "any" option. - Addi From morbus at disobey.com Fri Feb 13 12:37:52 2009 From: morbus at disobey.com (Morbus Iff) Date: Fri, 13 Feb 2009 07:37:52 -0500 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <200902131308.25603.drupal.beginner@wechange.org> References: <200902131308.25603.drupal.beginner@wechange.org> Message-ID: <499569A0.10305@disobey.com> > Should SELECT * FROM be considered a kind of bug? I personally consider it a bug, but I still haven't yet trained my fingers to do it the proper way. I subscribe to the logic from: http://www.parseerror.com/sql/select*isevil.html -- Morbus Iff ( i'm the droid you're looking for ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From kika at trip.ee Fri Feb 13 13:59:37 2009 From: kika at trip.ee (Kristjan Jansen) Date: Fri, 13 Feb 2009 13:59:37 +0000 Subject: [development] Body and teaser as fields In-Reply-To: <200902130055.23533.larry@garfieldtech.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <5b489e7b0902110513p3d8ae525ya53cd260744bb166@mail.gmail.com> <200902130055.23533.larry@garfieldtech.com> Message-ID: <37a603d00902130559xe28b9fblc237bd4668cec1df@mail.gmail.com> Perhaps I missed totally the FiC features but why can not $node->title be generic textfield as well? k From jcfiala at gmail.com Fri Feb 13 14:50:15 2009 From: jcfiala at gmail.com (John Fiala) Date: Fri, 13 Feb 2009 07:50:15 -0700 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <499569A0.10305@disobey.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> Message-ID: I think it's a bug to do it automatically - I think it's a good default to list the fields you need. But, if you have a reason to use SELECT * FROM... then definitely use it. -- John Fiala From metzlerd at metzlerd.com Fri Feb 13 15:03:20 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Fri, 13 Feb 2009 07:03:20 -0800 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <499569A0.10305@disobey.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> Message-ID: <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> Although there are merits in this argument, I wouldn't classify it as a bug. There's a lot of generic/abstracted data loading, and as long as there's code at there that dynamically adds columns, select * actually is the sanest way to do things. Also, the performance costs are database dependent. Mysql may work one way, but other db's work another. Any DB with precompiled cached queries is not going to carry significant parsing overhead. The amount of data transfered in most cases is dependent on the size of the data in the column and not the number of columns. So in some tables it may make sense. You might get the name of the image file in drupal, but you're not likely to get the image. Finally in my experience, most database performance problems lie in what is in the WHERE or JOIN, and not what's in the column list. Dave On Feb 13, 2009, at 4:37 AM, Morbus Iff wrote: >> Should SELECT * FROM be considered a kind of bug? > > I personally consider it a bug, but I still haven't yet trained my > fingers to do it the proper way. I subscribe to the logic from: > > http://www.parseerror.com/sql/select*isevil.html > > -- > Morbus Iff ( i'm the droid you're looking for ) > Technical: http://www.oreillynet.com/pub/au/779 > Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ > aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From morbus at disobey.com Fri Feb 13 15:15:56 2009 From: morbus at disobey.com (Morbus Iff) Date: Fri, 13 Feb 2009 10:15:56 -0500 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> Message-ID: <49958EAC.3020608@disobey.com> I give *little* regard for performance (in this case), and everything for my *expectations* and *documentation*. I could care less if it's faster or not. I care more about clarity. David Metzler wrote: > Although there are merits in this argument, I wouldn't classify it as > a bug. There's a lot of generic/abstracted data loading, and as long > as there's code at there that dynamically adds columns, select * > actually is the sanest way to do things. > > Also, the performance costs are database dependent. Mysql may work > one way, but other db's work another. Any DB with precompiled > cached queries is not going to carry significant parsing overhead. > The amount of data transfered in most cases is dependent on the size > of the data in the column and not the number of columns. So in some > tables it may make sense. You might get the name of the image file > in drupal, but you're not likely to get the image. > > Finally in my experience, most database performance problems lie in > what is in the WHERE or JOIN, and not what's in the column list. -- Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From karen at elderweb.com Fri Feb 13 15:50:55 2009 From: karen at elderweb.com (Karen Stevenson) Date: Fri, 13 Feb 2009 09:50:55 -0600 Subject: [development] Body and teaser as fields In-Reply-To: <37a603d00902130559xe28b9fblc237bd4668cec1df@mail.gmail.com> References: <7.0.1.0.2.20090210230217.069796c0@jaspan.org> <5b489e7b0902110513p3d8ae525ya53cd260744bb166@mail.gmail.com> <200902130055.23533.larry@garfieldtech.com> <37a603d00902130559xe28b9fblc237bd4668cec1df@mail.gmail.com> Message-ID: <5b489e7b0902130750me87b497i18163e113d3429d9@mail.gmail.com> The title is used in all kinds of special ways, like as the default link to the node, so we were going to leave it alone for now. We could maybe make it a 'locked' field though (although we haven't really defined yet what 'locked' really means.) Anyway, someone would have to spend some time digging through the code to be sure to uncover all the implications of handling the title differently before making any change to that. Karen On Fri, Feb 13, 2009 at 7:59 AM, Kristjan Jansen wrote: > Perhaps I missed totally the FiC features but why can not $node->title > be generic textfield as well? > k > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090213/63854608/attachment.htm From drupal at dwwright.net Fri Feb 13 15:52:22 2009 From: drupal at dwwright.net (Derek Wright) Date: Fri, 13 Feb 2009 07:52:22 -0800 Subject: [development] New project vocabularies In-Reply-To: <3CCD00B9-1A41-4CE1-96DF-5F005CCD8913@rocktreesky.com> References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <866C425A-686B-48C9-9DCC-5AC61EE3B705@dwwright.net> <3CCD00B9-1A41-4CE1-96DF-5F005CCD8913@rocktreesky.com> Message-ID: On Feb 13, 2009, at 2:50 AM, Addison Berry wrote: >> Can we at least make it not a required field in the short term? > > Please yes. That's good enough for me. ;) No longer required. > As Derek suggested, if it is required, please add an "any" option. I added "- Any -" to the mix, too. Even if it's not required, that's probably a reasonable option to have. Cheers, -Derek (dww) From cxjohnson at gmail.com Fri Feb 13 18:16:44 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 13 Feb 2009 12:16:44 -0600 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <49958EAC.3020608@disobey.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> <49958EAC.3020608@disobey.com> Message-ID: <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> I'm with Morbus on the clarity argument. And I also argue for better performance. It's not just the extra time the server needs to find the column names, but all of the extra data being buffered and sent over the wire. On large sites with load-balanced web server front ends, and mirrored or slaved database servers on the backend, operations people are usually trying to squeeze out every inch of performance possible from the site/database combined performance. Even though it may add only a millisecond per operation, when there are millions of operations being done, it quickly adds up. I'm well aware of the arguments against premature optimization, but given the arguments which Morbus presented, there's very little reason to not avoid "SELECT * " except when absolutely needed. ..chris On Fri, Feb 13, 2009 at 9:15 AM, Morbus Iff wrote: > > I give *little* regard for performance (in this case), and everything for my > *expectations* and *documentation*. I could care less if it's faster or not. > I care more about clarity. > > David Metzler wrote: >> >> Although there are merits in this argument, I wouldn't classify it as a >> bug. There's a lot of generic/abstracted data loading, and as long as >> there's code at there that dynamically adds columns, select * actually is >> the sanest way to do things. >> >> Also, the performance costs are database dependent. Mysql may work one >> way, but other db's work another. Any DB with precompiled cached queries >> is not going to carry significant parsing overhead. The amount of data >> transfered in most cases is dependent on the size of the data in the column >> and not the number of columns. So in some tables it may make sense. You >> might get the name of the image file in drupal, but you're not likely to >> get the image. >> >> Finally in my experience, most database performance problems lie in what >> is in the WHERE or JOIN, and not what's in the column list. > > -- > Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) > Technical: http://www.oreillynet.com/pub/au/779 > Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ > aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus > From predofaria at gmail.com Fri Feb 13 21:38:02 2009 From: predofaria at gmail.com (Pedro Faria de Miranda Pinto) Date: Fri, 13 Feb 2009 19:38:02 -0200 Subject: [development] User Reference on Profile module Message-ID: Today i need a user reference on profile but cck solution dont attend me so a build a patch to do it with profile module. If some one have interesting on it i can port to drupal 6 too. http://drupal.org/node/374098 thanks From mike at mikeyp.net Fri Feb 13 22:16:40 2009 From: mike at mikeyp.net (Michael Prasuhn) Date: Fri, 13 Feb 2009 14:16:40 -0800 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> <49958EAC.3020608@disobey.com> <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> Message-ID: <51F40894-26E4-4EF7-9928-212FA065F963@mikeyp.net> I would really like to hear David Strauss's comments on this thread. David, if you are out there, care to chime in? -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net From morbus at disobey.com Fri Feb 13 23:03:04 2009 From: morbus at disobey.com (Morbus Iff) Date: Fri, 13 Feb 2009 18:03:04 -0500 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <51F40894-26E4-4EF7-9928-212FA065F963@mikeyp.net> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> <49958EAC.3020608@disobey.com> <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> <51F40894-26E4-4EF7-9928-212FA065F963@mikeyp.net> Message-ID: <4995FC28.2020409@disobey.com> > I would really like to hear David Strauss's comments on this thread. > David, if you are out there, care to chime in? There could be only one reason to chime his name, and that would be for his inner knowledge of MySQL and the effects this may have on perf. While I'm sure I'll learn something on a tangential curve, it'd have little effect on why /I/ consider them not OK. -- Morbus Iff ( cheese and rice saves ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From catch56 at googlemail.com Fri Feb 13 23:46:36 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Fri, 13 Feb 2009 23:46:36 +0000 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <4995FC28.2020409@disobey.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> <49958EAC.3020608@disobey.com> <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> <51F40894-26E4-4EF7-9928-212FA065F963@mikeyp.net> <4995FC28.2020409@disobey.com> Message-ID: One way of both specifying the columns, and accounting for dynamic schema, is http://api.drupal.org/api/function/drupal_schema_fields_sql - which you can then build your query from. I'd imagine the hit to the schema is going to cost more than the MySQL internals for SELECT *, but otherwise it lets you get the best of both worlds in terms of correctness. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090213/9e8d0e90/attachment.htm From metzlerd at metzlerd.com Sat Feb 14 03:23:03 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Fri, 13 Feb 2009 19:23:03 -0800 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <49958EAC.3020608@disobey.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> <49958EAC.3020608@disobey.com> Message-ID: <457806CD-94A8-4B32-BADA-0ABFA5595A02@metzlerd.com> I would definitely agree here. Selecting from watchdog definitely deserves to have the columns listed. Selecting from taxonomies and categories are the same. But there are places in CCK and views that select * might be considered more appropriate. As a developer I'd love to see such comments in a patch review or code review, but I wouldn't love to see a bunch of issues filed because someone grepped my code for select *. I was really pointing out the fallacy of the select * = poor performance argument, and that you might do as well to find out how many ROWS were returned by the select statement in question, plus start searching for outer joins ,etc. And don't event get me started on insert statements without column lists.. dave On Feb 13, 2009, at 7:15 AM, Morbus Iff wrote: > > I give *little* regard for performance (in this case), and > everything for my *expectations* and *documentation*. I could care > less if it's faster or not. I care more about clarity. > > David Metzler wrote: >> Although there are merits in this argument, I wouldn't classify it >> as a bug. There's a lot of generic/abstracted data loading, and >> as long as there's code at there that dynamically adds columns, >> select * actually is the sanest way to do things. >> Also, the performance costs are database dependent. Mysql may >> work one way, but other db's work another. Any DB with >> precompiled cached queries is not going to carry significant >> parsing overhead. The amount of data transfered in most cases is >> dependent on the size of the data in the column and not the >> number of columns. So in some tables it may make sense. You >> might get the name of the image file in drupal, but you're not >> likely to get the image. >> Finally in my experience, most database performance problems lie >> in what is in the WHERE or JOIN, and not what's in the column list. > > -- > Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) > Technical: http://www.oreillynet.com/pub/au/779 > Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ > aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus From andrewberry at sentex.net Sat Feb 14 03:36:22 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Fri, 13 Feb 2009 22:36:22 -0500 Subject: [development] New project vocabularies In-Reply-To: References: <61bca48a0902120340m344535bay200b23ef409248f5@mail.gmail.com> <78789e870902120452n6ed5c03fm60b7b50aa91fa680@mail.gmail.com> <4e983be00902120502t4396b5cercb8151da7f64f870@mail.gmail.com> <86ca3ccb0902120711r3c254ef9ic24deadd97639103@mail.gmail.com> <866C425A-686B-48C9-9DCC-5AC61EE3B705@dwwright.net> <3CCD00B9-1A41-4CE1-96DF-5F005CCD8913@rocktreesky.com> Message-ID: On 13-Feb-09, at 10:52 AM, Derek Wright wrote: > I added "- Any -" to the mix, too. Even if it's not required, > that's probably a reasonable option to have. I would suggest removing "None" now that "Any" is available. To me "None" means "this code isn't usable anywhere, avoid it!". I'm sure this was talked about in the redesign somewhere, but I think moving that field out into a user-vote kind of field would be much more useful. As a module maintainer, *I* have no idea what users are using my code on except in cases where they report a bug and mention the site. I think it's fair to assume that most maintainers know their own (often off-the-wall) use cases, but not too much beyond that. Imagine if when a logged in user downloaded a module upgrade (since we could track their previous downloads if they were logged in), an option appeared asking them to fill in where they use the module. They could optionally put in a URL, along with an industry / segment / something. Or, it could just appear all the time near the "module rating" section in the iteration 11 mockup. This could even help long term usability of modules since maintainers might actually get some basic data about the profiles of their users. It could be a real boon to know that "most of my users are in education, so use terms which they're familiar with and don't have conflicting definitions". --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090213/00f62623/attachment-0001.bin From agentrickard at gmail.com Sat Feb 14 19:18:04 2009 From: agentrickard at gmail.com (Ken Rickard) Date: Sat, 14 Feb 2009 14:18:04 -0500 Subject: [development] Is "SELECT * FROM ..." ok? In-Reply-To: <457806CD-94A8-4B32-BADA-0ABFA5595A02@metzlerd.com> References: <200902131308.25603.drupal.beginner@wechange.org> <499569A0.10305@disobey.com> <075A91FC-24DD-4BD2-8B9F-1907FC44FF0D@metzlerd.com> <49958EAC.3020608@disobey.com> <457806CD-94A8-4B32-BADA-0ABFA5595A02@metzlerd.com> Message-ID: <25b45da00902141118t52bf9e78kb28a892f079bb769@mail.gmail.com> One additional (bugworthy) note: Using SELECT * on a {node} query breaks db_rewrite_sql() in Drupal 5 and Drupal 6. [1] This opens a quasi-security hole where content may be shown to non-privileged users. This is due to the fact that node_db_rewrite_sql() adds 'distinct' == TRUE, and you cannot run DISTINCT(*) queries. So, in the case of node list queries, SELECT * is _definitely_ a bug. - Ken Rickard Palantir.net [1] -- http://drupal.org/node/324070 On Fri, Feb 13, 2009 at 10:23 PM, David Metzler wrote: > I would definitely agree here. Selecting from watchdog definitely deserves > to have the columns listed. Selecting from taxonomies and categories are > the same. But there are places in CCK and views that select * might be > considered more appropriate. As a developer I'd love to see such comments > in a patch review or code review, but I wouldn't love to see a bunch of > issues filed because someone grepped my code for select *. > > I was really pointing out the fallacy of the select * = poor performance > argument, and that you might do as well to find out how many ROWS were > returned by the select statement in question, plus start searching for outer > joins ,etc. > > And don't event get me started on insert statements without column lists.. > > dave > > > > On Feb 13, 2009, at 7:15 AM, Morbus Iff wrote: > >> >> I give *little* regard for performance (in this case), and everything for >> my *expectations* and *documentation*. I could care less if it's faster or >> not. I care more about clarity. >> >> David Metzler wrote: >>> >>> Although there are merits in this argument, I wouldn't classify it as a >>> bug. There's a lot of generic/abstracted data loading, and as long as >>> there's code at there that dynamically adds columns, select * actually is >>> the sanest way to do things. >>> Also, the performance costs are database dependent. Mysql may work one >>> way, but other db's work another. Any DB with precompiled cached queries >>> is not going to carry significant parsing overhead. The amount of data >>> transfered in most cases is dependent on the size of the data in the column >>> and not the number of columns. So in some tables it may make sense. You >>> might get the name of the image file in drupal, but you're not likely to >>> get the image. >>> Finally in my experience, most database performance problems lie in what >>> is in the WHERE or JOIN, and not what's in the column list. >> >> -- >> Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) >> Technical: http://www.oreillynet.com/pub/au/779 >> Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ >> aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus > > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From drupal.beginner at wechange.org Sun Feb 15 08:51:25 2009 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Sun, 15 Feb 2009 16:51:25 +0800 Subject: [development] SQL coding standards (Re: Is "SELECT * FROM ..." ok? In-Reply-To: <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> References: <200902131308.25603.drupal.beginner@wechange.org> <49958EAC.3020608@disobey.com> <9ea8d6030902131016u1d7e765dle2a3db005fc6eb6a@mail.gmail.com> Message-ID: <200902151651.26167.drupal.beginner@wechange.org> Thanks everybody for your comments. I'm glad I asked! It seems that there is a small consensus to at least discourage its use where it's not actually necessary. Given the response so far, there is ground for further discussion on this topic. Thus, I have created a new sub-page to the SQL coding standard here: http://drupal.org/node/374660 Obviously, it needs to be completed. Also, I have counted the number of occurrences of SELECT * or SELECT x.* in Drupal 7 (HEAD), and I found almost 150 of them! So, this is the issue to refine the SQL coding standard by discussing actual code examples found in Drupal core: http://drupal.org/node/374661 Blessings, Augustin. From paulhoza at gmail.com Sun Feb 15 14:33:01 2009 From: paulhoza at gmail.com (Paul Hoza) Date: Sun, 15 Feb 2009 07:33:01 -0700 Subject: [development] Programmatic data importing from JSON source Message-ID: <4998279D.901@gmail.com> Hello folks, I've been struggling for a long time (way too long) to get a data feed imported into CCK nodes. I've attempted a plethora of different strategies, including but not limited to: FeedAPI, Feed Element Mapper, custom parsers, hacking parsers, tweaking mappers, Yahoo! Pipes to create custom feed versions of the original feed, serialized PHP exports, etc. I'm tired of the project, but I have to find a way to get this to work. So, I found a few articles on programmatically creating CCK nodes and I'm hoping to connect with anyone who's had experience doing this with JSON data. There is an XML/RSS version of this feed I need, but it sucks compared to the JSON version, with respect to how much data is in there and how it's formatted. The XML version hides a lot of crucial info into a element... which I might be able to parse through separately, but RSS feed aggregators just ignore stuff in there. Again, I'd have to make a custom parser to get in there. Here's an article that hits about as close as I've seen yet. I am leaving for a couple days, so I'll try to get something like this working when I get back, but I hoped to hear from anyone who's done the same thing. Information on using JSON data to create nodes is sparse, but this article hits pretty close to the mark: https://secure.prolucid.com/node/43 I had read other posts about doing similar methods using drupal_execute(), et. al, but they all talk only about XML as data source. I haven't found anything talking about JSON or (un)serialized PHP sources. What I really need to do is do an initial import of the JSON feed into my CCK node (which is a huge feed of 6,200+ items). After that, I want to check the feed every day for changes and create new daily nodes accordingly -- which is why FeedAPI really seemed like the ticket, aside from my massive struggles with making my own parser. For now, I'd be happy with a PHP script that I could call daily with cron. Thanks for any feedback... sorry for the long post. Part rant, part plea. :) Cheers, Paul Hoza From kvantomme at gmail.com Sun Feb 15 16:00:49 2009 From: kvantomme at gmail.com (Kristof Van Tomme) Date: Sun, 15 Feb 2009 17:00:49 +0100 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <4998279D.901@gmail.com> References: <4998279D.901@gmail.com> Message-ID: Hi Paul, Check out http://drupal.org/project/extra_RSS_fields it's very alpha and it's Drupal 5, but it sounds like it's approximately what you would need. Feel free to contact me directly should have any questions about it. cheers, Kristof 2009/2/15 Paul Hoza : > Hello folks, > > I've been struggling for a long time (way too long) to get a data feed > imported into CCK nodes. I've attempted a plethora of different strategies, > including but not limited to: FeedAPI, Feed Element Mapper, custom parsers, > hacking parsers, tweaking mappers, Yahoo! Pipes to create custom feed > versions of the original feed, serialized PHP exports, etc. > > I'm tired of the project, but I have to find a way to get this to work. > > So, I found a few articles on programmatically creating CCK nodes and I'm > hoping to connect with anyone who's had experience doing this with JSON > data. There is an XML/RSS version of this feed I need, but it sucks > compared to the JSON version, with respect to how much data is in there and > how it's formatted. The XML version hides a lot of crucial info into a > element... which I might be able to parse through separately, but > RSS feed aggregators just ignore stuff in there. Again, I'd have to make a > custom parser to get in there. > > Here's an article that hits about as close as I've seen yet. I am leaving > for a couple days, so I'll try to get something like this working when I get > back, but I hoped to hear from anyone who's done the same thing. > Information on using JSON data to create nodes is sparse, but this article > hits pretty close to the mark: > https://secure.prolucid.com/node/43 > I had read other posts about doing similar methods using drupal_execute(), > et. al, but they all talk only about XML as data source. I haven't found > anything talking about JSON or (un)serialized PHP sources. > > What I really need to do is do an initial import of the JSON feed into my > CCK node (which is a huge feed of 6,200+ items). After that, I want to > check the feed every day for changes and create new daily nodes accordingly > -- which is why FeedAPI really seemed like the ticket, aside from my massive > struggles with making my own parser. For now, I'd be happy with a PHP > script that I could call daily with cron. > > > Thanks for any feedback... sorry for the long post. Part rant, part plea. > :) > > Cheers, > Paul Hoza > > From metzlerd at metzlerd.com Sun Feb 15 16:35:06 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Sun, 15 Feb 2009 08:35:06 -0800 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <4998279D.901@gmail.com> References: <4998279D.901@gmail.com> Message-ID: Hey Paul, I haven't done this with JSON, but have written some XML to nested array conversion stuff that might help, but might not. Could you shoot an example of the feed and what makes it so complicated so that we don't shower you with irrelavent solutions :). Is it that you're trying to parse data that's inside XML that makes it so nasty or something else? You give me the impression that the JSON feed contains more information than the other feed. Is that true? Dave On Feb 15, 2009, at 6:33 AM, Paul Hoza wrote: > Hello folks, > > I've been struggling for a long time (way too long) to get a data > feed imported into CCK nodes. I've attempted a plethora of > different strategies, including but not limited to: FeedAPI, Feed > Element Mapper, custom parsers, hacking parsers, tweaking mappers, > Yahoo! Pipes to create custom feed versions of the original feed, > serialized PHP exports, etc. > > I'm tired of the project, but I have to find a way to get this to > work. > > So, I found a few articles on programmatically creating CCK nodes > and I'm hoping to connect with anyone who's had experience doing > this with JSON data. There is an XML/RSS version of this feed I > need, but it sucks compared to the JSON version, with respect to > how much data is in there and how it's formatted. The XML version > hides a lot of crucial info into a element... which I > might be able to parse through separately, but RSS feed aggregators > just ignore stuff in there. Again, I'd have to make a custom > parser to get in there. > > Here's an article that hits about as close as I've seen yet. I am > leaving for a couple days, so I'll try to get something like this > working when I get back, but I hoped to hear from anyone who's done > the same thing. Information on using JSON data to create nodes is > sparse, but this article hits pretty close to the mark: > https://secure.prolucid.com/node/43 > I had read other posts about doing similar methods using > drupal_execute(), et. al, but they all talk only about XML as data > source. I haven't found anything talking about JSON or (un) > serialized PHP sources. > > What I really need to do is do an initial import of the JSON feed > into my CCK node (which is a huge feed of 6,200+ items). After > that, I want to check the feed every day for changes and create new > daily nodes accordingly -- which is why FeedAPI really seemed like > the ticket, aside from my massive struggles with making my own > parser. For now, I'd be happy with a PHP script that I could call > daily with cron. > > > Thanks for any feedback... sorry for the long post. Part rant, > part plea. :) > > Cheers, > Paul Hoza > From paulhoza at gmail.com Sun Feb 15 21:07:59 2009 From: paulhoza at gmail.com (Paul Hoza) Date: Sun, 15 Feb 2009 14:07:59 -0700 Subject: [development] Programmatic data importing from JSON source In-Reply-To: References: <4998279D.901@gmail.com> Message-ID: <4998842F.4040906@gmail.com> Hi David, Thanks for the reply. I need to run out of town for a quick road trip, but will be back tomorrow afternoon. I will reply more usefully as soon as I get back. I don't mean to add cruft to the list by a useless reply, but I'm just very happy that a couple people already replied. (Thanks to Kristof as well.) I'm not even supposed to be checking email since we're a bit late, but I couldn't resist. :) Thanks... more soon, Paul David Metzler wrote: > Hey Paul, > > I haven't done this with JSON, but have written some XML to nested > array conversion stuff that might help, but might not. Could you shoot > an example of the feed and what makes it so complicated so that we > don't shower you with irrelavent solutions :). Is it that you're > trying to parse data that's inside XML that makes it so nasty or > something else? > > You give me the impression that the JSON feed contains more > information than the other feed. Is that true? > > Dave > On Feb 15, 2009, at 6:33 AM, Paul Hoza wrote: > From cxjohnson at gmail.com Mon Feb 16 15:32:04 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 16 Feb 2009 09:32:04 -0600 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <4998842F.4040906@gmail.com> References: <4998279D.901@gmail.com> <4998842F.4040906@gmail.com> Message-ID: <9ea8d6030902160732l70d1eff2pcd198d7136d9be3d@mail.gmail.com> JSON is extremely easy to handle, in my experience. Much easier than XML. PHP 5.2+ has a json_decode() command which turns the whole string into nicely structured arrays, for instance. On Sun, Feb 15, 2009 at 3:07 PM, Paul Hoza wrote: > > Hi David, > Thanks for the reply. I need to run out of town for a quick road trip, but > will be back tomorrow afternoon. I will reply more usefully as soon as I > get back. > > I don't mean to add cruft to the list by a useless reply, but I'm just very > happy that a couple people already replied. (Thanks to Kristof as well.) > I'm not even supposed to be checking email since we're a bit late, but I > couldn't resist. :) > > Thanks... more soon, > Paul > > > David Metzler wrote: >> >> Hey Paul, >> >> I haven't done this with JSON, but have written some XML to nested array >> conversion stuff that might help, but might not. Could you shoot an example >> of the feed and what makes it so complicated so that we don't shower you >> with irrelavent solutions :). Is it that you're trying to parse data that's >> inside XML that makes it so nasty or something else? >> >> You give me the impression that the JSON feed contains more information >> than the other feed. Is that true? >> >> Dave >> On Feb 15, 2009, at 6:33 AM, Paul Hoza wrote: >> > > From nan_wich at bellsouth.net Tue Feb 17 01:21:48 2009 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 16 Feb 2009 20:21:48 -0500 Subject: [development] (no subject) Message-ID: Okay, I know that altering the structure of a core table is bad news. I do not want to do that. I have a module that keeps a copy of a file path in its own table. This is de-normalizing the db. What I want to do is to change my table to just carry the file ID and change the queries to JOINS. That?s no biggie. However, someone wants me to also be able to link to an external image. It would not be hard for me to put that URL into the files table and get it back with my normal query. Would this be a legitimate use of the files table? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090216/73ab46ec/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 0 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090216/73ab46ec/attachment.bin -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.24/1954 - Release Date: 2/15/2009 6:09 PM From dmitrig01 at gmail.com Tue Feb 17 01:23:50 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Mon, 16 Feb 2009 17:23:50 -0800 Subject: [development] Incremental filter for the permissions page Message-ID: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> Hello Development, I've been working on a patch that incrementally filters the permission page - patch at http://drupal.org/node/229193 and demo at http://dmitrizone.com/229193.mov . The patch is pretty much ready to be reviewed, except for the fact that webchick has an issue with how it degrades. Currently, without JavaScript, the textfield for searching simply isn't there, and you can't use the incremental filter. Webchick would like it to be degradable. The issue with this is that we already have a 100-line search algorithm for searching in HTML, and we'd need another 150 or so search algorithm to do it server side, which would actually be quite different. CHX has an argument against needing a degradable version at http://drupal.org/node/229193#comment-1260194 : "I think this is fine with working only if JavaScript is there. Drupal works without JavaScript but with reduced functionality already. You can not resize a textarea without JS for example. Autocomplete does not work. This piece is similar." What do you guys think? Dmitri From news at unleashedmind.com Tue Feb 17 01:55:40 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Tue, 17 Feb 2009 02:55:40 +0100 Subject: [development] Incremental filter for the permissions page In-Reply-To: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> Message-ID: <0e1601c990a2$d68a0140$0200a8c0@structworks.com> > I've been working on a patch that incrementally filters the > permission page - patch at http://drupal.org/node/229193 and > demo at http://dmitrizone.com/229193.mov . > > Dmitri Whether or not this thingy degrades, I don't really care. I wouldn't mind if it does not. But I care for whether this actually works on a full-blown Drupal site having 10-15 roles and countless modules exposing permissions (including CCK Field Permissions that adds 3 permissions per fields, f.e. for 125 fields). A previous attempt on parsing/filtering the permissions page on such a site resulted in a total browser freeze: #366442: Admin menu: Collapse modules on permissions page [1] It worked flawlessly on a stock Drupal core install. This needs to be tested before committing this. Thanks, Daniel [1] http://drupal.org/node/366442 From recidive at gmail.com Tue Feb 17 03:56:41 2009 From: recidive at gmail.com (Henrique Recidive) Date: Tue, 17 Feb 2009 00:56:41 -0300 Subject: [development] Incremental filter for the permissions page In-Reply-To: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> References: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> Message-ID: <841684fe0902161956m1edec339kccbb7ed5390b0d37@mail.gmail.com> 2009/2/16 Dmitri Gaskin : > Hello Development, > > I've been working on a patch that incrementally filters the permission page > - patch at http://drupal.org/node/229193 and demo at > http://dmitrizone.com/229193.mov. > > The patch is pretty much ready to be reviewed, except for the fact that > webchick has an issue with how it degrades. > Currently, without JavaScript, the textfield for searching simply isn't > there, and you can't use the incremental filter. > Webchick would like it to be degradable. The issue with this is that we > already have a 100-line search algorithm for searching in HTML, and we'd > need another 150 or so search algorithm to do it server side, which would > actually be quite different. > > CHX has an argument against needing a degradable version at > http://drupal.org/node/229193#comment-1260194: > "I think this is fine with working only if JavaScript is there. Drupal works > without JavaScript but with reduced functionality already. You can not > resize a textarea without JS for example. Autocomplete does not work. This > piece is similar." In this case, degradable means that the form is not useless without JavaScript, and it surely is not. What I would like to see there is a reusable component, which other core and contrib modules could use. It would basically allow you to set jQuery selectors for "what to search" and "what to hide". Henrique > What do you guys think? > > Dmitri > From cxjohnson at gmail.com Tue Feb 17 04:08:33 2009 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 16 Feb 2009 22:08:33 -0600 Subject: [development] Incremental filter for the permissions page In-Reply-To: <0e1601c990a2$d68a0140$0200a8c0@structworks.com> References: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> <0e1601c990a2$d68a0140$0200a8c0@structworks.com> Message-ID: <9ea8d6030902162008u343497das7ced68ab5ae257f5@mail.gmail.com> Good point, Daniel. I develop for a bunch of sites with over 100 modules enabled and lot of CCK fields. My permissions page is huge. While a nicer UI for it would be nice, having it die because of Javascript overload would be worse. ..chris On Mon, Feb 16, 2009 at 7:55 PM, Daniel F. Kudwien wrote: >> I've been working on a patch that incrementally filters the >> permission page - patch at http://drupal.org/node/229193 and >> demo at http://dmitrizone.com/229193.mov . >> >> Dmitri > > Whether or not this thingy degrades, I don't really care. I wouldn't mind > if it does not. > > But I care for whether this actually works on a full-blown Drupal site > having 10-15 roles and countless modules exposing permissions (including CCK > Field Permissions that adds 3 permissions per fields, f.e. for 125 fields). > > A previous attempt on parsing/filtering the permissions page on such a site > resulted in a total browser freeze: > > #366442: Admin menu: Collapse modules on permissions page [1] > > It worked flawlessly on a stock Drupal core install. > > This needs to be tested before committing this. > > > Thanks, > Daniel > > [1] http://drupal.org/node/366442 > > From sammys-drupal at synerger.com Tue Feb 17 04:15:32 2009 From: sammys-drupal at synerger.com (Sammy Spets) Date: Tue, 17 Feb 2009 15:15:32 +1100 Subject: [development] Incremental filter for the permissions page In-Reply-To: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> References: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> Message-ID: <499A39E4.7050500@synerger.com> +1 for filter being unavailable with javascript disabled provided the filter itself can be disabled in a setting (in case javascript in browser X, OS Y, moon at Z causes fireworks). If an admin doesn't have javascript enabled on their own site it's their loss of productivity ;) -- Sammy Spets Synerger http://synerger.com Dmitri Gaskin wrote: > Hello Development, > > I've been working on a patch that incrementally filters the permission > page - patch at http://drupal.org/node/229193 and demo at > http://dmitrizone.com/229193.mov. > > The patch is pretty much ready to be reviewed, except for the fact > that webchick has an issue with how it degrades. > Currently, without JavaScript, the textfield for searching simply > isn't there, and you can't use the incremental filter. > Webchick would like it to be degradable. The issue with this is that > we already have a 100-line search algorithm for searching in HTML, and > we'd need another 150 or so search algorithm to do it server side, > which would actually be quite different. > > CHX has an argument against needing a degradable version at > http://drupal.org/node/229193#comment-1260194: > "I think this is fine with working only if JavaScript is there. Drupal > works without JavaScript but with reduced functionality already. You > can not resize a textarea without JS for example. Autocomplete does > not work. This piece is similar." > > What do you guys think? > > Dmitri From gordon at heydon.com.au Tue Feb 17 04:49:44 2009 From: gordon at heydon.com.au (Gordon Heydon) Date: Tue, 17 Feb 2009 15:49:44 +1100 Subject: [development] Incremental filter for the permissions page In-Reply-To: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> References: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> Message-ID: <7A265972-3AEC-48E4-AB20-8AAA1B7624AB@heydon.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I like this, it looks great, and I agree that it should degrade. However my definition of degrade is that if you don't have js then the it should look like it does now with no filtering. Having filtering on it with no js would not be hard, but it will be cumbersome to use. You can still do what you need to do without js, but to get the best usability then you should have the js on. Much like how the table weighting works, it is much easier with js, but you can do it with js off as well. Gordon. On 17/02/2009, at 12:23 PM, Dmitri Gaskin wrote: > Hello Development, > > I've been working on a patch that incrementally filters the > permission page - patch at http://drupal.org/node/229193 and demo at http://dmitrizone.com/229193.mov > . > > The patch is pretty much ready to be reviewed, except for the fact > that webchick has an issue with how it degrades. > Currently, without JavaScript, the textfield for searching simply > isn't there, and you can't use the incremental filter. > Webchick would like it to be degradable. The issue with this is that > we already have a 100-line search algorithm for searching in HTML, > and we'd need another 150 or so search algorithm to do it server > side, which would actually be quite different. > > CHX has an argument against needing a degradable version at http://drupal.org/node/229193#comment-1260194 > : > "I think this is fine with working only if JavaScript is there. > Drupal works without JavaScript but with reduced functionality > already. You can not resize a textarea without JS for example. > Autocomplete does not work. This piece is similar." > > What do you guys think? > > Dmitri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmaQegACgkQngavurZvkrzJZACgvIXiqMJGYzLAVf9KsMeSUj82 cw0AoIh2a8Qf5Zp7BSSxcVabfEL33sJx =eRm5 -----END PGP SIGNATURE----- From dmitrig01 at gmail.com Tue Feb 17 05:00:58 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Mon, 16 Feb 2009 21:00:58 -0800 Subject: [development] Incremental filter for the permissions page In-Reply-To: <841684fe0902161956m1edec339kccbb7ed5390b0d37@mail.gmail.com> References: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> <841684fe0902161956m1edec339kccbb7ed5390b0d37@mail.gmail.com> Message-ID: <61CC12F6-15C0-4CD4-853E-417D1CC2F559@gmail.com> On Feb 16, 2009, at 7:56 PM, Henrique Recidive wrote: > 2009/2/16 Dmitri Gaskin : >> Hello Development, >> >> I've been working on a patch that incrementally filters the >> permission page >> - patch at http://drupal.org/node/229193 and demo at >> http://dmitrizone.com/229193.mov. >> >> The patch is pretty much ready to be reviewed, except for the fact >> that >> webchick has an issue with how it degrades. >> Currently, without JavaScript, the textfield for searching simply >> isn't >> there, and you can't use the incremental filter. >> Webchick would like it to be degradable. The issue with this is >> that we >> already have a 100-line search algorithm for searching in HTML, and >> we'd >> need another 150 or so search algorithm to do it server side, which >> would >> actually be quite different. >> >> CHX has an argument against needing a degradable version at >> http://drupal.org/node/229193#comment-1260194: >> "I think this is fine with working only if JavaScript is there. >> Drupal works >> without JavaScript but with reduced functionality already. You can >> not >> resize a textarea without JS for example. Autocomplete does not >> work. This >> piece is similar." > > In this case, degradable means that the form is not useless without > JavaScript, and it surely is not. > > What I would like to see there is a reusable component, which other > core and contrib modules could use. That'd currently done. > > It would basically allow you to set jQuery selectors for "what to > search" and "what to hide". You have to do a bit more work than that but not much. I'm going to implement it for the modules page next, but that's going to be after this goes in. > > > Henrique > >> What do you guys think? >> >> Dmitri >> From dmitrig01 at gmail.com Tue Feb 17 05:01:58 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Mon, 16 Feb 2009 21:01:58 -0800 Subject: [development] Incremental filter for the permissions page In-Reply-To: <0e1601c990a2$d68a0140$0200a8c0@structworks.com> References: <0e1601c990a2$d68a0140$0200a8c0@structworks.com> Message-ID: <7C65AE35-5728-4633-A94B-831C2ACF3CC9@gmail.com> On Feb 16, 2009, at 5:55 PM, Daniel F. Kudwien wrote: >> I've been working on a patch that incrementally filters the >> permission page - patch at http://drupal.org/node/229193 and >> demo at http://dmitrizone.com/229193.mov . >> >> Dmitri > > Whether or not this thingy degrades, I don't really care. I > wouldn't mind > if it does not. > > But I care for whether this actually works on a full-blown Drupal site > having 10-15 roles and countless modules exposing permissions > (including CCK > Field Permissions that adds 3 permissions per fields, f.e. for 125 > fields). > Fixed in the latest patch, and I provided a test module. > A previous attempt on parsing/filtering the permissions page on such > a site > resulted in a total browser freeze: > > #366442: Admin menu: Collapse modules on permissions page [1] > > It worked flawlessly on a stock Drupal core install. > > This needs to be tested before committing this. > > > Thanks, > Daniel > > [1] http://drupal.org/node/366442 > From dipench at gmail.com Tue Feb 17 05:50:22 2009 From: dipench at gmail.com (Dipen) Date: Tue, 17 Feb 2009 11:20:22 +0530 Subject: [development] Incremental filter for the permissions page In-Reply-To: <7C65AE35-5728-4633-A94B-831C2ACF3CC9@gmail.com> References: <0e1601c990a2$d68a0140$0200a8c0@structworks.com> <7C65AE35-5728-4633-A94B-831C2ACF3CC9@gmail.com> Message-ID: <1fcccc8a0902162150qa1ce303pd96378d637cc1ddf@mail.gmail.com> Looks like Its not taking in capital letters, is that out of scope? Commented on the issue http://drupal.org/node/229193#comment-1262332 Dipen Chaudhary http://www.dipenchaudhary.com http://playdrupal.com On Tue, Feb 17, 2009 at 10:31 AM, Dmitri Gaskin wrote: > > On Feb 16, 2009, at 5:55 PM, Daniel F. Kudwien wrote: > > I've been working on a patch that incrementally filters the >>> permission page - patch at http://drupal.org/node/229193 and >>> demo at http://dmitrizone.com/229193.mov . >>> >>> Dmitri >>> >> >> Whether or not this thingy degrades, I don't really care. I wouldn't mind >> if it does not. >> >> But I care for whether this actually works on a full-blown Drupal site >> having 10-15 roles and countless modules exposing permissions (including >> CCK >> Field Permissions that adds 3 permissions per fields, f.e. for 125 >> fields). >> >> > Fixed in the latest patch, and I provided a test module. > > > A previous attempt on parsing/filtering the permissions page on such a >> site >> resulted in a total browser freeze: >> >> #366442: Admin menu: Collapse modules on permissions page [1] >> >> It worked flawlessly on a stock Drupal core install. >> >> This needs to be tested before committing this. >> >> >> Thanks, >> Daniel >> >> [1] http://drupal.org/node/366442 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090217/26d29de4/attachment.htm From dmitrig01 at gmail.com Tue Feb 17 07:03:21 2009 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Mon, 16 Feb 2009 23:03:21 -0800 Subject: [development] Incremental filter for the permissions page In-Reply-To: <1fcccc8a0902162150qa1ce303pd96378d637cc1ddf@mail.gmail.com> References: <0e1601c990a2$d68a0140$0200a8c0@structworks.com> <7C65AE35-5728-4633-A94B-831C2ACF3CC9@gmail.com> <1fcccc8a0902162150qa1ce303pd96378d637cc1ddf@mail.gmail.com> Message-ID: That's not a discussion for the development list, but i've fixed it :-) Dmitri On Feb 16, 2009, at 9:50 PM, Dipen wrote: > Looks like Its not taking in capital letters, is that out of scope? > > Commented on the issue http://drupal.org/node/229193#comment-1262332 > > > > > Dipen Chaudhary > http://www.dipenchaudhary.com > http://playdrupal.com > > > > > On Tue, Feb 17, 2009 at 10:31 AM, Dmitri Gaskin > wrote: > > On Feb 16, 2009, at 5:55 PM, Daniel F. Kudwien wrote: > > I've been working on a patch that incrementally filters the > permission page - patch at http://drupal.org/node/229193 and > demo at http://dmitrizone.com/229193.mov . > > Dmitri > > Whether or not this thingy degrades, I don't really care. I > wouldn't mind > if it does not. > > But I care for whether this actually works on a full-blown Drupal site > having 10-15 roles and countless modules exposing permissions > (including CCK > Field Permissions that adds 3 permissions per fields, f.e. for 125 > fields). > > > Fixed in the latest patch, and I provided a test module. > > > A previous attempt on parsing/filtering the permissions page on such > a site > resulted in a total browser freeze: > > #366442: Admin menu: Collapse modules on permissions page [1] > > It worked flawlessly on a stock Drupal core install. > > This needs to be tested before committing this. > > > Thanks, > Daniel > > [1] http://drupal.org/node/366442 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090216/7fe2949f/attachment.htm From remorse at partners.org Tue Feb 17 15:34:27 2009 From: remorse at partners.org (Richard Morse) Date: Tue, 17 Feb 2009 10:34:27 -0500 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <4998279D.901@gmail.com> References: <4998279D.901@gmail.com> Message-ID: <273A6AE5-B03C-4833-B4A8-34F9C7CE1A58@partners.org> Hi! I have written a module using XMLRPC to import data to a CCK- defined node type. I imagine that it wouldn't be too hard to modify to match your requirements. If you're interested, send me an email... Ricky On Feb 15, 2009, at 9:33 AM, Paul Hoza wrote: > Hello folks, > > I've been struggling for a long time (way too long) to get a data > feed imported into CCK nodes. I've attempted a plethora of > different strategies, including but not limited to: FeedAPI, Feed > Element Mapper, custom parsers, hacking parsers, tweaking mappers, > Yahoo! Pipes to create custom feed versions of the original feed, > serialized PHP exports, etc. > > I'm tired of the project, but I have to find a way to get this to > work. > > So, I found a few articles on programmatically creating CCK nodes > and I'm hoping to connect with anyone who's had experience doing > this with JSON data. There is an XML/RSS version of this feed I > need, but it sucks compared to the JSON version, with respect to how > much data is in there and how it's formatted. The XML version hides > a lot of crucial info into a element... which I might be > able to parse through separately, but RSS feed aggregators just > ignore stuff in there. Again, I'd have to make a custom parser to > get in there. > > Here's an article that hits about as close as I've seen yet. I am > leaving for a couple days, so I'll try to get something like this > working when I get back, but I hoped to hear from anyone who's done > the same thing. Information on using JSON data to create nodes is > sparse, but this article hits pretty close to the mark: > https://secure.prolucid.com/node/43 > I had read other posts about doing similar methods using > drupal_execute(), et. al, but they all talk only about XML as data > source. I haven't found anything talking about JSON or > (un)serialized PHP sources. > > What I really need to do is do an initial import of the JSON feed > into my CCK node (which is a huge feed of 6,200+ items). After > that, I want to check the feed every day for changes and create new > daily nodes accordingly -- which is why FeedAPI really seemed like > the ticket, aside from my massive struggles with making my own > parser. For now, I'd be happy with a PHP script that I could call > daily with cron. > > > Thanks for any feedback... sorry for the long post. Part rant, part > plea. :) > > Cheers, > Paul Hoza > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. From kkaefer at gmail.com Tue Feb 17 22:23:29 2009 From: kkaefer at gmail.com (=?ISO-8859-1?Q?Konstantin_K=E4fer?=) Date: Tue, 17 Feb 2009 23:23:29 +0100 Subject: [development] Incremental filter for the permissions page In-Reply-To: <61CC12F6-15C0-4CD4-853E-417D1CC2F559@gmail.com> References: <3F1DE890-52C7-48CD-9175-9B327A62A030@gmail.com> <841684fe0902161956m1edec339kccbb7ed5390b0d37@mail.gmail.com> <61CC12F6-15C0-4CD4-853E-417D1CC2F559@gmail.com> Message-ID: <60764DF6-9968-4F78-A091-573C429FCEDB@gmail.com> Hi, that's a pretty good and useful feature. I don't think that this feature (or lack of feature without JS) fulfills the criterias of functionality that should degrade: Search is currently not possible with or without JS; so the new feature is merely a progressive enhancement. That being said, searching the permissions (or the entire admin area for that matter) would be another useful feature request; but it certainly does not block this patch from getting in. > You have to do a bit more work than that but not much. I'm going to > implement it for the modules page next, but that's going to be after > this goes in. Please do it in a generic way (e.g. you can mark tables as "filterable", like you can mark a table as "sticky table headers"). That way, we can save a lot of JS code. Konstantin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3383 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090217/308b1bff/attachment-0001.bin From drupal-devel at webchick.net Wed Feb 18 04:22:24 2009 From: drupal-devel at webchick.net (Angela Byron) Date: Tue, 17 Feb 2009 23:22:24 -0500 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-5 Message-ID: <0D22DA1A-B347-4A48-9266-32F8EFF85C03@webchick.net> Helllooooo, devel list! It's that time of the month again! (No, not THAT time of the month, silly... the time when we roll an interim unstable release of Drupal 7 to keep people abreast of what's happening!) Below are some of highlights from UNSTABLE-4 => UNSTABLE-5. For those who like way too much information, I've also attached a copy of the full output from cvs-release-notes.tpl.php showing all commits. http://drupal.org/node/224333#UNSTABLE-5 has the details of contributed module developer-facing changes. Note: Patch Spotlight has once again been "upgraded" and is now part of the "Community Initiatives" handbook. I think I'm finally done moving it around now. :P~ Please check out http://drupal.org/community-initiatives/drupal-core for important places to jump in, or to add your own itch that you're interested in helping to scratch! So, without further ado, here's a summary of what's been going on the last month: For developers: =============== * The biggest news of course is we now have a fabulous Field API in core! HOORAY! While there is still work to do, the initial patch and several follow-ups went in, which allows fields to be attached to both users and nodes. If you're interested in helping with this, please see http://drupal.org/node/361849 for a "jump off" point. * Another big, exciting development is hook_page_alter(). Page callbacks now return drupal_render()able arrays, which modules can then modify before they are output. Some crazy, exciting stuff can be done here. * Lots of documentation fixes/improvements: Thanks to the inclusion of API documentation in core, and thanks in part to our new "Novice" tag (http://drupal.org/patch/novice ), we've had lots of undocumented hooks documented, unclear comments clarified, and incorrect docs corrected. Please keep those patches (and issues) coming! * Comment and Taxonomy modules are now truly optional and can be uninstalled. In more radical news, *Block* module has also been made optional. OoOoOOo, scandalous. ;) * Performance improvements, including adding the ability to disable anonymous sessions to help with the Digg/Slashdot effect, mammoth hook_form_alter()s have been broken up to use hook_form_FORM_ID_alter() instead, and stopping filter_xss_bad_protocol from being called hundreds of time on each page. There is definitely still some work to do, but we're getting there! * Error handling has been improved. Core now uses E_ALL error reporting by default (which helps ensure squeaky-clean code), and changing its sensitivity can be done from a settings page instead of by hacking common.inc. ;) * Nedjo organized a great virtual internationalization sprint, which resulted in fixing of several annoying bugs (locale uninstall being broken, all languages being active in language switcher block) and made important in-roads to more complex features that will hopefully be part of a future unstable release. For users: ========== * Locale interface has been **dramatically** improved. It now behaves a lot more like the watchdog or node content administration screens do. * The vocabulary edit form has been also visually simplified by removing a bunch of needless fieldsets and the "weight" field. Ahhh... * Lots of textual improvements, too. For example, "Input formats" are now "Text formats" which help better describe what they are for. * There are snazzy new forum icons! Hooray! * Administration theme has been moved from under site configuration where NO ONE ever finds it, to the bottom of the themes page where people actually might. ;) Catch you next month, Drupalistas! -Angie -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090217/e5d866ee/attachment.html -------------- next part -------------- From paulhoza at gmail.com Wed Feb 18 08:53:13 2009 From: paulhoza at gmail.com (Paul Hoza) Date: Wed, 18 Feb 2009 01:53:13 -0700 Subject: [development] Programmatic data importing from JSON source In-Reply-To: References: <4998279D.901@gmail.com> Message-ID: <499BCC79.3080308@gmail.com> Thank you, Kristof, It looks like an interesting direction. I'll look into it and get back to you if I decide to go that path. I've gotten a couple other responses that I'm investigating also. I'm in fact using D-6 (should have stated that up-front, I now realize!), so I'm somewhat deterred by the notion of needing to port anything right now. My knowledge of module authoring is limited, to say the least. Thank you very much for your reply, Paul Kristof Van Tomme wrote: > Hi Paul, > > Check out http://drupal.org/project/extra_RSS_fields it's very alpha > and it's Drupal 5, but it sounds like it's approximately what you > would need. > > Feel free to contact me directly should have any questions about it. > > cheers, > Kristof > > > > 2009/2/15 Paul Hoza : > >> Hello folks, >> >> I've been struggling for a long time (way too long) to get a data feed >> imported into CCK nodes... From kvantomme at gmail.com Wed Feb 18 09:09:10 2009 From: kvantomme at gmail.com (Kristof Van Tomme) Date: Wed, 18 Feb 2009 10:09:10 +0100 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <499BCC79.3080308@gmail.com> References: <4998279D.901@gmail.com> <499BCC79.3080308@gmail.com> Message-ID: Hi Paul, Extra RSS was the first real PHP code I ever wrote, so you won't find crazy code in there ;) I haven't investigated yet if views2 does custom field output in RSS feeds, if not, it shouldn't be too hard to port. Cheers, Kristof ***************************** I blog at http://www.pronovix.com/blog Twitter at http://twitter.com/kvantomme You can find my profiles on LinkedIn at http://www.linkedin.com/in/kvantomme XING at https://www.xing.com/profile/Kristof_VanTomme and Facebook at http://www.facebook.com/people/Kristof-Van-Tomme/618847872 2009/2/18 Paul Hoza : > > Thank you, Kristof, > It looks like an interesting direction. I'll look into it and get back to > you if I decide to go that path. I've gotten a couple other responses that > I'm investigating also. > > I'm in fact using D-6 (should have stated that up-front, I now realize!), so > I'm somewhat deterred by the notion of needing to port anything right now. > My knowledge of module authoring is limited, to say the least. > > Thank you very much for your reply, > Paul > > > Kristof Van Tomme wrote: >> >> Hi Paul, >> >> Check out http://drupal.org/project/extra_RSS_fields it's very alpha >> and it's Drupal 5, but it sounds like it's approximately what you >> would need. >> >> Feel free to contact me directly should have any questions about it. >> >> cheers, >> Kristof >> >> >> >> 2009/2/15 Paul Hoza : >> >>> >>> Hello folks, >>> >>> I've been struggling for a long time (way too long) to get a data feed >>> imported into CCK nodes... > > From paulhoza at gmail.com Wed Feb 18 10:42:29 2009 From: paulhoza at gmail.com (Paul Hoza) Date: Wed, 18 Feb 2009 03:42:29 -0700 Subject: [development] Programmatic data importing from JSON source In-Reply-To: References: <4998279D.901@gmail.com> Message-ID: <499BE615.6070803@gmail.com> Hi David, Sorry for the delayed reply... I chose to extend my trip another day. A much-needed break that's paying off in general attitude adjustments and coffee consumption (way down.) So, I was likely not clear about my skill at programming PHP and/or Drupal modules: "not fantastic." I didn't mean to say that the feed is necessarily "so complicated", but more specifically, it's botching every parser I've tried -- and each tweak I've tried to the given parsers. It's a predictable XML structure, but there are several different types of elements that defy simple parsing, IMO. First, the main issues I always run into (with the FeedAPI parsers, mainly) are numbered arrays. Any time there's a numeric array name, most parsers seem to ditch the whole tree below that element. The only exceptions are arrays where the parser knows there's likely to be an array in at the element, like "tags" or such. I did get around this with an admittedly-crude hack, where I told the parser to ignore sub-arrays after a certain point for a specific element that was causing me trouble (in this case, an enclosure element) while using the FeedAPI & Simplepie parser combo -- detailed here if anyone wants to read further... I apologize again for the hacky nature of my solution: http://www.thisworked.com/content/drupal-feedapi-feed-element-mapper-missing-unnamed-elements-array The thing is, since that's of course a very bad hack and only specifically "solves" one exact problem with a known feed, there are several other places in the feed where nested arrays with numeric names are also ignored. I gave up on this ugly approach at this point, not wanting to further butcher the parser without just writing my own. So... the main reason I failed so miserably with the XML version of this particular feed is the fact they (feed authors) have entrenched a great deal of important data into the and elements, but nested inside a bunch of
tags which seem like they should be parsable with proper care. In the JSON version, these are all very nicely extracted out into the root of the feed as separate elements. I realize now, after much festering with RSS parsers that the use of / is done solely to get around the limitations of the RSS specs. Any RSS parser will strip off all sorts of special elements, so there's not much point in including them, I suppose. In my case, I could have dug the info out, but I understand their logic there -- typical RSS readers/parsers would butcher the data. Here's a quick sample of what the tag looks like and why I again failed to figure out how to parse through it and get the data out of all the nested tags into mappable elements for Feed Element Mapper:
Recommended
FALSE
Width
640
Height
480
Categories
First, Second, Other
(...)
The point of this weak example is that there are a bunch of very useful bits buried in the that I haven't been able to extract. I understand that an array recursion expert might swim right through there, but I didn't figure it out before giving up on that path. I do really think that a parser with FeedAPI /should/ be able to dig through that element and pull out all sorts of niceties, but I don't understand how. ...so, this email is getting way too long. Sorry. :P Hopefully this gives enough of a picture. I will go answer other email now. (Seriously sorry about the lack of brevity.) Paul David Metzler wrote: > Hey Paul, > > I haven't done this with JSON, but have written some XML to nested > array conversion stuff that might help, but might not. Could you shoot > an example of the feed and what makes it so complicated so that we > don't shower you with irrelavent solutions :). Is it that you're > trying to parse data that's inside XML that makes it so nasty or > something else? > > You give me the impression that the JSON feed contains more > information than the other feed. Is that true? > > Dave > On Feb 15, 2009, at 6:33 AM, Paul Hoza wrote: > >> Hello folks, >> >> I've been struggling for a long time (way too long) to get a data >> feed imported into CCK nodes. I've attempted a plethora of different >> strategies, including but not limited to: FeedAPI, Feed Element >> Mapper, custom parsers, hacking parsers, tweaking mappers, Yahoo! >> Pipes to create custom feed versions of the original feed, serialized >> PHP exports, etc. >> >> I'm tired of the project, but I have to find a way to get this to work. >> >> So, I found a few articles on programmatically creating CCK nodes and >> I'm hoping to connect with anyone who's had experience doing this >> with JSON data. There is an XML/RSS version of this feed I need, but >> it sucks compared to the JSON version, with respect to how much data >> is in there and how it's formatted. The XML version hides a lot of >> crucial info into a element... which I might be able to >> parse through separately, but RSS feed aggregators just ignore stuff >> in there. Again, I'd have to make a custom parser to get in there. >> >> Here's an article that hits about as close as I've seen yet. I am >> leaving for a couple days, so I'll try to get something like this >> working when I get back, but I hoped to hear from anyone who's done >> the same thing. Information on using JSON data to create nodes is >> sparse, but this article hits pretty close to the mark: >> https://secure.prolucid.com/node/43 >> I had read other posts about doing similar methods using >> drupal_execute(), et. al, but they all talk only about XML as data >> source. I haven't found anything talking about JSON or (un)serialized >> PHP sources. >> >> What I really need to do is do an initial import of the JSON feed >> into my CCK node (which is a huge feed of 6,200+ items). After that, >> I want to check the feed every day for changes and create new daily >> nodes accordingly -- which is why FeedAPI really seemed like the >> ticket, aside from my massive struggles with making my own parser. >> For now, I'd be happy with a PHP script that I could call daily with >> cron. >> >> >> Thanks for any feedback... sorry for the long post. Part rant, part >> plea. :) >> >> Cheers, >> Paul Hoza >> From sivaji2009 at gmail.com Wed Feb 18 18:33:23 2009 From: sivaji2009 at gmail.com (sivaji j.g) Date: Thu, 19 Feb 2009 00:03:23 +0530 Subject: [development] Enhancing drupal quiz module Message-ID: Hello developers, I would like to join with quiz module developers, here a brief introduction about me and my new ideas for quiz module http://groups.drupal.org/node/19141. I could see a new issues being created everyday by its users here http://drupal.org/project/issues/quiz?states=all. I would like to know the current development work regarding this module and the possible ways to get started to contribute. If you have any suggestions please post it here http://groups.drupal.org/node/19141 will be a good reference for future. -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/ea76d936/attachment.htm From killshot91 at comcast.net Wed Feb 18 18:47:19 2009 From: killshot91 at comcast.net (Steve Edwards) Date: Wed, 18 Feb 2009 10:47:19 -0800 Subject: [development] Enhancing drupal quiz module In-Reply-To: References: Message-ID: <499C57B7.5060506@comcast.net> The proper place to do introduce yourself to the maintainers is in the issue queue at the link you referenced below. Chances are the module maintainers won't see your post in the SoC group, or possibly even this list. Steve sivaji j.g wrote: > Hello developers, > > I would like to join with quiz module developers, here a brief > introduction about me and my new ideas for quiz module > http://groups.drupal.org/node/19141. > > I could see a new issues being created everyday by its users here > http://drupal.org/project/issues/quiz?states=all. I would like to know > the current development work regarding this module and the possible > ways to get started to contribute. > > If you have any suggestions please post it here > http://groups.drupal.org/node/19141 will be a good reference for future. > > > > -- > Thanks a lot > ----------------------------------------- > http://ubuntuslave.blogspot.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090218/05dfe1ce/attachment.htm From sivaji2009 at gmail.com Wed Feb 18 19:31:26 2009 From: sivaji2009 at gmail.com (sivaji j.g) Date: Thu, 19 Feb 2009 01:01:26 +0530 Subject: [development] Enhancing drupal quiz module In-Reply-To: <499C57B7.5060506@comcast.net> References: <499C57B7.5060506@comcast.net> Message-ID: On Thu, Feb 19, 2009 at 12:17 AM, Steve Edwards wrote: > The proper place to do introduce yourself to the maintainers is in the > issue queue at the link you referenced below. > ok thanks. -- Thanks a lot ----------------------------------------- http://ubuntuslave.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/d1b29951/attachment.htm From nir at winpdb.org Wed Feb 18 22:19:25 2009 From: nir at winpdb.org (Nir Aides) Date: Thu, 19 Feb 2009 00:19:25 +0200 Subject: [development] My first post: path_set_alias() and multiple aliases Message-ID: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> Hi, path_set_alias($path, $alias) inserts a new alias in case there is already an alias for $path. However drupal_lookup_path() keeps picking up the old alias. It makes sense to keep the old alias so links don't break in a website, but why look up the old alias when generating a URL? Is this a bug? Shouldn't the query "SELECT dst FROM {url_alias} WHERE src = '%s' AND language IN('%s', '') ORDER BY language DESC" in drupal_lookup_path() be rewritten as "SELECT dst FROM {url_alias} WHERE src = '%s' AND language IN('%s', '') ORDER BY language DESC, pid DESC" Also, shouldn't this be db_result(db_query_range()) instead of just db_result(db_query())? Nir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/35535c3d/attachment.htm From dipench at gmail.com Thu Feb 19 08:59:04 2009 From: dipench at gmail.com (Dipen) Date: Thu, 19 Feb 2009 14:29:04 +0530 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> Message-ID: <1fcccc8a0902190059v4c07e194h145b2d5f1b54de0e@mail.gmail.com> As an API, I think it should return all aliases of a path or should take an additional parameter like 'all','latest','oldest' depending on how you want it. But yeah it returns the oldest alias and just one entry. Dipen Chaudhary http://www.dipenchaudhary.com http://playdrupal.com On Thu, Feb 19, 2009 at 3:49 AM, Nir Aides wrote: > Hi, > > path_set_alias($path, $alias) inserts a new alias in case there is already > an alias for $path. However drupal_lookup_path() keeps picking up the old > alias. > It makes sense to keep the old alias so links don't break in a website, but > why look up the old alias when generating a URL? > > Is this a bug? > > Shouldn't the query "SELECT dst FROM {url_alias} WHERE src = '%s' AND > language IN('%s', '') ORDER BY language DESC" in drupal_lookup_path() be > rewritten as "SELECT dst FROM {url_alias} WHERE src = '%s' AND language > IN('%s', '') ORDER BY language DESC, pid DESC" > > Also, shouldn't this be db_result(db_query_range()) instead of just > db_result(db_query())? > > Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/14b5582a/attachment.htm From mfioretti at nexaima.net Thu Feb 19 09:47:09 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 19 Feb 2009 10:47:09 +0100 Subject: [development] Back to Curl-based content generation Message-ID: <20090219094709.GH3116@nexaima.net> Greetings, sorry if I couldn't answer earlier to all the feedback that came in the original thread a couple weeks ago. It looks like several things I wrote were simply ignored by some posters. I'm going to shortly sum them up again, and then ask one (last, I promise) related question. Quoting from several posts of the original thread: > Quite frankly, shell + curl are not an adequate tool for the job, > unless you grok awk and sed really well. > ... > You will likely also need to have a cookie > .... > View Source. Search ' post'ed for a given form. > ... > Everything in drupal is processed through index.php, so you don't > need a sequence of URLs for your post'ing either. IIRC, I had already made clear, before getting these answers, that: - I'm already much more expert in awk/sed/bash/perl coding than with PHP, so a non-php solution is much more time-efficient for me, if at all possible. Not to mention that those tools/languages give, in the real world of desktop/usb key linux distros, more guarantees to work out of the box without tweaking or installing extra-packages than anything requiring php. - I know very well what HTML forms and HTTP cookies are, and have already done this with non-drupal websites. And the URLs you see in the browser when you add content by hand are NOT "index.php + some parameters" - (almost) the only solution I am interested into is how to add new content remotely, when I cannot alter in any way the configuration of the server where Drupal runs. I'm not rewriting all this to start a fight, really, just to clarify why I asked what I asked and what I already know, that is to save your time. This said, I do understand all the points about Drupal being more interested in offering a flexible API than in supporting this kind of things. So, I will now go back to my desk and put together, by myself, my custom shell+curl hack based on the one posted here by Martin Stadler (thanks, Martin!). However, let me ask you this: If you already said it, I do confess I didn't recognize it: what is the smallest possible set of Drupal(related) Php **files or libraries** that I should install on a Linux *desktop* without HTTP server but with a working PHP-CLI interpreter, to put together a PHP script which can log into a remote Drupal site and add nodes? Thanks, M. -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From mistknight at gmail.com Thu Feb 19 10:51:35 2009 From: mistknight at gmail.com (Ashraf Amayreh) Date: Thu, 19 Feb 2009 12:51:35 +0200 Subject: [development] Error creating a release Message-ID: Hello all, I'm noticing this error when trying to create a release: Fatal error: Call to undefined function project_project_access() in /var/www/ drupal.org/htdocs/sites/all/modules/project/release/project_release.moduleon line 212 Just thought I should raise a flag. Although it could just be maintenance work on the site. -- Ashraf Amayreh http://aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/e2bd1331/attachment-0001.htm From paolomainardi at gmail.com Thu Feb 19 10:59:02 2009 From: paolomainardi at gmail.com (Paolo Mainardi) Date: Thu, 19 Feb 2009 11:59:02 +0100 Subject: [development] Error creating a release In-Reply-To: References: Message-ID: On Thu, Feb 19, 2009 at 11:51 AM, Ashraf Amayreh wrote: > Hello all, > > I'm noticing this error when trying to create a release: > > Fatal error: Call to undefined function project_project_access() in > /var/www/ > drupal.org/htdocs/sites/all/modules/project/release/project_release.moduleon line 212 > > Just thought I should raise a flag. Although it could just be maintenance > work on the site. > This error is randomly appearing on all pages, also @project_edit_load Very good work guys! -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/d5b96232/attachment.htm From cog.rusty at gmail.com Thu Feb 19 11:04:56 2009 From: cog.rusty at gmail.com (Cog Rusty) Date: Thu, 19 Feb 2009 13:04:56 +0200 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219094709.GH3116@nexaima.net> References: <20090219094709.GH3116@nexaima.net> Message-ID: On Thu, Feb 19, 2009 at 11:47 AM, M. Fioretti wrote: > Greetings, > > sorry if I couldn't answer earlier to all the feedback that came in > the original thread a couple weeks ago. > > It looks like several things I wrote were simply ignored by some > posters. I'm going to shortly sum them up again, and then ask one > (last, I promise) related question. > > Quoting from several posts of the original thread: > >> Quite frankly, shell + curl are not an adequate tool for the job, >> unless you grok awk and sed really well. >> ... >> You will likely also need to have a cookie >> .... >> View Source. Search '> post'ed for a given form. >> ... >> Everything in drupal is processed through index.php, so you don't >> need a sequence of URLs for your post'ing either. > > IIRC, I had already made clear, before getting these answers, that: > > - I'm already much more expert in awk/sed/bash/perl coding than with > PHP, so a non-php solution is much more time-efficient for me, if at > all possible. Not to mention that those tools/languages give, in the > real world of desktop/usb key linux distros, more guarantees to work > out of the box without tweaking or installing extra-packages than > anything requiring php. > > - I know very well what HTML forms and HTTP cookies are, and have > already done this with non-drupal websites. And the URLs you see in > the browser when you add content by hand are NOT "index.php + some > parameters" > > - (almost) the only solution I am interested into is how to add new > content remotely, when I cannot alter in any way the configuration > of the server where Drupal runs. > > I'm not rewriting all this to start a fight, really, just to clarify > why I asked what I asked and what I already know, that is to save your > time. > > This said, I do understand all the points about Drupal being more > interested in offering a flexible API than in supporting this kind of > things. So, I will now go back to my desk and put together, by myself, > my custom shell+curl hack based on the one posted here by Martin > Stadler (thanks, Martin!). However, let me ask you this: > > If you already said it, I do confess I didn't recognize it: what is > the smallest possible set of Drupal(related) Php **files or > libraries** that I should install on a Linux *desktop* without HTTP > server but with a working PHP-CLI interpreter, to put together a PHP > script which can log into a remote Drupal site and add nodes? Maybe I lost some part of this discussion, but I wonder: Why would you need any kind of server or PHP on your desktop to work with a remote Drupal web site? And how could a web site respond to requests from any of those? Are you talking about putting together a CLI web browser? > Thanks, > M. > > -- > Your own civil rights and the quality of your life heavily depend on how > software is used *around* you: http://digifreedom.net/node/84 > From victorkane at gmail.com Thu Feb 19 11:11:21 2009 From: victorkane at gmail.com (Victor Kane) Date: Thu, 19 Feb 2009 09:11:21 -0200 Subject: [development] Back to Curl-based content generation In-Reply-To: References: <20090219094709.GH3116@nexaima.net> Message-ID: M. wants to shove content into a remote Drupal site from his desktop. So he wants to know the minimum to install in terms of a script which bootstraps Drupal and uses curl to get the content and node_save to save it to the remote URL. I think this might be better served by running an XMLRPC or other server (see services module), then you can use anything you like to speak the same protocol. Victor Kane http://awebfactory.com.ar On Thu, Feb 19, 2009 at 9:04 AM, Cog Rusty wrote: > On Thu, Feb 19, 2009 at 11:47 AM, M. Fioretti > wrote: > > Greetings, > > > > sorry if I couldn't answer earlier to all the feedback that came in > > the original thread a couple weeks ago. > > > > It looks like several things I wrote were simply ignored by some > > posters. I'm going to shortly sum them up again, and then ask one > > (last, I promise) related question. > > > > Quoting from several posts of the original thread: > > > >> Quite frankly, shell + curl are not an adequate tool for the job, > >> unless you grok awk and sed really well. > >> ... > >> You will likely also need to have a cookie > >> .... > >> View Source. Search ' >> post'ed for a given form. > >> ... > >> Everything in drupal is processed through index.php, so you don't > >> need a sequence of URLs for your post'ing either. > > > > IIRC, I had already made clear, before getting these answers, that: > > > > - I'm already much more expert in awk/sed/bash/perl coding than with > > PHP, so a non-php solution is much more time-efficient for me, if at > > all possible. Not to mention that those tools/languages give, in the > > real world of desktop/usb key linux distros, more guarantees to work > > out of the box without tweaking or installing extra-packages than > > anything requiring php. > > > > - I know very well what HTML forms and HTTP cookies are, and have > > already done this with non-drupal websites. And the URLs you see in > > the browser when you add content by hand are NOT "index.php + some > > parameters" > > > > - (almost) the only solution I am interested into is how to add new > > content remotely, when I cannot alter in any way the configuration > > of the server where Drupal runs. > > > > I'm not rewriting all this to start a fight, really, just to clarify > > why I asked what I asked and what I already know, that is to save your > > time. > > > > This said, I do understand all the points about Drupal being more > > interested in offering a flexible API than in supporting this kind of > > things. So, I will now go back to my desk and put together, by myself, > > my custom shell+curl hack based on the one posted here by Martin > > Stadler (thanks, Martin!). However, let me ask you this: > > > > If you already said it, I do confess I didn't recognize it: what is > > the smallest possible set of Drupal(related) Php **files or > > libraries** that I should install on a Linux *desktop* without HTTP > > server but with a working PHP-CLI interpreter, to put together a PHP > > script which can log into a remote Drupal site and add nodes? > > > Maybe I lost some part of this discussion, but I wonder: Why would you > need any kind of server or PHP on your desktop to work with a remote > Drupal web site? And how could a web site respond to requests from any > of those? Are you talking about putting together a CLI web browser? > > > > Thanks, > > M. > > > > -- > > Your own civil rights and the quality of your life heavily depend on how > > software is used *around* you: http://digifreedom.net/node/84 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/11829206/attachment.htm From mfioretti at nexaima.net Thu Feb 19 12:03:15 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 19 Feb 2009 13:03:15 +0100 Subject: [development] Back to Curl-based content generation In-Reply-To: References: <20090219094709.GH3116@nexaima.net> Message-ID: <20090219120315.GH8501@nexaima.net> On Thu, Feb 19, 2009 13:04:56 PM +0200, Cog Rusty wrote: > Maybe I lost some part of this discussion, but I wonder: Why would > you need any kind of server or PHP on your desktop to work with a > remote Drupal web site? because I want to add nodes from the command line at my desktop, for reasons not really relevant here (in short, it would integrate much, much better with my own, already existing document management/publishing/backup flow)... ...but, when I asked info to write my own bash/curl script to do this, many members of this list simply answered saying "install this or that drupal module or php library on the server" :-) > Are you talking about putting together a CLI web browser? No, just an http client, ie a shell script which sends to Drupal the same HTML code that a real browser would transmit when I add a node by hand, via keyboard and mouse. The web is full of scripts like this, but doing it to drupal seems much harder/undocumented than in other cases. Marco -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From earnie at users.sourceforge.net Thu Feb 19 12:23:29 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 19 Feb 2009 07:23:29 -0500 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219120315.GH8501@nexaima.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> Message-ID: <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> Quoting "M. Fioretti" : > On Thu, Feb 19, 2009 13:04:56 PM +0200, Cog Rusty wrote: > >> Maybe I lost some part of this discussion, but I wonder: Why would >> you need any kind of server or PHP on your desktop to work with a >> remote Drupal web site? > > because I want to add nodes from the command line at my desktop, for > reasons not really relevant here (in short, it would integrate much, > much better with my own, already existing document > management/publishing/backup flow)... > I add nodes to my site via a php script executed in batch. The script creates a node object and calls node_save(). No curl needed. Do you control the remote Drupal system? > ...but, when I asked info to write my own bash/curl script to do this, > many members of this list simply answered saying "install this or that > drupal module or php library on the server" :-) > Well, that is how we modify Drupal you know. You create a module to do this or that. >> Are you talking about putting together a CLI web browser? > > No, just an http client, ie a shell script which sends to Drupal the > same HTML code that a real browser would transmit when I add a node by > hand, via keyboard and mouse. The web is full of scripts like this, > but doing it to drupal seems much harder/undocumented than in other > cases. > Undocumented because it is out of the norm. I suggest you create a php script for the server side that will create the node object and do the node_save(). Then create a curl script on the client side that will fill the post data for the server script. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From gabor at hojtsy.hu Thu Feb 19 12:23:34 2009 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Thu, 19 Feb 2009 13:23:34 +0100 Subject: [development] Error creating a release In-Reply-To: References: Message-ID: <86ca3ccb0902190423v49b138ffofff99beede5646be@mail.gmail.com> Paolo, Ashraf, As the front page post said, we are using our own issue tracker to track these issues, so better look up there, and see whether this was already submitted. And it was! See http://drupal.org/node/376684 We are tracking the issue there. Thanks, G?bor On Thu, Feb 19, 2009 at 11:59 AM, Paolo Mainardi wrote: > > > On Thu, Feb 19, 2009 at 11:51 AM, Ashraf Amayreh > wrote: >> >> Hello all, >> >> I'm noticing this error when trying to create a release: >> >> Fatal error: Call to undefined function project_project_access() in >> /var/www/drupal.org/htdocs/sites/all/modules/project/release/project_release.module >> on line 212 >> >> Just thought I should raise a flag. Although it could just be maintenance >> work on the site. > > > This error is randomly appearing on all pages, also @project_edit_load > > Very good work guys! > > -- > Paolo Mainardi > > Vice Presidente Assoc.ILDN (http://www.ildn.net) > Blog: http://www.paolomainardi.com > From earnie at users.sourceforge.net Thu Feb 19 12:44:12 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 19 Feb 2009 07:44:12 -0500 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> Message-ID: <20090219074412.i67a1yaj4ypc8sog@mail.progw.org> Quoting Nir Aides : > Hi, > > path_set_alias($path, $alias) inserts a new alias in case there is already > an alias for $path. However drupal_lookup_path() keeps picking up the old > alias. > It makes sense to keep the old alias so links don't break in a website, but > why look up the old alias when generating a URL? > > Is this a bug? > You should review the issue queue. I know that there are issues related to path_set_alias. > Shouldn't the query "SELECT dst FROM {url_alias} WHERE src = '%s' AND > language IN('%s', '') ORDER BY language DESC" in drupal_lookup_path() be > rewritten as "SELECT dst FROM {url_alias} WHERE src = '%s' AND language > IN('%s', '') ORDER BY language DESC, pid DESC" > > Also, shouldn't this be db_result(db_query_range()) instead of just > db_result(db_query())? > I don't find this query in drupal_lookup_path for D6 or D7. The query should have a LIMIT 1 at least since db_result is only returning the first row. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From mistknight at gmail.com Thu Feb 19 12:54:51 2009 From: mistknight at gmail.com (Ashraf Amayreh) Date: Thu, 19 Feb 2009 14:54:51 +0200 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> Message-ID: You could always simply run a curl script that just mimics a login then page submission. On Thu, Feb 19, 2009 at 2:23 PM, Earnie Boyd wrote: > Quoting "M. Fioretti" : > > On Thu, Feb 19, 2009 13:04:56 PM +0200, Cog Rusty wrote: >> >> Maybe I lost some part of this discussion, but I wonder: Why would >>> you need any kind of server or PHP on your desktop to work with a >>> remote Drupal web site? >>> >> >> because I want to add nodes from the command line at my desktop, for >> reasons not really relevant here (in short, it would integrate much, >> much better with my own, already existing document >> management/publishing/backup flow)... >> >> > I add nodes to my site via a php script executed in batch. The script > creates a node object and calls node_save(). No curl needed. Do you > control the remote Drupal system? > > ...but, when I asked info to write my own bash/curl script to do this, >> many members of this list simply answered saying "install this or that >> drupal module or php library on the server" :-) >> >> > Well, that is how we modify Drupal you know. You create a module to do > this or that. > > Are you talking about putting together a CLI web browser? >>> >> >> No, just an http client, ie a shell script which sends to Drupal the >> same HTML code that a real browser would transmit when I add a node by >> hand, via keyboard and mouse. The web is full of scripts like this, >> but doing it to drupal seems much harder/undocumented than in other >> cases. >> >> > Undocumented because it is out of the norm. I suggest you create a php > script for the server side that will create the node object and do the > node_save(). Then create a curl script on the client side that will fill > the post data for the server script. > > -- > Earnie http://r-feed.com > Make a Drupal difference and review core patches. > > -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ > > -- Ashraf Amayreh http://aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/2cf6dcac/attachment.htm From mfioretti at nexaima.net Thu Feb 19 13:25:16 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 19 Feb 2009 14:25:16 +0100 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> Message-ID: <20090219132516.GK8501@nexaima.net> On Thu, Feb 19, 2009 07:23:29 AM -0500, Earnie Boyd wrote: > Quoting "M. Fioretti" : > >> On Thu, Feb 19, 2009 13:04:56 PM +0200, Cog Rusty wrote: >> >>> Maybe I lost some part of this discussion, but I wonder: Why would >>> you need any kind of server or PHP on your desktop to work with a >>> remote Drupal web site? No, as I already said several times in this thread. More exactly: I do control the one where I'd need this first, but not others on which I'll have to work soon, that's why I'm looking for one solution which doesn't rely on access to server. So, this wouldn't work, would it: > I add nodes to my site via a php script executed in batch. The script > creates a node object and calls node_save(). because it has to run on the same server which hosts the drupal website, right? > Well, that is how we modify Drupal you know. You create a module to > do this or that. The only problem being that "we" only means drupal sysadmins, not drupal users. I don't want to modify anything in the drupal websites I need to use, they work just fine. I only want to write software which talks to them from remote computers, to add nodes. Thanks, Marco -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From mfioretti at nexaima.net Thu Feb 19 13:28:11 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 19 Feb 2009 14:28:11 +0100 Subject: [development] Back to Curl-based content generation In-Reply-To: References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> Message-ID: <20090219132811.GL8501@nexaima.net> On Thu, Feb 19, 2009 14:54:51 PM +0200, Ashraf Amayreh wrote: > You could always simply run a curl script that just mimics a login > then page submission. honestly, this is getting funny now. This is exactly what *I* asked here weeks ago: info and documentation to put together just such a script with the minimum possible amount of manual trial and error, http headers sniffing and so on. Nothing more. Marco -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From hovercrafter at earthlink.net Thu Feb 19 13:57:17 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Thu, 19 Feb 2009 08:57:17 -0500 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219132811.GL8501@nexaima.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132811.GL8501@nexaima.net> Message-ID: <499D653D.9040406@earthlink.net> M. Fioretti wrote: > On Thu, Feb 19, 2009 14:54:51 PM +0200, Ashraf Amayreh wrote: > > > You could always simply run a curl script that just mimics a login > > then page submission. > > honestly, this is getting funny now. This is exactly what *I* asked > here weeks ago: info and documentation to put together just such a > script with the minimum possible amount of manual trial and error, > http headers sniffing and so on. Nothing more. > > Marco > Request the node/add/{node-type}page. Grep out all the input elements along with their default values. Change the needed default values (ie: title, body, etc.) then resubmit it via a post request to the same URL. If you want to catch error messages then you have to grep out the error division of the URL you submitted to. As far as what data is required - well that depends upon the site's configuration. It depends upon modules the site has enabled, how the content type is configured, what options are available to the current user's access level, etc. The only other option is the one stated numerous times - using a module. Either activate the Blog API module (and use XML-RPC), or use something like the services module. Now I have seen your reply about this: >No, as I already said several times in this thread. More exactly: I do >control the one where I'd need this first, but not others on which >I'll have to work soon, that's why I'm looking for one solution which >doesn't rely on access to server. So, this wouldn't work, would it: If you are doing this for other sites, then I can only assume it's because they are asking you to (if not then that opens up a whole new debate on ethics). If that's the case then can't you simple ask them to install a module for this, even if it's as simple as activating the BlogAPI module? From prometheus6 at gmail.com Thu Feb 19 14:16:40 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Thu, 19 Feb 2009 09:16:40 -0500 Subject: [development] Back to Curl-based content generation In-Reply-To: <499D653D.9040406@earthlink.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132811.GL8501@nexaima.net> <499D653D.9040406@earthlink.net> Message-ID: On Thu, Feb 19, 2009 at 8:57 AM, Jamie Holly wrote: > > M. Fioretti wrote: > > No, as I already said several times in this thread. More exactly: I do >> control the one where I'd need this first, but not others on which >> I'll have to work soon, that's why I'm looking for one solution which >> doesn't rely on access to server. So, this wouldn't work, would it: >> > > > If you are doing this for other sites, then I can only assume it's because > they are asking you to (if not then that opens up a whole new debate on > ethics). Indeed. In fact, the whole conversation has inspired me to write a module that blocks flooding by tracking form tokens instead of hosts. I get that (attempted DOS via automated comment submissions) periodically. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/27accffc/attachment.htm From news at unleashedmind.com Thu Feb 19 14:23:10 2009 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Thu, 19 Feb 2009 15:23:10 +0100 Subject: [development] Back to Curl-based content generation In-Reply-To: <499D653D.9040406@earthlink.net> Message-ID: <109601c9929d$97d1f550$0200a8c0@structworks.com> Executing arbitrary stuff in Drupal via cURL? Simple. As in "SimpleTest". The entire testing suite is based on cURL. I recommend having a look at http://drupal.org/project/simpletest, resp. /modules/simpletest in CVS HEAD of Drupal core. To get a feeling of how to use it properly, I recommend writing some tests for D7. That way, you'll learn how to properly use the testing framework, and thus, how to use cURL for doing arbitrary stuff. We even have some issues prepared for you: http://drupal.org/project/issues/drupal/term/345 sun From mfioretti at nexaima.net Thu Feb 19 14:29:15 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Thu, 19 Feb 2009 15:29:15 +0100 Subject: [development] Back to Curl-based content generation In-Reply-To: <499D653D.9040406@earthlink.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132811.GL8501@nexaima.net> <499D653D.9040406@earthlink.net> Message-ID: <20090219142915.GM8501@nexaima.net> On Thu, Feb 19, 2009 08:57:17 AM -0500, Jamie Holly wrote: > Request the node/add/{node-type}page. Grep out all the input > elements along with their default values... OK, thanks. > If you are doing this for other sites, then I can only assume it's > because they are asking you to (if not then that opens up a whole > new debate on ethics). Ethics? Are you serious? I have several **real** accounts on several, independent Drupal-based websites. **real** meaning "I'm a real, honest, regularly registered and approved user on all those websites". I must or want add content to all those websites more or less regularly, say several times a week. And in at least one case I also need to put online as nodes (without, I repeat, any possibility to modify the server setup) lots of already existing text files. And I just happen to find a much smarter and more efficient use of my time to type in my full-screen, favourite, heavily customized text-editor and then launch some "publish-to-drupal-website" script than log in to cut-and-paste stuff or click drop-down menus every time. Period. What's wrong with such a wish? Above all, what's ethic got to do with this? The only issue may be, in general, if this lessened the income from web ads of a site. Rest assured this is not an issue for any of the websites where I need to do this. I perfectly know how bad it is for websites, I even publicly wrote about it 7 years ago (http://www.linuxjournal.com/article/5623). So don't worry, ethics is perfectly safe here. Incidentally, this is not the first, more or less explicit "why are you asking us help on how to spam drupal websites" kind of answer I've got in this thread, and it's starting to be offensive, both for me and for you Drupal developers. I write online for a living: would I be so idiot to mess my reputation in such a way? Even if I didn't write, if I were a spammer, would I be so idiot to come here with my real name to ask? If I were a spammer I would have already made all of this work without ****ever**** asking in public, because I'd have had a much more powerful incentive to spend days and nights making spambots work without letting everybody know about it. > If that's the case then can't you simple ask them to install a > module for this, even if it's as simple as activating the BlogAPI > module? because some of those websites don't give a damn if I add content via browser, voodoo spells or anything in between, but simply won't change their default configuration for me. Sure, this is my problem only, it's just that it's tiring to repeat it many times. No problem, however. Marco -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From hovercrafter at earthlink.net Thu Feb 19 14:45:57 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Thu, 19 Feb 2009 09:45:57 -0500 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219142915.GM8501@nexaima.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132811.GL8501@nexaima.net> <499D653D.9040406@earthlink.net> <20090219142915.GM8501@nexaima.net> Message-ID: <499D70A5.4020506@earthlink.net> I'm sorry if you felt it an insult, but it is a legitimate concern . The reason the "common scripts" you found out there aren't working is not a default of Drupal, but rather a feature. That feature helps reduce spam, and you are asking the development list of Drupal how to circumvent this highly valuable feature. Perhaps your questions would be better raised in the support area of Drupal.org or support mailing list. Jamie Holly M. Fioretti wrote: > On Thu, Feb 19, 2009 08:57:17 AM -0500, Jamie Holly wrote: > > > Request the node/add/{node-type}page. Grep out all the input > > elements along with their default values... > > OK, thanks. > > > If you are doing this for other sites, then I can only assume it's > > because they are asking you to (if not then that opens up a whole > > new debate on ethics). > > Ethics? Are you serious? I have several **real** accounts on several, > independent Drupal-based websites. **real** meaning "I'm a real, > honest, regularly registered and approved user on all those websites". > > I must or want add content to all those websites more or less > regularly, say several times a week. And in at least one case I also > need to put online as nodes (without, I repeat, any possibility to > modify the server setup) lots of already existing text files. And I > just happen to find a much smarter and more efficient use of my time > to type in my full-screen, favourite, heavily customized text-editor > and then launch some "publish-to-drupal-website" script than log in to > cut-and-paste stuff or click drop-down menus every time. Period. > > What's wrong with such a wish? Above all, what's ethic got to do with > this? The only issue may be, in general, if this lessened the income > from web ads of a site. Rest assured this is not an issue for any of > the websites where I need to do this. I perfectly know how bad it is > for websites, I even publicly wrote about it 7 years ago > (http://www.linuxjournal.com/article/5623). So don't worry, ethics is > perfectly safe here. > > Incidentally, this is not the first, more or less explicit "why are > you asking us help on how to spam drupal websites" kind of answer I've > got in this thread, and it's starting to be offensive, both for me and > for you Drupal developers. I write online for a living: would I be so > idiot to mess my reputation in such a way? Even if I didn't write, if > I were a spammer, would I be so idiot to come here with my real name > to ask? If I were a spammer I would have already made all of this work > without ****ever**** asking in public, because I'd have had a much > more powerful incentive to spend days and nights making spambots work > without letting everybody know about it. > > > If that's the case then can't you simple ask them to install a > > module for this, even if it's as simple as activating the BlogAPI > > module? > > because some of those websites don't give a damn if I add content via > browser, voodoo spells or anything in between, but simply won't change > their default configuration for me. Sure, this is my problem only, it's just that it's tiring to repeat it many times. No problem, however. > > Marco > > From michael at favias.org Thu Feb 19 15:36:46 2009 From: michael at favias.org (Michael Favia) Date: Thu, 19 Feb 2009 09:36:46 -0600 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219142915.GM8501@nexaima.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132811.GL8501@nexaima.net> <499D653D.9040406@earthlink.net> <20090219142915.GM8501@nexaima.net> Message-ID: <499D7C8E.2010608@favias.org> M. Fioretti wrote: > Incidentally, this is not the first, more or less explicit "why are > you asking us help on how to spam drupal websites" kind of answer I've > got in this thread, and it's starting to be offensive, both for me and > for you Drupal developers. I write online for a living: would I be so > idiot to mess my reputation in such a way? Even if I didn't write, if > I were a spammer, would I be so idiot to come here with my real name > to ask? If I were a spammer I would have already made all of this work > without ****ever**** asking in public, because I'd have had a much > more powerful incentive to spend days and nights making spambots work > without letting everybody know about it. > Marco you are a relative unknown on this mailing list to me and others. Your drupal user history is entirely selfserving (http://drupal.org/user/166184/track) with out ever returning the favor to the community. Despite this many people have stepped forward to offer you ideas and help. Please understand that we all provide this advice and assistance out of the generosity of our hearts and the desire for our project to succeed. Your abrasiveness and ingratitude in response to this help are not appreciated nor welcome. Furthermore, your question IS suspicious without a better historical understanding of you as a drupal user/contributor so it should be met with the concern you have experienced. Several valid suggestions have been proposed and you would do well to investigate each of them. Please take any further discussion of it off the development list as this is a support question. -mf From martin at siarp.de Thu Feb 19 15:41:43 2009 From: martin at siarp.de (Martin Stadler) Date: Thu, 19 Feb 2009 16:41:43 +0100 Subject: [development] Back to Curl-based content generation In-Reply-To: <499D70A5.4020506@earthlink.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132811.GL8501@nexaima.net> <499D653D.9040406@earthlink.net> <20090219142915.GM8501@nexaima.net> <499D70A5.4020506@earthlink.net> Message-ID: <49571EFD-6045-4133-8FF2-685E0AA102D9@siarp.de> I'm trying to clean-up this thread (I know I shoudn't)... Useful things first so people who don't care about nonsense can skip the rest: Marco wants to be able to post content to arbitrary (not under any control by him) Drupal sites via command line. There seem to be two options: 1) Use a script like http://drupal.org/node/80548 . If you for some reason don't want to use PHP it should be easy to extract the cURL code to use it in a shell script or whatever as I pointed out earlier on this list. 2) Use SimpleTest as this seems to contain this functionality also based on cURL. @Marco: What more do you need? What kind of better prepared solution do you expect? What kind of documentation is missing? You already said you would be fine with these resources. I don't quote understand why this is still an issue. Now comes the social part: I think Marco is right when he is unhappy with most of the answers to his question. It seems most people didn't read so why do you answer then? I'd like to see more respect. Ok, I stop here. From subscribe at courtnage.ca Thu Feb 19 15:51:52 2009 From: subscribe at courtnage.ca (Ryan Courtnage) Date: Thu, 19 Feb 2009 08:51:52 -0700 Subject: [development] Back to Curl-based content generation In-Reply-To: References: <20090219094709.GH3116@nexaima.net> Message-ID: On Thu, Feb 19, 2009 at 2:47 AM, M. Fioretti wrote: > - (almost) the only solution I am interested into is how to add new > content remotely, when I cannot alter in any way the configuration > of the server where Drupal runs. I do this on a weekly basis: submit pre-written node content (among other things) to various Drupal sites. For me, these Drupal sites happen to be part of my development environment (local, dev, test, prod). No drupal module installation required. I do it with Selenium. http://seleniumhq.org/ R From ryancourtnage at gmail.com Thu Feb 19 15:57:57 2009 From: ryancourtnage at gmail.com (Ryan Courtnage) Date: Thu, 19 Feb 2009 08:57:57 -0700 Subject: [development] Back to Curl-based content generation In-Reply-To: References: <20090219094709.GH3116@nexaima.net> Message-ID: On Thu, Feb 19, 2009 at 2:47 AM, M. Fioretti wrote: > - (almost) the only solution I am interested into is how to add new > content remotely, when I cannot alter in any way the configuration > of the server where Drupal runs. I do this on a weekly basis: submit pre-written node content (among other things) to various Drupal sites. For me, these Drupal sites happen to be part of my development environment (local, dev, test, prod). No module installation required. I do it with Selenium. http://seleniumhq.org/ R From cpforbes at gmail.com Thu Feb 19 16:28:39 2009 From: cpforbes at gmail.com (Craig Forbes) Date: Thu, 19 Feb 2009 10:28:39 -0600 Subject: [development] Back to Curl-based content generation In-Reply-To: <20090219094709.GH3116@nexaima.net> References: <20090219094709.GH3116@nexaima.net> Message-ID: On Thu, Feb 19, 2009 at 3:47 AM, M. Fioretti wrote: > - (almost) the only solution I am interested into is how to add new > content remotely, when I cannot alter in any way the configuration > of the server where Drupal runs. Given the constraint that you cannot modify the server, it seems to me that the only way to do this is to mimic a user session via a client script. If you are only adding node then this shouldn't be too hard but it will take several requests and cookie management on the client. The session would look something like: POST login request POST node form submission (repeat node form POST for each node to be created) If you need to modify or delete nodes it becomes quite a bit harder since you will need to find the right node to modify before posting. Personally I would use perl on the client side if I had to do this since the client side tools are richer for perl than php. Now if I had the ability to alter the drupal installation I would use the services module and xmlrpc calls to get the data into drupal. I would still use perl for the xmlrpc client. -Craig From metzlerd at metzlerd.com Fri Feb 20 04:42:44 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Thu, 19 Feb 2009 20:42:44 -0800 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <499BE615.6070803@gmail.com> References: <4998279D.901@gmail.com> <499BE615.6070803@gmail.com> Message-ID: <2BB45BA1-D5DA-4C31-8E5B-3DB3F5E5FBED@metzlerd.com> Hey Paul, Thanks for the sample. I'm assuming that you've gotten what you needed from the dev list here. As it sounds like you got your problem solved. I'm not an expert of Feed API, but I do know XML Parsing, and it would seem that if you were ever to tackle a new feed_api parser, then I've got some code that you might be interested. It's the XML to array conversion code that I alluded to in another thread. I'm hoping to have it published as a contrib in some kind of dev form by the end of the month. I'm busy extracting it from some other code that I've got that isn't really appropriate for API distribution. Let me know if you need any more help. Dave On Feb 18, 2009, at 2:42 AM, Paul Hoza wrote: > uick sample of what the tag looks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090219/6c6ae094/attachment-0001.htm From paulhoza at gmail.com Fri Feb 20 04:53:04 2009 From: paulhoza at gmail.com (Paul Hoza) Date: Thu, 19 Feb 2009 21:53:04 -0700 Subject: [development] Programmatic data importing from JSON source In-Reply-To: <2BB45BA1-D5DA-4C31-8E5B-3DB3F5E5FBED@metzlerd.com> References: <4998279D.901@gmail.com> <499BE615.6070803@gmail.com> <2BB45BA1-D5DA-4C31-8E5B-3DB3F5E5FBED@metzlerd.com> Message-ID: <499E3730.1090106@gmail.com> Hi Dave, Thanks for the tip. I have what amounts to a few half-ish done custom parsers -- each in a varied state of mess. I definitely will keep you offer on-hand in case I go that route ultimately. I did get some good responses (a couple that accidentally ended up off-list), so I'm going to tackle this again tonight. The coffee pot's full of fresh Go Juice, so I'm looking forward to getting this tackled tonight... although I've said that to myself an embarrassing number of times on this project. >_> (For the curious...) I'm currently working on a fresh approach at directly accessing the JSON feed. I'm making a separate PHP script that reads in the feed and runs it through json_decode(). From there, I plan to dissect the object and map all the different key->value sets out to an array I'll feed into drupal_execute(). If this all works as I plan/hope, I'll be able to run this script with cron every day. ...thus are my plans, anyway. Mice didn't make these plans, so their value is currently in question. Thanks for the great feedback so far! I'll report back later so I don't leave the thread hanging. Thanks Dave. Paul David Metzler wrote: > Hey Paul, > > Thanks for the sample. I'm assuming that you've gotten what you > needed from the dev list here. As it sounds like you got your problem > solved. I'm not an expert of Feed API, but I do know XML Parsing, and > it would seem that if you were ever to tackle a new feed_api parser, > then I've got some code that you might be interested. It's the XML to > array conversion code that I alluded to in another thread. I'm hoping > to have it published as a contrib in some kind of dev form by the end > of the month. I'm busy extracting it from some other code that I've > got that isn't really appropriate for API distribution. > > Let me know if you need any more help. > > Dave > > > On Feb 18, 2009, at 2:42 AM, Paul Hoza wrote: > >> uick sample of what the tag looks >> > -- +-----------------------------------------------+ | Paul Hoza | I do: Games, Websites, Multimedia and more. | paul at hoza.net +-----------------------------------------------+ From mfioretti at nexaima.net Fri Feb 20 09:32:09 2009 From: mfioretti at nexaima.net (M. Fioretti) Date: Fri, 20 Feb 2009 10:32:09 +0100 Subject: [development] Conclusion of: Back to Curl-based content generation In-Reply-To: <20090219132516.GK8501@nexaima.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132516.GK8501@nexaima.net> Message-ID: <20090220093209.GC3476@nexaima.net> Hello, all. To save time, I'll answer with only one messages to all the replies which came after the half-rant I sent here yesterday. Please read it all, it isn't that long. I do enough, in public, to support FOSS and related issues like digital rights (cfr http://mfioretti.net) to not worry at all if sometimes I *may* appear as a freeloader with just a "short, self-serving involvement in the community" of one of the many FOSS tools I use. So, no problem on that front, really. Just a passing note that a quick internet search would have definitely proved that *I* wouldn't come here or anywhere else to learn how to spam. I admit that in my *very* first messages I wasn't clear enough, partly because I didn't even know myself what I should exactly ask. What actually frustrated me in all this too long thread, enough to write what I wrote yesterday, is just two things: - honestly, it took too many messages to be told clearly (regardless of manners) that you simply do NOT want to make easier the way I'd like to interact with Drupal, and _why_ you think so. Please note that I'm NOT questioning at all your decision and motives here. I'm just saying "if I had been told all this explicitly the first day, we'd have all saved a lot of time". Maybe this decision and its rationale should be posted on the Drupal website. - regardless of the point above, I have gotten more than one reply where it was evident that the person answering to me simply hadn't bothered to read my message, the one he was replying to, from beginning to end. So, I hope you'll take all this as just a friendly suggestion to pay more attention and in general use the list more effectively in the future. Me, I have nothing to add, and certainly don't want to bicker anymore. Considering all the input I got, it looks that I need to try, at least for those websites where I can ask to change configuration, a command line script which talks remotely, via XML-RPC, to the blogapi module. If somebody can post me privately (**) relevant documentation or, even better, working code samples (Perl, Python, whatever)... thanks a lot in advance. The reason I'm asking is that the blogapi page at drupal.org documents how that code works internally and how it talks to drupal, but I haven't recognized any link to documentation useful to write the _client_ side. Be well, Marco (**) I will unsubscribe really soon, need to focus on other things now. -- Your own civil rights and the quality of your life heavily depend on how software is used *around* you: http://digifreedom.net/node/84 From aldo at caonao.cu Fri Feb 20 16:14:05 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Fri, 20 Feb 2009 11:14:05 -0500 Subject: [development] how to pass arguments to custom php code Message-ID: <200902201114.05328.aldo@caonao.cu> i need to execute som custom php code, but i need take some data from database with NID argument, how can i read the NID from current node??? thanks in advanced -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From andrewberry at sentex.net Thu Feb 19 14:36:42 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Thu, 19 Feb 2009 09:36:42 -0500 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: <1fcccc8a0902190059v4c07e194h145b2d5f1b54de0e@mail.gmail.com> References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> <1fcccc8a0902190059v4c07e194h145b2d5f1b54de0e@mail.gmail.com> Message-ID: <6B8009AD-3D86-4999-AB65-B70D9CFDFB21@sentex.net> On 19-Feb-09, at 3:59 AM, Dipen wrote: > As an API, I think it should return all aliases of a path or should > take an additional parameter like 'all','latest','oldest' depending > on how you want it. But yeah it returns the oldest alias and just > one entry. I seem to remember that unless you do an ORDER BY that the order of returned results are implementation dependent. I can't seem to find anything to back that up other than a few old notes though. So while MySQL returns the first matched result in order of insertion, I think that could change when using some other RDBMS. Anyone have any more info? --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090219/f505f574/attachment.bin From stewsnooze at gmail.com Fri Feb 20 18:01:14 2009 From: stewsnooze at gmail.com (Stewart Robinson) Date: Fri, 20 Feb 2009 18:01:14 +0000 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: <6B8009AD-3D86-4999-AB65-B70D9CFDFB21@sentex.net> References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> <1fcccc8a0902190059v4c07e194h145b2d5f1b54de0e@mail.gmail.com> <6B8009AD-3D86-4999-AB65-B70D9CFDFB21@sentex.net> Message-ID: You just can't trust ordering without using order by. The behaviour is undefined. Indexes can affect the order you get stuff back in aswell as insertion order as you will effectively select positions from the index if you are lucky enough to hit it. Stew On 2/19/09, Andrew Berry wrote: > On 19-Feb-09, at 3:59 AM, Dipen wrote: > >> As an API, I think it should return all aliases of a path or should >> take an additional parameter like 'all','latest','oldest' depending >> on how you want it. But yeah it returns the oldest alias and just >> one entry. > > I seem to remember that unless you do an ORDER BY that the order of > returned results are implementation dependent. I can't seem to find > anything to back that up other than a few old notes though. So while > MySQL returns the first matched result in order of insertion, I think > that could change when using some other RDBMS. > > Anyone have any more info? > > --Andrew -- Sent from my mobile device From damz at prealable.org Fri Feb 20 18:05:53 2009 From: damz at prealable.org (Damien Tournoud) Date: Fri, 20 Feb 2009 19:05:53 +0100 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> Message-ID: On Wed, Feb 18, 2009 at 11:19 PM, Nir Aides wrote: > Hi, > > path_set_alias($path, $alias) inserts a new alias in case there is already > an alias for $path. However drupal_lookup_path() keeps picking up the old > alias. > It makes sense to keep the old alias so links don't break in a website, but > why look up the old alias when generating a URL? > Please see http://drupal.org/node/358315 Damien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090220/c26d2ed5/attachment.htm From Peter at attiks.com Fri Feb 20 18:41:14 2009 From: Peter at attiks.com (Peter Droogmans) Date: Fri, 20 Feb 2009 19:41:14 +0100 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: <6B8009AD-3D86-4999-AB65-B70D9CFDFB21@sentex.net> References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> <1fcccc8a0902190059v4c07e194h145b2d5f1b54de0e@mail.gmail.com> <6B8009AD-3D86-4999-AB65-B70D9CFDFB21@sentex.net> Message-ID: My 2c If I remember correctly from my DB classes, all tables in a relational databases are unordered, you cannot assume an order. My experience is that all databases use table (or insertion) order for simple select statements (like select x from y), but you might get "strange" ordering while using grouping / having clauses. So the safest is to specify the order, you never know if mysql is going to behave differently. Peter -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org] On Behalf Of Andrew Berry Sent: donderdag 19 februari 2009 15:37 To: development at drupal.org Subject: Re: [development] My first post: path_set_alias() and multiple aliases On 19-Feb-09, at 3:59 AM, Dipen wrote: > As an API, I think it should return all aliases of a path or should > take an additional parameter like 'all','latest','oldest' depending > on how you want it. But yeah it returns the oldest alias and just > one entry. I seem to remember that unless you do an ORDER BY that the order of returned results are implementation dependent. I can't seem to find anything to back that up other than a few old notes though. So while MySQL returns the first matched result in order of insertion, I think that could change when using some other RDBMS. Anyone have any more info? --Andrew From andrewberry at sentex.net Fri Feb 20 19:58:47 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Fri, 20 Feb 2009 14:58:47 -0500 Subject: [development] how to pass arguments to custom php code In-Reply-To: <200902201114.05328.aldo@caonao.cu> References: <200902201114.05328.aldo@caonao.cu> Message-ID: On 20-Feb-09, at 11:14 AM, Aldo Martinez Selleras wrote: > i need to execute som custom php code, but i need take some data > from database > with NID argument, how can i read the NID from current node??? http://api.drupal.org/api/function/arg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090220/dd6dae79/attachment.bin From metzlerd at metzlerd.com Sat Feb 21 16:58:10 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Sat, 21 Feb 2009 08:58:10 -0800 Subject: [development] My first post: path_set_alias() and multiple aliases In-Reply-To: References: <5d2328510902181419j3f06a45fo2a40461d00544049@mail.gmail.com> <1fcccc8a0902190059v4c07e194h145b2d5f1b54de0e@mail.gmail.com> <6B8009AD-3D86-4999-AB65-B70D9CFDFB21@sentex.net> Message-ID: <9DF2E27C-97D7-4567-BBDC-1C2FCEC2E5AD@metzlerd.com> Short answer: Yep don't count on the order of anything that doesn't have an order by clause. Longer answer just cause some seem interested: Most DB's (mysql included) will return unordered expressions in the order that they are retrieved, which sometimes equates to order of insertion but not always. All kinds of things can change that. Indexes get use because of data in the where clause. Maintenance activities in some databases will change the order of storage. Some databases will reuse of deleted rows causing the order to be different. Some databases store multiple tables data in the same file (oracle) and this can really get crazy when space gets reused. The biggest real world example of this is that in one of my larger databases, the order of things changed when we exported and re- imported data (to facilitate a character set conversion), which exposed a whole bunch of queries where the unfiltered list seemed to be broken. These were just queries that didn't have order by clauses in the expression. But I've seen query plans change in upgrades of database software also. So while it may seem to work, even across databases, you really shouldn't count on it, not even within a database architecture. Dave On Feb 20, 2009, at 10:41 AM, Peter Droogmans wrote: > My 2c > > If I remember correctly from my DB classes, all tables in a > relational databases are unordered, you cannot assume an order. My > experience is that all databases use table (or insertion) order for > simple select statements (like select x from y), but you might get > "strange" ordering while using grouping / having clauses. So the > safest is to specify the order, you never know if mysql is going to > behave differently. > > Peter > > -----Original Message----- > From: development-bounces at drupal.org [mailto:development- > bounces at drupal.org] On Behalf Of Andrew Berry > Sent: donderdag 19 februari 2009 15:37 > To: development at drupal.org > Subject: Re: [development] My first post: path_set_alias() and > multiple aliases > > On 19-Feb-09, at 3:59 AM, Dipen wrote: > >> As an API, I think it should return all aliases of a path or should >> take an additional parameter like 'all','latest','oldest' depending >> on how you want it. But yeah it returns the oldest alias and just >> one entry. > > I seem to remember that unless you do an ORDER BY that the order of > returned results are implementation dependent. I can't seem to find > anything to back that up other than a few old notes though. So while > MySQL returns the first matched result in order of insertion, I think > that could change when using some other RDBMS. > > Anyone have any more info? > > --Andrew From josh at chapterthree.com Sun Feb 22 18:54:44 2009 From: josh at chapterthree.com (Josh Koenig) Date: Sun, 22 Feb 2009 10:54:44 -0800 Subject: [development] Object Caching in DRUPAL-7? Message-ID: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> Greetings, I'd like to take the community's temperature on developing a global object caching strategy for drupal core 7.0. In effect, this would mean pulling the functionality of advcache module into core, though the code would doubtless be a bit different. This has been previously discussed by Robert Douglass and Steve Rude, and I think both the short-term and strategic value here is clear. As memcached permeates the collective consciousness of the web-development community, and as "cloud" computing becomes more and more prevalent, best practices in architecture increasingly point towards caching full objects whenever possible. This also fits well with Drupal's existing architecture. There are great functional points (e.g. node_load()) to mount this functionality. I'm certain I'm not the only one thinking along these lines. Anyone want to throw out their ideas? cheers -josh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090222/cfb127b1/attachment.htm From hovercrafter at earthlink.net Sun Feb 22 19:10:42 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Sun, 22 Feb 2009 14:10:42 -0500 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> Message-ID: <49A1A332.6090507@earthlink.net> I think this is an awesome idea, especially if we make it optional through settings.php. Example - fully loaded nodes can be cached, but only if there's a node_cache specified in settings.php, so it doesn't break existing stuff (or even the content_type overrides like in advanced cache). I know it would be nice to not have to worry about patching files when a new version does come out, but that's the lazy in me talking. Josh Koenig wrote: > Greetings, > > I'd like to take the community's temperature on developing a global > object caching strategy for drupal core 7.0. In effect, this would > mean pulling the functionality of advcache module into core, though > the code would doubtless be a bit different. > > This has been previously discussed by Robert Douglass and Steve Rude, > and I think both the short-term and strategic value here is clear. As > memcached permeates the collective consciousness of the > web-development community, and as "cloud" computing becomes more and > more prevalent, best practices in architecture increasingly point > towards caching full objects whenever possible. > > This also fits well with Drupal's existing architecture. There are > great functional points (e.g. node_load()) to mount this functionality. > > I'm certain I'm not the only one thinking along these lines. Anyone > want to throw out their ideas? > > cheers > -josh > From catch56 at googlemail.com Sun Feb 22 20:29:29 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Sun, 22 Feb 2009 20:29:29 +0000 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <49A1A332.6090507@earthlink.net> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A1A332.6090507@earthlink.net> Message-ID: There's a patch for node_load() here - http://drupal.org/node/111127 - has been sitting at RTBC for weeks though and just gone stale again. Since terms, users (hopefully, soon) etc. have almost exactly the same code for loading now, it'd be easy to add the same pattern there too, and I was thinking about trying that if node_load() gets in. The new core field API also allows objects to declare themselves as already cached - so the field cache is skipped for those objects and we save filling up memcache bins with the same stuff, so no issues there. However I'm not sure what you mean by a global object caching strategy - actually the same code? Or just parallel APIs? Nedjo Rogers has a patch for the former at http://drupal.org/node/365899 - adding cache_set/get to it wouldn't be hard at all (at least when loading by IDs, which is all we need really). Although I'd be tempted to add the caching in separate patches then unify it all later rather than trying to do both at once. +1, anyway. Nat > > Josh Koenig wrote: > >> Greetings, >> >> I'd like to take the community's temperature on developing a global object >> caching strategy for drupal core 7.0. In effect, this would mean pulling the >> functionality of advcache module into core, though the code would doubtless >> be a bit different. >> >> This has been previously discussed by Robert Douglass and Steve Rude, and >> I think both the short-term and strategic value here is clear. As memcached >> permeates the collective consciousness of the web-development community, and >> as "cloud" computing becomes more and more prevalent, best practices in >> architecture increasingly point towards caching full objects whenever >> possible. >> >> This also fits well with Drupal's existing architecture. There are great >> functional points (e.g. node_load()) to mount this functionality. >> >> I'm certain I'm not the only one thinking along these lines. Anyone want >> to throw out their ideas? >> >> cheers >> -josh >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090222/0dcb67eb/attachment.htm From josh at chapterthree.com Sun Feb 22 21:17:53 2009 From: josh at chapterthree.com (Josh Koenig) Date: Sun, 22 Feb 2009 13:17:53 -0800 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A1A332.6090507@earthlink.net> Message-ID: <223073f60902221317g545b7698sf96e8742a96b9d2a@mail.gmail.com> Thanks for the pointers on where I need to get up to speed! In terms of what I mean by a "global object caching strategy," ideally that means the same code, but at a minimum parallel APIs or methods. Most importantly it should be easy for savvy developers to follow "the Drupal way." Ultimately this is a design pattern thing, where we stop thinking of everything as necessarily coming from a database, and start thinking in terms of using the database as a highly efficient method for pulling up lists of IDs, and then loading the objects that are germane. My initial thoughts are here: http://groups.drupal.org/node/19385 Without object caching this is potentially expensive: think of the difference between a simple view built around specific fields vs one that calls node_load() for each resulting item. However, once you've got your nodes in a memory cloud, it's actually quite a lot faster. Moreover, this follows emerging best-practices for high availablility and scalability. E.g.: http://dev.mysql.com/doc/refman/5.1/en/ha-memcached.html As memcached becomes a commodity service -- e.g. it's trivial to roll out with the latest Debian and CentOS releases -- the upside of having the community put collective brainpower into the best way to utilize these tools (abd bake support into core) is huge. cheers -josh On Sun, Feb 22, 2009 at 12:29 PM, Nathaniel Catchpole < catch56 at googlemail.com> wrote: > There's a patch for node_load() here - http://drupal.org/node/111127 - has > been sitting at RTBC for weeks though and just gone stale again. > > Since terms, users (hopefully, soon) etc. have almost exactly the same code > for loading now, it'd be easy to add the same pattern there too, and I was > thinking about trying that if node_load() gets in. > > The new core field API also allows objects to declare themselves as already > cached - so the field cache is skipped for those objects and we save filling > up memcache bins with the same stuff, so no issues there. > > However I'm not sure what you mean by a global object caching strategy - > actually the same code? Or just parallel APIs? Nedjo Rogers has a patch for > the former at http://drupal.org/node/365899 - adding cache_set/get to it > wouldn't be hard at all (at least when loading by IDs, which is all we need > really). Although I'd be tempted to add the caching in separate patches then > unify it all later rather than trying to do both at once. > > +1, anyway. > > Nat > > > > >> >> Josh Koenig wrote: >> >>> Greetings, >>> >>> I'd like to take the community's temperature on developing a global >>> object caching strategy for drupal core 7.0. In effect, this would mean >>> pulling the functionality of advcache module into core, though the code >>> would doubtless be a bit different. >>> >>> This has been previously discussed by Robert Douglass and Steve Rude, and >>> I think both the short-term and strategic value here is clear. As memcached >>> permeates the collective consciousness of the web-development community, and >>> as "cloud" computing becomes more and more prevalent, best practices in >>> architecture increasingly point towards caching full objects whenever >>> possible. >>> >>> This also fits well with Drupal's existing architecture. There are great >>> functional points (e.g. node_load()) to mount this functionality. >>> >>> I'm certain I'm not the only one thinking along these lines. Anyone want >>> to throw out their ideas? >>> >>> cheers >>> -josh >>> >>> > -- -------------------- Josh Koenig, Partner & CTO http://www.chapterthree.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090222/79f24a72/attachment-0001.htm From cog.rusty at gmail.com Mon Feb 23 04:47:41 2009 From: cog.rusty at gmail.com (Cog Rusty) Date: Mon, 23 Feb 2009 06:47:41 +0200 Subject: [development] Conclusion of: Back to Curl-based content generation In-Reply-To: <20090220093209.GC3476@nexaima.net> References: <20090219094709.GH3116@nexaima.net> <20090219120315.GH8501@nexaima.net> <20090219072329.np7al0qxyr7wo4kg@mail.progw.org> <20090219132516.GK8501@nexaima.net> <20090220093209.GC3476@nexaima.net> Message-ID: On Fri, Feb 20, 2009 at 11:32 AM, M. Fioretti wrote: ...snip... > - honestly, it took too many messages to be told clearly (regardless > of manners) that you simply do NOT want to make easier the way I'd > like to interact with Drupal, and _why_ you think so. Please note > that I'm NOT questioning at all your decision and motives here. I'm > just saying "if I had been told all this explicitly the first day, > we'd have all saved a lot of time". Maybe this decision and its > rationale should be posted on the Drupal website. ...snip... Marco, the issue is not the people who do not want to do what you are looking for. There are things which all of us do not want to do,.and there is little that anyone can do about that. The issue is to find (or convert?) people who want to do what you are looking for. The rest is just talk. From drupal at reyero.net Mon Feb 23 12:13:18 2009 From: drupal at reyero.net (Jose A. Reyero) Date: Mon, 23 Feb 2009 13:13:18 +0100 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A1A332.6090507@earthlink.net> Message-ID: <49A292DE.7020806@reyero.net> Very good point, Catch, I think this global object caching is a good idea, but for it to be really useful we need that global object handling too (Nedjo's patch, http://drupal.org/node/365899 ), and in general we need some object API. Once we have that 'object API' in place adding some uniform caching for objects would be much easier. Then node_load, user_load, etc can be just wrappers for the drupal_load() function and we can have a really functional cache, which also invalidates cached objects when a 'write' operation is done. Add in drupal_load_multiple() and we have a really powerful thing. So I think we should move on first with that patch, then adding the global caching feature will be trivial. Nathaniel Catchpole wrote: > There's a patch for node_load() here - http://drupal.org/node/111127 - > has been sitting at RTBC for weeks though and just gone stale again. > > Since terms, users (hopefully, soon) etc. have almost exactly the same > code for loading now, it'd be easy to add the same pattern there too, > and I was thinking about trying that if node_load() gets in. > > The new core field API also allows objects to declare themselves as > already cached - so the field cache is skipped for those objects and > we save filling up memcache bins with the same stuff, so no issues there. > > However I'm not sure what you mean by a global object caching strategy > - actually the same code? Or just parallel APIs? Nedjo Rogers has a > patch for the former at http://drupal.org/node/365899 - adding > cache_set/get to it wouldn't be hard at all (at least when loading by > IDs, which is all we need really). Although I'd be tempted to add the > caching in separate patches then unify it all later rather than trying > to do both at once. > > +1, anyway. > > Nat > > > > > Josh Koenig wrote: > > Greetings, > > I'd like to take the community's temperature on developing a > global object caching strategy for drupal core 7.0. In effect, > this would mean pulling the functionality of advcache module > into core, though the code would doubtless be a bit different. > > This has been previously discussed by Robert Douglass and > Steve Rude, and I think both the short-term and strategic > value here is clear. As memcached permeates the collective > consciousness of the web-development community, and as "cloud" > computing becomes more and more prevalent, best practices in > architecture increasingly point towards caching full objects > whenever possible. > > This also fits well with Drupal's existing architecture. There > are great functional points (e.g. node_load()) to mount this > functionality. > > I'm certain I'm not the only one thinking along these lines. > Anyone want to throw out their ideas? > > cheers > -josh > > From aldo at caonao.cu Mon Feb 23 18:59:06 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Mon, 23 Feb 2009 13:59:06 -0500 Subject: [development] modify the "add comment" in links Message-ID: <200902231359.06803.aldo@caonao.cu> how can i change the link title "Add comment" for Reply, but only for forum and blog posts?? must be with theme() ??? thanks in advanced -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From aldo at caonao.cu Mon Feb 23 19:01:31 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Mon, 23 Feb 2009 14:01:31 -0500 Subject: [development] custom comment template Message-ID: <200902231401.31764.aldo@caonao.cu> may i create a custom template for specific node type comments?? -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From michael at favias.org Mon Feb 23 19:21:51 2009 From: michael at favias.org (Michael Favia) Date: Mon, 23 Feb 2009 13:21:51 -0600 Subject: [development] custom comment template In-Reply-To: <200902231401.31764.aldo@caonao.cu> References: <200902231401.31764.aldo@caonao.cu> Message-ID: <49A2F74F.2080807@favias.org> Aldo Martinez Selleras wrote: > may i create a custom template for specific node type comments?? > http://drupal.org/node/223440 - comment-{type}.tpl.php This is not a support list this is for development only please use the appropriate list or IRC for your support questions. -mf From earnie at users.sourceforge.net Mon Feb 23 20:03:47 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 23 Feb 2009 15:03:47 -0500 Subject: [development] modify the "add comment" in links In-Reply-To: <200902231359.06803.aldo@caonao.cu> References: <200902231359.06803.aldo@caonao.cu> Message-ID: <20090223150347.hsryygul0h4o84wc@mail.progw.org> Quoting Aldo Martinez Selleras : > how can i change the link title "Add comment" for Reply, but only for forum > and blog posts?? > http://api.drupal.org/api/function/hook_form_alter -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From drewish at katherinehouse.com Mon Feb 23 20:23:46 2009 From: drewish at katherinehouse.com (andrew morton) Date: Mon, 23 Feb 2009 12:23:46 -0800 Subject: [development] modify the "add comment" in links In-Reply-To: <20090223150347.hsryygul0h4o84wc@mail.progw.org> References: <200902231359.06803.aldo@caonao.cu> <20090223150347.hsryygul0h4o84wc@mail.progw.org> Message-ID: On Mon, Feb 23, 2009 at 12:03 PM, Earnie Boyd wrote: > Quoting Aldo Martinez Selleras : > >> how can i change the link title "Add comment" for Reply, but only for >> forum >> and blog posts?? >> > > http://api.drupal.org/api/function/hook_form_alter Actually I think the correct choice would be hook_link_alter(): http://api.drupal.org/api/function/hook_link_alter/6 From earnie at users.sourceforge.net Mon Feb 23 21:11:02 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 23 Feb 2009 16:11:02 -0500 Subject: [development] modify the "add comment" in links In-Reply-To: References: <200902231359.06803.aldo@caonao.cu> <20090223150347.hsryygul0h4o84wc@mail.progw.org> Message-ID: <20090223161102.kpdippuro00wgcow@mail.progw.org> Quoting andrew morton : > On Mon, Feb 23, 2009 at 12:03 PM, Earnie Boyd > wrote: >> Quoting Aldo Martinez Selleras : >> >>> how can i change the link title "Add comment" for Reply, but only for >>> forum >>> and blog posts?? >>> >> >> http://api.drupal.org/api/function/hook_form_alter > > Actually I think the correct choice would be hook_link_alter(): > http://api.drupal.org/api/function/hook_link_alter/6 > Will that change the #value of the submit button? -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From drewish at katherinehouse.com Mon Feb 23 23:13:57 2009 From: drewish at katherinehouse.com (andrew morton) Date: Mon, 23 Feb 2009 15:13:57 -0800 Subject: [development] modify the "add comment" in links In-Reply-To: <20090223161102.kpdippuro00wgcow@mail.progw.org> References: <200902231359.06803.aldo@caonao.cu> <20090223150347.hsryygul0h4o84wc@mail.progw.org> <20090223161102.kpdippuro00wgcow@mail.progw.org> Message-ID: On Mon, Feb 23, 2009 at 1:11 PM, Earnie Boyd wrote: > Quoting andrew morton : > >> On Mon, Feb 23, 2009 at 12:03 PM, Earnie Boyd >> wrote: >>> >>> Quoting Aldo Martinez Selleras : >>> >>>> how can i change the link title "Add comment" for Reply, but only for >>>> forum >>>> and blog posts?? >>>> >>> >>> http://api.drupal.org/api/function/hook_form_alter >> >> Actually I think the correct choice would be hook_link_alter(): >> http://api.drupal.org/api/function/hook_link_alter/6 >> > > Will that change the #value of the submit button? I might have misread his comment. I thought he wanted to change the links at the bottom of the nodes rather than the button labels. If it was the later than you'd be correct. andrew From aldo at caonao.cu Tue Feb 24 12:18:31 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Tue, 24 Feb 2009 07:18:31 -0500 Subject: [development] modify the "add comment" in links In-Reply-To: References: <200902231359.06803.aldo@caonao.cu> <20090223161102.kpdippuro00wgcow@mail.progw.org> Message-ID: <200902240718.31219.aldo@caonao.cu> yes, i just want to change the links at the bottom of the nodes, but only for forum and blog content type, and i think the hook_link_alter it's the better option... i'm studing the hook for later apply but, i have a question, can't i change the title value from custom forum template ?? i mean, from tpl.php file, i can't do that? -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From fofovi72 at gmail.com Tue Feb 24 13:58:44 2009 From: fofovi72 at gmail.com (Sam Golchi FOLI-AWLI) Date: Tue, 24 Feb 2009 19:28:44 +0530 Subject: [development] modify the "add comment" in links In-Reply-To: <200902240718.31219.aldo@caonao.cu> References: <200902231359.06803.aldo@caonao.cu> <20090223161102.kpdippuro00wgcow@mail.progw.org> <200902240718.31219.aldo@caonao.cu> Message-ID: <870d8d110902240558s727582d7g8a3391bae47229c2@mail.gmail.com> Yes you can change the title of the node from your template file (the final view of your node is generated in the template file). Cheers 2009/2/24 Aldo Martinez Selleras > yes, i just want to change the links at the bottom of the nodes, but only > for > forum and blog content type, and i think the hook_link_alter it's the > better > option... i'm studing the hook for later apply > > but, i have a question, can't i change the title value from custom forum > template ?? i mean, from tpl.php file, i can't do that? > > -- > ---------------------- > Aldo Martinez Selleras > Especialista en Telematica > CITMATEL GND Camaguey > Tel: 53 32 291661 > Linux User #364356 > -- FOLI-AWLI Mawusee Komla (Sam) http://golchi.blogspot.com/ http://golchitech.blogspot.com/ Le monde en grandissant de jour en jour devient plus petit... ----- Ne m'envoyez pas de fichiers attach?s au format Micro$oft (.DOC, .PPT) svp! Merci de lire http://www.gnu.org/philosophy/no-word-attachments.html Mes format pr?f?r?s : .PDF, ODF, .TXT, ABW Merci d'ajouter ce texte ? votre signature. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/33424267/attachment.htm From aldo at caonao.cu Tue Feb 24 16:19:14 2009 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Tue, 24 Feb 2009 11:19:14 -0500 Subject: [development] modify the "add comment" in links In-Reply-To: <870d8d110902240558s727582d7g8a3391bae47229c2@mail.gmail.com> References: <200902231359.06803.aldo@caonao.cu> <200902240718.31219.aldo@caonao.cu> <870d8d110902240558s727582d7g8a3391bae47229c2@mail.gmail.com> Message-ID: <200902241119.14801.aldo@caonao.cu> isn't the title node form value, it the title property from link array what i want to change!!! '#title' => t('Add Comment'), this is in the array in comment.module, but i want in the forum posts that value change and set to t('Reply') -- ---------------------- Aldo Martinez Selleras Especialista en Telematica CITMATEL GND Camaguey Tel: 53 32 291661 Linux User #364356 From paolomainardi at gmail.com Tue Feb 24 16:31:05 2009 From: paolomainardi at gmail.com (Paolo Mainardi) Date: Tue, 24 Feb 2009 17:31:05 +0100 Subject: [development] modify the "add comment" in links In-Reply-To: <200902241119.14801.aldo@caonao.cu> References: <200902231359.06803.aldo@caonao.cu> <200902240718.31219.aldo@caonao.cu> <870d8d110902240558s727582d7g8a3391bae47229c2@mail.gmail.com> <200902241119.14801.aldo@caonao.cu> Message-ID: On Tue, Feb 24, 2009 at 5:19 PM, Aldo Martinez Selleras wrote: > isn't the title node form value, it the title property from link array what > i > want to change!!! > > '#title' => t('Add Comment'), > > this is in the array in comment.module, but i want in the forum posts that > value change and set to t('Reply') > > -- hook_form_alter !!!!! -- Paolo Mainardi Vice Presidente Assoc.ILDN (http://www.ildn.net) Blog: http://www.paolomainardi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/f4cdbd06/attachment.htm From merlin at logrus.com Tue Feb 24 16:36:27 2009 From: merlin at logrus.com (Earl Miles) Date: Tue, 24 Feb 2009 08:36:27 -0800 Subject: [development] modify the "add comment" in links In-Reply-To: References: <200902231359.06803.aldo@caonao.cu> <200902240718.31219.aldo@caonao.cu> <870d8d110902240558s727582d7g8a3391bae47229c2@mail.gmail.com> <200902241119.14801.aldo@caonao.cu> Message-ID: <49A4220B.70209@logrus.com> Please take this conversation to the support list or the forums, it is inappropriate for this list. Thanks. From domenic at workhabit.com Tue Feb 24 19:43:03 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Tue, 24 Feb 2009 11:43:03 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: Message-ID: Hey all, I've been using Komodo for a while and while I like its built-in support for xdebug (breakpoints, stepping, stack trace, the whole enchilada) and code intel. But I hate it because it's a terrible resource hog. I've been using Coda for a couple weeks, and although it's extremely pretty, it lacks a few pretty key things, xdebug support being the main one. I used TextMate before Komodo and am thinking of going back, but I really would hate to live without debugging/xdebug support. Also, I've tried Eclipse and don't like it. Thoughts? TextMate + some magic to support xdebug maybe? -Dom From hovercrafter at earthlink.net Tue Feb 24 19:45:59 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Tue, 24 Feb 2009 14:45:59 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: Message-ID: <49A44E77.8010307@earthlink.net> Have you given NetBeans 6.54 a try yet? I've switched from Eclipse to it at the beginning of the month and haven't looked back. Jamie Holly Domenic Santangelo wrote: > Hey all, > > I've been using Komodo for a while and while I like its built-in > support for xdebug (breakpoints, stepping, stack trace, the whole > enchilada) and code intel. But I hate it because it's a terrible > resource hog. I've been using Coda for a couple weeks, and although > it's extremely pretty, it lacks a few pretty key things, xdebug > support being the main one. I used TextMate before Komodo and am > thinking of going back, but I really would hate to live without > debugging/xdebug support. Also, I've tried Eclipse and don't like it. > > Thoughts? TextMate + some magic to support xdebug maybe? > > -Dom > > From jim at rootyhollow.com Tue Feb 24 19:48:43 2009 From: jim at rootyhollow.com (Jim Taylor) Date: Tue, 24 Feb 2009 14:48:43 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: Message-ID: <2f2379e70902241148s6399ad3fpf7ebad3bf0ec77e9@mail.gmail.com> Also switched to NetBeans and am loving it On Tue, Feb 24, 2009 at 2:43 PM, Domenic Santangelo wrote: > Hey all, > > I've been using Komodo for a while and while I like its built-in > support for xdebug (breakpoints, stepping, stack trace, the whole > enchilada) and code intel. But I hate it because it's a terrible > resource hog. I've been using Coda for a couple weeks, and although > it's extremely pretty, it lacks a few pretty key things, xdebug > support being the main one. I used TextMate before Komodo and am > thinking of going back, but I really would hate to live without > debugging/xdebug support. Also, I've tried Eclipse and don't like it. > > Thoughts? TextMate + some magic to support xdebug maybe? > > -Dom > -- Jim Taylor Rooty Hollow LLC, Owner jim at rootyhollow.com www.rootyhollow.com (614) 886-5530 Twitter: jalama Linkedin: http://www.linkedin.com/in/rootyhollow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/8a1a380b/attachment-0001.htm From anthony at thrillist.com Tue Feb 24 19:50:05 2009 From: anthony at thrillist.com (Anthony Wlodarski) Date: Tue, 24 Feb 2009 11:50:05 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <2f2379e70902241148s6399ad3fpf7ebad3bf0ec77e9@mail.gmail.com> Message-ID: You make me want to stop using VIM for about and hour and try it. -Anthony -- Anthony Wlodarski www.thrillist.com Web Applications Developer 568 Broadway Ste. 605 New York, NY, 10012 (o) 646.786.1944 ________________________________ From: Jim Taylor Reply-To: Date: Tue, 24 Feb 2009 11:48:43 -0800 To: Subject: Re: [development] Welcome to the "development" mailing list Also switched to NetBeans and am loving it On Tue, Feb 24, 2009 at 2:43 PM, Domenic Santangelo wrote: Hey all, I've been using Komodo for a while and while I like its built-in support for xdebug (breakpoints, stepping, stack trace, the whole enchilada) and code intel. But I hate it because it's a terrible resource hog. I've been using Coda for a couple weeks, and although it's extremely pretty, it lacks a few pretty key things, xdebug support being the main one. I used TextMate before Komodo and am thinking of going back, but I really would hate to live without debugging/xdebug support. Also, I've tried Eclipse and don't like it. Thoughts? TextMate + some magic to support xdebug maybe? -Dom -- Jim Taylor Rooty Hollow LLC, Owner jim at rootyhollow.com www.rootyhollow.com (614) 886-5530 Twitter: jalama Linkedin: http://www.linkedin.com/in/rootyhollow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/9c52879d/attachment.htm From kb at 2bits.com Tue Feb 24 19:54:12 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Tue, 24 Feb 2009 14:54:12 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: <2f2379e70902241148s6399ad3fpf7ebad3bf0ec77e9@mail.gmail.com> Message-ID: <4a9fdc630902241154w3be78242qcf91249216c22464@mail.gmail.com> Oh, you can use xdebug with Vim too ... See here http://2bits.com/articles/developing-tracing-and-debugging-drupal.html On Tue, Feb 24, 2009 at 2:50 PM, Anthony Wlodarski wrote: > You make me want to stop using VIM for about and hour and try it. > > -Anthony > -- > Anthony Wlodarski > www.thrillist.com > Web Applications Developer > 568 Broadway Ste. 605 > New York, NY, 10012 > (o) 646.786.1944 > > > ------------------------------ > *From: *Jim Taylor > *Reply-To: * > *Date: *Tue, 24 Feb 2009 11:48:43 -0800 > *To: * > *Subject: *Re: [development] Welcome to the "development" mailing list > > > Also switched to NetBeans and am loving it > > On Tue, Feb 24, 2009 at 2:43 PM, Domenic Santangelo > wrote: > > Hey all, > > I've been using Komodo for a while and while I like its built-in > support for xdebug (breakpoints, stepping, stack trace, the whole > enchilada) and code intel. But I hate it because it's a terrible > resource hog. I've been using Coda for a couple weeks, and although > it's extremely pretty, it lacks a few pretty key things, xdebug > support being the main one. I used TextMate before Komodo and am > thinking of going back, but I really would hate to live without > debugging/xdebug support. Also, I've tried Eclipse and don't like it. > > Thoughts? TextMate + some magic to support xdebug maybe? > > -Dom > > > > > -- > Jim Taylor > Rooty Hollow LLC, Owner > jim at rootyhollow.com > www.rootyhollow.com > (614) 886-5530 > > Twitter: jalama > Linkedin: http://www.linkedin.com/in/rootyhollow > > -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/3bf1d37d/attachment.htm From michael at favias.org Tue Feb 24 19:57:09 2009 From: michael at favias.org (Michael Favia) Date: Tue, 24 Feb 2009 13:57:09 -0600 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: Message-ID: <49A45115.4090002@favias.org> Domenic Santangelo wrote: > Thoughts? TextMate + some magic to support xdebug maybe? > I know you said you've tried eclipse and don't like it but I have found Eclipse Ganymede + PDT 2.0 (with new caching support) + (new mainline SVN support) + ZendDebugger about the best development environment I have ever touched for PHP. Code completion, collaboration, live debugging with variable substitution, etc. There is a small trick to matching up module vendor branches so you dont spend time doing the SVN/CVS shuffle but nothing too difficult. -mf From joe at triangleparkcreative.com Tue Feb 24 19:59:35 2009 From: joe at triangleparkcreative.com (Joe Shindelar) Date: Tue, 24 Feb 2009 13:59:35 -0600 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A45115.4090002@favias.org> References: <49A45115.4090002@favias.org> Message-ID: <4AB662E1-9D06-4537-8A83-384AB7BD5C44@triangleparkcreative.com> I've been using Textmate + MacGDBp for a while and really liking it. http://www.bluestatic.org/software/macgdbp/ I've tried a few other IDE's but can't ever seem to pull myself away from Textmate for more than a few days. Joe Shindelar On Feb 24, 2009, at 1:57 PM, Michael Favia wrote: > Domenic Santangelo wrote: >> Thoughts? TextMate + some magic to support xdebug maybe? >> From starbow at citris-uc.org Tue Feb 24 19:55:19 2009 From: starbow at citris-uc.org (Tao Starbow) Date: Tue, 24 Feb 2009 11:55:19 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A44E77.8010307@earthlink.net> References: <49A44E77.8010307@earthlink.net> Message-ID: <49A450A7.4040103@citris-uc.org> What pulled you to NetBeans over Eclipse? Tao Jamie Holly wrote: > Have you given NetBeans 6.54 a try yet? I've switched from Eclipse to > it at the beginning of the month and haven't looked back. > > Jamie Holly > > > > > Domenic Santangelo wrote: >> Hey all, >> >> I've been using Komodo for a while and while I like its built-in >> support for xdebug (breakpoints, stepping, stack trace, the whole >> enchilada) and code intel. But I hate it because it's a terrible >> resource hog. I've been using Coda for a couple weeks, and although >> it's extremely pretty, it lacks a few pretty key things, xdebug >> support being the main one. I used TextMate before Komodo and am >> thinking of going back, but I really would hate to live without >> debugging/xdebug support. Also, I've tried Eclipse and don't like it. >> >> Thoughts? TextMate + some magic to support xdebug maybe? >> >> -Dom >> >> From matt at aleph-null.tv Tue Feb 24 20:25:56 2009 From: matt at aleph-null.tv (Matt) Date: Tue, 24 Feb 2009 14:25:56 -0600 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <4AB662E1-9D06-4537-8A83-384AB7BD5C44@triangleparkcreative.com> References: <49A45115.4090002@favias.org> <4AB662E1-9D06-4537-8A83-384AB7BD5C44@triangleparkcreative.com> Message-ID: <70fbbb000902241225t281f2709sb607e21ca11be9c@mail.gmail.com> Wow... I've been working on similar support for TextMate/XDebug for a while. But MacGDBp looks like exactly that! I'll have to try it. Off hand, will it work for local (non server-based) debugging? Matt On Tue, Feb 24, 2009 at 1:59 PM, Joe Shindelar wrote: > I've been using Textmate + MacGDBp for a while and really liking it. > > http://www.bluestatic.org/software/macgdbp/ > > I've tried a few other IDE's but can't ever seem to pull myself away from > Textmate for more than a few days. > > Joe Shindelar > > On Feb 24, 2009, at 1:57 PM, Michael Favia wrote: > >> Domenic Santangelo wrote: >>> >>> Thoughts? TextMate + some magic to support xdebug maybe? >>> > > -- Matt Butcher http://querypath.org http://technosophos.com From joe at triangleparkcreative.com Tue Feb 24 20:36:18 2009 From: joe at triangleparkcreative.com (Joe Shindelar) Date: Tue, 24 Feb 2009 14:36:18 -0600 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <70fbbb000902241225t281f2709sb607e21ca11be9c@mail.gmail.com> References: <49A45115.4090002@favias.org> <4AB662E1-9D06-4537-8A83-384AB7BD5C44@triangleparkcreative.com> <70fbbb000902241225t281f2709sb607e21ca11be9c@mail.gmail.com> Message-ID: <69D4732D-969E-4E1A-935C-9E624FDBB694@triangleparkcreative.com> I've been using it in combination with MAMP on my machine if that's what you're wondering. Otherwise I'm not really sure as that's my only experience with it. Joe Shindelar On Feb 24, 2009, at 2:25 PM, Matt wrote: > Wow... I've been working on similar support for TextMate/XDebug for a > while. But MacGDBp looks like exactly that! I'll have to try it. > > Off hand, will it work for local (non server-based) debugging? > > Matt > > > On Tue, Feb 24, 2009 at 1:59 PM, Joe Shindelar > wrote: >> I've been using Textmate + MacGDBp for a while and really liking it. >> >> http://www.bluestatic.org/software/macgdbp/ >> >> I've tried a few other IDE's but can't ever seem to pull myself >> away from >> Textmate for more than a few days. >> >> Joe Shindelar >> >> On Feb 24, 2009, at 1:57 PM, Michael Favia wrote: >> >>> Domenic Santangelo wrote: >>>> >>>> Thoughts? TextMate + some magic to support xdebug maybe? >>>> >> >> > > -- > Matt Butcher > http://querypath.org > http://technosophos.com From hovercrafter at earthlink.net Tue Feb 24 20:40:23 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Tue, 24 Feb 2009 15:40:23 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A450A7.4040103@citris-uc.org> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> Message-ID: <49A45B37.7000401@earthlink.net> Much less of a resource hog was the first big thing I noticed. Also the support for CSS and JS in NetBeans was a biggie. Having code completion on JQuery has been a life saved. I tried getting it to work with Aptana installed in Eclipse but never could. But the biggest benefit came a couple days after I started testing it out. I found the Drupal plugin for NetBeans: https://nbdrupalsupport.dev.java.net/ Now coding is that much more streamlined. No more going through and manually creating .module and .info files. Can't remember a hook? It adds a hook palette in so you got them all right there. It did take a little getting used to. For example, if I want to go to a function declaration I can no longer hit F3. Now I control-click it. Little things like that, but once I got used to it I have been very happy. Jamie Holly Tao Starbow wrote: > What pulled you to NetBeans over Eclipse? > > Tao > > Jamie Holly wrote: > > Have you given NetBeans 6.54 a try yet? I've switched from Eclipse to > > it at the beginning of the month and haven't looked back. > > > > Jamie Holly > > > > > > > > > > Domenic Santangelo wrote: > >> Hey all, > >> > >> I've been using Komodo for a while and while I like its built-in > >> support for xdebug (breakpoints, stepping, stack trace, the whole > >> enchilada) and code intel. But I hate it because it's a terrible > >> resource hog. I've been using Coda for a couple weeks, and although > >> it's extremely pretty, it lacks a few pretty key things, xdebug > >> support being the main one. I used TextMate before Komodo and am > >> thinking of going back, but I really would hate to live without > >> debugging/xdebug support. Also, I've tried Eclipse and don't like it. > >> > >> Thoughts? TextMate + some magic to support xdebug maybe? > >> > >> -Dom > >> > >> > > From donald at fane.com Tue Feb 24 20:40:18 2009 From: donald at fane.com (donald at fane.com) Date: Tue, 24 Feb 2009 13:40:18 -0700 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <4a9fdc630902241154w3be78242qcf91249216c22464@mail.gmail.com> References: <2f2379e70902241148s6399ad3fpf7ebad3bf0ec77e9@mail.gmail.com> <4a9fdc630902241154w3be78242qcf91249216c22464@mail.gmail.com> Message-ID: <20090224134018.iurib5s8rowk08gg@webmail.fane.com> You can use Notepad++ with xdebug, but I wouldn't unless I was forced. Still, phpEd is the best $200 I've ever spent. -Don- Quoting Khalid Baheyeldin : > Oh, you can use xdebug with Vim too ... > > See here > http://2bits.com/articles/developing-tracing-and-debugging-drupal.html > > On Tue, Feb 24, 2009 at 2:50 PM, Anthony Wlodarski > wrote: > >> You make me want to stop using VIM for about and hour and try it. >> >> -Anthony >> -- >> Anthony Wlodarski >> www.thrillist.com >> Web Applications Developer >> 568 Broadway Ste. 605 >> New York, NY, 10012 >> (o) 646.786.1944 >> >> >> ------------------------------ >> *From: *Jim Taylor >> *Reply-To: * >> *Date: *Tue, 24 Feb 2009 11:48:43 -0800 >> *To: * >> *Subject: *Re: [development] Welcome to the "development" mailing list >> >> >> Also switched to NetBeans and am loving it >> >> On Tue, Feb 24, 2009 at 2:43 PM, Domenic Santangelo >> wrote: >> >> Hey all, >> >> I've been using Komodo for a while and while I like its built-in >> support for xdebug (breakpoints, stepping, stack trace, the whole >> enchilada) and code intel. But I hate it because it's a terrible >> resource hog. I've been using Coda for a couple weeks, and although >> it's extremely pretty, it lacks a few pretty key things, xdebug >> support being the main one. I used TextMate before Komodo and am >> thinking of going back, but I really would hate to live without >> debugging/xdebug support. Also, I've tried Eclipse and don't like it. >> >> Thoughts? TextMate + some magic to support xdebug maybe? >> >> -Dom >> >> >> >> >> -- >> Jim Taylor >> Rooty Hollow LLC, Owner >> jim at rootyhollow.com >> www.rootyhollow.com >> (614) 886-5530 >> >> Twitter: jalama >> Linkedin: http://www.linkedin.com/in/rootyhollow >> >> > > > -- > Khalid M. Baheyeldin > 2bits.com, Inc. > http://2bits.com > Drupal optimization, development, customization and consulting. > Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra > Simplicity is the ultimate sophistication. -- Leonardo da Vinci > From mike at mikeyp.net Tue Feb 24 20:40:24 2009 From: mike at mikeyp.net (Michael Prasuhn) Date: Tue, 24 Feb 2009 12:40:24 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A44E77.8010307@earthlink.net> References: <49A44E77.8010307@earthlink.net> Message-ID: <79531053-B817-4755-889F-EFDBCA9CFA0D@mikeyp.net> Make sure you grab the NetBeans Drupal plugin https://nbdrupalsupport.dev.java.net/ -Mike On Feb 24, 2009, at 11:45 AM, Jamie Holly wrote: > Have you given NetBeans 6.54 a try yet? I've switched from Eclipse > to it at the beginning of the month and haven't looked back. > > Jamie Holly __________________ Michael Prasuhn 503.488.5433 office 714.356.0168 cell 503.661.7574 home mike at mikeyp.net http://mikeyp.net From victorkane at gmail.com Tue Feb 24 21:14:32 2009 From: victorkane at gmail.com (Victor Kane) Date: Tue, 24 Feb 2009 19:14:32 -0200 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A45115.4090002@favias.org> References: <49A45115.4090002@favias.org> Message-ID: This is one of my favorites; but my everyday real environment is KDE Dolphin (or else Konqueror in "midnight commander" mode) set up to use GVim as editor for *.php, *.inc *.module... Take a look at the various tools and the way I set them up here: Viva Konqueror! http://awebfactory.com.ar/node/91 Konqueror and Vim 7 as IDE http://awebfactory.com.ar/node/95 (here there is a tiny screenshot of TList being used as a function/object browser in php and in ruby) Even though I love Eclipse PDT, etc., I find myself actually using the Konqueror setup on an every day basis (Konqueror sometimes replaced with the more lithe Dolphin). The advantage of the KDE file managers is that they double as SFTP / SCP / FTP clients. Victor Kane http://awebfactory.com.ar On Tue, Feb 24, 2009 at 5:57 PM, Michael Favia wrote: > Domenic Santangelo wrote: > >> Thoughts? TextMate + some magic to support xdebug maybe? >> >> > I know you said you've tried eclipse and don't like it but I have found > Eclipse Ganymede + PDT 2.0 (with new caching support) + (new mainline SVN > support) + ZendDebugger about the best development environment I have ever > touched for PHP. Code completion, collaboration, live debugging with > variable substitution, etc. There is a small trick to matching up module > vendor branches so you dont spend time doing the SVN/CVS shuffle but nothing > too difficult. -mf > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/c0b54859/attachment.htm From jim at rootyhollow.com Tue Feb 24 20:33:11 2009 From: jim at rootyhollow.com (Jim Taylor) Date: Tue, 24 Feb 2009 15:33:11 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A450A7.4040103@citris-uc.org> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> Message-ID: <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> Kept having "buggy" issues with Eclipse, memory issues, losing features, etc... I had to re-download PDT a couple of times, finally I just gave up. After I saw NetBeans PHP support talked about in Site Point, I pulled the trigger. Functionally, I think it's much and more intuitive out of the box. If you make heavy use of task list, the task scanner can really bog Net Beans down, but you can simply close it. As an added bonus it has great CSS support. :) I agree I would use VIM if I had the patience, but I grew up in the Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow wrote: > What pulled you to NetBeans over Eclipse? > > Tao > > > Jamie Holly wrote: > >> Have you given NetBeans 6.54 a try yet? I've switched from Eclipse to it >> at the beginning of the month and haven't looked back. >> >> Jamie Holly >> >> >> >> >> Domenic Santangelo wrote: >> >>> Hey all, >>> >>> I've been using Komodo for a while and while I like its built-in >>> support for xdebug (breakpoints, stepping, stack trace, the whole >>> enchilada) and code intel. But I hate it because it's a terrible >>> resource hog. I've been using Coda for a couple weeks, and although >>> it's extremely pretty, it lacks a few pretty key things, xdebug >>> support being the main one. I used TextMate before Komodo and am >>> thinking of going back, but I really would hate to live without >>> debugging/xdebug support. Also, I've tried Eclipse and don't like it. >>> >>> Thoughts? TextMate + some magic to support xdebug maybe? >>> >>> -Dom >>> >>> >>> >> -- Jim Taylor Rooty Hollow LLC, Owner jim at rootyhollow.com www.rootyhollow.com (614) 886-5530 Twitter: jalama Linkedin: http://www.linkedin.com/in/rootyhollow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/e1cb1dcc/attachment.htm From starbow at citris-uc.org Tue Feb 24 22:18:24 2009 From: starbow at citris-uc.org (Tao Starbow) Date: Tue, 24 Feb 2009 14:18:24 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> Message-ID: <49A47230.6090500@citris-uc.org> Wow, having a working outline for javascript is really nice. Netbeans could grow on me. Tao Jim Taylor wrote: > Kept having "buggy" issues with Eclipse, memory issues, losing > features, etc... I had to re-download PDT a couple of times, finally > I just gave up. After I saw NetBeans PHP support talked about in Site > Point, I pulled the trigger. Functionally, I think it's much and more > intuitive out of the box. If you make heavy use of task list, the > task scanner can really bog Net Beans down, but you can simply close > it. As an added bonus it has great CSS support. :) > > I agree I would use VIM if I had the patience, but I grew up in the > Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) > > On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow > wrote: > > What pulled you to NetBeans over Eclipse? > > Tao > > > Jamie Holly wrote: > > Have you given NetBeans 6.54 a try yet? I've switched from > Eclipse to it at the beginning of the month and haven't looked > back. > > Jamie Holly > > > > > Domenic Santangelo wrote: > > Hey all, > > I've been using Komodo for a while and while I like its > built-in > support for xdebug (breakpoints, stepping, stack trace, > the whole > enchilada) and code intel. But I hate it because it's a > terrible > resource hog. I've been using Coda for a couple weeks, and > although > it's extremely pretty, it lacks a few pretty key things, > xdebug > support being the main one. I used TextMate before Komodo > and am > thinking of going back, but I really would hate to live > without > debugging/xdebug support. Also, I've tried Eclipse and > don't like it. > > Thoughts? TextMate + some magic to support xdebug maybe? > > -Dom > > > > > > > -- > Jim Taylor > Rooty Hollow LLC, Owner > jim at rootyhollow.com > www.rootyhollow.com > (614) 886-5530 > > Twitter: jalama > Linkedin: http://www.linkedin.com/in/rootyhollow From hovercrafter at earthlink.net Tue Feb 24 22:21:54 2009 From: hovercrafter at earthlink.net (Jamie Holly) Date: Tue, 24 Feb 2009 17:21:54 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> Message-ID: <49A47302.9080504@earthlink.net> If you don't use the task list you can disable that in the plugins. I can't remember the exact name of the plugin. I just went through the list and it popped out at me and I clicked to get rid of it. There's also a plugin that lets you connect directly to TRAC systems to handle issues. It would be nice to create something similar to connect with Project's issue tracker. If I knew enough Java I would tackle that. Jim Taylor wrote: > Kept having "buggy" issues with Eclipse, memory issues, losing > features, etc... I had to re-download PDT a couple of times, finally > I just gave up. After I saw NetBeans PHP support talked about in Site > Point, I pulled the trigger. Functionally, I think it's much and more > intuitive out of the box. If you make heavy use of task list, the > task scanner can really bog Net Beans down, but you can simply close > it. As an added bonus it has great CSS support. :) > > I agree I would use VIM if I had the patience, but I grew up in the > Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) > > On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow > wrote: > > What pulled you to NetBeans over Eclipse? > > Tao > > > Jamie Holly wrote: > > Have you given NetBeans 6.54 a try yet? I've switched from > Eclipse to it at the beginning of the month and haven't looked > back. > > Jamie Holly > > > > > Domenic Santangelo wrote: > > Hey all, > > I've been using Komodo for a while and while I like its > built-in > support for xdebug (breakpoints, stepping, stack trace, > the whole > enchilada) and code intel. But I hate it because it's a > terrible > resource hog. I've been using Coda for a couple weeks, and > although > it's extremely pretty, it lacks a few pretty key things, > xdebug > support being the main one. I used TextMate before Komodo > and am > thinking of going back, but I really would hate to live > without > debugging/xdebug support. Also, I've tried Eclipse and > don't like it. > > Thoughts? TextMate + some magic to support xdebug maybe? > > -Dom > > > > > > > -- > Jim Taylor > Rooty Hollow LLC, Owner > jim at rootyhollow.com > www.rootyhollow.com > (614) 886-5530 > > Twitter: jalama > Linkedin: http://www.linkedin.com/in/rootyhollow From sirkitree at gmail.com Tue Feb 24 22:42:12 2009 From: sirkitree at gmail.com (Jerad Bitner) Date: Tue, 24 Feb 2009 14:42:12 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <49A47302.9080504@earthlink.net> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47302.9080504@earthlink.net> Message-ID: <215a89c90902241442x6f97156bq7c8790483209354b@mail.gmail.com> Wow. Thank you for introducing me to Netbeans, I'm liking this so much more. Even found a nice git plugin - http://code.google.com/p/nbgit/downloads/list Might have a new addiction here... On Tue, Feb 24, 2009 at 2:21 PM, Jamie Holly wrote: > If you don't use the task list you can disable that in the plugins. I can't > remember the exact name of the plugin. I just went through the list and it > popped out at me and I clicked to get rid of it. > > There's also a plugin that lets you connect directly to TRAC systems to > handle issues. It would be nice to create something similar to connect with > Project's issue tracker. If I knew enough Java I would tackle that. > > Jim Taylor wrote: > >> Kept having "buggy" issues with Eclipse, memory issues, losing features, >> etc... I had to re-download PDT a couple of times, finally I just gave up. >> After I saw NetBeans PHP support talked about in Site Point, I pulled the >> trigger. Functionally, I think it's much and more intuitive out of the box. >> If you make heavy use of task list, the task scanner can really bog Net >> Beans down, but you can simply close it. As an added bonus it has great >> CSS support. :) >> I agree I would use VIM if I had the patience, but I grew up in the >> Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) >> >> On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow > starbow at citris-uc.org>> wrote: >> >> What pulled you to NetBeans over Eclipse? >> >> Tao >> >> >> Jamie Holly wrote: >> >> Have you given NetBeans 6.54 a try yet? I've switched from >> Eclipse to it at the beginning of the month and haven't looked >> back. >> >> Jamie Holly >> >> >> >> >> Domenic Santangelo wrote: >> >> Hey all, >> >> I've been using Komodo for a while and while I like its >> built-in >> support for xdebug (breakpoints, stepping, stack trace, >> the whole >> enchilada) and code intel. But I hate it because it's a >> terrible >> resource hog. I've been using Coda for a couple weeks, and >> although >> it's extremely pretty, it lacks a few pretty key things, >> xdebug >> support being the main one. I used TextMate before Komodo >> and am >> thinking of going back, but I really would hate to live >> without >> debugging/xdebug support. Also, I've tried Eclipse and >> don't like it. >> >> Thoughts? TextMate + some magic to support xdebug maybe? >> >> -Dom >> >> >> >> >> >> -- >> Jim Taylor >> Rooty Hollow LLC, Owner >> jim at rootyhollow.com >> www.rootyhollow.com >> (614) 886-5530 >> >> Twitter: jalama >> Linkedin: http://www.linkedin.com/in/rootyhollow >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/ba3d3413/attachment.htm From mathews.kyle at gmail.com Tue Feb 24 23:03:18 2009 From: mathews.kyle at gmail.com (Kyle Mathews) Date: Tue, 24 Feb 2009 16:03:18 -0700 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <215a89c90902241442x6f97156bq7c8790483209354b@mail.gmail.com> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47302.9080504@earthlink.net> <215a89c90902241442x6f97156bq7c8790483209354b@mail.gmail.com> Message-ID: Yeah! We found a topic everyone can talk about. On Netbeans -- does anyone know how to get xdebug working with it in Ubuntu? Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Tue, Feb 24, 2009 at 3:42 PM, Jerad Bitner wrote: > Wow. Thank you for introducing me to Netbeans, I'm liking this so much more. > Even found a nice git plugin - http://code.google.com/p/nbgit/downloads/list > Might have a new addiction here... > > On Tue, Feb 24, 2009 at 2:21 PM, Jamie Holly > wrote: >> >> If you don't use the task list you can disable that in the plugins. I >> can't remember the exact name of the plugin. I just went through the list >> and it popped out at me and I clicked to get rid of it. >> >> There's also a plugin that lets you connect directly to TRAC systems to >> handle issues. It would be nice to create something similar to connect with >> Project's issue tracker. If I knew enough Java I would tackle that. >> >> Jim Taylor wrote: >>> >>> Kept having "buggy" issues with Eclipse, memory issues, losing features, >>> etc... I had to re-download PDT a couple of times, finally I just gave up. >>> After I saw NetBeans PHP support talked about in Site Point, I pulled the >>> trigger. Functionally, I think it's much and more intuitive out of the box. >>> If you make heavy use of task list, the task scanner can really bog Net >>> Beans down, but you can simply close it. As an added bonus it has great >>> CSS support. :) >>> I agree I would use VIM if I had the patience, but I grew up in the >>> Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) >>> >>> On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow >> > wrote: >>> >>> What pulled you to NetBeans over Eclipse? >>> >>> Tao >>> >>> >>> Jamie Holly wrote: >>> >>> Have you given NetBeans 6.54 a try yet? I've switched from >>> Eclipse to it at the beginning of the month and haven't looked >>> back. >>> >>> Jamie Holly >>> >>> >>> >>> >>> Domenic Santangelo wrote: >>> >>> Hey all, >>> >>> I've been using Komodo for a while and while I like its >>> built-in >>> support for xdebug (breakpoints, stepping, stack trace, >>> the whole >>> enchilada) and code intel. But I hate it because it's a >>> terrible >>> resource hog. I've been using Coda for a couple weeks, and >>> although >>> it's extremely pretty, it lacks a few pretty key things, >>> xdebug >>> support being the main one. I used TextMate before Komodo >>> and am >>> thinking of going back, but I really would hate to live >>> without >>> debugging/xdebug support. Also, I've tried Eclipse and >>> don't like it. >>> >>> Thoughts? TextMate + some magic to support xdebug maybe? >>> >>> -Dom >>> >>> >>> >>> >>> >>> -- >>> Jim Taylor >>> Rooty Hollow LLC, Owner >>> jim at rootyhollow.com >>> www.rootyhollow.com >>> (614) 886-5530 >>> >>> Twitter: jalama >>> Linkedin: http://www.linkedin.com/in/rootyhollow > > From anthony at thrillist.com Tue Feb 24 23:04:46 2009 From: anthony at thrillist.com (Anthony Wlodarski) Date: Tue, 24 Feb 2009 15:04:46 -0800 Subject: [development] Welcome to the "development" mailing list In-Reply-To: Message-ID: Eh, I found the SFTP to be faulty without synchronization. Back to VIM and Xdebug for me. -Anthony -- Anthony Wlodarski www.thrillist.com Web Applications Developer 568 Broadway Ste. 605 New York, NY, 10012 (o) 646.786.1944 ________________________________ From: Kyle Mathews Reply-To: Date: Tue, 24 Feb 2009 15:03:18 -0800 To: Subject: Re: [development] Welcome to the "development" mailing list Yeah! We found a topic everyone can talk about. On Netbeans -- does anyone know how to get xdebug working with it in Ubuntu? Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Tue, Feb 24, 2009 at 3:42 PM, Jerad Bitner wrote: > Wow. Thank you for introducing me to Netbeans, I'm liking this so much more. > Even found a nice git plugin - http://code.google.com/p/nbgit/downloads/list > Might have a new addiction here... > > On Tue, Feb 24, 2009 at 2:21 PM, Jamie Holly > wrote: >> >> If you don't use the task list you can disable that in the plugins. I >> can't remember the exact name of the plugin. I just went through the list >> and it popped out at me and I clicked to get rid of it. >> >> There's also a plugin that lets you connect directly to TRAC systems to >> handle issues. It would be nice to create something similar to connect with >> Project's issue tracker. If I knew enough Java I would tackle that. >> >> Jim Taylor wrote: >>> >>> Kept having "buggy" issues with Eclipse, memory issues, losing features, >>> etc... I had to re-download PDT a couple of times, finally I just gave up. >>> After I saw NetBeans PHP support talked about in Site Point, I pulled the >>> trigger. Functionally, I think it's much and more intuitive out of the box. >>> If you make heavy use of task list, the task scanner can really bog Net >>> Beans down, but you can simply close it. As an added bonus it has great >>> CSS support. :) >>> I agree I would use VIM if I had the patience, but I grew up in the >>> Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) >>> >>> On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow >> > wrote: >>> >>> What pulled you to NetBeans over Eclipse? >>> >>> Tao >>> >>> >>> Jamie Holly wrote: >>> >>> Have you given NetBeans 6.54 a try yet? I've switched from >>> Eclipse to it at the beginning of the month and haven't looked >>> back. >>> >>> Jamie Holly >>> >>> >>> >>> >>> Domenic Santangelo wrote: >>> >>> Hey all, >>> >>> I've been using Komodo for a while and while I like its >>> built-in >>> support for xdebug (breakpoints, stepping, stack trace, >>> the whole >>> enchilada) and code intel. But I hate it because it's a >>> terrible >>> resource hog. I've been using Coda for a couple weeks, and >>> although >>> it's extremely pretty, it lacks a few pretty key things, >>> xdebug >>> support being the main one. I used TextMate before Komodo >>> and am >>> thinking of going back, but I really would hate to live >>> without >>> debugging/xdebug support. Also, I've tried Eclipse and >>> don't like it. >>> >>> Thoughts? TextMate + some magic to support xdebug maybe? >>> >>> -Dom >>> >>> >>> >>> >>> >>> -- >>> Jim Taylor >>> Rooty Hollow LLC, Owner >>> jim at rootyhollow.com >>> www.rootyhollow.com >>> (614) 886-5530 >>> >>> Twitter: jalama >>> Linkedin: http://www.linkedin.com/in/rootyhollow > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/6b0b73e5/attachment-0001.htm From prometheus6 at gmail.com Tue Feb 24 23:09:25 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Tue, 24 Feb 2009 18:09:25 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> Message-ID: Net Beans is pretty impressive. I grew up Microsoft too, and I've been using Zend Studio for a while. Net Beans seems just as capable, and it feels more familiar than Eclipse even now. I think I'll try that Drupal plug in. On Tue, Feb 24, 2009 at 3:33 PM, Jim Taylor wrote: > Kept having "buggy" issues with Eclipse, memory issues, losing features, > etc... I had to re-download PDT a couple of times, finally I just gave up. > After I saw NetBeans PHP support talked about in Site Point, I pulled the > trigger. Functionally, I think it's much and more intuitive out of the > box. If you make heavy use of task list, the task scanner can really bog > Net Beans down, but you can simply close it. As an added bonus it has > great CSS support. :) > > I agree I would use VIM if I had the patience, but I grew up in the > Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI :) > > > On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow wrote: > >> What pulled you to NetBeans over Eclipse? >> >> Tao >> >> >> Jamie Holly wrote: >> >>> Have you given NetBeans 6.54 a try yet? I've switched from Eclipse to it >>> at the beginning of the month and haven't looked back. >>> >>> Jamie Holly >>> >>> >>> >>> >>> Domenic Santangelo wrote: >>> >>>> Hey all, >>>> >>>> I've been using Komodo for a while and while I like its built-in >>>> support for xdebug (breakpoints, stepping, stack trace, the whole >>>> enchilada) and code intel. But I hate it because it's a terrible >>>> resource hog. I've been using Coda for a couple weeks, and although >>>> it's extremely pretty, it lacks a few pretty key things, xdebug >>>> support being the main one. I used TextMate before Komodo and am >>>> thinking of going back, but I really would hate to live without >>>> debugging/xdebug support. Also, I've tried Eclipse and don't like it. >>>> >>>> Thoughts? TextMate + some magic to support xdebug maybe? >>>> >>>> -Dom >>>> >>>> >>>> >>> > > > -- > Jim Taylor > Rooty Hollow LLC, Owner > jim at rootyhollow.com > www.rootyhollow.com > (614) 886-5530 > > Twitter: jalama > Linkedin: http://www.linkedin.com/in/rootyhollow > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/4e3aa0f0/attachment.htm From jim at rootyhollow.com Tue Feb 24 23:13:09 2009 From: jim at rootyhollow.com (Jim Taylor) Date: Tue, 24 Feb 2009 18:13:09 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47302.9080504@earthlink.net> <215a89c90902241442x6f97156bq7c8790483209354b@mail.gmail.com> Message-ID: <2f2379e70902241513l55fdda16ie8f0eb6886c446ca@mail.gmail.com> Kyle I can't remember what else I did but this is the php.ini settings that worked for me on ubuntu (8.10) ;xdebug zend_extension=/usr/lib/php5/20060613+lfs/xdebug.so [debug] ; Remote settings xdebug.remote_autostart=off xdebug.remote_enable=on xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_host=drupalhost xdebug.remote_port=9000 On Tue, Feb 24, 2009 at 6:03 PM, Kyle Mathews wrote: > Yeah! We found a topic everyone can talk about. > > On Netbeans -- does anyone know how to get xdebug working with it in > Ubuntu? > > > Kyle > > Research Assistant > eBusiness Center @ BYU > kyle.mathews2000.com/blog > > > > On Tue, Feb 24, 2009 at 3:42 PM, Jerad Bitner wrote: > > Wow. Thank you for introducing me to Netbeans, I'm liking this so much > more. > > Even found a nice git plugin - > http://code.google.com/p/nbgit/downloads/list > > Might have a new addiction here... > > > > On Tue, Feb 24, 2009 at 2:21 PM, Jamie Holly > > > wrote: > >> > >> If you don't use the task list you can disable that in the plugins. I > >> can't remember the exact name of the plugin. I just went through the > list > >> and it popped out at me and I clicked to get rid of it. > >> > >> There's also a plugin that lets you connect directly to TRAC systems to > >> handle issues. It would be nice to create something similar to connect > with > >> Project's issue tracker. If I knew enough Java I would tackle that. > >> > >> Jim Taylor wrote: > >>> > >>> Kept having "buggy" issues with Eclipse, memory issues, losing > features, > >>> etc... I had to re-download PDT a couple of times, finally I just gave > up. > >>> After I saw NetBeans PHP support talked about in Site Point, I pulled > the > >>> trigger. Functionally, I think it's much and more intuitive out of the > box. > >>> If you make heavy use of task list, the task scanner can really bog > Net > >>> Beans down, but you can simply close it. As an added bonus it has > great > >>> CSS support. :) > >>> I agree I would use VIM if I had the patience, but I grew up in the > >>> Microsoft world and switched to linux 3-4 yrs. ago so I do like me UI > :) > >>> > >>> On Tue, Feb 24, 2009 at 2:55 PM, Tao Starbow >>> > wrote: > >>> > >>> What pulled you to NetBeans over Eclipse? > >>> > >>> Tao > >>> > >>> > >>> Jamie Holly wrote: > >>> > >>> Have you given NetBeans 6.54 a try yet? I've switched from > >>> Eclipse to it at the beginning of the month and haven't looked > >>> back. > >>> > >>> Jamie Holly > >>> > >>> > >>> > >>> > >>> Domenic Santangelo wrote: > >>> > >>> Hey all, > >>> > >>> I've been using Komodo for a while and while I like its > >>> built-in > >>> support for xdebug (breakpoints, stepping, stack trace, > >>> the whole > >>> enchilada) and code intel. But I hate it because it's a > >>> terrible > >>> resource hog. I've been using Coda for a couple weeks, and > >>> although > >>> it's extremely pretty, it lacks a few pretty key things, > >>> xdebug > >>> support being the main one. I used TextMate before Komodo > >>> and am > >>> thinking of going back, but I really would hate to live > >>> without > >>> debugging/xdebug support. Also, I've tried Eclipse and > >>> don't like it. > >>> > >>> Thoughts? TextMate + some magic to support xdebug maybe? > >>> > >>> -Dom > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Jim Taylor > >>> Rooty Hollow LLC, Owner > >>> jim at rootyhollow.com > >>> www.rootyhollow.com > >>> (614) 886-5530 > >>> > >>> Twitter: jalama > >>> Linkedin: http://www.linkedin.com/in/rootyhollow > > > > > -- Jim Taylor Rooty Hollow LLC, Owner jim at rootyhollow.com www.rootyhollow.com (614) 886-5530 Twitter: jalama Linkedin: http://www.linkedin.com/in/rootyhollow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/c2de8e8a/attachment.htm From gerhard at killesreiter.de Tue Feb 24 23:16:53 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed, 25 Feb 2009 00:16:53 +0100 Subject: [development] Off-topic (was: Welcome to the "development" mailing list) In-Reply-To: References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> Message-ID: <49A47FE5.9050604@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Earl Dunovant schrieb: > Net Beans is pretty impressive. I grew up Microsoft too, and I've been using > Zend Studio for a while. Net Beans seems just as capable, and it feels more > familiar than Eclipse even now. I think I'll try that Drupal plug in. Say guys, you realize that "what IDE to use" is a pretty general PHP question and has absolutely nothing to do with Drupal development in particular? In other words: you are all off topic. I am going to sleep now, if my inbox is full of more of this stuff when I get up again, I'll run amok on the membership roster. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmkf+UACgkQfg6TFvELooR4OgCbBkF5L8igSwKZuLCQw15QxDyh HuMAn2x7eMHFyqLXMHghDr4UjImCy7H+ =MtCa -----END PGP SIGNATURE----- From domenic at workhabit.com Tue Feb 24 23:40:22 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Tue, 24 Feb 2009 15:40:22 -0800 Subject: [development] Off-topic (was: Welcome to the "development" mailing list) In-Reply-To: <49A47FE5.9050604@killesreiter.de> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47FE5.9050604@killesreiter.de> Message-ID: killes, OP here. I realize the importance of keeping the list clean and on-topic and am glad to see your input. Another perspective for you though, I asked the question as my programming time is 95% Drupal and I've been hopping from IDE to IDE in search of something useful *specifically* for Drupal-centric programming. Drupal-awareness inside the IDE (whether through a combination of tools or one awesome IDE) is an important criteria in this regard. Consequently, I must respectfully disagree with your assertion that we are all off-topic. Many technologies that we use -- PHP itself, for example -- are not by definition Drupal, but can be (and for the purposes of this list, should be) framed in the context of Drupal. -D -- Domenic Santangelo senior engineer | workhabit,inc. // email: domenic at workhabit.com | web: http://www.workhabit.com // office: 866-workhabit | direct: 916-288-8243 On Tue, Feb 24, 2009 at 3:16 PM, Gerhard Killesreiter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earl Dunovant schrieb: >> Net Beans is pretty impressive. I grew up Microsoft too, and I've been using >> Zend Studio for a while. Net Beans seems just as capable, and it feels more >> familiar than Eclipse even now. I think I'll try that Drupal plug in. > > > Say guys, you realize that "what IDE to use" is a pretty general PHP > question and has absolutely nothing to do with Drupal development in > particular? > > In other words: you are all off topic. > > I am going to sleep now, if my inbox is full of more of this stuff when > I get up again, I'll run amok on the membership roster. > > Cheers, > ? ? ? ?Gerhard > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmkf+UACgkQfg6TFvELooR4OgCbBkF5L8igSwKZuLCQw15QxDyh > HuMAn2x7eMHFyqLXMHghDr4UjImCy7H+ > =MtCa > -----END PGP SIGNATURE----- > From prometheus6 at gmail.com Wed Feb 25 00:03:51 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Tue, 24 Feb 2009 19:03:51 -0500 Subject: [development] Off-topic (was: Welcome to the "development" mailing list) In-Reply-To: <49A47FE5.9050604@killesreiter.de> References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47FE5.9050604@killesreiter.de> Message-ID: Would it be simpler if I don't use the list anymore? I don't remember anyone responding to my posts without attempting a correction of some sort. It is not the case that I have not returned to the community, code and advice. Apparently it's my social skills? On Tue, Feb 24, 2009 at 6:16 PM, Gerhard Killesreiter < gerhard at killesreiter.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Earl Dunovant schrieb: > > Net Beans is pretty impressive. I grew up Microsoft too, and I've been > using > > Zend Studio for a while. Net Beans seems just as capable, and it feels > more > > familiar than Eclipse even now. I think I'll try that Drupal plug in. > > > Say guys, you realize that "what IDE to use" is a pretty general PHP > question and has absolutely nothing to do with Drupal development in > particular? > > In other words: you are all off topic. > > I am going to sleep now, if my inbox is full of more of this stuff when > I get up again, I'll run amok on the membership roster. > > Cheers, > Gerhard > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmkf+UACgkQfg6TFvELooR4OgCbBkF5L8igSwKZuLCQw15QxDyh > HuMAn2x7eMHFyqLXMHghDr4UjImCy7H+ > =MtCa > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090224/32cd5f21/attachment-0001.htm From merlin at logrus.com Wed Feb 25 00:13:47 2009 From: merlin at logrus.com (Earl Miles) Date: Tue, 24 Feb 2009 16:13:47 -0800 Subject: [development] Off-topic In-Reply-To: References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47FE5.9050604@killesreiter.de> Message-ID: <49A48D3B.708@logrus.com> Earl Dunovant wrote: > Would it be simpler if I don't use the list anymore? I don't remember > anyone responding to my posts without attempting a correction of some sort. > > It is not the case that I have not returned to the community, code and > advice. Apparently it's my social skills? Nah. It's the name. =) From paulhoza at gmail.com Wed Feb 25 00:15:27 2009 From: paulhoza at gmail.com (Paul Hoza) Date: Tue, 24 Feb 2009 17:15:27 -0700 Subject: [development] Off-topic In-Reply-To: References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> <49A47FE5.9050604@killesreiter.de> Message-ID: <49A48D9F.20603@gmail.com> Considering that I found at least three new development tools that I've installed and am running through -- all in hopes of greatly improving my current Drupal-centric workload -- hopefully adds one vote to the Relevancy Rating of this thread. I think it's important to remember that lists like this represent a collective community working together on a sort of "meta project". ... I say "bah!" to the off-topic issue in general, but definitely to this thread being offensive to the list. Paul Domenic Santangelo wrote: > killes, > > OP here. I realize the importance of keeping the list clean and > on-topic and am glad to see your input. Another perspective for you > though, I asked the question as my programming time is 95% Drupal and > I've been hopping from IDE to IDE in search of something useful > *specifically* for Drupal-centric programming. Drupal-awareness inside > the IDE (whether through a combination of tools or one awesome IDE) is > an important criteria in this regard. > > Consequently, I must respectfully disagree with your assertion that we > are all off-topic. Many technologies that we use -- PHP itself, for > example -- are not by definition Drupal, but can be (and for the > purposes of this list, should be) framed in the context of Drupal. > > -D > From andrewberry at sentex.net Wed Feb 25 02:42:40 2009 From: andrewberry at sentex.net (Andrew Berry) Date: Tue, 24 Feb 2009 21:42:40 -0500 Subject: [development] Welcome to the "development" mailing list In-Reply-To: References: <49A44E77.8010307@earthlink.net> <49A450A7.4040103@citris-uc.org> <2f2379e70902241233r8ec6655x482a0028830c1027@mail.gmail.com> Message-ID: On 24-Feb-09, at 6:09 PM, Earl Dunovant wrote: > Net Beans is pretty impressive. When I last tried NetBeans a few months ago, the biggest issue I ran into was not being able to reference other projects. In Eclipse, I have one project for each module, with Drupal 5/6/HEAD projects referenced to provide function lookups. AFAICT, for each module I would have to keep them within the appropriate Drupal version, leading to 20-30 redundant copies of Drupal. Any suggestions, or was I doing my workflow completely wrong? --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2672 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20090224/33accc09/attachment.bin From sammys-drupal at synerger.com Wed Feb 25 03:30:53 2009 From: sammys-drupal at synerger.com (Sammy Spets) Date: Wed, 25 Feb 2009 14:30:53 +1100 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> Message-ID: <49A4BB6D.30208@synerger.com> I am totally for global object caching strategy. +100 There is the issue of distinguishing cacheable and non-cacheable fields. Does D7 Fields API flag fields as cacheable to make this simpler? Cheers, -- Sammy Spets Synerger http://synerger.com Josh Koenig wrote: > Greetings, > > I'd like to take the community's temperature on developing a global > object caching strategy for drupal core 7.0. In effect, this would > mean pulling the functionality of advcache module into core, though > the code would doubtless be a bit different. > > This has been previously discussed by Robert Douglass and Steve Rude, > and I think both the short-term and strategic value here is clear. As > memcached permeates the collective consciousness of the > web-development community, and as "cloud" computing becomes more and > more prevalent, best practices in architecture increasingly point > towards caching full objects whenever possible. > > This also fits well with Drupal's existing architecture. There are > great functional points (e.g. node_load()) to mount this functionality. > > I'm certain I'm not the only one thinking along these lines. Anyone > want to throw out their ideas? > > cheers > -josh > From drupal.beginner at wechange.org Wed Feb 25 06:30:02 2009 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Wed, 25 Feb 2009 14:30:02 +0800 Subject: [development] Use a meaningful subject line! (Re: Off-topic (was: Welcome to the "development" mailing list) In-Reply-To: References: <49A47FE5.9050604@killesreiter.de> Message-ID: <200902251430.02252.drupal.beginner@wechange.org> On Wednesday 25 February 2009 07:40:22 Domenic Santangelo wrote: > OP here. I realize the importance of keeping the list clean and > on-topic and am glad to see your input. Hi OP, I must side with Gerhard on at least one point: in this whole thread, he is the only one to have changed the subject line to something actually related to what is being discussed. This whole discussion could have been interesting to some people researching the archives of this list. However, how is anything that has been said related to "Welcome to the 'development' mailing list"??? This whole thread is lost as far as the archives are concerned. It's considered good netiquette to properly advertise the content of a mail by giving a meaningfull subject line. Any of the people who have replied to your email could have changed the topic line, too, to correct your original lack of manners. Gerhard is the only one to have done so. "Top-posting" is also considered bad manners. If you think about them, there are some good reasons behind each commonly agreed rule of netiquette, just like there are good reasons behind each of Drupal's very detailed coding standards. Thanks for taking such rules into consideration. Augustin. From prometheus6 at gmail.com Wed Feb 25 11:52:09 2009 From: prometheus6 at gmail.com (Earl Dunovant) Date: Wed, 25 Feb 2009 06:52:09 -0500 Subject: [development] Use a meaningful subject line! (Re: Off-topic (was: Welcome to the "development" mailing list) In-Reply-To: <200902251430.02252.drupal.beginner@wechange.org> References: <49A47FE5.9050604@killesreiter.de> <200902251430.02252.drupal.beginner@wechange.org> Message-ID: It is also rude to cut off a fruitful discussion because he might have issues with me for some reason (which I think I remember now...oh well...). On Wed, Feb 25, 2009 at 1:30 AM, augustin (beginner) < drupal.beginner at wechange.org> wrote: > On Wednesday 25 February 2009 07:40:22 Domenic Santangelo wrote: > > OP here. I realize the importance of keeping the list clean and > > on-topic and am glad to see your input. > > > Hi OP, > > I must side with Gerhard on at least one point: in this whole thread, he is > the only one to have changed the subject line to something actually related > to what is being discussed. > > This whole discussion could have been interesting to some people > researching > the archives of this list. However, how is anything that has been said > related to "Welcome to the 'development' mailing list"??? This whole thread > is lost as far as the archives are concerned. > > It's considered good netiquette to properly advertise the content of a mail > by > giving a meaningfull subject line. Any of the people who have replied to > your > email could have changed the topic line, too, to correct your original lack > of manners. Gerhard is the only one to have done so. > > "Top-posting" is also considered bad manners. > > If you think about them, there are some good reasons behind each commonly > agreed rule of netiquette, just like there are good reasons behind each of > Drupal's very detailed coding standards. > > Thanks for taking such rules into consideration. > > > Augustin. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090225/6b810f0b/attachment.htm From mistknight at gmail.com Wed Feb 25 12:15:16 2009 From: mistknight at gmail.com (Ashraf Amayreh) Date: Wed, 25 Feb 2009 14:15:16 +0200 Subject: [development] Use a meaningful subject line! (Re: Off-topic (was: Welcome to the "development" mailing list) In-Reply-To: References: <49A47FE5.9050604@killesreiter.de> <200902251430.02252.drupal.beginner@wechange.org> Message-ID: Guys, let's try to keep the flames off of here. I do agree the topic is fruitful to some and as with any other topic, totally a time waster for others. This is the nature of all topics on this list. Augustin's remark is very valid and the subject didn't remotely relate to the topic it was talking about. I'm sure if you'd like to write a new post that states its purpose in the subject along the lines of "[continued] IDEs for Drupal development" you will find less resistance from anyone on the list and you can pick up where you previously left off. On Wed, Feb 25, 2009 at 1:52 PM, Earl Dunovant wrote: > It is also rude to cut off a fruitful discussion because he might have > issues with me for some reason (which I think I remember now...oh well...). > > > On Wed, Feb 25, 2009 at 1:30 AM, augustin (beginner) < > drupal.beginner at wechange.org> wrote: > >> On Wednesday 25 February 2009 07:40:22 Domenic Santangelo wrote: >> > OP here. I realize the importance of keeping the list clean and >> > on-topic and am glad to see your input. >> >> >> Hi OP, >> >> I must side with Gerhard on at least one point: in this whole thread, he >> is >> the only one to have changed the subject line to something actually >> related >> to what is being discussed. >> >> This whole discussion could have been interesting to some people >> researching >> the archives of this list. However, how is anything that has been said >> related to "Welcome to the 'development' mailing list"??? This whole >> thread >> is lost as far as the archives are concerned. >> >> It's considered good netiquette to properly advertise the content of a >> mail by >> giving a meaningfull subject line. Any of the people who have replied to >> your >> email could have changed the topic line, too, to correct your original >> lack >> of manners. Gerhard is the only one to have done so. >> >> "Top-posting" is also considered bad manners. >> >> If you think about them, there are some good reasons behind each commonly >> agreed rule of netiquette, just like there are good reasons behind each of >> Drupal's very detailed coding standards. >> >> Thanks for taking such rules into consideration. >> >> >> Augustin. >> >> > -- Ashraf Amayreh http://aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090225/db433406/attachment-0001.htm From domenic at workhabit.com Wed Feb 25 18:37:15 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Wed, 25 Feb 2009 10:37:15 -0800 Subject: [development] IDEs for Drupal development [continued] (was: Welcome to the "development" mailing list) Message-ID: On Tue, Feb 24, 2009 at 6:42 PM, Andrew Berry wrote: > On 24-Feb-09, at 6:09 PM, Earl Dunovant wrote: > >> Net Beans is pretty impressive. > > Any suggestions, or was I doing my workflow completely wrong? Not sure on that one. I did end up trying NetBeans and so far I LOVE it. Thanks to all who replied. If anyone has an answer to Andrew's question, I'm interested to know it as well. -D From anthony at thrillist.com Wed Feb 25 18:40:53 2009 From: anthony at thrillist.com (Anthony Wlodarski) Date: Wed, 25 Feb 2009 10:40:53 -0800 Subject: [development] VIM as an editor. Message-ID: I am now running VIM 7.2 and love the tabs and auto complete features for PHP and other Web based technologies. Has anyone written a auto complete file yet for Drupal 5/6/7 branches yet? Regards, Anthony -- Anthony Wlodarski www.thrillist.com Web Applications Developer 568 Broadway Ste. 605 New York, NY, 10012 (o) 646.786.1944 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090225/ca5c8bd8/attachment.htm From jcfiala at gmail.com Wed Feb 25 20:14:35 2009 From: jcfiala at gmail.com (John Fiala) Date: Wed, 25 Feb 2009 13:14:35 -0700 Subject: [development] IDEs for Drupal development [continued] (was: Welcome to the "development" mailing list) In-Reply-To: References: Message-ID: On Wed, Feb 25, 2009 at 11:37 AM, Domenic Santangelo wrote: > On Tue, Feb 24, 2009 at 6:42 PM, Andrew Berry wrote: >> On 24-Feb-09, at 6:09 PM, Earl Dunovant wrote: >> >>> Net Beans is pretty impressive. >> >> Any suggestions, or was I doing my workflow completely wrong? > > Not sure on that one. I did end up trying NetBeans and so far I LOVE > it. Thanks to all who replied. If anyone has an answer to Andrew's > question, I'm interested to know it as well. > > -D Personally, I'm pretty happy with Komodo Edit - it's doing enough to help me get work done, and I don't need a lot more right now. -- John Fiala From gordon at heydon.com.au Wed Feb 25 21:20:07 2009 From: gordon at heydon.com.au (Gordon Heydon) Date: Thu, 26 Feb 2009 08:20:07 +1100 Subject: [development] VIM as an editor. In-Reply-To: References: Message-ID: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I too use vim for development, and I have not created an autocomplete for Drupal. If someone builds one I would love to get a copy. Gordon. On 26/02/2009, at 5:40 AM, Anthony Wlodarski wrote: > I am now running VIM 7.2 and love the tabs and auto complete > features for PHP and other Web based technologies. Has anyone > written a auto complete file yet for Drupal 5/6/7 branches yet? > > Regards, > Anthony > -- > Anthony Wlodarski > www.thrillist.com > Web Applications Developer > 568 Broadway Ste. 605 > New York, NY, 10012 > (o) 646.786.1944 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmltgcACgkQngavurZvkryzGgCeK+3bNIMAc47MxABaep6Q98vo 8J4An1PiwMd3ttGigpTKyaTu9H7JEOeQ =xAcE -----END PGP SIGNATURE----- From antoinesolutions at gmail.com Wed Feb 25 21:39:49 2009 From: antoinesolutions at gmail.com (Jon Antoine) Date: Wed, 25 Feb 2009 13:39:49 -0800 Subject: [development] VIM as an editor. In-Reply-To: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> Message-ID: <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> Since the topic of an IDE has come up, I'm curious as to how valuable a system would be that offers line by line debugging? I spent 3 months researching over 20 opensource projects and integrating them into a nice system for Drupal development, or any PHP development for that matter. I have documented about half of my work at dev.antoinesolutions.com. There you can review all the different projects I have integrated and instructions on how to do it yourself. I was also thinking of offering a VMware virtual machine for download at $99.00 for a year subscription with monthly releases. The $99.00 would cover my time and the bandwidth required to host such large files. Check out the site and let me know what you think. Cheers, Jon Antoine Senior Consultant Antoine Solutions Drupal Web Development www.antoinesolutions.com On Wed, Feb 25, 2009 at 1:20 PM, Gordon Heydon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I too use vim for development, and I have not created an autocomplete for > Drupal. If someone builds one I would love to get a copy. > > Gordon. > > On 26/02/2009, at 5:40 AM, Anthony Wlodarski wrote: > >> I am now running VIM 7.2 and love the tabs and auto complete features for >> PHP and other Web based technologies. ?Has anyone written a auto complete >> file yet for Drupal 5/6/7 branches yet? >> >> Regards, >> Anthony >> -- >> Anthony Wlodarski >> www.thrillist.com >> Web Applications Developer >> 568 Broadway Ste. 605 >> New York, NY, 10012 >> (o) 646.786.1944 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > > iEYEARECAAYFAkmltgcACgkQngavurZvkryzGgCeK+3bNIMAc47MxABaep6Q98vo > 8J4An1PiwMd3ttGigpTKyaTu9H7JEOeQ > =xAcE > -----END PGP SIGNATURE----- > From gerhard at killesreiter.de Wed Feb 25 21:58:47 2009 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed, 25 Feb 2009 22:58:47 +0100 Subject: [development] Learn to use a mailing list (was: VIM as an editor.) In-Reply-To: <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> Message-ID: <49A5BF17.9080005@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Antoine schrieb: > Since the topic of an IDE has come up, I'm curious as to how The topic was "VIM" not "IDE", see the subject of the mail you replied to. It is even written in capital letters. "Senior Consultant"? Apparently not for the topic of "how to effectively use a mailing list". See for example the "netiquette" part of this: http://www.openbsd.org/mail.html Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmlvxcACgkQfg6TFvELooSD0gCffBZ7tFKMhOSKI0hF027Ajo66 FsIAoLZeoWzyUP62bBmx4oHSFJBf90im =LO8J -----END PGP SIGNATURE----- From domenic at workhabit.com Wed Feb 25 22:05:45 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Wed, 25 Feb 2009 14:05:45 -0800 Subject: [development] Learn to use a mailing list (was: VIM as an editor.) In-Reply-To: <49A5BF17.9080005@killesreiter.de> References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> <49A5BF17.9080005@killesreiter.de> Message-ID: On Wed, Feb 25, 2009 at 1:58 PM, Gerhard Killesreiter wrote: > "Senior Consultant"? Apparently not for the topic of "how to > effectively use a mailing list". See for example the "netiquette" part > of this: http://www.openbsd.org/mail.html Yikes, forget netequitte, how about showing some common decency? The only two posts I've seen from you since joining this list yesterday were rude and condescending. Shall we get off of your lawn while we're at it? -D From antoinesolutions at gmail.com Wed Feb 25 22:13:34 2009 From: antoinesolutions at gmail.com (Jon Antoine) Date: Wed, 25 Feb 2009 14:13:34 -0800 Subject: [development] Learn to use a mailing list (was: VIM as an editor.) In-Reply-To: References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> <49A5BF17.9080005@killesreiter.de> Message-ID: <445719130902251413n28f112d1gac4c91d4a6ef1e57@mail.gmail.com> My sincerest apologies to anyone I have offended. I believe the topic at some point was IDE and was changed to VIM. Cheers, Jon Antoine Senior Consultant Antoine Solutions Open Source Development Tutorials & Documentation www.antoinesolutions.com On Wed, Feb 25, 2009 at 2:05 PM, Domenic Santangelo wrote: > On Wed, Feb 25, 2009 at 1:58 PM, Gerhard Killesreiter > wrote: >> "Senior Consultant"? Apparently not for the topic of "how to >> effectively use a mailing list". See for example the "netiquette" part >> of this: http://www.openbsd.org/mail.html > > Yikes, forget netequitte, how about showing some common decency? The > only two posts I've seen from you since joining this list yesterday > were rude and condescending. > > Shall we get off of your lawn while we're at it? > > -D > From earnie at users.sourceforge.net Wed Feb 25 22:33:04 2009 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 25 Feb 2009 17:33:04 -0500 Subject: [development] Learn to use a mailing list (was: VIM as an editor.) In-Reply-To: References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> <49A5BF17.9080005@killesreiter.de> Message-ID: <20090225173304.ct2v51xc83k08wg4@mail.progw.org> Quoting Domenic Santangelo : > On Wed, Feb 25, 2009 at 1:58 PM, Gerhard Killesreiter > wrote: >> "Senior Consultant"? Apparently not for the topic of "how to >> effectively use a mailing list". See for example the "netiquette" part >> of this: http://www.openbsd.org/mail.html > > Yikes, forget netequitte, how about showing some common decency? The > only two posts I've seen from you since joining this list yesterday > were rude and condescending. > > Shall we get off of your lawn while we're at it? > Enough from you already. This list isn't about what is the best tool to use and what add-ons you might get for it; but Gerhard didn't even slam you for that. He slammed you because you changed the topic without changing the subject. He's doing his job and as list administrator has the right to prevent your address from posting. So with your attitude, you might already be "off of the lawn". -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://4offer.biz/ -- http://give-me-an-offer.com/ From anthony at thrillist.com Wed Feb 25 22:36:09 2009 From: anthony at thrillist.com (Anthony Wlodarski) Date: Wed, 25 Feb 2009 14:36:09 -0800 Subject: [development] VIM as an editor. In-Reply-To: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> Message-ID: I am going to look at the documentation for VIM tonight and see what might be involved. I will get back to the list with my findings tomorrow morning. -Anthony -- Anthony Wlodarski www.thrillist.com Web Applications Developer 568 Broadway Ste. 605 New York, NY, 10012 (o) 646.786.1944 ________________________________ From: Gordon Heydon Reply-To: Date: Wed, 25 Feb 2009 13:20:07 -0800 To: Subject: Re: [development] VIM as an editor. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I too use vim for development, and I have not created an autocomplete for Drupal. If someone builds one I would love to get a copy. Gordon. On 26/02/2009, at 5:40 AM, Anthony Wlodarski wrote: > I am now running VIM 7.2 and love the tabs and auto complete > features for PHP and other Web based technologies. Has anyone > written a auto complete file yet for Drupal 5/6/7 branches yet? > > Regards, > Anthony > -- > Anthony Wlodarski > www.thrillist.com > Web Applications Developer > 568 Broadway Ste. 605 > New York, NY, 10012 > (o) 646.786.1944 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmltgcACgkQngavurZvkryzGgCeK+3bNIMAc47MxABaep6Q98vo 8J4An1PiwMd3ttGigpTKyaTu9H7JEOeQ =xAcE -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090225/c5254209/attachment.htm From domenic at workhabit.com Wed Feb 25 22:38:37 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Wed, 25 Feb 2009 14:38:37 -0800 Subject: [development] VIM as an editor. In-Reply-To: References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> Message-ID: On Wed, Feb 25, 2009 at 2:36 PM, Anthony Wlodarski wrote: > I will get back to the list with my findings tomorrow morning. Please do, I'm interested... -D From domenic at workhabit.com Wed Feb 25 22:43:23 2009 From: domenic at workhabit.com (Domenic Santangelo) Date: Wed, 25 Feb 2009 14:43:23 -0800 Subject: [development] Learn to use a mailing list (was: VIM as an editor.) In-Reply-To: <20090225173304.ct2v51xc83k08wg4@mail.progw.org> References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> <49A5BF17.9080005@killesreiter.de> <20090225173304.ct2v51xc83k08wg4@mail.progw.org> Message-ID: On Wed, Feb 25, 2009 at 2:33 PM, Earnie Boyd wrote: ]> Enough from you already. NO U > Gerhard didn't even slam you for > that. ?He slammed you because you changed the topic without changing the > subject. Kindly review who's talking about what before getting sanctimonious. Many thanks, -D From josh at chapterthree.com Thu Feb 26 01:58:04 2009 From: josh at chapterthree.com (Josh Koenig) Date: Wed, 25 Feb 2009 17:58:04 -0800 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <49A4BB6D.30208@synerger.com> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A4BB6D.30208@synerger.com> Message-ID: <223073f60902251758y504d7b29s3f3026abd720a0dc@mail.gmail.com> > There is the issue of distinguishing cacheable and non-cacheable fields. > Does D7 Fields API flag fields as cacheable to make this simpler? Off the top of my head, it would somewhat defeat the purpose of object-caching to try and handle this on the per-field basis. You'd really need field-level caching then, which is an order of magnitude more in complexity (if not more). That said, I'm not sure what a "non cacheable" field would be like, unless it was some kind of php computed value, which seems like an edge case. Am I mistaking your meaning here? In mose cases, the field values should only change when the object itself is updated, at which point the cache would be invalidated anyway, and the next load would be fresh. This does break down if there's a computed value in a field. The most basic example I can think of is a node with PHP content for the body. Maybe something that displays the current time. As it stands, I believe Drupal's page caching system grabs the output of that PHP and stores it for anonymous users, meaning they'll get out-of-date computations. That's potentially a big deal if you're talking about object-level caching for logged-in users, so perhaps we would treat nodes like this as "uncacheable." Anyway, let me know if I'm way off here. I'll also be checking up on Nedjo's patch, as that definitely seems like the right architectural solution for drupal 7 core. cheers -j From drupal.beginner at wechange.org Thu Feb 26 02:04:19 2009 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Thu, 26 Feb 2009 10:04:19 +0800 Subject: [development] VIM as an editor: Drupal handbook In-Reply-To: References: Message-ID: <200902261004.20862.drupal.beginner@wechange.org> On Thursday 26 February 2009 06:36:09 Anthony Wlodarski wrote: > I am going to look at the documentation for VIM tonight and see what might > be involved. A whole section of the Drupal handbook is dedicated to the development environment: http://drupal.org/setting-up-development-environment There is a page about configuring VIM for Drupal development: http://drupal.org/node/29325 So while all of you are discussing IDEs in general and VIM in particular, you might want to make sure the aforementioned section is updated at the same time. Blessings, Augustin. From catch56 at googlemail.com Thu Feb 26 04:28:42 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 25 Feb 2009 23:28:42 -0500 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <223073f60902251758y504d7b29s3f3026abd720a0dc@mail.gmail.com> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A4BB6D.30208@synerger.com> <223073f60902251758y504d7b29s3f3026abd720a0dc@mail.gmail.com> Message-ID: In the node_load() caching patch we've added a hook_nodeapi_post_load() which is uncached - so poll implements hook_nodeapi_load() to get the options in there, and hook_nodeapi_post_load() to get user-specific information. There may well be a use case for a field_attach equivalent which does the same thing. Field already has a cache though, so if we're caching objects persistently there'd actually be no change on this specific point. Nat On Wed, Feb 25, 2009 at 8:58 PM, Josh Koenig wrote: > > There is the issue of distinguishing cacheable and non-cacheable fields. > > Does D7 Fields API flag fields as cacheable to make this simpler? > > Off the top of my head, it would somewhat defeat the purpose of > object-caching to try and handle this on the per-field basis. You'd > really need field-level caching then, which is an order of magnitude > more in complexity (if not more). > > That said, I'm not sure what a "non cacheable" field would be like, > unless it was some kind of php computed value, which seems like an > edge case. Am I mistaking your meaning here? In mose cases, the field > values should only change when the object itself is updated, at which > point the cache would be invalidated anyway, and the next load would > be fresh. > > This does break down if there's a computed value in a field. The most > basic example I can think of is a node with PHP content for the body. > Maybe something that displays the current time. As it stands, I > believe Drupal's page caching system grabs the output of that PHP and > stores it for anonymous users, meaning they'll get out-of-date > computations. > > That's potentially a big deal if you're talking about object-level > caching for logged-in users, so perhaps we would treat nodes like this > as "uncacheable." > > Anyway, let me know if I'm way off here. > > I'll also be checking up on Nedjo's patch, as that definitely seems > like the right architectural solution for drupal 7 core. > > cheers > -j > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090225/16303969/attachment.htm From yuval at avramzon.net Thu Feb 26 11:47:52 2009 From: yuval at avramzon.net (Yuval Hager) Date: Thu, 26 Feb 2009 13:47:52 +0200 Subject: [development] VIM as an editor. In-Reply-To: <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> References: <7D9CD989-4E1E-4146-B755-7EBCE187A87A@heydon.com.au> <445719130902251339je6e78c7q28a480e7bce64700@mail.gmail.com> Message-ID: <200902261347.52879.yuval@avramzon.net> On Wednesday 25 February 2009, Jon Antoine wrote: > Since the topic of an IDE has come up, I'm curious as to how valuable > a system would be that offers line by line debugging? Actually at this point of your email I thought this is going to be yet another VIM+xdebug fan (like me), but the rest was less relevant in this regard.. :) --y -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20090226/f7d3a67c/attachment.pgp From nabil at gobrighttree.com Thu Feb 26 16:21:52 2009 From: nabil at gobrighttree.com (Nabil Alsharif) Date: Thu, 26 Feb 2009 10:21:52 -0600 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A4BB6D.30208@synerger.com> <223073f60902251758y504d7b29s3f3026abd720a0dc@mail.gmail.com> Message-ID: <1235665312.3437.48.camel@al-sa3ek.lappy> This is my first post on this list so pleas enlighten the ignorant. IMO having a hook_nodeapi_load and hook_nodeapi_post_load could get a little confusing and is redundant. I agree with Josh in that there should be a $node->cacheable field. The question is where does drupal check this field? For example I could create a cache friendly content type and set the nodes of that type to cacheable in (say hook_load). Another module could come along and alter that node (hook_nodeapi_*) in a way that isn't cache friendly and designate to as non-cacheable, what then? On Wed, 2009-02-25 at 23:28 -0500, Nathaniel Catchpole wrote: > In the node_load() caching patch we've added a > hook_nodeapi_post_load() which is uncached - so poll implements > hook_nodeapi_load() to get the options in there, and > hook_nodeapi_post_load() to get user-specific information. > > There may well be a use case for a field_attach equivalent which does > the same thing. Field already has a cache though, so if we're caching > objects persistently there'd actually be no change on this specific > point. > > Nat > > On Wed, Feb 25, 2009 at 8:58 PM, Josh Koenig > wrote: > > There is the issue of distinguishing cacheable and > non-cacheable fields. > > Does D7 Fields API flag fields as cacheable to make this > simpler? > > > Off the top of my head, it would somewhat defeat the purpose > of > object-caching to try and handle this on the per-field basis. > You'd > really need field-level caching then, which is an order of > magnitude > more in complexity (if not more). > > That said, I'm not sure what a "non cacheable" field would be > like, > unless it was some kind of php computed value, which seems > like an > edge case. Am I mistaking your meaning here? In mose cases, > the field > values should only change when the object itself is updated, > at which > point the cache would be invalidated anyway, and the next load > would > be fresh. > > This does break down if there's a computed value in a field. > The most > basic example I can think of is a node with PHP content for > the body. > Maybe something that displays the current time. As it stands, > I > believe Drupal's page caching system grabs the output of that > PHP and > stores it for anonymous users, meaning they'll get out-of-date > computations. > > That's potentially a big deal if you're talking about > object-level > caching for logged-in users, so perhaps we would treat nodes > like this > as "uncacheable." > > Anyway, let me know if I'm way off here. > > I'll also be checking up on Nedjo's patch, as that definitely > seems > like the right architectural solution for drupal 7 core. > > cheers > -j > -- ?---------------------------------- Nabil Alsharif Bright Tree 573-499-1244 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. Please consider the environment before printing this email or its attachment(s). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.drupal.org/pipermail/development/attachments/20090226/21a16fb7/attachment-0001.pgp From catch56 at googlemail.com Thu Feb 26 16:19:06 2009 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 26 Feb 2009 11:19:06 -0500 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <1235665312.3437.48.camel@al-sa3ek.lappy> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A4BB6D.30208@synerger.com> <223073f60902251758y504d7b29s3f3026abd720a0dc@mail.gmail.com> <1235665312.3437.48.camel@al-sa3ek.lappy> Message-ID: On Thu, Feb 26, 2009 at 11:21 AM, Nabil Alsharif wrote: > > IMO having a hook_nodeapi_load and hook_nodeapi_post_load could get a > little confusing and is redundant. I agree with Josh in that there > should be a $node->cacheable field. > This was in some of the earlier iterations of http://drupal.org/node/111127- the issue is that one rogue contrib module could completely disable node caching on a site by setting this flag. With _load() and _post_load() the worst that happens if you get them confused is you end up with some stale data or a single module not taking advantage of the cache as well as it could. Either way, would be really great to have some more reviews of the issue itself, since it's been sitting at RTBC for a while, and discussion on this list doesn't get taken into account on the issue queue. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090226/55436abc/attachment.htm From larry at garfieldtech.com Thu Feb 26 17:00:43 2009 From: larry at garfieldtech.com (larry at garfieldtech.com) Date: Thu, 26 Feb 2009 11:00:43 -0600 Subject: [development] Object Caching in DRUPAL-7? In-Reply-To: <1235665312.3437.48.camel@al-sa3ek.lappy> References: <223073f60902221054hb3a292fqc1cc0d40433373d0@mail.gmail.com> <49A4BB6D.30208@synerger.com> <223073f60902251758y504d7b29s3f3026abd720a0dc@mail.gmail.com> <1235665312.3437.48.camel@al-sa3ek.lappy> Message-ID: <49A6CABB.8040401@garfieldtech.com> Nabil Alsharif wrote: > This is my first post on this list so pleas enlighten the ignorant. > > IMO having a hook_nodeapi_load and hook_nodeapi_post_load could get a > little confusing and is redundant. I agree with Josh in that there > should be a $node->cacheable field. > > The question is where does drupal check this field? For example I could > create a cache friendly content type and set the nodes of that type to > cacheable in (say hook_load). Another module could come along and alter > that node (hook_nodeapi_*) in a way that isn't cache friendly and > designate to as non-cacheable, what then? You've just answered your own question. :-) Your second paragraph is the very reason why there's a two step build process (cacheable and not) rather than a single kill-switch flag. (At least that's how I interpret it; I wasn't involved in the original patch.) --Larry Garfield From darrel.opry at gmail.com Thu Feb 26 21:15:47 2009 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Thu, 26 Feb 2009 16:15:47 -0500 Subject: [development] Modules up for grabs to qualified individuals... Message-ID: I'll be bowing out of Drupal development for a while. The following modules would like new maintainers. Daylife, Derivative, Fapilicious, FFMpeg, Filefield, GeoLocation, ImageAPI, Imagecache, Imagefield, MimeDetect, NodeReferrer, and Transformer. If you're interested in taking over one of the modules send me an email with your plans for the module, why you think you're qualified, and links to your other work. .darrel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090226/104af9af/attachment.htm From yuval at avramzon.net Thu Feb 26 23:29:32 2009 From: yuval at avramzon.net (Yuval Hager) Date: Fri, 27 Feb 2009 01:29:32 +0200 Subject: [development] Modules up for grabs to qualified individuals... In-Reply-To: References: Message-ID: <200902270129.33411.yuval@avramzon.net> On Thursday 26 February 2009, Darrel O'Pry wrote: > I'll be bowing out of Drupal development for a while. > The following modules > would like new maintainers. > Daylife, Derivative, Fapilicious, FFMpeg, > Filefield, GeoLocation, ImageAPI, Imagecache, Imagefield, MimeDetect, > NodeReferrer, and Transformer. > Are you serious? There are quite a lot of stuff going with this modules - without you it won't be the same... :( --y -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20090227/0f09b62e/attachment.pgp From yuval at avramzon.net Fri Feb 27 22:04:05 2009 From: yuval at avramzon.net (Yuval Hager) Date: Sat, 28 Feb 2009 00:04:05 +0200 Subject: [development] [off topic] schema-less data Message-ID: <200902280004.05793.yuval@avramzon.net> Hi, The following post discusses how FriendFeed uses MySQL in a schema-less data model: http://bret.appspot.com/entry/how-friendfeed-uses-mysql. They report an improvement both on speed, stability and flexibility. I find this very interesting, and actually quite troubling. Does one really benefit from moving *away* from RDBMS's? My natural way of thinking is totally different - whenever we can define the business logic in relational terms, we should let the database do the heavylifting, and push *more* logic onto it - cause that's what they do best. I marked this as off topic, cause it's not really Drupal related, but I'm curious about your insights about this approach. We've had our bunch of off-topics in this and the consulting list for this week, so my apologies if this is too much. Cheers, -- Yuval Hager [@] yuval at avramzon.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20090228/764f0d31/attachment.pgp From metzlerd at metzlerd.com Sat Feb 28 03:28:52 2009 From: metzlerd at metzlerd.com (David Metzler) Date: Fri, 27 Feb 2009 19:28:52 -0800 Subject: [development] [off topic] schema-less data In-Reply-To: <200902280004.05793.yuval@avramzon.net> References: <200902280004.05793.yuval@avramzon.net> Message-ID: Oh where oh where has my PostGres gone? Amazingly enough no mention of postgres. Seemed, in reading this discussion a battle of the extremes. So the truth is probably in the middle. They represent the false choice between MySQL and Oracle, and I think there's a lot to be mentioned about the middle ground. I'm frankly amazed that they never tried it. It's clear that Drupal gets great benefit from caching serialized structures and often doesn't do more than use the DB layer as a filestore, that being said, I think this is a discussion of the nature of the data. They don't give a lot of discussion about what it takes in IO to modify the middle of a JSON store. Nor do they talk much about analysis of data, (show me all the feeds that have more than 600 common occurances). Really from a cursory inspection it sounds like the data needs for the product are pretty simple. It says something if they think they can write their own indexes and be faster than the RDBMS. I'll leave it to you to decide as to wether it says more about the developer or the RDBMS they are working with :). MySql is great, but I don't think its ever been considered to be the fastest RDBMS. I think they probably could have done well to consider just switching DB's. But who knows, now that their not using their RDBMS, maybe they'll remember that there's more than one open source RDBMS out there. Anyway, I'm not giving up my RDBMS any time soon. Dave On Feb 27, 2009, at 2:04 PM, Yuval Hager wrote: > Hi, > > The following post discusses how FriendFeed uses MySQL in a schema- > less data > model: http://bret.appspot.com/entry/how-friendfeed-uses-mysql. > > They report an improvement both on speed, stability and flexibility. > > I find this very interesting, and actually quite troubling. > Does one really benefit from moving *away* from RDBMS's? My natural > way of > thinking is totally different - whenever we can define the business > logic in > relational terms, we should let the database do the heavylifting, > and push > *more* logic onto it - cause that's what they do best. > > I marked this as off topic, cause it's not really Drupal related, > but I'm > curious about your insights about this approach. > > We've had our bunch of off-topics in this and the consulting list > for this > week, so my apologies if this is too much. > > Cheers, > > -- > Yuval Hager > [@] yuval at avramzon.net From karim.ratib at gmail.com Sat Feb 28 19:26:02 2009 From: karim.ratib at gmail.com (Karim Ratib) Date: Sat, 28 Feb 2009 11:26:02 -0800 Subject: [development] What's the best way to close a project? Message-ID: Hello all, I've been maintaining a module that I now feel would be better bundled with its parent module, which I also maintain. Specifically, the Workflow Graph (http://drupal.org/project/workflow_graph) module is tiny and depends totally on Graphviz Filter (http://drupal.org/project/graphviz_filter). I have added the Workflow Graph files to the latest release of Graphviz Filter, and I would now like to close the Workflow Graph project page (and CVS folder too if possible). My question is: what's the best practice to do so? How would that affect running instances of Workflow Graph (which in this case, are only a handful)? Thanks for your advice, K. From kb at 2bits.com Sat Feb 28 21:39:09 2009 From: kb at 2bits.com (Khalid Baheyeldin) Date: Sat, 28 Feb 2009 16:39:09 -0500 Subject: [development] What's the best way to close a project? In-Reply-To: References: Message-ID: <4a9fdc630902281339o4b3c821bn6cbee1f1c27afa8d@mail.gmail.com> On Sat, Feb 28, 2009 at 2:26 PM, Karim Ratib wrote: > Hello all, > > I've been maintaining a module that I now feel would be better bundled > with its parent module, which I also maintain. Specifically, the > Workflow Graph (http://drupal.org/project/workflow_graph) module is > tiny and depends totally on Graphviz Filter > (http://drupal.org/project/graphviz_filter). > > I have added the Workflow Graph files to the latest release of > Graphviz Filter, and I would now like to close the Workflow Graph > project page (and CVS folder too if possible). My question is: what's > the best practice to do so? How would that affect running instances of > Workflow Graph (which in this case, are only a handful)? > If it was me, I would do the following: - Check the code from the module to be obsoleted into the parent module. - Do a tag and release for it for the version(s) that are available of the old module. - Then go into Edit then Releases and uncheck all the releases that you have. - Put a big notice on the project saying "this is now part of XYZ", and the steps needed to switch. - Keep the project node published for a while, so users would know. I think that the users of the module will not see "revoked" or something like that, and will go to the project and know what is happening. Since graphviz is required by workflow graph, they will also get a notice to upgrade the module via update/update_status. > Thanks for your advice, > K. > -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20090228/051d074d/attachment-0001.htm