- Development - lists.drupal.org

phpgacl
by Roman Chyla 08 May '08

08 May '08

Hi all, I am looking into the phpgacl and after searching mailing lists, and drupal.org (via google, the search form seems not to be there) But found very little. eg: http://lists.drupal.org/archives/development/2004-03/msg00566.html Is there any reason why I should not think of phpgacl and Drupal together? (I am wondering why nobody has considered phpgacl for Drupal) Could you recommend me some group management modules in Drupal? Or any hints, anything that relates to permission control & gacl? I am thinking about including phpgacl into Drupal. Thank you very much, roman

4 5

RFC: drupal as a moving target
by Caleb Gilbert 08 May '08

08 May '08

> > You are. The community may benefit from Acquia's 'public' > support/choice of contributed modules it in no way, shape or form > establishes a 'gold' repository at drupal.org. Many companies have a > suite of modules they commonly use and track, just don't make public > that list. > Firstly - barring official announcements which I haven't seen, Dries nor Aqcuia have publicly stated that they *would* not help try to inject some sanity into upgrade/development cycles (e.g., making sure that certain contrib module's don't get left too far behind) Also, I never mentioned a 'gold' repository. My original intention was simply to sign on too the idea that catch suggested which I understood it was - 'why release a Drupal version that no one is going to use for any large/critical sites for six months (or possibly ever)'. In addition to myself, I know at least one other (large) shop that has more or less committed to skip Drupal 6. This is what's happening and no one wants to deal with it and just poo-poos such talk as being irrelevant. But it is happening, and it's up to everyone to form their own opinion of any relevancy. (personally I'm fine with the idea that some releases end up this way IF was more publicly acknowledge instead of hushed up, which is what I feel like is happening now to some extent) The real point of all this, which makes this discussion not just a pedantic exercise, is that I truly feel sorry for anyone starting up a big project right now who is just getting into Drupal and trying to make sense of what version to use. I've seen people giving others what I consider to be very bad advice and representing a state of stability/readiness for Drupal 6 which, in my considered *opinion*, is just not there. Regards, Caleb

13 21

where to now with the registry?
by justin randell 08 May '08

08 May '08

hi all, now that the registry has landed, i'd like to call for feedback about where to from here. there are two interrelated questions in my mind: 1. can we improve on the caching we put in front of the registry data? at the moment we cache files that should be included per menu path[1] and module hook implementations[2]. what else could be cached? litwol raised the idea on #drupal of caching theme calls. other ideas? 2. how could/should we change drupal to take advantage of the registry data? what can we do to make bootstrap lighter to make drupal faster? can we use the registry to simplify even further drupal's module code? to give a crude example of 'making bootstrap lighter', its now possible to remove module_load_all from _drupal_bootstrap_full, and make drupal run with a sprinkling of extra drupal_function_exists calls[3]. but this is crude, and there are bound to be better ways. what else? cheers justin [1] http://api.drupal.org/api/function/registry_cache_path_files/7 [2] http://api.drupal.org/api/function/registry_cache_hook_implementations/7 [3] http://api.drupal.org/api/function/drupal_function_exists/7

1 0

Drupal will be 20% faster under PHP 5.3
by Henrique Recidive 07 May '08

07 May '08

http://news.php.net/php.internals/36484 Also, since PHP 5.3 has namespaces feature, I wonder if this could help us improve registry, it will be possible to autoload namespaced functions. Henrique

5 4

drupal_goto an external destination
by Dave Cohen 06 May '08

06 May '08

I need to send the user to an external URL after a form submit. My approach is to set $form['destination'] via hook_form_alter. When the form is submitted, drupal_goto is called. In drupal_goto, my destination gets badly munged and the user is sent to the wrong URL. In my case, I'm trying to send the user to http://apps.facebook.com/my_application/my_path. But the user gets sent instead to http://my_domain.com/drupal/%252Fmy_application/my_path. The reason for this is at the start of drupal_goto. It looks like this: if (isset($_REQUEST['destination'])) { extract(parse_url(urldecode($_REQUEST['destination']))); } else if (isset($_REQUEST['edit']['destination'])) { extract(parse_url(urldecode($_REQUEST['edit']['destination']))); } $url = url($path, $query, $fragment, TRUE); The use of extract() makes the code nearly impossible to understand, unless you find perl intuitive, but I digress... During extract() $path, $query, and $fragment all get set. So does $scheme, $host, $user and $pass. But drupal_goto does nothing with the latter variables, and in my case important parts of the URL are dropped. Is there even a reason why parse_url is used here? Why not something closer to: if (isset($_REQUEST['destination'])) $url = url($_REQUEST['destination']) else ... And is there a workaround for me without patching core? Thanks, -Dave

3 4

Re: [development] User Status [WAS: User last access]
by David Timothy Strauss 06 May '08

06 May '08

----- "Ivan Sergio Borgonovo" <mail(a)webthatworks.it> wrote: > Hopefully MySQL is going to fix this kind of quirks and come up with > a decent boolean implementation and you may end up in a not so > efficient, hardly portable mess. There's no industry-standard way to handle booleans, so I'm not sure what you mean by "fix this kind of quirks" when any efficient boolean implementation would be defined by you as a quirk. > > "Make the common case fast." > > <http://en.wikipedia.org/wiki/Amdahl%27s_law> > > It can't be read as you're advertising it. > You can't optimize the most used DB and make the overall application > run faster on all DB. Any optimization we make for MySQL has a huge impact on the base of Drupal installations. Any optimization we make for other DBs has a negligible impact. Therefore, it behooves us to spend our time concerned with optimizing for MySQL and merely verifying the correctness of implementations in other databases. Amdahl's law applies because it establishes the relationship between an optimization and the overall impact on performance. If over 98% of Drupal installations use MySQL and 100% of Drupal installations use the user table, then an optimization to how we manage the user table in MySQL has a huge impact on overall performance. If under 2% of Drupal installations run PostgreSQL, then an optimization for PostgreSQL has minimal impact. > What about: > "We should forget about small efficiencies, say about 97% of the > time: premature optimization is the root of all evil." D. Knuth This is exactly why I support TINYINT(1) UNSIGNED NOT NULL or CHAR(0) on MySQL. CHAR(0) is portable as CHAR(1) on every database except Oracle. TINYINT(1) UNSIGNED NOT NULL is portable as larger unsigned integer formats on other DBs. You're misunderstanding Knuth if you think we should care about storage space or performance on non-MySQL databases. Optimizing for MySQL is not premature optimization.

5 4

Registry
by Dries Buytaert 05 May '08

05 May '08

Hello all, the registry patch is considered to be ready: http://drupal.org/node/221964. Given that this is an important patch, I'd like to give you a last opportunity to review it carefully -- both the clarity of the PHPdocs as the code itself. Thanks for your help, -- Dries Buytaert :: http://buytaert.net/

1 0

Free to a good home
by Larry Garfield 05 May '08

05 May '08

Upload path: http://drupal.org/project/uploadpath I wrote this for Drupal 5 originally for a client, and the client then decided to not use it. I've not really ever used it myself, and don't have the bandwidth to manage it. I'd like to stay on the CVS list for old time's sake, but otherwise it's up for adoption. (There's a Drupal 6 port sitting in the issue queue, and some other odds and ends.) Holy Grail theme http://drupal.org/project/holygrail I wrote this as a proof of concept way back, and it didn't prove the concept. :-) It's a somewhat broken port of Bluemarine for 4.7 to the A List Apart "holy grail" fluid layout model. I haven't touched it in over a year. I will likely never touch it again. If anyone wants it, it's all yours. Please contact me off list if interested. --Larry Garfield

1 0

Re: [development] User Status [WAS: User last access]
by David Timothy Strauss 04 May '08

04 May '08

I couldn't care less about the SQL92 standard (or any other SQL standard). What I care about is: * What we do is space efficient on MySQL * What we do is fast on MySQL * What we do works on other databases SQL92 doesn't answer any of those questions for me. Consequently, I have a few goals if we implement status bits for user accounts: * Not having one byte per bit * Not having O(n) searches for common bit-status user queries, if we have such queries * Ability to run on other databases, without significant regard to performance or space efficiency "Make the common case fast." <http://en.wikipedia.org/wiki/Amdahl%27s_law> ----- "Ivan Sergio Borgonovo" <mail(a)webthatworks.it> wrote: > On Sat, 3 May 2008 19:12:46 +0000 > "David Strauss" <david(a)fourkitchens.com> wrote: > > > But they probably support another bit-based format. > > The smallest thing you can find in SQL92 I think is boolean. > As said most DB support bit packing and some have aggregate functions > over boolean fields. > > char doesn't look as a good choice because on UTF8 may have some > overhead, it is ordered according to locale and in need it misses > interesting aggregate functions. > I don't know SQL standards and enough implementations to know if you > can avoid both problems in most DB. > Some DB let you define collation and encoding on a field base... some > don't even let you define the encoding/collation on a table base. > > The smallest SQL92 int is 2 bytes (smallint) someone may think it is > too large but it is very well handled by modern CPU and is not > affected by locale nor encoding... if you've more statuses... > > -- > Ivan Sergio Borgonovo > http://www.webthatworks.it

3 3

Re: [development] User Status [WAS: User last access]
by David Timothy Strauss 04 May '08

04 May '08

A bitmask isn't a column type; it's an operation to perform on a column to extract a bit. Bitmasking is handled by functions, and MySQL can't index the results of functions. That's why I say MySQL can't index bitmasks. You can put an index on the bitfield/int column, but it's useless for the majority of lookups.* *The index could function for conjunctive (AND) conditions beginning with the leftmost bit and not skipping any bits, but the query would have to be carefully constructed. ----- "Earnie Boyd" <earnie(a)users.sourceforge.net> wrote: > > -----Original Message----- > > From: Earnie Boyd <earnie(a)users.sourceforge.net> > > > > Date: Sat, 03 May 2008 09:59:43 > > To:development@drupal.org > > Subject: Re: [development] User Status [WAS: User last access] > > > > > > Quoting Larry Garfield <larry(a)garfieldtech.com>: > > > >> > >> A) Make status have a lot of different states with int/consts. > >> B) Make status a bitmask field (compact but harder to query). > >> C) Break status out into a series of is_foo fields (possibly a lot > of > >> needless data). > >> > > > > I like option B for this. > > > > Quoting David Strauss <david(a)fourkitchens.com>: > > > Remember that MySQL cannot truly index bitmasks. Consider a series > of > > CHAR(0) columns, which would take the same space but be indexable. > > > > I was thinking more of an integer field used as a bitmask. > > Earnie -- http://for-my-kids.com/ > -- http://give-me-an-offer.com/

1 0