- Development - lists.drupal.org

Multiple similar Forms on same page
by Ernst Plüss 01 Jun '07

01 Jun '07

Hi All I'd like to show the same form multiple times on one page. I tried to do this by calling drupal_get_form in a loop. Unfortunately this doesn't work since drupal makes them 100% identical (same form id and form-token) which means up on submition drupal cannot tell which form has sent the answer. Note that the forms are not 100% identical, they differ by things like item id and selection options. This is handled in the form building function. What's the right way of implementing this? Best Regards Ernst

1 1

To make Drupal even more SEO friendly...
by Karoly Negyesi 01 Jun '07

01 Jun '07

and get a per language path alias interface AND gain some wiki-like features as a nice side effect, we need http://drupal.org/node/147143 Please take a look! Moshe already RTBC'd it but at this time I really would like to see more support for it so we can squeeze this in to D6. Also, thanks goes to Gurpartap Singh for taking my patch and running with it. Regards, NK

2 1

Modules up for adoption
by Jeff Eaton 01 Jun '07

01 Jun '07

With the work going into Drupal 6 development, work, and a number of other modules, I've been looking over my list of contrib projects and admitting that I simply don't have enough hours in the day to maintain all of them effectively. I'm actively seeking maintainers and co-maintainers for the following modules. Drop me a line if you're interested in any of them and we can chat. If you're familiar with Drupal code and want to make a splash, a number of them offer some cool opportunities. Maintainers sought * Akismet -- The Wordpress anti-spam API. Insert Block -- Inserts blocks in node bodies using [this] syntax Insert View -- Inserts blocks in node bodies using [this] syntax Latest and greatest -- Cast votes on aggregator items. Loves and Hates -- Cast votes on taxonomy terms * Node Moderation -- Complex role-weighted voting for nodes Related Nodes -- Taxonomy-based 'similar nodes' block Co-maintainers sought Custom Breadcrumbs -- Create customized breadcrumb trails for each node type Custom Links -- Add links to nodes without code * Custom Pagers -- Forum/Book/Gallery style pagers for nodes in views * VotingAPI -- A backend API for voting and rating modules Most of these modules would need someone with moderate Drupal familiarity, but aren't particularly huge or complex as modules go. Starred modules are more complex and/or tricky, and would need someone with experience working on other modules and solid familiarity with Drupal's APIs and code standards. Most of the modules in the 'Maintainers sought' category (Akismet is one exception) haven't been upgraded to Drupal 5, or are in progress; I just haven't had time or had the need to. Most of them (Akismet excepted, probably) will become unmaintained after the Drupal 6 release unless someone else wants to pick them up. Modules in the 'Co-maintainers sought' category are all running smooth on Drupal 5, but my attention is divided enough that patches, fixes, and new features only get sporadic attention. I'm hoping to find other folks who share a similar vision for their future directions. If anyone is interested, drop me a line. Thanks! --Jeff

1 0

$node namespace woes -- can we fix this in D6?
by Derek Wright 01 Jun '07

01 Jun '07

hello world, i've had a series of bugs in the project* issue queues[1] caused by the fact that the project* modules use $node->pid just like "pid" always means in the project* codebase: the project id, or the nid of the project node that the (release|issue|...) belongs to. however, book.module thinks $node->pid is the nid of the parent page in the book hierarchy. :( so, all hell breaks loose when you try to put a release node into a book outline. certainly other contribs might use $node->pid to mean all sorts of things, too, which would conflict with both project* and book.module. i could always just hack project* to always prefix everything it tries to stuff into or read from $node with some kind of custom variable name prefix, like calling this "$node->project_issue_pid" instead of just "$node->pid". however, given that the API isn't quite frozen for D6 yet, i'm wondering if there's anything smarter and better we could do via the core API, instead of relying on convention and luck to avoid this problem... 1) what's the right way to handle variable namespaces in the $node object? can/should we change hook_nodeapi('load') to force people to use a namespace of some kind when populating $node? maybe $node should be a nested array instead of an object, so that everyone touches: $node[$module_name][$variable_name] instead of just: $node->variable_name ?? that probably sucks for all sorts of reasons, i'm just quickly brainstorming here... 2) presumably this has come up before? anyone have pointers to relevant old issues or threads? i don't remember seeing anything like this come up before, but i've been known to miss the occasional thread on this list. ;) 3) anyone else interested in making a little push to try to do this for D6? 4) would the D6 core maintainers be willing to commit a patch if it materialized and was properly reviewed/tested/RTBC'ed? thanks, -derek (dww) [1] for the interested reader: http://drupal.org/node/98278 http://drupal.org/node/124846 http://drupal.org/node/145782

12 19

PHP5 going forward
by Ken Rickard 31 May '07

31 May '07

All- I received a private note from Larry Garfield this morning based on something I posted online, so it's time to make it more public. Jonah Braun, who is on Joomla's security team and the 1,5 core team works in my office. When I came back from DrupalCON, I toid him that Rasmus had asked Drupal to drop support for PHP4. Jonah immediately took to the idea, and here's what he saw as the challenges. Two problems with dropping PHP4 support: 1) Many hosts (including mine) only support 4.x 2) If one project (Drupal) drops it but the other doesn't (Joomla), the audience (both developers and users) may abandon the project that drops PHP4. Jonah's modest proposal: An agreement to set a release version (or date) where major PHP-based projects drop PHP4 support. Larry, always ambitious, suggested that we get WordPress and Galley involved, too. I can very clearly see the advantage to projects setting an arbitrary date (say, January 1, 2008) after which we don't officially support PHP4. THis wouldn't say that we try to break PHP4, simply that new feature development (and patch support and security updates) require PHP 5. So consider this a modest proposal to get folks thinking about how to move forward together. I already passed Larry on to Jonah to see who might make that decision on the Joomla side. - Ken Rickard agentrickard

18 24

User Password Hashing
by Doug Green 31 May '07

31 May '07

There's been a rather long discussion of password security related to the hash algorithm. Given that this discussion began during the 5.x push and given its security implications, I'm risking breaking protocol and asking for a review. The thread has reached some agreement, but there are some implementation questions, one of which can really only be answered by a handful of people. http://drupal.org/node/29706 Thanks! Doug Green 904-583-3342 www.douggreenconsulting.com www.civicactions.com <http://www.civicactions.com/> Changing the world one node at a time!

1 0

Wordpress HyperDB
by James Walker 30 May '07

30 May '07

Hey folks, interesting (I think) announcement in the wordpress world this week that we may want to keep an eye on: http://comox.textdrive.com/pipermail/wp-hackers/2007-May/012893.html They're releasing the DB class used on wordpress.com which includes some of the following features: * Replication * Failover * Redundant (public/private) networks * Local and remote datacenters * Partitioning * Different tables on different DBs * Advanced stats for profiling That'd be a great list (for large-scale drupal sites) to have in our own abstraction layer, I think. One to keep an eye on... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net

2 1

We love sequences
by Karoly Negyesi 30 May '07

30 May '07

Or maybe not. Let me quote Moshe from http://lists.drupal.org/pipermail/development/2005-December/012108.html "A long time ago, we made a big effort to be database independent and introducing our own sequences feature was part of that. We wanted to welcome all RDMS, even those without sequences." Let's see mysql -- native (auto_increment modifier) SQLite -- native (auto_increment modifier) postgresql -- native (serial type backed by sequences) Oracle -- doable (via sequences and a trigger) MSQQL -- native (identity type) DB2 -- doable (DEFAULT NEXT_VALUE OF sequence) Firebird -- doable (generator, trigger) MS Access -- native (autoincrement type) Surely I have not covered all possible RDBMSes and the above might contain errors, I just spent ten minutes with googling this together. But still. It seems that most RDBMSes that we considered supporting support these. To continue quoting Moshe, "I'd support a patch that removed drupal sequences in favor of built in auto-increment and such." Let's hope he is not alone because http://drupal.org/node/49836#comment-251682 now contains such a patch. Regards, NK

2 1

Re: [development] Fieldsets for profile variables
by Mike Anon 30 May '07

30 May '07

Mark Leicester <mark.leicester(a)efurbishment.com> wrote: > Yes, I've also found the need for the sort of thing you describe. I > have a working implementation that allows the arbitrary grouping of > fields into fieldsets, where those fieldsets may be assigned and > weighted within any category including the account page itself. I left the account validation in. (Actually it is the account restriction.) So adding to the account page isn't something I had contemplated. > Like > you I only allow a single level of fieldset. I use an extra table to > group fields by a fieldset name in the same way that the current > implementation groups by category names. Well, the current implementation of category names is a bit less than what you describe you have implemented for fieldsets. At least in 4.7. It is merely an additional field within the profile fields table and there is no weighting allowed. Hence, the categories are displayed in alphabetical order. In addition to setting up a separate table, which I called profile_fieldsets, I just included a parent field in the table so the code can be expanded at some point. > My admin interface is > incomplete as yet (clients were happy to have it configured manually > and then left alone). My UI is a clone of the way that the profile fields themselves are input. In essence, I just copied the profile module, renamed it profilefieldsets, stripped out everything from the resulting module that dealt with the user level and kept things that dealt with the profile fields, modifying it to deal with profile fieldsets. > I've also added radio buttons to the available profile field types. In what context? > It sounds like we're more or less at the same place. Shall we compare > notes? Absolutely. I'll send you what I have off list, unless you think it should be shared here for others to comment upon. Thanks for the response, Mark. mike

2 1

Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
by Ashraf Amayreh 29 May '07

29 May '07

This is mainly for Dries and Andy. The case by case approach seems to be a logical solution to this problem. And the modules that may request this are a very limited, so it goes without saying this won't bog someone down and make CVS admins' lives miserable. Can we agree on who should be contacted to negotiate inclusion of customized external code? That sounds much better than just going back and forth without really achieving an end result. On 5/26/07, Michael Hess <mlhess(a)umich.edu> wrote: > > -Make the first module dependent on the second with clear instructions > > about where to get it from. > <http://tinymce.moxiecode.com/download.php> > > TinyMCE,already does this for some other CMS's > > >

8 8