- Development - lists.drupal.org

Re: [development] development Digest, Vol 54, Issue 94
by Chad Phillips -- Apartment Lines 23 Jun '07

23 Jun '07

On Jun 22, 2007, at 8:50 PM, Yves Chedemois <yched.drupal(a)free.fr> wrote: > Does handling content type deletion make sense ? i think it might, because of the dependence of nodes on node types -- possibly some modules may have information to add or need to cancel a type deletion altogether. i wonder how hard content types would be -- i haven't ever looked at that code... hunmonk

1 0

Re: [development] Date Calc and ADODB date library
by Karen Stevenson 23 Jun '07

23 Jun '07

<snip> What's worrying me more is two things: - do we really want to maintain two fork off PEAR, as you mention yourself - this means a lot of code to be parsed that won't really be used afterwards in most cases. selective loading, as in php5's _autoload mechanism, would obviate the second point, but only works out of the box with PHP5 (which would fit nicely with the GoPHP5 thread)... and with classes, not pure functions. </snip> First of all, both of these are VERY stable modules that are rarely updated, so keeping up with them is not like trying to fork something complicated (like TinyMCE, for instance). The ADODB date library has not been changed in years. The PEAR Date Calc library has had a more recent update, but the change was mostly just re-arranging the code and adding a couple new functions. The PEAR Date Calc library from several years ago still works fine. Anyway, I really don't think maintaining them would be a big problem. There are advantages to Drupalizing them instead of including them as-is -- PEAR Date Calc comes with a lot of PEAR baggage that is not even needed and half of the ADODB date library is documentation or test code that I would either remove or put into a separate files. Also I've already run into problems with the ADODB date library when more than one module uses it and the same functions get declared from different included files. We need one central, shared location for these kinds of things. Parsing possibly unneeded code is an issue, but we can find a solution for that. My practice has been to try to find ways to include files only when needed and I would certainly be in favor of that in this instance. We can do it lots of ways -- break the includes down between often and rarely used functions; create a basic include file that only contains wrapper functions that include_once() the necessary file then call the function only when it is needed; break out less common code into optional modules; etc etc. Again, if we Drupalize the code we can make changes like that. Anyway, the basic question is whether this is something that makes sense for core. If not, I won't push it any further, if so, I'll propose a patch. I definitely plan to include it as a part of Date API if it's not in core, so I'm going to do the work either way (and I plan to add it to the 5x branch of Date API either way). And my original question -- does anyone know exactly how I should attribute the original authors and licenses in my Drupalized version? Karen

4 3

Update status in core: required or optional?
by Derek Wright 23 Jun '07

23 Jun '07

As I understand it, Dries wants update_status to move into core by means of a patch against system.module. I.e. make it a required part of the module system, something that can't be disabled. However, there's a debate underway on if you should be able to disable it if you really want to. I'm sympathetic to arguments for both sides of the debate, so I opened an issue about it and am encouraging people to add their thoughtful comments on the topic: http://drupal.org/node/153968 Please don't reply here, just comment in the issue: http://drupal.org/project/comments/add/153968 Thanks! -Derek (dww)

1 0

Date Calc and ADODB date library
by Karen Stevenson 22 Jun '07

22 Jun '07

I have decided that it would be really useful to add the PEAR Date Calc and the ADODB date library to the Date API by reworking the original code to use Drupal coding conventions and styles and making them available as natively-available Drupal include files. Both have BSD licenses, so my understanding is that it is OK to do this. Anyone know for sure if that is true? And does anyone know exactly what parts of the original license info should be retained in the reworked code or how I should attribute the original modules/authors? Also, as I work through them, it occurs to me that once they're 'Drupalized' they might potentially be nice additions to Drupal core. They could then be used by a wide variety of core and contrib modules that do things with dates and schedules and calendars without the need to duplicate all that code. For those not familiar with them, ADODB date library makes it possible to handle date ranges from the year 100 to the year 3000 (a bigger range even than that allowed by php 5). The library checks to see if native php date handling will work on the date being manipulated and if so, uses it, which keeps overhead to a minimum. The PEAR Date Calc library has functions you can use to find things like the last day of February in 1950, or the first Tuesday in the second week of 1965, or the day of the week that October 29, 1929 fell on. Both work with both php4 and php5 on either Windows or NIX systems. PEAR Date Calc is a class that requires PEAR Date, but it is actually works fine reworked into a stand-alone collection of date functions with no need for PEAR or PEAR Date. The ADODB library has its own versions of some of the PEAR Date Calc functions which can be eliminated in the Drupalized version since they'll already be available. By creating Drupal versions of both, I may be able to find other ways to tweak them to better match the way Drupal does things, like replacing the PEAR Date Calc's DATE_CALC_BEGIN_WEEKDAY constant with Drupal's variable_get('date_first_day', 1). I'm not finished with them yet, but preliminarily it would be about 20 KB for the Drupalized ADODB library and 45 KB for the Drupalized PEAR Date Calc library, so they would add some size to the download, but maybe not enough to be a problem. Some of that might be offset by using the new functions in core (i.e. there will be a date_calc_get_week_days() to return the translated days of the week and date_calc_get_month_days() to return translated months of the year). The risk of doing this is that someone needs to keep up with the original code in case there are bug fixes that need to be ported to our fork, but both of these libraries are very stable and haven't changed much. Together they would make many things possible, or at least make them easier. Thoughts?? Karen

2 1

admin user search by email patch
by Damien Norris 22 Jun '07

22 Jun '07

Hello Drupal developers! This is my first post to this list and I apologize up front if i am suggesting something newbish or stupid or going about this the wrong way... but here goes! I would like to propose inclusion of a small patch to user.module, which extends /admin/user/search so that if you have "administer user" permissions, your search string will match against e-mail addresses as well as just usernames. I looked at the DEP documentation and I think tihs is probably simple enough to propose here in email, as there is a patch ready... --First, the rationale for this: One of my customer's most popular drupal sites has 5000+ users. While there IS a forgot password feature for helping users who lost their password or usernames find them, there is no way for an administrator to help when the user contacts them directly. While it would be nice to assume that all users can manage using the forgot password link, It has been our direct experience that many users can't or won't - they contact the site admins instead for help, and then there is no way to find their username from their email address. Without going into the database and running a SQL query there is no way for the administrator to glean the user's Drupal username. (is there a way I don't know of?) I did some digging on Drupal.org and found mention of an old user_search module from 4.6 (not ported beyond) and also some people working on profileplus for better profile searching support. But AFAIK this won't include email addresses, which are in the users table. When I went to huntfor a solution I discovered someone had made a patch to do this, but the patch wasn't up to date. I updated it to work against HEAD and also changed it to modify the help text so it works as follows: --New Behavour with the patch applied: For all non-admin users, everything is the same... the text box searches for a username and the help text reads: Enter a simple pattern ("*" may be used as a wildcard match) to search for a username. For example, one may search for "br" and Drupal might return "brian", "brad", and "brenda". But if you have 'administer users' permissions, the search will also search on the user.mail field, and the help text instead reads: Enter a simple pattern ("*" may be used as a wildcard match) to search for a username or e-mail address. For example, one may search for "br" and Drupal might return "brian", "brad", and "webmaster(a)brenda.com". That's it! The patch itself is as simple as it sounds... So my question for you folks is: what now? After my initial patch wasn't up to coding standards and I corrected it, the issue died on the vine. How do I move it forward from here? I guess first and foremost is to get more people to try testing it - where do I go to drum up more testers? Or what should be my next step? Here is the link to the latest version of the patch, user_search- by_email-HEAD_2.patch http://drupal.org/node/113983#comment-249183 I understand more steps may be required and it may take way loner than the code freeze has left... but I am just unsure how to get it moving forward again. Advice would be appreciated... Thanks! D.

4 3

Disabling a form button after a click doesn't work?
by Andy Triboletti 21 Jun '07

21 Jun '07

I'm trying to disable the submit button of my form and set the value to "waiting.." after someone clicks. In my javascript I'm doing: $("#node-form .form-submit")[0].disabled=true However with that added, the form can never be submitted successfully --it throws you back to the form but without any visible errors. (I take it out and it works) Any suggestions?

3 2

I'm back
by Karen Stevenson 21 Jun '07

21 Jun '07

I hope it isn't too spammy to send this to the list, but I maintain a lot of code that is used by a lot of people and I pretty much disappeared for a while, so I wanted to explain. I was helping care for my father while he died, which unexpectedly ended up being a 24x7 commitment for the last couple of months. He was starting to get pretty sick while I was at DrupalCon, and things went downhill from there until he passed away last week. I feel badly that my absence created a bottleneck for a lot of people, but glad I could be there for my father to make those last days as good as they could be. And I did do a little Drupal work while I was gone - we put his memories up on the family website and I needed to get a big MS Word document of stuff my sister had accumulated made into a multi-page Drupal book, so I created HTML2Book and submitted patches to HTML Tidy and Flickr and a couple other projects to help get the job done. Anyway, I'm just getting started on a mountain of unanswered email, open issues, and unfinished projects, so it will be a while before I'm actually caught up, but I'm back again. Karen

7 6

Re: [development] I'm back
by Karen Stevenson 21 Jun '07

21 Jun '07

Thanks! I really appreciate all the support I've gotten from the Drupal community. It's a really good group of people. I'm looking forward to getting back into the swing of things. Karen ----- Original Message ---- From: Robert Douglass <rob(a)robshouse.net> To: development(a)drupal.org Sent: Thursday, June 21, 2007 8:53:21 AM Subject: Re: [development] I'm back Welcome back, Karen. We missed you, but knew that you were going through hard times. I'm glad to hear that you were able to care for your father, and offer my humble best wishes to you and your family. Robert Karen Stevenson wrote: > I hope it isn't too spammy to send this to the list, but I maintain a lot of code that is used by a lot of people and I pretty much disappeared for a while, so I wanted to explain. I was helping care for my father while he died, which unexpectedly ended up being a 24x7 commitment for the last couple of months. He was starting to get pretty sick while I was at DrupalCon, and things went downhill from there until he passed away last week. I feel badly that my absence created a bottleneck for a lot of people, but glad I could be there for my father to make those last days as good as they could be. > > And I did do a little Drupal work while I was gone - we put his memories up on the family website and I needed to get a big MS Word document of stuff my sister had accumulated made into a multi-page Drupal book, so I created HTML2Book and submitted patches to HTML Tidy and Flickr and a couple other projects to help get the job done. > > Anyway, I'm just getting started on a mountain of unanswered email, open issues, and unfinished projects, so it will be a while before I'm actually caught up, but I'm back again. > > Karen > > >

1 0

Drupal 'view' with distinct modules
by James McLean 21 Jun '07

21 Jun '07

Howdy, We're working on a project using Drupal at its core and for one area of the website we would like to implement a section that is distinctly different from the rest of the website. Basically, in simplest terms, what we'd like to achieve is to have one area of the site distinct from the rest with its own layout and blocks, possibly even the ability to have blocks anywhere including the center content section - however it would all need to be a single installation of Drupal on the same domain if at all possible. I guess as a last resort it could be run under a different subdomain via the same installation (I think that is possible with Drupal?) something like http://myarea.thisdomain.com with the main site at http://www.thisdomain.com. I havent discussed that option with the project team though, just thinking out loud with that last point. Can anyone point me in the right direction? Cheers, James

5 4

Re: [development] I'm back
by Karen Stevenson 21 Jun '07

21 Jun '07

Thanks! I really appreciate all the support I've gotten from the Drupal community. Karen ----- Original Message ---- From: Chris Johnson <cxjohnson(a)gmail.com> To: development(a)drupal.org Sent: Thursday, June 21, 2007 8:39:06 AM Subject: Re: [development] I'm back Life happens, and is often more important than open-source software. Condolences on your loss, and welcome back. Chris

1 0