- Development - lists.drupal.org

Who's Using SimpleTest?
by Rob Thorne 04 Mar '06

04 Mar '06

I'm about to start work on a new project, and noticed the simpletest module. This seems like a nice way to unit test the new code, especially any public APIs I expose. Who's using this now, and if you're one of them, how happy are you with the module as it is? Thanks, Rob Thorne Torenware Networks

7 6

Giving credit for committed patches
by Steve Dondley 04 Mar '06

04 Mar '06

I'm about to talk about a potentially sensitive subject. I will try to approach this delicately by first saying this is not an attach or criticism, just a suggestion for improvement. It is not my intention to start a flame war as has been suggested. So with that out tof the way, I was noticing the other day that Dries gives credit to patch contributors in the cvs log message. I think this is smart. First, it helps build the reputation of those who contribute, garnering them the good will of the community, second it strokes their ego. As far as building the reputation of contributors, I think we all recognize that this is an extremely important facet of open source development. For most of us, our reputation within the Drupal community is dependent upon the letters in our respective handles. When I see the letters m-e-r-l-i-n-o-f-c-h-a-o-s I think happy thoughts. He's helped me tremendously and I can him credit because the things he has done for me have come from those mysterious arrangement of letters. And I have done what I can to reward him for his efforts. So I think when we give credit to contributors and build their reputation, it spreads good will. And it puts a human face to the code many labor so hard on. Second, let's just all admit right now we have egos. I'll be the first to say that, yup, I have one. No, I don't work just to receive recognition and praise for others. Just the challenge of programming and and building web sites for worthwhile cause provides enough self-fulfillment for me to carry on. That said, it sure does feel good when I get some recognition. When my first bug fix patch hit the Drupal core, I feld some accomplishment. And when I saw my name associated with that patch, I was quite proud and got a little high from it. It was the first open source project I was able to contribute to. On the other hand, I also feel a bit sleighted when I contriubute some time or talent to a project (on any endeavor, not just Drupal), and no one takes the the time to say "thanks". That doesn't mean I stop doing the work, but it does mean that I'm less motivated to do something next time. I feel a bit used. Maybe I'm an anomaly and I'm just a big egotistical asshole. But I suspect I'm just any other human and simply like getting recognition, no matter how small. So, my suggestion is to simply make more of attempt to give credit to those who contributed their time and talent in the cvs log messages. I think the effort expended to do that is minimal (maybe Dries can better respond to this point) and well worth the effort by fostering more good will and good vibes in the development community.

7 14

Re: [development] giving credit for committed patches
by qomo 04 Mar '06

04 Mar '06

Steve, I completely second what you are saying. I'm amazed by how much people contribute, relative to the amount of appreciation that is expressed on the site. Perhaps Nedjo can be Director of Appreciation! (Dries may be too overloaded already.) Ann

1 0

Re: [contributions:killes] /modules/cvslog cvs.module
by Dries Buytaert 03 Mar '06

03 Mar '06

On 03 Mar 2006, at 21:00, drupal-cvs(a)drupal.org wrote: > User: killes Branch: HEAD Date: Fri, 03 Mar 2006 20:00:56 +0000 > > Modified files: > /modules/cvslog cvs.module > > Log message: > #50940, fix feed url > > Links: > http://cvs.drupal.org/diff.php?path=contributions/modules/cvslog/ > cvs.module&old=1.81&new=1.82&root=contrib theme('feed_icon', ...) does check_url() ... you're checking it twice now. -- Dries Buytaert :: http://www.buytaert.net/

1 0

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

Giving credit for committed patches
by Steve Dondley 03 Mar '06

03 Mar '06

I'm about to talk about a potentially sensitive subject. I will try to approach this delicately by first saying this is not an attach or criticism, just a suggestion for improvement. It is not my intention to start a flame war as has been suggested. So with that out tof the way, I was noticing the other day that Dries gives credit to patch contributors in the cvs log message. I think this is smart. And I think an attempt should be made, where practical, to do it for all patches. First, it helps build the reputation of those who contribute, garnering them the good will of the community, second it strokes their ego. As far as building the reputation of contributors, I think we all recognize that this is an extremely important facet of open source development. For most of us, our reputation within the Drupal community is dependent upon the letters in our respective handles. When I see the letters m-e-r-l-i-n-o-f-c-h-a-o-s I think happy thoughts. He's helped me tremendously and I can him credit because the things he has done for me have come from those mysterious arrangement of letters. And I have done what I can to reward him for his efforts. So I think when we give credit to contributors and build their reputation, it spreads good will. And it puts a human face to the code many labor so hard on. Second, let's just all admit right now we have egos. I'll be the first to say that, yup, I have one. No, I don't work soley for recognition and praise from others. Just the challenge of programming and and building web sites for worthwhile cause provides enough self-fulfillment to sustain me. That said, it sure does feel good when I get some recognition. When my first bug fix patch hit the Drupal core, I feld some accomplishment. And when I saw my name associated with that patch, I was quite proud and got a little high from it. It was the first open source project I was able to contribute to. On the other hand, I also feel a bit sleighted when I contriubute some time or talent to a project (on any endeavor, not just Drupal), and no one takes the the time to say "thanks". That doesn't mean I stop doing the work, but it does mean that I'm less motivated to do something next time. Maybe I'm an anomaly and I'm just a big egotistical asshole. But I suspect I'm just like any other person and simply like getting recognition, no matter how small. So, my suggestion is to simply make more of attempt to give credit to those who contributed their time and talent in the cvs log messages. I think the effort expended to do that is minimal (maybe Dries can better respond to this point) and well worth the effort by fostering more good will and good vibes in the development community.

1 0

critical project module issues: duplicate calls to menu items, and $_POST variables unset
by Nedjo Rogers 03 Mar '06

03 Mar '06

Updating drupal.org to CVS HEAD is being held up in part by two critical bugs in the project module: http://drupal.org/node/50337 version select broken when browsing projects http://drupal.org/node/50786 comment issues broken Both of these bugs cropped up recently after things were working fine, and they seem to reflect the same underlying problem. The menu item functions implementing these functionalities (project_page_overview() and project_comment_page(), respectively) are called twice in the course of the page handling, when presumably they should be called only once. The first time they're called they have access to $_POST variables, but the second time they don't, and so, seemingly, fail for lack of data. Is anyone aware of a recent change to core that might be producing these double calls? Or changes in the handling of $_POST variables so that they are unset? Any ideas would be very welcome!

3 2

beta 5
by Gerhard Killesreiter 03 Mar '06

03 Mar '06

Hi there, I had intended to release a beta 5 this night, but I am simply too exhausted to do so in good conscience (if you think I have one). Therefor all the readers of this list have about 8 hours left to create, review, and test(!) many, many bug-resolving patches which I will then look at before rolling the tarball and I might even apply them! This is the page I will look at: http://drupal.org/project/issues?projects=3060&states=14&categories=bug Cheers, Gerhard

2 2

Help Rick Klau fix Feed Burner
by Nathan Digriz 02 Mar '06

02 Mar '06

This was the ending post here http://drupal.org/node/48829 ""OK, this likely means that we're sending a version of the feed that the Drupal aggregator can't parse properly, which is a simple fix on our end. Can someone who's got info on this shoot me an email at rickk(a)feedburner.comand I'll coordinate with our CTO on a deployment fix for our smartfeed service?"" I am only forwarding this so it does not get missed. I have no idea who the right person is. Thanks for listening

2 4

email when admin approves account: can it get into 4.7?
by Derek Wright 02 Mar '06

02 Mar '06

1 sentance summary: when drupal is configured to require admin approval for user, it should only email the temporary password once the admin has moved the account from blocked to active. http://drupal.org/node/5689 (you can tell from the node id this issue has been around a long time) ;) this is a *major* usability feature for site admins... i'd consider it a "critical" issue, but i don't know if anyone else feels that way. i've got a patch working for this in 4.6 (which is obviously frozen), since that's what i'm using and many other folks want it. if i made time to update the patch to work in 4.7 is there any chance that would make it into 4.7 before the freeze (it's in core -- user.module)? if so, i'll bump this to the top of my drupal-hackery list and get it done ASAP. if it's not going to get into 4.7 no matter how fast i do it, i'll work on fixing it in 4.8... thanks, -derek

7 11