- Development - lists.drupal.org

Re: [development] comments as nodes
by Michelle Cox 04 Jun '07

04 Jun '07

This is very interesting. I'm currently using the userreview module instead of fivestar, even though I'd prefer a star rating, because it lets you comment and rate at the same time. I'm interested in trying your approach, but I'm concerned about totally replacing the comment module. Have you run into any problems with things that use comments such as forums? Especially when using flatforum? I'm getting totally off topic for the dev list... If you prefer, I could file an issue with my question. Or you can email me directly if you don't mind doing that. This sounds really cool, but I'm nervous about replacing a core module like that. Michelle On 6/4/2007 10:56:52 AM, Robert Douglass (rob(a)robshouse.net) wrote: > One of the most useful applications that this module has found is also > the impetus for its creation: voting widgets in the comments that vote > on the parent node. > I'm creating a site, for example, where the comments > are all ratings of the parent node, and each comment needs to have four > separate fivestar widgets. To do this, the comment node type has four > CCK fields from the fivestar module where the target of the voting is > set as arg(1)... meaning the fields belong to the comment nodes but the > votes belong to the parent node. Very cool.

4 3

Reducing file handles
by Sean Robertson 04 Jun '07

04 Jun '07

Is there anything that can be done to reduce the number of file handles produced by Drupal databases? We run numerous Drupal sites (currently ~50, will likely end up closer to 200) on a two files servers with a load balancer and a separate MySQL database server. Usually, the bottleneck in MySQL is in connections, but we found that as we started moving sites over to the new setup, we very quickly ran into the default file handle limit. We've increased that limit and seen no adverse effects yet, but I expect we will as we continue setting up new sites (with each site adding a new database and ~100 tables to the db server). What is the best way to deal with that issue? Is there any way to reduce file handles in Drupal? Would innoDB help us any more than MyISAM or would that only help us with speeding up our busiest individual sites? I am getting increasingly concerned about scalability as we approach the next campaign cycle and I expect we will have at least a few sites that draw a LOT of traffic (we had carterfornevada.com last year which regularly drew 5k+ unique visits per day, often in sudden surges thanks to the wonderful blogging efforts of Sarah Carter). -- Sean Robertson Web Developer NGP Software, Inc. seanr(a)ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com

1 0

Documentation needed: new format for update_N hooks
by Angela Byron 04 Jun '07

04 Jun '07

Post-schema API, I assume we no longer do crappy stuff like this in our update_N hooks: switch ($_GLOBALS['db_type']) { case 'mysql': // blah... case 'pgsql': // blah.. } and probably are now supposed to use db_$FOO functions...but we really need some kind of instructions at the module update page (http://drupal.org/node/114774) I'll volunteer to write this, but I need to know: a) Is system_update_6022 a good example on how to perform database updates post-schema patch? b) If so, would a reasonable way to document this be to take the update code from http://drupal.org/node/115267#comment-249052 and compare it with this? Thanks... -Angie

4 4

Re: [development] Foreign keys in Drupal 6
by Chad Phillips -- Apartment Lines 04 Jun '07

04 Jun '07

> On 04 Jun 2007, at 05:14, David Strauss wrote: > >> Assuming the foreign keys patch to the schema API makes it in, >> there are >> four ways we can approach foreign keys in Drupal 6. >> >> 1. Don't use them at all. Just provide the schema API for contrib >> modules with higher database requirements than core. >> >> 2. Configure foreign keys as RESTRICT on delete. This will have no >> effect on MyISAM, but it will improve code quality because operations >> creating inconsistency would fail. Such operations would then be >> rewritten to manipulate the database in a consistent way. >> >> 3. Configure foreign keys as CASCADE on delete and have extra PHP run >> whenever a query manipulates a database using MyISAM. Basically, >> whenever a DELETE query gets sent to a MyISAM system, we would >> convert >> it to a SELECT query to identify the rows that would be deleted. >> Then, >> we would delete the records attached with foreign keys. Finally, we >> would run the original DELETE query. This would have to be recursive. >> >> 4. Configure foreign keys as CASCADE on delete and have modules >> conditionally run queries in their deletion hooks depending on the >> storage engine. If a module doesn't check the storage engine type, >> the >> DELETE it runs would simply be redundant. #2 also seems like the most sensible to me for Drupal 6.

1 0

Fun CCK idea.
by adrian rossouw 04 Jun '07

04 Jun '07

I was thinking it would be cool if we could have a way for CCK node types to be defined by modules. The same way that modules can provide default views. A quick way to do this would be to just have a module that generates a module for node types, generating the .info, and the .install .. and probably a dummy .module. this could really help with install profiles.

10 16

Drupal 6 code freeze
by Dries Buytaert 03 Jun '07

03 Jun '07

Hello world, we're moving forward at full speed, and it would be a pity to suddenly abrupt that, wouldn't it? As there are still many interesting patches in the queue that are almost there, and because we cranked out new stuff like crazy, I decided that it would be best to postpone the code freeze for 4 weeks. This is a one-time extension that leaves us some more time to finish some of the work that we started, and to put some more polish in place. Even with another 4 weeks, it is unlikely that all the key patches will make it into Drupal 6 so let's not waste time and keep up the steady pace of contributions (good job!). Also, keep in mind that towards the end of June, I'll be traveling a fair bit so I won't be able to review as many patches as usual. Last but not least, I'm going to give priority to those patches that were already in the works before today. Happy hacking, -- Dries Buytaert :: http://www.buytaert.net/

5 5

Google Gears
by Dries Buytaert 03 Jun '07

03 Jun '07

http://radar.oreilly.com/archives/2007/05/google_releases.html http://gears.google.com/ -- Dries Buytaert :: http://www.buytaert.net/

14 21

Re: [development] Google Gears
by Michelle Cox 03 Jun '07

03 Jun '07

Actually, I would love the ability to have my site offline synched easily to my site online. There aren't a lot of hotspots in my town, especially at the places that have kiddie stuff to keep my son entertained. I made a local copy of my site, but it's a PITA to keep it updated so I usually don't bother. Something like what has been talked about here would be awesome. Not something I'm in a position to help create, though, so it's just a wish on my part. Michelle On 5/31/2007 7:16:58 AM, Robin Monks (robin(a)civicspacelabs.org) wrote: > The weird thing is, with the dawn of cheap broadband, and wifi-covered > cities, planes, trains and buses, noone is actually offline to enjoy this > now. > > Robin > > On 5/31/07, Victor Kane <victorkane(a)gmail.com> wrote: > > > > well, one possibility is php gtk, see http://gtk.php.net/ (there is a > > data persistence layer in gears) > > But I > wasn't speaking only of using Gears itself, but rather of the > > paradigm shift to rich clients, with offline support. > > On the one hand stuff like Apollo, on the other ... if we have Drupal on > > a > > stick, we can have Drupal on a rich client. > > The paradigm shift of web apps recycled as rich client apps can be seen > > on > > many fronts, for example in the world of light, agile J2EE, the Spring > > Framework has the Rich Client sub-project (see > > http://www.springframework.org/spring-rcp) > > > > Victor Kane > > http://awebfactory.com.ar > > > > On 5/31/07, adrian rossouw <adrian(a)bryght.com> wrote: > > > > > > > > > On 31 May 2007, at 11:05 AM, Victor Kane wrote: > > > > > > use case is manage content, prepare a new edition of a site all ready > > > to > > > synchronize with on line edition...

4 4

coder and 6.x core remaining upgrades
by Doug Green 02 Jun '07

02 Jun '07

f you're working on core for 6.x, I'd like you to know that http://drupal.org/project/coder <http://drupal.org/project/coder's%206.x> 's 6.x upgrade review is now current. The HEAD version of coder works on the current Drupal HEAD, and if you run it on Drupal core itself it finds about 30 problems ranging including many argument changes to l(), url(), watchdog t()'s no longer needed. Since these upgrades span several modules and since I'm not aware of the fix really needed (for example, #multistep in poll.module), it seemed more appropriate just to let the core developers know that there are a few minor issues, and that coder should help you find many of them. :-) Thanks to the entire CivicActions engineering team that helped write these rules. Doug Green 904-583-3342 www.douggreenconsulting.com Bringing Ideas to Life with Software Artistry and Invention... Providing open source software political solutions

2 2

FormAPI 3: State of the Union
by Jeff Eaton 02 Jun '07

02 Jun '07

The FormAPI 3 patch that landed early this month has added some significant capabilities to the API and smoothed out rough edges that have been around since Drupal 4.7. With the code freeze 4 weeks off we have a bit more breathing space, and I wanted to give folks a heads up on a small handful of high-importance FAPI patches that are still in the queue. http://drupal.org/node/121620 This patch takes some of the hard-coded logic in form_builder() -- the stuff that handles how form elements are populated from incoming $_POST values -- and allows each form element type to implement custom handling code in a function, not unlike the submit and validate functions. This sounds simple, but is a BIG advance towards simplification of CCK fields and custom element types. http://drupal.org/node/146187 We've long juggled $_POST and $form_values when dealing with forms. This patch ensures that the raw post data is stored in $form_state in addition to the finessed $form_values. It also clarifies one of the tricky bits about drupal_execute() -- although it currently *says* that it takes a form values collection for processing, it REALLY treats that passed-in data like raw post values. With some complex forms, this causes odd issues. After this patch, drupal_execute() operates on $form_state['post'] for greater clarity. http://drupal.org/node/146667 This patch is ginormous, but implements a very simple pair of changes. First, $form_state should always be the FIRST parameter for a form building function, rather than the LAST. Without this change, form building code triggered via a menu callback will break if bogus parameters are passed in after the normal path. In addition, it eliminates the legacy $form_values variable, and points people instead to always use the standard, always-available $form_state ['values'] data. Reviews and testing are appreciated; the quest to streamline the API continues. Hoorah! --Jeff Eaton

2 2