- Development - lists.drupal.org

Multiple modules, multiple versions, in Eclipse
by Syscrusher 08 Jun '10

08 Jun '10

Greetings, all After some time away from Drupal due to work responsibilities, I have found myself able to return to module development (and I'm really glad of this!). I decided, since my local development environment was already outdated, to make the jump to Eclipse instead of continuing to code in vi and update CVS manually. I've used Eclipse for Java work but not for PHP previously. I got Eclipse up and running and editing my code, and was able to checkout and commit changes to my modules. Three modules that hadn't been updated for months now have new updates awaiting release. Where I ran into trouble is in managing the branch tags, and I think it's because of the way I set things up in Eclipse. Right now, I have one workspace called "drupal" and a project called "drupal-6-contrib", and I imported code for my three modules using the CVS checkout feature of Eclipse to select the correct branch. Eclipse can't find the branch or version tags for the individual code folders, even though it *did* find them when I did the initial checkout and commit. I need to be able to manage my modules for multiple Drupal core versions, and also for multiple modules, and I'm looking for advice from others as to the "best practices" for doing this. How did you partition your development environment as far as workspace, project, and folder levels, with regard to Drupal core and module versioning standards? There are lots of articles on d.o and on the web at-large about setting up the Eclipse mechanics, but I haven't found anything on this particular topic that talks about being able to do multiple versions concurrently. Ideally, I'd like to keep this in a single workspace so I can cut and paste code when forward-porting or back-porting, but that may not be practical. Thanks for any advice. Kind regards, Scott -- Syscrusher <syscrusher(a)4th.com>

4 7

Node body weight ignored?
by nan wich 07 Jun '10

07 Jun '10

I have a hook_nodeapi op='view' implementation that is changing $node->content['body']['#weight']. Apparently it is being ignored because every other section that has a weight higher (less negative) than that weight is still being rendered above the body. I haven't yet gone digging through core to find out why this is happening. Is this the correct behavior? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

4 10

user management in a subdomain environment
by Debra Willrett 07 Jun '10

07 Jun '10

How do I restrict user management in a subdomain environment? For example, I don't want a chapter administrator to view and edit all chapter members across all chapters, but I do want to give that ability to a super admin. I installed the Role Delegation module, but that doesn't restrict viewing the list of all users, it just linits roles when new users are created. Any suggestions? Thanks. Debra

4 3

Drupal 7 API Change notification: hook*translation
by Randy Fay 06 Jun '10

06 Jun '10

In trying to find a way to notify developers of D7 API changes, the best solution we've come up with is to formally publish to the Drupal Development Mailing List. API change notifications will occasionally be posted here with a title starting with "Drupal 7 API Change notification" Today field_attach_prepare_translation needs to be updated for D7 API <http://drupal.org/node/362021>was committed with significant API changes to the translation system. If your code provides hook_field_prepare_translation() or hook_node_prepare_translation(), or calls field_attach_prepare_translation(), you'll need to take a look at #32 and #33 of that issue. In fact, if you even know what those hooks are, you had *better* look at the issue. Thanks, -Randy -- Randy Fay Drupal Module and Site Development randy(a)randyfay.com +1 970.462.7450

2 1

The "postponed" issue status
by Randy Fay 04 Jun '10

04 Jun '10

Here's a question for the group: The "postponed" issue status, per http://drupal.org/node/156119, seems to be either: "We plan (maybe) to work on this later" or "We can't work on this yet because it's blocked by another issue" To demonstrate this ambiguity, a search of "open issues<http://drupal.org/project/issues/search/drupal?text=&assigned=&submitted=&p…>" does include "postponed". However, the "D7 critical issues<http://drupal.org/project/issues/search/drupal?version[0]=156281&status[0]=…>" search does *not* include postponed issues. Further, the "templates for issue transitions<http://drupal.org/node/467548>" page (mostlly oriented toward module maintainers) clearly takes the former "maybe we'll work on this later" attitude. My questions: 1. Which of these interpretations of "postponed" is "correct"? 2. Should we add a "blocked" status that is quite clear? -Randy -- Randy Fay Drupal Module and Site Development randy(a)randyfay.com +1 970.462.7450

5 6

File attachment ordering in Views
by Jeff Greenberg 03 Jun '10

03 Jun '10

Anyone have a tip on getting a view to list the uploaded files (attachments) to a node in the same order seen when editing the node? I have a node with 45 attachments and the list in view could not be shuffled any better! Jeff

2 3

Module dev...
by Dayton Perkins 01 Jun '10

01 Jun '10

I really don't need any more work to do, yet I am considering finishing and submitting a module to drupal..org. The module relies on mime_mail and provides a UI to mail a node to a subscriber list. It utilizes an AJAX script to loop through the subscriber list and send each mail. Currently the module is a bit of a hack as the AJAX script resides in the docroot. I would like advice as to how to place the script in the module folder and still invoke drupal_bootstrap() without file path errors. Thanks so much :-) Dayton Perkins Tuesday, June 01, 2010

9 8

Drupal 6 bugfix release expected June 2nd
by Gábor Hojtsy 30 May '10

30 May '10

Hi, Since we have several interesting bugs fixed in the development version of Drupal 6, I'd like to do a bugfix release on June 2nd. If you happen to have some opportunity to help, I suggest one of the following three options (in this order): 1. First and foremost, it is important to ensure we do not introduce new regressions in the system. Since Drupal 6 lacks automated tests, you are our testing army (this approach also known as crowdsourced testing). You choose whether we find out issues before the rollout of the new version on your live server or after. Testing on PHP 4, with mod_gzip, on systems where one of the top bugs were reproduced, etc. are especially useful. 2. Second, if for some reason you think (1) is not applicable to you, the RTBC queue has some nice bugs and fixes which would do with some verification. There are currently 17 RTBC issues waiting to be committed. But RTBC does not equal immediate commits, since often waiting on more positive feedback and the attention of the maintainer experienced in the field is useful to ensure it will not break your sites. Once again, no automated testing means we need numerous verifications of bugfixes of any significance to be comfortable to roll into Drupal. Therefore bugs being in the RTBC queue for long is by design unless many people jump onto reproducing the issue and testing the fix in various environments. A few is not enough, we need many. The queue is at http://drupal.org/project/issues/search/drupal?order=last_comment_timestamp… 3. Last, but not least, you might have some pressing issues not yet in this queue. Due to the explained need for testing in (2) and the explained possibilities of regressions in (1), new bugs getting into the queue have less likeliness to actually end up in the upcoming Drupal 6 release right away. However, you might still be able to convince some people in the community to jump on your bug and help fix/verify/ensure/double-check/test-again/you know-it. At worst, it will get fixed in a later Drupal 6/7 release. Ps. in all cases, please ensure that the bug was either already fixed in D7 or is not applicable to D7 before working on the D6 version of the fix. Thanks for all your help, Gábor Hojtsy - Drupal 6 co-maintainer

2 1

Has anyone got a script to highlight node bodies
by nan wich 23 May '10

23 May '10

Unfortunately, I don't know javascript very well - I can barely read it. I was just on what amounts to a blog site where, in this case, the most current node body was highlighted by a mouse-over. But I was thinking that it might be nice to do this for every node body, particularly on sites where there is a background that doesn't lend itself to superior readability. So does anyone have a script that can be used to just change the color of a node body background, perhaps with greater opacity on a mouseover? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

3 3

Wow, that was fast.
by nan wich 22 May '10

22 May '10

Now, I don't expect a reply, so don't worry about it. This is just an observation about the reach of this list. I posted a question a short time ago. Eighteen (18) minutes later, my Google Alert picked it up! Incredible. I guess Google really likes Drupal a lot.

1 0