February 2006 - Development - lists.drupal.org

18 critical bugs left
by Dries Buytaert 18 Mar '06

18 Mar '06

We're down to 18 critical bugs! :) URL to bookmark: http://drupal.org/project/issues? projects=3060&versions=9902,9842,9753,9728,6487&categories=bug&prioritie s=1&states=1,8,13,14 -- Dries Buytaert :: http://www.buytaert.net/

13 27

Forms.module for 4.7
by Boris Mann 09 Mar '06

09 Mar '06

See this? http://www.jotform.com/index My personal idea (i.e. handwaving) for forms.module for 4.7 is that it would provide support functions to be able to build forms on the fly. Both Survey.module and perhaps CCK (e.g. for custom built node/ add forms) would use forms.module for this functionality. Thoughts on this? Anyone feel like pooling resources/funds to get this built? -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com

12 20

OpenID
by Jonathan Daugherty 08 Mar '06

08 Mar '06

Greetings, A few months ago, a co-worker of mine created a Drupal module to support OpenID logins. The module was based on Dan Libby's PHP OpenID library. For anyone wanting to catch up, it was discussed here: http://drupal.org/node/33254 Some other OpenID discussion is here: http://drupal.org/node/23256 I've taken over the development of the module and I've updated the module to use the JanRain PHP OpenID implementation, which is a feature-complete port of our Python library. Our PHP library can be found here: http://www.openidenabled.com/openid/libraries/php Here is a link to the current module source, which is under fairly heavy development: http://www.openidenabled.com/resources/downloads/php-openid/openid.module Since authentication in general is probably a topic of considerable interest to you all, I want to be sure the OpenID module measures up. I've tried to be sure I understand Drupal's authentication internals and the role OpenID can play, but please correct me where appropriate. Here are some notes about the module: - The plugin declares a block hook and provides a one-field OpenID login form that appears in the left navbar. The module is not really an authentication module because it doesn't declare an appropriate authentication hook (username@server syntax won't work for OpenID). Various other callbacks in the module handle the OpenID authentication steps and set $user when appropriate. - If you log in with an OpenID and don't have a local Drupal account, an account is created for you with the appropriate authmap record. However, you'll be prompted for an email address upon successful OpenID authentication *before* the Drupal account is created. (My goal here is to make sure any kind of profile info needed is collected before the OpenID-auth'd user is allowed into Drupal.) - My major concern is how to blend OpenID with existing accounts so users can choose to use OpenID for their accounts. On my drupal installation, I can log in with a username and password or OpenID to access the same account, provided the appropriate authmap record is present (which I created manually). The use case we can think of here is, "I'm already known as johnboy on this Drupal installation, but I want to access the johnboy account with an OpenID now. How can I tell Drupal about that?" I'm thinking that the OpenID module can implement a form to let users configure this, but it will probably involve setting the users.pass field to NULL. What do you think? Do you have any recommendations for how we should go about doing this? What would be consistent for your futuristic vision of Drupal authentication? Any feedback would be much appreciated. Thanks! -- Jonathan Daugherty JanRain, Inc.

10 17

no 4-7-0 branch for core yet?
by Moshe Weitzman 06 Mar '06

06 Mar '06

i am trying to checkout a 4-7-0 branch from core for a client. I want him to get all updates to this branch just by cvs up. But that branch does not exist yet AFAICT. Is there some better way to do this. Should we ask Dries and team to create one? I suppose it doesn't exist yet because we haven't opened up HEAD for features. -moshe

28 59

enterprise needs
by qomo 06 Mar '06

06 Mar '06

Ben, Dries and chx are really nice people when you talk with them in person. I agree with you that Drupal's lack of backwards compatibility makes it difficult for enterprise users. One of the biggest enterprise users told me he plans to never upgrade. Other enterprise users I spoke with about this have reached the same conclusion. I've heard it said that if Drupal were forced to choose between the little 'guy', and corporate users, Drupal will choose the little person every single time. For Dries this is a labor of love. An example of what (one of) motivates him is that someone with a terminal/serious disease can reach out and find help through Drupal. Helping some big corporation save money is not what motivates him to give so much of his time to Drupal. Many people working with Drupal/civicspace are motivated by the idea of empowering the individual/"masses." (of course large non-profits also are enterprise users.) I would guess there's a 25% probability that an enterprise fork will develop that is backwards compatible. I do think that will be necessary for Drupal to become accepted in the corporate world. At the conference we talked about having an enterprise user group and/or an enterprise mailing list. Perhaps that can happen Enterprise users do have a lot to offer the community in terms of putting modules back in and donations. I think it's great you've written so much code. Thank you. I hope you can find a way to make Drupal fit your needs. Ann

15 29

Drupal and i18n, the holy grail?
by Bèr Kessels 03 Mar '06

03 Mar '06

Or, how to get the i18n project rolling. online here too http://www.webschuur.com/node/525 First of all we need to recognise that there is no Ultimate i18n solution. There are many, all depending on the different needs, cases and implementations. So, I really do not believe in a single i18n module. Or in a holy grail. Therefore I torn the problem apart, and made Lego blocks out of it. That way the problem becomes rather clear. On the top level there are a few types of i18n sites: 1 Mixed content. Sometimes I blog in English, sometimes in Dutch. 2 Mirrored translations. For *every single item* in a "normal" site, you now need X amount (X being amount of active languages). this can be reduced by saying 'I need admin areas only in language A, admin is defined as Foo and Bar' 3 Growing translations. For every piece of content there may, or may not, be a translation. Think about freetagging (a tag beer and a tag bier). Or about community efforts to get pages translated. interlingual connections (read this in langB) lay, or may not be required. 4 A few pages in langA to explain what its about. Simple, just maintain a few pages in another language.[1] 5 Inline translations. Only certain elements of content have to be translated. Example: a photogallery with only English and Dutch "descriptions". They may appear on one page even. Other elements may not be translated like the title, that can be the same for both languages. We can also differentiate some other translations areas. The clear difference being: 1 content (terms, nodes, comments, profiles. oh if only they all were *cough* :)) 2 interfaces (PO file import export) 3 admin submitted configuration (think menu-titles, or user roles, or flexinode types, or profile fields) The good news, is that all the types have one common denominator: language switching. Except maybe for site type 4. The bad news is that both workflow and interfaces differ a *lot* between the various types. So here is what I propose: * locale.module+locale.inc, current implementation MINUS language choosing/switching interface and code! handles "translate area 2". * lang_switcher.module. A *simple* API/library module containing only APIs and a block to select languages. No editing interfaces or forms should be in there. Should also contain the three methods of storing the language in APIs. $SESSION, url prefix /en/node/12 /fr/node/12 and url postfix ?lang=en. * config_translation.inc. the toughest part: a contrib that allows us to translate missions, blocks, menu-items etc. handles "translate area 3". I have a fuzzy vision of some form_alter, combined with table prefixing (ugh!) and variable_get/_set prefixing. Needs clear thought. * Loads of modules and or themes using these APIs and systems to allow a variety of cases and workflows. Node_translator.module, comment_lang_switchers (yes, ever thought of how to avoid EN comments appearing under the DE version, heh?). oh and, off course a contrib user_profile_lang.module, containing the part from locale.module, where you store your language preference in your profile. And now? Fists in the air and *ffoooorwaaaaaaard* :) Serious: if we think these Lego blocks are well defined, we only need to make them, the blocks. Most of this is ripping stuff from existing modules, putting that in other modules and finetune that. Oh, and occasionally we need to build non-existing stuff, like config_translation.inc/.module. Starting here, IMO is better then writing down that the industry needs i18n, not? Or developing yet another module for translating the 60% your specific case needs translated (and no-one else will ever need). BZR? CVS? bright SVN? Drupal.org issues? where to start? Bèr [1] unfortunately not /that/ simple, because if you want to have poor SEO and so, you need to add the lang="" entity to the surrounding XHTML.

14 42

Re: enterprise needs
by Ken Rickard 01 Mar '06

01 Mar '06

>Here's my scaling tree. As you progress up the tree, you will find that time, money, maintenance, headaches will all increase.'' Ben- Thanks, that's a great list. My problem (which I had to explain to Karoly) is that I'm not a sysadmin, so I can't implement (or even really explain) these points. But I will path them along to our guys who are in charge of such things. As I said to Karoly privately, part of our problem is that I _fell_ confident that Drupal will scale, I just don't have the tech cred to back that up. So your list really helps. - Ken

6 5

RCS $Id tag in database source files
by Derek Wright 01 Mar '06

01 Mar '06

The Drupal coding standards (http://drupal.org/node/318) doesn't explicitly list this point. In addition to .php files using: // $Id$ it seems like .mysql and .pgsql files should also include something like this: -- $Id$ Knowing the exact revision of a .mysql file seems just as handy as knowing it for source (.php, .module or .inc) files. Upon further inspection, I see that this has now been done in core/database/database.* in HEAD. Nice work, Markus and Dries, thanks. a) I'd like to encourage all module developers on this list to add this comment to any .mysql and .pgsql files in their own module(s). b) We should update the coding standards page about this. I'd just add a comment to the page, but it seems better to have it in the body of the node, instead. What's the best way for me to help make that happen? I submitted an issue to the Documentation project's "Developer Guide" component... is that the desired behavior? Thanks, -Derek

2 1

Re: enterprise needs
by Ken Rickard 28 Feb '06

28 Feb '06

darrel said: >You can't guarantee that community process will conform to your businesses needs, or that if they do conform for a period, that they will stay that way. True. True. That's why I orignally said: "After spending the week in Vancouver, I made the following report to our management team. If we are to go forward using Drupal, we need a dedicated support-and-development team of 3 people. (And my eyeball prediictions of such things are ususally pretty accurate.) The team lead will have, as one of his/her main responsibilities, the task of being our public face within the Drupal community. "This includes going to events, encouraging contributions of code, and helping with documentation. This is crucial, because without being a valued member of the community, all you'll ever really have is your own Drupal fork to support. "If your organization goes forward with the idea of contributing patches to core, helping document Drupal, and so forth, then you will have a voice in future Drupal development." But then the thread got hijacked by my "scalability" issues... And thanks to everyone for some great material which I have diligently copied and forwarded to out sysadmins and dba. - Ken

1 0

Ken's list of Enterprise needs
by qomo 28 Feb '06

28 Feb '06

I think Ken's idea of having 3 Drupal developers at his company, including a team leader whose job will include going to Drupal conferences and maintaining strong ties with the Drupal community is a clever solution to possible divergence between Drupal core values and enterprise needs. If all enterprises did this, it could bring a lot to Drupal. Ken, I hope your company ends up choosing Drupal. Please do keep us updated. Thank you, Ann

1 0