- Development - lists.drupal.org

Re: [development] hook_theme vs hook_elements?!?!
by Darrel O'Pry 03 Dec '07

03 Dec '07

I'm confused about hook_theme. I should have been paying more attention to that discussion. It seems to duplicate a lot of the functionality of the existing render api. I was wondering if someone could help me understand the differentiation and use cases for the similar features? A quick overview of functional duplication... The hook_theme 'arguments' property seems like it would be roughly equivalent to the way element property default values are set using _element_info. The hook_theme 'function' property seems very similar to how '#theme' functions currently. The hook_theme 'preprocess' property seems very similar to the render api's '#pre_render' The hook_theme 'override preprocess' seems to provide the same functionality as hook_view_alter... .darrel.

1 0

PostgreSQL Help Wanted
by Hans Salvisberg 02 Dec '07

02 Dec '07

Hello PostreSQL Gurus, Please take a look at http://drupal.org/node/196831 Could this be a long-standing pgsql bug in core? TIA! Hans

1 0

Should CSS @imports be fixed in D6?
by Gábor Hojtsy 02 Dec '07

02 Dec '07

Hey guys, Anyone interested in fixing CSS aggregation of @imports which is currently bugos in Drupal 6, or I should postpone this to D7 being completely out of your interest? http://drupal.org/node/113607 http://drupal.org/node/193604 It is sad to leave bugs in Drupal 6, but without people interested in fixing them (ie. pointing to the theme inheritence feature I pointed people to in the issue) this is going to be left in the release. You know having critical issues in the Drupal 6 issue queue does not help to block the release, without people interested in fixing them. The CSS @imports issue is one of the most neglected ones, if not the most neglected one itself. Thanks for all efforts, going into stabilizing Drupal 6 and advancing with the release. Gabor

1 0

Color.module question from a GHOP student. Can you help?
by Angela Byron 01 Dec '07

01 Dec '07

If you know anything about color.module, I'd really appreciate if someone could answer here: http://groups.drupal.org/node/7363

1 0

Re: [development] Mischievous registration of projects
by Michelle Cox 30 Nov '07

30 Nov '07

My understanding is that this is already considered unacceptable but I don't know if any concrete action is being taken against it. It might be one of those things where the people who are able to do something about it are simply too busy to play police. It should be common sense that you don't create a project unless you're going to do something with it. Michelle On 11/30/2007 8:54:27 AM, Roman Chyla (roman.chyla(a)gmail.com) wrote: > Please don't make the registration process difficult or slower. It is > better to focus on post-checking - if the module has not proven any > activity, some action might be taken, but not sooner than that. > roman > > On Nov 30, 2007 1:57 PM, Thomas Barregren <thomas(a)webbredaktoren.se> > wrote: > > Hi all, > > > > Maybe I talk through my hat, but I suggest a policy against mischievous > > registration of projects for the purpose of claiming namespace, e.g. > > opensocial, or for other reasons than providing a module, e.g. cvsdemo? > > > > Thomas > >

4 3

Re: [development] How many modules is too many?
by Khalid Baheyeldin 30 Nov '07

30 Nov '07

(Changing the subject) I regularly see 80+ to 110+, and that causes Apache to eat 100MB per process, which is really not good ... This is the open buffet binge syndrome detailed here: http://2bits.com/articles/server-indigestion-the-drupal-contributed-modules… On Nov 21, 2007 12:50 PM, Jim Li <jimmydami(a)gmail.com> wrote: > Cool, thanks! > It'd be interesting to have a poll on how many modules people use on a > social network site. I heard someone uses 160 modules at his dev site, > it may go down a bit later, but it probably will still in the 100+ > ragnge :) > > On Nov 20, 2007 6:31 PM, Earl Miles <merlin(a)logrus.com> wrote: > > On the other hand, having 150+ modules load *is* going to eat a whole > > lot of memory; so actually activating all these modules is a really bad > > idea. > > > > And yes, the modules page under 4.7 is going to choke like [insert > > really bad sports team metaphor here]. > > > > > > Sean Robertson wrote: > > > As I understand it, Drupal 5+ no longer does that. That's what the > > > .info files are for. Those files are only a couple hundred bytes each > > > so the full page even with a ton of modules downloaded should only use > a > > > small amount of memory unless you enable them all (which would affect > > > all pages, not just that one). > > > > > > > > > > > > Jim Li wrote: > > >> Hello, > > >> > > >> I saw some complaints that admin/build/modules page loads all modules > > >> and eats up lots of memory. And I heard a story that somebody new to > > >> drupal was trying to evaluate >150 modules and eventually drupal > > >> 'crashed' on this page due to memory limit. So I am just wondering is > > >> it a good idea that we use tabs to separate module groups on > > >> admin/build/modules page? Will it help with the problem? We can have > > >> three tabs: core, contrib, oh and uninstall (which will need some > > >> speical css rendering). > > >> > > >> Thanks, > > >> Jim > > > > > > > > -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.

2 2

Fatal error : install profiles and the use of hook_install
by Augustin (Beginner) 30 Nov '07

30 Nov '07

Hello, There seem to be a critical bugs hiding behind the way the install profiles are implemented. At the very least, there seem to be a gross inconsistency in the documentation. I could have fixed the api documentation myself, except that I am not sure what is the 'normal' behavior. When creating an install profile, one runs against such errors: "Fatal error: Call to undefined function xxx()" http://www.google.com/search?q=site%3Adrupal.org+profile+install+Fatal+erro… This happens when one includes a few specific modules in hook_profile_modules(), including book.module: http://drupal.org/node/164458#comment-643884 The api says that all functions are loaded when running hook_install(): http://api.drupal.org/api/function/hook_install "Note that since this function is called from a full bootstrap, all functions (including those in modules enabled by the current page request) are available when this hook is called. Use cases could be displaying a user message, or calling a module function necessary for initial setup, etc." But the profile documentation implies the contrary: http://drupal.org/node/67921 the modules (including core required modules and their functions) are NOT yet included when running hook_profile_modules() (which calls hook_install()). The modules are included only at a later stage, hook_profile_final(). A similar problem occurred with forum.module, until a certain function call was moved to hook_enable(): http://drupal.org/node/157519 This begs the question: what is it ok to include in hook_install()? Is hook_install() only for the DB schema, or can heavier lifting be done using any function call? If this cannot be fixed for D6, some warning should be included in the documentation, especially here: http://drupal.org/node/67921 . I didn't do so myself because I am uncertain about all the above. Blessings, Augustin.

5 6

Re: [development] Suggestion for User Permissions
by Simon Roberts 30 Nov '07

30 Nov '07

Agree. If someone really wants an "admin role" they can use (ta-da) http://drupal.org/project/adminrole > Date: Thu, 29 Nov 2007 09:45:53 -0800 > From: "Steven Peck" <sepeck(a)gmail.com> > Subject: Re: [development] Suggestion for User Permissions > To: development(a)drupal.org > Message-ID: > <a151b5a00711290945y37f9f5acsc3ff989a4104365d(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > When creating a site admin role, there are several items I do not turn > on for the users, nor do I want them on for those sites. > > Creating roles is generally a one time deal per role. It is something > that 'even it is a 'pain' or 'inconvenient' should not be 'globally > allowed turn on'. This comes to a security issue in that you should > determine your permission model. It is not an 'OMFG usability issue'. > It is a security issue. I have always liked the default 'everything > is off' model because I then have to turn on things. > > It may be inconvenient but it doesn't seem to be something to go into > hysterics over or claim usability as an overarching trump card. > > If we are going to do this, then allowing it only once per role 'at > time of creation' seems the least harmful approach to easily allowing > people to shoot themselves in the foot to solve some users > 'inconvenience'. > > Steven Peck :: www.blkmtn.org > > On Nov 29, 2007 5:14 AM, Earnie Boyd <earnie(a)users.sourceforge.net> wrote: > > Quoting Darren Oh <darrenoh(a)sidepotsinternational.com>: > > > > > Giving a permission to the authenticated user and the anonymous users > > > gives it to all roles. If you are speaking of giving a single role > > > all permissions, I would be careful. It would be better for modules > > > to set defaults for their permissions and then change each permission > > > individually. > > > > > > > IMO, the set/unset all function should be applied to created roles at > > the time of creation only. This solves the issues being discussed.

4 3

Re: [development] Do not let postgresql hold back great patches
by Larry Garfield 29 Nov '07

29 Nov '07

On Thu, 29 Nov 2007 09:28:28 -0500, Bill Moran <wmoran(a)potentialtech.com> wrote: > *) The argument has been made that PostgreSQL compatibility is holding > Drupal back, then 1 (One!) patch is referred to again and again. > How important is this one patch? If this _1_ patch is holding > Drupal back, please commit it! I think these issues were also stalled on cross-database compatibility issues: http://drupal.org/node/174025 http://drupal.org/node/83738 > *) The argument was made that PostgreSQL is too complicated to install > and test on, yet I described the setup in a single email. If anyone > found my instructions too difficult to follow, _please_ let me know > and I will go to efforts to clarify. Please make a handbook page out of them, and put it near (probably as a child of) the "setting up a dev environment" handbook page. We should probably have one for MySQL and one for Postgres (and if we add SQLite at a later date, one for that, too). Email is far too ephemeral to be a good reference. Thanks! --Larry Garfield

3 2

Suggestion for User Permissions
by Alessandro Feijó 29 Nov '07

29 Nov '07

the page Users Permissions can be *verry* long. Borring click so much checkboxes I suggest add a nice Global Checkbox in each role header, and using jQuery should be that simple: $(function() { $('#check_all_role1').Click(function() { $('.check_role1').val(this.value); } } How can I help with that, to add in Drupal 6 final release? Its time yet? What PHP file, in core, should I change it? any hook? Sorry for so much noob questions, this is probably documented in Drupal.org, but I didnt find. regards Feijó

11 15