- Development - lists.drupal.org

setting mail server for development
by Augustin (Beginner) 18 Dec '07

18 Dec '07

Hello, Recently, I was trying to debug a patch for devel_issues.module: the problem was with the formatting of the mail notification. I had troubles working efficiently on that patch because my development platform is not configured to send mails (to myself!). In order to work on patches like this and for some contrib modules, I absolutely need to set myself up so that mails do get delivered. I am using Linux (currently Mandriva 2006, though I plan to switch to Debian). I have installed the packages postfix and postfix-mysql, though I am not sure I need such a full featured software for simple Drupal devel needs. I don't have a static IP, so I didn't know how to proceed with the postfix configuration. Also, I am concerned about security issues. The mail server needn't be open to the world. The mail sent don't need to leave my local computer. Is there a way to configure Apache (or whatever is handling this) to sent emails directly to a file somewhere on my computer? How do you handle such issues? Augustin.

6 6

drupal && ldap integration
by Matkhamtkha Brekher 18 Dec '07

18 Dec '07

is it possible to use several different windows domains with different PDC to authenticate users against that PDCs ?

2 1

spreadsheet inside drupal
by Lluís 18 Dec '07

18 Dec '07

I have to develop a tool to keep track of money in my association. As every member has a drupal user I was planning to do it using drupal, and I would like if a) is there any page explaining how to administer groups like Organic groups doees? (any way easier than reading the source....) b) is there any javascript grid which is easily integrated in drupal? I like http://dhtmlx.com/docs/products/dhtmlxGrid/ because it is compatible with firefox, iexplorer and opera (between other things), but any suggestion is wellcome. Thanks -- *Si Déu ens ha donat dues orelles, dos ulls i només una boca, és perquè hem d'observar i escoltar molt i parlar poc. *Hi han dues paraules que t'obriran totes les portes del món: "estira" i "empeny". *Quan fa 6x9? 42!!! (funciona en base 13) *PowerBall: 11.286 rpm !!!! *Abans d'imprimir aquest missatge, pensa en el medi ambient.

2 1

preventing update_status abuse vs. drupal.org privacy
by Derek Wright 18 Dec '07

18 Dec '07

The update_status module (D5 contrib, D6 core) queries drupal.org for information about the available releases for a given project. Included in the request is an anonymous hash to uniquely but anonymously identify the site, so we can record usage statistics about d.o projects. This was the topic of a long discussion about drupal.org privacy, whether update.module in D6 core should be opt-in or opt-out, etc[1]. One of the open tasks coming out of that discussion is the creation of a drupal.org privacy policy[2]. However, once these usage statistics become more visible on d.o[3], once you have the ability to sort modules based on usage, etc, the temptation for people to try to abuse the system will inevitably grow. :( Of course, we generally try to trust everyone as much as possible, but Joomla went through a very similar situation of abuse [4] and had to take a number of steps to try to manage it. So, there's now a patch (thanks, drewish!) sitting in the project issue queue that would at least help us notice abuse and begin to be able to do something about it: http://drupal.org/node/168009 This would change the project_usage module (the thing on d.o itself that's recording the usage queries and will be making the data available to the project* UI as soon as enough people who care about that start helping[3]) to record the IP address of the incoming usage query, along with the project being requested and the unique key. This would allow us to notice if a large number of requests for usage were coming from the same IP using different (bogus) keys. Of course, that would also happen on a multi-site install, or via shared hosting, but we can certainly factor that in before declaring abuse. I should note that the httpd logs _already_ record the IP addresses of all incoming requests to *.d.o, so it's not like this is fundamentally new data we'd be collecting. It's just that the data would live in the d.o DB itself, not just on the d.o filesystem (which is harder to get to). However, unless we have this data directly in the same usage-related DB tables, it'll be _MUCH_ more difficult and time consuming to try to track down suspicions of abuse and be able to do anything about it if/when we discover any. So, what do y'all say? Should I commit this patch to make it easier for d.o admins to limit/prevent abuse of the update_status usage tracking system? Is that too much for the privacy-conscious to handle? If I commit the patch, what additional warnings/indications should we give to site admins via the UI to know what's happening when they enable update(_status).module? Are the existing warnings good enough to let the privacy-conscious know they shouldn't enable it? Don't reply here, please use the issue: http://drupal.org/node/168009#comment-form Thanks, -Derek (dww) [1] http://drupal.org/node/178581 [2] http://drupal.org/node/178776 [3] http://drupal.org/node/165380 [4] http://www.joomla.org/component/option,com_jd-wp/Itemid,33/p,344/

1 0

Do you know Unicode?
by Karoly Negyesi 18 Dec '07

18 Dec '07

Join me at http://drupal.org/node/200185#comment-662754 thanks.

1 0

Drupal 6 RC1 coming up
by Gábor Hojtsy 18 Dec '07

18 Dec '07

Hello World, Looking at the critical issue queue, it looks like we are right on track for the first release candidate around the middle of / before the end of this week. I previously alerted people working on help/description updates that we are short on time with those improvements, so we can actually have a string freeze with RC1 as planned. Again, I am focusing on the criticals queue and the string updates so we can fix as much as possible in time. Please help out in these areas to make Drupal 6 rock even more. This will also allow translators on holidays to take all their time with Drupal 6 :) as well as more contributed modules to start updating and tutorials and even more videos to be created in preparation to the release. Gabor

1 0

Short absense
by Dries Buytaert 17 Dec '07

17 Dec '07

Hello all, next week I'll be defending my PhD (internal defense). I'll keep an eye on things and chime in where necessary, but in general, I won't be very active for another week. The reason is twofold: (i) I have to prepare well and (ii) the members of my PhD committee will be in town and I have to sit in on meetings, be a host, etc. I'll be back in action after next week. Keep up the great work, -- Dries Buytaert :: http://www.buytaert.net/

5 5

Re: [development] From Michelle: Request to themers.
by Michelle Cox 17 Dec '07

17 Dec '07

On 12/16/2007 4:57:26 AM, John Morahan (john.morahan(a)gmail.com) wrote: > Why not have them rename the original to, say, > _phptemplate_variables_original(), and then add a new > _phptemplate_variables() that calls the original and adds more stuff to > it? That way you get the > original's variables no matter how it returns > them. > > function _phptemplate_variables($hook, $vars) { > $vars = array(); > if (function_exists('_phptemplate_variables_original')) { > $vars = _phptemplate_variables_original($hook, $vars); > } > if (module_exists('advanced_forum')) { > $vars = advanced_forum_addvars($hook, $vars); > } > return $vars; > } > > -john Now that is a _great_ idea! I'll put that down in the readme as an option if they aren't able to do the merge. Thanks! Michelle

5 4

From Michelle: Request to themers.
by Susan Stewart 16 Dec '07

16 Dec '07

Michelle asked me to send this on for her, as her email is acting up. -- Susan (HedgeMage) ======================================================================== If you maintain a theme on drupal.org, please read this. The Advanced Forum module needs to hook into _phptemplate_variables to work. I've done my best to minimize what needs to be merged by moving the bulk of it into a function. So all the user needs to add is this: if (module_exists('advanced_forum')) { $vars = advanced_forum_addvars($hook, $vars); } But even adding those three lines is hard for people who don't know anything about code. The problem is that _phptemplate_variables varies from theme to theme. Some themes don't have it at all and some have rather complex functions. My readme says to put those lines at the very top, which will usually work. But then there's themes like Garland that stick the "return $vars;" inside the "page" case and return just "array()" for everything else! So then I have to explain that $vars needs to get returned for all cases. This gets to be a big support pain trying to help people make this work with every possible theme out there. So what would be really, really awesome for me and for any other module maintainer that needs to add to _phptemplate_variables is if the theme maintainers would be willing to always return $vars from the function even if you only use a particular case in there. I'm not aware of any problems with just returning the $vars that is passed in to the function to begin with so it shouldn't affect your themes any and will make life easier for your users that need to add to the function. Of course, if you want to be really super helpful to me, you could add the advanced forum call right to the themes so the user doesn't have to do any merging. But I realize that's a lot to ask. :) Thanks, Michelle

3 2

Drupal as a developer-led open source project
by Khalid Baheyeldin 16 Dec '07

16 Dec '07

Robert Fabian makes some very interesting arguments about Drupal, and why its architecture and API are its most significant asset. He also makes a case of why a developer led product/project is a win-win-win case. Read more here: http://groups.drupal.org/node/7704 Further comments here: http://2bits.com/articles/drupal-web-applications-framework-should-drupal-t… And here: http://becircle.com/drupals_greatest_asset -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.

1 0