May 2007 - Development - lists.drupal.org

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

RFC: 2 proposed changes to CVS branch/tag conventions
by Derek Wright 29 May '07

29 May '07

Hello world, In working on moving update_status.module into core, and continuing to field support requests about proper branching and release management for contrib, I'm proposing 2 simple but important changes to our branch and tag naming conventions starting with D6 and beyond: 1) http://drupal.org/node/147493 What: All contrib branches must have the "--N" part of their name. No more special case for DRUPAL-6 == 6.x-1.* vs. DRUPAL-6--2 == 6.x-2.*. DRUPAL-6 would be prohibited. Maintainers must add DRUPAL-6--1 when they want to release the 6.x-1.* stable series. Why: help remind everyone that each release series belongs in its own branch, and remove a weird special case that's confusing our maintainers and users. 2) http://drupal.org/node/147494 What: Any official release (core or contrib) with "extra" (e.g. "beta", "RC", etc) must have a specific format for the extra field: no hyphens or underscores, and everything must be uppercase. Why: make a 1:1 mapping of tags to version strings possible (currently, every tag has exactly 1 version string, but a given version string might have N possible tags). Please read each issue linked above for details, motivation, etc. Both changes require no code, just some config changes to our CVS access control scripts and a little handbook editing. If you oppose either one, please comment in the appropriate issue, not here. This list is very large, and generates too many long, hard- to-follow threads as it is. Many of you won't care at all, and probably just trust my judgement on such matters by now. So, if you have questions, feedback, or objections, please comment in the issue and spare everyone on this list the noise of a debate they're not interested in. Thanks, -Derek (dww) p.s. If there are no legitimate objections raised by Thursday, May 31st, I'm going to close discussion and implement these configuration changes. I want to ensure that D6 starts with a clean slate, so I don't want to wait until people have already started adding D6- related CVS tags and branches.

1 0

Re: [development] files owned by uid, patch review request.
by Larry Garfield 28 May '07

28 May '07

On Tue, 08 May 2007 09:40:05 -0400, Earnie Boyd <earnie(a)users.sourceforge.net> wrote: > Quoting Darrel O'Pry <dopry(a)thing.net>: > >>> What if I want the files to get deleted when the node is deleted? >>> Would they still be deleted with the proposed patch? >> >> No. The file remains, but is disassociated from the node. There is no >> way to guarantee the file is not in use elsewhere on your site, or >> linked from an external site, so the file remains. >> >> It can be modified to do so, but being able to do it sanely will require >> the addition on drewish's modules column, or a hook delete for reference >> counting to make sure files are not in use elsewhere. >> > > I haven't looked at the patch so forgive me if this is addressed. > Would it be possible to make this a feature within the system settings? > Would it be possible to have a count of nodes using the file and if > the node being deleted is the only one prompt for the user for file > deletion? > > Earnie I would concur here. Leaving untracked orphan files around should not be typical behavior. Some sort of simple reference counting would need to be included so that (a) we can auto-delete files that are no longer in use (give or take a setting to do so or leave them) and/or (b) provide an admin area to manage said files. If files become a first-class core data type (along with nodes, users, vocabularies, and comments), then they need some sort of direct management. It doesn't have to be complicated; something akin to admin/content/node is probably all that would be needed (with a "number of uses" column). But a first-class data type needs administrative control within core. Contribs can add alternate admin screens if desired, but core needs to have something. That said, I'm strongly in favor of this move. --Larry Garfield

3 3

multilanguage patches in need of attention
by Gabor Hojtsy 28 May '07

28 May '07

Hi, I started to collect (and intend to keep up) a list of multilanguage interface and content support related core patches which are in a state where you can review code and/or at least provide your opinion on the code present there: http://groups.drupal.org/node/3714 There are impressive stuff in there like t() for JavaScript strings and node language support. Please look there for a few interesting issues to look at if you are like: 'dude, I have a lot of spare time, but what patch do I choose to review, let me see...'. ;) Gabor

3 2

low hanging fruit for Drupal 6: variable defaults
by Gabor Hojtsy 28 May '07

28 May '07

Hi, To be able to translate variables to multiple languages in Drupal nicely, we would need a small conceptual change, which would benefit all of the Drupal developers, so I am posting the call here in hopes we have someone or a small group to pick this task up. **We need a central place to define variable defaults** Simple! Now whenever you need a variable, you do variable_get('my_fine_var', 'my_default_value'); The problem with this is that you need to repeat this multiple times, and of course there is a chance you need to modify it later on, so you need to find all places a variable is used. Not good. Remember the changes from bluemarine to garland, we have been fixing theme_default errors for days, finding out places where the variable was used... So we need a central place to define variable defaults. For Drupal 6 this is enough now: hook_settings() { return array( 'my_fine_var' => 'my_default_value', ); } Have fun with naming it hook_settings(), as far as I see, it is an appropriate name, and not taken at the moment :) So Drupal can do a module_invoke_all() on hook_settings() and collect defaults to all variables from the modules defining them. It gets easier and shorter to use variables: variable_get('my_fine_var'); We can either cache the default vars as returned by the callback in the variable_get() function, or in the database among other variables, you get the idea. It is important to have all variables defined in hook_settings(), even if the default value is an empty string or array. Don't care yet about how this fits into translatable variables, because we can only follow up on that if this gets done. So someone please grab this issue and run with it ;) Gabor

16 56

Fieldsets for profile variables
by Mike Anon 28 May '07

28 May '07

This was posted in the forums under Module Development at: http://drupal.org/node/146972 It has received no responses (so far). If it receives no responses here, as well, then I have the answers to my questions. I wanted to attach a fairly large number of variables (fields) to each user's profile, and the UI for displaying and updating (editing) "that many" variables was not to my liking. At the moment (in 4.7, anyway), profile variables can be put into "categories" (apologies to jaza and bdragon, but that is the "official" description of the way that profile fields are divided into separate and distinct groups). When a user profile is edited, the various categories are displayed as links near the top of the first edit screen, with the first edit screen focused on the "account settings" category. Those with user administrative privs can add additional profile fields and each field can (actually, must) be placed within a category. I believe that there are no restrictions on the number of profile fields or the number of profile field categories, although I certainly haven't stress tested it. The "edit user profile" UI currently loads a separate page for each category. That separate page lists all of the profile fields associated with that category, in the order specified by the normal Drupal weight/alphabetization mechanism. There is no ability to group the fields in a fieldset. I have a simple module that allows those with user adminsitrative privs the ability to assign each profile field to not only a category, but to a fieldset, as well. Would this capability interest anybody else? By that I mean is it worth my time to spiff up the existing module I have so that it becomes a contrib module? Like many, I don't want to go through the effort if there is either no interest or, in the extreme, negative interest. At the moment, the code can only handle a fieldset depth of one. That is, only one level of fieldsets for each category. Of course, each category can have unlimited fieldsets, but they remain at the same level - one beneath the category. The design of the database modification, however, leaves the door open for unlimited fieldset depth (not that anybody would ever use more than 2 or 3 levels). In addition to someday allowing for unlimited fieldset depth, at some point I can see adding a "report" node allowing for a screen report to be generated with the contents of a given category/fieldset combination. Since users aren't nodes in 4.7, views can't be used to generate a report of this nature. My discussion on #drupal and #drupal-support lead me to believe that there is not much involved here which will be different for 5.x, although I haven't looked into that myself, yet. So, the question is, does it make sense for me to put "yet another profile extension module" in play? Translation: would you find this capability to be useful? I believe that I have checked the existing profile modules and none of them implement this functionality. Assuming this to be a useful thing for some people, would it make more sense to fold this capbilitity into an existing profile contrib module rather than create a separate contrib module?

3 3

Adding db_rewrite_sql to comment.module
by Josh Koenig 28 May '07

28 May '07

Shameless patch-whoring alert! I've been working on a number of projects lately that involve fine- tuning access, and since I got to experience Andy Kirkham's lesson on hook_db_rewrite_sql, I've been loving the power of this system to handle node access. However, in contrast to what the hook documentation says ("For comments, it is cid"), comment.module doesn't contain the critical call to db_rewrite_sql in comment_render(). This patch fixes that: http://drupal.org/node/128165 I've tested this pretty extensively on 5.1, and re-rolled without errors for 6-dev. My primary application for this is an ad-hoc private comment system called whisper.module which I'll be releasing in the next month. cheers -johs Josh Koenig, Partner josh(a)chapterthreellc.com AIM: chap3josh 1-888-822-4273

2 1

OG User Roles: user_access / node add / $user->roles
by Ron Parker 27 May '07

27 May '07

A few weeks back I floated my og user roles module idea on this list as instructed by CVS Admin. This module (http://drupal.org/node/87679) is designed to assign roles to OG group members that are specific to the groups they are in. The problem was that I had to patch the core user.module in order to get it to work. After a couple of suggestions, I decided to formulate a proposal for a Drupal hook. What I thought made the most sense was either a user_access hook or a $user->roles hook because what I wanted to do was add roles to the site wide roles returned by $user->roles. user_access (which returns permissions allowed according to roles) is called by node_access which is what determines access on a node/add. I recently proposed a $user->roles hook (http://drupal.org/node/143393) and someone pointed out that I could accomplish the same thing by using the existing hook_user "load" operation. They were right. I modified my module to add the appropriate roles to the user object using hook_user "load" and in testing, it appears that $user->roles now returns the OG group as well as the site wide roles when a user is in a group. However, on a group node add, for example, http://www.mysite.com/node/add/link?gids[]=29, my user gets an "Access denied" error. I wrote a little debug program that writes out the values returned by my hook_user "load" addition, and every time it's called it returns the correct values. node_access would be the access control for a group node add. I have examined the code closely, and this is the only code that would be executed on a node "create": // Can't use node_invoke(), because the access hook takes the $op parameter // before the $node parameter. $module = node_get_types('module', $node); if ($module == 'node') { $module = 'node_content'; // Avoid function name collisions. } $access = module_invoke($module, 'access', $op, $node); if (!is_null($access)) { return $access; } This code would then call "node_content_access" (hook_access for node), which would use "user_access" (thus calling global $user, thus invoking my modification) to determine access. So, I'm at a complete loss as to why I would get an "Access denied" error for a group role. I need some help! The only thing I have noticed which seems to give me a clue is that when I load the "devel" module and give users access, everything works. But, I can't figure out what the devel module is doing that would cause this. Any hint, clue or anything would be appreciated. Thanks! -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com

4 9