June 2008 - Development - lists.drupal.org

schema API add column after
by Ashraf Amayreh 10 Jun '08

10 Jun '08

Hello all, I have an alter statement where I add a column at a specified location "ALTER TABLE {example} ADD COLUMN def TEXT AFTER abc" in drupal 5. Checking the schema API I can't see an equivalent to specify the position of the new field, I guess it just appends it at the end of the table. Any way to work around this? -- Ashraf Amayreh http://blogs.aamayreh.org

9 12

MENU_LOCAL_TASK for just some node types
by Lluís 06 Jun '08

06 Jun '08

I want to make avaliable a local menu for just some node types, how can I achieve this? thanks. -- *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les esperances. *Als llocs desconeguts només s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

6 12

schema api enum data type
by Ashraf Amayreh 05 Jun '08

05 Jun '08

Hello all, I'm upgrading my module to drupal 6 and was using the enum data type, how can I handle this in the schema API? I searched the documentation but no enum and only a comment that wasn't answered. Any pointers appreciated. -- Ashraf Amayreh http://blogs.aamayreh.org

2 2

Re: [development] lightbox module comparison
by Karen Stevenson 05 Jun '08

05 Jun '08

I think a 'module comparisons' section is important enough to deserve a top-level place in the handbook, with a link from the downloads page to make it easy for someone looking for modules to find. I actually think writeups like this are far more useful that the contrib module rating system that is often discussed. What does a 5 star rating tell you? It tells you the module solved a specific problem for the person who rated it, it doesn't tell you if it will solve *your* problem or be useful in *your* situation. But this kind of writeup makes it easy to see which module is the best fit for your particular situation, which is really really useful. This should not be buried down in the module documentation -- someone looking at one of the other modules would never see it. It should be very prominent (and that hopefully would also encourage other people to add more of these kinds of comparisons). For instance a good comparison of the different wysiwyg editors would be pretty useful :) Karen ----- Original Message ---- From: FGM <fgm(a)osinet.fr> To: development(a)drupal.org Sent: Tuesday, June 3, 2008 10:27:32 AM Subject: Re: [development] lightbox module comparison I've done one on the two glossary modules I'm aware of (glossary.module and g2.module), it's on the g2 project page. Maybe there are more, though ? This being said, you might have something: module duplication and module voting being recurrent themes, it might make sense to formalize a rule like: "if you're doing a module that resembles other modules, create a comparison page, that will go in the <to be determined> section of the handbook", in the dev manual. What do you think of it ? FGM

7 12

With the Tid get last node
by Da Costa Alcindo 04 Jun '08

04 Jun '08

Hi, I am currently developing a module that displays a block with the last article in each category. Is what someone has already sought to retrieve the last article from a tid? With a function like taxonomy_get_last_node($tid) ?? Cheers, Da Costa Alcindo

4 6

Plone versus Drupal
by Chris Johnson 04 Jun '08

04 Jun '08

In looking for some use cases information for Drupal, I came across the following blog post about Plone versus Drupal: http://m.odul.us/2007/09/02/plone-vs-drupal-take-one It's worth reading not just to see how one person compares Drupal to Plone, but to see where Drupal is lacking some interesting capabilities (e.g. being able to generate Plone modules using UML).

1 0

Re: [development] Trust (was: Hit and run contrib)
by Jakob Petsovits 04 Jun '08

04 Jun '08

On Friday, 30. May 2008, Daniel F. Kudwien wrote: > We are parsing the "#12345" bit, but why don't we also parse the "by sun" > bit to assign 'contributor credits' to users for the corresponding project? Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default. > OTOH, if there was a prepared candidate - would you really grant CVS > access? Would you grant access to me? The question is "would I trust you not to mess up my modules"? Personally, I'm confident that you are careful with other people's modules (given your previous track record), I would grant you commit access to all my projects in a second because I know that you won't abuse that power. But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong. Now there are plenty of arguments against this, but I think trust is a crucial element in open source projects, and stimulating involvement is important *especially* for modules that have wide exposure and a large user base. I think granting CVS access should be the default, as well as expecting the account holders to follow a commit policy that we set up. Instead of denying commit access to single directories, we'd trash the CVS account of people who don't respect the commit policy (which would involve not pissing off the respective module maintainer). That also has the consequence that people who deliver more and better code for a given module can't be blocked by inactive maintainers anymore, instead the maintainers have to actively work on their status as project leader. Which in turn stimulates progress both of "external" contributions and of maintainer involvement. As of now, modules are considered to be the personal property of a given person or company, even if their importance has a much higher impact than those. I think we should get away from this notion, and consider modules on drupal.org the joint property of the community, not only in license but also in governance. If collaboration doesn't work out (which I believe will be the exception much rather than the rule), one can still fork anything and come up with something else on his own. That's how open source normally works, and I fail to see why drupal.org needs to be the big exception. If we grant CVS access to people, we should trust them to fix more stuff than they break. If they break more stuff than they fix, retract commit access on the whole. Think about how we can make a transition to trusting people. Wishes, Jakob P.S.: A showcase. KDE has a repository where each committer has access to the whole SVN repository, and an accompanying commit policy [1] (next to other policies). Potential committers need to formally apply for an account, but when they get one then they're trusted to do stuff right. And you know what? It works. Bugs are fixed by people who would otherwise just be watching the progress, and code gets ported by people who modify the base framework. Just recently I fixed a few trivial bugs in Kate, which made me motivated enough to join the Kate development list and post a few more, less trivial patches there for review - if they're approved, I can commit them on my own. On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess. Now you can critizise me for being lazy, but I think this is symptomatic and happens all the time. If we want to scale contrib, we need to lower the contribution barrier for people who are able to fix stuff, while raising the barrier for people who break stuff. Let incompetent CVS users release their modules on their own server (they're probably no good for drupal.org either) and educate them to get into version control and patches before they're granted a CVS account. In turn, give trust to the people who actually have proven to be worthy of a CVS account. [1] KDE commit policy: http://techbase.kde.org/Policies/SVN_Commit_Policy *goes off to get his flame-resistant jacket*

7 14

lightbox module comparison
by Stella Power 03 Jun '08

03 Jun '08

Hi, There's quite a few modules in Drupal which provide similar but different functionality. I maintain the lightbox2 module and frequently get asked "what's the difference between lightbox2 and module X?" So I've finally created a doc comparing the various "lightbox" type modules available in Drupal (lightbox2, thickbox, shadowbox, .....). The doc is available at http://drupal.org/node/266126 for anyone who may be interested. I'd really like to see more comparisons done on modules which share similar functionality. I think it would be quite useful to see such a comparison before downloading all the modules and trying them out one by one, especially for newbies in the Drupal community. Just my 2 cents. Cheers, Stella

11 11

Hit and run contrib
by Caleb Gilbert 03 Jun '08

03 Jun '08

No real propositions here - just observations...but with the popularity of Drupal growing by leaps and bounds the amount of flaky hit and run maintainers/contrib-modules also appears to be growing exponentially. It's annoying. :p - Caleb

15 22

Request for Comments: Search.inc
by Michael Haggerty 03 Jun '08

03 Jun '08

I am writing to request comments on a proposed modification to Drupal core. Proposal: move the core search functionality in Drupal into an include file which can be specified on a per site basis. The actual functions used to return search results would not change, this proposed modification would simply put them all in a file which can be specified within settings.php. There are a number of reasons to consider doing this: 1) The flexibility to specify different search components would resolve some potential design deficiencies in the platform as it stands now. We have been doing some work integrating the Xapian search engine with Drupal. Instead of storing indexed results in the Drupal database, we are putting indexed content in Xapian instead. To get this to work properly, we have needed to patch core, which represents a deficiency both in terms of installation and long term maintenance of sites. Modifications to core mean people are working with unique distributions of Drupal instead of a common distribution, which are more complex to support. 2) This change would not differ significantly from design patterns currently in place within the framework. Other core components have already adopted this approach. An alternate cache.inc file can be specified within settings.php and is used by Robert Douglas' memcache module. Settings.php has had the ability to override system settings for a long time. 3) In some high traffic scenarios, database throughput becomes a bottleneck to the point where Drupal's current search features become unusable in the context in which they are deployed. Providing the flexibility to specify the underlying search components used for Drupal will provide system architects with additional options for scaling Drupal sites without losing characteristic features of the platform. In the case of Xapian, all database traffic related to search features are offloaded into an external database, which could represent significant gains in Drupal database throughput. 4) Open source search engines are becoming increasingly sophisticated, and there are a number of emerging systems coming of age which developers may want to integrate in the future. Developers are often loathe to want to hack core, for reasons ranging from inexperience to lack of support for core modifications within the Drupal community. Being able to modify the underlying search components without the need for a core patch greatly simplifies the process of integration and likely increases the likelihood developers will want to attempt integration projects. 5) Search remains an important component of any Web site. One of the great strengths of Drupal is the ability to provide an integrated set of tools for managing content. The most significant benefit to adopting this approach could be the ability to expand the range of options available to implementers at the time a site is being built. Providing numerous search engine configuration options with relative benefits and drawbacks increases the strength of the platform. Best Regards, Michael Haggerty _______________________________________________ Michael Haggerty | Managing Partner | Trellon, LLC web www.trellon.com | email mhaggerty(a)trellon.com tel 240 643 6561 | aim haggerty321

7 6