August 2007 - Development - lists.drupal.org

coding standard question
by Steve Rude 28 Aug '07

28 Aug '07

So I was trying to research a coding standard that I don't see documented anywhere. What is the standard about NULL, TRUE and FALSE. According to the coder module it says to use lowercase because it is faster, but throughout core there is uppercase. e.g. in the system.module (not to mention the trailing comma is missing...) /** * Implementation of hook_menu(). */ function system_menu($may_cache) { $items = array(); if ($may_cache) { $items[] = array('path' => 'system/files', 'title' => t('File download'), 'callback' => 'file_download', 'access' => TRUE, 'type' => MENU_CALLBACK); I know this is a very minor point, but we are trying to match our internal coding standards with that of Drupal. Thanks! Steve Rude

12 21

Re: [development] coding standard question
by AjK 28 Aug '07

28 Aug '07

> I have spent quite a bit of time on things that many people have felt > are "worthless" (Memcache, APC Cache, core cache serialization patch) > and have had a good performance impact. It is my area of interest. I > apologize if it offends anyone for posting to this list about it. Is > there a better place to post about this stuff? Hi Steve, I didn't mean to offend, sorry if it came over like that. My point is, like yourself, I'm a performance junkie and when a see something that looks like I'll get a "hit" I investigate. As part of this (and for other reasons), I often spend time in both PHP and MySQL internals. A quick review of the code often tells me if something is worth following up on. In this case I can't see it. There are other places to look also (Jeff Eaton just posted a good email) but this wouldn't personally be high on my list. But keep up the good work, as a friend of mine once said, "once those cycles have passed you by you just can't get them back again" ;) regards --Andy (AjK)

1 0

Menu update -- the older your database is, the better
by Karoly Negyesi 28 Aug '07

28 Aug '07

Hi, http://drupal.org/node/147657 is now RTBC and I really countercheck every presumption about the menu table and have erected various safeguards against weird, weird menu tables -- please test! If you have a database which you upgrade since 4.5 for example... that'd be valuable. Thanks, NK

1 0

this guy deserves attention
by Karoly Negyesi 27 Aug '07

27 Aug '07

Jiří Bernášek aka JirkaRybka http://drupal.org/user/106464 recently began submitting core patches after about half a year of contributing to various contribs and helping out in the forums. First he started helping fixing the Drupal 5->6 update path (updates are not easy -- I never saw anyone starting core work with fixing update) and then went on to enhance Drupal by moving the access_check from update.php to settings.php Keep up the good work !

1 0

Re: [development] Deleting Cached Permissions
by sysop＠scbbs.com 26 Aug '07

26 Aug '07

> Date: Sat, 25 Aug 2007 10:12:51 -0700 > From: David Metzler: > > The earliest hook avialable to you is hook_init. I use it > successfully to require auth for specific pages in my cas module. Be > careful not to rely on the arg() function. It is not always > defined when caching is enabled. > > Dave Thanks! Putting both the cache_clear_all() and user_access('', NULL, TRUE) statements in hook_init() totally works! Submitted patch for Drupal core here: http://drupal.org/node/170524 -ron

1 0

Re: [development] Deleting Cached Permissions
by sysop＠scbbs.com 25 Aug '07

25 Aug '07

OK, I've modified the user_access() function to utilize the $reset functionality as described here: http://www.lullabot.com/articles/a_beginners_guide_to_caching_data I use something like user_access('reset', NULL, TRUE) to reset the $perm value in the user_access() function. However, to make this work, I need to be able to call this function before other modules call user_access(). So, my question now is: in what hook should I put my user_access() reset call in order to make it is always called first before or when loading a node? Thanks! -ron Quoting Moshe Weitzman <weitzman(a)tejasa.com>: > it is fine to avoid it with some workaround, ideally you will also > submit a patch so next time someone else doesn't have to work around > this. > > On 8/24/07, sysop(a)scbbs.com <sysop(a)scbbs.com> wrote: >> Yes, that would be perfect. The problem is that this functionality is >> currently not in user_access(). >> >> I looked at the php docs and see that this is possible, but the only >> way to implement it in user_access() would be to modify the >> user.module -- which I'm trying to avoid. >> >> Quoting Moshe Weitzman <weitzman(a)tejasa.com>: >> >> > it is reasonable to add a param to user_access() called $reset which >> > if true, kills $perm at beginning of function. this is how other >> > static caches get rebuilt on demand in drupal. >> > >> > On 8/23/07, Ron Parker <sysop(a)scbbs.com> wrote: >> >> I wrote this list before on this issue: http://drupal.org/node/166557; >> >> but, received no response. Decided to re-pose the question. >> >> >> >> The problem is that I'm getting the "access denied" error on file upload >> >> even though the file is uploaded. This is because user_access('upload >> >> files') is failing for a user who, in fact, has this permission in this >> >> particular group. >> >> >> >> I did the following: >> >> >> >> 1. Modified user_access() function to NOT cache the $perm permissions. >> >> 2. Deleted records from cache_menu. >> >> >> >> I don't know which (if not both) of the above did the trick, but it >> >> resolved the issue. That means (I think) it's a cache problem. >> >> >> >> I know I can use cache_clear_all() to delete items from cache_menu. >> >> However, I would like know if it's possible to delete/modify the static >> >> $perm variable that is set in the user_access() function OUTSIDE of that >> >> function? >> >> >> >> That is: The user_access() function sets a static variable $perm = >> >> array(). Permissions are cached in this variable. Can I create a >> >> function in my module that can update the $perm variable that is set in >> >> the user_access() function of the node.module? >> >> >> >> Thanks for any assistance. >> >> >> >> -ron >> >> >> >> -- >> >> Ron Parker >> >> Software Creations http://www.scbbs.com >> >> Self-Administration Web Site http://saw.scbbs.com >> >> SDSS Subscription Mgmt Service http://sdss.scbbs.com >> >> Central Ave Dance Ensemble http://www.centralavedance.com >> >> R & B Salsa http://www.randbsalsa.com >> >> >> >> >> > >> >> >> >> >

2 1

Re: [development] jQuery 1.1.4
by Matt Farina 24 Aug '07

24 Aug '07

2 1

comment module: minor issue unreachable code
by Hans Wolters 24 Aug '07

24 Aug '07

Hi there, In the comment module there is some code that will never be reached: function comment_nodeapi(&$node, $op, $arg = 0) { switch ($op) { case 'load': return db_fetch_array(db_query("SELECT...... break; The return will make it impossible to reach the break. Regards, Hans

8 12

SoC 2007: Public/Private Files Call for Testers
by Kyle Cunningham 23 Aug '07

23 Aug '07

Hi All, For the Summer of Code I've been working on a patch to core to implement per file public and private files. This patch is in the issue queue at http://drupal.org/node/166759 and it needs your help! People that are willing to test functionality, check for style problems, and help with features are all welcome. This patch has quite a few changes and I can't test it all myself. So if anyone interested can look over the patch, do testing, or anything else please post to the list, email me, or talk to me on #drupal (_CitizenKane_). Cheers, Kyle Cunningham P.S. A document listing out testing steps in all the detail can be found at http://www.codeincarnate.com/testing.txt

1 0

Re: [development] Custom FAPI elements in 6.x
by Karen Stevenson 23 Aug '07

23 Aug '07

<snip> Also, we should examine the four after_build calls that remain. I suspect they can be replaced by other constructs now and if so, we should mention in the doc that this is deprecated. Finally we should make it clear when to use _value and when #process. The question is, can we do everything we do in _value with #process ? I think the answer is yes however it still looks like a healthy split -- if you just want to assign #value then use _value , if you want to split your element after #value is in place, use #process. </snip> Yes, it is confusing to know when to use _value and when to use #process, and yes you can do everything you can do with _value in #process and much more, so it might be useful to figure out when to use which. Actually I had the same question and eaton and I went back and forth in IRC on the reasons, and he finally said he figured _value and #value_callback were screwdrivers while #process is a jackhammer, and that is a pretty good analogy. The advantage of _value is its simplicity if all you want to do is set the value. You don't need to know anything about how the form or form_state are configured, you just test if there is a submitted value to know whether you are working with a posted value or not and return whatever you want the value to be. #process is more powerful and more complicated -- you get the whole $form_state and you need to know how to extract out of it the information you want. If you want to alter the element itself or do anything other than set the value, you must use #process, _value won't work for that. Maybe I should add something like that to the tutorial? On the 'four after_build calls that remain', which four are you talking about. Do you mean #after_build, #pre_render, and #post_render? I can't think of a fourth. And yes, if we want to deprecate anything, it would be good to mention it here. Karen

3 2