May 2006 - Development - lists.drupal.org

Re: [development] Freezing the Drupal API
by Khalid B 16 May '06

16 May '06

On 5/15/06, Richard Archer <drupal.org(a)juggernaut.com.au> wrote: > Recent discussions on the Consultants list has raised the issue of > the cost of doing business using Drupal, notably the high cost of > upgrading existing installations due to the ever-changing nature > of Drupal's API. > > I wonder if there would be any interest in forming a group to > tackle this by identifying where the current API has potential > for improvement and perhaps even writing some code! > > My aim would be that as of Drupal 5.0 with CCK, the published > API would be treated as "stable" and changes to it would be > resisted strongly. > > IMHO, if this could be achieved it would give Drupal a much more > mature look and make it more attractive to large users. > > It would also increase the manpower available to work on future > Drupal development because right now extra resources are being > wasted maintaining the 4.5 and 4.6 trees, simply because the API > changes between releases makes it impractical for many users to > upgrade to 4.7. The shifting API from release to release is a pain, yes, but the benefits of that outweigh the drawbacks. The core developers innovate as they see fit, and do not let the API freeze limit their creativity, the features to be implemented, or the overall flexibility, power and compactness of Drupal's core. Perhaps it is best to spend energy on migration paths (e.g. Flexinode to CCK, forms updater, ...etc.) rather than freeze the API early. Let the creative juices flow ...

11 13

programmeerzomer.nl
by Breyten Ernsting 16 May '06

16 May '06

Hi, At http://www.programmeerzomer.nl/ there is an initiative to organize an event a la Google SoC, but more directed to Dutch open source software. However, the software itself doesn't need to be Dutch, but the mentro has to be? Any takers? I've entered as a participant, so obviously I can't mentor, therefore I'm sending this out. Grtz, Breyten :-)

2 2

hook_user case:update
by Stefan Pampel 16 May '06

16 May '06

Hi, the task is to update a module from 4.6.x to 4.7.0. In drupal 4.6.x i got the a form field form the user settings Dialog during the update proces via $foo=$edit['bar']; modified it via $foobar=_fun($foo); an returned via $edit['bar']=$foobar; to store it modified in the users settings. I looked arround 'Converting 4.6 modules to 4.7' but found no solution for this problem. any hints? thx -- _______________________________ / / | polyformal / | Stefan Pampel / | Kaesenstraße 8 | 50677 Köln - Germany | phone: +49 3103 122 | fax: +49 221 9311 9223 | www.polyformal.de |_____________________/

1 0

Re: [development] Freezing the Drupal API
by Greg Knaddison - GVS 16 May '06

16 May '06

On 5/15/06, Richard Archer <drupal.org(a)juggernaut.com.au> wrote: > My point is, there are already multiple forks of Drupal. > > There's the 4.5 branch, the 4.6 branch and the 4.7 branch. > When 4.8 is released it will have a maintainer appointed > and there will be 4 forks. Plus the Bryght guys have > their own version of Drupal. I guess Civicspace does too. > Bèr often talks about his Sympal fork. You keep using that word. I do not think it means what you think it means. http://en.wikipedia.org/wiki/Fork_%28software_development%29 All of the parties involved in the "forks" you mention are maintaining them in symphony, not in opposition. > This is a ludicrous and unnecessarily complex position to > be in. And all because IMHO insufficient thought has been > put into building a robust, flexible API so that Drupal can > be enhanced without having to hack on core or have the API > whipped out from under your feet. People have actively stated the motvation for not having a static API: it encumbers innovation. It's not insufficient thought, it's sufficient thought that has been applied in a different way due to different philosophies. > It should not be so painful to upgrade from 4.5 to 4.6 that > people stick with 4.5 for years after it has been superceded. This is an unreasonable point of view. People don't upgrade for a variety of reasons and only one of them is how painful the process is. Software upgrades are hard to get right. The companies that need an easy upgrade path end up running systems that have had very little innovation in 30 years (I worked in telecoms, I know of which I speak on reliability vs. features). I think everyone agrees that upgrades need to be reasonably easy - but there is a delicate balance with innovation and in the case of Drupal the desired philosophy has been stated, documented, and agreed (by most, if not all). > I am offering to help formulate a plan whereby these problems > can be prevented or at least lessened in the future. Well, that is nice. But code is gold. Talk is silver. And talk of talk must be made of an even lesser metal. Personally, my "talk" on the subject is that Drupal should version the API and modules should be checked against the API version number prior to being enabled. The module maintainer is then given the additional burden of updating the "compatable with XXX" flag in the .install file. Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses

3 3

WordPress' project Shuttle: Administration redesign project
by Stefan Nagtegaal 16 May '06

16 May '06

http://www.brokenkode.com/shuttle This is awesome! Spread over with AJAX/JavaScript goodies and even more eye-candy WordPress redesigned their Administration section.. Have a look at the screenshots and enjoy this ride through WP's wonderfull new and improved admin interface. Steef

11 14

finding blocks and getting them simpler.
by Bèr Kessels 16 May '06

16 May '06

Hello list, One thing that has bothered me for a long time, is how to get/find/parse blocks in a simple way. Problems are: * you need to read the code to find the "delta". Modules like views require you to hover the admin/blocks/edit links in order to find the delta. * a block returned by hook_block('view') needs casting and remodelling before I can be passed to theme_block. I addressed the last point with a helper function get_block. But that function still has the first problem above: You need to know a) the module that makes the block and b) the delta. Does anyone know a trick for this? Or did I miss an API function? Is someone working on code for this? NOTE: I am not particularly interested in a discussion to revise the core block architecture. Eventhough that might be an interesting project, I am looking for an intermediate function/api-set right now :) Bèr

8 17

RE: [development] RFC: Candidate 'premium' modules
by Boerland, Bert 16 May '06

16 May '06

-----Original Message----- From: development-bounces(a)drupal.org > Exactly. Any Drupal 4.7 site can be configured to 'call home' and > report back a list of the enabled themes and modules. Like that, we > can see what modules are actually being used (rather than just being > downloaded). sampling is a bit harder than that. remember http://www.umich.edu/~newsinfo/MT/97/Fal97/mt1hf97.gif ? replace "telephone" with "call home", "samplers" with "internet sites" and "voters" with "drupal sites /including/ intranets".

2 1

Re: [development] Freezing the Drupal API
by Jeremy Epstein 16 May '06

16 May '06

I agree with Richard's ideas, but not with his plans ;-). As one of the many developers who has witnessed and has had to become familiar with the API change from 4.6 to 4.7, I am definitely in support of Drupal's "constantly changing APIs" policy (if it's between stable versions, of course - and it is). Had we not introduced FAPI, and the many other (smaller) API changes, Drupal would be stuck with its own mistakes, and would be unable to fix itself. In Drupal's case, the benefits of better code far outweigh the drawbacks of difficult upgrade paths. Plenty of other examples (before my time) illustrate this point as well, including the theme system overhaul from 4.4 to 4.5, and the introduction of the node system itself in 3.0 (according to <a href="http://cvs.drupal.org/viewcvs/drupal/drupal/CHANGELOG.txt?view=markup">the changelog</a>, there was no node system in Drupal once upon a time!). I would like to see plenty more such examples in the future. As such, I am against freezing the APIs. However, I do think that we should work towards making the APIs more robust and longer-lasting, and that we should make more of an effort to get them right in the first place, so that there is less need to re-do them. I don't want a stable API to be a strict rule for Drupal, but I'd like to see it happening more, as a side effect of good program design. I realise (as I'm writing) that what I'm saying doesn't really need saying, because our aim always is to "get it right the first time", and we are succeeding in doing this more and more (hopefully FAPI will prove to be a good example of this, and FAPI 2.0 will not break the FAPI 1.0 API). But I think that Richard has a point: Drupal does often fall into the trap of "code first, think later", and we should certainly make a conscious effort to do it the other way around whenever possible. And I also give my +1 to Gerhard finding more manners, particularly for a fellow core developer such as Richard. If we can "think first, code later", we can also "think first, write emails later". Cheers, Jaza. On 5/16/06, Richard Archer <drupal.org(a)juggernaut.com.au> wrote: > Hi all, > > Recent discussions on the Consultants list has raised the issue of > the cost of doing business using Drupal, notably the high cost of > upgrading existing installations due to the ever-changing nature > of Drupal's API. > > I wonder if there would be any interest in forming a group to > tackle this by identifying where the current API has potential > for improvement and perhaps even writing some code! > > My aim would be that as of Drupal 5.0 with CCK, the published > API would be treated as "stable" and changes to it would be > resisted strongly. > > IMHO, if this could be achieved it would give Drupal a much more > mature look and make it more attractive to large users. > > It would also increase the manpower available to work on future > Drupal development because right now extra resources are being > wasted maintaining the 4.5 and 4.6 trees, simply because the API > changes between releases makes it impractical for many users to > upgrade to 4.7. > > ...Richard. >

1 0

Keepin Drupal together
by Bèr Kessels 16 May '06

16 May '06

Hello, Not sure where this should go. Into devel ML or Recently some very frustrated (?) and hostile threads leading nowhere but to even more threads have arised on the ML. Let us please, for a second, not look at the content of these threads and at the If we continue with facilitating such hostility, or (as seen from the other side) such naivity (which seems to be the reason for that hostility), I am quite sure that people will, leave Drupal. Our ML are primary communications. If I were to join a system, because I am looking o do buisyness with that system, but where the first thing I am told is to FSK Up Because We Are Not Going To Listen To Your Uninsightfull Ideas I am out of there. And even If i see others telling that to others (whom might have similar ideas to mine) the same will happen, just as soon. If someone is a long term member, but see communication going all wrong, people not listening, and progress not going in the direction that person would like to see it going, he or she might say: well indeed, FSK IT. I am Fsking Up as suggested, but I am taking my work with me. Result: a fork. Drupal cannot use a fork. But with the current athmosphere I taste, this might not be far from happening. Therefore: Lets stay professional. Keep your frustrations for your friends. For your family, or even your schrimp ;). We are talking about software, not about ego's. Let us respect one anothers needs. Not everyone needs Drupal for his or her hobby-train-club-site. Some make a living from it, some need it for their make-anarchy-change-the-world-activists-group. Respect the difference in views, and in needs. Respect that others need Drupal to do and be different than what you think it should be and do. We should stand above this harsh talks at all costs. And I think that if people are not able to stand above that, they should be told so. (by whom?) I take my share of responsibility, for this too. For I have not been only positive about Drupal lately either. But I feel that should be possible. For if we sit back and say "Drupal is perfect. We want mo more change (as in: community, or way of doing stuff)" we might as well call ourselves dead. So lets all start with looking at ourselves and see how we can all make Drupal better by starting with some respect for our fellow developers. And with repect to their ideas. Think twice before replying. If you completely and utterly disagree, say so, but keep in mind that your opinion is Just Another Opinion. You are nothing higher or better then the one with the original idea. No matter how much more code you committed or how much lower your UID is. That is, has never been, and (if its up to me) will never be a criterium for being able to voice yourself. Never. Bèr

1 0

Re: [development] Freezing the Drupal API
by Khalid B 16 May '06

16 May '06

> I know. This, along with "code is gold" is the Drupal mantra. I, for one, do not fully agree with this mantra. My view is that discussing something before hand, hashing out the pros and cons with the community, design issues, alternatives, APIs, and that gory stuff BEFORE writing code will give it a better chance to be thought out, well designed, and has good chance of getting committed. Often writing code and then trying to get +1s on it getting committed can be an energy drain. Code can be gold, but can also be a waste of energy in some cases. This is not to say that that model is always flawed, but sometimes it is an overused mantra that has its drawbacks ... So Richard, in this instance, I do agree with you.

1 0