From jpetso at gmx.at Sun Jun 1 00:20:02 2008 From: jpetso at gmx.at (Jakob Petsovits) Date: Sun, 1 Jun 2008 02:20:02 +0200 Subject: [development] Trust (was: Hit and run contrib) In-Reply-To: <200805311038.42473.jpetso@gmx.at> References: <200805311038.42473.jpetso@gmx.at> Message-ID: <200806010220.02369.jpetso@gmx.at> On Saturday, 31. May 2008, Jakob Petsovits wrote: [snip] > But that is the core of the issue at hand here - we've got lots of CVS > accounts, but we don't trust them a single bit. Instead of relying on trust > and goodwill, we rely on technical measures to lock out potential helpers > before they even get the chance to do something wrong. [snip] Ok, I figured that people way smarter than me would have no problem demonstrating why we should not do it the way that I proposed. I can live with that :) Hope it was not a complete waste of your time, maybe someone else can find a way some time on how not to make mistrust the default. So yeah, I'm done with this again already :P Thanks for reading, Jakob P.S.: Views was probably the worst possible example, with a highly skilled *and* incredibly active maintainer making random commit access not only unnecessary but (as rightly stated) also counter-productive. A better example would have been more low-profile stuff like http://drupal.org/project/comment_cck, where the maintainer hasn't committed or posted to the issue queue for half a year, with a couple of patches including a Drupal 6 port being left out in the queue. That's the classical example of a project that should be lead by the community instead of a single maintainer. From jpetso at gmx.at Sun Jun 1 00:24:38 2008 From: jpetso at gmx.at (Jakob Petsovits) Date: Sun, 1 Jun 2008 02:24:38 +0200 Subject: [development] Trust (was: Hit and run contrib) In-Reply-To: <48417755.6010003@logrus.com> References: <200805311038.42473.jpetso@gmx.at> <48417755.6010003@logrus.com> Message-ID: <200806010224.39167.jpetso@gmx.at> On Saturday, 31. May 2008, Earl Miles wrote: > Jakob Petsovits wrote: > > On the other hand, just recently I noticed a missing break; statement > > somewhere in Views. Checked out with CVS. But it didn't directly concern > > me or pose any problems to what I was doing, and opening up a new issue > > would have taken more time and effort than I was willing to put in. Like, > > "someone will probably fix it anyways". With commit access, I would have > > committed the fix right away, and in the unlikely case that it's actually > > wrong (and a "// fall through" comment would be required instead) then > > Earl would have noticed and fixed it the right way. It's probably still > > unfixed, I guess. > > > > Now you can critizise me for being lazy, but I think this is symptomatic > > and happens all the time. If we want to scale contrib, we need to lower > > the contribution barrier for people who are able to fix stuff, while > > raising the barrier for people who break stuff. > > I just grepped and looked at 43 instances of switch() in Views 1. > > I find one case that might look like a missing break in the theme > wizard; and it's kind of odd. Otherwise, nada. Waste of my time. Views 2. Ok, let me see if I can dig this up again... don't know anymore where I found it, but perhaps it's still in there somewhere. See you in your issue queue, Jakob From drupal-devel at webchick.net Sun Jun 1 00:32:00 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Sat, 31 May 2008 20:32:00 -0400 Subject: [development] Trust (was: Hit and run contrib) In-Reply-To: <200806010220.02369.jpetso@gmx.at> References: <200805311038.42473.jpetso@gmx.at> <200806010220.02369.jpetso@gmx.at> Message-ID: <4841EE00.7080403@webchick.net> Jakob Petsovits wrote: > On Saturday, 31. May 2008, Jakob Petsovits wrote: > [snip] >> But that is the core of the issue at hand here - we've got lots of CVS >> accounts, but we don't trust them a single bit. Instead of relying on trust >> and goodwill, we rely on technical measures to lock out potential helpers >> before they even get the chance to do something wrong. > [snip] > > Ok, I figured that people way smarter than me would have no problem > demonstrating why we should not do it the way that I proposed. > I can live with that :) > > Hope it was not a complete waste of your time, maybe someone else can > find a way some time on how not to make mistrust the default. No, it was a fine suggestion, no worries. :) Plus it was fun to re-live my days as a total n00b. ;) The only thing I could think of is some kind of flag a maintainer can optionally (opt-in!) set to mark their project "open" which allows anyone who wants to to commit stuff to it. I'd probably do that with every single one of my modules, since I'm a truly awful maintainer. :D And then people like Earl Miles could NOT opt-in since his module is important and he's clueful about its inner workings, but d.o webmasters could enable this flag if a module was known to be abandoned and not have a suitable person to take over. I wouldn't put this higher on the priority list than other things though, like, say, porting Project* to D6. :) -Angie From jpetso at gmx.at Sun Jun 1 00:38:19 2008 From: jpetso at gmx.at (Jakob Petsovits) Date: Sun, 1 Jun 2008 02:38:19 +0200 Subject: [development] Trust (was: Hit and run contrib) In-Reply-To: <200806010224.39167.jpetso@gmx.at> References: <200805311038.42473.jpetso@gmx.at> <48417755.6010003@logrus.com> <200806010224.39167.jpetso@gmx.at> Message-ID: <200806010238.19787.jpetso@gmx.at> On Sunday, 1. June 2008, Jakob Petsovits wrote: > On Saturday, 31. May 2008, Earl Miles wrote: > > I just grepped and looked at 43 instances of switch() in Views 1. > > > > I find one case that might look like a missing break in the theme > > wizard; and it's kind of odd. Otherwise, nada. Waste of my time. > > Views 2. Ok, let me see if I can dig this up again... don't know anymore > where I found it, but perhaps it's still in there somewhere. Ok, found it, and it seems that it's indeed intended (for reference, 'style_options' vs. 'row_options'). So shame on me and further reinforcing the notion that I should not be granted commit access to Views. Putting a // fall through comment instead of the break; might help avoiding stupid monkeys like me, though. Sorry for wasting your time; friends?, Jakob From merlin at logrus.com Sun Jun 1 06:33:01 2008 From: merlin at logrus.com (Earl Miles) Date: Sat, 31 May 2008 23:33:01 -0700 Subject: [development] Trust (was: Hit and run contrib) In-Reply-To: <200806010238.19787.jpetso@gmx.at> References: <200805311038.42473.jpetso@gmx.at> <48417755.6010003@logrus.com> <200806010224.39167.jpetso@gmx.at> <200806010238.19787.jpetso@gmx.at> Message-ID: <4842429D.1010009@logrus.com> Jakob Petsovits wrote: > On Sunday, 1. June 2008, Jakob Petsovits wrote: >> On Saturday, 31. May 2008, Earl Miles wrote: >>> I just grepped and looked at 43 instances of switch() in Views 1. >>> >>> I find one case that might look like a missing break in the theme >>> wizard; and it's kind of odd. Otherwise, nada. Waste of my time. >> Views 2. Ok, let me see if I can dig this up again... don't know anymore >> where I found it, but perhaps it's still in there somewhere. > > Ok, found it, and it seems that it's indeed intended > (for reference, 'style_options' vs. 'row_options'). > > So shame on me and further reinforcing the notion that I should not > be granted commit access to Views. > > Putting a > // fall through > comment instead of the > break; > might help avoiding stupid monkeys like me, though. > > Sorry for wasting your time; friends?, Hehe. No prob. =) From yuval at avramzon.net Sun Jun 1 12:07:50 2008 From: yuval at avramzon.net (Yuval Hager) Date: Sun, 1 Jun 2008 15:07:50 +0300 Subject: [development] Change URL on ajax call, but enforce access checks? Message-ID: <200806011507.51530.yuval@avramzon.net> Hi, I'm trying to understand what is the best way to supply URL based content through Ajax, without compromising on security and access control. When the user clicks on the widget, an ajax URL is called upon and served by a menu callback (e.g. http://example.com/myajax). I'd like to also relate to the URL that the widget is displayed upon. This is easily achieved by using a GET parameter on the ajax URL (e.g. http://example.com/myajax?referer=user/2) The myajax callback might call other functions in the system that use argument checking (e.g. arg(0) == 'user' && is_numeric(arg(1) )). This is necessary if I want to use the same functions to generate content for the non-JS version. Therefore, I set: before calling those other functions. Assuming I don't know anything about those "other functions", this looks to me like a security risk. Since the whole access sub-system is using 'myajax' as the path for access checks. Those "other functions" might assume that access checks where already ran by Drupal subsystem, which I just bypassed. Can you see a better way to implement this? maybe I should check _menu_item_is_accessible(menu_set_active_item($_GET['referer']))? It seems to work but looks a bit hackish to me... Any help will be appreciated, Thanks, -- Yuval Hager [T] +972-77-341-4155 [@] yuval at avramzon.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20080601/35f087ff/attachment.pgp From weitzman at tejasa.com Sun Jun 1 13:18:57 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Sun, 1 Jun 2008 09:18:57 -0400 Subject: [development] Change URL on ajax call, but enforce access checks? In-Reply-To: <200806011507.51530.yuval@avramzon.net> References: <200806011507.51530.yuval@avramzon.net> Message-ID: <6117a7500806010618v6f12a214r795ee4d07ddacf86@mail.gmail.com> arg() checking is discouraged in modern drupal for this very reason. each drupal release we have been able to get rid of more of them in core and with the D6 menu system, I really doubt we need any of these calls to arg(). contrib modules that use arg() for access control should refactor and let the menu system handle access control. your workaround looks fine if it works and has no side effects. needs testing. From gerhard at killesreiter.de Sun Jun 1 14:34:27 2008 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Sun, 01 Jun 2008 16:34:27 +0200 Subject: [development] Hit and run contrib In-Reply-To: <8893724B-7333-4439-BEDE-7980A5E69D93@dwwright.net> References: <069101c8c1f3$28e02110$0200a8c0@structworks.com> <8893724B-7333-4439-BEDE-7980A5E69D93@dwwright.net> Message-ID: <4842B373.6040107@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb: > > On May 29, 2008, at 6:19 PM, Daniel F. Kudwien wrote: > >> we encourage maintainers to commit patches and credit the contributor(s) >> using a message of the following syntax: >> >> "#12345 by sun: Fixed coding-style." >> >> We are parsing the "#12345" bit, but why don't we also parse the "by sun" >> bit to assign 'contributor credits' to users for the corresponding >> project? > > Because killes said "I think enforcing conventions on cvs committers > is a bad idea." Well, we can of course ask nicely. ;) It is probably in the best interest of a module maintainer to play nice with the contributors. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQrNzfg6TFvELooQRAmXcAJ4tIG99x1SRPPDBSPcQemFDFPnzwACdHiOG BkRu0exRNHWK3cR+sfGX5sU= =hmpY -----END PGP SIGNATURE----- From mike at mikeyp.net Sun Jun 1 19:42:44 2008 From: mike at mikeyp.net (Michael Prasuhn) Date: Sun, 1 Jun 2008 12:42:44 -0700 Subject: [development] Hit and run contrib In-Reply-To: <4842B373.6040107@killesreiter.de> References: <069101c8c1f3$28e02110$0200a8c0@structworks.com> <8893724B-7333-4439-BEDE-7980A5E69D93@dwwright.net> <4842B373.6040107@killesreiter.de> Message-ID: Another issue I've noticed, is users contributing what amounts to site specific modules, that duplicate another module with small differences, such as would be specific to only a single site. The motive for this seems to be either clients, development companies, or individuals who are seeking credit or trying to improve appearances by having contributed modules in their name. Now for my speculation on the issue, this may be due to the general attitude in the Drupal community that the way to evaluate a members skill, or value, is by CVS commit logs, or core patches submitted. While this is a good way to evaluate, it may be the value placed on such a metric, that causes people to strive to find a way to be visible, without considering quality or consequences to new users in terms of duplicated modules. I for one, know that I have had multiple employers look at my d.o account and cvs log, yet I know that at least one of them did not ever read the code associated with it. I don't know what the real solution to this problem is, but I know that I am guilty of striving to have something committed in CVS, without regard to quality, commitment to maintain it, or overall quality. -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax From blogdiva at culturekitchen.com Mon Jun 2 00:54:48 2008 From: blogdiva at culturekitchen.com (Liza Sabater) Date: Sun, 01 Jun 2008 20:54:48 -0400 Subject: [development] Hit and run contrib In-Reply-To: References: <38ad0b0a0805261907h38fc57cep5f30cb4e9f541f3b@mail.gmail.com> <20080527081813.snuit13m4jc0k4c0@mail.progw.org> <483C580A.2090300@intermedia-online.com> <4a9fdc630805271322jc2e1a7dob9e15407c19e53c6@mail.gmail.com> Message-ID: <484344D8.6000900@culturekitchen.com> An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080601/0cea10fe/attachment.htm From drupal-devel at webchick.net Mon Jun 2 01:34:11 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Sun, 01 Jun 2008 21:34:11 -0400 Subject: [development] Hit and run contrib In-Reply-To: <484344D8.6000900@culturekitchen.com> References: <38ad0b0a0805261907h38fc57cep5f30cb4e9f541f3b@mail.gmail.com> <20080527081813.snuit13m4jc0k4c0@mail.progw.org> <483C580A.2090300@intermedia-online.com> <4a9fdc630805271322jc2e1a7dob9e15407c19e53c6@mail.gmail.com> <484344D8.6000900@culturekitchen.com> Message-ID: <48434E13.8040108@webchick.net> Liza Sabater wrote: > David Reed wrote: >> how about a simple rating system for for contrib modules > +++1 here are the places to jump in and help: http://groups.drupal.org/drupal-org-redesign-analysis http://groups.drupal.org/issue-tracking-and-software-releases From yuval at avramzon.net Mon Jun 2 04:14:28 2008 From: yuval at avramzon.net (Yuval Hager) Date: Mon, 2 Jun 2008 07:14:28 +0300 Subject: [development] Change URL on ajax call, but enforce access checks? In-Reply-To: <6117a7500806010618v6f12a214r795ee4d07ddacf86@mail.gmail.com> References: <200806011507.51530.yuval@avramzon.net> <6117a7500806010618v6f12a214r795ee4d07ddacf86@mail.gmail.com> Message-ID: <200806020714.31066.yuval@avramzon.net> On Sunday 01 June 2008, Moshe Weitzman wrote: > arg() checking is discouraged in modern drupal for this very reason. > each drupal release we have been able to get rid of more of them in > core and with the D6 menu system, I really doubt we need any of these > calls to arg(). contrib modules that use arg() for access control > should refactor and let the menu system handle access control. > > your workaround looks fine if it works and has no side effects. needs > testing. It looked like it was working in most cases, but there is a certain case where it fails. If user with uid==1 (admin) is browsing the site, running: gets me access denied every time. I tried to follow the code using a debugger, but can't get my head around the structure of $menu. Any idea how to get the access checking results correctly here? (btw, this is Drupal 5.x) -- Yuval Hager [T] +972-77-341-4155 [@] yuval at avramzon.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20080602/11de9fef/attachment.pgp From drupal at dave-cohen.com Mon Jun 2 07:19:53 2008 From: drupal at dave-cohen.com (Dave Cohen) Date: Mon, 2 Jun 2008 00:19:53 -0700 Subject: [development] multiple local task menus Message-ID: <200806020019.54753.drupal@dave-cohen.com> I'm just getting used to the new (Drupal 6) menu system and there's a lot to like about it. I can't quite figure out how to do one thing, though. Is this possible... Those familiar with Organic Groups know that when viewing some pages there is a notion of a "group context". So for example if node/42 is in group 6, then the group context is 6 when visiting ?q=node/42. Similarly, the group context remains 6 on ?q=node/add/book/parent/42 and ?q=comment/edit/123 (if comment 123 is on node 42). What I'd like to do is create menu items that behave like tabs for the group. So whenever the group context is known, the menu items would appear. Imagine ?q=node/42 with tabs like ?q=node/42/edit, ?q=node/42/revisions, etc. That page would also have another set of "tabs" something like ?q=group/6/edit, ?q=group/6/tracker, etc. And those group-specific tabs would also appear on ?q=node/add/book/parent/42 etc, whenever the group context is known. I hope I've explained the question reasonably well. I've read the menu docs on drupal.org and I can't figure a way to do this. Is it possible? Thanks, -Dave From drupal at samboyer.org Mon Jun 2 09:37:27 2008 From: drupal at samboyer.org (Sam Boyer) Date: Mon, 02 Jun 2008 04:37:27 -0500 Subject: [development] Taking a wee bit of the black magic out of Panels Message-ID: <1212399447.6907.22.camel@thereishope> Hi fellow devs, Despite being pedal-to-the-metal trying to get Panels2 to RC, and from there, ported to D6, I do occasionally find time to at least _think_ about doing other things. Like, say, documentation! Documentation is, after all, just about the only thing that'll help clear away some of that aura of mystery shrouding the Panels API. So, with that in mind, I've made what I hope will be a useful first step in that direction. I've written up some pretty thorough documentation of the Panels 'Content Type' plugin; the documentation includes pretty detailed discussion and samples for all twenty of the properties available to content types in the current version of the Panels API. That includes the handful of new ones we added in Beta4. It's a gen-u-ine first draft, but I hope that folks might find it useful, and maybe even comment! The entire system is doxygen-generated, so it's got all those standard code documentation-type features you could hope for, plus a bunch more. The main page of the API docs is at http://doxy.samboyer.org/panels2/ , and the direct link to the content types docs is http://doxy.samboyer.org/panels2/panels_api_plugins_content_types.html . Since everything's generated by doxygen from directly from the source files in the Panels project itself, you can diff/patch and hit the queue like you would with any other code. The doxyfile is included as well, for those who are curious. Or at least it will be tomorrow, once I commit it. Right now, I need sleep. cheers, Sam From tomi at vacilando.org Mon Jun 2 09:48:54 2008 From: tomi at vacilando.org (Tomas J. Fulopp - Vacilando.org) Date: Mon, 02 Jun 2008 11:48:54 +0200 Subject: [development] Hit and run contrib In-Reply-To: References: <38ad0b0a0805261907h38fc57cep5f30cb4e9f541f3b@mail.gmail.com> <20080527081813.snuit13m4jc0k4c0@mail.progw.org> <483C580A.2090300@intermedia-online.com> <4a9fdc630805271322jc2e1a7dob9e15407c19e53c6@mail.gmail.com> Message-ID: <4843C206.4060506@vacilando.org> > how about a simple rating system for for contrib modules Module view and download count would be one of the best measures of popularity. The Project module team's work seems to be almost there - watch/help http://drupal.org/node/165380 Tom?? (Vacilando) From mhaggerty-lists at trellon.com Mon Jun 2 18:24:24 2008 From: mhaggerty-lists at trellon.com (Michael Haggerty) Date: Mon, 2 Jun 2008 14:24:24 -0400 Subject: [development] Request for Comments: Search.inc Message-ID: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> I am writing to request comments on a proposed modification to Drupal core. Proposal: move the core search functionality in Drupal into an include file which can be specified on a per site basis. The actual functions used to return search results would not change, this proposed modification would simply put them all in a file which can be specified within settings.php. There are a number of reasons to consider doing this: 1) The flexibility to specify different search components would resolve some potential design deficiencies in the platform as it stands now. We have been doing some work integrating the Xapian search engine with Drupal. Instead of storing indexed results in the Drupal database, we are putting indexed content in Xapian instead. To get this to work properly, we have needed to patch core, which represents a deficiency both in terms of installation and long term maintenance of sites. Modifications to core mean people are working with unique distributions of Drupal instead of a common distribution, which are more complex to support. 2) This change would not differ significantly from design patterns currently in place within the framework. Other core components have already adopted this approach. An alternate cache.inc file can be specified within settings.php and is used by Robert Douglas' memcache module. Settings.php has had the ability to override system settings for a long time. 3) In some high traffic scenarios, database throughput becomes a bottleneck to the point where Drupal's current search features become unusable in the context in which they are deployed. Providing the flexibility to specify the underlying search components used for Drupal will provide system architects with additional options for scaling Drupal sites without losing characteristic features of the platform. In the case of Xapian, all database traffic related to search features are offloaded into an external database, which could represent significant gains in Drupal database throughput. 4) Open source search engines are becoming increasingly sophisticated, and there are a number of emerging systems coming of age which developers may want to integrate in the future. Developers are often loathe to want to hack core, for reasons ranging from inexperience to lack of support for core modifications within the Drupal community. Being able to modify the underlying search components without the need for a core patch greatly simplifies the process of integration and likely increases the likelihood developers will want to attempt integration projects. 5) Search remains an important component of any Web site. One of the great strengths of Drupal is the ability to provide an integrated set of tools for managing content. The most significant benefit to adopting this approach could be the ability to expand the range of options available to implementers at the time a site is being built. Providing numerous search engine configuration options with relative benefits and drawbacks increases the strength of the platform. Best Regards, Michael Haggerty _______________________________________________ Michael Haggerty | Managing Partner | Trellon, LLC web www.trellon.com | email mhaggerty at trellon.com tel 240 643 6561 | aim haggerty321 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080602/e0a3cc70/attachment-0001.htm From mfburdett at gmail.com Mon Jun 2 18:47:57 2008 From: mfburdett at gmail.com (mark burdett) Date: Mon, 2 Jun 2008 11:47:57 -0700 Subject: [development] Request for Comments: Search.inc In-Reply-To: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> References: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> Message-ID: The main thing I would like to see is splitting search module into a base search api module and a node search module. The latter could be disabled and replaced with any number of alternative node search modules. If it's possible for Xapian search to use the search api, then this might be an even easier solution -- just turn modules on and off, no need to modify a settings file. --mark On Mon, Jun 2, 2008 at 11:24 AM, Michael Haggerty wrote: > I am writing to request comments on a proposed modification to Drupal core. > Proposal: move the core search functionality in Drupal into an include file > which can be specified on a per site basis. The actual functions used to > return search results would not change, this proposed modification would > simply put them all in a file which can be specified within settings.php. > There are a number of reasons to consider doing this: > 1) The flexibility to specify different search components would resolve some > potential design deficiencies in the platform as it stands now. We have been > doing some work integrating the Xapian search engine with Drupal. Instead of > storing indexed results in the Drupal database, we are putting indexed > content in Xapian instead. To get this to work properly, we have needed to > patch core, which represents a deficiency both in terms of installation and > long term maintenance of sites. Modifications to core mean people are > working with unique distributions of Drupal instead of a common > distribution, which are more complex to support. > 2) This change would not differ significantly from design patterns currently > in place within the framework. Other core components have already adopted > this approach. An alternate cache.inc file can be specified within > settings.php and is used by Robert Douglas' memcache module. Settings.php > has had the ability to override system settings for a long time. > 3) In some high traffic scenarios, database throughput becomes a bottleneck > to the point where Drupal's current search features become unusable in the > context in which they are deployed. Providing the flexibility to specify the > underlying search components used for Drupal will provide system architects > with additional options for scaling Drupal sites without losing > characteristic features of the platform. In the case of Xapian, all database > traffic related to search features are offloaded into an external database, > which could represent significant gains in Drupal database throughput. > 4) Open source search engines are becoming increasingly sophisticated, and > there are a number of emerging systems coming of age which developers may > want to integrate in the future. Developers are often loathe to want to hack > core, for reasons ranging from inexperience to lack of support for core > modifications within the Drupal community. Being able to modify the > underlying search components without the need for a core patch greatly > simplifies the process of integration and likely increases the likelihood > developers will want to attempt integration projects. > 5) Search remains an important component of any Web site. One of the great > strengths of Drupal is the ability to provide an integrated set of tools for > managing content. The most significant benefit to adopting this approach > could be the ability to expand the range of options available to > implementers at the time a site is being built. Providing numerous search > engine configuration options with relative benefits and drawbacks increases > the strength of the platform. > Best Regards, > Michael Haggerty > _______________________________________________ > Michael Haggerty | Managing Partner | Trellon, LLC > > web www.trellon.com | email mhaggerty at trellon.com > tel 240 643 6561 | aim haggerty321 > From agentrickard at gmail.com Mon Jun 2 19:33:58 2008 From: agentrickard at gmail.com (Ken Rickard) Date: Mon, 2 Jun 2008 15:33:58 -0400 Subject: [development] Request for Comments: Search.inc In-Reply-To: References: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> Message-ID: <25b45da00806021233i301e03c6s11ec1d5d6d561d92@mail.gmail.com> Please open an issue for this (if there isn't one already) and move the discussion there. Personally, without any deep research, I like this idea. Much like cache.inc in D6. - Ken On Mon, Jun 2, 2008 at 2:47 PM, mark burdett wrote: > The main thing I would like to see is splitting search module into a > base search api module and a node search module. The latter could be > disabled and replaced with any number of alternative node search > modules. If it's possible for Xapian search to use the search api, > then this might be an even easier solution -- just turn modules on and > off, no need to modify a settings file. > > --mark > > On Mon, Jun 2, 2008 at 11:24 AM, Michael Haggerty > wrote: > > I am writing to request comments on a proposed modification to Drupal > core. > > Proposal: move the core search functionality in Drupal into an include > file > > which can be specified on a per site basis. The actual functions used to > > return search results would not change, this proposed modification would > > simply put them all in a file which can be specified within settings.php. > > There are a number of reasons to consider doing this: > > 1) The flexibility to specify different search components would resolve > some > > potential design deficiencies in the platform as it stands now. We have > been > > doing some work integrating the Xapian search engine with Drupal. Instead > of > > storing indexed results in the Drupal database, we are putting indexed > > content in Xapian instead. To get this to work properly, we have needed > to > > patch core, which represents a deficiency both in terms of installation > and > > long term maintenance of sites. Modifications to core mean people are > > working with unique distributions of Drupal instead of a common > > distribution, which are more complex to support. > > 2) This change would not differ significantly from design patterns > currently > > in place within the framework. Other core components have already adopted > > this approach. An alternate cache.inc file can be specified within > > settings.php and is used by Robert Douglas' memcache module. Settings.php > > has had the ability to override system settings for a long time. > > 3) In some high traffic scenarios, database throughput becomes a > bottleneck > > to the point where Drupal's current search features become unusable in > the > > context in which they are deployed. Providing the flexibility to specify > the > > underlying search components used for Drupal will provide system > architects > > with additional options for scaling Drupal sites without losing > > characteristic features of the platform. In the case of Xapian, all > database > > traffic related to search features are offloaded into an external > database, > > which could represent significant gains in Drupal database throughput. > > 4) Open source search engines are becoming increasingly sophisticated, > and > > there are a number of emerging systems coming of age which developers may > > want to integrate in the future. Developers are often loathe to want to > hack > > core, for reasons ranging from inexperience to lack of support for core > > modifications within the Drupal community. Being able to modify the > > underlying search components without the need for a core patch greatly > > simplifies the process of integration and likely increases the likelihood > > developers will want to attempt integration projects. > > 5) Search remains an important component of any Web site. One of the > great > > strengths of Drupal is the ability to provide an integrated set of tools > for > > managing content. The most significant benefit to adopting this approach > > could be the ability to expand the range of options available to > > implementers at the time a site is being built. Providing numerous search > > engine configuration options with relative benefits and drawbacks > increases > > the strength of the platform. > > Best Regards, > > Michael Haggerty > > _______________________________________________ > > Michael Haggerty | Managing Partner | Trellon, LLC > > > > web www.trellon.com | email mhaggerty at trellon.com > > tel 240 643 6561 | aim haggerty321 > > > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080602/a90c8d97/attachment.htm From kb at 2bits.com Mon Jun 2 19:48:29 2008 From: kb at 2bits.com (Khalid Baheyeldin) Date: Mon, 2 Jun 2008 15:48:29 -0400 Subject: [development] Request for Comments: Search.inc In-Reply-To: <25b45da00806021233i301e03c6s11ec1d5d6d561d92@mail.gmail.com> References: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> <25b45da00806021233i301e03c6s11ec1d5d6d561d92@mail.gmail.com> Message-ID: <4a9fdc630806021248i6cd90ccar939f5632ab7462c5@mail.gmail.com> > Personally, without any deep research, I like this idea. Much like > cache.inc in D6. > [Minor correction: D5's cache.inc is also pluggable that way]. Yeah, I like this type of pluggability. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080602/3055d531/attachment.htm From weitzman at tejasa.com Mon Jun 2 21:14:41 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Mon, 2 Jun 2008 17:14:41 -0400 Subject: [development] Request for Comments: Search.inc In-Reply-To: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> References: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> Message-ID: <6117a7500806021414w5bf4d59ev9db631af79d12183@mail.gmail.com> > I am writing to request comments on a proposed modification to Drupal core. > Proposal: move the core search functionality in Drupal into an include file > which can be specified on a per site basis. I'm all for more flexible search and indexing. But I fail to see how it is more modular to move all the code from a module and into an include file. Modules can already by be swapped for alternate implementations using our usual modules page. So this would just move something that can be done in the UI into something that has to be done by hand. Probably you want to do some refactoring along the way which is the important part of the proposal. From douggreen at douggreenconsulting.com Mon Jun 2 21:14:42 2008 From: douggreen at douggreenconsulting.com (Doug Green) Date: Mon, 02 Jun 2008 17:14:42 -0400 Subject: [development] Request for Comments: Search.inc In-Reply-To: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> References: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> Message-ID: <484462C2.4010609@douggreenconsulting.com> I invite you to join the search group on g.d.o and make this proposal there: http://groups.drupal.org/node/4102 Please also read all of the blog entries on search that came out of the MINNESOTA SEARCH SPRINT: http://drupal.org/search/node/MINNESOTA+SEARCH+SPRINT http://www.google.com/search?hl=en&q=MINNESOTA+SEARCH+SPRINT&btnG=Google+Search I hope that you help us with this. We have two visions. We'd like to make it possible to extend/separate the indexing and/or extend/separate the UI. Earnest Berry started on separating the UI, but AFAIK nobody has started work on separating the indexing. Thanks! Doug Michael Haggerty wrote: > I am writing to request comments on a proposed modification to Drupal > core. > > Proposal: move the core search functionality in Drupal into an include > file which can be specified on a per site basis. The actual functions > used to return search results would not change, this proposed > modification would simply put them all in a file which can be > specified within settings.php. > > There are a number of reasons to consider doing this: > > 1) The flexibility to specify different search components would > resolve some potential design deficiencies in the platform as it > stands now. We have been doing some work integrating the Xapian search > engine with Drupal. Instead of storing indexed results in the Drupal > database, we are putting indexed content in Xapian instead. To get > this to work properly, we have needed to patch core, which represents > a deficiency both in terms of installation and long term maintenance > of sites. Modifications to core mean people are working with unique > distributions of Drupal instead of a common distribution, which are > more complex to support. > > 2) This change would not differ significantly from design patterns > currently in place within the framework. Other core components have > already adopted this approach. An alternate cache.inc file can be > specified within settings.php and is used by Robert Douglas' memcache > module. Settings.php has had the ability to override system settings > for a long time. > > 3) In some high traffic scenarios, database throughput becomes a > bottleneck to the point where Drupal's current search features become > unusable in the context in which they are deployed. Providing the > flexibility to specify the underlying search components used for > Drupal will provide system architects with additional options for > scaling Drupal sites without losing characteristic features of the > platform. In the case of Xapian, all database traffic related to > search features are offloaded into an external database, which could > represent significant gains in Drupal database throughput. > > 4) Open source search engines are becoming increasingly sophisticated, > and there are a number of emerging systems coming of age which > developers may want to integrate in the future. Developers are often > loathe to want to hack core, for reasons ranging from inexperience to > lack of support for core modifications within the Drupal community. > Being able to modify the underlying search components without the need > for a core patch greatly simplifies the process of integration and > likely increases the likelihood developers will want to attempt > integration projects. > > 5) Search remains an important component of any Web site. One of the > great strengths of Drupal is the ability to provide an integrated set > of tools for managing content. The most significant benefit to > adopting this approach could be the ability to expand the range of > options available to implementers at the time a site is being built. > Providing numerous search engine configuration options with relative > benefits and drawbacks increases the strength of the platform. > > Best Regards, > Michael Haggerty > _______________________________________________ > > Michael Haggerty | Managing Partner | Trellon, LLC > > web www.trellon.com | email mhaggerty at trellon.com > tel 240 643 6561 | aim haggerty321 > > -- Doug Green douggreen at douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention... From darrel.opry at gmail.com Tue Jun 3 00:20:24 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Mon, 2 Jun 2008 20:20:24 -0400 Subject: [development] Request for Comments: Search.inc In-Reply-To: <484462C2.4010609@douggreenconsulting.com> References: <9331868E-0B35-4649-9CDE-8904B01060D5@trellon.com> <484462C2.4010609@douggreenconsulting.com> Message-ID: 1,2) great but Nix the include file, use modules instead. It would be much better implemented using modules and search hooks. Otherwise we'll run into another image.inc and the support issues of how to swap out search systems. You will also end up with the inability to use more than once search system at a time which already afflicts core image, database, and cache API's. I'd rather not see that design patter repeated again. 3,4,5) I think flexibility is reason enough without fluff bullet points saying flexibility, flexibility. .darrel. On Mon, Jun 2, 2008 at 5:14 PM, Doug Green < douggreen at douggreenconsulting.com> wrote: > I invite you to join the search group on g.d.o and make this proposal > there: > > http://groups.drupal.org/node/4102 > > Please also read all of the blog entries on search that came out of the > MINNESOTA SEARCH SPRINT: > > http://drupal.org/search/node/MINNESOTA+SEARCH+SPRINT > > http://www.google.com/search?hl=en&q=MINNESOTA+SEARCH+SPRINT&btnG=Google+Search > > I hope that you help us with this. We have two visions. We'd like to > make it possible to extend/separate the indexing and/or extend/separate > the UI. Earnest Berry started on separating the UI, but AFAIK nobody > has started work on separating the indexing. > > Thanks! > Doug > > Michael Haggerty wrote: > > I am writing to request comments on a proposed modification to Drupal > > core. > > > > Proposal: move the core search functionality in Drupal into an include > > file which can be specified on a per site basis. The actual functions > > used to return search results would not change, this proposed > > modification would simply put them all in a file which can be > > specified within settings.php. > > > > There are a number of reasons to consider doing this: > > > > 1) The flexibility to specify different search components would > > resolve some potential design deficiencies in the platform as it > > stands now. We have been doing some work integrating the Xapian search > > engine with Drupal. Instead of storing indexed results in the Drupal > > database, we are putting indexed content in Xapian instead. To get > > this to work properly, we have needed to patch core, which represents > > a deficiency both in terms of installation and long term maintenance > > of sites. Modifications to core mean people are working with unique > > distributions of Drupal instead of a common distribution, which are > > more complex to support. > > > > 2) This change would not differ significantly from design patterns > > currently in place within the framework. Other core components have > > already adopted this approach. An alternate cache.inc file can be > > specified within settings.php and is used by Robert Douglas' memcache > > module. Settings.php has had the ability to override system settings > > for a long time. > > > > 3) In some high traffic scenarios, database throughput becomes a > > bottleneck to the point where Drupal's current search features become > > unusable in the context in which they are deployed. Providing the > > flexibility to specify the underlying search components used for > > Drupal will provide system architects with additional options for > > scaling Drupal sites without losing characteristic features of the > > platform. In the case of Xapian, all database traffic related to > > search features are offloaded into an external database, which could > > represent significant gains in Drupal database throughput. > > > > 4) Open source search engines are becoming increasingly sophisticated, > > and there are a number of emerging systems coming of age which > > developers may want to integrate in the future. Developers are often > > loathe to want to hack core, for reasons ranging from inexperience to > > lack of support for core modifications within the Drupal community. > > Being able to modify the underlying search components without the need > > for a core patch greatly simplifies the process of integration and > > likely increases the likelihood developers will want to attempt > > integration projects. > > > > 5) Search remains an important component of any Web site. One of the > > great strengths of Drupal is the ability to provide an integrated set > > of tools for managing content. The most significant benefit to > > adopting this approach could be the ability to expand the range of > > options available to implementers at the time a site is being built. > > Providing numerous search engine configuration options with relative > > benefits and drawbacks increases the strength of the platform. > > > > Best Regards, > > Michael Haggerty > > _______________________________________________ > > > > Michael Haggerty | Managing Partner | Trellon, LLC > > > > web www.trellon.com | email mhaggerty at trellon.com > > tel 240 643 6561 | aim haggerty321 > > > > > > > -- > Doug Green > douggreen at douggreenconsulting.com > 904-583-3342 > > Bringing Ideas to Life with Software Artistry and Invention... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080602/05ac6757/attachment.htm From drupal at dwwright.net Tue Jun 3 08:01:59 2008 From: drupal at dwwright.net (Derek Wright) Date: Tue, 3 Jun 2008 01:01:59 -0700 Subject: [development] Hit and run contrib In-Reply-To: <48434E13.8040108@webchick.net> References: <38ad0b0a0805261907h38fc57cep5f30cb4e9f541f3b@mail.gmail.com> <20080527081813.snuit13m4jc0k4c0@mail.progw.org> <483C580A.2090300@intermedia-online.com> <4a9fdc630805271322jc2e1a7dob9e15407c19e53c6@mail.gmail.com> <484344D8.6000900@culturekitchen.com> <48434E13.8040108@webchick.net> Message-ID: On Jun 1, 2008, at 6:34 PM, Angela Byron wrote: > here are the places to jump in and help: More specifically: http://groups.drupal.org/node/7191 Enjoy, -Derek (dww) From stella at stellapower.net Tue Jun 3 15:12:54 2008 From: stella at stellapower.net (Stella Power) Date: Tue, 3 Jun 2008 16:12:54 +0100 Subject: [development] lightbox module comparison Message-ID: Hi, There's quite a few modules in Drupal which provide similar but different functionality. I maintain the lightbox2 module and frequently get asked "what's the difference between lightbox2 and module X?" So I've finally created a doc comparing the various "lightbox" type modules available in Drupal (lightbox2, thickbox, shadowbox, .....). The doc is available at http://drupal.org/node/266126 for anyone who may be interested. I'd really like to see more comparisons done on modules which share similar functionality. I think it would be quite useful to see such a comparison before downloading all the modules and trying them out one by one, especially for newbies in the Drupal community. Just my 2 cents. Cheers, Stella -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080603/39b24fc9/attachment.htm From john at rivul.com Tue Jun 3 15:49:58 2008 From: john at rivul.com (John Horning) Date: Tue, 03 Jun 2008 11:49:58 -0400 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: <48456826.8030701@rivul.com> An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080603/b4e06133/attachment.htm From catch56 at googlemail.com Tue Jun 3 16:25:24 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 3 Jun 2008 17:25:24 +0100 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: On Tue, Jun 3, 2008 at 4:12 PM, Stella Power wrote: > Hi, > > There's quite a few modules in Drupal which provide similar but different > functionality. I maintain the lightbox2 module and frequently get asked > "what's the difference between lightbox2 and module X?" So I've finally > created a doc comparing the various "lightbox" type modules available in > Drupal (lightbox2, thickbox, shadowbox, .....). The doc is available at > http://drupal.org/node/266126 for anyone who may be interested. > > I'd really like to see more comparisons done on modules which share similar > functionality. I think it would be quite useful to see such a comparison > before downloading all the modules and trying them out one by one, > especially for newbies in the Drupal community. Just my 2 cents. > > Very nice write-up. There was a similar one done for Drupal 5 wysiwyg editors as part of GHOP, and it'd be great to see more. I took the liberty of adding a new book page at http://drupal.org/node/266179 for 'Module Comparisons' and adding both as child pages so we can list them together in one place. Also cross-posting to the documentation list. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080603/32b0f998/attachment-0001.htm From mail at webthatworks.it Tue Jun 3 17:58:49 2008 From: mail at webthatworks.it (Ivan Sergio Borgonovo) Date: Tue, 3 Jun 2008 19:58:49 +0200 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: <20080603195849.7db41c60@dawn.webthatworks.it> On Tue, 3 Jun 2008 16:12:54 +0100 "Stella Power" wrote: > Hi, > module X?" So I've finally created a doc comparing the various > "lightbox" type modules available in Drupal (lightbox2, thickbox, > shadowbox, .....). The doc is available at thanks, very appreciated. > http://drupal.org/node/266126 for anyone who may be interested. > I'd really like to see more comparisons done on modules which > share similar functionality. I think it would be quite useful to Me too. -- Ivan Sergio Borgonovo http://www.webthatworks.it From fgm at osinet.fr Tue Jun 3 15:27:32 2008 From: fgm at osinet.fr (FGM) Date: Tue, 3 Jun 2008 17:27:32 +0200 Subject: [development] lightbox module comparison References: Message-ID: <002201c8c58e$6042fd50$2401a8c0@pcosi> I've done one on the two glossary modules I'm aware of (glossary.module and g2.module), it's on the g2 project page. Maybe there are more, though ? This being said, you might have something: module duplication and module voting being recurrent themes, it might make sense to formalize a rule like: "if you're doing a module that resembles other modules, create a comparison page, that will go in the section of the handbook", in the dev manual. What do you think of it ? FGM ----- Original Message ----- From: "Stella Power" To: "Drupal Dev" Sent: Tuesday, June 03, 2008 5:12 PM Subject: [development] lightbox module comparison Hi, There's quite a few modules in Drupal which provide similar but different functionality. I maintain the lightbox2 module and frequently get asked "what's the difference between lightbox2 and module X?" So I've finally created a doc comparing the various "lightbox" type modules available in Drupal (lightbox2, thickbox, shadowbox, .....). The doc is available at http://drupal.org/node/266126 for anyone who may be interested. I'd really like to see more comparisons done on modules which share similar functionality. I think it would be quite useful to see such a comparison before downloading all the modules and trying them out one by one, especially for newbies in the Drupal community. Just my 2 cents. Cheers, Stella From Greg at GrowingVentureSolutions.com Tue Jun 3 18:45:27 2008 From: Greg at GrowingVentureSolutions.com (Greg Knaddison - GVS) Date: Tue, 3 Jun 2008 11:45:27 -0700 Subject: [development] lightbox module comparison In-Reply-To: <002201c8c58e$6042fd50$2401a8c0@pcosi> References: <002201c8c58e$6042fd50$2401a8c0@pcosi> Message-ID: <3861c6770806031145u3ff40cddi92c9cbb46421161@mail.gmail.com> On Tue, Jun 3, 2008 at 8:27 AM, FGM wrote: > This being said, you might have something: module duplication and module > voting being recurrent themes, it might make sense to formalize a rule like: > "if you're doing a module that resembles other modules, create a comparison > page, that will go in the section of the handbook", in > the dev manual. > > What do you think of it ? I've been submitting issues in the queue requesting that the author of the second module updates their page to include a link to the original one and clarifies what the differences are in their module from the original one. Most folks have been willing to do this. If there are more duplicates than an original and a new...definitely having a page to compare seems like a good policy. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg From syscrusher at 4th.com Tue Jun 3 19:24:18 2008 From: syscrusher at 4th.com (Syscrusher) Date: Tue, 03 Jun 2008 15:24:18 -0400 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: <48459A62.1090703@4th.com> Nathaniel Catchpole wrote: > I took the > liberty of adding a new book page at http://drupal.org/node/266179 for > 'Module Comparisons' and adding both as child pages so we can list them > together in one place. Also cross-posting to the documentation list. Thanks! Before seeing your post, I happened to notice and use the new node (coincidentally), and thought to myself how helpful it was that there was such a grouping. I didn't realize it was new....good idea! Syscrusher From wdlists at optonline.net Tue Jun 3 20:34:04 2008 From: wdlists at optonline.net (Walt Daniels) Date: Tue, 03 Jun 2008 16:34:04 -0400 Subject: [development] CCK and Views data structures screwed up In-Reply-To: <48459A62.1090703@4th.com> References: <48459A62.1090703@4th.com> Message-ID: <34B41CAFEE004FB0BF5C2F354B7568C4@Squirt> I have a CCK content type and it has a bunch of entries in it. When I show it in a view two of the entries are duplicated multiple times. I suspect something is screwed up in the data structure. Experiment number one. There were three copies of one entry so I decide to clone that entry so as to not lose the data and then delete the original. Doing so created three copies called Clone of ... and deleting the original got rid of all three. Next step is create a new entry and copy the fields from the clone into it. When that is submitted, I now have two copies (one less than before). What is going on? Pathauto is turned on in case that has something to do with the problem. There is only one entry in the alias table. From merlin at logrus.com Tue Jun 3 20:35:55 2008 From: merlin at logrus.com (Earl Miles) Date: Tue, 03 Jun 2008 13:35:55 -0700 Subject: [development] CCK and Views data structures screwed up In-Reply-To: <34B41CAFEE004FB0BF5C2F354B7568C4@Squirt> References: <48459A62.1090703@4th.com> <34B41CAFEE004FB0BF5C2F354B7568C4@Squirt> Message-ID: <4845AB2B.6060306@logrus.com> Walt Daniels wrote: > I have a CCK content type and it has a bunch of entries in it. When I show > it in a view two of the entries are duplicated multiple times. I suspect > something is screwed up in the data structure. > > Experiment number one. There were three copies of one entry so I decide to > clone that entry so as to not lose the data and then delete the original. > Doing so created three copies called Clone of ... and deleting the original > got rid of all three. Next step is create a new entry and copy the fields > from the clone into it. When that is submitted, I now have two copies (one > less than before). What is going on? > > Pathauto is turned on in case that has something to do with the problem. > There is only one entry in the alias table. There's no way to answer this question without knowing every field, filter, sort criteria and argument in your query. It's really really easy to produce 'dups' in SQL and thus in Views; many things could be doing it. Often it's taxonomy related, but any field that can have multiple values can easily do it if not configured appropriately. From merlin at logrus.com Tue Jun 3 20:37:54 2008 From: merlin at logrus.com (Earl Miles) Date: Tue, 03 Jun 2008 13:37:54 -0700 Subject: [development] CCK and Views data structures screwed up In-Reply-To: <4845AB2B.6060306@logrus.com> References: <48459A62.1090703@4th.com> <34B41CAFEE004FB0BF5C2F354B7568C4@Squirt> <4845AB2B.6060306@logrus.com> Message-ID: <4845ABA2.7000502@logrus.com> Earl Miles wrote: > Walt Daniels wrote: >> I have a CCK content type and it has a bunch of entries in it. When I >> show >> it in a view two of the entries are duplicated multiple times. I suspect >> something is screwed up in the data structure. >> Experiment number one. There were three copies of one entry so I >> decide to >> clone that entry so as to not lose the data and then delete the original. >> Doing so created three copies called Clone of ... and deleting the >> original >> got rid of all three. Next step is create a new entry and copy the fields >> from the clone into it. When that is submitted, I now have two copies >> (one >> less than before). What is going on? >> >> Pathauto is turned on in case that has something to do with the problem. >> There is only one entry in the alias table. > > There's no way to answer this question without knowing every field, > filter, sort criteria and argument in your query. > > It's really really easy to produce 'dups' in SQL and thus in Views; many > things could be doing it. Often it's taxonomy related, but any field > that can have multiple values can easily do it if not configured > appropriately. I should amend: It's highly unlikely that the data structures are messed up. From news at unleashedmind.com Tue Jun 3 20:43:13 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Tue, 3 Jun 2008 22:43:13 +0200 Subject: [development] CCK and Views data structures screwed up In-Reply-To: <34B41CAFEE004FB0BF5C2F354B7568C4@Squirt> Message-ID: <028101c8c5ba$71cb58c0$0200a8c0@structworks.com> Your support request successfully reached thousands of developers now. 99.9% of all recipients need to hit delete once again. And the one or more developers that are actually able to answer this question prefer to reply on drupal.org issues. Did you already search the issue queue or similar reports? http://drupal.org/project/issues/search/views Did you create an issue? http://drupal.org/project/issues/views Thanks, Daniel > -----Original Message----- > From: development-bounces at drupal.org > [mailto:development-bounces at drupal.org] On Behalf Of Walt Daniels > Sent: Tuesday, June 03, 2008 10:34 PM > To: development at drupal.org > Subject: [development] CCK and Views data structures screwed up > > I have a CCK content type and it has a bunch of entries in > it. When I show it in a view two of the entries are > duplicated multiple times. I suspect something is screwed up > in the data structure. > > Experiment number one. There were three copies of one entry > so I decide to clone that entry so as to not lose the data > and then delete the original. > Doing so created three copies called Clone of ... and > deleting the original got rid of all three. Next step is > create a new entry and copy the fields from the clone into > it. When that is submitted, I now have two copies (one less > than before). What is going on? > > Pathauto is turned on in case that has something to do with > the problem. > There is only one entry in the alias table. > From victorkane at gmail.com Tue Jun 3 20:45:32 2008 From: victorkane at gmail.com (Victor Kane) Date: Tue, 3 Jun 2008 17:45:32 -0300 Subject: [development] CCK and Views data structures screwed up In-Reply-To: <4845ABA2.7000502@logrus.com> References: <48459A62.1090703@4th.com> <34B41CAFEE004FB0BF5C2F354B7568C4@Squirt> <4845AB2B.6060306@logrus.com> <4845ABA2.7000502@logrus.com> Message-ID: If it says "Clone of", Walt, you must be using the Node clone module (which I happen to use frequently, and as I recall, it simply makes another node). So I would say that views is answering logically, it is finding three nodes and saying it found three nodes. Of course, if this is not the case, disregard. Victor On Tue, Jun 3, 2008 at 5:37 PM, Earl Miles wrote: > Earl Miles wrote: > >> Walt Daniels wrote: >> >>> I have a CCK content type and it has a bunch of entries in it. When I >>> show >>> it in a view two of the entries are duplicated multiple times. I suspect >>> something is screwed up in the data structure. >>> Experiment number one. There were three copies of one entry so I decide >>> to >>> clone that entry so as to not lose the data and then delete the original. >>> Doing so created three copies called Clone of ... and deleting the >>> original >>> got rid of all three. Next step is create a new entry and copy the fields >>> from the clone into it. When that is submitted, I now have two copies >>> (one >>> less than before). What is going on? >>> >>> Pathauto is turned on in case that has something to do with the problem. >>> There is only one entry in the alias table. >>> >> >> There's no way to answer this question without knowing every field, >> filter, sort criteria and argument in your query. >> >> It's really really easy to produce 'dups' in SQL and thus in Views; many >> things could be doing it. Often it's taxonomy related, but any field that >> can have multiple values can easily do it if not configured appropriately. >> > > I should amend: It's highly unlikely that the data structures are messed > up. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080603/6912a75b/attachment-0001.htm From karen at elderweb.com Wed Jun 4 01:25:08 2008 From: karen at elderweb.com (Karen Stevenson) Date: Tue, 3 Jun 2008 18:25:08 -0700 (PDT) Subject: [development] lightbox module comparison Message-ID: <127343.21565.qm@web65614.mail.ac4.yahoo.com> I think a 'module comparisons' section is important enough to deserve a top-level place in the handbook, with a link from the downloads page to make it easy for someone looking for modules to find. I actually think writeups like this are far more useful that the contrib module rating system that is often discussed. What does a 5 star rating tell you? It tells you the module solved a specific problem for the person who rated it, it doesn't tell you if it will solve *your* problem or be useful in *your* situation. But this kind of writeup makes it easy to see which module is the best fit for your particular situation, which is really really useful. This should not be buried down in the module documentation -- someone looking at one of the other modules would never see it. It should be very prominent (and that hopefully would also encourage other people to add more of these kinds of comparisons). For instance a good comparison of the different wysiwyg editors would be pretty useful :) Karen ----- Original Message ---- From: FGM To: development at drupal.org Sent: Tuesday, June 3, 2008 10:27:32 AM Subject: Re: [development] lightbox module comparison I've done one on the two glossary modules I'm aware of (glossary.module and g2.module), it's on the g2 project page. Maybe there are more, though ? This being said, you might have something: module duplication and module voting being recurrent themes, it might make sense to formalize a rule like: "if you're doing a module that resembles other modules, create a comparison page, that will go in the section of the handbook", in the dev manual. What do you think of it ? FGM From mistknight at gmail.com Wed Jun 4 03:32:06 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Wed, 4 Jun 2008 06:32:06 +0300 Subject: [development] Trust (was: Hit and run contrib) In-Reply-To: <4842429D.1010009@logrus.com> References: <200805311038.42473.jpetso@gmx.at> <48417755.6010003@logrus.com> <200806010224.39167.jpetso@gmx.at> <200806010238.19787.jpetso@gmx.at> <4842429D.1010009@logrus.com> Message-ID: Angela seems to have hit the jackpot though, if the maintainer is allowed to set a flag per module which shows somewhere on his module's page. On Sun, Jun 1, 2008 at 9:33 AM, Earl Miles wrote: > Jakob Petsovits wrote: > >> On Sunday, 1. June 2008, Jakob Petsovits wrote: >> >>> On Saturday, 31. May 2008, Earl Miles wrote: >>> >>>> I just grepped and looked at 43 instances of switch() in Views 1. >>>> >>>> I find one case that might look like a missing break in the theme >>>> wizard; and it's kind of odd. Otherwise, nada. Waste of my time. >>>> >>> Views 2. Ok, let me see if I can dig this up again... don't know anymore >>> where I found it, but perhaps it's still in there somewhere. >>> >> >> Ok, found it, and it seems that it's indeed intended >> (for reference, 'style_options' vs. 'row_options'). >> >> So shame on me and further reinforcing the notion that I should not >> be granted commit access to Views. >> >> Putting a >> // fall through >> comment instead of the >> break; >> might help avoiding stupid monkeys like me, though. >> >> Sorry for wasting your time; friends?, >> > > Hehe. No prob. =) > -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/9a632eae/attachment.htm From rich at freestylesystems.co.uk Wed Jun 4 09:05:32 2008 From: rich at freestylesystems.co.uk (Richard Burford) Date: Wed, 4 Jun 2008 10:05:32 +0100 Subject: [development] lightbox module comparison In-Reply-To: <127343.21565.qm@web65614.mail.ac4.yahoo.com> References: <127343.21565.qm@web65614.mail.ac4.yahoo.com> Message-ID: Agreed. A link from each module page to the comparison would be good a good addition. I'll add one for Shadowbox now. psynaptic http://freestylesystems.co.uk http://api.freestylesystems.co.uk On 4 Jun 2008, at 02:25, Karen Stevenson wrote: > I think a 'module comparisons' section is important enough to > deserve a top-level place in the handbook, with a link from the > downloads page to make it easy for someone looking for modules to > find. I actually think writeups like this are far more useful that > the contrib module rating system that is often discussed. What does > a 5 star rating tell you? It tells you the module solved a specific > problem for the person who rated it, it doesn't tell you if it will > solve *your* problem or be useful in *your* situation. But this kind > of writeup makes it easy to see which module is the best fit for > your particular situation, which is really really useful. > > This should not be buried down in the module documentation -- > someone looking at one of the other modules would never see it. It > should be very prominent (and that hopefully would also encourage > other people to add more of these kinds of comparisons). > > For instance a good comparison of the different wysiwyg editors > would be pretty useful :) > > Karen > > ----- Original Message ---- > From: FGM > To: development at drupal.org > Sent: Tuesday, June 3, 2008 10:27:32 AM > Subject: Re: [development] lightbox module comparison > > I've done one on the two glossary modules I'm aware of > (glossary.module and > g2.module), it's on the g2 project page. Maybe there are more, > though ? > > This being said, you might have something: module duplication and > module > voting being recurrent themes, it might make sense to formalize a > rule like: > "if you're doing a module that resembles other modules, create a > comparison > page, that will go in the section of the > handbook", in > the dev manual. > > What do you think of it ? > > FGM -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2437 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080604/24c561a7/attachment.bin From catch56 at googlemail.com Wed Jun 4 09:06:07 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 4 Jun 2008 10:06:07 +0100 Subject: [development] lightbox module comparison In-Reply-To: <127343.21565.qm@web65614.mail.ac4.yahoo.com> References: <127343.21565.qm@web65614.mail.ac4.yahoo.com> Message-ID: I've moved this up to the top level of "beyond the basics" (alongside snippets, modules, themes, howtos etc.). And it's even got a WYSIWYG comparison in it (although a few months old now). I'd quite like to see a comparison of the various 'related/similar content' modules - there must be at least 10-15 by now. Image modules would be a massive help for newbies. Must be lots of others. Nat On 6/4/08, Karen Stevenson wrote: > > I think a 'module comparisons' section is important enough to deserve a > top-level place in the handbook, with a link from the downloads page to make > it easy for someone looking for modules to find. I actually think writeups > like this are far more useful that the contrib module rating system that is > often discussed. What does a 5 star rating tell you? It tells you the module > solved a specific problem for the person who rated it, it doesn't tell you > if it will solve *your* problem or be useful in *your* situation. But this > kind of writeup makes it easy to see which module is the best fit for your > particular situation, which is really really useful. > > This should not be buried down in the module documentation -- someone > looking at one of the other modules would never see it. It should be very > prominent (and that hopefully would also encourage other people to add more > of these kinds of comparisons). > > For instance a good comparison of the different wysiwyg editors would be > pretty useful :) > > Karen > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/6046c63e/attachment.htm From Alcindo.DaCosta at edipresse.ch Wed Jun 4 09:41:20 2008 From: Alcindo.DaCosta at edipresse.ch (Da Costa Alcindo) Date: Wed, 4 Jun 2008 11:41:20 +0200 Subject: [development] With the Tid get last node Message-ID: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net> Hi, I am currently developing a module that displays a block with the last article in each category. Is what someone has already sought to retrieve the last article from a tid? With a function like taxonomy_get_last_node($tid) ?? Cheers, Da Costa Alcindo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/c9a994b0/attachment.htm From douggreen at douggreenconsulting.com Wed Jun 4 11:10:55 2008 From: douggreen at douggreenconsulting.com (Doug Green) Date: Wed, 04 Jun 2008 07:10:55 -0400 Subject: [development] With the Tid get last node In-Reply-To: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net> References: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net> Message-ID: <4846783F.1050600@douggreenconsulting.com> use views for this select block, return 1 node filter by taxonomy sort by created date DESC Da Costa Alcindo wrote: > Hi, > > > > I am currently developing a module that displays a block with the last > article in each category. > Is what someone has already sought to retrieve the last article from a > tid? > > > > With a function like taxonomy_get_last_node($tid) ?? > > > > Cheers, > > Da Costa Alcindo > > > -- Doug Green douggreen at douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention... From Alcindo.DaCosta at edipresse.ch Wed Jun 4 12:17:48 2008 From: Alcindo.DaCosta at edipresse.ch (Da Costa Alcindo) Date: Wed, 4 Jun 2008 14:17:48 +0200 Subject: [development] With the Tid get last node References: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net> <4846783F.1050600@douggreenconsulting.com> Message-ID: <70D65090AAD69746ABB882EE6F85C4FD0913D583@LSMAIL01.edipresse.net> I already use a view to retrieve all term id, and now I would like to just doing research to find the first Nest good category. -----Message d'origine----- De?: development-bounces at drupal.org [mailto:development-bounces at drupal.org] De la part de Doug Green Envoy??: mercredi, 4. juin 2008 13:11 ??: development at drupal.org Objet?: Re: [development] With the Tid get last node use views for this select block, return 1 node filter by taxonomy sort by created date DESC Da Costa Alcindo wrote: > Hi, > > > > I am currently developing a module that displays a block with the last > article in each category. > Is what someone has already sought to retrieve the last article from a > tid? > > > > With a function like taxonomy_get_last_node($tid) ?? > > > > Cheers, > > Da Costa Alcindo > > > -- Doug Green douggreen at douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention... From Alcindo.DaCosta at edipresse.ch Wed Jun 4 12:44:53 2008 From: Alcindo.DaCosta at edipresse.ch (Da Costa Alcindo) Date: Wed, 4 Jun 2008 14:44:53 +0200 Subject: [development] With the Tid get last node References: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net><4846783F.1050600@douggreenconsulting.com> <70D65090AAD69746ABB882EE6F85C4FD0913D583@LSMAIL01.edipresse.net> Message-ID: <70D65090AAD69746ABB882EE6F85C4FD0913D586@LSMAIL01.edipresse.net> Hi, I found a solution, I make a complaint directly into the database, if it can help someone;) $query = "SELECT vqh_node.nid, vqh_node.title, vqh_node.created AS vqh_node_created_created FROM vqh_node vqh_node LEFT JOIN vqh_term_node vqh_term_node ON vqh_node.nid = vqh_term_node.nid LEFT JOIN vqh_term_data vqh_term_data ON vqh_term_node.tid = vqh_term_data.tid WHERE (vqh_term_node.tid = '$term->tid') ORDER BY vqh_node_created_created DESC LIMIT 0,1"; Da Costa Alcindo -----Message d'origine----- De?: development-bounces at drupal.org [mailto:development-bounces at drupal.org] De la part de Da Costa Alcindo Envoy??: mercredi, 4. juin 2008 14:18 ??: development at drupal.org Objet?: Re: [development] With the Tid get last node I already use a view to retrieve all term id, and now I would like to just doing research to find the first Nest good category. -----Message d'origine----- De?: development-bounces at drupal.org [mailto:development-bounces at drupal.org] De la part de Doug Green Envoy??: mercredi, 4. juin 2008 13:11 ??: development at drupal.org Objet?: Re: [development] With the Tid get last node use views for this select block, return 1 node filter by taxonomy sort by created date DESC Da Costa Alcindo wrote: > Hi, > > > > I am currently developing a module that displays a block with the last > article in each category. > Is what someone has already sought to retrieve the last article from a > tid? > > > > With a function like taxonomy_get_last_node($tid) ?? > > > > Cheers, > > Da Costa Alcindo > > > -- Doug Green douggreen at douggreenconsulting.com 904-583-3342 Bringing Ideas to Life with Software Artistry and Invention... From aenovo at estudiantes.uci.cu Wed Jun 4 13:23:16 2008 From: aenovo at estudiantes.uci.cu (Ariel Enrique Novo Rijo) Date: Wed, 4 Jun 2008 09:23:16 -0400 Subject: [development] Drupal architecture References: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net><4846783F.1050600@douggreenconsulting.com><70D65090AAD69746ABB882EE6F85C4FD0913D583@LSMAIL01.edipresse.net> <70D65090AAD69746ABB882EE6F85C4FD0913D586@LSMAIL01.edipresse.net> Message-ID: Hello. I was having a discussion with some Drupal-adicts friends about the arquitectural structure of it. The point is somebody said the architectural pattern that describe the behavior of Drupal is the refelction pattern. Since you met Drupal, the first you hear is the architecture of Drupal is a modular architecture, but, if you are going to point this definition into the principal architectural styles or patterns, like: layered organized systems, MVC, .... etc, it doesn't match exactly with the definitions and characteristics of any of those. >From my view, i think Drupal is an Independient Components System, in this group you can find Client/server Systems and Events Systems, Drupal Characteristics match whith both of them so or. I would like to know your opinion about. PD: sorry if the objetives of this group are not related whith this topic, i'm new over here. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 3932 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080604/10c92123/attachment.bin From fgm at osinet.fr Wed Jun 4 13:25:18 2008 From: fgm at osinet.fr (FGM) Date: Wed, 4 Jun 2008 15:25:18 +0200 Subject: [development] Drupal architecture References: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net><4846783F.1050600@douggreenconsulting.com><70D65090AAD69746ABB882EE6F85C4FD0913D583@LSMAIL01.edipresse.net><70D65090AAD69746ABB882EE6F85C4FD0913D586@LSMAIL01.edipresse.net> Message-ID: <008c01c8c646$74f36e20$2401a8c0@pcosi> The traditional answer is that Drupal follows the PAC model. http://www.garfieldtech.com/blog/mvc-vs-pac ----- Original Message ----- From: "Ariel Enrique Novo Rijo" To: Sent: Wednesday, June 04, 2008 3:23 PM Subject: [development] Drupal architecture Hello. I was having a discussion with some Drupal-adicts friends about the arquitectural structure of it. The point is somebody said the architectural pattern that describe the behavior of Drupal is the refelction pattern. Since you met Drupal, the first you hear is the architecture of Drupal is a modular architecture, but, if you are going to point this definition into the principal architectural styles or patterns, like: layered organized systems, MVC, .... etc, it doesn't match exactly with the definitions and characteristics of any of those. >From my view, i think Drupal is an Independient Components System, in this group you can find Client/server Systems and Events Systems, Drupal Characteristics match whith both of them so or. I would like to know your opinion about. PD: sorry if the objetives of this group are not related whith this topic, i'm new over here. Thanks. From cxjohnson at gmail.com Wed Jun 4 13:42:32 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 4 Jun 2008 15:42:32 +0200 Subject: [development] Plone versus Drupal Message-ID: <9ea8d6030806040642o23cc14afy8cae4ad54050494@mail.gmail.com> In looking for some use cases information for Drupal, I came across the following blog post about Plone versus Drupal: http://m.odul.us/2007/09/02/plone-vs-drupal-take-one It's worth reading not just to see how one person compares Drupal to Plone, but to see where Drupal is lacking some interesting capabilities (e.g. being able to generate Plone modules using UML). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/26c30a76/attachment.htm From aenovo at estudiantes.uci.cu Wed Jun 4 14:03:40 2008 From: aenovo at estudiantes.uci.cu (Ariel Enrique Novo Rijo) Date: Wed, 4 Jun 2008 10:03:40 -0400 Subject: [development] Drupal architecture References: <70D65090AAD69746ABB882EE6F85C4FD0913D579@LSMAIL01.edipresse.net><4846783F.1050600@douggreenconsulting.com><70D65090AAD69746ABB882EE6F85C4FD0913D583@LSMAIL01.edipresse.net><70D65090AAD69746ABB882EE6F85C4FD0913D586@LSMAIL01.edipresse.net> <008c01c8c646$74f36e20$2401a8c0@pcosi> Message-ID: Thanks, very good article. ________________________________ De: development-bounces at drupal.org en nombre de FGM Enviado el: mi? 4/6/08 9:25 Para: development at drupal.org Asunto: Re: [development] Drupal architecture The traditional answer is that Drupal follows the PAC model. http://www.garfieldtech.com/blog/mvc-vs-pac ----- Original Message ----- From: "Ariel Enrique Novo Rijo" To: Sent: Wednesday, June 04, 2008 3:23 PM Subject: [development] Drupal architecture Hello. I was having a discussion with some Drupal-adicts friends about the arquitectural structure of it. The point is somebody said the architectural pattern that describe the behavior of Drupal is the refelction pattern. Since you met Drupal, the first you hear is the architecture of Drupal is a modular architecture, but, if you are going to point this definition into the principal architectural styles or patterns, like: layered organized systems, MVC, .... etc, it doesn't match exactly with the definitions and characteristics of any of those. >From my view, i think Drupal is an Independient Components System, in this group you can find Client/server Systems and Events Systems, Drupal Characteristics match whith both of them so or. I would like to know your opinion about. PD: sorry if the objetives of this group are not related whith this topic, i'm new over here. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 4498 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080604/21e3edfa/attachment-0001.bin From stella at stellapower.net Wed Jun 4 19:21:54 2008 From: stella at stellapower.net (Stella Power) Date: Wed, 4 Jun 2008 20:21:54 +0100 Subject: [development] lightbox module comparison In-Reply-To: References: <127343.21565.qm@web65614.mail.ac4.yahoo.com> Message-ID: I added one to the lightbox2 module page too. On Wed, Jun 4, 2008 at 10:05 AM, Richard Burford < rich at freestylesystems.co.uk> wrote: > Agreed. A link from each module page to the comparison would be good a good > addition. I'll add one for Shadowbox now. > > psynaptic > http://freestylesystems.co.uk > http://api.freestylesystems.co.uk > > > On 4 Jun 2008, at 02:25, Karen Stevenson wrote: > > I think a 'module comparisons' section is important enough to deserve a >> top-level place in the handbook, with a link from the downloads page to make >> it easy for someone looking for modules to find. I actually think writeups >> like this are far more useful that the contrib module rating system that is >> often discussed. What does a 5 star rating tell you? It tells you the module >> solved a specific problem for the person who rated it, it doesn't tell you >> if it will solve *your* problem or be useful in *your* situation. But this >> kind of writeup makes it easy to see which module is the best fit for your >> particular situation, which is really really useful. >> >> This should not be buried down in the module documentation -- someone >> looking at one of the other modules would never see it. It should be very >> prominent (and that hopefully would also encourage other people to add more >> of these kinds of comparisons). >> >> For instance a good comparison of the different wysiwyg editors would be >> pretty useful :) >> >> Karen >> >> ----- Original Message ---- >> From: FGM >> To: development at drupal.org >> Sent: Tuesday, June 3, 2008 10:27:32 AM >> Subject: Re: [development] lightbox module comparison >> >> I've done one on the two glossary modules I'm aware of (glossary.module >> and >> g2.module), it's on the g2 project page. Maybe there are more, though ? >> >> This being said, you might have something: module duplication and module >> voting being recurrent themes, it might make sense to formalize a rule >> like: >> "if you're doing a module that resembles other modules, create a >> comparison >> page, that will go in the section of the handbook", in >> the dev manual. >> >> What do you think of it ? >> >> FGM >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/f1f0394c/attachment.htm From stella at stellapower.net Wed Jun 4 19:20:26 2008 From: stella at stellapower.net (Stella Power) Date: Wed, 4 Jun 2008 20:20:26 +0100 Subject: [development] lightbox module comparison In-Reply-To: <127343.21565.qm@web65614.mail.ac4.yahoo.com> References: <127343.21565.qm@web65614.mail.ac4.yahoo.com> Message-ID: I think we may also need a comparison on the different "access" modules available. For example, there's "node access", "taxonomy access control", "taxonomy access control lite", "simple access", "path access", "url access", ... While I'm sure they all do different things, it would be useful to an overview page of the features provided by each. I also wouldn't mind a comparison on the ecommerce modules available in Drupal, though perhaps that would be too big a task for one person! I'm sure I saw a comparison of e-commerce and ubercart somewhere on the web, can't find it right now, but it might be another useful link to add to this section of the handbook. It might be useful to see comparisons that other users want too. Should users create documentation tasks? Or should they just scratch their own itch? I'm already a member of the docs team and certainly wouldn't mind helping with this. Cheers, Stella On Wed, Jun 4, 2008 at 2:25 AM, Karen Stevenson wrote: > I think a 'module comparisons' section is important enough to deserve a > top-level place in the handbook, with a link from the downloads page to make > it easy for someone looking for modules to find. I actually think writeups > like this are far more useful that the contrib module rating system that is > often discussed. What does a 5 star rating tell you? It tells you the module > solved a specific problem for the person who rated it, it doesn't tell you > if it will solve *your* problem or be useful in *your* situation. But this > kind of writeup makes it easy to see which module is the best fit for your > particular situation, which is really really useful. > > This should not be buried down in the module documentation -- someone > looking at one of the other modules would never see it. It should be very > prominent (and that hopefully would also encourage other people to add more > of these kinds of comparisons). > > For instance a good comparison of the different wysiwyg editors would be > pretty useful :) > > Karen > > ----- Original Message ---- > From: FGM > To: development at drupal.org > Sent: Tuesday, June 3, 2008 10:27:32 AM > Subject: Re: [development] lightbox module comparison > > I've done one on the two glossary modules I'm aware of (glossary.module and > g2.module), it's on the g2 project page. Maybe there are more, though ? > > This being said, you might have something: module duplication and module > voting being recurrent themes, it might make sense to formalize a rule > like: > "if you're doing a module that resembles other modules, create a comparison > page, that will go in the section of the handbook", in > the dev manual. > > What do you think of it ? > > FGM > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/8f77dc65/attachment.htm From larry at garfieldtech.com Wed Jun 4 22:42:47 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Wed, 4 Jun 2008 17:42:47 -0500 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: I agree that these comparison pages are very valuable; no question. However, one problem with them is that they are also time-sensitive. I don't expect any of the modules mentioned to stand still. That means much of the data is going to become outdated; some in a month, some in 6 months. Are we also committing to keeping these pages up to date? Out of date/wrong documentation can be just as bad if not worse than no documentation at all. --Larry Garfield the killjoy On Wed, 4 Jun 2008 20:21:54 +0100, "Stella Power" wrote: > I added one to the lightbox2 module page too. > > > On Wed, Jun 4, 2008 at 10:05 AM, Richard Burford < > rich at freestylesystems.co.uk> wrote: > >> Agreed. A link from each module page to the comparison would be good a > good >> addition. I'll add one for Shadowbox now. >> >> psynaptic >> http://freestylesystems.co.uk >> http://api.freestylesystems.co.uk >> >> >> On 4 Jun 2008, at 02:25, Karen Stevenson wrote: >> >> I think a 'module comparisons' section is important enough to deserve a >>> top-level place in the handbook, with a link from the downloads page to > make >>> it easy for someone looking for modules to find. I actually think > writeups >>> like this are far more useful that the contrib module rating system > that is >>> often discussed. What does a 5 star rating tell you? It tells you the > module >>> solved a specific problem for the person who rated it, it doesn't tell > you >>> if it will solve *your* problem or be useful in *your* situation. But > this >>> kind of writeup makes it easy to see which module is the best fit for > your >>> particular situation, which is really really useful. >>> >>> This should not be buried down in the module documentation -- someone >>> looking at one of the other modules would never see it. It should be > very >>> prominent (and that hopefully would also encourage other people to add > more >>> of these kinds of comparisons). >>> >>> For instance a good comparison of the different wysiwyg editors would > be >>> pretty useful :) >>> >>> Karen >>> >>> ----- Original Message ---- >>> From: FGM >>> To: development at drupal.org >>> Sent: Tuesday, June 3, 2008 10:27:32 AM >>> Subject: Re: [development] lightbox module comparison >>> >>> I've done one on the two glossary modules I'm aware of (glossary.module >>> and >>> g2.module), it's on the g2 project page. Maybe there are more, though ? >>> >>> This being said, you might have something: module duplication and > module >>> voting being recurrent themes, it might make sense to formalize a rule >>> like: >>> "if you're doing a module that resembles other modules, create a >>> comparison >>> page, that will go in the section of the handbook", > in >>> the dev manual. >>> >>> What do you think of it ? >>> >>> FGM >>> >> >> > > From news at unleashedmind.com Wed Jun 4 22:55:45 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Thu, 5 Jun 2008 00:55:45 +0200 Subject: [development] lightbox module comparison In-Reply-To: Message-ID: <041401c8c696$1fc3f870$0200a8c0@structworks.com> > Are we also committing to keeping these pages up to date? > Out of date/wrong documentation can be just as bad if not > worse than no documentation at all. As a maintainer of a module that is included in one of these comparisons, it's in my interest to update that page to reflect recent changes. If it's rated poor, and I'll never update the page, it will stay poor (and probably is). sun From catch56 at googlemail.com Wed Jun 4 23:10:54 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 5 Jun 2008 00:10:54 +0100 Subject: [development] lightbox module comparison In-Reply-To: <041401c8c696$1fc3f870$0200a8c0@structworks.com> References: <041401c8c696$1fc3f870$0200a8c0@structworks.com> Message-ID: I agree with Daniel on this. It's also an issue for /any/ documentation in the handbook - I found a drupal 4.3 site listed in the top level site showcases handbook page the other week. We might want a note somewhere on the parent page making this point very clearly, and the 'last updated' in big letters on the thickbox article might be worth replicating. On Wed, Jun 4, 2008 at 11:55 PM, Daniel F. Kudwien wrote: > > Are we also committing to keeping these pages up to date? > > Out of date/wrong documentation can be just as bad if not > > worse than no documentation at all. > > As a maintainer of a module that is included in one of these comparisons, > it's in my interest to update that page to reflect recent changes. If it's > rated poor, and I'll never update the page, it will stay poor (and probably > is). > > sun > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080605/4e6d3f23/attachment.htm From stella at stellapower.net Wed Jun 4 22:48:25 2008 From: stella at stellapower.net (Stella Power) Date: Wed, 4 Jun 2008 23:48:25 +0100 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: Well I plan on keeping the lightbox comparison page up to date, hopefully with some updates from the individual module maintainers. It's also why I have a "Last Updated" bit at the top of the comparison, so people reading it can see exactly how recent it is. I also have a date beside each module in the first overview table to show when the info on that particular module was last updated. Cheers, Stella On Wed, Jun 4, 2008 at 11:42 PM, Larry Garfield wrote: > > I agree that these comparison pages are very valuable; no question. > However, one problem with them is that they are also time-sensitive. I > don't expect any of the modules mentioned to stand still. That means much > of the data is going to become outdated; some in a month, some in 6 months. > Are we also committing to keeping these pages up to date? Out of > date/wrong documentation can be just as bad if not worse than no > documentation at all. > > --Larry Garfield the killjoy > > On Wed, 4 Jun 2008 20:21:54 +0100, "Stella Power" > wrote: > > I added one to the lightbox2 module page too. > > > > > > On Wed, Jun 4, 2008 at 10:05 AM, Richard Burford < > > rich at freestylesystems.co.uk> wrote: > > > >> Agreed. A link from each module page to the comparison would be good a > > good > >> addition. I'll add one for Shadowbox now. > >> > >> psynaptic > >> http://freestylesystems.co.uk > >> http://api.freestylesystems.co.uk > >> > >> > >> On 4 Jun 2008, at 02:25, Karen Stevenson wrote: > >> > >> I think a 'module comparisons' section is important enough to deserve a > >>> top-level place in the handbook, with a link from the downloads page to > > make > >>> it easy for someone looking for modules to find. I actually think > > writeups > >>> like this are far more useful that the contrib module rating system > > that is > >>> often discussed. What does a 5 star rating tell you? It tells you the > > module > >>> solved a specific problem for the person who rated it, it doesn't tell > > you > >>> if it will solve *your* problem or be useful in *your* situation. But > > this > >>> kind of writeup makes it easy to see which module is the best fit for > > your > >>> particular situation, which is really really useful. > >>> > >>> This should not be buried down in the module documentation -- someone > >>> looking at one of the other modules would never see it. It should be > > very > >>> prominent (and that hopefully would also encourage other people to add > > more > >>> of these kinds of comparisons). > >>> > >>> For instance a good comparison of the different wysiwyg editors would > > be > >>> pretty useful :) > >>> > >>> Karen > >>> > >>> ----- Original Message ---- > >>> From: FGM > >>> To: development at drupal.org > >>> Sent: Tuesday, June 3, 2008 10:27:32 AM > >>> Subject: Re: [development] lightbox module comparison > >>> > >>> I've done one on the two glossary modules I'm aware of (glossary.module > >>> and > >>> g2.module), it's on the g2 project page. Maybe there are more, though ? > >>> > >>> This being said, you might have something: module duplication and > > module > >>> voting being recurrent themes, it might make sense to formalize a rule > >>> like: > >>> "if you're doing a module that resembles other modules, create a > >>> comparison > >>> page, that will go in the section of the handbook", > > in > >>> the dev manual. > >>> > >>> What do you think of it ? > >>> > >>> FGM > >>> > >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080604/13bd7a9f/attachment-0001.htm From news at unleashedmind.com Wed Jun 4 23:26:36 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Thu, 5 Jun 2008 01:26:36 +0200 Subject: [development] lightbox module comparison In-Reply-To: Message-ID: <042e01c8c69a$6ed18ff0$0200a8c0@structworks.com> Q: Why don't we display 'Last Updated' on all handbook pages using Drupal's internal information? sun From rich at freestylesystems.co.uk Thu Jun 5 07:39:03 2008 From: rich at freestylesystems.co.uk (Richard Burford) Date: Thu, 5 Jun 2008 08:39:03 +0100 Subject: [development] lightbox module comparison In-Reply-To: <042e01c8c69a$6ed18ff0$0200a8c0@structworks.com> References: <042e01c8c69a$6ed18ff0$0200a8c0@structworks.com> Message-ID: I was just thinking this myself. It would certainly save a lot of work which could be better spent on other documentation tasks. psynaptic http://freestylesystems.co.uk http://api.freestylesystems.co.uk On 5 Jun 2008, at 00:26, Daniel F. Kudwien wrote: > Q: Why don't we display 'Last Updated' on all handbook pages using > Drupal's > internal information? > > sun -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2437 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080605/2a21d93c/attachment.bin From catch56 at googlemail.com Thu Jun 5 09:11:04 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 5 Jun 2008 10:11:04 +0100 Subject: [development] lightbox module comparison In-Reply-To: References: <042e01c8c69a$6ed18ff0$0200a8c0@structworks.com> Message-ID: On 6/5/08, Richard Burford wrote: > > I was just thinking this myself. It would certainly save a lot of work > which could be better spent on other documentation tasks. > > psynaptic > >> >> > I've started a discussion on the documentation list to discuss this: http://lists.drupal.org/pipermail/documentation/2008-June/006128.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080605/0486ac13/attachment.htm From enboig at gmail.com Thu Jun 5 12:27:26 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Thu, 5 Jun 2008 14:27:26 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types Message-ID: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> I want to make avaliable a local menu for just some node types, how can I achieve this? thanks. -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From earnie at users.sourceforge.net Thu Jun 5 12:55:57 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 05 Jun 2008 08:55:57 -0400 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> Message-ID: <20080605085557.abzqhd2hufc4484k@mail.progw.org> Quoting Llu?s : > I want to make avaliable a local menu for just some node types, how > can I achieve this? > I think this is the wrong list; see http://drupal.org/support for more appropriate help. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From michael at favias.org Thu Jun 5 14:03:26 2008 From: michael at favias.org (Michael Favia) Date: Thu, 05 Jun 2008 09:03:26 -0500 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> Message-ID: <4847F22E.4070105@favias.org> Llu?s wrote: > I want to make avaliable a local menu for just some node types, how > can I achieve this? I think this is development related enough so here goes: Create a conditional menu item inside of if(!$may_cache) that tests the node->type against you desired nodes. This will prevent the LMT from always showing up. If you want to get fancy let the user select the allowable node types via a settings page and pull the data via variable_get(). This information applies to Drupal-5 but may be modified to apply to drupal 6. good luck. -- Michael Favia michael at favias.org tel. 512.585.5650 http://www.favias.org From mistknight at gmail.com Thu Jun 5 14:11:02 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Thu, 5 Jun 2008 17:11:02 +0300 Subject: [development] schema api enum data type Message-ID: Hello all, I'm upgrading my module to drupal 6 and was using the enum data type, how can I handle this in the schema API? I searched the documentation but no enum and only a comment that wasn't answered. Any pointers appreciated. -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080605/ef956b8f/attachment.htm From david at fourkitchens.com Thu Jun 5 14:17:34 2008 From: david at fourkitchens.com (=?utf-8?B?RGF2aWQgU3RyYXVzcw==?=) Date: Thu, 5 Jun 2008 14:17:34 +0000 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <4847F22E.4070105@favias.org> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com><4847F22E.4070105@favias.org> Message-ID: <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> I believe you mean *outside* of $may_cache. -----Original Message----- From: Michael Favia Date: Thu, 05 Jun 2008 09:03:26 To:development at drupal.org Subject: Re: [development] MENU_LOCAL_TASK for just some node types Llu?s wrote: > I want to make avaliable a local menu for just some node types, how > can I achieve this? I think this is development related enough so here goes: Create a conditional menu item inside of if(!$may_cache) that tests the node->type against you desired nodes. This will prevent the LMT from always showing up. If you want to get fancy let the user select the allowable node types via a settings page and pull the data via variable_get(). This information applies to Drupal-5 but may be modified to apply to drupal 6. good luck. -- Michael Favia michael at favias.org tel. 512.585.5650 http://www.favias.org From mistknight at gmail.com Thu Jun 5 14:21:08 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Thu, 5 Jun 2008 17:21:08 +0300 Subject: [development] schema api enum data type In-Reply-To: References: Message-ID: Forgot that I got rid of these enums in later update hooks, so I no longer need that. Although if there's a standard way of handling them it would be nice to know :) On Thu, Jun 5, 2008 at 5:11 PM, Ashraf Amayreh wrote: > Hello all, > > I'm upgrading my module to drupal 6 and was using the enum data type, how > can I handle this in the schema API? > > I searched the documentation but no enum and only a comment that wasn't > answered. Any pointers appreciated. > > -- > Ashraf Amayreh > http://blogs.aamayreh.org > -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080605/dba43dc2/attachment-0001.htm From kkaefer at gmail.com Thu Jun 5 14:27:40 2008 From: kkaefer at gmail.com (=?ISO-8859-1?Q?Konstantin_K=E4fer?=) Date: Thu, 5 Jun 2008 16:27:40 +0200 Subject: [development] lightbox module comparison In-Reply-To: References: Message-ID: <6E56B05E-657F-45BC-9CAE-F2ED503947B9@gmail.com> I'd like to mention that Stella has (supposedly) mailed the maintainers of all mentioned modules to review the article and point out mistakes/explain allegedly missing features etc. I think it is very important to give module maintainers the chance to do also for future comparisons; so when you're planning to do your own module shootout, please consider this. Konstantin On 05.06.2008, at 00:48, Stella Power wrote: > Well I plan on keeping the lightbox comparison page up to date, > hopefully with some updates from the individual module maintainers. > It's also why I have a "Last Updated" bit at the top of the > comparison, so people reading it can see exactly how recent it is. > I also have a date beside each module in the first overview table to > show when the info on that particular module was last updated. > > Cheers, > Stella > > On Wed, Jun 4, 2008 at 11:42 PM, Larry Garfield > wrote: > > I agree that these comparison pages are very valuable; no question. > However, one problem with them is that they are also time- > sensitive. I don't expect any of the modules mentioned to stand > still. That means much of the data is going to become outdated; > some in a month, some in 6 months. Are we also committing to > keeping these pages up to date? Out of date/wrong documentation can > be just as bad if not worse than no documentation at all. > > --Larry Garfield the killjoy > > On Wed, 4 Jun 2008 20:21:54 +0100, "Stella Power" > wrote: > > I added one to the lightbox2 module page too. > > > > > > On Wed, Jun 4, 2008 at 10:05 AM, Richard Burford < > > rich at freestylesystems.co.uk> wrote: > > > >> Agreed. A link from each module page to the comparison would be > good a > > good > >> addition. I'll add one for Shadowbox now. > >> > >> psynaptic > >> http://freestylesystems.co.uk > >> http://api.freestylesystems.co.uk > >> > >> > >> On 4 Jun 2008, at 02:25, Karen Stevenson wrote: > >> > >> I think a 'module comparisons' section is important enough to > deserve a > >>> top-level place in the handbook, with a link from the downloads > page to > > make > >>> it easy for someone looking for modules to find. I actually think > > writeups > >>> like this are far more useful that the contrib module rating > system > > that is > >>> often discussed. What does a 5 star rating tell you? It tells > you the > > module > >>> solved a specific problem for the person who rated it, it > doesn't tell > > you > >>> if it will solve *your* problem or be useful in *your* > situation. But > > this > >>> kind of writeup makes it easy to see which module is the best > fit for > > your > >>> particular situation, which is really really useful. > >>> > >>> This should not be buried down in the module documentation -- > someone > >>> looking at one of the other modules would never see it. It > should be > > very > >>> prominent (and that hopefully would also encourage other people > to add > > more > >>> of these kinds of comparisons). > >>> > >>> For instance a good comparison of the different wysiwyg editors > would > > be > >>> pretty useful :) > >>> > >>> Karen > >>> > >>> ----- Original Message ---- > >>> From: FGM > >>> To: development at drupal.org > >>> Sent: Tuesday, June 3, 2008 10:27:32 AM > >>> Subject: Re: [development] lightbox module comparison > >>> > >>> I've done one on the two glossary modules I'm aware of > (glossary.module > >>> and > >>> g2.module), it's on the g2 project page. Maybe there are more, > though ? > >>> > >>> This being said, you might have something: module duplication and > > module > >>> voting being recurrent themes, it might make sense to formalize > a rule > >>> like: > >>> "if you're doing a module that resembles other modules, create a > >>> comparison > >>> page, that will go in the section of the > handbook", > > in > >>> the dev manual. > >>> > >>> What do you think of it ? > >>> > >>> FGM > >>> > >> > >> > > > > > > From enboig at gmail.com Thu Jun 5 14:32:54 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Thu, 5 Jun 2008 16:32:54 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> Message-ID: <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> My problem is there is no $node object to check $node->type. My menu definition is: function comptacau_project_menu() { $items=array(); $items[] = array('path' => 'node/'. arg(1) .'/pressupost_form', 'title' => t('Pressupost'), 'callback' => 'devel_load_object', 'callback arguments' => array('node', arg(1)), 'access' => user_access('access devel information'), 'type' => MENU_LOCAL_TASK, ); return $items; } When I get it all working; I will check if this goes inside cache or outside On Thu, Jun 5, 2008 at 4:17 PM, David Strauss wrote: > I believe you mean *outside* of $may_cache. > > -----Original Message----- > From: Michael Favia > > Date: Thu, 05 Jun 2008 09:03:26 > To:development at drupal.org > Subject: Re: [development] MENU_LOCAL_TASK for just some node types > > > Llu?s wrote: >> I want to make avaliable a local menu for just some node types, how >> can I achieve this? > > I think this is development related enough so here goes: > > Create a conditional menu item inside of if(!$may_cache) that tests the > node->type against you desired nodes. This will prevent the LMT from > always showing up. If you want to get fancy let the user select the > allowable node types via a settings page and pull the data via > variable_get(). This information applies to Drupal-5 but may be modified > to apply to drupal 6. good luck. > > -- > Michael Favia michael at favias.org > tel. 512.585.5650 http://www.favias.org > -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From tapocol at gmail.com Thu Jun 5 14:39:42 2008 From: tapocol at gmail.com (Craig Jackson) Date: Thu, 5 Jun 2008 08:39:42 -0600 Subject: [development] schema api enum data type In-Reply-To: References: Message-ID: <60cae1c50806050739i39ba1ed9i5cf0319447e19801@mail.gmail.com> Well, this is the map of database types. There is no reference to enum or set. http://api.drupal.org/api/function/db_type_map/6 I think you may be able to pass enum in as the type and/or pgsql_type, then you can put the options in the length (with each option separated by commas). But, I am unsure about possible problems. So, you (or someone else) would need to run through the code to see if it makes sense to do that. http://api.drupal.org/api/function/drupal_install_schema/6 Craig Jackson On Thu, Jun 5, 2008 at 8:21 AM, Ashraf Amayreh wrote: > Forgot that I got rid of these enums in later update hooks, so I no longer > need that. Although if there's a standard way of handling them it would be > nice to know :) > > On Thu, Jun 5, 2008 at 5:11 PM, Ashraf Amayreh wrote: >> >> Hello all, >> >> I'm upgrading my module to drupal 6 and was using the enum data type, how >> can I handle this in the schema API? >> >> I searched the documentation but no enum and only a comment that wasn't >> answered. Any pointers appreciated. >> >> -- >> Ashraf Amayreh >> http://blogs.aamayreh.org > > > > -- > Ashraf Amayreh > http://blogs.aamayreh.org From michael at favias.org Thu Jun 5 14:50:53 2008 From: michael at favias.org (Michael Favia) Date: Thu, 05 Jun 2008 09:50:53 -0500 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> Message-ID: <4847FD4D.2060107@favias.org> Llu?s wrote: > My problem is there is no $node object to check $node->type. My menu > definition is: My mistake. You are correct. To my knowledge you will either have to load the node or if you have pathauto working and uniquely prefix the node type you can test the path for the presence of the token for that type. (it is pretty hackish but ive used it before to avoid the excessive database hits). -- Michael Favia michael at favias.org tel. 512.585.5650 http://www.favias.org From michael at favias.org Thu Jun 5 14:53:04 2008 From: michael at favias.org (Michael Favia) Date: Thu, 05 Jun 2008 09:53:04 -0500 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com><4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> Message-ID: <4847FDD0.2060007@favias.org> David Strauss wrote: > I believe you mean *outside* of $may_cache. > -----Original Message----- > From: Michael Favia > Create a conditional menu item inside of if(!$may_cache) that tests the Either inside of if (!$may_cache) {as i wrote above} or outside of if ($may_cache) works perfectly fine of course. -- Michael Favia michael at favias.org tel. 512.585.5650 http://www.favias.org From david at fourkitchens.com Thu Jun 5 15:02:09 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Thu, 5 Jun 2008 10:02:09 -0500 (CDT) Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> Message-ID: <2139451743.691761212678129425.JavaMail.root@mail-2.01.com> Apologies. I somehow missed the "!" when reading this on my BlackBerry. That's what I get for emailing the developer list when I'm 10 minutes out of bed. ----- "David Strauss" wrote: > I believe you mean *outside* of $may_cache. > > -----Original Message----- > From: Michael Favia > > Date: Thu, 05 Jun 2008 09:03:26 > To:development at drupal.org > Subject: Re: [development] MENU_LOCAL_TASK for just some node types > > > Llu?s wrote: > > I want to make avaliable a local menu for just some node types, how > > can I achieve this? > > I think this is development related enough so here goes: > > Create a conditional menu item inside of if(!$may_cache) that tests > the > node->type against you desired nodes. This will prevent the LMT from > always showing up. If you want to get fancy let the user select the > allowable node types via a settings page and pull the data via > variable_get(). This information applies to Drupal-5 but may be > modified > to apply to drupal 6. good luck. > > -- > Michael Favia michael at favias.org > tel. 512.585.5650 http://www.favias.org From gwenael.saint-genest at makina-corpus.com Thu Jun 5 15:02:37 2008 From: gwenael.saint-genest at makina-corpus.com (Saint-Genest Gwenael) Date: Thu, 05 Jun 2008 17:02:37 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> Message-ID: <4848000D.6090702@makina-corpus.com> Hi, You can use node_load() to get node type attribute. function comptacau_project_menu($may_cache) { $items=array(); if (arg(0) == 'node' && is_numeric(arg(1))) { $node = node_load(arg(1)); // DEBUG: Example with 'page' but can be anything else ... if ($node->type == 'page') { $items[] = array( 'path' => 'node/'. arg(1) . '/pressupost_form', 'title' => t('Pressupost'), 'callback' => 'devel_load_object', 'callback arguments' => array($node), 'access' => user_access('access devel information'), 'type' => MENU_LOCAL_TASK ); } } return $items; } G. Saint-Genest -- Gwenael Saint-Genest MAKINA CORPUS - www.makina-corpus.com 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire Tel : +33 (0) 2 40 94 96 08 From enboig at gmail.com Thu Jun 5 15:30:55 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Thu, 5 Jun 2008 17:30:55 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <4848000D.6090702@makina-corpus.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> <4848000D.6090702@makina-corpus.com> Message-ID: <45a29f450806050830u6e5b066bxd117c2840914a8e8@mail.gmail.com> It works prefectly, thanks a lot. On Thu, Jun 5, 2008 at 5:02 PM, Saint-Genest Gwenael wrote: > Hi, > > You can use node_load() to get node type attribute. > > function comptacau_project_menu($may_cache) { > $items=array(); > if (arg(0) == 'node' && is_numeric(arg(1))) { > $node = node_load(arg(1)); > // DEBUG: Example with 'page' but can be anything else ... > if ($node->type == 'page') { > $items[] = array( > 'path' => 'node/'. arg(1) . '/pressupost_form', > 'title' => t('Pressupost'), > 'callback' => 'devel_load_object', > 'callback arguments' => array($node), > 'access' => user_access('access devel information'), > 'type' => MENU_LOCAL_TASK > ); > } > } > return $items; > } > > G. Saint-Genest > > -- > Gwenael Saint-Genest > MAKINA CORPUS - www.makina-corpus.com > 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire > Tel : +33 (0) 2 40 94 96 08 > -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From enboig at gmail.com Fri Jun 6 08:26:04 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Fri, 6 Jun 2008 10:26:04 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806050830u6e5b066bxd117c2840914a8e8@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> <4848000D.6090702@makina-corpus.com> <45a29f450806050830u6e5b066bxd117c2840914a8e8@mail.gmail.com> Message-ID: <45a29f450806060126o74ae7db5y2f6a1a4e28aa613e@mail.gmail.com> not prefectly; I have observed an odd behaviour with my function: it just works the first time I change the path ("pressupostos" by something else); as soon as I clear the cache (using devel module) the tab disappear. function comptacau_project_menu() { global $node; $items=array(); if ($may_cache) { $items[] = array('path' => 'comptacau/projects_autocomplete', 'title' => t('project_autocomplete'), 'callback' => 'projects_autocomplete', 'access' => comptacau_access('search_project'), 'type' => MENU_CALLBACK); } else { //no cache if (arg(1)>0) { //just load the node when there is a node $node = node_load(arg(1)); } $items[] = array('path' => 'node/'. arg(1) .'/pressupostos', //if I change this line, the tab appear 'title' => t('Pressupost'), 'callback' => 'drupal_get_form', 'callback arguments' => array('comtpacau_project_pressupost_form',arg(1)), 'access' => ($node->type=='comptacau_project'), 'type' => MENU_LOCAL_TASK); } return $items; } What am I missing? thanks a lot On Thu, Jun 5, 2008 at 5:30 PM, Llu?s wrote: > It works prefectly, thanks a lot. > > On Thu, Jun 5, 2008 at 5:02 PM, Saint-Genest Gwenael > wrote: >> Hi, >> >> You can use node_load() to get node type attribute. >> >> function comptacau_project_menu($may_cache) { >> $items=array(); >> if (arg(0) == 'node' && is_numeric(arg(1))) { >> $node = node_load(arg(1)); >> // DEBUG: Example with 'page' but can be anything else ... >> if ($node->type == 'page') { >> $items[] = array( >> 'path' => 'node/'. arg(1) . '/pressupost_form', >> 'title' => t('Pressupost'), >> 'callback' => 'devel_load_object', >> 'callback arguments' => array($node), >> 'access' => user_access('access devel information'), >> 'type' => MENU_LOCAL_TASK >> ); >> } >> } >> return $items; >> } >> >> G. Saint-Genest >> >> -- >> Gwenael Saint-Genest >> MAKINA CORPUS - www.makina-corpus.com >> 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire >> Tel : +33 (0) 2 40 94 96 08 >> > > > > -- > *La felicitat ha de ser compatible, compartible i cooperativa. > *Envellim quan els records superen les esperances. > *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. > *Abans d'imprimir aquest missatge, pensa en el medi ambient. > -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From enboig at gmail.com Fri Jun 6 08:52:55 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Fri, 6 Jun 2008 10:52:55 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806060126o74ae7db5y2f6a1a4e28aa613e@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> <4848000D.6090702@makina-corpus.com> <45a29f450806050830u6e5b066bxd117c2840914a8e8@mail.gmail.com> <45a29f450806060126o74ae7db5y2f6a1a4e28aa613e@mail.gmail.com> Message-ID: <45a29f450806060152w1c626215nab117c70d1e015e@mail.gmail.com> After some checking the problems just exists if I clean cache while looking a node of this type; if I clear cache from de front page everything works ok. It works so I don't need to change it, but I would like to understand why does it happen. On Fri, Jun 6, 2008 at 10:26 AM, Llu?s wrote: > not prefectly; I have observed an odd behaviour with my function: it > just works the first time I change the path ("pressupostos" by > something else); as soon as I clear the cache (using devel module) the > tab disappear. > > function comptacau_project_menu() { > global $node; > $items=array(); > > if ($may_cache) { > $items[] = array('path' => 'comptacau/projects_autocomplete', > 'title' => t('project_autocomplete'), > 'callback' => 'projects_autocomplete', > 'access' => comptacau_access('search_project'), > 'type' => MENU_CALLBACK); > } > else { //no cache > if (arg(1)>0) { //just load the node when there is a node > $node = node_load(arg(1)); > } > $items[] = array('path' => 'node/'. arg(1) .'/pressupostos', //if > I change this line, the tab appear > 'title' => t('Pressupost'), > 'callback' => 'drupal_get_form', > 'callback arguments' => > array('comtpacau_project_pressupost_form',arg(1)), > 'access' => ($node->type=='comptacau_project'), > 'type' => MENU_LOCAL_TASK); > } > return $items; > } > > What am I missing? > > thanks a lot > > On Thu, Jun 5, 2008 at 5:30 PM, Llu?s wrote: >> It works prefectly, thanks a lot. >> >> On Thu, Jun 5, 2008 at 5:02 PM, Saint-Genest Gwenael >> wrote: >>> Hi, >>> >>> You can use node_load() to get node type attribute. >>> >>> function comptacau_project_menu($may_cache) { >>> $items=array(); >>> if (arg(0) == 'node' && is_numeric(arg(1))) { >>> $node = node_load(arg(1)); >>> // DEBUG: Example with 'page' but can be anything else ... >>> if ($node->type == 'page') { >>> $items[] = array( >>> 'path' => 'node/'. arg(1) . '/pressupost_form', >>> 'title' => t('Pressupost'), >>> 'callback' => 'devel_load_object', >>> 'callback arguments' => array($node), >>> 'access' => user_access('access devel information'), >>> 'type' => MENU_LOCAL_TASK >>> ); >>> } >>> } >>> return $items; >>> } >>> >>> G. Saint-Genest >>> >>> -- >>> Gwenael Saint-Genest >>> MAKINA CORPUS - www.makina-corpus.com >>> 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire >>> Tel : +33 (0) 2 40 94 96 08 >>> >> >> >> >> -- >> *La felicitat ha de ser compatible, compartible i cooperativa. >> *Envellim quan els records superen les esperances. >> *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. >> *Abans d'imprimir aquest missatge, pensa en el medi ambient. >> > > > > -- > *La felicitat ha de ser compatible, compartible i cooperativa. > *Envellim quan els records superen les esperances. > *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. > *Abans d'imprimir aquest missatge, pensa en el medi ambient. > -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From gwenael.saint-genest at makina-corpus.com Fri Jun 6 08:54:08 2008 From: gwenael.saint-genest at makina-corpus.com (Saint-Genest Gwenael) Date: Fri, 06 Jun 2008 10:54:08 +0200 Subject: [development] MENU_LOCAL_TASK for just some node types In-Reply-To: <45a29f450806060126o74ae7db5y2f6a1a4e28aa613e@mail.gmail.com> References: <45a29f450806050527h76b660d8y5ddbdeaf86e0bc64@mail.gmail.com> <4847F22E.4070105@favias.org> <1010529256-1212675496-cardhu_decombobulator_blackberry.rim.net-2076604454-@bxe027.bisx.prod.on.blackberry> <45a29f450806050732o6bea8d9fo33f1e8cb9f59a6c4@mail.gmail.com> <4848000D.6090702@makina-corpus.com> <45a29f450806050830u6e5b066bxd117c2840914a8e8@mail.gmail.com> <45a29f450806060126o74ae7db5y2f6a1a4e28aa613e@mail.gmail.com> Message-ID: <4848FB30.8090309@makina-corpus.com> Llu?s wrote: > not prefectly; I have observed an odd behaviour with my function: it > just works the first time I change the path ("pressupostos" by > something else); as soon as I clear the cache (using devel module) the > tab disappear. > > function comptacau_project_menu() { (... snip ...) > > What am I missing? > > thanks a lot I think you can have best results with a "$may_cache" parameter to the function ;) Gwen -- Gwenael Saint-Genest MAKINA CORPUS - www.makina-corpus.com 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire Tel : +33 (0) 2 40 94 96 08 From mistknight at gmail.com Mon Jun 9 11:48:41 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Mon, 9 Jun 2008 14:48:41 +0300 Subject: [development] schema API add column after Message-ID: Hello all, I have an alter statement where I add a column at a specified location "ALTER TABLE {example} ADD COLUMN def TEXT AFTER abc" in drupal 5. Checking the schema API I can't see an equivalent to specify the position of the new field, I guess it just appends it at the end of the table. Any way to work around this? -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080609/3076cf02/attachment.htm From matej.svetlik at cetelem.sk Mon Jun 9 15:09:14 2008 From: matej.svetlik at cetelem.sk (Matej =?ISO-8859-1?Q?Svetl=EDk?=) Date: Mon, 09 Jun 2008 17:09:14 +0200 Subject: [development] schema API add column after In-Reply-To: References: Message-ID: <1213024154.5384.6.camel@svetlo.cetelem.sk> hello, why do you need to have table column at specified position? On Mon, 2008-06-09 at 14:48 +0300, Ashraf Amayreh wrote: > Hello all, > > I have an alter statement where I add a column at a specified location > "ALTER TABLE {example} ADD COLUMN def TEXT AFTER abc" in drupal 5. > > Checking the schema API I can't see an equivalent to specify the > position of the new field, I guess it just appends it at the end of > the table. > > Any way to work around this? > > -- > Ashraf Amayreh > http://blogs.aamayreh.org From mistknight at gmail.com Mon Jun 9 18:12:40 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Mon, 9 Jun 2008 21:12:40 +0300 Subject: [development] schema API add column after In-Reply-To: <1213024154.5384.6.camel@svetlo.cetelem.sk> References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: I'm a little confused here, the upgrade guide says how hook_update_N should use the schema API, does this apply to the already existing update hooks or to new ones only? Same goes for the update hook naming conventions that contain drupal major version and so forth, how does this affect the already existing update hooks from the module's 5.x version? On Mon, Jun 9, 2008 at 6:09 PM, Matej Svetl?k wrote: > hello, > > why do you need to have table column at specified position? > > On Mon, 2008-06-09 at 14:48 +0300, Ashraf Amayreh wrote: > > Hello all, > > > > I have an alter statement where I add a column at a specified location > > "ALTER TABLE {example} ADD COLUMN def TEXT AFTER abc" in drupal 5. > > > > Checking the schema API I can't see an equivalent to specify the > > position of the new field, I guess it just appends it at the end of > > the table. > > > > Any way to work around this? > > > > -- > > Ashraf Amayreh > > http://blogs.aamayreh.org > > -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080609/b41a6cab/attachment.htm From nan_wich at bellsouth.net Mon Jun 9 18:43:16 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 9 Jun 2008 14:43:16 -0400 Subject: [development] schema API add column after In-Reply-To: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: Matej Svetl?k wrote: > why do you need to have table column at specified position? I was trying to keep quiet, even though I have this same issue, but I can't now. Think about a new installation as opposed to an updated ("add column") installation. In the new installation, my schema says the columns come in the order, a, b, c, etc. but let's say we now want to add column d. For a new installation, it would look nicer to have it between b and c. The hook_schema can be done this way. But how does one tell MySql that we want it between b and c? In straight MySql, this is easy with the "AFTER COLUMN ..." cause. So, now you're going to ask, "What do you mean by 'it would look nicer'?" So I'll give you an example that I'm actually working on right now. I have a node extension table that has nid, vid, name, and more text fields. I am changing the name column from text to integer so that it can point to new table. I really prefer to keep integer columns (pointers) together. And, in this case, I am replacing one column with another (add new column, insert data, delete old column), so it would be nice to have the new column be in the "same place" the old one was before the update. Make sense? NancyDru -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.1.0/1492 - Release Date: 6/9/2008 10:29 AM From darthsteven at gmail.com Mon Jun 9 19:17:52 2008 From: darthsteven at gmail.com (Steven Jones) Date: Mon, 9 Jun 2008 20:17:52 +0100 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: Hi, I'd imagine that you could only use the schema API when it's available, so on your 6.x branch of your module. But isn't that when the numbering format changed for update functions too? You should always leave update hooks as is, unless they're buggy, right? On Mon, Jun 9, 2008 at 7:12 PM, Ashraf Amayreh wrote: > I'm a little confused here, the upgrade guide says how hook_update_N should > use the schema API, does this apply to the already existing update hooks or > to new ones only? Same goes for the update hook naming conventions that > contain drupal major version and so forth, how does this affect the already > existing update hooks from the module's 5.x version? > > On Mon, Jun 9, 2008 at 6:09 PM, Matej Svetl?k > wrote: >> >> hello, >> >> why do you need to have table column at specified position? >> >> On Mon, 2008-06-09 at 14:48 +0300, Ashraf Amayreh wrote: >> > Hello all, >> > >> > I have an alter statement where I add a column at a specified location >> > "ALTER TABLE {example} ADD COLUMN def TEXT AFTER abc" in drupal 5. >> > >> > Checking the schema API I can't see an equivalent to specify the >> > position of the new field, I guess it just appends it at the end of >> > the table. >> > >> > Any way to work around this? >> > >> > -- >> > Ashraf Amayreh >> > http://blogs.aamayreh.org >> > > > > -- > Ashraf Amayreh > http://blogs.aamayreh.org -- Regards Steven Jones From darrel.opry at gmail.com Mon Jun 9 19:26:01 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Mon, 9 Jun 2008 15:26:01 -0400 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: it would be nice if schema API handled this automatically based on index order in the schema array... That's what I would hope happens... If not maybe someone who wants this feature can write a patch for schema API. On Mon, Jun 9, 2008 at 2:43 PM, Nancy Wichmann wrote: > Matej Svetl?k wrote: > > > why do you need to have table column at specified position? > > I was trying to keep quiet, even though I have this same issue, but I can't > now. > > Think about a new installation as opposed to an updated ("add column") > installation. > > In the new installation, my schema says the columns come in the order, a, > b, > c, etc. but let's say we now want to add column d. For a new installation, > it would look nicer to have it between b and c. The hook_schema can be done > this way. But how does one tell MySql that we want it between b and c? In > straight MySql, this is easy with the "AFTER COLUMN ..." cause. > > So, now you're going to ask, "What do you mean by 'it would look nicer'?" > So I'll give you an example that I'm actually working on right now. I have > a > node extension table that has nid, vid, name, and more text fields. I am > changing the name column from text to integer so that it can point to new > table. I really prefer to keep integer columns (pointers) together. And, > in > this case, I am replacing one column with another (add new column, insert > data, delete old column), so it would be nice to have the new column be in > the "same place" the old one was before the update. > > Make sense? > > NancyDru > > > No virus found in this outgoing message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.1.0/1492 - Release Date: 6/9/2008 > 10:29 AM > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080609/42b3dc10/attachment.htm From mistknight at gmail.com Mon Jun 9 20:40:59 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Mon, 9 Jun 2008 23:40:59 +0300 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: It would be nice to patch it, but I'm sort of worried about upgrading to 6.x for the time being. I'm tempted to think the guidelines for the update hooks only apply to new update hooks and that users upgrading their installations must upgrade to the latest 5.x version of the module before upgrading to 6.x, is this accurate? On Mon, Jun 9, 2008 at 10:26 PM, Darrel O'Pry wrote: > it would be nice if schema API handled this automatically based on index > order in the schema array... That's what I would hope happens... If not > maybe someone who wants this feature can write a patch for schema API. > > On Mon, Jun 9, 2008 at 2:43 PM, Nancy Wichmann > wrote: > >> Matej Svetl?k wrote: >> >> > why do you need to have table column at specified position? >> >> I was trying to keep quiet, even though I have this same issue, but I >> can't >> now. >> >> Think about a new installation as opposed to an updated ("add column") >> installation. >> >> In the new installation, my schema says the columns come in the order, a, >> b, >> c, etc. but let's say we now want to add column d. For a new installation, >> it would look nicer to have it between b and c. The hook_schema can be >> done >> this way. But how does one tell MySql that we want it between b and c? In >> straight MySql, this is easy with the "AFTER COLUMN ..." cause. >> >> So, now you're going to ask, "What do you mean by 'it would look nicer'?" >> So I'll give you an example that I'm actually working on right now. I have >> a >> node extension table that has nid, vid, name, and more text fields. I am >> changing the name column from text to integer so that it can point to new >> table. I really prefer to keep integer columns (pointers) together. And, >> in >> this case, I am replacing one column with another (add new column, insert >> data, delete old column), so it would be nice to have the new column be in >> the "same place" the old one was before the update. >> >> Make sense? >> >> NancyDru >> >> >> No virus found in this outgoing message. >> Checked by AVG. >> Version: 8.0.100 / Virus Database: 270.1.0/1492 - Release Date: 6/9/2008 >> 10:29 AM >> >> > -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080609/f366765d/attachment.htm From karoly at negyesi.net Mon Jun 9 20:43:34 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Mon, 09 Jun 2008 22:43:34 +0200 (CEST) Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: > Make sense? Nope. I try to refrain from being a maths egghead but SQL does not need or rely on column order. Regards NK From darthsteven at gmail.com Mon Jun 9 20:48:02 2008 From: darthsteven at gmail.com (Steven Jones) Date: Mon, 9 Jun 2008 21:48:02 +0100 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: If you care that much, you're probably looking at the table in something like phpMyAdmin, in which case you can do this: http://dev.mysql.com/doc/refman/5.0/en/change-column-order.html otherwise just query the columns in a different order as chx says. On Mon, Jun 9, 2008 at 9:43 PM, Karoly Negyesi wrote: >> Make sense? > > Nope. I try to refrain from being a maths egghead but SQL does not need or rely on column order. > > Regards > > NK > -- Regards Steven Jones From mail at webthatworks.it Mon Jun 9 21:39:22 2008 From: mail at webthatworks.it (Ivan Sergio Borgonovo) Date: Mon, 9 Jun 2008 23:39:22 +0200 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: <20080609233922.71fa3693@dawn.webthatworks.it> On Mon, 09 Jun 2008 22:43:34 +0200 (CEST) "Karoly Negyesi" wrote: > > Make sense? > > Nope. I try to refrain from being a maths egghead but SQL does not > need or rely on column order. +1 Relying on column order is generally considered bad design and adding columns at a specified place is not supported on all DBs. I'm not sure being able to add a column in a specified place is part of the standard... but this doesn't make it a good design practice. Supporting bad design that risk to break stuff for other DB doesn't look as a good idea. Relaying on column order is hard to maintain and it is always accompanied by "select *" that may lead to very poor performances. eg. you add a column there but you don't tell your co-developer, you add a column there but you forget to add it to all your statements. Result: all your code will break or your statement will return an extra 20Kb of TEXT where it is not needed. You explicitly name columns and there will be higher chances that: a) your code will continue to work in most of the places b) you'll spot the places where you've to change it easier Once you support it in the API people will start to use it. There *may* be performance improvements having fixed size columns at the beginning of the table but this heavily depends on the implementation and well... most of the times when you're looking for performance improvements there... it is like to hope in extra boost adding some more stickers to your Corolla. Not all the times having one more weapon means being safer. -- Ivan Sergio Borgonovo http://www.webthatworks.it From drupal at oadaeh.net Mon Jun 9 23:07:30 2008 From: drupal at oadaeh.net (Jason Flatt) Date: Mon, 9 Jun 2008 16:07:30 -0700 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: <200806091607.30382.drupal@oadaeh.net> On Mon Jun 9 2008 1:48:02 pm Steven Jones wrote: > If you care that much, you're probably looking at the table in > something like phpMyAdmin, in which case you can do this: > http://dev.mysql.com/doc/refman/5.0/en/change-column-order.html > > otherwise just query the columns in a different order as chx says. No. What he said was that it doesn't matter what order the columns are in. He didn't say to query them in a different order. They can be queried in any order. > On Mon, Jun 9, 2008 at 9:43 PM, Karoly Negyesi wrote: > >> Make sense? > > > > Nope. I try to refrain from being a maths egghead but SQL does not need > > or rely on column order. > > > > Regards > > > > NK -- Jason Flatt http://www.oadaeh.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 15; Cramer, 13; Travis, 11; Angela; Harry, 7; and William, 2) Linux User: http://www.kubuntu.org/ Drupal Fanatic: http://drupal.org/ From mistknight at gmail.com Mon Jun 9 23:42:54 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Tue, 10 Jun 2008 02:42:54 +0300 Subject: [development] schema API add column after In-Reply-To: <200806091607.30382.drupal@oadaeh.net> References: <1213024154.5384.6.camel@svetlo.cetelem.sk> <200806091607.30382.drupal@oadaeh.net> Message-ID: I guess that as long as I could insert in any order I want there shouldn't be a problem, although having some users with a table that has columns with a different order than others seems a little awkward. On Tue, Jun 10, 2008 at 2:07 AM, Jason Flatt wrote: > On Mon Jun 9 2008 1:48:02 pm Steven Jones wrote: > > If you care that much, you're probably looking at the table in > > something like phpMyAdmin, in which case you can do this: > > http://dev.mysql.com/doc/refman/5.0/en/change-column-order.html > > > > otherwise just query the columns in a different order as chx says. > > No. What he said was that it doesn't matter what order the columns are in. > He > didn't say to query them in a different order. They can be queried in any > order. > > > > On Mon, Jun 9, 2008 at 9:43 PM, Karoly Negyesi > wrote: > > >> Make sense? > > > > > > Nope. I try to refrain from being a maths egghead but SQL does not need > > > or rely on column order. > > > > > > Regards > > > > > > NK > > > -- > Jason Flatt > http://www.oadaeh.net/ > Father of Six: http://www.flattfamily.com/ (Joseph, 15; Cramer, 13; > Travis, > 11; Angela; Harry, 7; and William, 2) > Linux User: http://www.kubuntu.org/ > Drupal Fanatic: http://drupal.org/ > -- Ashraf Amayreh http://blogs.aamayreh.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080610/d9bd5720/attachment.htm From kb at 2bits.com Tue Jun 10 04:18:08 2008 From: kb at 2bits.com (Khalid Baheyeldin) Date: Tue, 10 Jun 2008 00:18:08 -0400 Subject: [development] schema API add column after In-Reply-To: References: <1213024154.5384.6.camel@svetlo.cetelem.sk> Message-ID: <4a9fdc630806092118v783674e1n2e4633a5f96c7c56@mail.gmail.com> On Mon, Jun 9, 2008 at 4:43 PM, Karoly Negyesi wrote: > > Make sense? > > Nope. I try to refrain from being a maths egghead but SQL does not need or > rely on column order. > Agreed. If you are saying: INSERT INTO tablename VALUES ('a', 1, 2, 3, 'b'); Instead of INSERT INTO tablename (col1, col4, col2, col5, col3) VALUES ('a', 1, 2, 3, 'b'); Then you should change the former to the latter for maintenance's sake. (If you are coding for Drupal 6, better use drupal_write_record() anyways). But, there is a good reason to be able to control the column order: performance. If you have numeric or short columns following varchar or text columns, MySQL has to work more if you do a WHERE on the short columns vs. if the shorter and numeric columns are before the text columns. So, yes, don't rely on column positions from the programming point of view, but from a DBA point of you, they can make a difference. In fact NOT relying on the order when coding makes the life of a DBA easier, since he can move columns around as needed, without breaking code, whereas it would be impossible to do so if the code relies on position. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080610/657f1829/attachment.htm From drupal at reyero.net Tue Jun 10 10:57:30 2008 From: drupal at reyero.net (Jose A. Reyero) Date: Tue, 10 Jun 2008 12:57:30 +0200 Subject: [development] Easier PHP4 compatibility for Drupal modules Message-ID: <484E5E1A.2030608@reyero.net> Hello, It seems many of us -if not most of us- are already developing modules and other stuff using PHP5. As a module maintainer I'm bothered from time to time with "PHP4 compatibility" feature requests and patches that are usually like this one: |if (!function_exists('array_diff_key')) { function array_diff_key() { .... } } |So most of the times, its just a few conditional function definitions that will make the module backwards compatible with PHP4. I'm thinking it would be really nice to have a 'php4' Drupal module that handles these simple cases. Then we can just tell people wanting our modules to work with PHP4 to go and try this other module. This module also wouldn't even need to use conditional function definitions as it is supossed to be enabled only for PHP4 sites so it would be even easier. So.. Anyone? PS: Yes, I know, "why don't you do it yourself?" But a) I am already maintaining a number of modules and I can hardly keep up with the issue queue - I've already added some to the "Abandoned modules" user - and b) I'm not using PHP4 for anything anymore so I won't even be able to test such a module.... So please, someone who needs PHP4 compatibility..... Jose A. Reyero || From earnie at users.sourceforge.net Tue Jun 10 11:28:23 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 10 Jun 2008 07:28:23 -0400 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E5E1A.2030608@reyero.net> References: <484E5E1A.2030608@reyero.net> Message-ID: <20080610072823.kuezdofvkr0g4sk0@mail.progw.org> Quoting "Jose A. Reyero" : > > So.. Anyone? > I say just refer them to http://www.gophp5.org/ and add the banner to your project page. Drupal 7 will only support PHP5. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From eric.schaefer at eas-consulting.de Tue Jun 10 14:22:01 2008 From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer) Date: Tue, 10 Jun 2008 16:22:01 +0200 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <20080610072823.kuezdofvkr0g4sk0@mail.progw.org> References: <484E5E1A.2030608@reyero.net> <20080610072823.kuezdofvkr0g4sk0@mail.progw.org> Message-ID: <484E8E09.5000800@eas-consulting.de> Earnie Boyd schrieb: > I say just refer them to http://www.gophp5.org/ and add the banner to > your project page. How will that help small community sites with a cheap hosting company that refuses to upgrade to php5? > Drupal 7 will only support PHP5. There should be a cut like this to encourage the upgrade, but all previous versions including contributed modules should support php4. Eric From eric.schaefer at eas-consulting.de Tue Jun 10 14:25:43 2008 From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer) Date: Tue, 10 Jun 2008 16:25:43 +0200 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E5E1A.2030608@reyero.net> References: <484E5E1A.2030608@reyero.net> Message-ID: <484E8EE7.1060105@eas-consulting.de> Jose A. Reyero schrieb: > So.. Anyone? I was already thinking about something like this. We would probably only need to create the module with a couple of functions and let the crowd hand in patches for all the functions they need. I would give it a try, if no one else wants to do it. Eric From catch56 at googlemail.com Tue Jun 10 14:39:17 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 10 Jun 2008 15:39:17 +0100 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E8EE7.1060105@eas-consulting.de> References: <484E5E1A.2030608@reyero.net> <484E8EE7.1060105@eas-consulting.de> Message-ID: I can think of at least Date module which ships with a PHP4 compat module already. Having a centralised one would take the load off individual developers and IMO make it easier to drop PHP4 support later on (i.e. the module doesn't get upgraded to Drupal 7, and the modules which use it don't have to clear out a lot of PHP4 specific code when upgraded). Good idea. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080610/86fd6325/attachment.htm From nan_wich at bellsouth.net Tue Jun 10 15:01:07 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Tue, 10 Jun 2008 11:01:07 -0400 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E8EE7.1060105@eas-consulting.de> Message-ID: Eric-Alexander wrote: > need to create the module ... I would give it a try I would recommend that we just add a new piece to the Helpers module, which already exists to help developers. Nancy -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]On Behalf Of Schaefer Sent: Tuesday, June 10, 2008 10:26 AM To: development at drupal.org Subject: Re: [development] Easier PHP4 compatibility for Drupal modules Jose A. Reyero schrieb: > So.. Anyone? I was already thinking about something like this. We would probably only need to create the module with a couple of functions and let the crowd hand in patches for all the functions they need. I would give it a try, if no one else wants to do it. Eric -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.2.0/1494 - Release Date: 6/10/2008 7:22 AM From merlin at logrus.com Tue Jun 10 15:12:35 2008 From: merlin at logrus.com (Earl Miles) Date: Tue, 10 Jun 2008 08:12:35 -0700 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E8E09.5000800@eas-consulting.de> References: <484E5E1A.2030608@reyero.net> <20080610072823.kuezdofvkr0g4sk0@mail.progw.org> <484E8E09.5000800@eas-consulting.de> Message-ID: <484E99E3.7030305@logrus.com> Eric-Alexander Schaefer wrote: > Earnie Boyd schrieb: >> I say just refer them to http://www.gophp5.org/ and add the banner to >> your project page. > > How will that help small community sites with a cheap hosting company > that refuses to upgrade to php5? > >> Drupal 7 will only support PHP5. > > There should be a cut like this to encourage the upgrade, but all > previous versions including contributed modules should support php4. While Drupal 6 supports PHP4, there is absolutely no requirement for contrib modules for Drupal 6 to support PHP4. From morbus at disobey.com Tue Jun 10 15:20:56 2008 From: morbus at disobey.com (Morbus Iff) Date: Tue, 10 Jun 2008 11:20:56 -0400 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E99E3.7030305@logrus.com> References: <484E5E1A.2030608@reyero.net> <20080610072823.kuezdofvkr0g4sk0@mail.progw.org> <484E8E09.5000800@eas-consulting.de> <484E99E3.7030305@logrus.com> Message-ID: <484E9BD8.7010602@disobey.com> >>> Drupal 7 will only support PHP5. >> There should be a cut like this to encourage the upgrade, but all >> previous versions including contributed modules should support php4. > > While Drupal 6 supports PHP4, there is absolutely no requirement for > contrib modules for Drupal 6 to support PHP4. And, in fact, contrib modules can specify which version of PHP they run under, and Drupal will properly stop you from enabling that module should you not meet those requirements. -- Morbus Iff ( take your rosaries off my ovaries ) 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 larry at garfieldtech.com Tue Jun 10 15:21:35 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 10 Jun 2008 10:21:35 -0500 Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <484E8E09.5000800@eas-consulting.de> References: <484E8E09.5000800@eas-consulting.de> Message-ID: <118369a9f2a1e18f86904344d10fe4be@localhost> On Tue, 10 Jun 2008 16:22:01 +0200, Eric-Alexander Schaefer wrote: > Earnie Boyd schrieb: >> I say just refer them to http://www.gophp5.org/ and add the banner to >> your project page. > > How will that help small community sites with a cheap hosting company > that refuses to upgrade to php5? It gives them a nice long list of hosts who want their business and aren't hamstringing them. That's why GoPHP5 still has that list up. :-) >> Drupal 7 will only support PHP5. > > There should be a cut like this to encourage the upgrade, but all > previous versions including contributed modules should support php4. > > Eric PHP 4 vs. 5 compatibility is a lot more than just what functions are available. What you're looking for is the PHP_Compat library, available in PEAR. It's user-space backports of most of the new functions in PHP 5. It's under the PHP License, but I believe the author said he was willing to relicense it for us under the GPL. I actually wrote a patch to add about 80% of PHP_Compat to Drupal 6 early last year, which Dries rejected. (In hindsight, I believe he was right to do so.) One of the key problems with it, I didn't realize until later, is that PHP parses and loads conditionally loaded functions *even if the condition is never met*. The condition being met just aliases the internal name of the function (some gobbldygook unique string) to the requested name. It eats up memory either way. However, many many modules don't support PHP 4 for other reasons. Frankly I think it's foolish for any module that deals with XML to even bother trying to support PHP 4; the XML processing system is completely different, and PHP 5's XML processing can save you 40K of source code over PHP 4's. (cf, Amazon Tools module.) The way object references are handled are different as well. SPL classes really have no capability to be backported. Proper timezone support didn't exist until PHP 5.2, much less 5.1. Plus, many of us, like the OP, don't even have access to a PHP 4 system anymore to test against. I don't even know if some of my modules work in PHP 4. I agree that a common php4.module is better than several modules re-implementing various PHP 4 utilities themselves and causing namespace collisions. However, Drupal 6 modules that depend on PHP 5 features should be declaring that fact in their info files to prevent themselves from being installed on unsupported versions. Having a "compat" module will mean users will have to edit (hack) the info files of those modules to remove the php requirement line, and then hope that the PHP 5 features it depends on are covered by the compat module. I do not see "hack the module and pray" as a viable recommendation to give anyone. The better solution is to make it as easy as possible for people to migrate off of hosts that are still running a version of PHP that is no longer supported anyway. Point them to GoPHP5, point them to "migrating to a new sever" instructions on drupal.org, etc. Helping extend the life of PHP 4 is doing people a disservice, just as much as keeping them on Windows 98 for longer would be. --Larry Garfield From enboig at gmail.com Wed Jun 11 11:37:38 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Wed, 11 Jun 2008 13:37:38 +0200 Subject: [development] node/create inside a tab Message-ID: <45a29f450806110437w41c3b0f6n955fee629933d304@mail.gmail.com> I have created some node types, different views for them, and special forms. Now I want to make a page with tabs to them. Adding views and forms is easy; but I have problems with "add form": $items[] = array('path' => 'comptacau/assentaments/add', 'title' => t('Gesti? d\'assentaments'), 'callback' => 'drupal_get_form', 'callback arguments' => 'comptacau_assentament_form', 'access' => true, 'type' => MENU_CALLBACK); This doesn't work; any hint of how to achieve this? Is there a way to make an aliases: comptacau/assentament/add -> node/add/comptacau-assentament? thanks -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From karoly at negyesi.net Wed Jun 11 11:53:06 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Wed, 11 Jun 2008 13:53:06 +0200 (CEST) Subject: [development] Easier PHP4 compatibility for Drupal modules In-Reply-To: <118369a9f2a1e18f86904344d10fe4be@localhost> References: <484E8E09.5000800@eas-consulting.de> <118369a9f2a1e18f86904344d10fe4be@localhost> Message-ID: > It's user-space backports of most of the new functions in PHP 5. It's under the PHP License, but I believe > the author said he was willing to relicense it for us under the GPL. http://lists.drupal.org/pipermail/development/2006-November/020834.html From winborn at advomatic.com Wed Jun 11 15:07:10 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 11 Jun 2008 11:07:10 -0400 Subject: [development] What to do with Drupal FTP? Message-ID: <484FEA1E.5060007@advomatic.com> Regarding Drupal FTP at http://drupal.org/project/drupal_ftp I just had a conversation with chx in irc about the status of Drupal FTP, and its possible uses (if completed) for malware, and possible security holes. Particularly in light of the SoC project Plugin Manager, and that I stopped work on the project a year ago, I'm happy to drop the module. However, the concept itself does have some merit, and there are many other uses I can think of other than what's planned for the Plugin Manager. Additionally, I've had a few queries over the months that indicate some developers are actually using the module, although I imagine they're in the minority. The project itself came partly out of the poor file handling that Drupal has had in the past (but will hopefully be fixed with http://drupal.org/node/142995 hint hint...) So my question is what is the best course of action at this point? Currently, the module works, although is incomplete from its original goals. It does currently store the u/p of its designated FTP server, which is a weakness, although it would have to be developed beyond how it is to exploit that weakness. I have no intention in the near term of continuing development of the project, don't plan to upgrade it to Drupal 6, and believe a better approach for remote file handling will emerge for Drupal 7. Should I entirely remove the project? Officially abandon it? Amend or replace the project page with a warning, in case people are actually using it? Ask for a security team audit if we decide to keep it? Thanks, Aaron Winborn From winborn at advomatic.com Wed Jun 11 16:12:53 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 11 Jun 2008 12:12:53 -0400 Subject: [development] What to do with Drupal FTP? In-Reply-To: <484FEA1E.5060007@advomatic.com> References: <484FEA1E.5060007@advomatic.com> Message-ID: <484FF985.4040700@advomatic.com> Had a discussion with Thomas_Zahreddi1 in irc, and I suspect there may be more demand for the functionality than I'd suspected. But also got to thinking that Media Mover might be a better solution as well, in general, for most of what might be achieved with Drupal FTP. (I'd have to look at that module again; not sure how well it handles FTP already, assuming it does.) Aaron Winborn wrote: > Regarding Drupal FTP at http://drupal.org/project/drupal_ftp > > I just had a conversation with chx in irc about the status of Drupal > FTP, and its possible uses (if completed) for malware, and possible > security holes. Particularly in light of the SoC project Plugin > Manager, and that I stopped work on the project a year ago, I'm happy > to drop the module. > > However, the concept itself does have some merit, and there are many > other uses I can think of other than what's planned for the Plugin > Manager. Additionally, I've had a few queries over the months that > indicate some developers are actually using the module, although I > imagine they're in the minority. The project itself came partly out of > the poor file handling that Drupal has had in the past (but will > hopefully be fixed with http://drupal.org/node/142995 hint hint...) > > So my question is what is the best course of action at this point? > Currently, the module works, although is incomplete from its original > goals. It does currently store the u/p of its designated FTP server, > which is a weakness, although it would have to be developed beyond how > it is to exploit that weakness. > > I have no intention in the near term of continuing development of the > project, don't plan to upgrade it to Drupal 6, and believe a better > approach for remote file handling will emerge for Drupal 7. > > Should I entirely remove the project? Officially abandon it? Amend or > replace the project page with a warning, in case people are actually > using it? Ask for a security team audit if we decide to keep it? > > Thanks, > Aaron Winborn > From victorkane at gmail.com Wed Jun 11 16:18:05 2008 From: victorkane at gmail.com (Victor Kane) Date: Wed, 11 Jun 2008 13:18:05 -0300 Subject: [development] What to do with Drupal FTP? In-Reply-To: <484FF985.4040700@advomatic.com> References: <484FEA1E.5060007@advomatic.com> <484FF985.4040700@advomatic.com> Message-ID: Are you taking into account, since this is still open for discussion, the Joomla "callback" method: sites FTP placed in database, called by central server...? Of course, that would require push from the Drupal side... or from somewhere... Victor Kane http://awebfactory.com.ar On Wed, Jun 11, 2008 at 1:12 PM, Aaron Winborn wrote: > Had a discussion with Thomas_Zahreddi1 in irc, and I suspect there may be > more demand for the functionality than I'd suspected. But also got to > thinking that Media Mover might be a better solution as well, in general, > for most of what might be achieved with Drupal FTP. (I'd have to look at > that module again; not sure how well it handles FTP already, assuming it > does.) > > > Aaron Winborn wrote: > >> Regarding Drupal FTP at http://drupal.org/project/drupal_ftp >> >> I just had a conversation with chx in irc about the status of Drupal FTP, >> and its possible uses (if completed) for malware, and possible security >> holes. Particularly in light of the SoC project Plugin Manager, and that I >> stopped work on the project a year ago, I'm happy to drop the module. >> >> However, the concept itself does have some merit, and there are many other >> uses I can think of other than what's planned for the Plugin Manager. >> Additionally, I've had a few queries over the months that indicate some >> developers are actually using the module, although I imagine they're in the >> minority. The project itself came partly out of the poor file handling that >> Drupal has had in the past (but will hopefully be fixed with >> http://drupal.org/node/142995 hint hint...) >> >> So my question is what is the best course of action at this point? >> Currently, the module works, although is incomplete from its original goals. >> It does currently store the u/p of its designated FTP server, which is a >> weakness, although it would have to be developed beyond how it is to exploit >> that weakness. >> >> I have no intention in the near term of continuing development of the >> project, don't plan to upgrade it to Drupal 6, and believe a better approach >> for remote file handling will emerge for Drupal 7. >> >> Should I entirely remove the project? Officially abandon it? Amend or >> replace the project page with a warning, in case people are actually using >> it? Ask for a security team audit if we decide to keep it? >> >> Thanks, >> Aaron Winborn >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080611/1c14eb09/attachment-0001.htm From arthur at civicactions.com Wed Jun 11 16:10:50 2008 From: arthur at civicactions.com (arthur) Date: Wed, 11 Jun 2008 12:10:50 -0400 Subject: [development] What to do with Drupal FTP? In-Reply-To: <484FEA1E.5060007@advomatic.com> References: <484FEA1E.5060007@advomatic.com> Message-ID: I did an implementation of FTP for media_mover to harvest files from a server. I didn't didn't even realize that there was an ftp module (damn my lazy search habits). I actually think it'd be nice to have a abstract ftp module that other modules could implement. Yes, it has huge potential security issues, which does require implementations to be responsible as well as alert admins that they are opening up possible exploits. On the other hand, it gives huge functionality benefits- in my case, being able to move 100mb files without having users needing to deal with uploading via http is a big deal. I guess I'd rather see one module which does the implementation that tries to deal with the security issues rather than a dozen (like myself) going it alone... I'd be willing to lend a hand in submitting patches and what not if you want to keep the module going. arthur On Jun 11, 2008, at 11:07 AM, Aaron Winborn wrote: > Regarding Drupal FTP at http://drupal.org/project/drupal_ftp > > I just had a conversation with chx in irc about the status of Drupal > FTP, and its possible uses (if completed) for malware, and possible > security holes. Particularly in light of the SoC project Plugin > Manager, and that I stopped work on the project a year ago, I'm > happy to drop the module. > > However, the concept itself does have some merit, and there are many > other uses I can think of other than what's planned for the Plugin > Manager. Additionally, I've had a few queries over the months that > indicate some developers are actually using the module, although I > imagine they're in the minority. The project itself came partly out > of the poor file handling that Drupal has had in the past (but will > hopefully be fixed with http://drupal.org/node/142995 hint hint...) > > So my question is what is the best course of action at this point? > Currently, the module works, although is incomplete from its > original goals. It does currently store the u/p of its designated > FTP server, which is a weakness, although it would have to be > developed beyond how it is to exploit that weakness. > > I have no intention in the near term of continuing development of > the project, don't plan to upgrade it to Drupal 6, and believe a > better approach for remote file handling will emerge for Drupal 7. > > Should I entirely remove the project? Officially abandon it? Amend > or replace the project page with a warning, in case people are > actually using it? Ask for a security team audit if we decide to > keep it? > > Thanks, > Aaron Winborn > --------------------------------------------------- arthur at civicactions.com From enboig at gmail.com Wed Jun 11 16:20:21 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Wed, 11 Jun 2008 18:20:21 +0200 Subject: [development] node/create inside a tab In-Reply-To: <45a29f450806110437w41c3b0f6n955fee629933d304@mail.gmail.com> References: <45a29f450806110437w41c3b0f6n955fee629933d304@mail.gmail.com> Message-ID: <45a29f450806110920i3bccefbbtb3369b2251446c3a@mail.gmail.com> at last I found the correct callback: $items[] = array('path' => 'comptacau/moviments/ingressos/afegir', 'title' => t('Afegir un ingr?s'), 'callback' => 'node_add', 'callback arguments' => 'comptacau-ingres', 'access' => true, 'type' => MENU_NORMAL_ITEM); 2008/6/11 Llu?s : > I have created some node types, different views for them, and special > forms. Now I want to make a page with tabs to them. Adding views and > forms is easy; but I have problems with "add form": > > $items[] = array('path' => 'comptacau/assentaments/add', > 'title' => t('Gesti? d\'assentaments'), > 'callback' => 'drupal_get_form', > 'callback arguments' => 'comptacau_assentament_form', > 'access' => true, > 'type' => MENU_CALLBACK); > > This doesn't work; any hint of how to achieve this? Is there a way to > make an aliases: > comptacau/assentament/add -> node/add/comptacau-assentament? > > thanks > > -- > *La felicitat ha de ser compatible, compartible i cooperativa. > *Envellim quan els records superen les esperances. > *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. > *Abans d'imprimir aquest missatge, pensa en el medi ambient. > -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From fgm at osinet.fr Wed Jun 11 16:30:21 2008 From: fgm at osinet.fr (FGM) Date: Wed, 11 Jun 2008 18:30:21 +0200 Subject: [development] What to do with Drupal FTP? References: <484FEA1E.5060007@advomatic.com> Message-ID: <01a701c8cbe0$7699c180$2401a8c0@pcosi> I happen to have an FTP client too. Maybe interesting as it's driven by an external state machine and can conduct batch operations with progress displays. It's not a module, though, but designed for PHP-GTK. But it might prove useful. ----- Original Message ----- From: "arthur" To: Sent: Wednesday, June 11, 2008 6:10 PM Subject: Re: [development] What to do with Drupal FTP? I did an implementation of FTP for media_mover to harvest files from a server. I didn't didn't even realize that there was an ftp module (damn my lazy search habits). I actually think it'd be nice to have a abstract ftp module that other modules could implement. Yes, it has huge potential security issues, which does require implementations to be responsible as well as alert admins that they are opening up possible exploits. On the other hand, it gives huge functionality benefits- in my case, being able to move 100mb files without having users needing to deal with uploading via http is a big deal. I guess I'd rather see one module which does the implementation that tries to deal with the security issues rather than a dozen (like myself) going it alone... I'd be willing to lend a hand in submitting patches and what not if you want to keep the module going. arthur On Jun 11, 2008, at 11:07 AM, Aaron Winborn wrote: > Regarding Drupal FTP at http://drupal.org/project/drupal_ftp > > I just had a conversation with chx in irc about the status of Drupal > FTP, and its possible uses (if completed) for malware, and possible > security holes. Particularly in light of the SoC project Plugin > Manager, and that I stopped work on the project a year ago, I'm > happy to drop the module. > > However, the concept itself does have some merit, and there are many > other uses I can think of other than what's planned for the Plugin > Manager. Additionally, I've had a few queries over the months that > indicate some developers are actually using the module, although I > imagine they're in the minority. The project itself came partly out > of the poor file handling that Drupal has had in the past (but will > hopefully be fixed with http://drupal.org/node/142995 hint hint...) > > So my question is what is the best course of action at this point? > Currently, the module works, although is incomplete from its > original goals. It does currently store the u/p of its designated > FTP server, which is a weakness, although it would have to be > developed beyond how it is to exploit that weakness. > > I have no intention in the near term of continuing development of > the project, don't plan to upgrade it to Drupal 6, and believe a > better approach for remote file handling will emerge for Drupal 7. > > Should I entirely remove the project? Officially abandon it? Amend > or replace the project page with a warning, in case people are > actually using it? Ask for a security team audit if we decide to > keep it? > > Thanks, > Aaron Winborn > --------------------------------------------------- arthur at civicactions.com From winborn at advomatic.com Wed Jun 11 16:35:30 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 11 Jun 2008 12:35:30 -0400 Subject: [development] What to do with Drupal FTP? In-Reply-To: References: <484FEA1E.5060007@advomatic.com> Message-ID: <484FFED2.80005@advomatic.com> I like the idea of an FTP API for similar modules to take advantage of. I'm not attached to it being Drupal FTP, although it does seem like a good enough namespace at this time. I just posted at http://groups.drupal.org/node/10893#comment-39618 as well, as I think the Plugin Manager soc project might also benefit from this. arthur wrote: > I did an implementation of FTP for media_mover to harvest files from a > server. I didn't didn't even realize that there was an ftp module > (damn my lazy search habits). > > I actually think it'd be nice to have a abstract ftp module that other > modules could implement. Yes, it has huge potential security issues, > which does require implementations to be responsible as well as alert > admins that they are opening up possible exploits. On the other hand, > it gives huge functionality benefits- in my case, being able to move > 100mb files without having users needing to deal with uploading via > http is a big deal. > > I guess I'd rather see one module which does the implementation that > tries to deal with the security issues rather than a dozen (like > myself) going it alone... > > I'd be willing to lend a hand in submitting patches and what not if > you want to keep the module going. > > > arthur > > > > > On Jun 11, 2008, at 11:07 AM, Aaron Winborn wrote: > >> Regarding Drupal FTP at http://drupal.org/project/drupal_ftp >> >> I just had a conversation with chx in irc about the status of Drupal >> FTP, and its possible uses (if completed) for malware, and possible >> security holes. Particularly in light of the SoC project Plugin >> Manager, and that I stopped work on the project a year ago, I'm happy >> to drop the module. >> >> However, the concept itself does have some merit, and there are many >> other uses I can think of other than what's planned for the Plugin >> Manager. Additionally, I've had a few queries over the months that >> indicate some developers are actually using the module, although I >> imagine they're in the minority. The project itself came partly out >> of the poor file handling that Drupal has had in the past (but will >> hopefully be fixed with http://drupal.org/node/142995 hint hint...) >> >> So my question is what is the best course of action at this point? >> Currently, the module works, although is incomplete from its original >> goals. It does currently store the u/p of its designated FTP server, >> which is a weakness, although it would have to be developed beyond >> how it is to exploit that weakness. >> >> I have no intention in the near term of continuing development of the >> project, don't plan to upgrade it to Drupal 6, and believe a better >> approach for remote file handling will emerge for Drupal 7. >> >> Should I entirely remove the project? Officially abandon it? Amend or >> replace the project page with a warning, in case people are actually >> using it? Ask for a security team audit if we decide to keep it? >> >> Thanks, >> Aaron Winborn >> > > --------------------------------------------------- > arthur at civicactions.com > > > From drewish at katherinehouse.com Wed Jun 11 18:03:54 2008 From: drewish at katherinehouse.com (andrew morton) Date: Wed, 11 Jun 2008 11:03:54 -0700 Subject: [development] node/create inside a tab In-Reply-To: <45a29f450806110920i3bccefbbtb3369b2251446c3a@mail.gmail.com> References: <45a29f450806110437w41c3b0f6n955fee629933d304@mail.gmail.com> <45a29f450806110920i3bccefbbtb3369b2251446c3a@mail.gmail.com> Message-ID: On Wed, Jun 11, 2008 at 9:20 AM, Llu?s wrote: > at last I found the correct callback: > > $items[] = array('path' => 'comptacau/moviments/ingressos/afegir', > 'title' => t('Afegir un ingr?s'), > 'callback' => 'node_add', > 'callback arguments' => 'comptacau-ingres', > 'access' => true, > 'type' => MENU_NORMAL_ITEM); Shouldn't callback arguments be an array rather than a string? http://api.drupal.org/api/function/hook_menu/5 andrew From drupal at dave-cohen.com Wed Jun 11 18:07:15 2008 From: drupal at dave-cohen.com (Dave Cohen) Date: Wed, 11 Jun 2008 11:07:15 -0700 Subject: [development] What to do with Drupal FTP? In-Reply-To: <484FEA1E.5060007@advomatic.com> References: <484FEA1E.5060007@advomatic.com> Message-ID: <200806111107.15113.drupal@dave-cohen.com> On Wednesday 11 June 2008, Aaron Winborn wrote: > Regarding Drupal FTP at http://drupal.org/project/drupal_ftp [snip] > ... The project itself came partly out of > the poor file handling that Drupal has had in the past (but will > hopefully be fixed with http://drupal.org/node/142995 hint hint...) [snip] I'm all in favor of improving Drupal's core file handling. But also when discussions like this come up, I mention http://drupal.org/project/upapi (Upload API contrib module). If I could rally the troops around this module it could become a great thing. One thing this module does is invoke hooks to let other modules know when new files have been uploaded and act on them. I can imagine an add-on that detects FTPed files, and inserts them into the upapi system (which currently only supports uploads via forms). > Should I entirely remove the project? Officially abandon it? Amend or > replace the project page with a warning, in case people are actually > using it? Ask for a security team audit if we decide to keep it? I'd maintain it if you need it, hand it off if you don't. But don't remove it entirely. -Dave From doug.holton at gmail.com Wed Jun 11 23:18:49 2008 From: doug.holton at gmail.com (Doug Holton) Date: Wed, 11 Jun 2008 17:18:49 -0600 Subject: [development] possible change in xml on update.drupal.org site breaks drush Message-ID: <48505D59.9010501@gmail.com> I wasn't sure if there is a project page for the update.drupal.org site to post this. Was the xml output on that site recently changed? For example with this xml file: http://updates.drupal.org/release-history/lightbox2/5.x The update-status module's xml parser class (I'm using drupal 5.7) removes all information between the tag and the tag. That breaks drush because it needs the "default_major" data. Here's an issue with more information: http://drupal.org/node/269444 From darrel.opry at gmail.com Wed Jun 11 23:27:39 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Wed, 11 Jun 2008 19:27:39 -0400 Subject: [development] What to do with Drupal FTP? In-Reply-To: <200806111107.15113.drupal@dave-cohen.com> References: <484FEA1E.5060007@advomatic.com> <200806111107.15113.drupal@dave-cohen.com> Message-ID: On Wed, Jun 11, 2008 at 2:07 PM, Dave Cohen wrote: > I'm all in favor of improving Drupal's core file handling. But also when > discussions like this come up, I mention http://drupal.org/project/upapi > (Upload API contrib module). If I could rally the troops around this > module > it could become a great thing. > > One thing this module does is invoke hooks to let other modules know when > new > files have been uploaded and act on them. I can imagine an add-on that > detects FTPed files, and inserts them into the upapi system (which > currently > only supports uploads via forms) Dave, why rally troops around a contrib module instead of a core patch? The UpAPI module is awesome work and implements some really cool stuff, but is irrelevant to the discussion of Drupal FTP and it's merit. I think having ftp client implementations aren't really the greatest thing, especially when PHP's native stream wrappers include FTP and SFTP/SSH. There is a patch floating around for stream wrapper support in core http://drupal.org/node/227232 which would deprecate most of these types of file clients. I think modules like drupal_ftp and media_mover are excellent use cases for stream wrapper support in core. If it were me I'd list it as officially abandoned if you don't need it and let people know it's looking for a maintainer if anyone requires it. .darrel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080611/3e8f3c60/attachment-0001.htm From winborn at advomatic.com Thu Jun 12 00:48:15 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 11 Jun 2008 20:48:15 -0400 Subject: [development] What to do with Drupal FTP? In-Reply-To: References: <484FEA1E.5060007@advomatic.com> <200806111107.15113.drupal@dave-cohen.com> Message-ID: <4850724F.2010609@advomatic.com> An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080611/6b3ec6a3/attachment.htm From daniel at morante.net Thu Jun 12 16:48:34 2008 From: daniel at morante.net (Daniel Morante) Date: Thu, 12 Jun 2008 12:48:34 -0400 Subject: [development] WebCalendar Module Message-ID: <1213289314.6305.2.camel@ubuntu-desktop> I've updated the WebCalendar integration module so that is (partly) works with Drupal 6.0 (user accounts are not integrated yet). How would I submit my changes? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080612/7b32fbed/attachment.htm From darrenoh at sidepotsinternational.com Thu Jun 12 17:07:45 2008 From: darrenoh at sidepotsinternational.com (Darren Oh) Date: Thu, 12 Jun 2008 13:07:45 -0400 Subject: [development] WebCalendar Module In-Reply-To: <1213289314.6305.2.camel@ubuntu-desktop> References: <1213289314.6305.2.camel@ubuntu-desktop> Message-ID: Go to the project page and submit a patch. On Jun 12, 2008, at 12:48 PM, Daniel Morante wrote: > I've updated the WebCalendar integration module so that is (partly) > works with Drupal 6.0 (user accounts are not integrated yet). How > would I submit my changes? From bob.pepin at gmail.com Thu Jun 12 23:59:22 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Fri, 13 Jun 2008 01:59:22 +0200 Subject: [development] Drupal 6.2 theme system standalone Message-ID: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> Hello, I've extracted a couple of functions from drupal 6.2 so I can use drupal themes in my own CMS without using the rest of drupal. It's only been a couple of hours since I started work on this, so this is still all very rough. So far it runs the themes included with drupal (bluemarine, chameleon, garland and pushbutton) and the internet_services theme from the drupal themes site. To play with it, you need to extract the attached file into a directory and copy the include/theme.inc file and the themes/ folder from the drupal distribution into that directory. Bob -------------- next part -------------- A non-text attachment was scrubbed... Name: theme-standalone.tar.gz Type: application/x-gzip Size: 17604 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080613/f7f24de8/attachment-0001.bin From juan.fco.rodriguez at gmail.com Fri Jun 13 12:18:21 2008 From: juan.fco.rodriguez at gmail.com (Juan Rodriguez) Date: Fri, 13 Jun 2008 14:18:21 +0200 Subject: [development] Why function t() arguments are not passed through t() again ? Message-ID: <96b30c400806130518o6a0316b2xb91425412e02115e@mail.gmail.com> Hello, I am trying to translate what comes from the following piece of code inside node.module:node_add() .... drupal_set_title(t('Submit @name', array('@name' => $types[$type]->name))); .... Using localization I can translate "Submit @name" to "Enviar @name". The problem is that the node type name is written in english and I can not change that name without breaking a lot of custom pages. I wonder why the previous line is not written this way: ... drupal_set_title(t('Submit @name', array('@name' => t($types[$type]->name)))); ... Another option would be to modify function t(), to automatically pass all arguments through t(). Do you see any problem with modifiying t() ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080613/79c90d03/attachment.htm From enboig at gmail.com Fri Jun 13 12:23:39 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Fri, 13 Jun 2008 14:23:39 +0200 Subject: [development] problem rebuild-permissions Message-ID: <45a29f450806130523t3e109a27xb31b1b981d528fc6@mail.gmail.com> I have problems rebuilding my node_access table (too much nodes...). Increasing my php execution time/memory limit is not an option so I thougth of creating a script which updates one node at a time, and using javascript loads to save the next node (I know making a module with ajax would be more elegant, but not enough time...) It basically recive a nid, load the node, node_access_acquire_grants(), and refresh with the next node. Should it work or it has some problem? thanks %d ORDER BY nid",$_GET['node'])); if ($actual>0) { $sencer=node_load($actual); node_access_acquire_grants($sencer); } ?> 0 ? " onLoad=\"setTimeout('delayer()', 1000)\"" : "") ?>> 0) echo "doing...".$actual; else echo "Done"; ?> -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From gabor at hojtsy.hu Fri Jun 13 12:26:28 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Fri, 13 Jun 2008 14:26:28 +0200 Subject: [development] Why function t() arguments are not passed through t() again ? In-Reply-To: <96b30c400806130518o6a0316b2xb91425412e02115e@mail.gmail.com> References: <96b30c400806130518o6a0316b2xb91425412e02115e@mail.gmail.com> Message-ID: <86ca3ccb0806130526o68f52925p65b644b5e0735c73@mail.gmail.com> On Fri, Jun 13, 2008 at 2:18 PM, Juan Rodriguez wrote: > Using localization I can translate "Submit @name" to "Enviar @name". > The problem is that the node type name is written in english and I can not > change that name > without breaking a lot of custom pages. > I wonder why the previous line is not written this way: > ... > drupal_set_title(t('Submit @name', array('@name' => > t($types[$type]->name)))); > ... Because t() translates static text (coming from source code), not user entered text (such as the node type name). > Another option would be to modify function t(), to automatically pass all > arguments through > t(). > Do you see any problem with modifiying t() ? So that would make all user names, numbers, etc end up in the translation table, right?. Such as t('@number of new posts', array('@number' => $new_post_count) would always t() the $new_post_count, and you would get 1, 2, 3, 4, up until infinity in your translation table. I don't think this is what you want. Gabor From earnie at users.sourceforge.net Fri Jun 13 12:35:50 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Fri, 13 Jun 2008 08:35:50 -0400 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> Message-ID: <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> Quoting Bob Pepin : > Hello, > I've extracted a couple of functions from drupal 6.2 so I can use > drupal themes in my own CMS without using the rest of drupal. It's > only been a couple of hours since I started work on this, so this is > still all very rough. > So far it runs the themes included with drupal (bluemarine, chameleon, > garland and pushbutton) and the internet_services theme from the > drupal themes site. > > To play with it, you need to extract the attached file into a > directory and copy the include/theme.inc file and the themes/ folder > from the drupal distribution into that directory. > Excuse my harshness in this but why should I really care about your fork of the Drupal theme engine to another CMS? This list is about coding for Drupal and I don't see how what you have is about coding for Drupal. What you have posted is about using pieces of Drupal in other software which isn't quite what I think this list is for. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From recidive at gmail.com Fri Jun 13 15:04:07 2008 From: recidive at gmail.com (Henrique Recidive) Date: Fri, 13 Jun 2008 12:04:07 -0300 Subject: [development] Why function t() arguments are not passed through t() again ? In-Reply-To: <96b30c400806130518o6a0316b2xb91425412e02115e@mail.gmail.com> References: <96b30c400806130518o6a0316b2xb91425412e02115e@mail.gmail.com> Message-ID: <841684fe0806130804o1ff30985v8b4ac9d976b5f324@mail.gmail.com> 2008/6/13 Juan Rodriguez : > Hello, > > I am trying to translate what comes from the following piece of code inside > node.module:node_add() > .... > drupal_set_title(t('Submit @name', array('@name' => > $types[$type]->name))); > .... > Using localization I can translate "Submit @name" to "Enviar @name". > The problem is that the node type name is written in english and I can not > change that name > without breaking a lot of custom pages. If you are running Drupal 5+, go to admin/content/types and change the node type 'nice name' there. > I wonder why the previous line is not written this way: > ... > drupal_set_title(t('Submit @name', array('@name' => > t($types[$type]->name)))); > ... > Another option would be to modify function t(), to automatically pass all > arguments through > t(). > Do you see any problem with modifiying t() ? > > From darrel.opry at gmail.com Fri Jun 13 16:19:17 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Fri, 13 Jun 2008 12:19:17 -0400 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> Message-ID: Hey Bob, that totally awesome. I'd love to know how you got around hook theme.. and I think a decent amount of work has gone into keeping various drupal subsystems as pretty stand alone... basically the stuff in the includes directory... awesome to hear you're working with porting the theme system... I assume we're talking phptemplate, cuz that stuff is just awesome.. Just remember the licensing, and credit where credit is due :).. /me points at Adrian and all the people in the room who have contributed to Drupal's theme system over time. .darrel. On Fri, Jun 13, 2008 at 8:35 AM, Earnie Boyd wrote: > Quoting Bob Pepin : > > Hello, >> I've extracted a couple of functions from drupal 6.2 so I can use >> drupal themes in my own CMS without using the rest of drupal. It's >> only been a couple of hours since I started work on this, so this is >> still all very rough. >> So far it runs the themes included with drupal (bluemarine, chameleon, >> garland and pushbutton) and the internet_services theme from the >> drupal themes site. >> >> To play with it, you need to extract the attached file into a >> directory and copy the include/theme.inc file and the themes/ folder >> from the drupal distribution into that directory. >> >> > Excuse my harshness in this but why should I really care about your fork of > the Drupal theme engine to another CMS? This list is about coding for > Drupal and I don't see how what you have is about coding for Drupal. What > you have posted is about using pieces of Drupal in other software which > isn't quite what I think this list is for. > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080613/0ed5acc6/attachment.htm From mgalvin at simplifiedcomplexity.org Fri Jun 13 16:59:14 2008 From: mgalvin at simplifiedcomplexity.org (Matt Galvin) Date: Fri, 13 Jun 2008 12:59:14 -0400 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> Message-ID: On Fri, Jun 13, 2008 at 8:35 AM, Earnie Boyd wrote: > Excuse my harshness in this but why should I really care about your fork of > the Drupal theme engine to another CMS? This list is about coding for > Drupal and I don't see how what you have is about coding for Drupal. What > you have posted is about using pieces of Drupal in other software which > isn't quite what I think this list is for. In general (not to target you directly in any way) there is not really an excuse for harshness in email. You have time to think and write polite and respectful words. If you don't want to sound harsh, don't be harsh. Drupal is open source. Anyone is free to use it for what they wish as long as they share their derivative work. He is sharing his. It may not be useful for you but it might be for someone. Among other things Drupal takes PHPTemplate and builds on top of it for theming. What Bob is doing is not all that different. While it is not about Drupal development itself, it is about using Drupal's code base which might be relevant to any Drupal developer even if only to say that he tried something that he thought was possible and is making it work. You never know what may come if it (or anything on or around Drupal). It is nice to at least hear of these things so we are aware of them, IMHO. Thanks for sharing Bob. Best, Matt From adrian at bryght.com Fri Jun 13 17:04:04 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Fri, 13 Jun 2008 19:04:04 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> Message-ID: <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote: > > Drupal is open source. Anyone is free to use it for what they wish as > long as they share their derivative work. He is sharing his. It may > not be useful for you but it might be for someone. Among other things > Drupal takes PHPTemplate and builds on top of it for theming. What Bob > is doing is not all that different. yeah. tbh, i wrote and tested phptemplate (and formsapi) completely separately from drupal before starting to integrate it. Some of the more recent changes in D6 might make it a bit harder to separate, but it should still be workable. From naheemzaffar at gmail.com Fri Jun 13 17:14:54 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 13 Jun 2008 18:14:54 +0100 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> Message-ID: <3adc77210806131014m77d043a0xe9973c51fc7cb0ea@mail.gmail.com> I am someone who could have used this when migrating from wordpress with a combination of "legacy" php flat files that called into wordpress for theming. In the end I decided to leave both the wordpress theme and the theming of the flat files (through wordpress) as is, but that decision means most of the older pages look very different from the newer ones, have different formatting, different menus. In short, what is outlined in the first post would be extremely helpful for people coming from a similar situation. A helping hand in moving TO Drupal, not away from it. From agentrickard at gmail.com Fri Jun 13 17:15:29 2008 From: agentrickard at gmail.com (Ken Rickard) Date: Fri, 13 Jun 2008 13:15:29 -0400 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> Message-ID: <25b45da00806131015nf2b63a1w56b6dbafd84438@mail.gmail.com> Question for the pseudo lawyers in the room. Does this mean that Bob's work must be GPL'd? On Fri, Jun 13, 2008 at 1:04 PM, Adrian Rossouw wrote: > > On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote: > > >> Drupal is open source. Anyone is free to use it for what they wish as >> long as they share their derivative work. He is sharing his. It may >> not be useful for you but it might be for someone. Among other things >> Drupal takes PHPTemplate and builds on top of it for theming. What Bob >> is doing is not all that different. >> > yeah. tbh, i wrote and tested phptemplate (and formsapi) completely > separately > from drupal before starting to integrate it. > > Some of the more recent changes in D6 might make it a bit harder to > separate, > but it should still be workable. > > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080613/6eabeb44/attachment.htm From bob.pepin at gmail.com Fri Jun 13 18:10:43 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Fri, 13 Jun 2008 20:10:43 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <25b45da00806131015nf2b63a1w56b6dbafd84438@mail.gmail.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> <25b45da00806131015nf2b63a1w56b6dbafd84438@mail.gmail.com> Message-ID: <3480f31c0806131110v1c6f84d8g377885a6726b93c7@mail.gmail.com> Well for now I've put GPL on it, which makes sense cause a lot of what I have done is simply assembling the drupal functions used by the theme system into one place. You could even create a script for extracting those functions from the drupal codebase, which would also make maintenance easier, maybe something like this even exists already? Besides, I figured most of the development happening on this will be improving compatibility with certain themes by either importing or adding stubs for the extra drupal functions used by them, which is something where it makes a lot of sense to share contributions. Anyway, I plan on layering a very thin entry point to this library just on top of the drupal callbacks, so the idea is for example not to implement any custom cache facility inside this but instead to provide hooks where you can register your own routines for handling caching from outside the library. This will hopefully prevent the GPL from infecting your projects ;) But besides, I'd also be interested to know if theoretically I would be forced to use the GPL in this particular case, so if we've got any license war veterans in here, feel free to comment. On Fri, Jun 13, 2008 at 19:15, Ken Rickard wrote: > Question for the pseudo lawyers in the room. Does this mean that Bob's work > must be GPL'd? > > > On Fri, Jun 13, 2008 at 1:04 PM, Adrian Rossouw wrote: >> >> On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote: >> >>> >>> Drupal is open source. Anyone is free to use it for what they wish as >>> long as they share their derivative work. He is sharing his. It may >>> not be useful for you but it might be for someone. Among other things >>> Drupal takes PHPTemplate and builds on top of it for theming. What Bob >>> is doing is not all that different. >> >> yeah. tbh, i wrote and tested phptemplate (and formsapi) completely >> separately >> from drupal before starting to integrate it. >> >> Some of the more recent changes in D6 might make it a bit harder to >> separate, >> but it should still be workable. >> > > > > -- > Ken Rickard > agentrickard at gmail.com > http://ken.therickards.com From drewish at katherinehouse.com Fri Jun 13 18:12:23 2008 From: drewish at katherinehouse.com (andrew morton) Date: Fri, 13 Jun 2008 11:12:23 -0700 Subject: [development] problem rebuild-permissions In-Reply-To: <45a29f450806130523t3e109a27xb31b1b981d528fc6@mail.gmail.com> References: <45a29f450806130523t3e109a27xb31b1b981d528fc6@mail.gmail.com> Message-ID: On Fri, Jun 13, 2008 at 5:23 AM, Llu?s wrote: > I have problems rebuilding my node_access table (too much nodes...). > Increasing my php execution time/memory limit is not an option ... Yeah this was a problem in D5. In D6 there's the batch api that handles this. You might mine this issue for hints: http://drupal.org/node/144337 andrew From larry at garfieldtech.com Fri Jun 13 19:34:09 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 13 Jun 2008 14:34:09 -0500 Subject: [development] Drupal 6.2 theme system standalone Message-ID: <3c744ea6348121b38bd33e2140968d7d@localhost> Because the code is derived from Drupal, yes, it must be distributed under the GPL if it is distributed. (There is no legal requirement that you distribute your changes at all, just that if you distribute them you do so under the GPL). Other PHP code that interacts with these "extracted subsystems" *is* affected by the GPL as well. Because it is interacting in the same memory space and sharing the same data structures, the combined work is then a derivative work of the extracted subsystem, and therefore the GPL on the extracted subsystem requires that the combined work also be distributed under the GPL if it is distributed. So the sort of API trickery you describe below is irrelevant; the GPL still applies. If you wanted the trickery below to work, you'd need to be using the LGPL, which exists for exactly that purpose. (That is an aside, though, since Drupal is under the GPL only.) In general, as long as the license is followed I have no problem with these "extracted systems". I think they're actually very good for Drupal, because we *should* be making subsystems that are as insulated from each other and loosely coupled as possible. I actually would love to see efforts like this contribute back to Drupal to help make our subsystems even more modular and loosely coupled. I've been seriously considering doing the same to the new database API after it lands for the same reasons; it's cool in its own right, and modularity is a very good thing. --Larry Garfield On Fri, 13 Jun 2008 20:10:43 +0200, "Bob Pepin" wrote: > Well for now I've put GPL on it, which makes sense cause a lot of what > I have done is simply assembling the drupal functions used by the > theme system into one place. You could even create a script for > extracting those functions from the drupal codebase, which would also > make maintenance easier, maybe something like this even exists > already? Besides, I figured most of the development happening on this > will be improving compatibility with certain themes by either > importing or adding stubs for the extra drupal functions used by them, > which is something where it makes a lot of sense to share > contributions. > > Anyway, I plan on layering a very thin entry point to this library > just on top of the drupal callbacks, so the idea is for example not to > implement any custom cache facility inside this but instead to provide > hooks where you can register your own routines for handling caching > from outside the library. This will hopefully prevent the GPL from > infecting your projects ;) > > But besides, I'd also be interested to know if theoretically I would > be forced to use the GPL in this particular case, so if we've got any > license war veterans in here, feel free to comment. > > On Fri, Jun 13, 2008 at 19:15, Ken Rickard wrote: >> Question for the pseudo lawyers in the room. Does this mean that Bob's > work >> must be GPL'd? >> >> >> On Fri, Jun 13, 2008 at 1:04 PM, Adrian Rossouw > wrote: >>> >>> On 13 Jun 2008, at 6:59 PM, Matt Galvin wrote: >>> >>>> >>>> Drupal is open source. Anyone is free to use it for what they wish as >>>> long as they share their derivative work. He is sharing his. It may >>>> not be useful for you but it might be for someone. Among other things >>>> Drupal takes PHPTemplate and builds on top of it for theming. What Bob >>>> is doing is not all that different. >>> >>> yeah. tbh, i wrote and tested phptemplate (and formsapi) completely >>> separately >>> from drupal before starting to integrate it. >>> >>> Some of the more recent changes in D6 might make it a bit harder to >>> separate, >>> but it should still be workable. >>> >> >> >> >> -- >> Ken Rickard >> agentrickard at gmail.com >> http://ken.therickards.com From liam at intermedia-online.com Fri Jun 13 20:36:02 2008 From: liam at intermedia-online.com (Liam McDermott) Date: Fri, 13 Jun 2008 16:36:02 -0400 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> Message-ID: <4852DA32.5060804@intermedia-online.com> Earnie Boyd wrote: > Excuse my harshness in this but why should I really care about your fork > of the Drupal theme engine to another CMS? Seems to be a bit of a misunderstanding here. :) This decoupled theme engine is useful. As an empirical example, I have to work on some old, crufty hand-crafted PHP sites and often look to api.drupal.org to see how things _should_ be done. The owners simply won't let me switch it to Drupal, for a variety of -- misguided -- reasons. So for those of us who love the Drupal API, but are unable to use the full CMS in certain circumstances, this is useful (license issues notwithstanding). This doesn't read like a fork, just a copy that will probably be repeated when the theme engine changes. Using the word 'fork' implies some sort of conflict, which is rather disingenuous. That 'other CMS' is hardly a competitor to Drupal, just a home-brew project. Remember: we can't all use Drupal all of the time, luckily the GPL allows us to mix-and-match code from a variety of sources (as long as the licenses are compatible). This is mildly off-topic for the dev list, but since a number of people who hack on Drupal are interested I believe we can put pedantry aside for a moment. Unless we should have a development-related-to-drupal-but-not-exactly-on-topic-for-the-dev-list errrr, list? Thanks for contributing this back, Bob! :) Kind Regards, Liam McDermott. From hdeelstra at gmail.com Fri Jun 13 20:51:17 2008 From: hdeelstra at gmail.com (Heine Deelstra) Date: Fri, 13 Jun 2008 22:51:17 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> <1BA4BFD7-E0DE-4005-9C0E-B338DAE55D09@bryght.com> Message-ID: On Fri, 13 Jun 2008 19:04:04 +0200, Adrian Rossouw wrote: > yeah. tbh, i wrote and tested phptemplate (and formsapi) completely > separately > from drupal before starting to integrate it. > > Some of the more recent changes in D6 might make it a bit harder to > separate, > but it should still be workable. I can report that it is indeed very workable (and bliss) to use FAPI outside Drupal. Heine From earnie at users.sourceforge.net Fri Jun 13 22:28:30 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Fri, 13 Jun 2008 18:28:30 -0400 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> Message-ID: <20080613182830.ql4ks06sk2kgwkgo@mail.progw.org> Quoting Matt Galvin : > On Fri, Jun 13, 2008 at 8:35 AM, Earnie Boyd > wrote: >> Excuse my harshness in this but why should I really care about your fork of >> the Drupal theme engine to another CMS? This list is about coding for >> Drupal and I don't see how what you have is about coding for Drupal. What >> you have posted is about using pieces of Drupal in other software which >> isn't quite what I think this list is for. > > In general (not to target you directly in any way) there is not really > an excuse for harshness in email. You have time to think and write > polite and respectful words. If you don't want to sound harsh, don't > be harsh. > Alright, then I must have meant to be somewhat harsh. > Drupal is open source. Anyone is free to use it for what they wish as > long as they share their derivative work. He is sharing his. It may > not be useful for you but it might be for someone. Among other things > Drupal takes PHPTemplate and builds on top of it for theming. What Bob > is doing is not all that different. > I've no problem with anyone using any piece of open source and making it his own. I have a problem with getting that changed source in my Inbox. Especially since that changed source was for use outside of Drupal. > While it is not about Drupal development itself, it is about using > Drupal's code base which might be relevant to any Drupal developer > even if only to say that he tried something that he thought was > possible and is making it work. You never know what may come if it (or > anything on or around Drupal). It is nice to at least hear of these > things so we are aware of them, IMHO. > That is fine, many people share many things and this list seems to be becoming an announcement list for all the work going on. However, post a link or create an issue with the files attached. Please be kind and don't post a file in email that not everyone is going to use. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From bob.pepin at gmail.com Sat Jun 14 01:53:34 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Sat, 14 Jun 2008 03:53:34 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <4852DA32.5060804@intermedia-online.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <20080613083550.bc2z7cbcp8qscoo4@mail.progw.org> <4852DA32.5060804@intermedia-online.com> Message-ID: <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> I've put a somewhat more complete version that includes an API and a theme browser up on google code. http://drupal-theme-standalone.googlecode.com/ btw, drupal isn't perfect either, just earlier I spent fifteen minutes hunting a bug just because I dared to create a variable called $theme in some toplevel code.. turned out that global was already taken by the drupal theme system, which apparently doesn't bother too much with error checking, so all I got was a blank page, no error message, no nothing.. of course PHP isn't completely innocent in this either ;) On Fri, Jun 13, 2008 at 22:36, Liam McDermott wrote: > Earnie Boyd wrote: >> >> Excuse my harshness in this but why should I really care about your fork >> of the Drupal theme engine to another CMS? > > Seems to be a bit of a misunderstanding here. :) > > This decoupled theme engine is useful. As an empirical example, I have to > work on some old, crufty hand-crafted PHP sites and often look to > api.drupal.org to see how things _should_ be done. The owners simply won't > let me switch it to Drupal, for a variety of -- misguided -- reasons. > > So for those of us who love the Drupal API, but are unable to use the full > CMS in certain circumstances, this is useful (license issues > notwithstanding). > > This doesn't read like a fork, just a copy that will probably be repeated > when the theme engine changes. Using the word 'fork' implies some sort of > conflict, which is rather disingenuous. > > That 'other CMS' is hardly a competitor to Drupal, just a home-brew project. > Remember: we can't all use Drupal all of the time, luckily the GPL allows us > to mix-and-match code from a variety of sources (as long as the licenses are > compatible). > > This is mildly off-topic for the dev list, but since a number of people who > hack on Drupal are interested I believe we can put pedantry aside for a > moment. Unless we should have a > development-related-to-drupal-but-not-exactly-on-topic-for-the-dev-list > errrr, list? > > Thanks for contributing this back, Bob! :) > > Kind Regards, > Liam McDermott. > From larry at garfieldtech.com Sat Jun 14 05:14:39 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Sat, 14 Jun 2008 00:14:39 -0500 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> Message-ID: <200806140014.39470.larry@garfieldtech.com> On Friday 13 June 2008, Bob Pepin wrote: > I've put a somewhat more complete version that includes an API and a > theme browser up on google code. > > http://drupal-theme-standalone.googlecode.com/ > > btw, drupal isn't perfect either, just earlier I spent fifteen minutes > hunting a bug just because I dared to create a variable called $theme > in some toplevel code.. turned out that global was already taken by > the drupal theme system, which apparently doesn't bother too much with > error checking, so all I got was a blank page, no error message, no > nothing.. of course PHP isn't completely innocent in this either ;) Creating a global variable in the first place was your first mistake. They are a design flaw by definition for exactly the reason you describe. Creating one that was not namespaced to your module was mistake #2, for the reasons you describe. :-) You cannot really error check globals in that way, which is part of the problem with them. Friends don't let friends use globals. :-) -- Larry Garfield AIM: LOLG42 larry at garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From bob.pepin at gmail.com Sat Jun 14 12:24:06 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Sat, 14 Jun 2008 14:24:06 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <200806140014.39470.larry@garfieldtech.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> Message-ID: <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> On Sat, Jun 14, 2008 at 07:14, Larry Garfield wrote: > On Friday 13 June 2008, Bob Pepin wrote: >> btw, drupal isn't perfect either, just earlier I spent fifteen minutes >> hunting a bug just because I dared to create a variable called $theme >> in some toplevel code.. turned out that global was already taken by >> the drupal theme system, which apparently doesn't bother too much with >> error checking, so all I got was a blank page, no error message, no >> nothing.. of course PHP isn't completely innocent in this either ;) > > Creating a global variable in the first place was your first mistake. They > are a design flaw by definition for exactly the reason you describe. > Creating one that was not namespaced to your module was mistake #2, for the > reasons you describe. :-) Well, since PHP does have neither namespaces nor modules (okay, you can use classes as some kind of poor man's namespaces if you don't mind writing ClassName::function() all the time), mistake #2 was unavoidable ;) My point though was that $theme is not exactly the ideal name for a global variable used inside a library. But since the library I'm talking about was previously simply a little module living in its little closed drupal world, I can understand why it turned out the way it did. > You cannot really error check globals in that way, which is part of the > problem with them. Well in this case $theme was an instance of one of my own classes, whereas the library was treating it as a string. Something that in most languages would've either been detected at compile time or would have signaled an error at runtime instantly. And for error checking globals in general, simply requiring variables to be declared before use and signaling an error when a variable with the same name already exists can prevent those conflicts (this would work similar to how PHP prevents you from accidentally redefining a function). And then of course being able to create properly lexically scoped variables (like the "let" keyword that exists in various languages for example) would avoid the problem altogether. Okay, enough off topic for today, have a nice weekend ;) Bob From eric.schaefer at eas-consulting.de Sat Jun 14 12:56:58 2008 From: eric.schaefer at eas-consulting.de (Eric-Alexander Schaefer) Date: Sat, 14 Jun 2008 14:56:58 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> Message-ID: <4853C01A.6090001@eas-consulting.de> Bob Pepin schrieb: > Well, since PHP does have neither namespaces nor modules (okay, you > can use classes as some kind of poor man's namespaces if you don't > mind writing ClassName::function() all the time), mistake #2 was > unavoidable ;) Every programming language that allows you to name your functions and variables arbitrarily supports namespaces. $YOUR_NAMESPACE_your_valiable YOUR_NAMESPACE_your_function() _YOUR_NAMESPACE_your_private_function() HTH, Eric From victorkane at gmail.com Sat Jun 14 13:07:47 2008 From: victorkane at gmail.com (Victor Kane) Date: Sat, 14 Jun 2008 10:07:47 -0300 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: <4853C01A.6090001@eas-consulting.de> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> Message-ID: That's not strictly 100% accurate, since with real namespaces, the scope would be restricted; although for the purposes here, your suggestion would be practical. Victor Kane http://awebfactory.com.ar On Sat, Jun 14, 2008 at 9:56 AM, Eric-Alexander Schaefer < eric.schaefer at eas-consulting.de> wrote: > Bob Pepin schrieb: > >> Well, since PHP does have neither namespaces nor modules (okay, you >> can use classes as some kind of poor man's namespaces if you don't >> mind writing ClassName::function() all the time), mistake #2 was >> unavoidable ;) >> > > Every programming language that allows you to name your functions and > variables arbitrarily supports namespaces. > > $YOUR_NAMESPACE_your_valiable > YOUR_NAMESPACE_your_function() > _YOUR_NAMESPACE_your_private_function() > > HTH, > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080614/8c836826/attachment.htm From bob.pepin at gmail.com Sat Jun 14 13:42:51 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Sat, 14 Jun 2008 15:42:51 +0200 Subject: [development] Drupal 6.2 theme system standalone In-Reply-To: References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> Message-ID: <3480f31c0806140642m6259659ewc86057649b5a5cbb@mail.gmail.com> Well, since the original reason for using the variable here was being able to shorten down DrupalThemeStandalone::init() to $theme->init() in a 10-line test script, making that $DrupalThemeStandalone_TestScript_theme->init() would kind of defeat the purpose. But you are right of course that global variables used in libraries should always have some sort of LIBRARY_NAME prefix. But then again I could also have avoided the problem by simply putting all of my code inside a main() function, instead of naively expecting an innocent looking 5-letter variable name like $theme not to be used already by some functions somewhere as a global variable to keep their state. On Sat, Jun 14, 2008 at 15:07, Victor Kane wrote: > That's not strictly 100% accurate, since with real namespaces, the scope > would be restricted; although for the purposes here, your suggestion would > be practical. > > Victor Kane > http://awebfactory.com.ar > > On Sat, Jun 14, 2008 at 9:56 AM, Eric-Alexander Schaefer > wrote: >> >> Bob Pepin schrieb: >>> >>> Well, since PHP does have neither namespaces nor modules (okay, you >>> can use classes as some kind of poor man's namespaces if you don't >>> mind writing ClassName::function() all the time), mistake #2 was >>> unavoidable ;) >> >> Every programming language that allows you to name your functions and >> variables arbitrarily supports namespaces. >> >> $YOUR_NAMESPACE_your_valiable >> YOUR_NAMESPACE_your_function() >> _YOUR_NAMESPACE_your_private_function() >> >> HTH, >> Eric > > From earnie at users.sourceforge.net Sat Jun 14 14:41:37 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 14 Jun 2008 10:41:37 -0400 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <4853C01A.6090001@eas-consulting.de> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> Message-ID: <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> Quoting Eric-Alexander Schaefer : > Bob Pepin schrieb: >> Well, since PHP does have neither namespaces nor modules (okay, you >> can use classes as some kind of poor man's namespaces if you don't >> mind writing ClassName::function() all the time), mistake #2 was >> unavoidable ;) > > Every programming language that allows you to name your functions and > variables arbitrarily supports namespaces. > > $YOUR_NAMESPACE_your_valiable > YOUR_NAMESPACE_your_function() > _YOUR_NAMESPACE_your_private_function() > Why should Bob do that when Drupal doesn't? We need to take a stab at using a $drupal static array that is controlled by a drupal_register function. If only one argument is passed then drupal_register will return the value of the requested variable from the $drupal static array. Else all other arguments are stored as a value of the variable and that stored value is then returned. Note that the first argument is always the associative index value for the $drupal array. If only two arguments are passed then the stored value should only be the value of the second argument. If more than two arguments then the argument array is stored after the index value is shifted off of the array. I'm working up a patch for this. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From adrian at bryght.com Sat Jun 14 14:47:43 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Sat, 14 Jun 2008 16:47:43 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> Message-ID: <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> On 14 Jun 2008, at 4:41 PM, Earnie Boyd wrote: > > Why should Bob do that when Drupal doesn't? We need to take a stab > at using a $drupal static array that is controlled by a > drupal_register function. If only one argument is passed then > drupal_register will return the value of the requested variable from > the $drupal static array. Else all other arguments are stored as a > value of the variable and that stored value is then returned. Note > that the first argument is always the associative index value for > the $drupal array. If only two arguments are passed then the stored > value should only be the value of the second argument. If more than > two arguments then the argument array is stored after the index > value is shifted off of the array. I'm working up a patch for this. drupal_get_context and drupal_set_context there's been patches before, and there's patches in the queue still Dries didn't like the idea when i floated it 5 years ago, but maybe it's time =) From syscrusher at 4th.com Sat Jun 14 15:00:30 2008 From: syscrusher at 4th.com (Syscrusher) Date: Sat, 14 Jun 2008 11:00:30 -0400 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> Message-ID: <1213455630.26741.6.camel@marcus> On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: > Dries didn't like the idea when i floated it 5 years ago, but maybe > it's time =) If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago? I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes. Kind regards, Scott -- Syscrusher From news at unleashedmind.com Sat Jun 14 15:02:56 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Sat, 14 Jun 2008 17:02:56 +0200 Subject: [development] namespaced global variables [WAS: Drupal6.2 theme system standalone] In-Reply-To: <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> Message-ID: <061201c8ce2f$ba736a90$0200a8c0@structworks.com> > drupal_get_context and drupal_set_context > > there's been patches before, and there's patches in the queue still New patches should not use the term 'context'. Panels 2 (& Views?) already occupy that namespace with a concept that will hopefully be adopted by more contrib modules and perhaps core. sun From bob.pepin at gmail.com Sat Jun 14 15:03:15 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Sat, 14 Jun 2008 17:03:15 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <1213455630.26741.6.camel@marcus> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: <3480f31c0806140803n2f5cc822haf42bec480159f2d@mail.gmail.com> On a side note, the next person designing a callback interface should also keep in mind that call_user_func can take array($classname, $methodname) as first argument. Would have avoided all the name clashes with callbacks in themes right now. On Sat, Jun 14, 2008 at 17:00, Syscrusher wrote: > On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: >> Dries didn't like the idea when i floated it 5 years ago, but maybe >> it's time =) > > If we're talking about that kind of a major change, is it time to > revisit the question of whether Drupal should use PHP's OOP features, > now that the PHP language has better OO support than it did several > years ago? > > I realize this has been discussed before, and I'm not trying to open a > flame war here. If the answer is "Hell no!", then I will not start a > fight about it. I just thought we might be trying with things like > home-grown contexts to reinvent a wheel that's already solved by > classes. > > Kind regards, > > Scott > > -- > Syscrusher > > From fgm at osinet.fr Sat Jun 14 15:07:29 2008 From: fgm at osinet.fr (FGM) Date: Sat, 14 Jun 2008 17:07:29 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2theme system standalone] References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com><4852DA32.5060804@intermedia-online.com><3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com><200806140014.39470.larry@garfieldtech.com><3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com><4853C01A.6090001@eas-consulting.de><20080614104137.uj05x87jvrc0gw4c@mail.progw.org><83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: <016601c8ce30$5d6ac6d0$2401a8c0@pcosi> We could even go futher and require PHP5.3. That way namespaces would be available. ----- Original Message ----- From: "Syscrusher" To: Sent: Saturday, June 14, 2008 5:00 PM Subject: Re: [development] namespaced global variables [WAS: Drupal 6.2theme system standalone] On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: > Dries didn't like the idea when i floated it 5 years ago, but maybe > it's time =) If we're talking about that kind of a major change, is it time to revisit the question of whether Drupal should use PHP's OOP features, now that the PHP language has better OO support than it did several years ago? I realize this has been discussed before, and I'm not trying to open a flame war here. If the answer is "Hell no!", then I will not start a fight about it. I just thought we might be trying with things like home-grown contexts to reinvent a wheel that's already solved by classes. Kind regards, Scott -- Syscrusher From victorkane at gmail.com Sat Jun 14 15:13:23 2008 From: victorkane at gmail.com (Victor Kane) Date: Sat, 14 Jun 2008 12:13:23 -0300 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <1213455630.26741.6.camel@marcus> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: This is the question, globals should be shied away from altogether. On Sat, Jun 14, 2008 at 12:00 PM, Syscrusher wrote: > On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: > > Dries didn't like the idea when i floated it 5 years ago, but maybe > > it's time =) > > If we're talking about that kind of a major change, is it time to > revisit the question of whether Drupal should use PHP's OOP features, > now that the PHP language has better OO support than it did several > years ago? > > I realize this has been discussed before, and I'm not trying to open a > flame war here. If the answer is "Hell no!", then I will not start a > fight about it. I just thought we might be trying with things like > home-grown contexts to reinvent a wheel that's already solved by > classes. > > Kind regards, > > Scott > > -- > Syscrusher > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080614/410309cf/attachment.htm From adrian at bryght.com Sat Jun 14 15:09:45 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Sat, 14 Jun 2008 17:09:45 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <1213455630.26741.6.camel@marcus> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: On 14 Jun 2008, at 5:00 PM, Syscrusher wrote: > > If we're talking about that kind of a major change, is it time to > revisit the question of whether Drupal should use PHP's OOP features, > now that the PHP language has better OO support than it did several > years ago? how is that a major change ? we simply find all occurences of global and $GLOBALS, and replace it with context_get. we will also be able to track whenever global variables change because you need to use context_set to use them, so it's impossible to fsck up your site by accidentally wiping out globals. From adrian at bryght.com Sat Jun 14 15:12:38 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Sat, 14 Jun 2008 17:12:38 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <3480f31c0806140803n2f5cc822haf42bec480159f2d@mail.gmail.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> <3480f31c0806140803n2f5cc822haf42bec480159f2d@mail.gmail.com> Message-ID: <160CD0B4-1D10-4D6A-8ACE-570F632658D0@bryght.com> On 14 Jun 2008, at 5:03 PM, Bob Pepin wrote: > On a side note, the next person designing a callback interface should > also keep in mind that call_user_func can take array($classname, > $methodname) as first argument. Would have avoided all the name > clashes with callbacks in themes right now. except when you use that format you can't pass references to functions, as it makes copies of everything chx wrote a simple call_user_func array replacement that passes references a few years ago. basically : function call($func, &$var1, &$var2, &$var3, &$var4, &$var5, & $var6 ... etc) { if (function_exists($func) { return $func($func, &$var1, &$var2, &$var3, &$var4, &$var5, & $var6 ... etc); } } From adrian at bryght.com Sat Jun 14 15:13:50 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Sat, 14 Jun 2008 17:13:50 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <1213455630.26741.6.camel@marcus> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: On 14 Jun 2008, at 5:00 PM, Syscrusher wrote: > > I realize this has been discussed before, and I'm not trying to open a > flame war here. If the answer is "Hell no!", then I will not start a > fight about it. I just thought we might be trying with things like > home-grown contexts to reinvent a wheel that's already solved by > classes. > Classes do not give us any benefits here over a simple , easy to debug, easy to understand function which works exactly like variable_get and variable_set. Query builders, data api, forms api.. these are things where objects would be beneficial. not something as simple as this. From victorkane at gmail.com Sat Jun 14 15:21:45 2008 From: victorkane at gmail.com (Victor Kane) Date: Sat, 14 Jun 2008 12:21:45 -0300 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: Don't want to start a whole discussion again on this, but the adoption of OO paradigm eliminates the need for most globals in the first place. That's the advantage, along with a lot of others... Victor Kane http://awebfactory.com.ar On Sat, Jun 14, 2008 at 12:09 PM, Adrian Rossouw wrote: > > On 14 Jun 2008, at 5:00 PM, Syscrusher wrote: > > >> If we're talking about that kind of a major change, is it time to >> revisit the question of whether Drupal should use PHP's OOP features, >> now that the PHP language has better OO support than it did several >> years ago? >> > how is that a major change ? > > we simply find all occurences of global and $GLOBALS, and replace it with > context_get. > > we will also be able to track whenever global variables change because you > need to use context_set to use them, > so it's impossible to fsck up your site by accidentally wiping out globals. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080614/585e412d/attachment.htm From bob.pepin at gmail.com Sat Jun 14 15:27:28 2008 From: bob.pepin at gmail.com (Bob Pepin) Date: Sat, 14 Jun 2008 17:27:28 +0200 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <160CD0B4-1D10-4D6A-8ACE-570F632658D0@bryght.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> <3480f31c0806140803n2f5cc822haf42bec480159f2d@mail.gmail.com> <160CD0B4-1D10-4D6A-8ACE-570F632658D0@bryght.com> Message-ID: <3480f31c0806140827j7dbe63beu106b700fcdbee7c1@mail.gmail.com> the same array($classname, $methodname) format is supported by call_user_func_array, and according to the doc at php.net Note: Referenced variables in param_arr are passed to the function by a reference, others are passed by a value. In other words, it does not depend on the function signature whether the parameter is passed by a value or by a reference. No idea though if it's always been that way or if it's changed recently or if maybe it goes back to passing by value if we're calling an object method. On Sat, Jun 14, 2008 at 17:12, Adrian Rossouw wrote: > > On 14 Jun 2008, at 5:03 PM, Bob Pepin wrote: > >> On a side note, the next person designing a callback interface should >> also keep in mind that call_user_func can take array($classname, >> $methodname) as first argument. Would have avoided all the name >> clashes with callbacks in themes right now. > > except when you use that format you can't pass references to functions, as > it makes copies of everything > > chx wrote a simple call_user_func array replacement that passes references a > few years ago. > > basically : > > function call($func, &$var1, &$var2, &$var3, &$var4, &$var5, &$var6 ... etc) > { > if (function_exists($func) { > return $func($func, &$var1, &$var2, &$var3, &$var4, &$var5, > &$var6 ... etc); > } > } > From earnie at users.sourceforge.net Sat Jun 14 16:31:06 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 14 Jun 2008 12:31:06 -0400 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <1213455630.26741.6.camel@marcus> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> <1213455630.26741.6.camel@marcus> Message-ID: <20080614123106.2pd1mu3j9gggococ@mail.progw.org> Quoting Syscrusher : > On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: >> Dries didn't like the idea when i floated it 5 years ago, but maybe >> it's time =) > > If we're talking about that kind of a major change, is it time to > revisit the question of whether Drupal should use PHP's OOP features, > now that the PHP language has better OO support than it did several > years ago? > My opinion is that no and yes. Some modules would benefit from the use of OO while the Drupal core functionality should remain procedural. > I realize this has been discussed before, and I'm not trying to open a > flame war here. If the answer is "Hell no!", then I will not start a > fight about it. I just thought we might be trying with things like > home-grown contexts to reinvent a wheel that's already solved by > classes. > Put your flames to http://drupal.org/node/270538 if you wish. I'm working on a feature that we can use to namespace all variables. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From earnie at users.sourceforge.net Sat Jun 14 16:34:19 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 14 Jun 2008 12:34:19 -0400 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <4852DA32.5060804@intermedia-online.com> <3480f31c0806131853k1adb8013w8bab1d921889311a@mail.gmail.com> <200806140014.39470.larry@garfieldtech.com> <3480f31c0806140524j26903c7eh8d16185806e23b3e@mail.gmail.com> <4853C01A.6090001@eas-consulting.de> <20080614104137.uj05x87jvrc0gw4c@mail.progw.org> <83F565CA-8DBB-4A9C-8B2D-A126ABD69F42@bryght.com> Message-ID: <20080614123419.nwmcrhb4xackscc4@mail.progw.org> Quoting Adrian Rossouw : > > On 14 Jun 2008, at 4:41 PM, Earnie Boyd wrote: > >> >> Why should Bob do that when Drupal doesn't? We need to take a stab >> at using a $drupal static array that is controlled by a >> drupal_register function. If only one argument is passed then >> drupal_register will return the value of the requested variable from >> the $drupal static array. Else all other arguments are stored as a >> value of the variable and that stored value is then returned. Note >> that the first argument is always the associative index value for >> the $drupal array. If only two arguments are passed then the stored >> value should only be the value of the second argument. If more >> than two arguments then the argument array is stored after the >> index value is shifted off of the array. I'm working up a patch >> for this. > > drupal_get_context and drupal_set_context > > there's been patches before, and there's patches in the queue still > > Dries didn't like the idea when i floated it 5 years ago, but maybe > it's time =) > > And there will be another patch at http://drupal.org/node/270538 once I upload the patch. I have most of it coded already, just need to do some testing but don't have time to set that up yet. Wife is having health issues and I'm having development delays because of that. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From earnie at users.sourceforge.net Sat Jun 14 16:40:14 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 14 Jun 2008 12:40:14 -0400 Subject: [development] namespaced global variables [WAS: Drupal6.2 theme system standalone] In-Reply-To: <061201c8ce2f$ba736a90$0200a8c0@structworks.com> References: <061201c8ce2f$ba736a90$0200a8c0@structworks.com> Message-ID: <20080614124014.lb7f8k31dhs8ko4o@mail.progw.org> Quoting "Daniel F. Kudwien" : >> drupal_get_context and drupal_set_context >> >> there's been patches before, and there's patches in the queue still > > New patches should not use the term 'context'. Panels 2 (& Views?) already > occupy that namespace with a concept that will hopefully be adopted by more > contrib modules and perhaps core. > The names of the functions can be discussed in http://drupal.org/node/270538 so that we can come to a good agreement and track it their. I have a patch coded but it is not yet tested. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From larry at garfieldtech.com Sat Jun 14 16:42:55 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Sat, 14 Jun 2008 11:42:55 -0500 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <3480f31c0806140803n2f5cc822haf42bec480159f2d@mail.gmail.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <1213455630.26741.6.camel@marcus> <3480f31c0806140803n2f5cc822haf42bec480159f2d@mail.gmail.com> Message-ID: <200806141142.55181.larry@garfieldtech.com> Classes make really lousy namespaces. That is semantically a wrong use of classes, and also hurts the new Drupal 7 registry. Classes should be used for tight-coupling bundles of code and data. They are not a poor man's namespace. On Saturday 14 June 2008, Bob Pepin wrote: > On a side note, the next person designing a callback interface should > also keep in mind that call_user_func can take array($classname, > $methodname) as first argument. Would have avoided all the name > clashes with callbacks in themes right now. > > On Sat, Jun 14, 2008 at 17:00, Syscrusher wrote: > > On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: > >> Dries didn't like the idea when i floated it 5 years ago, but maybe > >> it's time =) > > > > If we're talking about that kind of a major change, is it time to > > revisit the question of whether Drupal should use PHP's OOP features, > > now that the PHP language has better OO support than it did several > > years ago? > > > > I realize this has been discussed before, and I'm not trying to open a > > flame war here. If the answer is "Hell no!", then I will not start a > > fight about it. I just thought we might be trying with things like > > home-grown contexts to reinvent a wheel that's already solved by > > classes. > > > > Kind regards, > > > > Scott > > > > -- > > Syscrusher -- Larry Garfield AIM: LOLG42 larry at garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From larry at garfieldtech.com Sat Jun 14 16:46:32 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Sat, 14 Jun 2008 11:46:32 -0500 Subject: [development] =?iso-8859-1?q?namespaced_global_variables_=5BWAS?= =?iso-8859-1?q?=3A_Drupal_6=2E2=09theme_system_standalone=5D?= In-Reply-To: <20080614123106.2pd1mu3j9gggococ@mail.progw.org> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <1213455630.26741.6.camel@marcus> <20080614123106.2pd1mu3j9gggococ@mail.progw.org> Message-ID: <200806141146.32959.larry@garfieldtech.com> On Saturday 14 June 2008, Earnie Boyd wrote: > Quoting Syscrusher : > > On Sat, 2008-06-14 at 16:47 +0200, Adrian Rossouw wrote: > >> Dries didn't like the idea when i floated it 5 years ago, but maybe > >> it's time =) > > > > If we're talking about that kind of a major change, is it time to > > revisit the question of whether Drupal should use PHP's OOP features, > > now that the PHP language has better OO support than it did several > > years ago? > > My opinion is that no and yes. Some modules would benefit from the use > of OO while the Drupal core functionality should remain procedural. Drupal core should use procedural where it makes sense to do so, and OO where it makes sense to do so. Contrib should use procedural where it makes sense to do so, and OO where it makes sense to do so. PHP code should use procedural where it makes sense to do so, and OO where it makes sense to do so. Religious adherence or distaste for one mechanism or the other is simply naive and damaging to the architecture of the project (any project, not just Drupal). -- Larry Garfield AIM: LOLG42 larry at garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From earnie at users.sourceforge.net Sat Jun 14 16:50:06 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sat, 14 Jun 2008 12:50:06 -0400 Subject: [development] namespaced global variables [WAS: Drupal 6.2 theme system standalone] In-Reply-To: <200806141146.32959.larry@garfieldtech.com> References: <3480f31c0806121659y4519edaehe20d969203ceaaa3@mail.gmail.com> <1213455630.26741.6.camel@marcus> <20080614123106.2pd1mu3j9gggococ@mail.progw.org> <200806141146.32959.larry@garfieldtech.com> Message-ID: <20080614125006.i8k4boo77dr4cok0@mail.progw.org> Quoting Larry Garfield : > > Religious adherence or distaste for one mechanism or the other is > simply naive > and damaging to the architecture of the project (any project, not just > Drupal). > No "yes or no" argument from me, I totally agree. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From larry at garfieldtech.com Tue Jun 17 05:16:56 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 17 Jun 2008 00:16:56 -0500 Subject: [development] RFC: Drupal pluggable systems Message-ID: <200806170016.57149.larry@garfieldtech.com> Recently I've been talking up various ideas for pluggable subsystems in Drupal in IRC and the other usual haunts. Ideas have been percolating in my head, but so far I have been remiss in actually writing them down. Yesterday, however, I had an epiphany to solve the primary issue I was trying to work out, so I present a hopefully workable RFC (for real, not IETF version) for pluggable subsystems in Drupal. For the full write-up, please see: http://www.garfieldtech.com/blog/drupal-handler-rfc In the interests of simplicity, *please* don't reply on the list. Reply on the post above. Thanks. -- Larry Garfield AIM: LOLG42 larry at garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson From adrian at bryght.com Tue Jun 17 12:41:11 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Tue, 17 Jun 2008 14:41:11 +0200 Subject: [development] RFC: Drupal pluggable systems In-Reply-To: <200806170016.57149.larry@garfieldtech.com> References: <200806170016.57149.larry@garfieldtech.com> Message-ID: <95A63FE5-9B4A-475A-A8BB-0341807632E6@bryght.com> On 17 Jun 2008, at 7:16 AM, Larry Garfield wrote: > Recently I've been talking up various ideas for pluggable subsystems > in Drupal > in IRC and the other usual haunts. Ideas have been percolating in my > head, > but so far I have been remiss in actually writing them down. > Yesterday, > however, I had an epiphany to solve the primary issue I was trying > to work > out, so I present a hopefully workable RFC (for real, not IETF > version) for > pluggable subsystems in Drupal. I've always thought drupal needs the concept of libraries too. ie: code that is just used when requested, no need to be enabled or anything. My all time favorite thing in that post is putting a bunch of initialization data in an sqlite database, tho you have to be very careful about what sql queries you write then, as you won't be able to join between db engines. From larry at garfieldtech.com Tue Jun 17 15:17:26 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Tue, 17 Jun 2008 10:17:26 -0500 Subject: [development] RFC: Drupal pluggable systems In-Reply-To: <95A63FE5-9B4A-475A-A8BB-0341807632E6@bryght.com> References: <95A63FE5-9B4A-475A-A8BB-0341807632E6@bryght.com> Message-ID: On Tue, 17 Jun 2008 14:41:11 +0200, Adrian Rossouw wrote: > > On 17 Jun 2008, at 7:16 AM, Larry Garfield wrote: > >> Recently I've been talking up various ideas for pluggable subsystems >> in Drupal >> in IRC and the other usual haunts. Ideas have been percolating in my >> head, >> but so far I have been remiss in actually writing them down. >> Yesterday, >> however, I had an epiphany to solve the primary issue I was trying >> to work >> out, so I present a hopefully workable RFC (for real, not IETF >> version) for >> pluggable subsystems in Drupal. > > I've always thought drupal needs the concept of libraries too. > > ie: code that is just used when requested, no need to be enabled or > anything. > > My all time favorite thing in that post is putting a bunch of > initialization data in an sqlite database, > tho you have to be very careful about what sql queries you write then, > as you won't be able to join > between db engines. The idea is it would be a clone; you'd write to the system and registry tables in the "default" target, then call db_replicate_table('default', 'config', 'system') (or something) and Drupal will clone the system table from the default target to the config target. Then you run SELECT queries against the config target. If you need to do fancier stuff, use the default target. Using targets does require knowledge of how each target is designed to work. And please keep replies on the blog to avoid splitting the conversation. :-) --Larry Garfield From sysop at scbbs.com Tue Jun 17 17:49:06 2008 From: sysop at scbbs.com (Ron Parker) Date: Tue, 17 Jun 2008 10:49:06 -0700 Subject: [development] Help with hook_search Message-ID: <4857F912.7010005@scbbs.com> I just submitted an issue here: http://drupal.org/node/271604. The Drupal 5.x and 6.x hook_search documentation is incorrect. I just want to add another tab to the search form that, for right now, just does another regular search. Not specialized in any way (at least right now). Just a normal search, but the api documentation is incorrect and I can't find any examples anywhere of how to do this. Can someone point me in the right direction, or show me the hook_search api code that *does* work? Thanks! -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com From fgm at osinet.fr Tue Jun 17 18:44:14 2008 From: fgm at osinet.fr (=?iso-8859-1?Q?Fr=E9d=E9ric_G._MARAND?=) Date: Tue, 17 Jun 2008 20:44:14 +0200 Subject: [development] Help with hook_search In-Reply-To: <4857F912.7010005@scbbs.com> References: <4857F912.7010005@scbbs.com> Message-ID: Could you describe why you think the documentation is incorrect ? I've used it to create other searches without specific problems. How was core not compliant with the documentation in your case ? Also, could you please open this as an issue against Drupal/search or Documentation/In CVS so the issue and its eventual resolution remain more widely available in the future ? Others might meet the same problem as you. Frederic G. MARAND OSInet ----- Original Message ----- From: "Ron Parker" To: Sent: Tuesday, June 17, 2008 7:49 PM Subject: [development] Help with hook_search I just submitted an issue here: http://drupal.org/node/271604. The Drupal 5.x and 6.x hook_search documentation is incorrect. I just want to add another tab to the search form that, for right now, just does another regular search. Not specialized in any way (at least right now). Just a normal search, but the api documentation is incorrect and I can't find any examples anywhere of how to do this. Can someone point me in the right direction, or show me the hook_search api code that *does* work? Thanks! -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.3.0/1505 - Release Date: 16/06/2008 07:20 From sysop at scbbs.com Tue Jun 17 19:04:53 2008 From: sysop at scbbs.com (Ron Parker) Date: Tue, 17 Jun 2008 12:04:53 -0700 Subject: [development] Help with hook_search In-Reply-To: References: <4857F912.7010005@scbbs.com> Message-ID: <48580AD5.9030209@scbbs.com> I'm not saying that hook_search does not work. I'm saying that the api documentation for hook_search, what I tried to use in order to learn how to use hook_search, is incorrect. I have documented what I found here: http://drupal.org/node/271392 * node_access_join_sql() and node_access_where_sql() no longer exist * AND not necessary in $join sql statement * check_outputdeprecated since Drupal 4.7. And, the code, even when fixed, doesn't work. At least, I've not been able to get it to work. Hopefully I'm wrong, but it seems like an incredible oversight and I can't believe no one else has discovered it until now. Opened Drupal Documentation issue here: http://drupal.org/node/271604 Thanks. -ron Fr?d?ric G. MARAND wrote: > Could you describe why you think the documentation is incorrect ? I've > used it to create other searches without specific problems. How was > core not compliant with the documentation in your case ? > > Also, could you please open this as an issue against Drupal/search or > Documentation/In CVS so the issue and its eventual resolution remain > more widely available in the future ? Others might meet the same > problem as you. > > Frederic G. MARAND > OSInet > > ----- Original Message ----- From: "Ron Parker" > To: > Sent: Tuesday, June 17, 2008 7:49 PM > Subject: [development] Help with hook_search > > > > I just submitted an issue here: http://drupal.org/node/271604. The > Drupal 5.x and 6.x hook_search documentation is incorrect. > > I just want to add another tab to the search form that, for right now, > just does another regular search. Not specialized in any way (at least > right now). Just a normal search, but the api documentation is > incorrect and I can't find any examples anywhere of how to do this. > > Can someone point me in the right direction, or show me the hook_search > api code that *does* work? > > Thanks! > > -ron > > -- > Ron Parker > Software Creations http://www.scbbs.com > Self-Administration Web Site http://saw.scbbs.com > SDSS Subscription Mgmt Service http://sdss.scbbs.com > Central Ave Dance Ensemble http://www.centralavedance.com > R & B Salsa http://www.randbsalsa.com > > > > -------------------------------------------------------------------------------- > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 8.0.100 / Virus Database: 270.3.0/1505 - Release Date: > 16/06/2008 07:20 > > > __________ NOD32 3194 (20080617) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080617/beeb1011/attachment-0001.htm From juan.fco.rodriguez at gmail.com Wed Jun 18 15:20:35 2008 From: juan.fco.rodriguez at gmail.com (Juan Rodriguez) Date: Wed, 18 Jun 2008 17:20:35 +0200 Subject: [development] Is it possible to serialize the output of a custom block and unserialize the value in a page.tpl.php ? Message-ID: <96b30c400806180820h27c7d857g29ec046d5b8ab98b@mail.gmail.com> Hello, I am trying to serialize the output of a block, which is received in a page.tpl with the $content variable. It seems it does not work, but I don't know why, because I can output the serialized string (using $content) in a page.tpl.php file but if I try to unserialize it and afterwards try to print_r the result, it shows nothing. Does anybody have any clue? It seems quite weird to me... From adrian at bryght.com Wed Jun 18 15:25:20 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Wed, 18 Jun 2008 17:25:20 +0200 Subject: [development] Is it possible to serialize the output of a custom block and unserialize the value in a page.tpl.php ? In-Reply-To: <96b30c400806180820h27c7d857g29ec046d5b8ab98b@mail.gmail.com> References: <96b30c400806180820h27c7d857g29ec046d5b8ab98b@mail.gmail.com> Message-ID: <4D9BEDF9-8B8C-4B8F-9349-0EC4B018ADBA@bryght.com> On 18 Jun 2008, at 5:20 PM, Juan Rodriguez wrote: > > Does anybody have any clue? It seems quite weird to me... might be better and more consistent to use a static embedded in a function. ie: function myblock($variables = null) { static $vars = null; if (is_array($variables)) { $vars = $variables; } return $variables; } and just use the myblock($vars) in the right preprocess or _variables, and use myblock() when you want to get the content. From zblace at gmail.com Wed Jun 18 18:15:36 2008 From: zblace at gmail.com (zeljko blace) Date: Wed, 18 Jun 2008 20:15:36 +0200 Subject: [development] is anyone picking up DOC module? Message-ID: Hi ! I was looking for a Document management module and found that there was an offer to pick up development for 6.x version of Drupal http://drupal.org/node/254256 but it seems that author never responded. Anyone else developing/maintaining alternative module for Drupla 6.x ? Best wishes, Z From Greg at GrowingVentureSolutions.com Wed Jun 18 19:56:45 2008 From: Greg at GrowingVentureSolutions.com (Greg Knaddison - GVS) Date: Wed, 18 Jun 2008 13:56:45 -0600 Subject: [development] is anyone picking up DOC module? In-Reply-To: References: Message-ID: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> On Wed, Jun 18, 2008 at 12:15 PM, zeljko blace wrote: > I was looking for a Document management module > and found that there was an offer to pick up development > for 6.x version of Drupal > http://drupal.org/node/254256 > but it seems that author never responded. > > Anyone else developing/maintaining alternative module > for Drupla 6.x ? Sounds like a perfect opportunity for them (or you) to follow the Abandoned Project takeover process: http://drupal.org/node/251466 Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg From zblace at gmail.com Wed Jun 18 20:30:22 2008 From: zblace at gmail.com (zeljko blace) Date: Wed, 18 Jun 2008 22:30:22 +0200 Subject: [development] is anyone picking up DOC module? In-Reply-To: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> References: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> Message-ID: On Wed, Jun 18, 2008 at 9:56 PM, Greg Knaddison - GVS wrote: > On Wed, Jun 18, 2008 at 12:15 PM, zeljko blace wrote: >> I was looking for a Document management module >> and found that there was an offer to pick up development >> for 6.x version of Drupal >> http://drupal.org/node/254256 >> but it seems that author never responded. >> >> Anyone else developing/maintaining alternative module >> for Drupla 6.x ? > > Sounds like a perfect opportunity for them (or you) to follow the > Abandoned Project takeover process: http://drupal.org/node/251466 unfortunately I am no programmer - just a designer/deployer of Drupal sites From haralevi at inf.fu-berlin.de Wed Jun 18 20:29:00 2008 From: haralevi at inf.fu-berlin.de (Andre Harale) Date: Wed, 18 Jun 2008 22:29:00 +0200 Subject: [development] Security Assurance in FOSS: Request for contribution Message-ID: <20080618203714.4CFBF3CF81@fraxinus.osuosl.org> Dear members of the Drupal project, we kindly ask for your participation in our survey on security assurance in free/open source software. Security assurances are confidence building activities through structured design processes, documentation, and testing. By participating in our survey you contribute to ongoing research with the aim to make free/open source software more secure. It will not take more than 10 minutes of your valuable time for our 21 questions. Our survey is online for the next two weeks until July 1 at: http://survey.mi.fu-berlin.de/public/survey.php?name=fosssecurity Please find the results of the survey on the project page during July: https://www.inf.fu-berlin.de/w/SE/FOSSSecuritySurvey For further information about Open Source research at the Research Group Software Engineering at Freie Universitaet Berlin, please visit: https://www.inf.fu-berlin.de/w/SE/FOSSHome Thank you in anticipation, Sascha Rasmussen, Alexander Kunze, and Andre Haralevich In case you participate in more than one FOSS project, please fill out the questionnaire for the one where security is most important, or fill out one questionnaire per project. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080618/a163ede3/attachment.htm From vlado at dikini.net Thu Jun 19 09:34:26 2008 From: vlado at dikini.net (Vladimir Zlatanov) Date: Thu, 19 Jun 2008 10:34:26 +0100 Subject: [development] is anyone picking up DOC module? In-Reply-To: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> References: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> Message-ID: <1213868066.7062.60.camel@localhost.localdomain> > > I was looking for a Document management module > > and found that there was an offer to pick up development > > for 6.x version of Drupal > > http://drupal.org/node/254256 > > but it seems that author never responded. Sorry, this one went under my radar. > > Anyone else developing/maintaining alternative module > > for Drupla 6.x ? > Sounds like a perfect opportunity for them (or you) to follow the > Abandoned Project takeover process: http://drupal.org/node/251466 I would be glad to either get help on this module, or possibly a takeover. My ego is not high on my agenda :) For D6 - there is a need for redoing the file-api related parts. I haven't got the time and the project seems not to attract a lot of interest to make it a priority for me. If anyone is interested taking over the module or a joint effort, drop me an email. Cheers, Vlado From gwenael.saint-genest at makina-corpus.com Thu Jun 19 14:13:16 2008 From: gwenael.saint-genest at makina-corpus.com (Saint-Genest Gwenael) Date: Thu, 19 Jun 2008 16:13:16 +0200 Subject: [development] Error when install two Drupal 6.2 with PGSQL and table prefix (and patch) Message-ID: <485A697C.8010807@makina-corpus.com> Hi, Today, i've tried to install two sets of datas into a drupal 6.2 database (with pgsql). With a table prefix i've take an error like : Warning: pg_query() [function.pg-query]: Query failed: ERROR: type "int_unsigned" already exists in /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 138 Warning: ERROR: type "int_unsigned" already exists query: CREATE DOMAIN int_unsigned integer CHECK (VALUE >= 0) in /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 159 Warning: pg_query() [function.pg-query]: Query failed: ERROR: type "smallint_unsigned" already exists in /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 138 Warning: ERROR: type "smallint_unsigned" already exists query: CREATE DOMAIN smallint_unsigned smallint CHECK (VALUE >= 0) in /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 159 Warning: pg_query() [function.pg-query]: Query failed: ERROR: type "bigint_unsigned" already exists in /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 138 Warning: ERROR: type "bigint_unsigned" already exists query: CREATE DOMAIN bigint_unsigned bigint CHECK (VALUE >= 0) in /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 159 Ok ... Drupal try to create data types two times ... and crash :( If anyone else has the same error, this patch can solve this problem : --=={ snip }==-- --- drupal-6.2-ref/modules/system/system.install 2008-06-19 10:19:36.000000000 +0200 +++ drupal-6.2/modules/system/system.install 2008-06-19 15:53:28.000000000 +0200 @@ -302,9 +302,15 @@ function system_install() { if ($GLOBALS['db_type'] == 'pgsql') { // Create unsigned types. - db_query("CREATE DOMAIN int_unsigned integer CHECK (VALUE >= 0)"); - db_query("CREATE DOMAIN smallint_unsigned smallint CHECK (VALUE >= 0)"); - db_query("CREATE DOMAIN bigint_unsigned bigint CHECK (VALUE >= 0)"); + if (!db_result(db_query("SELECT COUNT(*) FROM pg_type WHERE typname = 'int_unsigned'"))) { + db_query("CREATE DOMAIN int_unsigned integer CHECK (VALUE >= 0)"); + } + if (!db_result(db_query("SELECT COUNT(*) FROM pg_type WHERE typname = 'smallint_unsigned'"))) { + db_query("CREATE DOMAIN smallint_unsigned smallint CHECK (VALUE >= 0)"); + } + if (!db_result(db_query("SELECT COUNT(*) FROM pg_type WHERE typname = 'bigint_unsigned'"))) { + db_query("CREATE DOMAIN bigint_unsigned bigint CHECK (VALUE >= 0)"); + } // Create functions. db_query('CREATE OR REPLACE FUNCTION "greatest"(numeric, numeric) RETURNS numeric AS --=={ snip }==-- Gwen -- Gwenael Saint-Genest MAKINA CORPUS - www.makina-corpus.com 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire Tel : +33 (0) 2 40 94 96 08 From catch56 at googlemail.com Thu Jun 19 14:17:40 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 19 Jun 2008 15:17:40 +0100 Subject: [development] Error when install two Drupal 6.2 with PGSQL and table prefix (and patch) In-Reply-To: <485A697C.8010807@makina-corpus.com> References: <485A697C.8010807@makina-corpus.com> Message-ID: Gwen, Please review existing issues for postgresql [1] and submit your patch to one if appropriate, or if not, create an issue and attach it there [2]. Nat 1. http://drupal.org/project/issues/drupal?text=postgresql&projects=3060&states=1%2C16%2C8%2C13%2C14%2C15%2C2%2C4 2. http://drupal.org/node/add/project-issue/drupal On Thu, Jun 19, 2008 at 3:13 PM, Saint-Genest Gwenael < gwenael.saint-genest at makina-corpus.com> wrote: > Hi, > > Today, i've tried to install two sets of datas into a drupal 6.2 > database (with pgsql). With a table prefix i've take an error like : > > Warning: pg_query() [function.pg-query]: Query failed: ERROR: type > "int_unsigned" already exists in > /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 138 > Warning: ERROR: type "int_unsigned" already exists query: CREATE DOMAIN > int_unsigned integer CHECK (VALUE >= 0) in > /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 159 > Warning: pg_query() [function.pg-query]: Query failed: ERROR: type > "smallint_unsigned" already exists in > /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 138 > Warning: ERROR: type "smallint_unsigned" already exists query: CREATE > DOMAIN smallint_unsigned smallint CHECK (VALUE >= 0) in > /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 159 > Warning: pg_query() [function.pg-query]: Query failed: ERROR: type > "bigint_unsigned" already exists in > /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 138 > Warning: ERROR: type "bigint_unsigned" already exists query: CREATE > DOMAIN bigint_unsigned bigint CHECK (VALUE >= 0) in > /var/www/xxxxxx/drupal-6.2/includes/database.pgsql.inc on line 159 > > Ok ... Drupal try to create data types two times ... and crash :( > > If anyone else has the same error, this patch can solve this problem : > > --=={ snip }==-- > --- drupal-6.2-ref/modules/system/system.install 2008-06-19 > 10:19:36.000000000 +0200 > +++ drupal-6.2/modules/system/system.install 2008-06-19 > 15:53:28.000000000 +0200 > @@ -302,9 +302,15 @@ > function system_install() { > if ($GLOBALS['db_type'] == 'pgsql') { > // Create unsigned types. > - db_query("CREATE DOMAIN int_unsigned integer CHECK (VALUE >= 0)"); > - db_query("CREATE DOMAIN smallint_unsigned smallint CHECK (VALUE >= > 0)"); > - db_query("CREATE DOMAIN bigint_unsigned bigint CHECK (VALUE >= 0)"); > + if (!db_result(db_query("SELECT COUNT(*) FROM pg_type WHERE typname > = 'int_unsigned'"))) { > + db_query("CREATE DOMAIN int_unsigned integer CHECK (VALUE >= 0)"); > + } > + if (!db_result(db_query("SELECT COUNT(*) FROM pg_type WHERE typname > = 'smallint_unsigned'"))) { > + db_query("CREATE DOMAIN smallint_unsigned smallint CHECK (VALUE > >> = 0)"); >> > + } > + if (!db_result(db_query("SELECT COUNT(*) FROM pg_type WHERE typname > = 'bigint_unsigned'"))) { > + db_query("CREATE DOMAIN bigint_unsigned bigint CHECK (VALUE >= 0)"); > + } > > // Create functions. > db_query('CREATE OR REPLACE FUNCTION "greatest"(numeric, numeric) > RETURNS numeric AS > --=={ snip }==-- > > > Gwen > > -- > Gwenael Saint-Genest > MAKINA CORPUS - www.makina-corpus.com > 44 boulevard des Pas Enchant?s FR-44230 Saint S?bastien sur Loire > Tel : +33 (0) 2 40 94 96 08 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080619/9898432f/attachment.htm From bharanikumariyerphp at gmail.com Sun Jun 22 15:00:36 2008 From: bharanikumariyerphp at gmail.com (bharani kumar) Date: Sun, 22 Jun 2008 20:30:36 +0530 Subject: [development] custom module with five star module colabration Message-ID: <2240033d0806220800x63b395a8k94c8439cd2720c33@mail.gmail.com> hi I am installed the five start module, I developed the custome module , name of module is event I am displaying event title,name,and star voting , How to display this star voting into the custom event, Expecting best solution -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080622/e254eb28/attachment.htm From kb at 2bits.com Sun Jun 22 16:29:48 2008 From: kb at 2bits.com (Khalid Baheyeldin) Date: Sun, 22 Jun 2008 12:29:48 -0400 Subject: [development] custom module with five star module colabration In-Reply-To: <2240033d0806220800x63b395a8k94c8439cd2720c33@mail.gmail.com> References: <2240033d0806220800x63b395a8k94c8439cd2720c33@mail.gmail.com> Message-ID: <4a9fdc630806220929o7b85b869y57555697d4cc605c@mail.gmail.com> The development list is for development questions. Your question is of the support type and you should check http://drupal.org/support for where best to ask such questions. Please do not post such questions to the list. On Sun, Jun 22, 2008 at 11:00 AM, bharani kumar < bharanikumariyerphp at gmail.com> wrote: > hi > I am installed the five start module, > > I developed the custome module , name of module is event > > I am displaying event title,name,and star voting , > > How to display this star voting into the custom event, > > Expecting best solution > -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080622/4daeabb8/attachment.htm From dries.buytaert at gmail.com Sun Jun 22 19:33:17 2008 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Sun, 22 Jun 2008 21:33:17 +0200 Subject: [development] DrupalCon Szeged registration Message-ID: <1248DB3C-BAF8-476D-996C-62982A947AB2@gmail.com> I had to share this: I just completed my DrupalCon Szeged registration. The conference organization and the registration system on the website are truly remarkable. Keep up the great work! (If you haven't registered yet for DrupalCon Szeged, now is the time as the conference will become more expensive at the end of the week.) -- Dries Buytaert :: http://buytaert.net From Greg at GrowingVentureSolutions.com Sun Jun 22 21:36:46 2008 From: Greg at GrowingVentureSolutions.com (Greg Knaddison - GVS) Date: Sun, 22 Jun 2008 15:36:46 -0600 Subject: [development] module_exists vs. functions_exists? Message-ID: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> Hi, In building some contrib modules that interact with other modules I often find myself writing something like: if (module_exists('module_name')) { $foo = module_name_api_function($bar); } This seems to be pretty common across core and contrib. I'd even call it standard. Another option would be: if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); } The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error. The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution. Thoughts? Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com From larry at garfieldtech.com Sun Jun 22 21:46:14 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Sun, 22 Jun 2008 16:46:14 -0500 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> Message-ID: <200806221646.14513.larry@garfieldtech.com> Come Drupal 7, you'll want to use drupal_function_exists() specifically so that it can lazy-load the function if needed. I suppose that's a strike in favor of using function_exists() for now so that your logic is already setup for that. On Sunday 22 June 2008 4:36:46 pm Greg Knaddison - GVS wrote: > Hi, > > In building some contrib modules that interact with other modules I > often find myself writing something like: > > if (module_exists('module_name')) { > $foo = module_name_api_function($bar); > } > > This seems to be pretty common across core and contrib. I'd even call > it standard. > > Another option would be: > > if (function_exists('module_name_api_function')) { > $foo = module_name_api_function($bar); > } > > The benefit of the second format is that if/when module_name's > maintainer decides to rewrite module_name and change all their > functions then my module may simply stop interacting with it rather > than failing on a function not found error. > > The benefit of the first format is that it fails quickly and is likely > to generate a bug report with a very clear solution. > > Thoughts? > > Thanks, > Greg -- Larry Garfield larry at garfieldtech.com From kb at 2bits.com Sun Jun 22 22:28:43 2008 From: kb at 2bits.com (Khalid Baheyeldin) Date: Sun, 22 Jun 2008 18:28:43 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <200806221646.14513.larry@garfieldtech.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <200806221646.14513.larry@garfieldtech.com> Message-ID: <4a9fdc630806221528j6ad417fak97abfc2a981d7609@mail.gmail.com> What happens when mymodule is enabled, but because of the registry (or even in D6, the "file" argument in hook_menu()) is not loading the function you assume exists just because mymodule is enabled (and module_exists('mymodule') returns TRUE? I guess function_exists() would be path dependent now? Please correct me. On Sun, Jun 22, 2008 at 5:46 PM, Larry Garfield wrote: > Come Drupal 7, you'll want to use drupal_function_exists() specifically so > that it can lazy-load the function if needed. I suppose that's a strike in > favor of using function_exists() for now so that your logic is already > setup > for that. > > On Sunday 22 June 2008 4:36:46 pm Greg Knaddison - GVS wrote: > > Hi, > > > > In building some contrib modules that interact with other modules I > > often find myself writing something like: > > > > if (module_exists('module_name')) { > > $foo = module_name_api_function($bar); > > } > > > > This seems to be pretty common across core and contrib. I'd even call > > it standard. > > > > Another option would be: > > > > if (function_exists('module_name_api_function')) { > > $foo = module_name_api_function($bar); > > } > > > > The benefit of the second format is that if/when module_name's > > maintainer decides to rewrite module_name and change all their > > functions then my module may simply stop interacting with it rather > > than failing on a function not found error. > > > > The benefit of the first format is that it fails quickly and is likely > > to generate a bug report with a very clear solution. > > > > Thoughts? > > > > Thanks, > > Greg > > -- > Larry Garfield > larry at garfieldtech.com > -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080622/8a1eb362/attachment-0001.htm From earnie at users.sourceforge.net Sun Jun 22 23:01:19 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sun, 22 Jun 2008 19:01:19 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> Message-ID: <20080622190119.es270p02h8noko8w@mail.progw.org> Quoting Greg Knaddison - GVS : > Hi, > > In building some contrib modules that interact with other modules I > often find myself writing something like: > > if (module_exists('module_name')) { > $foo = module_name_api_function($bar); > } > > This seems to be pretty common across core and contrib. I'd even call > it standard. > > Another option would be: > > if (function_exists('module_name_api_function')) { > $foo = module_name_api_function($bar); > } > > The benefit of the second format is that if/when module_name's > maintainer decides to rewrite module_name and change all their > functions then my module may simply stop interacting with it rather > than failing on a function not found error. > > The benefit of the first format is that it fails quickly and is likely > to generate a bug report with a very clear solution. > > Thoughts? > I would rather ask the interacting modules to insert a MODULE_FOO_VERSION and check for the constant being defined and defined to the version you expect. The module_exists function used with function_exists as you suggest is a good fall back for not having MODULE_FOO_VERSION. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From weitzman at tejasa.com Sun Jun 22 23:28:04 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Sun, 22 Jun 2008 19:28:04 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <200806221646.14513.larry@garfieldtech.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <200806221646.14513.larry@garfieldtech.com> Message-ID: <6117a7500806221628l6352cb94k416244856ea0eb4e@mail.gmail.com> > Come Drupal 7, you'll want to use drupal_function_exists() specifically so > that it can lazy-load the function if needed. I suppose that's a strike in > favor of using function_exists() for now so that your logic is already setup > for that. Right ... For D6 and below, module_invoke() does the if (function_exists()) for you. Some people prefer that pattern. From darthclue at gmail.com Sun Jun 22 23:30:50 2008 From: darthclue at gmail.com (Darth Clue) Date: Sun, 22 Jun 2008 18:30:50 -0500 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080622190119.es270p02h8noko8w@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <20080622190119.es270p02h8noko8w@mail.progw.org> Message-ID: <485EE0AA.5090609@gmail.com> Earnie Boyd wrote: > I would rather ask the interacting modules to insert a > MODULE_FOO_VERSION and check for the constant being defined and > defined to the version you expect. The module_exists function used > with function_exists as you suggest is a good fall back for not having > MODULE_FOO_VERSION. Agreed. I recently had an issue where a module I depended on was upgraded and this resulted in my module failing. Being able to specify that I was expecting a specific version of the module would have helped troubleshoot the issue alot quicker. Jonathan From catch56 at googlemail.com Sun Jun 22 23:39:18 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 23 Jun 2008 00:39:18 +0100 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <485EE0AA.5090609@gmail.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <20080622190119.es270p02h8noko8w@mail.progw.org> <485EE0AA.5090609@gmail.com> Message-ID: > Agreed. I recently had an issue where a module I depended on was upgraded > and this resulted in my module failing. Being able to specify that I was > expecting a specific version of the module would have helped troubleshoot > the issue alot quicker. > > Jonathan There's a patch here which does exactly that, just waiting to be reviewed: http://drupal.org/node/211747 Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080623/6b484579/attachment.htm From winborn at advomatic.com Mon Jun 23 11:50:35 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Mon, 23 Jun 2008 07:50:35 -0400 (EDT) Subject: [development] module_exists vs. functions_exists? In-Reply-To: <6117a7500806221628l6352cb94k416244856ea0eb4e@mail.gmail.com> Message-ID: <7188263.49521214221835199.JavaMail.root@zimbra> Ah, didn't realize it was changing :( Guess I need to read up on this issue. ----- Original Message ----- From: "Moshe Weitzman" To: development at drupal.org Sent: Sunday, June 22, 2008 7:28:04 PM GMT -05:00 US/Canada Eastern Subject: Re: [development] module_exists vs. functions_exists? > Come Drupal 7, you'll want to use drupal_function_exists() specifically so > that it can lazy-load the function if needed. I suppose that's a strike in > favor of using function_exists() for now so that your logic is already setup > for that. Right ... For D6 and below, module_invoke() does the if (function_exists()) for you. Some people prefer that pattern. From winborn at advomatic.com Mon Jun 23 11:49:33 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Mon, 23 Jun 2008 07:49:33 -0400 (EDT) Subject: [development] module_exists vs. functions_exists? In-Reply-To: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> Message-ID: <18140452.49491214221773105.JavaMail.root@zimbra> I usually use the following pattern: if (module_exists('module_name')) { $foo = module_invoke('module_name', 'api_function', $bar); } ----- Original Message ----- From: "Greg Knaddison - GVS" To: development at drupal.org Sent: Sunday, June 22, 2008 5:36:46 PM GMT -05:00 US/Canada Eastern Subject: [development] module_exists vs. functions_exists? Hi, In building some contrib modules that interact with other modules I often find myself writing something like: if (module_exists('module_name')) { $foo = module_name_api_function($bar); } This seems to be pretty common across core and contrib. I'd even call it standard. Another option would be: if (function_exists('module_name_api_function')) { $foo = module_name_api_function($bar); } The benefit of the second format is that if/when module_name's maintainer decides to rewrite module_name and change all their functions then my module may simply stop interacting with it rather than failing on a function not found error. The benefit of the first format is that it fails quickly and is likely to generate a bug report with a very clear solution. Thoughts? Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com From nan_wich at bellsouth.net Mon Jun 23 12:07:55 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 23 Jun 2008 08:07:55 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <18140452.49491214221773105.JavaMail.root@zimbra> Message-ID: Aaron Winborn wrote: > $foo = module_invoke('module_name', 'api_function', $bar); I understand that this may be a bit safer, but it has a drawback o its own. Coder won't catch these when it's time to upgrade to a new core version. Nancy -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1513 - Release Date: 6/22/2008 7:52 AM From earnie at users.sourceforge.net Mon Jun 23 12:20:29 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 23 Jun 2008 08:20:29 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <18140452.49491214221773105.JavaMail.root@zimbra> References: <18140452.49491214221773105.JavaMail.root@zimbra> Message-ID: <20080623082029.86sm32ci8uk0o44s@mail.progw.org> Quoting Aaron Winborn : > I usually use the following pattern: > > if (module_exists('module_name')) { > $foo = module_invoke('module_name', 'api_function', $bar); > } > I think you're correct in using this; but only for hooks. You've stated 'api_function' when it is actually the 'hook'. And if mymodule_myfunction isn't a hook should we be using module_invoke to do the call? No, we should call the function directly. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From news at unleashedmind.com Mon Jun 23 12:53:52 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 23 Jun 2008 14:53:52 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080623082029.86sm32ci8uk0o44s@mail.progw.org> Message-ID: <00f601c8d530$308ef1c0$0200a8c0@structworks.com> > $foo = module_invoke('module_name', 'api_function', $bar); ...without module_exists() is sufficient. module_invoke() invokes module_hook(), which in turn checks for function_exists(). Also, module_invoke() is not limited to Drupal hooks / API callbacks. If the returned results of call_user_func_array() work for your particular implementation, this is the best approach for each module that wants to integrate with another, optionally installed module in contrib. @see http://api.drupal.org/api/function/module_invoke/5 @see http://api.drupal.org/api/function/module_hook/5 Daniel From morbus at disobey.com Mon Jun 23 13:51:34 2008 From: morbus at disobey.com (Morbus Iff) Date: Mon, 23 Jun 2008 09:51:34 -0400 Subject: [development] 5/6: cache_clear_all(), custom items, and no cache_lifetime > failure Message-ID: <485FAA66.2080803@disobey.com> Michelle ran into it long ago in her Advanced Forum module, and I ran into it a while back in regards to blocks. I just ran into it again today in a non-block scenario. In short: http://www.lullabot.com/articles/a_beginners_guide_to_caching_data will only work if you have a "Minimum cache lifetime" set. Cache expiration, for items with a custom expiration, will never automatically occur, as cache_clear_all('', 'cache') is never called. This happens in Drupal 5 and 6. There are three ways that cache can be expired: 1) you manually expire your own entry. 2) cache_clear_all() is called with the right parameters. 3) cache_get() is called, with a minimum cache_lifetime set. For now, let's safely ignore 1) since the explanation of cache_set() suggests that setting your own expiration timestamp treats the item as CACHE_TEMPORARY, and that it'll be flushed in the next general clear. Also ignore #3 - let's assume no minimum cache lifetime was set. If we take a look at cache_clear_all(): http://api.drupal.org/api/function/cache_clear_all/5 http://api.drupal.org/api/function/cache_clear_all/6 we can see the helpful comment of "No minimum cache lifetime, flush all temporary cache entries now." To get this code to run, however, the $cid must be empty *and $table must be set to 'cache'*. If both cid and table are empty, then the function defaults to clearing cache_block and cache_page. But, if you grep for "cache_clear_all()" in core, you'll never find an instance of "cache_clear_all(NULL, 'cache')". You'll see lots of "cache_clear_all()"s with no parameters, and lots of specific clearing, but nothing that specifically clears out temporary items in 'cache'. You won't even see a "destroy everything" cache_clear_all(*, 'cache', TRUE). I consider this a bug: * garbage collection should happen automatically - else, why would a calling module tell cache_set() about the expiry date if it's the module's responsibility to clean it up? * "Minimum cache lifetime" is a performance tweak, and should not be required to properly clear CACHE_TEMPORARY items. How to fix the bug? Honestly, I don't know - one would, presumably, add a cache_clear_all(NULL, 'cache') to a hook_cron implementation, but I'm not the one to know the best location for that. Suggestions? And, naturally, if my reasoning is all wrong, lemme know too. -- 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 winborn at advomatic.com Mon Jun 23 14:46:47 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Mon, 23 Jun 2008 10:46:47 -0400 (EDT) Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080623082029.86sm32ci8uk0o44s@mail.progw.org> Message-ID: <14233550.49601214232407103.JavaMail.root@zimbra> As we don't have public and private scope, I think that in practice, failing a better method, module_invoke should be the safer way to do this. In my modules, if I have functionality I don't want to expose, I prefix it with an underscore: _module_name_private_api. Thus, in my hypothetical contract, module_name_public_api would be safe to be called using module_invoke, at least within a core version, and would at least guarantee the same arguments and expected result, even if the inner codebase changed. Whereas the private function would have no such guarantee, and modules invoking it do so at the risk that the function's arguments may change, or it may even cease to exist. Additionally, module_invoke would allow for optional dependence, which is generally where I use that anyway. ----- Original Message ----- From: "Earnie Boyd" To: development at drupal.org Sent: Monday, June 23, 2008 8:20:29 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] module_exists vs. functions_exists? Quoting Aaron Winborn : > I usually use the following pattern: > > if (module_exists('module_name')) { > $foo = module_invoke('module_name', 'api_function', $bar); > } > I think you're correct in using this; but only for hooks. You've stated 'api_function' when it is actually the 'hook'. And if mymodule_myfunction isn't a hook should we be using module_invoke to do the call? No, we should call the function directly. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From winborn at advomatic.com Mon Jun 23 14:59:23 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Mon, 23 Jun 2008 10:59:23 -0400 (EDT) Subject: [development] module_exists vs. functions_exists? In-Reply-To: <23466338.49631214233131514.JavaMail.root@zimbra> Message-ID: <10060579.49651214233163132.JavaMail.root@zimbra> Ah, thanks. Keeping it simple... ----- Original Message ----- From: "Daniel F. Kudwien" To: development at drupal.org Sent: Monday, June 23, 2008 8:53:52 AM GMT -05:00 US/Canada Eastern Subject: Re: [development] module_exists vs. functions_exists? > $foo = module_invoke('module_name', 'api_function', $bar); ...without module_exists() is sufficient. module_invoke() invokes module_hook(), which in turn checks for function_exists(). Also, module_invoke() is not limited to Drupal hooks / API callbacks. If the returned results of call_user_func_array() work for your particular implementation, this is the best approach for each module that wants to integrate with another, optionally installed module in contrib. @see http://api.drupal.org/api/function/module_invoke/5 @see http://api.drupal.org/api/function/module_hook/5 Daniel From earnie at users.sourceforge.net Mon Jun 23 15:58:31 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 23 Jun 2008 11:58:31 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <00f601c8d530$308ef1c0$0200a8c0@structworks.com> References: <00f601c8d530$308ef1c0$0200a8c0@structworks.com> Message-ID: <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> Quoting "Daniel F. Kudwien" : > > Also, module_invoke() is not limited to Drupal hooks / API callbacks. > If the returned results of call_user_func_array() work for your > particular implementation, this is the best approach for each module > that wants to integrate with another, optionally installed module in > contrib. > While using module_invoke for things other than hooks today, I do not think we should recommend it since the purpose of module_invoke is to invoke the hook. Using module_invoke for more than its intended purpose is confusing and may cause issues in the future should module_invoke change its ways. Module_invoke is more like calling an object function while executing the function directly is more like executing a static class function. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From nan_wich at bellsouth.net Mon Jun 23 16:00:46 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Mon, 23 Jun 2008 12:00:46 -0400 Subject: [development] 5/6: cache_clear_all(), custom items, and no cache_lifetime > failure In-Reply-To: <485FAA66.2080803@disobey.com> Message-ID: Morbus Iff wrote: > will only work if you have a "Minimum cache lifetime" set. And other things will break if you do use it. IIRC, Update Status had some problems when it was turned on. Nancy -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1513 - Release Date: 6/22/2008 7:52 AM From earnie at users.sourceforge.net Mon Jun 23 16:28:08 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 23 Jun 2008 12:28:08 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <14233550.49601214232407103.JavaMail.root@zimbra> References: <14233550.49601214232407103.JavaMail.root@zimbra> Message-ID: <20080623122808.7jtu6ansyn4gko8k@mail.progw.org> Quoting Aaron Winborn : > As we don't have public and private scope, But we do, really. Sure it's global but we do have the ability to create standards that set a private scope using the module name and prefixing the module name with an _ (underscore) character for private module use. > I think that in practice, failing a better method, module_invoke > should be the safer way to do this. As I've stated already, module_invoke is meant to be used to invoke hooks. Using module_invoke for anything else is confusing and can cause issues should module_invoke change its methods. > In my modules, if I have functionality I don't want to expose, I > prefix it with an underscore: _module_name_private_api. This should be the case for all private symbols. This ensures that some new hook isn't going to cause you to have to rename your private functions. Stating this brings another issue with the Drupal hook system in that my naming of my module static function isn't namespace safe. For example mymodule_myfunction becomes invoked when Drupal or some other module adds a hook and invokes all implementations of hook_myfunction which isn't what I meant for mymodule_myfunction. This is most easily avoided by using a static class and defining all functions for the module within the class. However, this should only happen with a new version of Drupal and we have to convert the modules to use the new versions anyway; but, how many of us check our function names as being a new hook? > Thus, in my hypothetical contract, module_name_public_api would be > safe to be called using module_invoke, at least within a core > version, and would at least guarantee the same arguments and expected > result, even if the inner codebase changed. Whereas the private > function would have no such guarantee, and modules invoking it do so > at the risk that the function's arguments may change, or it may even > cease to exist. > No such guarantee for public function can be made and private functions should remain private for the reason you suggest. Another reason to use classes for the module functions; if I mark the function private, it truly is. > Additionally, module_invoke would allow for optional dependence, > which is generally where I use that anyway. > Not anymore than using function_exists. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From news at unleashedmind.com Mon Jun 23 16:38:46 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 23 Jun 2008 18:38:46 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> Message-ID: <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> > While using module_invoke for things other than hooks today, > I do not think we should recommend it since the purpose of > module_invoke is to invoke the hook. Using module_invoke for > more than its intended purpose is confusing and may cause > issues in the future should module_invoke change its ways. > Module_invoke is more like calling an object function while > executing the function directly is more like executing a > static class function. > > Earnie For what it's worth: Drupal's core API changes only between major versions. As long as we're speaking of D5 and D6, and of contrib modules for D5 and D6, I would repeat my previous recommendation to a) remove unnecessary module_exists()/function_exists() code bloats, and b) manifest a best practice that can be dealt with in the module upgrade docs for D7 and/or beyond. Until there is not a better API method, it is absolutely safe to use module_invoke(). Look, it's still there: http://api.drupal.org/api/function/module_invoke/7 Daniel From michael at favias.org Mon Jun 23 17:56:40 2008 From: michael at favias.org (Michael Favia) Date: Mon, 23 Jun 2008 12:56:40 -0500 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <00f601c8d530$308ef1c0$0200a8c0@structworks.com> References: <00f601c8d530$308ef1c0$0200a8c0@structworks.com> Message-ID: <485FE3D8.1070406@favias.org> Daniel F. Kudwien wrote: > Also, module_invoke() is not limited to Drupal hooks / API callbacks. If the returned results of call_user_func_array() work for your particular implementation, this is the best approach for each module that wants to integrate with another, optionally installed module in contrib. Assuming you dont want to do something else if the module/function doesn't exist of course. Which in my usage is normally the case. I suppose checking the boolean return value from call_user_func_array() would probably suffice for most cases unless FALSE is a valid return from the function that didn't exist in the first place. Tricky, tricky. Who's on first? -- Michael Favia michael at favias.org tel. 512.585.5650 http://www.favias.org From earnie at users.sourceforge.net Mon Jun 23 17:59:29 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 23 Jun 2008 13:59:29 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> References: <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> Message-ID: <20080623135929.q7888mrnil7kkk4c@mail.progw.org> Quoting "Daniel F. Kudwien" : >> While using module_invoke for things other than hooks today, >> I do not think we should recommend it since the purpose of >> module_invoke is to invoke the hook. Using module_invoke for >> more than its intended purpose is confusing and may cause >> issues in the future should module_invoke change its ways. >> Module_invoke is more like calling an object function while >> executing the function directly is more like executing a >> static class function. >> >> Earnie > > For what it's worth: Drupal's core API changes only between major > versions. As long as we're speaking of D5 and D6, and of contrib > modules for D5 and D6, I would repeat my previous recommendation to > a) remove unnecessary module_exists()/function_exists() code bloats, > and b) manifest a best practice that can be dealt with in the module > upgrade docs for D7 and/or beyond. Until there is not a better API > method, it is absolutely safe to use module_invoke(). > > Look, it's still there: > http://api.drupal.org/api/function/module_invoke/7 > For D7 it has already been stated that you want to use http://api.drupal.org/api/function/drupal_function_exists/7 so that the modules files are loaded as necessary. Module_invoke is not the correct thing to do unless you want to invoke hooks. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From drupal.beginner at wechange.org Tue Jun 24 08:36:19 2008 From: drupal.beginner at wechange.org (Augustin (Beginner)) Date: Tue, 24 Jun 2008 16:36:19 +0800 Subject: [development] Code freeze? Message-ID: <200806241636.19350.drupal.beginner@wechange.org> Hi, What is the latest news about the D7 code freeze. I haven't seen any announcement on this list. Do we have a date for the code freeze, or at least a better estimate than what was offered at the beginning of the thaw? thanks, Augustin. From catch56 at googlemail.com Tue Jun 24 09:03:35 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 24 Jun 2008 10:03:35 +0100 Subject: [development] Code freeze? In-Reply-To: <200806241636.19350.drupal.beginner@wechange.org> References: <200806241636.19350.drupal.beginner@wechange.org> Message-ID: The latest news (unless there's an update I'm not aware of) is still http://buytaert.net/drupal-7-timeline So I guess it depends on what Dries means by "fully embrace testing" and whether we've done that or not. See also: http://drupal.org/node/254640 Nat On Tue, Jun 24, 2008 at 9:36 AM, Augustin (Beginner) wrote: > > > Hi, > > What is the latest news about the D7 code freeze. I haven't seen any > announcement on this list. Do we have a date for the code freeze, or > at least a better estimate than what was offered at the beginning of > the thaw? > > > thanks, > > > Augustin. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080624/6326fd85/attachment.htm From drupal.beginner at wechange.org Tue Jun 24 12:47:37 2008 From: drupal.beginner at wechange.org (Augustin (Beginner)) Date: Tue, 24 Jun 2008 20:47:37 +0800 Subject: [development] Code freeze? In-Reply-To: References: <200806241636.19350.drupal.beginner@wechange.org> Message-ID: <200806242047.37932.drupal.beginner@wechange.org> On Tuesday 24 June 2008 17:03:35 Nathaniel Catchpole wrote: > The latest news (unless there's an update I'm not aware of) is > still http://buytaert.net/drupal-7-timeline > > So I guess it depends on what Dries means by "fully embrace > testing" and whether we've done that or not. > > See also: http://drupal.org/node/254640 > Thanks for the links. I was not aware of the second. The former is precisely why I'm asking. July 15th is approaching quickly, and it'd be nice to have a more precise estimate, now. Thanks, Augustin. From frando2 at unbiskant.org Tue Jun 24 14:27:09 2008 From: frando2 at unbiskant.org (Frando) Date: Tue, 24 Jun 2008 07:27:09 -0700 (PDT) Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080623135929.q7888mrnil7kkk4c@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <18140452.49491214221773105.JavaMail.root@zimbra> <20080623082029.86sm32ci8uk0o44s@mail.progw.org> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> Message-ID: <18092252.post@talk.nabble.com> In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I don't see why you should not use module_invoke to call API functions. -- Frando Earnie wrote: > > Quoting "Daniel F. Kudwien" : > >>> While using module_invoke for things other than hooks today, >>> I do not think we should recommend it since the purpose of >>> module_invoke is to invoke the hook. Using module_invoke for >>> more than its intended purpose is confusing and may cause >>> issues in the future should module_invoke change its ways. >>> Module_invoke is more like calling an object function while >>> executing the function directly is more like executing a >>> static class function. >>> >>> Earnie >> >> For what it's worth: Drupal's core API changes only between major >> versions. As long as we're speaking of D5 and D6, and of contrib >> modules for D5 and D6, I would repeat my previous recommendation to >> a) remove unnecessary module_exists()/function_exists() code bloats, >> and b) manifest a best practice that can be dealt with in the module >> upgrade docs for D7 and/or beyond. Until there is not a better API >> method, it is absolutely safe to use module_invoke(). >> >> Look, it's still there: >> http://api.drupal.org/api/function/module_invoke/7 >> > > For D7 it has already been stated that you want to use > http://api.drupal.org/api/function/drupal_function_exists/7 so that the > modules files are loaded as necessary. Module_invoke is not the > correct thing to do unless you want to invoke hooks. > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/ > > > -- View this message in context: http://www.nabble.com/module_exists-vs.-functions_exists--tp18059424p18092252.html Sent from the Drupal - Dev mailing list archive at Nabble.com. From earnie at users.sourceforge.net Tue Jun 24 17:48:21 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 24 Jun 2008 13:48:21 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <18092252.post@talk.nabble.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <18140452.49491214221773105.JavaMail.root@zimbra> <20080623082029.86sm32ci8uk0o44s@mail.progw.org> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> Message-ID: <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> Quoting Frando : > > In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I > don't see why you should not use module_invoke to call API functions. > As I have already stated it isn't the defined use of the function. The defined use of the function is to execute hook implementations. If it is used for anything else then confusion will happen and perhaps cause for a lot of frustration in maintenance. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From mike at mikeyp.net Tue Jun 24 17:50:54 2008 From: mike at mikeyp.net (Michael Prasuhn) Date: Tue, 24 Jun 2008 10:50:54 -0700 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <18140452.49491214221773105.JavaMail.root@zimbra> <20080623082029.86sm32ci8uk0o44s@mail.progw.org> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> Message-ID: <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> On Jun 24, 2008, at 10:48 AM, Earnie Boyd wrote: > Quoting Frando : > >> >> In Drupal 7, module_invoke uses module_hook uses >> drupal_function_exists. I >> don't see why you should not use module_invoke to call API functions. >> > > As I have already stated it isn't the defined use of the function. > The defined use of the function is to execute hook implementations. > If it is used for anything else then confusion will happen and > perhaps cause for a lot of frustration in maintenance. I don't buy it. This looks like an excellent use of an existing function that does exactly what is called for. What defines a 'hook' anyway? Is a function not a hook if only one module implements it? Would it be such a stretch to think of every function as a hook to be invoked in multiple different ways? -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net 503.488.5433 714.356.0168 cell 949.200.7670 fax From damz at prealable.org Tue Jun 24 18:32:20 2008 From: damz at prealable.org (Damien) Date: Tue, 24 Jun 2008 20:32:20 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <18140452.49491214221773105.JavaMail.root@zimbra> <20080623082029.86sm32ci8uk0o44s@mail.progw.org> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> Message-ID: On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn wrote, about module_invoke(): > > I don't buy it. This looks like an excellent use of an existing function > that does exactly what is called for. What defines a 'hook' anyway? Is a > function not a hook if only one module implements it? Would it be such a > stretch to think of every function as a hook to be invoked in multiple > different ways? > It doesn't make sense to use module_invoke() in the stated case (calling a specific API function of a module). module_invoke() does not do any error checking, and it does not report anything useful. You should call drupal_functon_exists() directly and act accordingly in case of errors. Using module_invoke() here would be bad practice at best, but could also be dangerous. Damien Tournoud -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080624/5dc91f11/attachment-0001.htm From earnie at users.sourceforge.net Tue Jun 24 19:50:43 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Tue, 24 Jun 2008 15:50:43 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <18140452.49491214221773105.JavaMail.root@zimbra> <20080623082029.86sm32ci8uk0o44s@mail.progw.org> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> Message-ID: <20080624155043.r9b9fddgxdkwgg0w@mail.progw.org> Quoting Michael Prasuhn : > > On Jun 24, 2008, at 10:48 AM, Earnie Boyd wrote: > >> Quoting Frando : >> >>> >>> In Drupal 7, module_invoke uses module_hook uses drupal_function_exists. I >>> don't see why you should not use module_invoke to call API functions. >>> >> >> As I have already stated it isn't the defined use of the function. >> The defined use of the function is to execute hook implementations. >> If it is used for anything else then confusion will happen and >> perhaps cause for a lot of frustration in maintenance. > > > I don't buy it. This looks like an excellent use of an existing > function that does exactly what is called for. What defines a 'hook' > anyway? Is a function not a hook if only one module implements it? > Would it be such a stretch to think of every function as a hook to be > invoked in multiple different ways? > http://api.drupal.org/api/group/hooks/7 Yes it is a bit of a stretch to think of every function as a hook because every function isn't supposed to be and doing so causes confusion and hardship in maintenance. The definition of module_invoke is to invoke implemented hooks and shouldn't be used as a lazy method of calling a function. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From mike at mikeyp.net Tue Jun 24 19:31:36 2008 From: mike at mikeyp.net (Michael Prasuhn) Date: Tue, 24 Jun 2008 12:31:36 -0700 Subject: [development] module_exists vs. functions_exists? In-Reply-To: References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <18140452.49491214221773105.JavaMail.root@zimbra> <20080623082029.86sm32ci8uk0o44s@mail.progw.org> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> Message-ID: On Jun 24, 2008, at 11:32 AM, Damien wrote: > On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn > wrote, about module_invoke(): I don't buy it. This looks like an > excellent use of an existing function that does exactly what is > called for. What defines a 'hook' anyway? Is a function not a hook > if only one module implements it? Would it be such a stretch to > think of every function as a hook to be invoked in multiple > different ways? > > It doesn't make sense to use module_invoke() in the stated case > (calling a specific API function of a module). module_invoke() does > not do any error checking, and it does not report anything useful. > You should call drupal_functon_exists() directly and act accordingly > in case of errors. > > Using module_invoke() here would be bad practice at best, but could > also be dangerous. Once again, I don't buy it. If you have to switch off of whether the function exists, then by all means do that. But for Drupal 6 development I see no issue with using module_invoke. If you can't be bothered to test your code to make sure what it depends on is there, then your code has deeper issues than the method used to interface with another API. -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net From cxjohnson at gmail.com Tue Jun 24 23:02:01 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 24 Jun 2008 18:02:01 -0500 Subject: [development] module_exists vs. functions_exists? In-Reply-To: References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> Message-ID: <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> module_invoke() is used to call core API functions in a special core API class called hooks. If your function is not part of the core API, then using module_invoke to call it is misleading. Misleading code is a maintenance problem. Some day, the functionality of module_invoke() may change and not work correctly to call random contributed module functions. It will always work to call hooks, however. Hence, by definition, it is wrong to use it for a purpose it was not meant. On Tue, Jun 24, 2008 at 2:31 PM, Michael Prasuhn wrote: > On Jun 24, 2008, at 11:32 AM, Damien wrote: > >> On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn wrote, >> about module_invoke(): I don't buy it. This looks like an excellent use of >> an existing function that does exactly what is called for. What defines a >> 'hook' anyway? Is a function not a hook if only one module implements it? >> Would it be such a stretch to think of every function as a hook to be >> invoked in multiple different ways? >> >> It doesn't make sense to use module_invoke() in the stated case (calling a >> specific API function of a module). module_invoke() does not do any error >> checking, and it does not report anything useful. You should call >> drupal_functon_exists() directly and act accordingly in case of errors. >> >> Using module_invoke() here would be bad practice at best, but could also >> be dangerous. >> > > > Once again, I don't buy it. If you have to switch off of whether the > function exists, then by all means do that. But for Drupal 6 development I > see no issue with using module_invoke. If you can't be bothered to test your > code to make sure what it depends on is there, then your code has deeper > issues than the method used to interface with another API. > > -Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080624/8d1ad4b9/attachment.htm From zblace at gmail.com Wed Jun 25 10:45:26 2008 From: zblace at gmail.com (zeljko blace) Date: Wed, 25 Jun 2008 12:45:26 +0200 Subject: [development] is anyone picking up DOC module? In-Reply-To: <1213868066.7062.60.camel@localhost.localdomain> References: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> <1213868066.7062.60.camel@localhost.localdomain> Message-ID: As DOC module seems to be stuck, I am looking for alternative method for primitive DOC management. So far I have been thinking of attaching .doc and .xls files to nodes and removing body from those nodes then displaying them with views2... That way files can be commented on, searched for and can have notes on versions Any other options/alternatives? regards Zeljko From zblace at gmail.com Wed Jun 25 11:09:42 2008 From: zblace at gmail.com (zeljko blace) Date: Wed, 25 Jun 2008 13:09:42 +0200 Subject: [development] internal messaging among users for Drupal 6.x? Message-ID: Hi folks! Not sure if this fits support or development...sorry for cross-posting. What is the logical solution to providing interface for internal messaging among users for Drupal 6.x? I need just basic inbox & outbox view, and compose, reply & forward forms. Is there a specific Module? something being ported from 5.x or made new for 6.x? Regards - Zeljko From juan.fco.rodriguez at gmail.com Wed Jun 25 12:03:03 2008 From: juan.fco.rodriguez at gmail.com (Juan Rodriguez) Date: Wed, 25 Jun 2008 14:03:03 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> Message-ID: <96b30c400806250503p6b4de22dk4ece5d2c63d72b4e@mail.gmail.com> On Wed, Jun 25, 2008 at 1:02 AM, Chris Johnson wrote: > module_invoke() is used to call core API functions in a special core API > class called hooks. If your function is not part of the core API, then > using module_invoke to call it is misleading. Misleading code is a > maintenance problem. Some day, the functionality of module_invoke() may > change and not work correctly to call random contributed module functions. > It will always work to call hooks, however. Hence, by definition, it is > wrong to use it for a purpose it was not meant. > > On Tue, Jun 24, 2008 at 2:31 PM, Michael Prasuhn wrote: >> >> On Jun 24, 2008, at 11:32 AM, Damien wrote: >>> >>> On Tue, Jun 24, 2008 at 7:50 PM, Michael Prasuhn wrote, >>> about module_invoke(): I don't buy it. This looks like an excellent use of >>> an existing function that does exactly what is called for. What defines a >>> 'hook' anyway? Is a function not a hook if only one module implements it? >>> Would it be such a stretch to think of every function as a hook to be >>> invoked in multiple different ways? >>> >>> It doesn't make sense to use module_invoke() in the stated case (calling >>> a specific API function of a module). module_invoke() does not do any error >>> checking, and it does not report anything useful. You should call >>> drupal_functon_exists() directly and act accordingly in case of errors. >>> >>> Using module_invoke() here would be bad practice at best, but could also >>> be dangerous. >> >> >> Once again, I don't buy it. If you have to switch off of whether the >> function exists, then by all means do that. But for Drupal 6 development I >> see no issue with using module_invoke. If you can't be bothered to test your >> code to make sure what it depends on is there, then your code has deeper >> issues than the method used to interface with another API. >> >> -Mike >> > > I agree with Chris johnson, I would say even more, I would propose a modification to module_invoke to not allow calling API functions other than hooks :) From earnie at users.sourceforge.net Wed Jun 25 13:26:46 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 25 Jun 2008 09:26:46 -0400 Subject: [development] is anyone picking up DOC module? In-Reply-To: References: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> <1213868066.7062.60.camel@localhost.localdomain> Message-ID: <20080625092646.9n18ir456fnwo884@mail.progw.org> Quoting zeljko blace : > > Any other options/alternatives? > You might find a few at http://groups.drupal.org/document-management where there are several posts and comments about the subject. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From naheemzaffar at gmail.com Wed Jun 25 13:41:45 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 25 Jun 2008 14:41:45 +0100 Subject: [development] internal messaging among users for Drupal 6.x? In-Reply-To: References: Message-ID: <3adc77210806250641g785318fawa69ed165a4c60f2d@mail.gmail.com> There is some work being done in the privatemsg module. It is not ready for prime time yet, but it should be Real Soon(TM). (the drupal-6.x version is I think a completely new implementation and does not use much of the 5.x code.) From earnie at users.sourceforge.net Wed Jun 25 13:54:25 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 25 Jun 2008 09:54:25 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> Message-ID: <20080625095425.28t2ltoxfq6ock88@mail.progw.org> Quoting Chris Johnson : > module_invoke() is used to call core API functions in a special core API > class called hooks. If your function is not part of the core API, then > using module_invoke to call it is misleading. Misleading code is a > maintenance problem. Some day, the functionality of module_invoke() may > change and not work correctly to call random contributed module functions. > It will always work to call hooks, however. Hence, by definition, it is > wrong to use it for a purpose it was not meant. > Correct, and stating it like Chris has said we can go as far to say that module_invoke is a private core function reserved for the use of the hooks class. Modules themselves should not use it unless the module has created a hook and needs to call other modules implementations of that hook. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From vlado at dikini.net Wed Jun 25 12:41:58 2008 From: vlado at dikini.net (Vladimir Zlatanov) Date: Wed, 25 Jun 2008 13:41:58 +0100 Subject: [development] is anyone picking up DOC module? In-Reply-To: References: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> <1213868066.7062.60.camel@localhost.localdomain> <1214391547.7022.126.camel@localhost.localdomain> Message-ID: <1214397718.7022.148.camel@localhost.localdomain> oops, forgot to cc the list. Sorry. Somebody else might be able to pitch in as well. >> As DOC module seems to be stuck, >> I am looking for alternative method for primitive DOC management. > >> So far I have been thinking of attaching .doc and .xls >> files to nodes and removing body from those nodes >> then displaying them with views2... > > Just to clarify - you are looking for ways to store files with drupal. > And maybe some tagging, etc... > yes - very basic > > It that is yes - you can use views to display the various lists the way > > you want them to. You could style the results. > > yes - just need to have them in Blocks rather then full pages. Views does blocks. And you seem to like them. > > If I had to start from scratch, I wouldn't even develop docs in the > > first place. It fills a very narrow niche, and my users are very, very, > > very conservative. I would try and configure a system similar to what > > you described. In D6 it should be trivial to make a simple file node. I > > haven't done it, but the infrastructure is there. You will need to > > invest some time in coding though. > > PHP coding of new feature or just HTML/CSS+Views2 or CCK2? Very few lines of code to create the new node type and possibly assign a node title based on the file name. There is sample code in docs, but it is overcomplicated, since it does more work. I'm not sure if you won't be able to get away with mostly a custom .info file. Haven't looked carefully at d6 yet. If you base it around standard nodes, you don't need cck. views is automatic. Theming as well, unless you want a custom look, which is sightly more complicated, but quite straight forward. The docs team has done a good job, really. > >> That way files can be commented on, searched for and > >> can have notes on versions > > Only if you can extract text from the files. You still could do taxonomy based queries. > > just few words would be sufficient Well, you need something to put those words into the search table. You need something to extract them from your files - doc, pdf, whatever.... Drupal by default doesn't know anything but their name and size and that is not in the search table. I would be happy to update docs, but i will possibly have a week or so free(ish) towards the middle of July. Before that it is busy, busy, busy. If anyone wants to help out with the module or become a co-maintainer/maintainer, just shout. We can sync via email and irc. Cheers, Vlado From zblace at gmail.com Wed Jun 25 15:29:25 2008 From: zblace at gmail.com (zeljko blace) Date: Wed, 25 Jun 2008 17:29:25 +0200 Subject: [development] is anyone picking up DOC module? In-Reply-To: <1214397718.7022.148.camel@localhost.localdomain> References: <3861c6770806181256o2a0dd5e5pac4ebf63ab91e6f0@mail.gmail.com> <1213868066.7062.60.camel@localhost.localdomain> <1214391547.7022.126.camel@localhost.localdomain> <1214397718.7022.148.camel@localhost.localdomain> Message-ID: On Wed, Jun 25, 2008 at 2:41 PM, Vladimir Zlatanov wrote: > oops, forgot to cc the list. Sorry. Somebody else might be able to pitch > in as well. > >>> As DOC module seems to be stuck, >>> I am looking for alternative method for primitive DOC management. >> >>> So far I have been thinking of attaching .doc and .xls >>> files to nodes and removing body from those nodes >>> then displaying them with views2... >> >> Just to clarify - you are looking for ways to store files with drupal. >> And maybe some tagging, etc... > >> yes - very basic > >> > It that is yes - you can use views to display the various lists the way >> > you want them to. You could style the results. >> >> yes - just need to have them in Blocks rather then full pages. > Views does blocks. And you seem to like them. > >> > If I had to start from scratch, I wouldn't even develop docs in the >> > first place. It fills a very narrow niche, and my users are very, very, >> > very conservative. I would try and configure a system similar to what >> > you described. In D6 it should be trivial to make a simple file node. I >> > haven't done it, but the infrastructure is there. You will need to >> > invest some time in coding though. >> >> PHP coding of new feature or just HTML/CSS+Views2 or CCK2? > Very few lines of code to create the new node type and possibly assign a > node title based on the file name. There is sample code in docs, but it is > overcomplicated, since it does more work. I'm not sure if you won't be able > to get away with mostly a custom .info file. Haven't looked carefully > at d6 yet. Can anyone give me pointers where to look at this - as I am not a programmer at all, just know markup well and not afraid to experiment ;-) > If you base it around standard nodes, you don't need cck. views is > automatic. Theming as well, unless you want a custom look, which is > sightly more complicated, but quite straight forward. The docs team has > done a good job, really. OK - I will look at it and report over the weekend. >> >> That way files can be commented on, searched for and >> >> can have notes on versions >> > Only if you can extract text from the files. You still could do taxonomy based queries. >> >> just few words would be sufficient > Well, you need something to put those words into the search table. You need something > to extract them from your files - doc, pdf, whatever.... Drupal by default doesn't > know anything but their name and size and that is not in the search table. well I was thinking to use free tagging instead of proper file search > I would be happy to update docs, but i will possibly have a week or so > free(ish) towards the middle of July. Before that it is busy, busy, > busy. If anyone wants to help out with the module or become a > co-maintainer/maintainer, just shout. We can sync via email and irc. If I get stuck with this problem myself I will be able to help with testing your beta code otherwise I will try to take a vacation on 18th ;-) > Cheers, > Vlado Cheers :-) From zblace at gmail.com Wed Jun 25 15:30:06 2008 From: zblace at gmail.com (zeljko blace) Date: Wed, 25 Jun 2008 17:30:06 +0200 Subject: [development] internal messaging among users for Drupal 6.x? In-Reply-To: <3adc77210806250641g785318fawa69ed165a4c60f2d@mail.gmail.com> References: <3adc77210806250641g785318fawa69ed165a4c60f2d@mail.gmail.com> Message-ID: On Wed, Jun 25, 2008 at 3:41 PM, Naheem Zaffar wrote: > There is some work being done in the privatemsg module. It is not > ready for prime time yet, but it should be Real Soon(TM). Can I track progress somewhere? > (the drupal-6.x version is I think a completely new implementation and > does not use much of the 5.x code.) I see. From winborn at advomatic.com Wed Jun 25 15:35:37 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 25 Jun 2008 11:35:37 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080625095425.28t2ltoxfq6ock88@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> Message-ID: <486265C9.1000608@advomatic.com> Then if developers (such as myself, but not only myself) are using module_invoke as a safe method to invoke a module's "public" API function, then perhaps we need to create a comparable safe and easy method, rather than calling said developers "lazy". (The lazy method, indeed, would be simply calling the function directly.) Perhaps module_invoke_api or module_call_function would be in order. As Drupal evolves, more and more modules will provide an API available for use by other modules. In fact, there are already several such modules, such as getID3, Voting API, and others, which do nothing but provide glue for other modules to work with. We need to encourage this cooperation, and if not provide an easy and safe method for invoking a function in an API, at least document a best practice. Earnie Boyd wrote: > Quoting Chris Johnson : > >> module_invoke() is used to call core API functions in a special core API >> class called hooks. If your function is not part of the core API, then >> using module_invoke to call it is misleading. Misleading code is a >> maintenance problem. Some day, the functionality of module_invoke() may >> change and not work correctly to call random contributed module >> functions. >> It will always work to call hooks, however. Hence, by definition, it is >> wrong to use it for a purpose it was not meant. >> > > Correct, and stating it like Chris has said we can go as far to say > that module_invoke is a private core function reserved for the use of > the hooks class. Modules themselves should not use it unless the > module has created a hook and needs to call other modules > implementations of that hook. > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/ > From earnie at users.sourceforge.net Wed Jun 25 15:56:53 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 25 Jun 2008 11:56:53 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <486265C9.1000608@advomatic.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> Message-ID: <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> Quoting Aaron Winborn : > at least document a best practice. > mymod.info dependencies = urmod mymod.module $mymod_bar = urmod_foo(); Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From naheemzaffar at gmail.com Wed Jun 25 15:57:12 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Wed, 25 Jun 2008 16:57:12 +0100 Subject: [development] internal messaging among users for Drupal 6.x? In-Reply-To: References: <3adc77210806250641g785318fawa69ed165a4c60f2d@mail.gmail.com> Message-ID: <3adc77210806250857p448c8c1eid9f4fcf90d083940@mail.gmail.com> 2008/6/25 zeljko blace : > On Wed, Jun 25, 2008 at 3:41 PM, Naheem Zaffar wrote: >> There is some work being done in the privatemsg module. It is not >> ready for prime time yet, but it should be Real Soon(TM). > > Can I track progress somewhere? > http://drupal.org/project/privatemsg http://drupal.org/node/202348 for port to drupal 6 /restart of module. 6.x-1.x-dev nightly: http://drupal.org/node/268824 The module does need a few more eyes on there, but I do suspect that it will become very useful within a short period of time. (Disclaimer: I am not its developer.) There is also a pm_lite module out there, no idea what state that is in. From kb at 2bits.com Wed Jun 25 16:02:10 2008 From: kb at 2bits.com (Khalid Baheyeldin) Date: Wed, 25 Jun 2008 12:02:10 -0400 Subject: [development] internal messaging among users for Drupal 6.x? In-Reply-To: References: <3adc77210806250641g785318fawa69ed165a4c60f2d@mail.gmail.com> Message-ID: <4a9fdc630806250902v5e585cd2qd40f7dd3e82984b2@mail.gmail.com> Zeljko The development list is not the correct place for these questions. The development list is for development type questions only (code, ...etc.) that do not fit in a specific issue queue. Do not cross post questions from support to development. On Wed, Jun 25, 2008 at 11:30 AM, zeljko blace wrote: > On Wed, Jun 25, 2008 at 3:41 PM, Naheem Zaffar > wrote: > > There is some work being done in the privatemsg module. It is not > > ready for prime time yet, but it should be Real Soon(TM). > > Can I track progress somewhere? > > > (the drupal-6.x version is I think a completely new implementation and > > does not use much of the 5.x code.) > > I see. > -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080625/728c974c/attachment-0001.htm From winborn at advomatic.com Wed Jun 25 16:01:59 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 25 Jun 2008 12:01:59 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> Message-ID: <48626BF7.8050000@advomatic.com> Doesn't work in many cases. I frequently build modules with optional dependencies. Even with your set up, we're assuming a module's api stays the same within a core version, which is frequently not true. There's no easy answer for the first case, other than bloating your code with additional drupal_function_exists checks, and the second would require tracking module version (at least its major version). Earnie Boyd wrote: > Quoting Aaron Winborn : > >> at least document a best practice. >> > > mymod.info > dependencies = urmod > > mymod.module > $mymod_bar = urmod_foo(); > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/ > From winborn at advomatic.com Wed Jun 25 16:14:14 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Wed, 25 Jun 2008 12:14:14 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <48626BF7.8050000@advomatic.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> Message-ID: <48626ED6.5090905@advomatic.com> How about: mymod.info dependencies[] = taxonomy, someothermod 1.x, urmod optional_dependencies[] = optionalmod 2.x mymod.module $mymod_bar = module_call('optionalmod', 'cool_function', $args); if (isset($mymod_bar)) { $mymod_foo = module_invoke('urmod', 'some_hook', $mymod_bar); } Aaron Winborn wrote: > Doesn't work in many cases. I frequently build modules with optional > dependencies. Even with your set up, we're assuming a module's api > stays the same within a core version, which is frequently not true. > > There's no easy answer for the first case, other than bloating your > code with additional drupal_function_exists checks, and the second > would require tracking module version (at least its major version). > > Earnie Boyd wrote: >> Quoting Aaron Winborn : >> >>> at least document a best practice. >>> >> >> mymod.info >> dependencies = urmod >> >> mymod.module >> $mymod_bar = urmod_foo(); >> >> Earnie -- http://for-my-kids.com/ >> -- http://give-me-an-offer.com/ >> > From damz at prealable.org Wed Jun 25 16:43:26 2008 From: damz at prealable.org (Damien) Date: Wed, 25 Jun 2008 18:43:26 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <48626ED6.5090905@advomatic.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> <48626ED6.5090905@advomatic.com> Message-ID: On Wed, Jun 25, 2008 at 6:14 PM, Aaron Winborn wrote: > mymod.module > $mymod_bar = module_call('optionalmod', 'cool_function', $args); > if (isset($mymod_bar)) { > $mymod_foo = module_invoke('urmod', 'some_hook', $mymod_bar); > } > Again, I do not see the point of module_call if you can do: if (drupal_function_exists('cool_function')) { $mymod_bar = cool_function($args); } Advantages? - It is cleaner and faster - It does not add a new level of indirection - It makes reference tracking works (such as what is done on api.drupal.org) Moreover, you can do correct error management: if (drupal_function_exists()) { } else { } Damien -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080625/64c70b2f/attachment.htm From adrian at bryght.com Wed Jun 25 17:06:33 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Wed, 25 Jun 2008 19:06:33 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <48626BF7.8050000@advomatic.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> Message-ID: <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote: > > There's no easy answer for the first case, other than bloating your > code with additional drupal_function_exists checks, and the second > would require tracking module version (at least its major version). we need this anyway. badly. From earnie at users.sourceforge.net Wed Jun 25 18:58:37 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Wed, 25 Jun 2008 14:58:37 -0400 Subject: [development] module version tracking [WAS: module_exists vs. functions_exists?] In-Reply-To: <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> Message-ID: <20080625145837.0coxv0lli8m8gk08@mail.progw.org> Quoting Adrian Rossouw : > > On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote: > >> >> There's no easy answer for the first case, other than bloating your >> code with additional drupal_function_exists checks, and the second >> would require tracking module version (at least its major version). > we need this anyway. > Now this I agree with. But we could development a MOP to handle this easily enough. Something like define('MYMOD_VERSION', '2.x') but be good enough for that. > badly. > The other option is to read the module.info file and grab the version info from it. The version info is appended to the file by the packaging script and could be easily parsed using the PHP function parse_ini_file; like $urmod_info = parse_ini_file('/path/to/urmod/urmod.info'). Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From adrian at bryght.com Wed Jun 25 19:05:08 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Wed, 25 Jun 2008 21:05:08 +0200 Subject: [development] module version tracking [WAS: module_exists vs. functions_exists?] In-Reply-To: <20080625145837.0coxv0lli8m8gk08@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <00f601c8d530$308ef1c0$0200a8c0@structworks.com> <20080623115831.rkqmp5t3dq0wsgok@mail.progw.org> <010b01c8d54f$9ba602e0$0200a8c0@structworks.com> <20080623135929.q7888mrnil7kkk4c@mail.progw.org> <18092252.post@talk.nabble.com> <20080624134821.8u3mxxqjyvb40kgg@mail.progw.org> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> <20080625145837.0coxv0lli8m8gk08@mail.progw.org> Message-ID: <639081A2-FAF7-4F41-8391-9797D692B57C@bryght.com> On 25 Jun 2008, at 8:58 PM, Earnie Boyd wrote: > > Now this I agree with. But we could development a MOP to handle > this easily enough. Something like define('MYMOD_VERSION', '2.x') > but be good enough for that. http://php.net/version_compare i actually think we need something a bit more severe, tho it's probably out of spec for D7. ie : versioned content types (from cck) and views. so you can have a module require a specific version of a view. From catch56 at googlemail.com Wed Jun 25 19:07:46 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 25 Jun 2008 20:07:46 +0100 Subject: [development] module version tracking [WAS: module_exists vs. functions_exists?] In-Reply-To: <20080625145837.0coxv0lli8m8gk08@mail.progw.org> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> <20080625145837.0coxv0lli8m8gk08@mail.progw.org> Message-ID: Adrian and Earnie wrote: >>> There's no easy answer for the first case, other than bloating your code >>> with additional drupal_function_exists checks, and the second would require >>> tracking module version (at least its major version). >>> >> we need this anyway >> > > badly. >> >> > The other option is to read the module.info file and grab the version info > from it. There's already a patch for this here, crying out for some attention : http://drupal.org/node/211747 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080625/f5fbad92/attachment.htm From darrel.opry at gmail.com Thu Jun 26 01:40:30 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Wed, 25 Jun 2008 21:40:30 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> Message-ID: On Wed, Jun 25, 2008 at 1:06 PM, Adrian Rossouw wrote: > > On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote: > > >> There's no easy answer for the first case, other than bloating your code >> with additional drupal_function_exists checks, and the second would require >> tracking module version (at least its major version). >> > we need this anyway. > > badly. drupal_function_exists or module version tracking? I know it would be great to have it centralized, but currently requirement checking can be done in hook_requirements.. although it would be nice to have some automagic in .info for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080625/5ba26cea/attachment-0001.htm From dries.buytaert at gmail.com Thu Jun 26 07:08:48 2008 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu, 26 Jun 2008 09:08:48 +0200 Subject: [development] Code freeze? In-Reply-To: <200806241636.19350.drupal.beginner@wechange.org> References: <200806241636.19350.drupal.beginner@wechange.org> Message-ID: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> I've been thinking about this some. While we have made incredible progress with the test infrastructure as well as implemented a dozen of usability improvements, we're still light on feature improvements (such as fields in core). Combined with the late arrival of CCK and Views, and the many Drupal 6 books that are currently being written, it sounds best to postpone the code freeze a little longer. Given the current state of things, the proposed July 15 deadline seems a bit too aggressive to my liking. If people are supportive to the idea of pushing back the code freeze date, I'll write up an announcement. Thanks, On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote: > Hi, > > What is the latest news about the D7 code freeze. I haven't seen any > announcement on this list. Do we have a date for the code freeze, or > at least a better estimate than what was offered at the beginning of > the thaw? > > > thanks, > > Augustin. -- Dries Buytaert :: http://buytaert.net From shai at content2zero.com Thu Jun 26 07:29:55 2008 From: shai at content2zero.com (Shai Gluskin) Date: Thu, 26 Jun 2008 03:29:55 -0400 Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <9f68efb70806260029x373d5386i83f924defe6f5437@mail.gmail.com> Dries and all, Great news! I think it is only natural that Drupal's success will lead to slower development cycles. Most Drupal shops will only begin creating Drupal 6 production sites this summer. There will be so much learned from creating productrion sites in 6. That learning should be taken into account when coding for 7. In my opinion, what is key for Drupal to stay true to its core values is that major upgrades remain open to significantly changing APIs where they lead to improvements in the platform. That will keep Drupal fresh and compelling. There don't need to be yearly major releases to keep Drupal fresh. I can also imagine that it might be in Acquia's interest to slow down development cycles. Though Acquia's interests may not always be the same as Drupal's, I think often they are. I don't think there is anything wrong with adjusting development cycles or other plans based on Acquia's interests. I know you didn't a mention a date for the code freeze. I'd vote for Spring of '09. Shai On Thu, Jun 26, 2008 at 3:08 AM, Dries Buytaert wrote: > I've been thinking about this some. While we have made incredible progress > with the test infrastructure as well as implemented a dozen of usability > improvements, we're still light on feature improvements (such as fields in > core). > > Combined with the late arrival of CCK and Views, and the many Drupal 6 > books that are currently being written, it sounds best to postpone the code > freeze a little longer. Given the current state of things, the proposed > July 15 deadline seems a bit too aggressive to my liking. > > If people are supportive to the idea of pushing back the code freeze date, > I'll write up an announcement. > > Thanks, > > On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote: > >> Hi, >> >> What is the latest news about the D7 code freeze. I haven't seen any >> announcement on this list. Do we have a date for the code freeze, or >> at least a better estimate than what was offered at the beginning of >> the thaw? >> >> >> thanks, >> >> Augustin. >> > > > > -- > Dries Buytaert :: http://buytaert.net > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/2f7b3ff3/attachment.htm From hielema at gmail.com Thu Jun 26 07:52:06 2008 From: hielema at gmail.com (Folkert Hielema) Date: Thu, 26 Jun 2008 09:52:06 +0200 Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <48634AA6.80201@gmail.com> +1 for postpone code freeze D7 Thanks, Folkert Hielema Dries Buytaert wrote: > I've been thinking about this some. While we have made incredible > progress with the test infrastructure as well as implemented a dozen > of usability improvements, we're still light on feature improvements > (such as fields in core). > > Combined with the late arrival of CCK and Views, and the many Drupal 6 > books that are currently being written, it sounds best to postpone the > code freeze a little longer. Given the current state of things, the > proposed July 15 deadline seems a bit too aggressive to my liking. > > If people are supportive to the idea of pushing back the code freeze > date, I'll write up an announcement. > > Thanks, > > On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote: >> Hi, >> >> What is the latest news about the D7 code freeze. I haven't seen any >> announcement on this list. Do we have a date for the code freeze, or >> at least a better estimate than what was offered at the beginning of >> the thaw? >> >> >> thanks, >> >> Augustin. > > > > -- > Dries Buytaert :: http://buytaert.net > > > > > From darrel.opry at gmail.com Thu Jun 26 08:13:41 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Thu, 26 Jun 2008 04:13:41 -0400 Subject: [development] Code freeze? In-Reply-To: <48634AA6.80201@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <48634AA6.80201@gmail.com> Message-ID: I haven't even caught up to D6.... D7 can totally wait on freeze... no need to put the cart in front of the horse as the saying goes. On Thu, Jun 26, 2008 at 3:52 AM, Folkert Hielema wrote: > +1 for postpone code freeze D7 > > Thanks, > > Folkert Hielema > > > Dries Buytaert wrote: > >> I've been thinking about this some. While we have made incredible >> progress with the test infrastructure as well as implemented a dozen of >> usability improvements, we're still light on feature improvements (such as >> fields in core). >> >> Combined with the late arrival of CCK and Views, and the many Drupal 6 >> books that are currently being written, it sounds best to postpone the code >> freeze a little longer. Given the current state of things, the proposed >> July 15 deadline seems a bit too aggressive to my liking. >> >> If people are supportive to the idea of pushing back the code freeze date, >> I'll write up an announcement. >> >> Thanks, >> >> On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote: >> >>> Hi, >>> >>> What is the latest news about the D7 code freeze. I haven't seen any >>> announcement on this list. Do we have a date for the code freeze, or >>> at least a better estimate than what was offered at the beginning of >>> the thaw? >>> >>> >>> thanks, >>> >>> Augustin. >>> >> >> >> >> -- >> Dries Buytaert :: http://buytaert.net >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/d5910065/attachment.htm From karoly at negyesi.net Thu Jun 26 08:59:42 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu, 26 Jun 2008 10:59:42 +0200 (CEST) Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: > If people are supportive to the idea of pushing back the code freeze > date, I'll write up an announcement. http://buytaert.net/drupal-7-timeline has a later November 15, 2008 freeze date if we are doing good in testing. We do! And during DrupalCon http://szeged2008.drupalcon.org/sessions/testing-part-2-awesome-testing-party we shall have a testing writing party for more awesomeness. However, I would like to suggest an even later freeze. The need for supporting Drupal 5 longer than usual has been raised and it would be a simple solution if we simply would push the projected release to next summer. There is no rush: Drupal 5 and Drupal 6 are fine releases, much more so than anything before, they perfectly can carry the Druplicon flag proudly for another year. This was less so with earlier releases, unlike with previous Drupals I feel no pressing need of dropping support as soon as feasible. While one could say this is just hubris on my side because I am more deeply involved with these releases, I hope this is not so, my involvement in Drupal 4.7 was also quite significant (I think more so than Drupal 5) and yet I was very happy when the support for that got dropped... I recommend adding some usability enhancements to Drupal 6 meanwhile. It can be said that some of these are bugfixes, as in, UI bugs :) and the usual argument against backports is that people will be less eager to up to the next release -- I would like to see Drupal 7 be so much faster (because so much less code is loaded) that people will rush to it. Regards Karoly Negyesi From fsteiner-mail1 at bio.ifi.lmu.de Thu Jun 26 08:46:40 2008 From: fsteiner-mail1 at bio.ifi.lmu.de (Frank Steiner) Date: Thu, 26 Jun 2008 10:46:40 +0200 Subject: [development] Extending menu objects to store node translations Message-ID: <48635770.9030400@bio.ifi.lmu.de> Hi, I would like to discuss if menu objects could be extended to store pointers to a node and all of its translations. Some other people but me would like to see that, too, see http://drupal.org/node/230868 Why could such menus make sense? At our site most stuff is language neutral because as long as we don't have e.g. a translation of the english research site, we show it for all languages. But for the teaching sites, we need english and german versions. But we have nodes with menu entries and those menu entries have children. A menu looks like "Programming Course A" |- Material for Practice 1 |- Material for Practice 2 ... The "Material pages" just contain code snippets or PDFs for download, they don't have lot of text, so they don't have to exist for two languages. The nodes are language neutral. But the "Programming Course A" node contains a lot of explanations so it must exist in english and german. The problem is clear: When I translate this node I must give the translation a new menu item "Programmierung Kurs A" so that a menu item appears when switching the language. But then the whole "Material" subtree is gone for this new menu item. So I would have to create translations for all "Material" nodes, attach the attachments once again and put all those translated nodes below "Programmierung Kurs A". Useless, since the "Material" nodes wouldn't change but just be duplicated. What I would like to have is a menu object that can store pointers to the translated versions of the node it points to, too. Then when swichting the language, the menu system could check if a translated version for the nodes exists and keep showing the menu item. If the menu string was localized, it could display the translated version (as works already). This way, the "Material" subtree would stay because all translated nodes would have the same single menu item. This wouldn't be hard to do. With changing a bit of code in the i18n menu, I already achieved that the menu item changes its href to the path of the translated node, so with translating the menu string, the menu item "Programming Course A" pointing to "node/xx" changed to "Programmierung Kurs A" and points to "node/yy". The only problem: When I'm viewing the translated node, the function menu_tree_page_data in menu.inc rebuilds the tree by searching for the menu object of the node it currently shows. Since the translated node doesn't have an own menu item, menu_tree_page_data shows the "Programming Course A"/"Programmierung Kurs A" item but doesn't unfold its subtree because it doesn't realize it is connected to the current node. I think all that would be neccessary for a conservative extension not destroying anything else was extending the menu object by another array to store the links to the translated nodes. When translating nodes, you could have a checkbox to "reuse the menu item" or sth. menu_tree_page_data would just have to check that array, too, when looking for connections between the currently showing node and the menu system. I consider hacking this for our own site, but I would like to know if there are chances that the menu system could be extended this was for drupal 7. What do you think about the idea? cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * From catch56 at googlemail.com Thu Jun 26 09:36:44 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Thu, 26 Jun 2008 10:36:44 +0100 Subject: [development] Code freeze? In-Reply-To: References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: I'd also like to see a much later code freeze. At least November 15th - but the first half of next year also sounds good. Testing has come a long way, but time spent on that has slowed down development of features (and in my own case time spent using D6 and helping get modules upgraded for that) - on my part this is betting on a longer D7 release cycle, so there'll be a longer period to get these things in later - so I really hope that plays off... There are also Summer of Code projects which directly impact quite neglected parts of core (new help system, new aggregator etc.) - delaying the code freeze might give these a chance to develop into core patches - but it'll be a long wait to get them into Drupal 8. Since testing is generally working to keep things pretty stable, we should be able to have a much, much shorter freeze/beta/rc period - and much less incentive for people to try to push patches in at the last minute. And there's no D7 maintainer yet - wouldn't be fair to only let them commit patches during code freeze would it? Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/5bbc5b2c/attachment.htm From tz at it-arts.org Thu Jun 26 09:33:42 2008 From: tz at it-arts.org (Thomas Zahreddin) Date: Thu, 26 Jun 2008 11:33:42 +0200 Subject: [development] module_exists vs. functions_exists? In-Reply-To: References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com><37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net><9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com><20080625095425.28t2ltoxfq6ock88@mail.progw.org><486265C9.1000608@advomatic.com><20080625115653.vn8qm7akwjk0gkws@mail.progw.org><48626BF7.8050000@advomatic.com><01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> Message-ID: Reading this thread, i ask myself and you why not using a established package format like RPM http://en.wikipedia.org/wiki/RPM_Package_Manager , deb-format or some other out of the linux - environment, compared on http://kitenet.net/~joey/pkg-comp/ Or if you are afraid of high complexity and efford to support such a format on all plattforms - then give the PEAR-or PECL-format a chance. I don't want to say any of these formats meets the requirements, but i did not have seen this formats discussed. What do you think about an more generaly used format for Drupal-packages? Best Thomas Zahreddin Kr?zastr. 18/15 A-6912 H?rbranz T. +49 89 420951948 o. +43 5573 83048 F. +49 89 420951948-9 mailto:tz at it-arts.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/3c81b645/attachment.htm From rob at robshouse.net Thu Jun 26 10:04:00 2008 From: rob at robshouse.net (Robert Douglass) Date: Thu, 26 Jun 2008 12:04:00 +0200 Subject: [development] Code freeze? In-Reply-To: References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: Just to confirm what seems like an overwhelmingly unified sentiment: a later D7 seems like a good thing. We started a bunch of work on the search system at the search sprint in Minnesota and I'd really like to see the bulk of it get finished. Yet I'm still sitting on relatively popular modules that I have to upgrade to D6 and I can't help but think that they are a bigger priority for me at the moment. Delaying the date of the code freeze just seems like the right thing. - Robert On Jun 26, 2008, at 11:36 AM, Nathaniel Catchpole wrote: > I'd also like to see a much later code freeze. At least November > 15th - but the first half of next year also sounds good. > > Testing has come a long way, but time spent on that has slowed down > development of features (and in my own case time spent using D6 and > helping get modules upgraded for that) - on my part this is betting > on a longer D7 release cycle, so there'll be a longer period to get > these things in later - so I really hope that plays off... > > There are also Summer of Code projects which directly impact quite > neglected parts of core (new help system, new aggregator etc.) - > delaying the code freeze might give these a chance to develop into > core patches - but it'll be a long wait to get them into Drupal 8. > > Since testing is generally working to keep things pretty stable, we > should be able to have a much, much shorter freeze/beta/rc period - > and much less incentive for people to try to push patches in at the > last minute. > > And there's no D7 maintainer yet - wouldn't be fair to only let them > commit patches during code freeze would it? > > Nat > > From karoly at negyesi.net Thu Jun 26 10:48:31 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu, 26 Jun 2008 12:48:31 +0200 (CEST) Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: > If people are supportive to the idea of pushing back the code freeze > date, I'll write up an announcement. http://buytaert.net/drupal-7-timeline has a later November 15, 2008 freeze date if we are doing good in testing. We do! And during DrupalCon http://szeged2008.drupalcon.org/sessions/testing-part-2-awesome-testing-party we shall have a testing writing party for more awesomeness. However, I would like to suggest an even later freeze. The need for supporting Drupal 5 longer than usual has been raised and it would be a simple solution if we simply would push the projected release to next summer. There is no rush: Drupal 5 and Drupal 6 are fine releases, much more so than anything before, they perfectly can carry the Druplicon flag proudly for another year. This was less so with earlier releases, unlike with previous Drupals I feel no pressing need of dropping support as soon as feasible. While one could say this is just hubris on my side because I am more deeply involved with these releases, I hope this is not so, my involvement in Drupal 4.7 was also quite significant (I think more so than Drupal 5) and yet I was very happy when the support for that got dropped... I recommend adding some usability enhancements to Drupal 6 meanwhile. It can be said that some of these are bugfixes, as in, UI bugs :) and the usual argument against backports is that people will be less eager to up to the next release -- I would like to see Drupal 7 be so much faster (because so much less code is loaded) that people will rush to it. Regards Karoly Negyesi From dries.buytaert at gmail.com Thu Jun 26 11:57:55 2008 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu, 26 Jun 2008 13:57:55 +0200 Subject: [development] Code freeze? In-Reply-To: References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> On 26 Jun 2008, at 12:48, Karoly Negyesi wrote: > http://buytaert.net/drupal-7-timeline has a later November 15, 2008 > freeze date if we are doing good in testing. We do! And during > DrupalCon http://szeged2008.drupalcon.org/sessions/testing-part-2-awesome-testing-party > we shall have a testing writing party for more awesomeness. I do think we're doing great work on testing. I've been committing testing related patches on a (almost) daily basis. That's pretty sweet. That said, we aren't able to measure our test coverage yet. In other words, it's really hard to tell how well we actually do. Any updates on that? -- Dries Buytaert :: http://buytaert.net From work at wimleers.com Thu Jun 26 12:03:42 2008 From: work at wimleers.com (Wim Leers) Date: Thu, 26 Jun 2008 14:03:42 +0200 Subject: [development] Code freeze? In-Reply-To: References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> Here's another confirmation of that seemingly unified sentiment. It seems to me nobody has had enough time to *really* start working with D6. I also still have to port several relatively popular modules, and for me too, they are a higher priority than contributing to D7. So, I'm also for a delay of the code freeze. Wim Leers ~ http://wimleers.com/work On Jun 26, 2008, at 12:04 , Robert Douglass wrote: > Just to confirm what seems like an overwhelmingly unified sentiment: > a later D7 seems like a good thing. We started a bunch of work on > the search system at the search sprint in Minnesota and I'd really > like to see the bulk of it get finished. Yet I'm still sitting on > relatively popular modules that I have to upgrade to D6 and I can't > help but think that they are a bigger priority for me at the moment. > Delaying the date of the code freeze just seems like the right thing. > > - Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080626/1616930f/attachment-0001.bin From winborn at advomatic.com Thu Jun 26 13:18:08 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Thu, 26 Jun 2008 09:18:08 -0400 Subject: [development] Code freeze? In-Reply-To: <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> Message-ID: <48639710.2080803@advomatic.com> Yes, this is great news. I feel like all I'm doing is trying to catch up with module upgrades, and was worried I'd miss out on really diving into d7 before its code freeze. The only sadness I feel is the inevitable wait on hook_file. On the flip side, it would give some time for some experimentation with hook_file on the contrib side, which would hopefully allow contributors to make use of that feature and others closer to its launch. Drupal 6 will have time to mature, and Drupal 7 will be a more solid launch for it. Wim Leers wrote: > Here's another confirmation of that seemingly unified sentiment. It > seems to me nobody has had enough time to *really* start working with > D6. I also still have to port several relatively popular modules, and > for me too, they are a higher priority than contributing to D7. So, > I'm also for a delay of the code freeze. > > Wim Leers ~ http://wimleers.com/work > > > > On Jun 26, 2008, at 12:04 , Robert Douglass wrote: > >> Just to confirm what seems like an overwhelmingly unified sentiment: >> a later D7 seems like a good thing. We started a bunch of work on the >> search system at the search sprint in Minnesota and I'd really like >> to see the bulk of it get finished. Yet I'm still sitting on >> relatively popular modules that I have to upgrade to D6 and I can't >> help but think that they are a bigger priority for me at the moment. >> Delaying the date of the code freeze just seems like the right thing. >> >> - Robert From sirkitree at gmail.com Thu Jun 26 13:23:48 2008 From: sirkitree at gmail.com (Jerad Bitner) Date: Thu, 26 Jun 2008 09:23:48 -0400 Subject: [development] Code freeze? In-Reply-To: <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> Message-ID: <215a89c90806260623v4e3fdfedg476fb2e5a8719bb7@mail.gmail.com> Agreed on the later code freeze, and I definitely think next summer is not unreasonable. Coming from an in-house shop with large installations who are struggling to get a D6 upgrade still in the works almost solely because D5 might not be supported (okay the cooler features of the framework are a huge incentive to the devs) it's slightly intimidating to think that there already be a code freeze on the next version of Drupa when we *might* have D6 upgrades done by the end of October. Many modules have still not caught up (mine being some of them) making it very hard to get full platforms up to speed with D6. So yes, many reasons from an in-house perspective to have longer development periods. +3 (taking into account my colleages aren't on this list but feel the same). On Thu, Jun 26, 2008 at 8:03 AM, Wim Leers wrote: > Here's another confirmation of that seemingly unified sentiment. It seems > to me nobody has had enough time to *really* start working with D6. I also > still have to port several relatively popular modules, and for me too, they > are a higher priority than contributing to D7. So, I'm also for a delay of > the code freeze. > > Wim Leers ~ http://wimleers.com/work > > > > > On Jun 26, 2008, at 12:04 , Robert Douglass wrote: > > Just to confirm what seems like an overwhelmingly unified sentiment: a >> later D7 seems like a good thing. We started a bunch of work on the search >> system at the search sprint in Minnesota and I'd really like to see the bulk >> of it get finished. Yet I'm still sitting on relatively popular modules that >> I have to upgrade to D6 and I can't help but think that they are a bigger >> priority for me at the moment. Delaying the date of the code freeze just >> seems like the right thing. >> >> - Robert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/07277302/attachment.htm From matt at cabinetuk.com Thu Jun 26 13:23:49 2008 From: matt at cabinetuk.com (Matt Connolly) Date: Thu, 26 Jun 2008 14:23:49 +0100 Subject: [development] Bug in profile.module for new users Message-ID: <0AB6B911-099B-4ED8-9D3C-6D411F68F0D3@cabinetuk.com> I've discovered a bug that is manifesting itself in the "profile.module" when new users are created via my remote authentication module. My module calls user_external_login_register, which calls user_load which calls user_module_invoke with $type = "insert" which calls profile_user which calls profile_save_profle which calls _profile_get_fields which calls user_access And this is where the problem is. The user is still being created, and calling user_access creates a bad sql query and presents a whole bunch of warnings to the user when their account is created. Attached is a patch, which removes the problem. But I wanted to know whether the problem is really in the profile.module (_profile_get_fields) or in the user.module (user_access) ?? Any thoughts? -Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: profile-module.patch Type: application/octet-stream Size: 787 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080626/04343220/attachment.obj -------------- next part -------------- From cxjohnson at gmail.com Thu Jun 26 13:29:29 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Thu, 26 Jun 2008 08:29:29 -0500 Subject: [development] Code freeze? In-Reply-To: <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> Message-ID: <9ea8d6030806260629q187d5dc9r6f3983fe42c02c0a@mail.gmail.com> Since chx is in favor of a delay, I can support that idea, too. ;-) Seriously, how about a freeze date of January 15, 2009? -- ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/b219662e/attachment.htm From jvandyk at iastate.edu Thu Jun 26 13:30:56 2008 From: jvandyk at iastate.edu (John VanDyk) Date: Thu, 26 Jun 2008 08:30:56 -0500 Subject: [development] Bug in profile.module for new users In-Reply-To: <0AB6B911-099B-4ED8-9D3C-6D411F68F0D3@cabinetuk.com> References: <0AB6B911-099B-4ED8-9D3C-6D411F68F0D3@cabinetuk.com> Message-ID: See http://drupal.org/node/208911 http://drupal.org/node/208888 >I've discovered a bug that is manifesting itself in the >"profile.module" when new users are created via my remote >authentication module. > >My module calls user_external_login_register, >which calls user_load >which calls user_module_invoke with $type = "insert" >which calls profile_user >which calls profile_save_profle >which calls _profile_get_fields >which calls user_access > >And this is where the problem is. The user is still being created, >and calling user_access creates a bad sql query and presents a whole >bunch of warnings to the user when their account is created. > >Attached is a patch, which removes the problem. But I wanted to know >whether the problem is really in the profile.module >(_profile_get_fields) or in the user.module (user_access) ?? > >Any thoughts? > >-Matt > > >Attachment converted: Scutigera:profile-module.patch ( / ) (0057D6FB) From nan_wich at bellsouth.net Thu Jun 26 13:36:47 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Thu, 26 Jun 2008 09:36:47 -0400 Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: Dries Buytaert wrote: > If people are supportive to the idea of pushing back the code freeze > date, I'll write up an announcement. I agree that there is still considerable resistance to D6, so let's not push D7 so hard. However, there is a side note to this that I would love to see more heavily pushed: I am still getting module issues related to PHP 4 (even 4.3) and MySql 4. And the users are saying they don't want to push their hosts to upgrade. I really would like to see a lot more emphasis on getting hosting companies ready now, rather than later. In every issue I have where infrastructure releases may be involved, I point out the need to upgrade. But I seem to be the only one who is pointing this out to them. It's going to take some hosting companies a while to get updated, so we need to be pushing this now - even for a first of 2009 roll-out. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1519 - Release Date: 6/25/2008 4:13 PM From drupal-devel at webchick.net Thu Jun 26 13:56:52 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Thu, 26 Jun 2008 09:56:52 -0400 Subject: [development] Code freeze? In-Reply-To: <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> Message-ID: <4863A024.2050307@webchick.net> Dries Buytaert wrote: > I do think we're doing great work on testing. I've been committing > testing related patches on a (almost) daily basis. That's pretty sweet. Like catch and others, I've been dumping basically all the time I have available to work on D7 on testing stuff, in the hopes that it will help extend the code freeze out to when I will have much MORE time to dump into D7 in the fall. ;) > That said, we aren't able to measure our test coverage yet. In other > words, it's really hard to tell how well we actually do. Any updates on > that? I think that our current test coverage by conventional tools is going to be close to 0%. It's also clear that the community has not in fact "embraced testing." Instead, a hardcore group of around 15-20 people (the "testing brigade" ;)) have, and are driving this effort forward on behalf of the rest of the development team. I also think that both of these situations are okay right now. Because what the "testing brigade" has been focusing on is: 1. Improvement of testing tools. For example, that Batch API patch that was just committed I think is the *key* turning point that will make testing something that can be done by normal humans rather than just the "testing brigade." 2. Fixing of existing tests. Back when I wrote http://webchick.net/itch-of-the-week/fix-testing-crisis, we were in pretty sorry shape in this regard. I remember growing the critical bug queue by at least 20 in one night documenting all the tests that didn't pass. Now, we're down to 3 failing tests as of this morning. 3. Improving coverage of tests that run through the end-user experience via the browser. This helps save our reviewers from getting carpal tunnel clicking on forms to ensure that the basic system is running properly while they're testing a patch. 4. Developing testing guidelines, best practices. We're not totally there yet, but a fairly large amount of time has been spent on things like documentation, clean-up of tests so that they all follow basically the same conventions, etc. This type of work is important to getting new developers on the testing train. However, all of this "clean-up" work has come at the expense of dramatically increasing our testing coverage. But I actually think that it would've been way too premature to dump a bunch of time into increasing our test coverage while the above 4 points were outstanding. My goal is for the "Awesome Testing Party" at Drupalcon Szeged (if it gets accepted) to help a lot in this regard. -Angie From syscrusher at 4th.com Thu Jun 26 14:54:43 2008 From: syscrusher at 4th.com (Syscrusher) Date: Thu, 26 Jun 2008 10:54:43 -0400 Subject: [development] Code freeze? In-Reply-To: <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <02173E44-2B99-4C8E-B7A1-FF595D8B923E@wimleers.com> Message-ID: <1214492083.20835.242.camel@marcus> On Thu, 2008-06-26 at 14:03 +0200, Wim Leers wrote: > Here's another confirmation of that seemingly unified sentiment. It > seems to me nobody has had enough time to *really* start working > with > D6. I also still have to port several relatively popular modules, > and > for me too, they are a higher priority than contributing to D7. So, > I'm also for a delay of the code freeze. Likewise for me. I've been so busy converting my company's internal-use modules (customized for our accounting environment, not useful to the community) that I'm behind schedule on my GPL modules. They're in work, but not yet done. Luckily once I'm done with the internal ones, my boss says I can do the GPL ones on company time as "independent R&D work". I've found Drupal 6 to be a really terrific release, and would be happy to see it remain current for a while as we work on an equally terrific and compelling D7 behind the scenes. Better a fantastic release in 18 months than a pretty-good release in 12, in my opinion. +1 for delaying the freeze. Scott -- Syscrusher From larry at garfieldtech.com Thu Jun 26 15:08:38 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Thu, 26 Jun 2008 10:08:38 -0500 Subject: [development] =?utf-8?q?Code_freeze=3F?= In-Reply-To: References: Message-ID: On Thu, 26 Jun 2008 09:36:47 -0400, "Nancy Wichmann" wrote: > Dries Buytaert wrote: > >> If people are supportive to the idea of pushing back the code freeze >> date, I'll write up an announcement. > > I agree that there is still considerable resistance to D6, so let's not > push > D7 so hard. > > However, there is a side note to this that I would love to see more > heavily > pushed: I am still getting module issues related to PHP 4 (even 4.3) and > MySql 4. And the users are saying they don't want to push their hosts to > upgrade. I really would like to see a lot more emphasis on getting hosting > companies ready now, rather than later. > > In every issue I have where infrastructure releases may be involved, I > point > out the need to upgrade. But I seem to be the only one who is pointing > this > out to them. > > It's going to take some hosting companies a while to get updated, so we > need > to be pushing this now - even for a first of 2009 roll-out. Just point people here: http://gophp5.org/ - Anyone still on PHP 4 at this point does so at their own risk, with full knowledge that they're on borrowed time at best. Even the PHP Group has dropped PHP 4 at this point. --Larry Garfield, who spent a large chunk of last year raising awareness. :-) From merlin at logrus.com Thu Jun 26 15:12:37 2008 From: merlin at logrus.com (Earl Miles) Date: Thu, 26 Jun 2008 08:12:37 -0700 Subject: [development] Code freeze? In-Reply-To: References: Message-ID: <4863B1E5.9030603@logrus.com> Nancy Wichmann wrote: > Dries Buytaert wrote: > >> If people are supportive to the idea of pushing back the code freeze >> date, I'll write up an announcement. > > I agree that there is still considerable resistance to D6, so let's not push > D7 so hard. > > However, there is a side note to this that I would love to see more heavily > pushed: I am still getting module issues related to PHP 4 (even 4.3) and > MySql 4. And the users are saying they don't want to push their hosts to > upgrade. I really would like to see a lot more emphasis on getting hosting > companies ready now, rather than later. > > In every issue I have where infrastructure releases may be involved, I point > out the need to upgrade. But I seem to be the only one who is pointing this > out to them. > > It's going to take some hosting companies a while to get updated, so we need > to be pushing this now - even for a first of 2009 roll-out. At this point, I'd suggest just adding a requirement to your module for PHP5 if you like. PHP4 has been EOL'd, after all. It should not surprise Dries in the slightest that I am in favor of a 2009 code freeze leading to a late 2009 or even scheduled 2010 release for 2007. I don't see a need to rush; and I am in complete agreement with the general opinion that, as Drupal has matured, so too should its release cycle slow down. From weitzman at tejasa.com Thu Jun 26 15:15:15 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Thu, 26 Jun 2008 11:15:15 -0400 Subject: [development] Code freeze? In-Reply-To: <4863A024.2050307@webchick.net> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> <4863A024.2050307@webchick.net> Message-ID: <6117a7500806260815k435be584w629790fef7a70545@mail.gmail.com> > I think that our current test coverage by conventional tools is going to be > close to 0%. It's also clear that the community has not in fact "embraced > testing." Instead, a hardcore group of around 15-20 people (the "testing > brigade" ;)) have, and are driving this effort forward on behalf of the rest > of the development team. I am quite certain that you will not see any "embrace" until testing.drupal.org is up and integrated into our workflow. When the TestingBot starts posting unit test success/failure into the queue, we will see the embrace. I salute the testing brigade for all that you have done and will do. It really is a big and important job. I have never seen such unanimity in drupal like we are seeing for delaying this freeze. Consider it done. No need to keep piling on ... From drupal at dwwright.net Thu Jun 26 15:16:18 2008 From: drupal at dwwright.net (Derek Wright) Date: Thu, 26 Jun 2008 10:16:18 -0500 Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: To jump on the "yes, please delay" train... On Jun 26, 2008, at 2:08 AM, Dries Buytaert wrote: > Given the current state of things... A few other facts of the current state: a) Due to multiple crisis in my personal life, and launching my first really major Drupal site, I've had practically no time to work on project*. Therefore, drupal.org is still running D5. A code freeze on D7 before upgrading d.o to D6 seems like a terrible idea. ;) b) There are some significant improvements and fixes that need to happen to Update status, and Earl has his hands full with the "chaos suite" in contrib. c) Aside from project*, I've got a few other important contribs that aren't 6.x-1.0 material yet. d) As a result of a-c, I've been almost entirely out of the loop on D7 development. I was starting to get a little bummed out that I was going to completely miss the chance to seriously work on core for the D7 release at all. Personal factors aside, I also support the more general "slow down, already" sentiment. ;) Drupal adoption is obviously taking off in a big way. I think our "we must be reborn every year or we die" attitude is running up against the reality of "if they rewrite themselves every year, I can't make use of this platform" in the real world. I'm thrilled we don't maintain backwards compatibility, but I do think we need to reconsider the pace of major releases. Thanks, -Derek (dww) From drupal-devel at webchick.net Thu Jun 26 16:20:35 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Thu, 26 Jun 2008 12:20:35 -0400 Subject: [development] Code freeze? In-Reply-To: <6117a7500806260815k435be584w629790fef7a70545@mail.gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> <4863A024.2050307@webchick.net> <6117a7500806260815k435be584w629790fef7a70545@mail.gmail.com> Message-ID: <4863C1D3.8040801@webchick.net> Moshe Weitzman wrote: >> I think that our current test coverage by conventional tools is going to be >> close to 0%. It's also clear that the community has not in fact "embraced >> testing." Instead, a hardcore group of around 15-20 people (the "testing >> brigade" ;)) have, and are driving this effort forward on behalf of the rest >> of the development team. > > I am quite certain that you will not see any "embrace" until > testing.drupal.org is up and integrated into our workflow. When the > TestingBot starts posting unit test success/failure into the queue, we > will see the embrace. Yep. Step 0 of that is making sure all tests pass, otherwise *every* uploaded patch will report test failures. ;) That means getting http://drupal.org/project/issues?projects=3060&components=tests&categories=bug&priorities=1 down to 0. Step 1 is abstracting out the issue reply status change functionality - http://drupal.org/node/271216. Steps 2+ will be at http://drupal.org/project/issues/Drupaltestbed Obviously, the more hands on deck, the faster we live in a glorious world where: - patch creators get told within 24 hours whether their patches need re-rolls without having to wait for a reviewer to stumble cross them many weeks later - patch reviewers are assured that any issues marked patch (code needs review) are, in fact, reviewable, and don't waste their invaluable time trying to apply patches that either don't apply anymore or break existing functionality - testers are assured that once they write a test to confirm a bug is fixed or a feature works, that bug will never again recur and that feature will never get broken. - developers are free to refactor with impunity because they can tell instantly if they've broken something fundamental to the system. That said, the Batch API patch makes running all tests tolerable (even a little bit fun!) now from within testing module itself. So although testing.drupal.org is definitely a VERY nice to have, it's not a prerequisite for embracing testing. We can start today. :) -Angie From nan_wich at bellsouth.net Thu Jun 26 16:52:06 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Thu, 26 Jun 2008 12:52:06 -0400 Subject: [development] Code freeze? In-Reply-To: Message-ID: Larry Garfield wrote: > Just point people here: http://gophp5.org/... Check every one of my project pages. ----------------- Earl Miles wrote: > At this point, I'd suggest just adding a requirement to your module for > PHP5 if you like. PHP4 has been EOL'd, after all. I have seriously considered this, but I know there are a bunch of my users who would be left out at this point. And of course we still have the less-than-perfectly-functioning hook_requirements in 5.x. I also look and see the D6 still has a requirement for only 4.3.5 and I'd prefer not to have to force people to upgrade when core doesn't. I know there are other contrib maintainers who don't care, but I do. -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1519 - Release Date: 6/25/2008 4:13 PM From larry at garfieldtech.com Thu Jun 26 17:06:27 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Thu, 26 Jun 2008 12:06:27 -0500 Subject: [development] =?utf-8?q?Code_freeze=3F?= In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: If I can say "AOL!" here... :-) The slow uptake of D6 is due mostly to everyone and their brother taking the opportunity to rewrite their contrib modules at the same time as upgrading to D6, or right before doing so. Views, Panels, Project*, CCK, filefield, imagefield, and a half-dozen others have major improvements planned in contrib space that are progressing; they just take time. Those, in turn, block dozens of other modules. Dries and others are right that we really can't close D7 knowing what all we need to do to it until D6 has had time to test its mettle in production, and I don't know of any non-trivial D6 deployments yet. We can only guess at what we need to do to fix the issues in D6 with D7 at this point. webchick lamented the lack of "embracing testing" and that we have only a "testing brigade". I'm actually not surprised at that. That's known as a "QA Team" in many circles, and is a very good thing. A semi-dedicated QA team that beats people over the head is a more efficient use of resources than trying to get everyone to be everything for every patch. My hats off to the "testing brigade" for their ongoing work, and may they continue to thwap the rest of us when appropriate. (Incidentally, is it my imagination or does the Testing Brigade consist mostly of former GHOP students and mentors?) Their work is made even harder by the time needed to basically rewrite our own testing framework, since we're apparently not sticking with any existing testing framework (which seems inline with Drupal's usual policy...) The flipside of that, however, is writing code that is easy to test. Right now, Drupal's code base is really not very unit testable. Various ideas have been floated to for mock functions, runkit, etc., but in the end the real answer here is to refactor Drupal itself so that its APIs are easier to unit test in isolation. That goes hand in hand with one of the key "make it rock" goals for Drupal 7, which is "better internal APIs". We've made some progress on this front, but a lot of patches in that direction are simply waiting on people having time to work on it, many of whom are involved in the testing brigade now. (I'm thinking of the block API refactoring here, and killing $op, as well as various others.) That sort of heavy refactoring takes a lot of time even when your top developers aren't engaged in D6 module ports and building a testing framework. That is critical for "embracing testing", however, as well as bettering Drupal in general. So yes, +1 on delaying the code freeze. There's a lot of work that's half-way through. Let's complete it, and give D6 time to show us where the mines are so we can fix them at the same time. --Larry Garfield On Thu, 26 Jun 2008 09:08:48 +0200, Dries Buytaert wrote: > I've been thinking about this some. While we have made incredible > progress with the test infrastructure as well as implemented a dozen > of usability improvements, we're still light on feature improvements > (such as fields in core). > > Combined with the late arrival of CCK and Views, and the many Drupal 6 > books that are currently being written, it sounds best to postpone the > code freeze a little longer. Given the current state of things, the > proposed July 15 deadline seems a bit too aggressive to my liking. > > If people are supportive to the idea of pushing back the code freeze > date, I'll write up an announcement. > > Thanks, > > On 24 Jun 2008, at 10:36, Augustin (Beginner) wrote: >> Hi, >> >> What is the latest news about the D7 code freeze. I haven't seen any >> announcement on this list. Do we have a date for the code freeze, or >> at least a better estimate than what was offered at the beginning of >> the thaw? >> >> >> thanks, >> >> Augustin. > > > > -- > Dries Buytaert :: http://buytaert.net From kyle at codeincarnate.com Thu Jun 26 17:01:31 2008 From: kyle at codeincarnate.com (Kyle Cunningham) Date: Thu, 26 Jun 2008 12:01:31 -0500 Subject: [development] Code freeze? In-Reply-To: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <4863CB6B.9040303@codeincarnate.com> > If people are supportive to the idea of pushing back the code freeze > date, I'll write up an announcement. > +1 to pushing back the code freeze. I'm in the middle of quite a few large Drupal 6 modules, along with a number of ports that my company needs for Drupal 6. Plus, it seems like there are a number of significant features that would not get in to Drupal 7 with a code freeze only a couple of weeks away. Cheers, Kyle Cunningham From earnie at users.sourceforge.net Thu Jun 26 18:19:51 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 26 Jun 2008 14:19:51 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com><37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net><9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com><20080625095425.28t2ltoxfq6ock88@mail.progw.org><486265C9.1000608@advomatic.com><20080625115653.vn8qm7akwjk0gkws@mail.progw.org><48626BF7.8050000@advomatic.com><01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> Message-ID: <20080626141951.5nb9x0l80a688w48@mail.progw.org> Quoting Thomas Zahreddin : > Reading this thread, i ask myself and you why not using a established > package format like RPM http://en.wikipedia.org/wiki/RPM_Package_Manager , > deb-format or some other out of the linux - environment, compared on > http://kitenet.net/~joey/pkg-comp/ > > Or if you are afraid of high complexity and efford to support such a format > on all plattforms - then give the PEAR-or PECL-format a chance. > I don't want to say any of these formats meets the requirements, but i did > not have seen this formats discussed. > > What do you think about an more generaly used format for Drupal-packages? > http://drupal.org/project/Installation+profiles But that doesn't help the need of module version dependency checking within the coded module. For that I've just uploaded Module Versions[1] to CVS. I've attached it to D5 for now. I'll get a D6 tag going tomorrow. The module should work for either and is aimed at Development and Developers only. [1] http://drupal.org/project/modver Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From earnie at users.sourceforge.net Thu Jun 26 18:36:02 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Thu, 26 Jun 2008 14:36:02 -0400 Subject: [development] module_exists vs. functions_exists? In-Reply-To: References: <3861c6770806221436o7b446684gfc55228f3a08f356@mail.gmail.com> <37ECA445-8D2A-4C3E-A734-FEF82A7C5EA2@mikeyp.net> <9ea8d6030806241602i43255e15u18e4fe853d43abc2@mail.gmail.com> <20080625095425.28t2ltoxfq6ock88@mail.progw.org> <486265C9.1000608@advomatic.com> <20080625115653.vn8qm7akwjk0gkws@mail.progw.org> <48626BF7.8050000@advomatic.com> <01EB314B-F2DE-4B67-8AFC-8C29F5B3ED7F@bryght.com> Message-ID: <20080626143602.cnky0m2avugwwkkg@mail.progw.org> Quoting Darrel O'Pry : > On Wed, Jun 25, 2008 at 1:06 PM, Adrian Rossouw wrote: > >> >> On 25 Jun 2008, at 6:01 PM, Aaron Winborn wrote: >> >> >>> There's no easy answer for the first case, other than bloating your code >>> with additional drupal_function_exists checks, and the second would require >>> tracking module version (at least its major version). >>> >> we need this anyway. >> >> badly. > > > drupal_function_exists or module version tracking? I know it would be great > to have it centralized, but currently requirement checking can be done in > hook_requirements.. although > it would be nice to have some automagic in .info for it. > Ooo, cool deal. With the Module Versions module[1] I just created you could write a hook for the requirement which is then displayed on the status page. [1] http://drupal.org/project/modver Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From kb at 2bits.com Thu Jun 26 18:48:18 2008 From: kb at 2bits.com (Khalid Baheyeldin) Date: Thu, 26 Jun 2008 14:48:18 -0400 Subject: [development] Code freeze? In-Reply-To: References: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <4a9fdc630806261148r2597eacaof3e16e3ed21d9e42@mail.gmail.com> I am in favor of pushing D7 later, not for testing (which I am not very keen on, due to past experience with automated testing), but for the reasons Larry outlined here: The slow uptake of D6 is due mostly to everyone and their brother taking the > opportunity to rewrite their contrib modules at the same time as upgrading > to D6, or right before doing so. Views, Panels, Project*, CCK, filefield, > imagefield, and a half-dozen others have major improvements planned in > contrib space that are progressing; they just take time. Those, in turn, > block dozens of other modules. > If we push for D7 to go out, and sites are just converting to D6 because the crucial modules above are just freshly available, then it will be another round of crunch time to get them to D7, and it would not be on time. So, better spend the time adding more features to D7 (fields, views engine, ...etc.) rather than just a testing framework, which is not visible in a tangible way to end users (site builders and owners in this case). -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080626/4cefc4f0/attachment.htm From drupal-devel at webchick.net Thu Jun 26 19:25:25 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Thu, 26 Jun 2008 15:25:25 -0400 Subject: [development] The State of Testing (was Re: Code freeze?) In-Reply-To: References: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <4863ED25.1010706@webchick.net> Larry Garfield wrote: > webchick lamented the lack of "embracing testing" and that we have only a "testing brigade". I'm actually not surprised at that. That's known as a "QA Team" in many circles, and is a very good thing. A semi-dedicated QA team that beats people over the head is a more efficient use of resources than trying to get everyone to be everything for every patch. My hats off to the "testing brigade" for their ongoing work, and may they continue to thwap the rest of us when appropriate. (Incidentally, is it my imagination or does the Testing Brigade consist mostly of former GHOP students and mentors?) Their work is made even harder by the time needed to basically rewrite our own testing framework, since we're apparently not sticking with any existing testing framework (which seems inline with Drupal's usual policy...) A couple things: 1. I wasn't lamenting anything. I was simply stating the reality. The reality is that the community hasn't remotely "embraced testing," and a huge part of that is because the testing brigade has had its hands more than full hammering out larger over-arching issues with the testing framework and existing tests, which I proceeded to document in the rest of my reply. 2. I'm fine with this reality, and at the present point in time it would be silly to expect anything else. If we had tried to get 800+ developers to "embrace testing" back in March, it would've been a complete CF. I'm saying that NOW, we're in a much better position to have a larger body of developers working on testing, thanks to the hard work of the testing brigade over the past several months. 3. We /are/ going to need 800+ people fluent in writing tests by the time the D7 release is upon us. 15-20 people simply cannot provide 100% (or even 10%) test coverage on their own, nor should we want that to happen. The testing brigade should be focusing on doing "test reviews," mentoring developers on how to write good tests and answering their questions, checking for thorny areas which need more test coverage, fix issues in the testing framework that are beyond regular developers' expertise, etc. 4. Yes, there's a strong GHOP tie-in. I think that's because most of the people who helped out with and participated in GHOP are the same people who generally help out with and participate in any community initiative. And the same people who didn't... well... ;) 5. The testing framework re-write I was originally very opposed to. But the fact is that SimpleTest had all manner of problems running with our code, and going in there and monkeying with the code to fix it was a huge time-sink every single time. The code that's there now is at least understandable by more than 3 people, it's fully documented, and it also takes far less time to run the full test suite. In general, I'd say it's a huge win. 6. I agree about testable APIs being another huge component of this. The solution of course is to grow the size of the testing brigade, and the size of the body of people who know how to write tests. If this area was more well-covered, developers who'd normally be putting efforts into API re-writes could resume doing so. As it is currently, however, everyone in the testing brigade has more than enough to do on that single area of focus. -Angie From pinglaura at gmail.com Thu Jun 26 20:02:34 2008 From: pinglaura at gmail.com (Laura Scott) Date: Thu, 26 Jun 2008 14:02:34 -0600 Subject: [development] Code freeze? In-Reply-To: References: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> Message-ID: <9F0CB034-B530-4547-B3C9-84FEA704E4E9@gmail.com> On Jun 26, 2008, at 11:06 AM, Larry Garfield wrote: > The slow uptake of D6 is due mostly to everyone and their brother > taking the opportunity to rewrite their contrib modules at the same > time as upgrading to D6, or right before doing so. Views, Panels, > Project*, CCK, filefield, imagefield, and a half-dozen others have > major improvements planned in contrib space that are progressing; > they just take time. Those, in turn, block dozens of other modules. +1 from a community marketing perspective as well. I'm glad there's general consensus that with the tail wagging the dog, Drupal will benefit from a slowdown so D6 can get established in the marketplace before pushing D7 out. However, I'm -1 on making this a policy towards a new 18-month release cycle. I feel rolling with the flow makes sense. If D8 is coming along well, there will be little to gain by delaying it in the interests of a general slowdown. My two bits. Laura From cwgordon7 at cwgordon.com Thu Jun 26 22:12:19 2008 From: cwgordon7 at cwgordon.com (Charlie Gordon) Date: Thu, 26 Jun 2008 18:12:19 -0400 Subject: [development] Code freeze? In-Reply-To: <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> References: <200806241636.19350.drupal.beginner@wechange.org> <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <517BAB61-BA8B-46FB-A199-F27B4CF64486@gmail.com> Message-ID: <48641443.8000002@cwgordon.com> Dries Buytaert wrote: > I do think we're doing great work on testing. I've been committing > testing related patches on a (almost) daily basis. That's pretty sweet. > > That said, we aren't able to measure our test coverage yet. In other > words, it's really hard to tell how well we actually do. Any updates > on that? I've been in contact with the maintainer of the phpcoverage tool we have been attempting to use, and I will try to generate workable coverage reports based on the patch they have just recently supplied to increase the tool's scalability. However, hook_simpletest() seems to have been removed, so this may require a core patch... but looking into it. As soon as I've generated coverage reports, you will hear about it! :) From dries.buytaert at gmail.com Fri Jun 27 08:02:10 2008 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Fri, 27 Jun 2008 10:02:10 +0200 Subject: [development] Code freeze? In-Reply-To: <9F0CB034-B530-4547-B3C9-84FEA704E4E9@gmail.com> References: <2F0CB3AB-AAF1-4011-93E8-58236182BC93@gmail.com> <9F0CB034-B530-4547-B3C9-84FEA704E4E9@gmail.com> Message-ID: <163FB9FB-F805-4B7A-8F42-A4C41DF50253@gmail.com> OK, we'll postpone the code freeze for now. At this point, I won't make any decisions or promises about when the code freeze will be. I'l revisit this question in a couple months time. On 26 Jun 2008, at 22:02, Laura Scott wrote: >> The slow uptake of D6 is due mostly to everyone and their brother >> taking the opportunity to rewrite their contrib modules at the same >> time as upgrading to D6, or right before doing so. Views, Panels, >> Project*, CCK, filefield, imagefield, and a half-dozen others have >> major improvements planned in contrib space that are progressing; >> they just take time. Those, in turn, block dozens of other modules. > > +1 from a community marketing perspective as well. I'm glad there's > general consensus that with the tail wagging the dog, Drupal will > benefit from a slowdown so D6 can get established in the marketplace > before pushing D7 out. However, I'm -1 on making this a policy > towards a new 18-month release cycle. I feel rolling with the flow > makes sense. If D8 is coming along well, there will be little to > gain by delaying it in the interests of a general slowdown. -- Dries Buytaert :: http://buytaert.net From matt at cabinetuk.com Fri Jun 27 14:32:52 2008 From: matt at cabinetuk.com (Matt Connolly) Date: Fri, 27 Jun 2008 15:32:52 +0100 Subject: [development] Resetting Drupal's menu cache Message-ID: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> Hi all, I've noticed that when you make a change to your MODULE_menu hook, that you need to disable and re-enable the module before the changes are made effective. This is fine for my module because I can do that, but I want to make a change to a core module (for example, make the weight of Logout 1000 so it is always at the bottom). The menu module is a core module and cannot be disabled, so how do I reset this menu cache for core modules? -Matt From darthsteven at gmail.com Fri Jun 27 14:36:17 2008 From: darthsteven at gmail.com (Steven Jones) Date: Fri, 27 Jun 2008 15:36:17 +0100 Subject: [development] Resetting Drupal's menu cache In-Reply-To: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> Message-ID: Just clear the cache_menu table in the database. If you're on D6 this can be done on the 'performance' page in the admin section. Otherwise just resubmitting the modules page should work(?) Regards Steven Jones On Fri, Jun 27, 2008 at 3:32 PM, Matt Connolly wrote: > Hi all, > > I've noticed that when you make a change to your MODULE_menu hook, that you > need to disable and re-enable the module before the changes are made > effective. > > This is fine for my module because I can do that, but I want to make a > change to a core module (for example, make the weight of Logout 1000 so it > is always at the bottom). > > The menu module is a core module and cannot be disabled, so how do I reset > this menu cache for core modules? > > > -Matt > > From winborn at advomatic.com Fri Jun 27 14:37:53 2008 From: winborn at advomatic.com (Aaron Winborn) Date: Fri, 27 Jun 2008 10:37:53 -0400 Subject: [development] Resetting Drupal's menu cache In-Reply-To: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> Message-ID: <4864FB41.500@advomatic.com> My understanding is that you need to visit the Module settings page for menu changes to take effect in d6 (/admin/build/modules). Matt Connolly wrote: > Hi all, > > I've noticed that when you make a change to your MODULE_menu hook, > that you need to disable and re-enable the module before the changes > are made effective. > > This is fine for my module because I can do that, but I want to make a > change to a core module (for example, make the weight of Logout 1000 > so it is always at the bottom). > > The menu module is a core module and cannot be disabled, so how do I > reset this menu cache for core modules? > > > -Matt > From shai at content2zero.com Fri Jun 27 14:40:04 2008 From: shai at content2zero.com (Shai Gluskin) Date: Fri, 27 Jun 2008 10:40:04 -0400 Subject: [development] Resetting Drupal's menu cache In-Reply-To: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> Message-ID: <9f68efb70806270740w72164103p4c0c4932fa18bde4@mail.gmail.com> Matt, I'm pretty sure you truncate the cache_menu table in the db. Shai On Fri, Jun 27, 2008 at 10:32 AM, Matt Connolly wrote: > Hi all, > > I've noticed that when you make a change to your MODULE_menu hook, that you > need to disable and re-enable the module before the changes are made > effective. > > This is fine for my module because I can do that, but I want to make a > change to a core module (for example, make the weight of Logout 1000 so it > is always at the bottom). > > The menu module is a core module and cannot be disabled, so how do I reset > this menu cache for core modules? > > > -Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080627/fa697158/attachment.htm From larry at garfieldtech.com Fri Jun 27 14:58:03 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 27 Jun 2008 9:58:03 -0500 Subject: [development] Resetting Drupal's menu cache In-Reply-To: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> Message-ID: In Drupal 5, just truncate cache_menu. In Drupal 6, you do have to visit the modules page, or go to the Performance page and hit the clear cache button. I tend to find the latter works better. That said, it sounds from your message like you're editing a core module directly. *Do not do that!* In Drupal 6, use hook_menu_alter() to change the weight of a menu item. Then you can just hit the cache clear button and it will rebuild the menu index. --Larry Garfield On Fri, 27 Jun 2008 15:32:52 +0100, Matt Connolly wrote: > Hi all, > > I've noticed that when you make a change to your MODULE_menu hook, > that you need to disable and re-enable the module before the changes > are made effective. > > This is fine for my module because I can do that, but I want to make a > change to a core module (for example, make the weight of Logout 1000 > so it is always at the bottom). > > The menu module is a core module and cannot be disabled, so how do I > reset this menu cache for core modules? > > > -Matt From matt at cabinetuk.com Fri Jun 27 15:12:31 2008 From: matt at cabinetuk.com (Matt Connolly) Date: Fri, 27 Jun 2008 16:12:31 +0100 Subject: [development] Resetting Drupal's menu cache In-Reply-To: References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> Message-ID: <575F119C-2FC6-4028-9F19-388428A9AD25@cabinetuk.com> Thanks. Clearing cache data at the very bottom of the performance page did the trick. The question was originally because you cannot disable core modules, such as "menu.module". Thanks again, Matt On 27/06/2008, at 3:36 PM, Steven Jones wrote: > Just clear the cache_menu table in the database. > If you're on D6 this can be done on the 'performance' page in the > admin section. Otherwise just resubmitting the modules page should > work(?) > > Regards > Steven Jones > > > On Fri, Jun 27, 2008 at 3:32 PM, Matt Connolly > wrote: >> Hi all, >> >> I've noticed that when you make a change to your MODULE_menu hook, >> that you >> need to disable and re-enable the module before the changes are made >> effective. >> >> This is fine for my module because I can do that, but I want to >> make a >> change to a core module (for example, make the weight of Logout >> 1000 so it >> is always at the bottom). >> >> The menu module is a core module and cannot be disabled, so how do >> I reset >> this menu cache for core modules? >> >> >> -Matt >> >> From cwgordon7 at cwgordon.com Fri Jun 27 16:12:04 2008 From: cwgordon7 at cwgordon.com (Charlie Gordon) Date: Fri, 27 Jun 2008 12:12:04 -0400 Subject: [development] Resetting Drupal's menu cache In-Reply-To: <575F119C-2FC6-4028-9F19-388428A9AD25@cabinetuk.com> References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> <575F119C-2FC6-4028-9F19-388428A9AD25@cabinetuk.com> Message-ID: <48651154.9000600@cwgordon.com> Matt Connolly wrote: > Thanks. > > Clearing cache data at the very bottom of the performance page did the > trick. > > The question was originally because you cannot disable core modules, > such as "menu.module". Um, yes, you can disable menu module. Just uncheck the box. :P In any case, it is not necessary - simply resubmitting the modules administration page will cause the menu cache to rebuild, which will affect /all/ modules, not just the ones disabled/re-enabled. Also, in what case would you have changes to menu_menu()? It is a core module - its code should not be changed. From danithaca at gmail.com Sat Jun 28 00:48:22 2008 From: danithaca at gmail.com (Daniel Xiaodan Zhou) Date: Fri, 27 Jun 2008 20:48:22 -0400 Subject: [development] code review for the "pivots" project Message-ID: Hi all, We are working on the "pivots" project as an attempt to give module recommendations. The idea is to display on a module page the related forum conversations and related modules that are referenced in the same conversations. We think it could provide some useful information for users to decide whether to download a module or how to use it. The "pivots" system has been enabled for D.O. site maintainers and CVS account holders. More details can be found here: http://drupal.org/node/265450 We are about to deliver it to all interested D.O. users. And we hope to get some code reviews from the community to improve code quality. The code is published to CVS: contributions/modules/pivots4do Or, for a quick browse, you might go to the following links. PHP: http://danithaca.pastebin.com/m798c291d http://danithaca.pastebin.com/m2ea9911a Java Indexer: http://danithaca.pastebin.com/m1b147b25 http://danithaca.pastebin.com/m53f9621b http://danithaca.pastebin.com/m592c46ec For a short description of the architecture and security concerns, please refer to: http://drupal.org/node/265450#comment-884264 Your comments would be much appreciated. Thanks! Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080627/3e21040f/attachment.htm From nan_wich at bellsouth.net Sat Jun 28 04:11:33 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sat, 28 Jun 2008 00:11:33 -0400 Subject: [development] code review for the "pivots" project In-Reply-To: Message-ID: Daniel Xiaodan Zhou wrote: > We are working on the "pivots" project as an attempt to give module recommendations. The idea is to > display on a module page the related forum conversations and related modules that are referenced in > the same conversations. I looked at a couple of my modules. The "recent discussions" didn't even reference my modules. It is unlikely the "referenced modules" really have any significance either. This could be damaging in the eyes of those who fail to research, which seems to be the vast majority of DO users. Please do NOT open it up to the general public in the condition it?s in now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080628/d958eb2b/attachment-0001.htm -------------- next part -------------- No virus found in this outgoing message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.4.1/1519 - Release Date: 6/25/2008 4:13 PM From cwgordon7 at cwgordon.com Sat Jun 28 09:34:14 2008 From: cwgordon7 at cwgordon.com (Charlie Gordon) Date: Sat, 28 Jun 2008 05:34:14 -0400 Subject: [development] We now have test coverage reports! Message-ID: <48660596.4050307@cwgordon.com> We have now generated test coverage reports, which are publically available at http://coverage.cwgordon.com/. If you would like the raw data for manipulation, it is available at http://coverage.cwgordon.com/cc.tgz. For those of you who don't want to click links, the essence of the matter is: we have 66.68% test coverage with our current tests. However, we can also learn a lot from these reports, such as which files and functions we need to pay more attention to in our testing. Hopefully this report will prove useful! :) -Charlie From david at fourkitchens.com Sat Jun 28 14:20:16 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Sat, 28 Jun 2008 09:20:16 -0500 (CDT) Subject: [development] We now have test coverage reports! In-Reply-To: <48660596.4050307@cwgordon.com> Message-ID: <221493113.1230481214662816626.JavaMail.root@mail-2.01.com> How did you make these reports? ----- "Charlie Gordon" wrote: > We have now generated test coverage reports, which are publically > available at http://coverage.cwgordon.com/. If you would like the raw > > data for manipulation, it is available at > http://coverage.cwgordon.com/cc.tgz. For those of you who don't want > to > click links, the essence of the matter is: we have 66.68% test > coverage > with our current tests. However, we can also learn a lot from these > reports, such as which files and functions we need to pay more > attention > to in our testing. Hopefully this report will prove useful! :) > > -Charlie From cwgordon7 at cwgordon.com Sat Jun 28 19:49:46 2008 From: cwgordon7 at cwgordon.com (Charlie Gordon) Date: Sat, 28 Jun 2008 15:49:46 -0400 Subject: [development] We now have test coverage reports! In-Reply-To: <221493113.1230481214662816626.JavaMail.root@mail-2.01.com> References: <221493113.1230481214662816626.JavaMail.root@mail-2.01.com> Message-ID: <486695DA.3000307@cwgordon.com> David Timothy Strauss wrote: > How did you make these reports? > I've actually released the source code I used in a module; it can be found at http://drupal.org/project/code_coverage. Basically, it relies on xdebug to generate the code coverage data, and then just stores and processes it in a way that's meaningful. From gabor at hojtsy.hu Sun Jun 29 06:18:48 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Sun, 29 Jun 2008 08:18:48 +0200 Subject: [development] We now have test coverage reports! In-Reply-To: <486695DA.3000307@cwgordon.com> References: <221493113.1230481214662816626.JavaMail.root@mail-2.01.com> <486695DA.3000307@cwgordon.com> Message-ID: <86ca3ccb0806282318n52642401t9fcb3c4a8b7be389@mail.gmail.com> On Sat, Jun 28, 2008 at 9:49 PM, Charlie Gordon wrote: > David Timothy Strauss wrote: >> >> How did you make these reports? > > I've actually released the source code I used in a module; it can be found > at http://drupal.org/project/code_coverage. Basically, it relies on xdebug > to generate the code coverage data, and then just stores and processes it in > a way that's meaningful. Grm, have you seen: http://drupal.org/node/260032 ?? Gabor From cwgordon7 at cwgordon.com Sun Jun 29 07:06:12 2008 From: cwgordon7 at cwgordon.com (Charlie Gordon) Date: Sun, 29 Jun 2008 03:06:12 -0400 Subject: [development] We now have test coverage reports! In-Reply-To: <86ca3ccb0806282318n52642401t9fcb3c4a8b7be389@mail.gmail.com> References: <221493113.1230481214662816626.JavaMail.root@mail-2.01.com> <486695DA.3000307@cwgordon.com> <86ca3ccb0806282318n52642401t9fcb3c4a8b7be389@mail.gmail.com> Message-ID: <48673464.7060803@cwgordon.com> G?bor Hojtsy wrote: > Grm, have you seen: http://drupal.org/node/260032 ?? > Gabor > Yes, I have, and I actually re-used some of that code. A lot of it had to be thrown out, though, because it was kind of badly written. -Charlie From gabor at hojtsy.hu Sun Jun 29 07:33:43 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Sun, 29 Jun 2008 09:33:43 +0200 Subject: [development] We now have test coverage reports! In-Reply-To: <48673464.7060803@cwgordon.com> References: <221493113.1230481214662816626.JavaMail.root@mail-2.01.com> <486695DA.3000307@cwgordon.com> <86ca3ccb0806282318n52642401t9fcb3c4a8b7be389@mail.gmail.com> <48673464.7060803@cwgordon.com> Message-ID: <86ca3ccb0806290033o4cd5e2c1g53e4d62e3f2472f7@mail.gmail.com> OK, great, it would be great to follow up on the issue and close it then. Gabor On Sun, Jun 29, 2008 at 9:06 AM, Charlie Gordon wrote: > G?bor Hojtsy wrote: >> >> Grm, have you seen: http://drupal.org/node/260032 ?? >> Gabor >> > > Yes, I have, and I actually re-used some of that code. A lot of it had to be > thrown out, though, because it was kind of badly written. > > -Charlie > From drupal.beginner at wechange.org Sun Jun 29 08:28:46 2008 From: drupal.beginner at wechange.org (Augustin (Beginner)) Date: Sun, 29 Jun 2008 16:28:46 +0800 Subject: [development] breadcrumb override problem Message-ID: <200806291628.46946.drupal.beginner@wechange.org> Hello, I'm upgrading and cleaning directory.module for Drupal 6. I am running on a breadcrumb problem. I think the Drupal core implementation of breadcrumbs is broken. First of all, there can only be one set of breadcrumbs. Imagine a blog post outlined in some book, with a few taxonomy terms. We potentially have three sets of breadcrumbs: the one set by each module involved (blog, book, taxononomy, though core taxonomy.module doesn't set the breadcrumbs on a node view.) To decide which breadcrumb will prevail, timing is everything: it will be the one set by the last call of drupal_set_breadcrumb() BEFORE the first call of drupal_get_breadcrumb(). I was trying to override the taxonomy.module's breadcrumbs on a taxonomy/term/nnn page, but: - if I call drupal_set_breadcrumb() from hook_help(), it's too late: the theming engine has already called drupal_get_breadcrumb() and my breadcrumbs are ignored. - if I call drupal_set_breadcrumb() from hook_init(), it's too early: taxonomy.module will override mine just before drupal_get_breadcrumb() gets called! So, now, I am a bit lost and don't know where I can best call drupal_set_breadcrumb() so that it comes after taxonomy's call, and before the first drupal_get_breadcrumb() call... Searching d.o, I've found many other issues in other crontrib modules which seem to deal with more or less the same problem, but I've not found a solution yet. So: 1) how should I solve my particular problem (the timing of drupal_set_breadcrumb() in my module to override/enhance taxonomy's breadcrumbs). 2) Do you agree that Drupal's core breadcrumbs handling could be improved, to make it possible to have several sets of breadcrumbs (why not? A good themer could accommodate them easily), or at least to make it easier to override / complement each other's breadcrumbs. If there's some kind of agreement on the second point, I'll open an issue for D7 with a summary of the discussion here. Blessings, Augustin. -- From karoly at negyesi.net Sun Jun 29 08:31:23 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun, 29 Jun 2008 10:31:23 +0200 Subject: [development] Please do not mark core issues RTBC Message-ID: <7e270cea0806290131i4a3eff6ajdbea792c8d2c40a2@mail.gmail.com> unless you ran all tests. Report what you saw -- we have a few know fails right now, but I expect that very soon you will be able to report "all passed". I also ask Dries not to commit unless there is such a report. Thanks to all Karoly Negyesi From karoly at negyesi.net Sun Jun 29 10:09:21 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Sun, 29 Jun 2008 12:09:21 +0200 (CEST) Subject: [development] Resetting Drupal's menu cache In-Reply-To: <48651154.9000600@cwgordon.com> References: <45B32973-00CA-4F20-A27A-3F2184A7DD65@cabinetuk.com> <575F119C-2FC6-4028-9F19-388428A9AD25@cabinetuk.com> <48651154.9000600@cwgordon.com> Message-ID: > case, it is not necessary - simply resubmitting the modules > administration page will cause the menu cache to rebuild, which will > affect /all/ modules, not just the ones disabled/re-enabled. Simply visiting the modules admin page cause everything to rebuild in Drupal 6. The menu cache in Drupal 6 is not that relevant. The router table is, but if you are frequently rebuilding that, even during development, then ask yourself "do I have separate router items here or I forgot about the menu_links table and menu_link_save?" From drupal-devel at webchick.net Sun Jun 29 10:14:17 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Sun, 29 Jun 2008 06:14:17 -0400 Subject: [development] breadcrumb override problem In-Reply-To: <200806291628.46946.drupal.beginner@wechange.org> References: <200806291628.46946.drupal.beginner@wechange.org> Message-ID: <48676079.4060204@webchick.net> Augustin (Beginner) wrote: > 1) how should I solve my particular problem (the timing of > drupal_set_breadcrumb() in my module to override/enhance taxonomy's > breadcrumbs). Maybe override the $breadcrumb variable from your module using a preprocess hook? See http://drupal.org/node/173880 for more info. > 2) Do you agree that Drupal's core breadcrumbs handling could be > improved, to make it possible to have several sets of breadcrumbs > (why not? A good themer could accommodate them easily), or at least > to make it easier to override / complement each other's breadcrumbs. If the new theme system in D6 doesn't provide enough flexibility, possibly. It's pretty awesome, though. -Angie From mroswell at gmail.com Sun Jun 29 11:04:07 2008 From: mroswell at gmail.com (Marjorie Roswell) Date: Sun, 29 Jun 2008 07:04:07 -0400 Subject: [development] Drupal Function Frequency Report? Message-ID: I'm on a drupal learning curve. It occurs to me that I'd love to see a report of all the functions used in Drupal by frequency. (Then, I'd tackle the learning curve by starting with what's used most, and moving down the list!) I imagine starting with something like the api pull from the Module Builder Module (http://drupal.org/project/module_builder) and then somehow scanning the CVS for all the functions, and calculating a frequency. Seriously, would love to basically tackle this learning curve in a logical way, based on how often something appears in code, ideally in both core and contrib, combned. I recognize that little-used code functions may still be quite important, but this approach would certainly serve as a good guide. I don't have the skillset to write this report. Is there anyone for whom producing this function frequency report would be a relative cinch? Margie From rob at robshouse.net Sun Jun 29 11:09:52 2008 From: rob at robshouse.net (Robert Douglass) Date: Sun, 29 Jun 2008 13:09:52 +0200 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: Message-ID: <2B3BD9C8-C8EB-42DF-8926-CF058487C2E9@robshouse.net> XCachGrind makes such reports. Robert Douglass Senior Drupal Advisor Acquia robert at acquia.com +1 517 639 0204 (US) +49 228 4097 197 (Germany) On Jun 29, 2008, at 1:04 PM, Marjorie Roswell wrote: > I'm on a drupal learning curve. > > It occurs to me that I'd love to see a report of all the functions > used in Drupal by frequency. (Then, I'd tackle the learning curve by > starting with what's used most, and moving down the list!) > > I imagine starting with something like the api pull from the Module > Builder Module (http://drupal.org/project/module_builder) and then > somehow scanning the CVS for all the functions, and calculating a > frequency. > > Seriously, would love to basically tackle this learning curve in a > logical way, based on how often something appears in code, ideally in > both core and contrib, combned. > > I recognize that little-used code functions may still be quite > important, but this approach would certainly serve as a good guide. > > I don't have the skillset to write this report. Is there anyone for > whom producing this function frequency report would be a relative > cinch? > > Margie From mroswell at gmail.com Sun Jun 29 11:39:00 2008 From: mroswell at gmail.com (Marjorie Roswell) Date: Sun, 29 Jun 2008 07:39:00 -0400 Subject: [development] Drupal Function Frequency Report? In-Reply-To: <2B3BD9C8-C8EB-42DF-8926-CF058487C2E9@robshouse.net> References: <2B3BD9C8-C8EB-42DF-8926-CF058487C2E9@robshouse.net> Message-ID: Is that this? http://kcachegrind.sourceforge.net/cgi-bin/show.cgi I seriously wouldn't have a clue how to get that running. If it's easy for you, can you release this report? If not, well, 'twas a good idea, anyhow. Margie On Sun, Jun 29, 2008 at 7:09 AM, Robert Douglass wrote: > XCachGrind makes such reports. > > Robert Douglass > > Senior Drupal Advisor > Acquia > robert at acquia.com > +1 517 639 0204 (US) > +49 228 4097 197 (Germany) > > > > On Jun 29, 2008, at 1:04 PM, Marjorie Roswell wrote: > >> I'm on a drupal learning curve. >> >> It occurs to me that I'd love to see a report of all the functions >> used in Drupal by frequency. (Then, I'd tackle the learning curve by >> starting with what's used most, and moving down the list!) >> >> I imagine starting with something like the api pull from the Module >> Builder Module (http://drupal.org/project/module_builder) and then >> somehow scanning the CVS for all the functions, and calculating a >> frequency. >> >> Seriously, would love to basically tackle this learning curve in a >> logical way, based on how often something appears in code, ideally in >> both core and contrib, combned. >> >> I recognize that little-used code functions may still be quite >> important, but this approach would certainly serve as a good guide. >> >> I don't have the skillset to write this report. Is there anyone for >> whom producing this function frequency report would be a relative >> cinch? >> >> Margie > > From rob at robshouse.net Sun Jun 29 11:49:22 2008 From: rob at robshouse.net (Robert Douglass) Date: Sun, 29 Jun 2008 13:49:22 +0200 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: <2B3BD9C8-C8EB-42DF-8926-CF058487C2E9@robshouse.net> Message-ID: <329335A1-2512-4763-AF94-85CC86EB7416@robshouse.net> Yeah, that's the one. I had this set up once but have deleted it since. It's a funny story actually. I configured it to keep logs of my local Drupal, but forgot to turn it off. Several weeks later my hard drive was completely out of space and crashing. It wasn't until I found the 120GB of KCacheGrind files that I could use my computer again. Robert Douglass Senior Drupal Advisor Acquia robert at acquia.com +1 517 639 0204 (US) +49 228 4097 197 (Germany) On Jun 29, 2008, at 1:39 PM, Marjorie Roswell wrote: > Is that this? > http://kcachegrind.sourceforge.net/cgi-bin/show.cgi > > I seriously wouldn't have a clue how to get that running. > > If it's easy for you, can you release this report? If not, well, 'twas > a good idea, anyhow. > > Margie > > On Sun, Jun 29, 2008 at 7:09 AM, Robert Douglass > wrote: >> XCachGrind makes such reports. >> >> Robert Douglass >> >> Senior Drupal Advisor >> Acquia >> robert at acquia.com >> +1 517 639 0204 (US) >> +49 228 4097 197 (Germany) >> >> >> >> On Jun 29, 2008, at 1:04 PM, Marjorie Roswell wrote: >> >>> I'm on a drupal learning curve. >>> >>> It occurs to me that I'd love to see a report of all the functions >>> used in Drupal by frequency. (Then, I'd tackle the learning curve by >>> starting with what's used most, and moving down the list!) >>> >>> I imagine starting with something like the api pull from the Module >>> Builder Module (http://drupal.org/project/module_builder) and then >>> somehow scanning the CVS for all the functions, and calculating a >>> frequency. >>> >>> Seriously, would love to basically tackle this learning curve in a >>> logical way, based on how often something appears in code, ideally >>> in >>> both core and contrib, combned. >>> >>> I recognize that little-used code functions may still be quite >>> important, but this approach would certainly serve as a good guide. >>> >>> I don't have the skillset to write this report. Is there anyone for >>> whom producing this function frequency report would be a relative >>> cinch? >>> >>> Margie >> >> From darrel.opry at gmail.com Sun Jun 29 12:07:46 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Sun, 29 Jun 2008 08:07:46 -0400 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: <2B3BD9C8-C8EB-42DF-8926-CF058487C2E9@robshouse.net> Message-ID: The frequency changes per page that you're loading... but to set it up you need to install xdebug and setup the profiling.. http://onwebdevelopment.blogspot.com/2008/06/php-code-performance-profiling-on.html might be a good starting point for you. .darrel. On Sun, Jun 29, 2008 at 7:39 AM, Marjorie Roswell wrote: > Is that this? > http://kcachegrind.sourceforge.net/cgi-bin/show.cgi > > I seriously wouldn't have a clue how to get that running. > > If it's easy for you, can you release this report? If not, well, 'twas > a good idea, anyhow. > > Margie > > On Sun, Jun 29, 2008 at 7:09 AM, Robert Douglass > wrote: > > XCachGrind makes such reports. > > > > Robert Douglass > > > > Senior Drupal Advisor > > Acquia > > robert at acquia.com > > +1 517 639 0204 (US) > > +49 228 4097 197 (Germany) > > > > > > > > On Jun 29, 2008, at 1:04 PM, Marjorie Roswell wrote: > > > >> I'm on a drupal learning curve. > >> > >> It occurs to me that I'd love to see a report of all the functions > >> used in Drupal by frequency. (Then, I'd tackle the learning curve by > >> starting with what's used most, and moving down the list!) > >> > >> I imagine starting with something like the api pull from the Module > >> Builder Module (http://drupal.org/project/module_builder) and then > >> somehow scanning the CVS for all the functions, and calculating a > >> frequency. > >> > >> Seriously, would love to basically tackle this learning curve in a > >> logical way, based on how often something appears in code, ideally in > >> both core and contrib, combned. > >> > >> I recognize that little-used code functions may still be quite > >> important, but this approach would certainly serve as a good guide. > >> > >> I don't have the skillset to write this report. Is there anyone for > >> whom producing this function frequency report would be a relative > >> cinch? > >> > >> Margie > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080629/e8312fe9/attachment.htm From drupal-devel at webchick.net Sun Jun 29 12:14:27 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Sun, 29 Jun 2008 08:14:27 -0400 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: Message-ID: <48677CA3.2010208@webchick.net> Marjorie Roswell wrote: > Seriously, would love to basically tackle this learning curve in a > logical way, based on how often something appears in code, ideally in > both core and contrib, combned. Honestly, the best way to tackle the Drupal development learning curve is just to shell out 30 smackers for Pro Drupal Development (use the "Buy" link at http://www.drupalbook.com/; the Drupal Association gets a little bit of a cut). Trying to learn functions piecemeal like that is going to leave you with a bit of a "swiss cheese" understanding of how things fit together, and further frustration as you go along. PDD is great because it guides you "top down" through all of Drupal's various sub-systems. I'd been developing with Drupal heavily for over 2 years when I first read it and it still managed to cement a bunch of fundamentals for me and really help me see how everything fit together. The one caveat is that there's a 2nd edition due out in late August on Drupal 6. So you'll probably end up re-buying the book again in the fall if you buy it now. However, my guess is that if you could cut the time spent suffering the Drupal learning curve by 1000 hours, you can probably make that $30 up in a quick dash of client work real soon. ;) Also, I've not had a chance to really sit down and read it yet, but in paging through, the book "Learning Drupal 6 Module Development" looks like it would be a good second book to pick up once you get the concepts in PDD down and want to start actually building things. -Angie From earnie at users.sourceforge.net Sun Jun 29 14:18:03 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sun, 29 Jun 2008 10:18:03 -0400 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: Message-ID: <20080629101803.kpitjssaykjoc8cg@mail.progw.org> Quoting Marjorie Roswell : > I'm on a drupal learning curve. > Besides the other things that have been mentioned have a look at http://api.drupal.org http://drupal.kollm.org/node/1 http://drupalmodules.com/ Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From rich at freestylesystems.co.uk Sun Jun 29 14:27:34 2008 From: rich at freestylesystems.co.uk (Richard Burford) Date: Sun, 29 Jun 2008 15:27:34 +0100 Subject: [development] Drupal Function Frequency Report? In-Reply-To: <20080629101803.kpitjssaykjoc8cg@mail.progw.org> References: <20080629101803.kpitjssaykjoc8cg@mail.progw.org> Message-ID: and also http://api.freestylesystems.co.uk psynaptic http://freestylesystems.co.uk http://api.freestylesystems.co.uk On 29 Jun 2008, at 15:18, Earnie Boyd wrote: > Quoting Marjorie Roswell : > >> I'm on a drupal learning curve. >> > > Besides the other things that have been mentioned have a look at > > http://api.drupal.org > http://drupal.kollm.org/node/1 > http://drupalmodules.com/ > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2437 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080629/33987a32/attachment.bin From jvandyk at iastate.edu Sun Jun 29 14:28:25 2008 From: jvandyk at iastate.edu (John VanDyk) Date: Sun, 29 Jun 2008 09:28:25 -0500 Subject: [development] Drupal Function Frequency Report? In-Reply-To: <48677CA3.2010208@webchick.net> References: <48677CA3.2010208@webchick.net> Message-ID: At 8:14 AM -0400 6/29/08, Angela Byron wrote: >PDD is great because it guides you "top down" through all of >Drupal's various sub-systems. I'd been developing with Drupal >heavily for over 2 years when I first read it and it still managed >to cement a bunch of fundamentals for me and really help me see how >everything fit together. > >The one caveat is that there's a 2nd edition due out in late August >on Drupal 6. [rising to the bait] Late August? I certainly hope it's not that late! :) I'm aiming squarely for mid-July; late July if things don't go as fast as we hope. Ignore the predictions on the publisher's website. What do they know about book timelines anyway? Er... That said, the first edition is still a good introduction to Drupal's various systems. John From mroswell at gmail.com Sun Jun 29 15:37:50 2008 From: mroswell at gmail.com (Marjorie Roswell) Date: Sun, 29 Jun 2008 11:37:50 -0400 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: <48677CA3.2010208@webchick.net> Message-ID: I've got both books. Matt, when he signed my copy, looked at all my notes, and said "you've read the heck out of this book!" I have to read it again, as it was my first exposure to Drupal on a "vacation" without a computer. I read every word, but without ever having used drupal before. I should re-read it now that I know something! (I have been referencing it.) I also bought the D6 Packt book, but we're still using version 5, so I need to be careful with that one. All that said, I guess I have an analytic mind, and I do think that getting a function frequency list would actually be a helpful guide. If anyone wants to create such a thing, probably of interest to the community. But I do understand that if I can't do it (and I don't think I can), someone else might not have that same itch. Best, Margie P.S. John, and Angie, et. al.: Looking forward to your respective books. They're destined for my collection the moment they're available! From caleb.gilbert at gmail.com Mon Jun 30 01:21:51 2008 From: caleb.gilbert at gmail.com (Caleb Gilbert) Date: Sun, 29 Jun 2008 18:21:51 -0700 Subject: [development] Code freeze? Message-ID: <38ad0b0a0806291821l7bb732b9i94e9601906d99417@mail.gmail.com> Reading this thread has me very excited - what a great decision to extend the code freeze of Drupal 7 for a while! In particular, I enjoyed/share chx's comment that 'Drupal 5/6 is quite good enough to hang-a-reputation-on for some time to come'. Indeed they are. :-) - Caleb OK, we'll postpone the code freeze for now. At this point, I won't make any decisions or promises about when the code freeze will be. I'l revisit this question in a couple months time. On 26 Jun 2008, at 22:02, Laura Scott wrote: >>* The slow uptake of D6 is due mostly to everyone and their brother *>>* taking the opportunity to rewrite their contrib modules at the same *>>* time as upgrading to D6, or right before doing so. Views, Panels, *>>* Project*, CCK, filefield, imagefield, and a half-dozen others have *>>* major improvements planned in contrib space that are progressing; *>>* they just take time. Those, in turn, block dozens of other modules. *>* *>* +1 from a community marketing perspective as well. I'm glad there's *>* general consensus that with the tail wagging the dog, Drupal will *>* benefit from a slowdown so D6 can get established in the marketplace *>* before pushing D7 out. However, I'm -1 on making this a policy *>* towards a new 18-month release cycle. I feel rolling with the flow *>* makes sense. If D8 is coming along well, there will be little to *>* gain by delaying it in the interests of a general slowdown. * -- Dries Buytaert :: http://buytaert.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080629/e530dc80/attachment.htm From david at fourkitchens.com Mon Jun 30 05:47:30 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Mon, 30 Jun 2008 00:47:30 -0500 (CDT) Subject: [development] Code freeze? In-Reply-To: <38ad0b0a0806291821l7bb732b9i94e9601906d99417@mail.gmail.com> Message-ID: <1888252681.16411214804850622.JavaMail.root@mail-2.01.com> This list goes to a lot of people. Please try to make your posts more substantive than "I agree!" ----- "Caleb Gilbert" wrote: > Reading this thread has me very excited - what a great decision to extend the code freeze of Drupal 7 for a while! In particular, I enjoyed/share chx's comment that 'Drupal 5/6 is quite good enough to hang-a-reputation-on for some time to come'. Indeed they are. :-) > > - Caleb > > > OK, we'll postpone the code freeze for now. At this point, I won't > make any decisions or promises about when the code freeze will be. > I'l revisit this question in a couple months time. > > > On 26 Jun 2008, at 22:02, Laura Scott wrote: > >> The slow uptake of D6 is due mostly to everyone and their brother > >> taking the opportunity to rewrite their contrib modules at the same > > >> time as upgrading to D6, or right before doing so. Views, Panels, > >> Project*, CCK, filefield, imagefield, and a half-dozen others have > >> major improvements planned in contrib space that are progressing; > > >> they just take time. Those, in turn, block dozens of other modules. > > > > +1 from a community marketing perspective as well. I'm glad there's > > general consensus that with the tail wagging the dog, Drupal will > > > benefit from a slowdown so D6 can get established in the marketplace > > before pushing D7 out. However, I'm -1 on making this a policy > > towards a new 18-month release cycle. I feel rolling with the flow > > > makes sense. If D8 is coming along well, there will be little to > > gain by delaying it in the interests of a general slowdown. > > > > -- > Dries Buytaert :: http://buytaert.net > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080630/ae08d42c/attachment.htm From fintan at io1.biz Mon Jun 30 06:56:23 2008 From: fintan at io1.biz (fintan at io1.biz) Date: Mon, 30 Jun 2008 07:56:23 +0100 Subject: [development] Drupal Function Frequency Report? In-Reply-To: References: <2B3BD9C8-C8EB-42DF-8926-CF058487C2E9@robshouse.net> Message-ID: <48688397.4030806@io1.biz> We released an amazon ec2 ami with xdebug setup and output for kcachegrind/wincachegrind, have a look here : http://www.io1.biz/blogs/drupalxdebugvimkcachegrind-ec2-ami Fintan Darrel O'Pry wrote: > The frequency changes per page that you're loading... but to set it up > you need to install xdebug and setup the profiling.. > > http://onwebdevelopment.blogspot.com/2008/06/php-code-performance-profiling-on.html > > might be a good starting point for you. > > .darrel. > > On Sun, Jun 29, 2008 at 7:39 AM, Marjorie Roswell > wrote: > > Is that this? > http://kcachegrind.sourceforge.net/cgi-bin/show.cgi > > I seriously wouldn't have a clue how to get that running. > > If it's easy for you, can you release this report? If not, well, 'twas > a good idea, anyhow. > > Margie > > On Sun, Jun 29, 2008 at 7:09 AM, Robert Douglass > > wrote: > > XCachGrind makes such reports. > > > > Robert Douglass > > > > Senior Drupal Advisor > > Acquia > > robert at acquia.com > > +1 517 639 0204 (US) > > +49 228 4097 197 (Germany) > > > > > > > > On Jun 29, 2008, at 1:04 PM, Marjorie Roswell wrote: > > > >> I'm on a drupal learning curve. > >> > >> It occurs to me that I'd love to see a report of all the functions > >> used in Drupal by frequency. (Then, I'd tackle the learning > curve by > >> starting with what's used most, and moving down the list!) > >> > >> I imagine starting with something like the api pull from the Module > >> Builder Module (http://drupal.org/project/module_builder) and then > >> somehow scanning the CVS for all the functions, and calculating a > >> frequency. > >> > >> Seriously, would love to basically tackle this learning curve in a > >> logical way, based on how often something appears in code, > ideally in > >> both core and contrib, combned. > >> > >> I recognize that little-used code functions may still be quite > >> important, but this approach would certainly serve as a good guide. > >> > >> I don't have the skillset to write this report. Is there anyone for > >> whom producing this function frequency report would be a relative > >> cinch? > >> > >> Margie > > > > > > -- Fintan Galvin Managing Director IO1 Limited Leveraging Strategic Advantage Mobile: +44 773 8506781 Ph: + 44 20 8816 7690 skype: johnfgalvin ******************************************************************** Important. Confidentiality: This communication is intended for the above-named person(s) and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. ******************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080630/7403cab4/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: fintan.vcf Type: text/x-vcard Size: 150 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20080630/7403cab4/attachment-0001.vcf From matt at cabinetuk.com Mon Jun 30 11:32:10 2008 From: matt at cabinetuk.com (Matt Connolly) Date: Mon, 30 Jun 2008 12:32:10 +0100 Subject: [development] upload module or maybe url() bug Message-ID: <82F1AC62-00D4-4DC7-A779-EE2D5AA6C2C6@cabinetuk.com> I have a question about url encoding Spaces in URLS are normally translated to "%20" and spaces in queries are normally translated into "+", although the "%20" is correctly decoded. I'm discovering that private file uploads are not working when there is a "+" in the file name. This is being translated into a " " (space) which is quite normal for queries. With public downloads, (ie accessibly directly via http://mydrupalsite/sites/files/fred+wilma.jpg " the file works. So apache doesn't translate the + in the file's path name into a space, and the file is downloaded. With private downloads, the file name is placed into a query, thanks to mod_rewrite (or, becomes http://mydrupalsite/q?=system/files/fred+wilma.jpg " . You can see where the problem is. I can easily fix this by altering the "file_create_url" function in "/ includes/file.inc". I know I've been warned to not change drupal's core modules and code, but ..... I think I need to. However, I wonder if the problem would be better handled in the "url()" function? I notice that if you create page url's "bananas+pears" and "apples and oranges" the urls are all encoded with %20. So it seems you can't use the "+" in a custom URL. Butt least here what you type and what you get are consistent. Any thoughts? -Matt From enboig at gmail.com Mon Jun 30 12:13:11 2008 From: enboig at gmail.com (=?ISO-8859-1?Q?Llu=EDs?=) Date: Mon, 30 Jun 2008 14:13:11 +0200 Subject: [development] upload module or maybe url() bug In-Reply-To: <82F1AC62-00D4-4DC7-A779-EE2D5AA6C2C6@cabinetuk.com> References: <82F1AC62-00D4-4DC7-A779-EE2D5AA6C2C6@cabinetuk.com> Message-ID: <45a29f450806300513l649e68c0ma942af72d62900d7@mail.gmail.com> check with http://drupal.org/project/transliteration ; it solved my problems On 6/30/08, Matt Connolly wrote: > I have a question about url encoding > > Spaces in URLS are normally translated to "%20" and spaces in queries are > normally translated into "+", although the "%20" is correctly decoded. > > I'm discovering that private file uploads are not working when there is a > "+" in the file name. This is being translated into a " " (space) which is > quite normal for queries. > > With public downloads, (ie accessibly directly via > http://mydrupalsite/sites/files/fred+wilma.jpg" the file > works. So apache doesn't translate the + in the file's path name into a > space, and the file is downloaded. > > With private downloads, the file name is placed into a query, thanks to > mod_rewrite (or, becomes > http://mydrupalsite/q?=system/files/fred+wilma.jpg" . You > can see where the problem is. > > > I can easily fix this by altering the "file_create_url" function in > "/includes/file.inc". I know I've been warned to not change drupal's core > modules and code, but ..... I think I need to. > > However, I wonder if the problem would be better handled in the "url()" > function? > > I notice that if you create page url's "bananas+pears" and "apples and > oranges" the urls are all encoded with %20. So it seems you can't use the > "+" in a custom URL. Butt least here what you type and what you get are > consistent. > > > Any thoughts? > -Matt > > -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts nom?s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. From jm at poure.com Mon Jun 30 14:05:52 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Mon, 30 Jun 2008 16:05:52 +0200 Subject: [development] Drupal could be 10x times faster with correct indexing Message-ID: <1214834752.8415.10.camel@debian> Dear friends, Today my Drupal 6.2 server was flooded and I discovered that there was a real lack of indexing in Drupal. Here is the issue with solutions: http://drupal.org/node/276742 When using MySQL, you don't really know how SQL queries are treated, except execution times that may be monitored (?). On the converse, PostgreSQL offers full logging of queries and access to query plans, showing how the database executes data. In the above issue, I could speed-up a simple query by 10 times. You may not notice this issue when using small Drupal sites (because the whole database executes in shared memory) or when using Drupal with caching. But ... on large installations like mine, you cannot cache everything without a huge amount of memory. And the result is SLOW. Using PostgreSQL, normal queries should run in less than one millisecond, usually 0,2 millisecond. Long queries with difficult JOINS should run in less that 5 milliseconds. This way, the database server is always faster than anay kind of PHP cache. And you can use large sites on small sites. There is an extensive query debugging needed on Drupal: 1) Turn on extensive logging in PostgreSQL, including query execution times. 2) Whenever a query executes in more than 1 millisecond, run psql or pgAdmin (graphical client) to run EXPLAIN ANALYSE. 3) Find sequential scans and fix them. Most of times, JOINS and clauses and ORDER BY should be on indexes. 4) Add proper indexing 5) Run EXPLAIN ANALYSE again. Times usualy are divided by 10. 6) Add indexes everywhere. After this hard work, a normal Drupal 6.2 installation should be able to answer thousands of queries. Do not hesitate to answer my issue : ?http://drupal.org/node/276742 The issue offers a pratical example. Again, this kind of problem will only show on large sites (like Drupal.org), not a small installation. But I consider this as a bug, a very important issue which should be fixed ASAP. Kind regards, Jean-Michel Pour? From robert at middleswarth.net Mon Jun 30 15:44:26 2008 From: robert at middleswarth.net (Robert Middleswarth) Date: Mon, 30 Jun 2008 11:44:26 -0400 Subject: [development] Drupal Function Frequency Report? In-Reply-To: <48677CA3.2010208@webchick.net> References: <48677CA3.2010208@webchick.net> Message-ID: <4868FF5A.4000601@middleswarth.net> I agree for the most part with Angela. I started Piece mail learning drupal and just didn't get what Drupal was doing so at best I was copy and past code segments not understanding why they worked. I read Pro Drupal Development and it helped some but I found that "Learning Drupal 6 Module Development" layed it out how things worked together for me and taught me the basics and showed me real world ways of doing things something Pro Drupal Development didn't do. Don't get me wrong I now reference both book and for something Pro Drupal Development is great but to me it is more a reference book for the most common commands then a good book to teach you the in's and out's of Drupal. Thanks Robert Angela Byron wrote: > Marjorie Roswell wrote: >> Seriously, would love to basically tackle this learning curve in a >> logical way, based on how often something appears in code, ideally in >> both core and contrib, combned. > > Honestly, the best way to tackle the Drupal development learning curve > is just to shell out 30 smackers for Pro Drupal Development (use the > "Buy" link at http://www.drupalbook.com/; the Drupal Association gets > a little bit of a cut). > > Trying to learn functions piecemeal like that is going to leave you > with a bit of a "swiss cheese" understanding of how things fit > together, and further frustration as you go along. PDD is great > because it guides you "top down" through all of Drupal's various > sub-systems. I'd been developing with Drupal heavily for over 2 years > when I first read it and it still managed to cement a bunch of > fundamentals for me and really help me see how everything fit together. > > The one caveat is that there's a 2nd edition due out in late August on > Drupal 6. So you'll probably end up re-buying the book again in the > fall if you buy it now. However, my guess is that if you could cut the > time spent suffering the Drupal learning curve by 1000 hours, you can > probably make that $30 up in a quick dash of client work real soon. ;) > > Also, I've not had a chance to really sit down and read it yet, but in > paging through, the book "Learning Drupal 6 Module Development" looks > like it would be a good second book to pick up once you get the > concepts in PDD down and want to start actually building things. > > -Angie > From david at fourkitchens.com Mon Jun 30 18:29:53 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Mon, 30 Jun 2008 13:29:53 -0500 (CDT) Subject: [development] Drupal could be 10x times faster with correct indexing In-Reply-To: <1626237312.160451214850425660.JavaMail.root@mail-2.01.com> Message-ID: <1572746172.160961214850593372.JavaMail.root@mail-2.01.com> When it comes to database capabilities, MySQL is quite a bit more than a glorified card catalog. When it comes to database architecture, Drupal developers are quite a bit more than rejected Microsoft Access programmers. ----- "Jean-Michel Pour?" wrote: > Here is the issue with solutions: > http://drupal.org/node/276742 >From the issue, it seems like your indexes are missing or misconfigured. > When using MySQL, you don't really know how SQL queries are treated, > except execution times that may be monitored (?). Wrong. Use EXPLAIN. > This way, the database server is always faster than any kind of PHP cache. Wrong. Databases have higher latency for even simple queries compared to PHP static caching and memcache. > There is an extensive query debugging needed on Drupal: > [...] > 6) Add indexes everywhere. Wrong. Indexes add multiple forms of overhead. They should not be added gratuitously. Indexes should be added when they enhance performance more than they cost it or if they enhance data integrity (UNIQUE/PRIMARY keys). > [...] I consider this as a bug, [...] Wrong. Bugs are issues of correctness. Performance improvements are not issues of correctness. From caleb.gilbert at gmail.com Mon Jun 30 19:37:04 2008 From: caleb.gilbert at gmail.com (Caleb Gilbert) Date: Mon, 30 Jun 2008 12:37:04 -0700 Subject: [development] Code freeze? Message-ID: <38ad0b0a0806301237y534463a0q2b8691d42e6272a4@mail.gmail.com> Indeed this does go to a lot of people. Please try not to feel compelled to try and censor things that someone else might feel compelled to share -- especially if they are particularly exited and upbeat about something the community is doing. Some people might call this sharing, "feedback", and see value in receiving it. Regards, - Caleb This list goes to a lot of people. Please try to make your posts more substantive than "I agree!" ----- "Caleb Gilbert" wrote: > Reading this thread has me very excited - what a great decision to extend the code freeze of Drupal 7 for a while! In particular, I enjoyed/share chx's comment that 'Drupal 5/6 is quite good enough to hang-a-reputation-on for some time to come'. Indeed they are. :-) > > - Caleb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080630/d56b8fa3/attachment.htm From david at fourkitchens.com Mon Jun 30 20:16:10 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Mon, 30 Jun 2008 15:16:10 -0500 (CDT) Subject: [development] upload module or maybe url() bug In-Reply-To: <1821616247.184811214856817132.JavaMail.root@mail-2.01.com> Message-ID: <123367545.185441214856970424.JavaMail.root@mail-2.01.com> See this issue: http://drupal.org/node/191116 Translating spaces to "+" is not RFC-compliant. For maximum compatibility, you should encode both spaces and plus signs using % notation. ----- "Matt Connolly" wrote: > I have a question about url encoding > > Spaces in URLS are normally translated to "%20" and spaces in queries > > are normally translated into "+", although the "%20" is correctly > decoded. > > I'm discovering that private file uploads are not working when there > > is a "+" in the file name. This is being translated into a " " (space) > > which is quite normal for queries. > > With public downloads, (ie accessibly directly via > http://mydrupalsite/sites/files/fred+wilma.jpg > " the file works. So apache doesn't translate the + in the file's path > > name into a space, and the file is downloaded. > > With private downloads, the file name is placed into a query, thanks > > to mod_rewrite (or, becomes > http://mydrupalsite/q?=system/files/fred+wilma.jpg > " . You can see where the problem is. > > > I can easily fix this by altering the "file_create_url" function in "/ > > includes/file.inc". I know I've been warned to not change drupal's > core modules and code, but ..... I think I need to. > > However, I wonder if the problem would be better handled in the > "url()" function? > > I notice that if you create page url's "bananas+pears" and "apples and > > oranges" the urls are all encoded with %20. So it seems you can't use > > the "+" in a custom URL. Butt least here what you type and what you > get are consistent. > > > Any thoughts? > -Matt From david at fourkitchens.com Mon Jun 30 20:35:21 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Mon, 30 Jun 2008 15:35:21 -0500 (CDT) Subject: [development] Drupal could be 10x times faster with correct indexing In-Reply-To: <1572746172.160961214850593372.JavaMail.root@mail-2.01.com> Message-ID: <1486801252.191851214858121639.JavaMail.root@mail-2.01.com> My reply may have been overly blunt, but it's insulting to have someone post to our development list promising a 10x performance boost from methods we've clearly considered and implemented. Development work and discussion surrounding database indexes is easy to find with a quick search of Drupal.org. ----- "David Timothy Strauss" wrote: > When it comes to database capabilities, MySQL is quite a bit more than > a glorified card catalog. When it comes to database architecture, > Drupal developers are quite a bit more than rejected Microsoft Access > programmers. > > ----- "Jean-Michel Pour?" wrote: > > > Here is the issue with solutions: > > http://drupal.org/node/276742 > > From the issue, it seems like your indexes are missing or > misconfigured. > > > When using MySQL, you don't really know how SQL queries are > treated, > > except execution times that may be monitored (?). > > Wrong. Use EXPLAIN. > > > This way, the database server is always faster than any kind of PHP > cache. > > Wrong. Databases have higher latency for even simple queries compared > to PHP static caching and memcache. > > > There is an extensive query debugging needed on Drupal: > > [...] > > 6) Add indexes everywhere. > > Wrong. Indexes add multiple forms of overhead. They should not be > added gratuitously. Indexes should be added when they enhance > performance more than they cost it or if they enhance data integrity > (UNIQUE/PRIMARY keys). > > > [...] I consider this as a bug, [...] > > Wrong. Bugs are issues of correctness. Performance improvements are > not issues of correctness. From syscrusher at 4th.com Mon Jun 30 20:51:08 2008 From: syscrusher at 4th.com (Syscrusher) Date: Mon, 30 Jun 2008 16:51:08 -0400 Subject: [development] Drupal could be 10x times faster with correct indexing In-Reply-To: <1214834752.8415.10.camel@debian> References: <1214834752.8415.10.camel@debian> Message-ID: <1214859068.25265.12.camel@marcus> On Mon, 2008-06-30 at 16:05 +0200, Jean-Michel Pour? wrote: > When using MySQL, you don't really know how SQL queries are treated, > except execution times that may be monitored (?). > What's wrong with MySQL's standard EXPLAIN command? :-) Not to knock PostgreSQL -- I use and like both databases. But EXPLAIN provides very similar information to PostgreSQL's query plan. Scott -- Syscrusher From matt at cabinetuk.com Mon Jun 30 21:42:33 2008 From: matt at cabinetuk.com (Matt Connolly) Date: Mon, 30 Jun 2008 22:42:33 +0100 Subject: [development] upload module or maybe url() bug In-Reply-To: <123367545.185441214856970424.JavaMail.root@mail-2.01.com> References: <123367545.185441214856970424.JavaMail.root@mail-2.01.com> Message-ID: <6E63E7B9-EE6A-4C55-B63F-1FA68CBB396A@cabinetuk.com> The + in the file name is being translated into a space and the file download does not work because the file is not found. When I change the code, as I have, by including a url_encode function on the filename, it all works perfectly. My question really is: should this be specifically for the file download - like how I have patched my drupal installation, or is it better served in the url() function if this would also solve other urls in the site (page names, etc) -Matt On 30/06/2008, at 9:16 PM, David Timothy Strauss wrote: > See this issue: > http://drupal.org/node/191116 > > Translating spaces to "+" is not RFC-compliant. For maximum > compatibility, you should encode both spaces and plus signs using % > notation. > > ----- "Matt Connolly" wrote: > >> I have a question about url encoding >> >> Spaces in URLS are normally translated to "%20" and spaces in queries >> >> are normally translated into "+", although the "%20" is correctly >> decoded. >> >> I'm discovering that private file uploads are not working when there >> >> is a "+" in the file name. This is being translated into a " >> " (space) >> >> which is quite normal for queries. >> >> With public downloads, (ie accessibly directly via >> http://mydrupalsite/sites/files/fred+wilma.jpg >> " the file works. So apache doesn't translate the + in the file's >> path >> >> name into a space, and the file is downloaded. >> >> With private downloads, the file name is placed into a query, thanks >> >> to mod_rewrite (or, becomes >> http://mydrupalsite/q?=system/files/fred+wilma.jpg >> " . You can see where the problem is. >> >> >> I can easily fix this by altering the "file_create_url" function in >> "/ >> >> includes/file.inc". I know I've been warned to not change drupal's >> core modules and code, but ..... I think I need to. >> >> However, I wonder if the problem would be better handled in the >> "url()" function? >> >> I notice that if you create page url's "bananas+pears" and "apples >> and >> >> oranges" the urls are all encoded with %20. So it seems you can't use >> >> the "+" in a custom URL. Butt least here what you type and what you >> get are consistent. >> >> >> Any thoughts? >> -Matt From david at fourkitchens.com Mon Jun 30 22:29:04 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Mon, 30 Jun 2008 17:29:04 -0500 (CDT) Subject: [development] upload module or maybe url() bug In-Reply-To: <226776862.218651214864826530.JavaMail.root@mail-2.01.com> Message-ID: <633364551.218751214864944612.JavaMail.root@mail-2.01.com> I'd try an extra step to encode "+" characters in your URLs. I would support adding such a feature to Drupal's url() if it makes the encoding less ambiguous. ----- "Matt Connolly" wrote: > The + in the file name is being translated into a space and the file > > download does not work because the file is not found. > > When I change the code, as I have, by including a url_encode function > > on the filename, it all works perfectly. > > My question really is: should this be specifically for the file > download - like how I have patched my drupal installation, or is it > better served in the url() function if this would also solve other > urls in the site (page names, etc) > > -Matt > > On 30/06/2008, at 9:16 PM, David Timothy Strauss wrote: > > > See this issue: > > http://drupal.org/node/191116 > > > > Translating spaces to "+" is not RFC-compliant. For maximum > > compatibility, you should encode both spaces and plus signs using % > > > notation. > > > > ----- "Matt Connolly" wrote: > > > >> I have a question about url encoding > >> > >> Spaces in URLS are normally translated to "%20" and spaces in > queries > >> > >> are normally translated into "+", although the "%20" is correctly > >> decoded. > >> > >> I'm discovering that private file uploads are not working when > there > >> > >> is a "+" in the file name. This is being translated into a " > >> " (space) > >> > >> which is quite normal for queries. > >> > >> With public downloads, (ie accessibly directly via > >> http://mydrupalsite/sites/files/fred+wilma.jpg > >> " the file works. So apache doesn't translate the + in the file's > > >> path > >> > >> name into a space, and the file is downloaded. > >> > >> With private downloads, the file name is placed into a query, > thanks > >> > >> to mod_rewrite (or, becomes > >> http://mydrupalsite/q?=system/files/fred+wilma.jpg > >> " . You can see where the problem is. > >> > >> > >> I can easily fix this by altering the "file_create_url" function in > > >> "/ > >> > >> includes/file.inc". I know I've been warned to not change drupal's > >> core modules and code, but ..... I think I need to. > >> > >> However, I wonder if the problem would be better handled in the > >> "url()" function? > >> > >> I notice that if you create page url's "bananas+pears" and "apples > > >> and > >> > >> oranges" the urls are all encoded with %20. So it seems you can't > use > >> > >> the "+" in a custom URL. Butt least here what you type and what > you > >> get are consistent. > >> > >> > >> Any thoughts? > >> -Matt From david at fourkitchens.com Mon Jun 30 22:41:24 2008 From: david at fourkitchens.com (David Timothy Strauss) Date: Mon, 30 Jun 2008 17:41:24 -0500 (CDT) Subject: [development] upload module or maybe url() bug In-Reply-To: <633364551.218751214864944612.JavaMail.root@mail-2.01.com> Message-ID: <1562326950.220141214865684830.JavaMail.root@mail-2.01.com> We should already be escaping the plus signs: http://drupal.org/node/191116#comment-627128 ----- "David Timothy Strauss" wrote: > I'd try an extra step to encode "+" characters in your URLs. I would > support adding such a feature to Drupal's url() if it makes the > encoding less ambiguous. > > ----- "Matt Connolly" wrote: > > > The + in the file name is being translated into a space and the file > > > > download does not work because the file is not found. > > > > When I change the code, as I have, by including a url_encode > function > > > > on the filename, it all works perfectly. > > > > My question really is: should this be specifically for the file > > download - like how I have patched my drupal installation, or is it > > better served in the url() function if this would also solve other > > urls in the site (page names, etc) > > > > -Matt > > > > On 30/06/2008, at 9:16 PM, David Timothy Strauss wrote: > > > > > See this issue: > > > http://drupal.org/node/191116 > > > > > > Translating spaces to "+" is not RFC-compliant. For maximum > > > compatibility, you should encode both spaces and plus signs using > % > > > > > notation. > > > > > > ----- "Matt Connolly" wrote: > > > > > >> I have a question about url encoding > > >> > > >> Spaces in URLS are normally translated to "%20" and spaces in > > queries > > >> > > >> are normally translated into "+", although the "%20" is correctly > > >> decoded. > > >> > > >> I'm discovering that private file uploads are not working when > > there > > >> > > >> is a "+" in the file name. This is being translated into a " > > >> " (space) > > >> > > >> which is quite normal for queries. > > >> > > >> With public downloads, (ie accessibly directly via > > >> http://mydrupalsite/sites/files/fred+wilma.jpg > > >> " the file works. So apache doesn't translate the + in the file's > > > > >> path > > >> > > >> name into a space, and the file is downloaded. > > >> > > >> With private downloads, the file name is placed into a query, > > thanks > > >> > > >> to mod_rewrite (or, becomes > > >> http://mydrupalsite/q?=system/files/fred+wilma.jpg > > >> " . You can see where the problem is. > > >> > > >> > > >> I can easily fix this by altering the "file_create_url" function > in > > > > >> "/ > > >> > > >> includes/file.inc". I know I've been warned to not change > drupal's > > >> core modules and code, but ..... I think I need to. > > >> > > >> However, I wonder if the problem would be better handled in the > > >> "url()" function? > > >> > > >> I notice that if you create page url's "bananas+pears" and > "apples > > > > >> and > > >> > > >> oranges" the urls are all encoded with %20. So it seems you can't > > use > > >> > > >> the "+" in a custom URL. Butt least here what you type and what > > you > > >> get are consistent. > > >> > > >> > > >> Any thoughts? > > >> -Matt