August 2006 - Development - lists.drupal.org

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

Drupal Administration survey II: second draft
by Kieran Lal 15 Sep '06

15 Sep '06

I would like to thank Mark Burdett for reviewing and editing the survey. Please review and edit the survey questions. The survey results will be used in helping to direct user experience improvements for the Drupal software, Drupal.org, and community processes. The survey will be posted in the top left block on Drupal.org and run for 45 days. This draft, http://groups.drupal.org/node/1326, has also been posted in the Usability Group: http://groups.drupal.org/usability If you complete all the questions in this survey and would like to be recognized as a contributor to improving Drupal user experience please indicate your Drupal.org username Drupal.org username_______________ How would you describe yourself as a Drupal administrator? (pick the best one) New user Non-technical user forced to become "accidental technologist" Inexperienced with Drupal but learning fast, based on other website-building experience Experienced administrator, comfortable with configuring site rapidly Module developer who understands what's going on behind the scenes Other_______________ Which types of Drupal websites do you administer (select all that apply) Personal Blog Community site Social Change site Brochure site News site E-Commerce site ...? Other site How many Drupal sites do you administer? (select one) 1 2-5 6-11 12-24 25 or more How frequently do you administer you your Drupal site? (pick the best one) Monthly Once every couple of weeks Several times a week Daily for 30-60 minutes of website management Daily for several hours in site development and deployment Other_______________ How long do you administer your Drupal site in a single sitting approximately? (pick the best one) Thirty minutes to an hour Few hours Half a day All day long Other_______________ How does Drupal help you accomplish your goals as a web site administrator? (select no more than 3) Rapid deployment of features and ability to meet customer requirements Web based content publishing is easy and allows for end user contributions Easy-to-learn website that can be taught to users Allows website developers to leverage previous experience when building new sites Allows for monitoring and logging of the website Module configuration, extensibility with new modules, and clean code make it easy to customize the website as you need it Dynamic and exciting developer community allows for rapid and fun learning Other_______________ Why do you use Drupal? (select no more than 3) Features, extensibility, integration of modules, clean code allow you to customize your site Speed of deployment and re-use of existing functionality Quality community is helpful, has smart people, is very active, and is working on community solutions not just technical capabilities Allows users to create content, categorize content, and add navigation to the site Other_______________ How does Drupal help your users? (select no more than 3) Gives them the features they want quickly Allows users to create web based content such as forum posts, or blogs Drupal community innovates and provides new and improved community-building tools Cost effective, easy to convince non-technical decision makers Other_______________ What are your *most common* Drupal administration tasks? (select no more than 3) Monitor site through reviewing logs, looking at user activity Manage spam through comments, trackbacks, forum, and user registration Configure modules Update modules, install modules, test patches, track fixes for modules Work on themes and edit theme templates to customize module output Learn about Drupal capabilities and features, understand terminology, and plan improvements Manage users accounts, change permissions Respond to user feedback during testing and make changes Create web pages through the creating content types Other_______________ What are your *least common* Drupal tasks? (select no more than 3) Add new features by adding modules or coding new features Manage spam, delete content and comment, and banning users Modify existing content such publishing to the front page, making content sticky, or changing titles Layout content in positions with blocks, views, or designing a content section Change site theme or theme a content section Modify site navigation Other_______________ When you administer your site you find it *easy* to: (1 is *not easy*, 5 is *very easy*) 1-5 Add new features and install modules 1-5 Automate tasks using cron 1-5 Manage user information by editing user account permissions 1-5 Change themes or make changes to layout with theme templates 1-5 Post, edit, and version web pages and other content types 1-5 General settings such as changing titles, or date format When you administer your site you find it *hard* to: (1 is *not hard*, 5 is *very hard*) 1-5 Discover where to configure site settings, or where all the different places where a site needs to be configured are 1-5 Understanding Drupal specific concepts or understand technical language without pictures 1-5 Upgrade modules manually, theme/customize module output, determine module dependencies 1-5 Manage content specifically creating new content types, viewing differences in node versions, importing content, or seeing multiple previews of content on a single page 1-5 Manage large groups or users, nodes, menu items, comments, blocks 1-5 Get overview of new content and activities on site 1-5 Configure user permissions with increasing granularity 1-5 Manage menus such as changing menu block weights for all menus on a page, or ordering menu items within a menu What are some *important* administration tasks that did not fit into the categories above for you? (select no more than 3) Analyzing logs to understand the state of your site Integrating modules, resolving incompatibilities, theming the output Setting up a testing process including creating a test role, soliciting feedback from users, configuring corrections, and working with module development process to get bugs resolved Work on the theme and templates to create structure and distinct looks to sections of the site Hide output from modules such as node links or browsing links Managing menus with the menu editing interface, bulk menu editing, and menu options Manage performance of the site Identify popular content Aggregate content from other sources into a site _______________ Other

5 7

RE: [Drupal feature] Sqlite port
by tachyonxv＠psiforum.co.uk 15 Sep '06

15 Sep '06

I have a test site at http://atlantean.5gigs.com running what should be the latest version of this. I have been busy with non-Drupal stuff and maintaining Drupal installs. It might be an idea to dump all failed queries via trigger_error() into the log for SQL debugging purposes. @I've put some effort into modifying/adopting jenseng's [1] ALTER TABLE support for sqlite. The code is a mess and I still have to check if it can actually run a Drupal database update, but it's a start... [1] http://code.jenseng.com/db/ I've seen that code mentioned before and that’s about the only way to do it, due to the lack of any alter table support. I think the cache gets corrupted under some circumstances, though I am not sure what does that. The majority of the SQL should be working, or at least enough to make it useable. I did do as test run on a local install with apache bench and with a few simultaneous clients Sqlite is noticeably slower than MySQL, though it is still reasonably responsive. If you have any ideas or test code, I might be able to test it locally. I am not intending on taking this into core, unless its works correctly and its performance is decent. TachyonXV

2 2

module with XML RPC
by Augustin (Beginner) 07 Sep '06

07 Sep '06

Hello, I most probably will need to create a new module that needs to handle XML RPCalls. I have no experience with XML RPC, so I'd like to ask a few general questions about Drupal's implementation. If I understand well, the files includes/xmlrpc(s).inc are a fork from the library: http://scripts.incutio.com/xmlrpc/ How come the Drupal XML RPC API doesn't use any of the PHP XML RPC functions defined here: http://php.net/xmlrpc ? Is this a completely different implementation? Why? Is there a historical/technical reason behind this? How does a XML RPC "session" happen? During a page load, we can use php to query the DB, get a reply from the SQL server, process that reply and display the page according to the reply we got. Does the procedure happen remotely with XML RPC? I.e., if I have a drupal XML RPC client module, that needs to contact a remote XML RPC server, do I get a chance to send the call, get the reply and process that reply all within one page load, as if it were a SQL query? If not, how is the exchange of information handled. What modules exist that use XML RPC a lot, that I could study? How would a simple code snippet look like? (make a call to server, get reply, and have a if / else fork according to the reply we got - or display / print_r() the content of the reply). I saw a few handbook pages, and some issues about xml rpc, but I can't find any information for a total noob... Thanks, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

6 6

possible theme?
by Dries Buytaert 03 Sep '06

03 Sep '06

Hello world, is there someone else who likes? http://www.drupalart.org/drupal48/ http://drupal.org/node/81217 Personally, I think it makes for the best candidate so far. It looks like bluemarine's pretty sister, and is what I had in mind. Let's avoid talking about the underlying XHTML/CSS: we'll worry about that in step #2. Instead, let's talk about the aesthetics, the brand and the message this theme communicates. On a scale from 1-5 (1 = "Argh, it hurts my eyes", 3 = "I can live with it", 5 = "Exactly what we need"), what rating would you give this design (not its XHTML/CSS) and why? -- Dries Buytaert :: http://www.buytaert.net/

35 63

module_exist() / module_exists()
by John VanDyk 01 Sep '06

01 Sep '06

From http://drupal.org/node/64279#module-exists : "module_exist() is now module_exists() For consistency with PHP function_exists, file_exists, etc. That's about all there is to say about that. :)" From my local copy of cvs: $ cd /cvs/contributions/modules $ grep -r module_exist\( . | wc -l 630 It would be nice to have a wrapper function in for one release cycle.

2 1

all fields in the create content forms now can be pre-populated from the URL
by Karoly Negyesi 01 Sep '06

01 Sep '06

Hi, I very rarely rave about contrib modules. But this worths mentioning: http://drupal.org/node/55403 got fixed. Congratulations for everyone involved: egfrith and eafarris. Regards NK

34 94

Re: [development] possible theme?
by Ken Rickard 01 Sep '06

01 Sep '06

>Oh, if you do that, make text #000, then you could get away with .node > .submitted boing #666 >Or would you disagree there too Ken? No, I agree. Submitted is the perfect place for grey or light text. It's 'extra' information that I don't need to read. Making it a lighter color reiniforces that. Making it lighter actually gets it out of the way of the 'real content.' - Ken agentrickard

5 5

re: RE: RE: RE: [development] changes to hook_nodeapi
by Peter Wolanin 01 Sep '06

01 Sep '06

Jeff, My criticism was a little too broad, perhaps- I don't think the entire patch should be rolled back but that at the least 3 of the 4 ops, insert, update, delete, should stay where they are in hook_nodeapi. I might also argue for the return of hook_delete. The removal of hook_validate, hook_insert, and hook_update make more sense, becuase a module that implements them would already have to be constructing a node form. However, that still means that calling node_save() in its present form wouldn't work. I agree with your comment that node_save should be refactored as a helper function (regardless). I don't think this patch fundamentally enables programatic submission (correct me if I'm wrong) -that was in other patches. http://drupal.org/node/68418 does make *some* changes to assist programtic submission, but primarily eliminates various hooks from the node module and removes ops from hook_nodeapi. -Peter >Date: Thu, 31 Aug 2006 15:01:39 -0500 >From: "Jeff Eaton" <jeff(a)viapositiva.net> >Subject: RE: RE: RE: [development] changes to hook_nodeapi >To: <development(a)drupal.org> >Message-ID: <003e01c6cd38$4900a700$6700a8c0@JEATON2DEV> ... >Perhaps what we should ask is, 'OTHER than rolling back an important >piece of code recapturing, how can we make the new mechanism as easy for >developers as the old one was?' Not _the same as_ but _as easy as_. >Perhaps a helper function to 'register' your module's CRUD without >altering any form arrays? Perhaps node_save() existing as a wrapper >function for the functionality? > >> Even without this patch, any developer who *wants* to use the >>Forms API and submit hooks can. This patch *forces* us, even >>when it's not appropriate to the data model (as mentioned in >> a previous post). > >No. Previously, developers who wanted to use the Form API hooks for >programmatic submission could not. It didn't work. Period. That was sad, >because the provisions for validation, error handling, and extendibility >that are there in Forms API are all lacking in nodeapi's simple model. > >What is needed, IMO, is a set of simpler wrappers and interfaces for the >'simple' cases that don't cripple the complex ones. Previously, the >simple cases just used a completely different validation/submission >pipeline -- and that was a serious problem. > >We now have a different (albeit less fundamental) problem -- but one >that is solvable. IMO, at least :) > >--Jeff

4 3

Re: [development] module_exist() / module_exists()
by Konstantin Käfer 01 Sep '06

01 Sep '06

Well, the bad thing about wrapper functions is that people won't change them if it is not necessary. If we take the wrapper function out after the next release, we will face the same problem. 2006/8/31, John VanDyk <jvandyk(a)iastate.edu>: > From http://drupal.org/node/64279#module-exists : > > "module_exist() is now module_exists() > For consistency with PHP function_exists, file_exists, etc. That's > about all there is to say about that. :)" > > From my local copy of cvs: > > $ cd /cvs/contributions/modules > $ grep -r module_exist\( . | wc -l > 630 > > It would be nice to have a wrapper function in for one release cycle. >

4 3