January 2006 - Development - lists.drupal.org

+= on arrays
by Karoly Negyesi 18 Jan '06

18 Jan '06

Hi! jvandyk raised the question whether += is officially supported by PHP as it is not in the documentation. I contacted Goba who pointed me to lxr.php.net and from there I read the relevant pieces of PHP source code and it's quite clear it does. Stop here if you are not interested in gory details. I said you should stop, right? OK, here are the details if you have not stopped: http://lxr.php.net/search?string=T_PLUS_EQUAL both in Zend and ZendEngine2 we can see that T_PLUS_EQUAL is executed by: zend_do_binary_assign_op(ZEND_ASSIGN_ADD, &$$, &$1, &$3 TSRMLS_CC); so we move on to http://lxr.php.net/search?string=ZEND_ASSIGN_ADD and jump to http://lxr.php.net/source/Zend/zend_execute.c#1162 case ZEND_ASSIGN_ADD: EG(binary_op) = add_function; goto binary_assign_op_addr; and finally we peek into add_function: http://lxr.php.net/source/Zend/zend_operators.c#613 617 if (op1->type == IS_ARRAY && op2->type == IS_ARRAY) { So. We gained the knowledge that it's split into an addition and an assign before the op types are checked. Therefore, if + works for a certain kind of operation, then += does, too. (Zend2 analysis is left as an exercise. It leads to add_function, too.) Regards NK

5 10

reminder: bugfix party tomorrow Wed. Jan. 18
by ae2005 18 Jan '06

18 Jan '06

Reminder: On Wednesday, January 18, 2006 5pm London time (noon eastern time US, 9am US West Coast Time, 7pm Bucharest time), the Drupal community is invited to a Bug Fixing party. Even if you can't attend at that time, you can still help out. See you there! ae2005 http://drupal.org/node/44182

2 1

Why Drupal 4.7 is late? (long)
by Karoly Negyesi 18 Jan '06

18 Jan '06

First of all, it is not late. It'll be out when it's done and noone said it otherwise. However, it was announced quite some ago that "In preparation of the Drupal 4.7.0 release, development of Drupal core will be frozen on September 1st." http://drupal.org/node/28466 On September 1st, Dries announced http://drupal.org/node/30176 that September 15 is the new code freeze date mainly due to form API and upgrade system improvements. He hoped to have a release candidate on October 7. Form API thread http://drupal.org/node/29465 started on August 23. The Form API was committed to core in October 7. In a mere three months it saw 48 revisions. Bootstrap, for example saw 80 in two years. Even node.module needed four months to reach v1.48 but that was almost five years ago and much, much less code and users were affected. Form API is a big change. Not just the way the forms are defined but the whole workflow is changed. You no longer have access to the POSTed information on form build time, you can interact with that later on via various callbacks. This immense change is percieved as hard but it is not. Aaron Welch (also known as crunchywelch) have converted nothing less than flexinode single handedly in three days time and this included several form API fixes -- this was back when form API itself was pretty bogus. His estimate (and mine) is that it can be done in a day now that form API is fixed up. Other modules have also been converted. Ecommerce is under way. Module developers, brace yourselves and try it. It's not hard if you first forget the old ways. But alas the form API conversion of core were not made by form API experts. You know why? It's so simple. Think a bit on it. I think you guessed it: because there were none (with Adrian being the exception, of course). But how could there be? It's a whole new API. We struggled, learned it, added stuff to the API itself when there was a need. So, there are quite a lot of bugs in core resulting from this conversion and the quality is not even. Currently, there are only a handful people who can -- or want? -- to hammer these bugs out. Everyone, it's impossible for a small handful of developers to fix them all. Often patch fixing efforts abandoned and I need to take over. I took the form API mantle but it's impossible to cope with the load! Currently, being a form API maintainer means that I need to understand _all_ core (there are approx. a thousand functions and some 32K LoC) on an astonishing level because various bugs that were introduced by form API fall somehow on me. If I'd be a millionarie with nothing else to do but fixing core bugs, it'd be a different situation but alas I need to earn money. Do you except the menu maintainer to fix all those menu permission issues just because menu system is used? So, I ask for the help of seasoned developers. Form API is not voodoo magic. It is not written in Brainfuck. It's PHP code which you guys can understand pretty well. It's even documented even if the documentation is a bit spotty. But there are good things also -- because fixing all this stuff took this long, the upgrade system could run its course and got commited on December 6. It's also a very good thing, now modules can use the upgrade system. This sounds a bit deceiving but if you think that there is no difference on a database level between create and alter then you'll quickly realize that this is a pillar for install system. And we can also say that when you have added a feature to your site by installing a new module, it's a new version of that particular site, it's indeed an upgrade. Thanks for bearing with me Karoly Negyesi Ps. If anyone wants to start bitching around "you should have released without form API", then first please show your comment with a September date asking for that on Drupal.org -- I met none in the roadmap posts or the form API thread.

17 24

Developer preview: GoJoinGo a group events service based on Drupal
by Kieran Lal 17 Jan '06

17 Jan '06

Hello, some of you may have noticed that we have begun checking code into a new Drupal-based project called GoJoinGo that is intended to provide a "group events" type of service. The project includes a simple bash script that allows you to check out all the necessary modules using CVS and you can then populate the database. You will also notice that there are some significant patches for 4.6 modules. It is our intention to remove these patches in a Drupal 4.7 release as most of these patches are already included in Drupal head. We are now taking the step of providing a developer preview of GoJoinGo. We are providing this preview in the hope of attracting developers to who want to partner with us in delivering sites based on this code base. We are currently in the process of deploying GoJoinGo as a stand-alone group events service, as well as deploying it to be integrated into two existing commercial websites that are themselves based on Drupal. This site is very much in active development, with design improvements pending. We are reaching out to the Drupal developer community, but we are not declaring a public beta. We reserve the right to lock the site down if it starts getting blogged as an official launch. We will not be answering business questions, service questions, or feature request questions at this time. We will answer questions that fit between <?php and ?>. Programmers and site developers who are looking for support should expect to reciprocate with documentation and patches. CivicSpace Labs

2 2

NULL testing and isset
by Karoly Negyesi 17 Jan '06

17 Jan '06

Hi! instead of === NULL use isset, please. Three times faster. If you are using !$foo for NULL testing (checking whether a static is set), then use isset, too. I have not checked how many times isset faster here but that's a language construct and it's a hell lot faster. Regards Karoly Negyesi

2 1

Module to Track RSS Subscribers
by Nick Lewis 17 Jan '06

17 Jan '06

Hi folks, I'm in the early stages of building a set of scripts that parse out info about hits to a site's RSS feed. The goal is to trasmogrify what is now only viewable as thousands of anonymous hits to node/feed to a list of total hits to node/feed by ip address. My hope is that this will be the foundation for a module/feature that gives me a ballpark idea of how many RSS subscribers I actually have. Anyone working on something similar? Or should I consider building this as a new feature to submit for review in the statistics.module? Finally, the statistics.module dropped a lot of functionality that would have allowed this anyway after the port to 4.6 -- was there a good reason for this? Best, Nick Lewis http://nicklewis.smartcampaigns.com

9 20

[lazyweb] Drupal Configurator
by Arnab Nandi 17 Jan '06

17 Jan '06

Hi, Just wanted to float this idea to the devel group. The Drupal Configurator will be an OFFLINE app (Java / .NET|Mono?) that allows you to perform most admin functions in an offline mode. Even with a decently fast connection, it is quite frustrating if you have to set up * flexinode * taxonomy * profiles via the browser... so many page views / iterations!. So, why not have a small forms driven app that allows us to do all of this in one shot, and then upload the combined preferences to the website? This can be done by setting up a special module for the configurator, which uses XML-RPC to read in and configure Drupal using this tool. I'm never going to have the time to do this, but it would be awesome if someone actually writes this. Let's see if the Drupal Lazyweb works! -Arnab -- http://www.arnab.org

6 5

Activate/Deactivate hooks for modules
by David Reed 17 Jan '06

17 Jan '06

I find my self longing for Activate and Deactivate hooks for modules. These hooks would run only when the module is activated or deactivated in the admin/modules form This would give module developers a convenient place to run on-time setup code (e.g. database setup) and a place to do cleanup once their module was deactivated. If there's interest I could create a patch for discussion. Is there another easy way to accomplish these types of setup and cleanup tasks?

3 2

Re: [development] NULL testing and isset
by David K Norman 17 Jan '06

17 Jan '06

development-request(a)drupal.org wrote: > Date: Tue, 17 Jan 2006 12:24:08 +0100 > From: "Karoly Negyesi" <karoly(a)negyesi.net> > Subject: [development] NULL testing and isset > > Hi! > > instead of === NULL use isset, please. Three times faster. If you are > using !$foo for NULL testing (checking whether a static is set), then use > isset, too. I have not checked how many times isset faster here but that's > a language construct and it's a hell lot faster. I tried it out. I looped through a check of === NULL and isset each 700000 times. The === NULL loop took an average of 1.57 secs, and == NULL was 1.68 secs. The !isset test was only 0.28 secs and empty at 0.25 secs on my Athlon 2400+. Using !$var was the fastest at 0.21 secs, though I think ! is sloppy and is the most difficult to tell what exactly is being tested. I'll keep my test script for a while if anyone wants to see (31 LOC).

1 0

RE: [development] Severity levels
by Steven Peck 17 Jan '06

17 Jan '06

For now it should probably go as a child page here: http://drupal.org/node/10259 so it doesn't get lost. I am looking through the developers guide strucutre and trying to figure the best approach for it. We have some duplicate and even triplicate content that needs heavy editing and I want to do it it in one fell swoop. ________________________________ From: development-bounces(a)drupal.org on behalf of Bèr Kessels Sent: Mon 1/16/2006 8:29 AM To: development(a)drupal.org Cc: documentation(a)drupal.org Subject: Re: [development] Severity levels This should (also) be discussed on the docs list. Where can we put it? IMO a simple bookpage with a link on the issue creation page should do, not? Op maandag 16 januari 2006 17:17, schreef Karoly Negyesi: > extreme critical: when a bug breaks all core , sessions, bootstrap one of > the form elements or something like that. These are to be fixed > immediately because Drupal HEAD is not usable at all. > > critical bugs render a whole (or most of a) module unusable. Example: you > can't post a forum topic. > > major bugs: a smaller part of a module. You can't add a menu with menu > module. > > -- below these are bugs that do not hold a release -- > > Normal bugs just bugs, we could even release with these. Just one > functionality, like the category filter not working on node admin screen. Can we release with these? Personally I don't really care, and woulod say 'yes'. But that is because I work for my cleints and can filter out therse bugs before a site goes live. But certainly Joe Schmoe will get a negative idea about a piece of software that 'has bogs all over the place' (I cannot find the comment IO refer to, anymore). I think this is up to Dries to decide, what and how many boogs are still alive when we go live? > And minor bugs are cosmetical stuff, notices etc Are those not 'tasks' instead. Or even features? -- PGP ber(a)webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels(a)gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc

3 2