September 2006 - Development - lists.drupal.org

Java port of Drupal
by Khalid B 08 Sep '06

08 Sep '06

In another thread far far away, the mentat Dries Buytaert declared : > Hopefully, it also means that, in future, we can support > databases like Oracle with fewer pains. One day, it might turn out > to be really important, but until then, it's just theory, of > course. :-) I think that coincides nicely with the Java port of Drupal that is under way. We are using SVN for that project too ... :-)

1 0

t() function concept/bug/patch proposal
by Alan Dixon 07 Sep '06

07 Sep '06

there have been enough recent posts referring to the t() function that I'd like to draw attention to my previous bug report/patch again: http://drupal.org/node/74181 In summary - the current concept of t() is officially that it only supports fixed, module defined strings, not 'user-defined' (which means anything else, e.g., a title, a taxonomy term, etc.). In particular, when given an empty string as an argument, it wastes an expensive sql lookup (and really bombs if those are in an init function before the db caching is started). Nevertheless, I see a number of recent posts that are using t() for lookups of arbitrary user strings, a kind of hopeful translation mechanism, instead of the rigorous one originally intended for it. I'd like to propose an official change to the concept of the t() function that it accepts any arguments, including dynamically generated ones, since that seems to be the common usage, and in that light accept the simple patch proposed above, all in the name of simple performance for a wide range of sites/modules. -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/

5 8

Re: [development] MySQL Insert on Duplicate Key Update
by Ken Rickard 07 Sep '06

07 Sep '06

Khalid- I assumed so. In theory, database.pgsql.inc could intepret this line, but I also asume that using this syntax isn't a huge performance gain. 'Nuff said. - Kem From: "Khalid B" <kb(a)2bits.com> Subject: Re: [development] MySQL Insert on Duplicate Key Update To: development(a)drupal.org Message-ID: <4a9fdc630609060818m410e2f5eve53210f5f1c1287(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed One word: PostgreSQL. On 9/6/06, Ken Rickard <agentrickard(a)gmail.com> wrote: > All- > > What is the opinion regarding the use of MySQL's syntax for: > > INSERT .... ON DUPLICATE KEY UPDATE > > http://dev.mysql.com/doc/refman/4.1/en/insert-on-duplicate.html > > I haven't seen any code that uses it. Is that habit or policy? > > - Ken Rickard > agentrickard >

2 1

module with XML RPC
by Augustin (Beginner) 07 Sep '06

07 Sep '06

Hello, I most probably will need to create a new module that needs to handle XML RPCalls. I have no experience with XML RPC, so I'd like to ask a few general questions about Drupal's implementation. If I understand well, the files includes/xmlrpc(s).inc are a fork from the library: http://scripts.incutio.com/xmlrpc/ How come the Drupal XML RPC API doesn't use any of the PHP XML RPC functions defined here: http://php.net/xmlrpc ? Is this a completely different implementation? Why? Is there a historical/technical reason behind this? How does a XML RPC "session" happen? During a page load, we can use php to query the DB, get a reply from the SQL server, process that reply and display the page according to the reply we got. Does the procedure happen remotely with XML RPC? I.e., if I have a drupal XML RPC client module, that needs to contact a remote XML RPC server, do I get a chance to send the call, get the reply and process that reply all within one page load, as if it were a SQL query? If not, how is the exchange of information handled. What modules exist that use XML RPC a lot, that I could study? How would a simple code snippet look like? (make a call to server, get reply, and have a if / else fork according to the reply we got - or display / print_r() the content of the reply). I saw a few handbook pages, and some issues about xml rpc, but I can't find any information for a total noob... Thanks, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

6 6

{Short issue queues need care - 7} Why we shouldn't close all issues without proper review.
by Augustin (Beginner) 07 Sep '06

07 Sep '06

Hello and welcome to the seventh edition of {Short issue queues need care}. There is a long introduction, but I think it's worth your serious consideration. Thank you for reading it. This week: 1} Why we shouldn't close all issues without proper review. a) Why we shouldn't close all issues without proper review. b) Necessary change in order not to waste precious developers' time c) Our collective goal d) The good news: we ARE making progress. 2} Featured short issue queues. 3} Why this report and how to cooperate? ******************************************* 1} Why we shouldn't close all issues without proper review. ******************************************* Recently, there has been some people talking about closing ALL outstanding issues without any review. There are several reasons why this is a bad idea. It it disturbs you that there are some many issues open, use the solution that some people have told me: Just ignore them. Just carry on scratching your own itch and ignore the state of the queue. Such people may stop reading here. Actually, I have witnessed some subtle improvements since I started writing this (almost) weekly report. More on that further down. a) Why we shouldn't close all issues without proper review. =========================================================== First, closing all the issues will not make the bugs (the real ones) disappear. Second, if their feature request is closed, it will not make people stop wishing that the feature were implemented. Third, sure, the issues can be reopened, but instead of having a long list of open issues, some of which could be closed straight away, we would have to worry about a much longer list of closed issues, wondering which one should be open. Fourth, doing so would be an insult to all the people who took the time to report issues, to code a patch, etc, just for their work and comments to be discarded. What will happen is not that those issues (with all the comments and patches attached) will be reopened, but new ones will be opened, without any comment and without any patch. It is such a waste of time and efforts. Fifth, this is THE MOST IMPORTANT REASON, what is needed is not mindlessly closing all the issues, but a subtle change of culture within the community. 2000 issues might be closed today, but unless this change takes place, within a few months the new queue will start growing again. So, what is it that needs to change? Closing everything and saying "let's start anew" is like the heavy smoker who throws his cigarettes at 11:59pm on New Year's Eve, and says he quits smoking (or the porn addict who deletes his collection from his hard drive, and says he quits w**king!- see reuniting.info). I'm sure you know as well as I do that New Year resolutions do not last long. What is needed is to quit smoking every day. b) Necessary change in order not to waste precious developers' time ==================================================================== There is a tendency (we all have) to say that all that matter is to "scratch one's own itch". I don't like that saying one bit. Yes, we all do scratch own own itches, but it shouldn't prevent us from helping other people scratch THEIR itches (have ever tried to scratch an itch between your own shoulder blades? It's so much nicer when a loving partner does it for you :) ). The point is that we are part of a community and we should help each other. We all have time constraints (it is understandable, and there is nothing wrong with that), so we have limited time to devote to this particular project. Some can do more, and some can do less. That's ok. But we are still part of the community and we should not only push forward our own patches, but also look around and see who needs help with their patch, and help them to have their patch committed. Here is a very concrete example. Look at this queue: http://drupal.org/project/issues?projects=3060&states=14 The few guys responsible to deal with it really rock!! The queue never gets very long, and the issues are never more than a few days old. When they come to work on Drupal, they just have a look at the above queue to see what needs their attention. They are not only scratching their own itch, but also working on behalf of the whole community. My aim with this report is to make it so that the following issue queue reflects the same kind of achievement: http://drupal.org/project/issues?projects=3060&categories=bug&states=8 As you see, it is not THAT long (102 issues only). But behind each of those issues, there is a guy or two who took the time to setup a test environment and code a patch. And you want to throw all their efforts by the window?? How long would it take you to deal with 5 of those issues? 1 day? 1 week? 2 weeks? more? Take 20 developers and the whole list could be done within that period of time. c) Our collective goal ====================== So, when that queue: http://drupal.org/project/issues?projects=3060&categories=bug&states=8 becomes and remains as short as that one: http://drupal.org/project/issues?projects=3060&states=14 then the community would have won! Then the issue queue will take care of itself. (obviously, we can later add the feature requests to the list). EVERY issue set as PATCH NEEDS REVIEW and that issue does not get reviewed, it is a waste of a developer's time. (I'm sure you all have had this experience). The problem is NOT that we don't have enough man-hours. The problem is that we waste too much time. We waste our own time, and we waste our co-developers' time. I don't want to give a personal example (I am afraid to become bitter), so I'll take another example. I just noticed that webchick changed the status of the 'signature' issue from 'needs review' to 'postponed'. She did so with a sigh so big that I heard it half way across the world. She worked very hard on that issue, providing patch after patch. The only ones to give her feedback were the core-commiters, who are already overworked. I feel bad for her because I could have helped her. Maybe if I had taken the time to give the patch a proper review, I may have been able to set the patch as RTBC. I (or anyone else) could have made a difference for her patch. The same scenario is repeated at each release cycle, because we, the community, do not take the time to review other people's patches, scratch other people's itches. I am not blaming anybody. Many of you DO review patches. And I try my best to do my share, according to the time I have available. But you get my point. The issues queues I highlight every week were not chosen by chance, but for a specific purpose. The 7 queues highlighted here are ALL important: either they are about critical issues, or they are about issues where a developer has taken the time to provide a patch. d) The good news: we ARE making progress. ========================================== The good news in all that ranting is that in the few weeks I have been writing this report, I have witnessed a lot of positive changes. Already a few of the queues I featured in earlier weeks are no longer part of the report because all the issues within had been dealt with. This proves that a significant number of developers do care, and give their time selflessly. Thanks to those. Also, the general trend within the last 2 months for the Patches Need Review, is downwards. There are already fewer of them. All of this shows that we DO have enough man-hours. It's ok to ignore (for a while) all the feature requests without any patch attached. But if we make sure that our co-developers do not waste time coding patches that never get reviewed, then the community would become more efficient. I'll keep reporting on the achievements of the developers community in my weekly update. If you want to help, I suggest you start by the queue #7. If there is nothing you can help with there, then choose one of the 6 other queues. If you do so, you can PM me (it encourages me :)) or see part 3} to show your participation, and to ask for help: this way we'll see that many developers care. Thanks for reading :) and more importantly: Thanks for scratching other people's itches. ******************************************* 2} Featured short issue queues. ******************************************* There are 930 subscribers to this mailing list. Is it possible that 20-50 of those read this report and decide to work together to lower the number of issues on each of the 7 queues featured this week? Pick one list. See at the very end if you wish to officially 'adopt' one queue. The number in parenthesis designs the number of issues 2 weeks old or more (i.e. issues most likely forgotten and not being dealt with). (Queue #1) DRUPAL-4-6 critical issues: http://drupal.org/project/issues?projects=3060&versions=12052,11555,11262,1… 18/06/2006 : 24 (19) issues. 25/06/2006 : 8 (5) issues. 02/07/2006 : 5 (4) issues. 07/08/2006 : 5 (5) issues. 14/08/2006 : 5 (4) issues. 22/08/2006 : 4 (2) issues. 04/09/2006: 5 (1) issues only. Those are really critical issues, already fixed in head and 4.7. A few junior developers (myself and others) have tried to help out, here, but we lack the knowledge to solve them, and the seniority to decide to downgrade those issues ('normal' issue, or 'won't fix'). A senior developer is needed to decide the fate of those issues. If they are indeed very critical, then a patch is needed soon: can you at least tell how they should be fixed. (Queue #2) DRUPAL-4-7 critical issues: http://drupal.org/project/issues?projects=3060&versions=12050,11551,11252,1… 18/06/2006 : 31 (19) issues. 25/06/2006 : 12 (8) issues. 02/07/2006 : 7 (5) issues. 07/08/2006 : 19 (13) issues. 14/08/2006 : 7 (0) issues. 22/08/2006 : 7 (0) issues. 04/09/2006: 18 (0) issues only! New critical issues keep coming every week, because 4.7 is the most used version. Most are not really critical, though. (It should get better for Killes when 5.0 comes out). (Queue #3) CVS critical bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 18/06/2006 : 6 (1) issues. 25/06/2006 : 13 (1) issues. 02/07/2006 : 15 (1) issues. 07/08/2006 : 16 (3) issues. 14/08/2006 : 22 (5) issues. 22/08/2006 : 21 (6) issues. 04/09/2006: 33 (8) issues only! The rising number of issues is an indication of the state of turmoil cvs is in, after so many big patches have landed. But, as you know: cleanup has begun. (Queue #4) DRUPAL-4-6 Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=12052,11555,11262,1… 18/06/2006 : 26 (25) issues. 25/06/2006 : 26 (25) issues. 02/07/2006 : 25 (24) issues. 07/08/2006 : 24 (23) issues. 14/08/2006 : 24 (23) issues. 22/08/2006 : 20 (2) issues. 04/09/2006: 11 (0) issues . Most need to be bumped to cvs, if the bug still exists in HEAD. If the bug hasn't been fixed yet, try to reroll the patch for head, or else set as "patch needs work". Thanks again to Fernando (and maybe others) who worked a lot to bring the number down. (Queue #5) DRUPAL-4-7 Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=12050,11551,11252,1… 18/06/2006 : 17 (5) issues. 25/06/2006 : 16 (7) issues. 02/07/2006 : 21 (8) issues. 07/08/2006 : 15 (11) issues. 14/08/2006 : 15 (4) issues. 22/08/2006 : 12 (5) issues. 04/09/2006: 9 (3) issues only. Make sure to note if the bug has been fixed in HEAD already: it would be silly to have a fix in 4.7, to see the bug reappear when 5.0 comes out. (Queue #6) CVS Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 18/06/2006 : 72 (67) issues. 25/06/2006 : 71 (67) issues. 02/07/2006 : 77 (66) issues. 07/08/2006 : 72 (59) issues. 14/08/2006 : 88 (59) issues. 22/08/2006 : 81 (57) issues. 04/09/2006: 82 (64) issues . As you see, many issues are old (over 2 weeks old: 64 issues), so we have the choice between : re-rolling the patch for current head, set as code needs work, or set as already fixed if appropriate. (Queue #7) Your own list of Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&categories=bug&states=8&part… 1) Follow the search link above, 2) In the URL, replace "your_drupal_user_name" with your actual user name. 3) On the result page, click at the bottom of the page on the "#" link (Permalink to search query). 4) bookmark the page. Those are issues you have already participated in, and you should already know the context. Help the person preparing the patch to eventually come up with a patch that can be RTBC. Obviously, if there are many results to the query, start from those issues you are the most familiar with... If everyone does this, the result will be seen in the queues #4, #5 and #6 above. ******************************************* 3} Why this report and how to cooperate? ******************************************* There are now over 2200 issues in the queue. The figure sounds daunting: how can a very few volunteer developers deal with such a huge amount of bugs? The point is that we don't need to worry of the whole issue queue, but by getting somewhat more organized, the most important of those issues can be definitively dealt with. To start with, there shouldn't be anything critical within the Drupal project issues. Critical bugs must be dealt as a matter of priority. But one can get easily discouraged when facing 4 four pages of critical issues. The first step is therefore to sort out what is really critical from what is not. Having a shortlist of what is really critical, two or three developers can focus on a single issue, helping each other, so that one week later there is one really critical issue less. Similarly, 10-12 developers could get rid of 3-4 critical issues and in a few weeks, the list of critical issues would be down to almost nothing (only 1-2 issues caused by a large patch recently introduced in head, for example). If you wish to participate in tackling one of the 7 short issue queues featured here, please reply to the list, quoting only the issue you wish to 'adopt', changing also the subject title of your email to reflect the queue you have chosen. Hopefully, two or three more developers will reply to you, saying they want to help you with the issues in that same queue. Thank you to all the volunteers for your cooperation. Blessings, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

15 24

issue with ecomerce / na_arbitrator
by Dan Horning 07 Sep '06

07 Sep '06

I've discovered a quick issue that i wondered if anyone could point me in the right direction for the repair.. using NA_arbitrator ecommerce and workflow i've setup a ecommerce site i've setup workflows that grant access to given roles to ecommerce items however the add to cart links do not respect the roles assigned ... any thoughts as to which area i should be looking to ? -- Dan Horning - danhorning.com American Digital Services - americandigitalservices.com Where you are only limited by imagination. 1-866-493-4218 (direct) / 1-800-863-3854 (main number)

3 2

Core Mod or Patch For High-Availability Drupal?
by Mike Hostetler 06 Sep '06

06 Sep '06

Hi everyone- I'm currently running 4 Drupal installations on a Linux Cluster. I've got MySQL configured in a Master-Master Replication configuration (MySQL 5). This has worked very well for me. In the process of administrating my Drupal installations, I've added a few tweaks here and there to Drupal to help it perform better on this MySQL Replication Scheme. These tweaks have involved some drastic changes such as adding auto_increment fields to both the cache and sessions table. I've followed discussions on this list about the reasons for the design of the cache and sessions table and I'd prefer not to bring that up in this thread. My question to Drupal Devs is this, should I put my patches together into a mega-patch for Drupal to run on this configuration and then post about in the Drupal Handbook, or is there something else I should do? I'm running all the sites on 4.7.3 (one is on 4.6, and I've had to patch that like crazy, so I'm not even going to try and submit that patch). Thanks, -- Mike Hostetler mike.hostetler(a)gmail.com http://www.amountaintop.com

4 3

Looking for a maintainer for attachment and filemanager
by Heine Deelstra 06 Sep '06

06 Sep '06

Dear all, I'm looking for somebody willing to maintain Attachment and / or Filemanager. Attachement <http://drupal.org/node/10245> Filemanager <http://drupal.org/node/10243> Latest commit by the maintainer March 1 (2006) and a long issues queue lead me to believe the modules are unmaintained. I've send an email to ccourtne on Aug 13, but have not received a reply (and I don't want to wait longer). Everyone interested, please mail me or reply to this message and I'll make you the project owner. Regards, Heine Deelstra

6 6

PHPTemplate theme & usability
by Stefan Nagtegaal 06 Sep '06

06 Sep '06

I'm not sure I posted this to the right list, but you guys should forgive me when I'm on the wrong track.. As you (probably) know, I'm designing/coding a new theme. I am using PHPTemplate for the first time in my life to create a full theme (please don't ask why). Now, on my road to get this darn theme working I noticed that the following code is used inside coore themes to place the primary/ secondary navigation: <?php if (isset($secondary_links)) { ?><?php print theme ('links', $secondary_links, array('class' =>'links', 'id' => 'subnavlist')) ?><?php } ?> and: <?php if (isset($primary_links)) { ?><?php print theme ('links', $primary_links, array('class' =>'links', 'id' => 'navlist')) ?><?php } ?> Now, my question is why do we do this? There is a block generated for every new 'menu list' which can be positioned into every region a theme supports. This is imo very weird.. Even weirder is the way before you get the links to display into the defined place using the method above. (Goto 'admin/build/menu/settings', set the 'Menu containing (primary| secondary) links'). I thought we had the blocks generated for that? I was totally confused.. it took me 2 hours to spit through PHPTemplate to find a bug, another hour to fid some settings which would popup this idea on my mind, and 2 minutes in #drupal to get the solution.. I hope you guys don't mind me saying this, but as someone who has been using drupal for 4 years now, this does not make any sense to me at all.. is this only me? Is there anyone who could think of a way on how we can improve this? Or am I all wrong, and is this usable "as is"? Kind regards, Steef

3 3

hook_perm() and t()
by Augustin (Beginner) 06 Sep '06

06 Sep '06

Hi, hook_perm() doesn't use t()? I've checked a few core modules, and the perms are not wrapped in t(). Does this mean that the perms in ?q=admin/user/access are never translated? Is this valid? /************************************* * Implementation of hook_perm() *************************************/ function hook_perm() { return array(t('administer hook')); } and: 'access' => user_access(t('administer demexp')), ??? http://api.drupal.org/api/HEAD/function/hook_perm makes no mention of t() either way. thanks, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

3 3