- Development - lists.drupal.org

Unsetting array elements?
by Nick Wilson 21 Sep '06

21 Sep '06

Hi everyone, Im having a spot of bother working out how to unset an array contained in a session. This: unset($GLOBALS[HTTP_SESSION_VARS][partners_upload][$adId]); does NOT work, neither does using $_SESSION instead of HTTP_SESSION_VARS -- when i query the sessions table, the 'partners_upload' array still contains the $adId element (which itself is an array). Can anyone suggest where i might be going wrong here? many thanks.. -- Nick Wilson http://performancing.com/user/1

2 2

RE: [development] Question on hook_menu in cvs.
by Metzler, David 20 Sep '06

20 Sep '06

Got it, thanks. I mistakenly assumed that sections in the "maycache" section would be cached for the session. Turned out my own logic around forcing the menu to display in admin/build/menu section had me fooled into believing these were cached beyond a page load. Dave -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Gerhard Killesreiter Sent: Wednesday, September 20, 2006 12:23 PM To: development(a)drupal.org Subject: Re: [development] Question on hook_menu in cvs. Metzler, David wrote: > So that means that you simply cannot create or reposition, or make > optional any menus that have logic in them? (which therefore cannot be > cached?) The conclusion is invalid. :p > What I'm ultimately reaching for is to be able to have a menu item > only appear if the user is not logged in, and give the site > administrator the ability to attach this menu to primary links, etc. > > Am I thinking about this problem wrong? Is there another way to > achieve the same functionality? Yes, there is: Look at the "user" path and how it is handled. Cheers, Gerhard

1 0

RE: [development] Question on hook_menu in cvs.
by Metzler, David 20 Sep '06

20 Sep '06

So that means that you simply cannot create or reposition, or make optional any menus that have logic in them? (which therefore cannot be cached?) What I'm ultimately reaching for is to be able to have a menu item only appear if the user is not logged in, and give the site administrator the ability to attach this menu to primary links, etc. Am I thinking about this problem wrong? Is there another way to achieve the same functionality? -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Gerhard Killesreiter Sent: Wednesday, September 20, 2006 10:14 AM To: development(a)drupal.org Subject: Re: [development] Question on hook_menu in cvs. Metzler, David wrote: > In the process of updating my cas module. Having trouble implementing > a non-cachable "suggested" menu item. > > I've been working with this code and I can't get the non-cached > entries to show up in administer menus? Anyone know if this is by design? Yep, by design. Cheers, Gerhard

2 1

Making a whole site location aware - a design question
by drupal＠mclewin.com 20 Sep '06

20 Sep '06

I have a question for the masters. If you are an impatient master, jump over the context and to the second to last sentence for the question. A friend and I are well into building up a Drupal 4.7 based site where the user's location is taken into account in nearly every display. The site, www.folkjam.org (or folkjam.org for some), is most simply a database of acoustic music jam sessions (Irish sessions, bluegrass, folk, fiddle, stuff like that). When a user visits the site, we determine their lat/lon from an IP to lat/lon database (a custom module we've added), or from user selection based on US zip code or finally from the zip code that the location module injects into the user's login record when a user registers and configures it. By the time we are done, every display in the site will show only nodes that a) have no locative data on them or b) Have locative data that is within a 90 mile radius of the user's configured location. We've come pretty far, but there is one key place where we need some direction. We intend to contribute much of our work back to Drupal (which is why I'm asking for help - I want the changes to be palatable). There are seven pieces of information that we need to store in a way that other modules can leverage them. Three are critical to a location-aware Drupal site. Four are important for display. They are: The site visitor's Latitude, Longitude, Radius (stored in miles), Country code, Postal code, Province, City. The Lat/Lon/Radius are the critical three. We are presently keeping these in session variables wrapped in accessor functions. The accessor functions are namespaced as part of the site specific glue module that brings most of our customizations together, and the session variables are too. Neither are appropriate for direct calls from contributed modules such as the event.module. In making event.module capable of only showing event-enabled nodes that are within $search_radius of a lat/lon, we started by adding GET style parameters and passing lat/lon/radius into the event.module. Because these three pieces of information needed to go all the way down the event module's call stack to the data retrieval routine, most functions had their signatures extended. Completing this work will require touching the entire event module theme as well, since the 'next month', etc navigation links all need the lat= lon= radius= parameters on the URL. We are not happy with this solution as something to contribute back. What we would rather do is store the seven location awareness information tidbits in a 'well recognized location' where other modules can know to use them. Then we want to add a setting to event.module that can be enabled to restrict events to within a search radius of the visitor's 'current location', and then modify the core data logic and display building logic in event.module to constrain the events it retrieves based on the lat/lon/radius in the 'well recognized location' when the location module is installed AND for nodes that have locative data AND when the active user has a lat/lon/radius configured. In reading the notes from the DrupalCon on Vancouver it seems that location awareness was a topic - I hope there is already some thought about this that I just didn't read. While I suspect that the $user object is probably the place to keep this, I am uncertain of how much we can rely on the $user object when the user is not logged in - we want to be able to customize displays even when users don't register with us or log in. Before fixing that little pocket of ignorance and becoming expert on the nuances of $user, I thought I'd seek advice. Hopefully that is enough context for you. Here's the question: What is an appropriate "well recognized location" within Drupal to keep these seven pieces of information? (latitide, longitude, search radius (storage in miles), country code, province, postal code and city. I'm looking forward to having an answer (or seven :) ) so that we can get closer to having patches in the patch queue. Scott

6 11

Question on hook_menu in cvs.
by Metzler, David 20 Sep '06

20 Sep '06

In the process of updating my cas module. Having trouble implementing a non-cachable "suggested" menu item. I've been working with this code and I can't get the non-cached entries to show up in administer menus? Anyone know if this is by design? Am I taking the wrong approach here? Consider the following code snippet: function cas_menu($may_cache) { global $user; $items = array(); if ($may_cache) { $items[] = array( 'path' => 'admin/settings/cas', 'title' => t('cas settings'), 'description' => 'Configure central authentication services', 'callback' => 'drupal_get_form', 'callback arguments' => 'cas_admin_settings', 'access' => user_access('administer cas'), 'type' => MENU_NORMAL_ITEM, ); } else { if ((!$user->uid) || ((arg(0)=='admin') && (arg(1) == 'build') && arg(2) == 'menu')) { drupal_set_message('loading menu array'); $items[] = array( 'path' => 'cas/login', 'title' => t('CAS Login'), 'callback' => 'cas_page', 'access' => TRUE, 'type' => MENU_SUGGESTED_ITEM, ); } } return $items; }

2 1

Re: [development] code names for core releases?
by Khalid B 20 Sep '06

20 Sep '06

On 9/19/06, Richard Archer <drupal.org(a)juggernaut.com.au> wrote: > At 7:59 PM -0400 19/9/06, Trae McCombs wrote: > > >Richard, please just go with a +1 or -1 for the idea. > > My -1 for names has already been posted. Fair enough. > If we must use a name, HEAD is just fine. Richard, can I reiterate the arguments already made against this? Regarding HEAD/Trunk/cvs. HEAD is transient. Today's HEAD and not tomorrow's HEAD. If an issue or a documentation page refers to HEAD, what release exactly does this correspond to? Look at an issue from a year or two ago that refers to HEAD. Which release did the fix or the problem or the documented feature is in? Hard to say, and to find out you have to do extensive research. It would be easier to say 5.0, since it is the next release. But that is not known until all the desired features go in, then a decision is made on whether this is a major or minor release. Who knows, maybe FormAPI 7.0 and thingamajigg will make it in the next release and it is not 5.1 anymore, rather 6.0 ... So, from the time 5.0 is branched till we decide on what the next number will be a code name (bikeshed, peaceNbananas, whatever) refers to "the next release" after 5.0. Once it gets a number we can refer to either the number or the name since they are synonymous. Why is this concept so hard to grasp?

6 6

RE: [development] code names for core releases?
by Steven Peck 20 Sep '06

20 Sep '06

In the past Dries has said not interested. This discussion comes up every freeze, see archives. See first sentence. This may have changed. Additional comments below. > -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Khalid B > Sent: Tuesday, September 19, 2006 7:45 PM > To: development(a)drupal.org > Subject: Re: [development] code names for core releases? > > Let me try to rehash the process, using the next release as an > example. > > Let us say Dries branches 5.0 a few weeks from now. The makes > HEAD (technically trunk) open to development again. > > At that point, there is no need for 5.0 to have a code name, since > it has a version number that will not change. > > The next release is expected to be, most probably 5.1. But it > can be 6.0 as well depending on how much new features make > it in before the code freeze. From 2 weeks from now until the > code freeze (6 months or more), the "next release" has no > definite name. 60 message thread fighting over nameing syntax of weird name generation. Time could have ben spent on coding or QA testing. > For that period of 6 months, the code name will be used to > reference that release. Any references in documentation, issues, > mailing lists, ...etc. will not reference a name (bikeshed) that > will never again be used in the future for any other release. Assumes 6 month release cycle. Someone will say this was an example date. Someone else will say 'so we're going with 6 month release'... 14 message thread discussing it again. > There would be a page on drupal.org listing release names > and the corresponding version numbers. Who would do this? Our Drupal version release numbers weren't explained until I wrote the page and other then some folks updating development pages I see very few people adding these little gems into the handbook.... ALMOST NO ONE updating handbook pages. So not really interested in mythical documentation load being added to some mythical person who doesn't exist. Not to mention big discussion complaining about how the current version isn't well explained but no one bothered to actually do anything about that anyway. > If some documentation still references bikeshed, and someone is > reading that in a year or more, it is easy to know that bikeshed > became 5.1. On the contrary, being referenced as HEAD or > CVS or "the next release" is a name that gets reused every > release. See above rant about mythical non existant person getting additional workload that doesn't have enough people as it is actually doing anything. > then the next release gets another unique code name (say peace > and banana for amusement value [note, I am not advocating this, > just a humorous example]), ...etc. 50 message thread discussing name of release and arguing over rules for nameing. Not counting this thread. > Note that the same is true even for Windows (e.g. Longhorn became > Vista, Chicago became Windows 95, ...etc.). Microsoft abandoned > release numbers after Windows 3.1 and chose year numbers, then > cutesy marketing names. Apple and Intel use code names as well, > although for different reasons. Examples here: Marketing is not something we have done well off of Drupal.org. Frankly I don't see it as something we need to do anyway. It's better left to companies selling services... Their services. When and if our marketing team actually produces actual marketing material you can discuss how changing names would help market Drupal. In the mean time, no marketing documentation has in fact been produced except by people doing it on an ad hoc basis because no one else did and someone had to try something to which others merely pointed fingers and complained. Charlie has had ONE response to his post on th edoc list. So, see lack of resources in my above discussion. > http://en.wikipedia.org/wiki/Project_code_name > > I hope it is now clear why code names have value and when they > will be used in the development cycle the most. I hope it is clear why code names means investing in people/volunteer resources we don't have because people who already promised they would do stuff already don't do it. Oh. -1 on code names. -sp

1 0

Re: [development] code names for core releases?
by Khalid B 20 Sep '06

20 Sep '06

Let me try to rehash the process, using the next release as an example. Let us say Dries branches 5.0 a few weeks from now. The makes HEAD (technically trunk) open to development again. At that point, there is no need for 5.0 to have a code name, since it has a version number that will not change. The next release is expected to be, most probably 5.1. But it can be 6.0 as well depending on how much new features make it in before the code freeze. From 2 weeks from now until the code freeze (6 months or more), the "next release" has no definite name. For that period of 6 months, the code name will be used to reference that release. Any references in documentation, issues, mailing lists, ...etc. will not reference a name (bikeshed) that will never again be used in the future for any other release. There would be a page on drupal.org listing release names and the corresponding version numbers. If some documentation still references bikeshed, and someone is reading that in a year or more, it is easy to know that bikeshed became 5.1. On the contrary, being referenced as HEAD or CVS or "the next release" is a name that gets reused every release. then the next release gets another unique code name (say peace and banana for amusement value [note, I am not advocating this, just a humorous example]), ...etc. Note that the same is true even for Windows (e.g. Longhorn became Vista, Chicago became Windows 95, ...etc.). Microsoft abandoned release numbers after Windows 3.1 and chose year numbers, then cutesy marketing names. Apple and Intel use code names as well, although for different reasons. Examples here: http://en.wikipedia.org/wiki/Project_code_name I hope it is now clear why code names have value and when they will be used in the development cycle the most.

1 0

Re: [development] code names for core releases?
by Trae McCombs 20 Sep '06

20 Sep '06

"Ya'll hear that, we're usin' code names!" - Raising Arizona Richard, please just go with a +1 or -1 for the idea. While "silly" isn't exactly a bad form of expression if everyone used their personal opinion it could get ugly. For the record, I'm +1 on code names. :) Peace, love and bananas. Trae On 9/19/06, Richard Archer <drupal.org(a)juggernaut.com.au> wrote: > > At 10:49 PM +0200 19/9/06, Derek Wright wrote: > > >i get the sense i'm in the minority thinking that this late binding > >is a) unnecessary and b) costly. however, if i can't win that > >battle, i'll wholeheartedly support using code names instead of the > >terrible options we currently use ("cvs", "HEAD", etc). > > Well, I'm right there with you. > > Names for code are just plain silly. > > ...R. > -- Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com

4 3

Re: [development] code names for core releases?
by Khalid B 19 Sep '06

19 Sep '06

On 9/19/06, Richard Archer <drupal.org(a)juggernaut.com.au> wrote: > At 10:07 AM +0200 19/9/06, Derek Wright wrote: > > >the indirection is sort of a pain in > >the ass, and can also lead to confusion > > Just in case adoption of release names is a real possibility: > > +1 to numbers > -1 to names > > It would be a horrible regression to use names instead of > release numbers. Sure they're cute and quirky, but we're > developing software here, not trying to entertain users. Richard. The problem is that numbers once chosen cannot change. If you say the next release is 4.8 and change your mind because a lot more features made it since then, then you will impact a lot of places for that (documentation, issues, ...etc.) The purpose of the name is not to be cute or quirky, but rather totally meaningless and does not imply anything. Just a unique label from a large namespace. If anything, I am against any entertainment value in code names.

1 0