webdevgeeks

This Wednesday we opened the registration for Drupalcon Szeged 2008 and some of the early birds are already in! If you sign up before the end of June you will be able to buy your ticket at the extra discounted price of 80 EUR. From July the price will increase to 120 EUR, from August on to 160 EUR and just before and during the conference it will be 200 EUR to attend. We also help you get a hotel room and buy shuttle bus tickets until July 24, so if you'd like to go the easy way, make sure to register by then.

A week ago we published the sponsor packages. We received positive feedback from several companies and we already sold our first platinum package! As you might have noticed we only have 3 gold and 4 platinum packages available this Drupalcon. So if you want to get the exclusive benefits of these packages and get your company's name on one of our BoF or session rooms, contact us as soon as possible. To make the conference a huge success again, we will need your help: if you know a company that could be interested in sponsoring Drupalcon please get in touch!

We also opened session submission last week. If you have a topic that you would like to present this Drupalcon please fill in the form. Our track chairs will then evaluate your proposal and choose the sessions that will become part of the conference tracks. Session submission will be open until the last week of July. You can also submit BoF session proposals for our unconference program. This Drupalcon we are going to have 3 bigger rooms for larger BoFs (and an open space for smaller ones), so make sure to get the word out about your plans and spark interest in them sooner then later.

Drupalcon North America 2009, Drupalcon Europe 2009 as well as Drupalcon [place your idea here] are being planned right now. If you would like to have a Drupalcon in your town please let us know by submitting a formal proposal. If you have questions regarding the submission process feel free to contact the Drupal Association and someone will help you.

DCA08 is unlike any corporate conference you've ever attended - and for good reason. Focusing on "Drupal" - an open source content management system and application framework, DCA08 is a low-cost, highly collaborative "unconference" held in at the University of Lethbridge, in Southern Alberta, Canada.

Gone are the days of sponsored vendor presentations and for-profit registration fees. Our peer taught, volunteer-run sessions will by heavy with "doers", and light on the "talkers".

Join us July 3 & 4 from 8am - 5pm both days (Networking event on July 3rd)

Official Website: http://www.drupalcampalberta.org

REGISTRATION WILL HAPPEN ON THE OFFICIAL SITE (Don't signup here) Thanks!

Registration is now open at http://www.drupalcampalberta.org/event/drupal-camp-alberta-2008

Vancouver

Jacob Redding and Kieran Lal will discuss growth of local groups on http://groups.drupal.org, best practices for organizing your local group, and request feedback on some improvements to GDO which will help local organizers. We will be presenting statistics calculated from http://groups.drupal.org, what we've learned by talking to 8 local group organizers, and request feedback on some improvements to http://groups.drupal.org to help local group organizers.

Free Conference Play Back
Playback Number: (712) 432-1281
Access Code: 450345#

http://acquia.acrobat.com/localgroups/

Free Conference Call
Conference Dial-in Number: (712) 432-1600
Participant Access Code: 450345#
International Dial-in Numbers
Austria: 0820 4000 1552
Belgium: 070 35 9974
France: 0826 100 256
Germany: 01805 00 76 09
Ireland: 0818 270 021
Italy: 848 390 156
Netherlands: 0870 001 920
Spain: 902 886025
Switzerland: 0848 560 179
UK: 0870 35 204 74

Groups.drupal.org

Following our success in organizing the past Drupalcon Barcelona 2007, the Catalan User Group is ready to start organizing local events at the Citilab, where we held the Drupalcon. We have created the Drupal.cat association to help the catalan drupal community grow, and our first action will be the organization of a monthly drupalcamp at the Citilab, on each second Saturday of every month.

Our first drupalcamp in Barcelona, then, will be held at the Citilab on the 14th of June and everyone is wellcome. Leave your session proposals on our session list page.

Drupal Event Organization

Totally disorderly and mostly here for our own reference =)

• Refactor node/user search implementations into own modules.
• Control over the search interface.
• Moving stuff between adv. search form and main search form and/or block.
• Full search building interfaces. Create search environments; Each env. has own settings. eg. What content types are in search? What does the interface look like? Analog to building a view w/ fastsearch.

Brainstorm: if you store a view (from a fastsearch view, for example), and it is capable of returning a list of all of the nids in the view, we could build facet lists from the view. This would have general utility to views.

Note: said brainstorm highlights the need to isolate the indexer as a standalone component.

Federated search: Do similar search on multiple Drupal sites at once. Existing implementation is S. Witten's Search RSS aggregator.
Problems:

• Authentication
• (Node) access
• Result weaving (score/relevance)
• Asynchronous nature (blocking on slow sites?)

do_search: Gets its SQL from;

• arguments to the function
• search_parse_query
• Builds some of its own.

do_search tasks include:

• Documenting it.
• Code comments needs work.
• The variable name needs work.
• Refactoring.

Search query handling (currently search_get_keys, search_query_insert, search_query_extract). uid:2, nid:5

• term_name:"Ronald Reagan"
  (solution to this in ApacheSolr)
• Tracking the query at various parts of request. For example, adv. search form, the string for the query gets passed along in the $form. Ugly. Solution is global singleton. (or static, passed by reference singleton...) ApacheSolr solves this.

Search

This page is a resource for members of the Drupal community. If you would like to promote the Knight Drupal Initiative, you can use the following materials.

For more information about the KDI, see the program goals and the FAQ. To submit a proposal, please review the application tips and the application process.

Program summary

A one sentence summary of the KDI.

* The Knight Drupal Initiative is an ongoing grant program for Drupal and is designed to help people improve their communities by providing a robust, freely distributed, open source digital publishing platform.

Elevator pitch

For use when you have thirty seconds to explain the KDI.

* The Knight Drupal Initiative is an ongoing, open grant funding process for the Drupal open source project. We want to enable more people to enter the digital conversation by lowering the technical barriers to entry. We will provide powerful tools for digital publication, free and open to all. Our goal is to encourage people to improve their communities by supporting the free exchange of information and ideas.

Program flyer

If you are attending a local Drupal user group meeting or a larger conference, you should print and distribute the program flyer. It provides a quick look at the program and its goals.

Download the PDF file

Marketing of Drupal

Find all the information about this Drupal Camp at http://drupalcamp08.drupalindia.in

International Attendees may want to look at http://youtube.com/watch?v=XjeAtS4GGkk to know what Ahmedabad looks like.

Hello All Drupal lovers,

We proudly annouce the venue for Drupal Camp India at DA-IICT, Gandhinagar. Although it took really long for us as far as finalization of the venue is concerned, we finally got DA-IICT venu approved for first ever DrupalCamp in India between 8 to 10 August, DA-IICT is a well-known institute situated at Gandhinagar, the capital city of Gujarat.

DA-IICT is an Internationally recognized Institute having world-class infrastructure and is run by Mr. Anil Ambani led ADAE Group. DA-IICT has a very active Open Source Group/Linux Group and is actively supported by different MNC's for carrying out research based projects.

I hope that the Drupal Community in India and around the world would gear up and contribute to make this
Camp a success!

Best,

Rajat

India

I have just posted a patch which allows people to add a single field into a pane for much greater control over content layout.

See http://drupal.org/node/97375 for the patch to CCK

Panels

groups.drupal.org now features Pages, a major new feature added this week. Group admins now have much more control over the presentation of their group’s content. You may see this feature in action by clicking on the tabs in the redesigned Drupal Dojo group, or Los Angeles or SoC 2008. To learn how this customization was achieved, watch this screencast (blip.tv) by Josh Koenig.

Group admins may add as many custom Pages as they desire to their group. The admin may choose her own page layout, and may place whatever content she wishes into each region of the page. If this sounds like Panels module to you, then pat yourself on the back. This feature is a happy integration between Organic Groups module and the Panels module.

Group admins are encouraged to build out their groups using Pages (see screencast), and report bugs or feature requests in the groups.drupal.org group.

Many thanks to Earl Miles for Panels and Views, and to Josh Koenig for the screencast, and to the Post Carbon Institute for funding og_panels module.

Maintenance

Hi folks,

I'm following up on promises I made during the Birds of a Feather sessions at Drupalcon Boston to post a case study of how we're using Drupal at Amherst College. We've developed a module to facilitate hierarchical content creation and permission control that's also of potential interest to folks outside of the academic community.

Preamble aside - about 3 years ago the college decided to fundamentally change the way it was approaching the web, and a little over 2 years ago we started building on top of Drupal. The project had some broad goals:

• Find a way to gather together all members of the college community under a common web platform. Faculty, Students, Staff and Alumni were our primary focus, though we've since incorporated applicants.
• Change the way the college creates and manages web content. Amherst had been on the Dreamweaver + templates + department directories with shared passwords (!!!) model. We also wanted to get a consistent navigation scheme and thematically similar templates applied to the upper levels of the college's site.
• Begin dynamically building the academic portions of the college's website. Course listings, faculty listings, course enrollment listings, and more needed to all be delivered out of data instead of built manually by various academic staff and faculty.
• Amherst was disturbed by the legal action Blackboard took against Desire2Learn. We also knew that about 90% of faculty use of Blackboard on our campus was for password protected document sharing. We wanted to move away from Blackboard and replace it with other tools.

A partial list of what we've delivered so far: Automation of curricular data:

• every academic department has a dynamically produced list of courses built from Datatel/Registrar data - example, Asian Studies
• every academic department has a dynamically produced list of faculty - example, Spanish faculty listing
• every course has a dynamically produced course website with numerous components including course rosters and e-reserves; this is delivered with granular permissions for reading and authoring content for each of the website components. Example - a recent Economics course. A picture of the permission settings for a course:
  
• every faculty member has a dynamically generated ”CV” page which lists contact info, the courses they're teaching, have taught, and (soon) will be teaching. Faculty can add to this material as they like. Example - Dale Hudson's CV

Every user gets some or all of the following depending on role:

• A customizable and personalized portal that delivers content specific to their role(s) at the college -- examples being readings and assignments for students, news from their classmates for alums, news from the college, etc. A picture:
  
• personal webspace. Example - Susan Edwards' personal website
• professional “CV” webspace if you're an employee, with dynamic content inserted into it (office location, email address, courses taught, etc.). A picture:

• Authoring permissions on the various resources specific to their role(s) -- examples: faculty members can edit their course websites, alums can add news to their class year's news page, department coordinators and staff can edit departmental websites, librarians can add e-reserves to course websites, enrolled students can add content to the class blog, etc. There are literally hundreds of groups. A picture:

• read permissions on the materials specific to their role(s) -- examples: students can see the e-reserves for the courses they're enrolled in, faculty can review the faculty meeting minutes, etc.
• The ability to maintain their personal information – contact info, family history, professional history, personal interests, more (mostly for alums).

Additional features:

• e-commerce tools providing features like reunion registration for alums and gifts to the college
• a voting tool for trustee elections, faculty committee memberships, and more.

How we did it:

• Staff: We have two full time Drupal developers and myself (diplomat/project manager). One of our DBA's spent about half her time on this over the last two years. Our desktop support folks have spent a ton of time on training, representing about 1/2 of one person's time over the last 2 years. Our web designer spent at least half her time on this, and probably closer to 75%.
• Process: We opted for a phased rollout strategy, focusing our attention on one college role at a time before moving on to the next, and we've followed a “release quickly, adjust later according to user request” philosophy. Results of this approach have been mixed. We've managed to do a lot in ~2 years, but nothing is ever “complete” and we've often stumbled over unforeseen problems we would have caught had we pursued a more gradual, thoughtful approach. I'm not sure we would change though if given a do-over, because one of the goals was to quickly modernize the college's approach to the web, and a more deliberate approach conflicts with that goal.

• Code: The main thing we needed that Drupal doesn't have out-of-the-box was sophisticated hierarchical content authoring with permissions control. To deliver this we built our own module, which we've dubbed “monster menus.” A brief overview:

• Content is organized in one or more trees, with each level of the tree acting as a container for one or more Drupal nodes. Nodes can appear in more than one container at the same time, allowing content to be reused without the need to update it in more than one place. The user sees branches of a tree as a menu contained within a block. You can specify the depth of the branch to be displayed in a menu block, and menus can be themed as desired.

• Each level of the tree provides an element in the full URL of a given container.
• A granular permissions system:
• uses a Unix-like system of dependence, where a given user's ability to access one level of the tree depends on his ability at the parent levels; newly-added nodes inherit the permissions of their container, by default
• each container in the tree has separate settings for "who can edit its settings or delete it", "who can add sub-pages", "who can assign Drupal nodes to the container", and "who can read Drupal nodes in the container".
• includes three types of groups: pre-defined (where the member list is generated by a SQL query), ad-hoc (access to a single container), and manually edited (where one or more permitted people control the membership list). The ability to edit this last kind of group is, itself, controlled using the same groups-based permissions model. This allows maintenance of access control lists to be distributed to any number of trusted users.
• because this scheme does not use Drupal's built-in grants tables, it scales well to many thousands of users, groups, and nodes
• Menu settings, allowed themes, and allowed node types can be assigned per container, and cascade downward in the tree.
• Each user has his own "homepage" space where he can create new containers and content
• Based on user feedback, we found it best to change certain terminology, and remove a few node options, thus simplifying the interface a bit. This would be optional, were we to release the module to a wider audience.

I've recorded a ~10 minute screencast which runs through most of the features discussed above, which you can review here.

We've also done a lot of work on our own profile module (eduprofile), which draws on our backend (Datatel) to display users’ biographical, curricular, and personal information. It lets them edit various portions, depending on their role, and choose which other roles can see each portion of their data. An important distinction is that these are not Drupal roles, they're created dynamically from institutional data.

Areas we've struggled with:

• search. We've researched integrating with a Google Mini and, once time permits, will go that route. For now, we're not too happy with our search relevancy, and we're only searching across publicly available content.
• data integration. This has nothing to do with Drupal per se, but in terms of time spent, it's been one of the largest time sinks for us.
• We had to touch core. We have to do integration work when we adopt modules from contrib. We were able to back much of our code out of core when we ported to Drupal 5, and we're hopeful we can back all the way out when we port to Drupal 6 this summer.

What we're working on now:

• Moving the last of our old, static content into the system
• updating our codebase to Drupal 6
• calendaring for all users, built using a customized version of the events module
• quiz tool and gradebook to supplant most of the remaining Blackboard use on campus.
• migrating our library site
• enhancing our portal to incorporate more features (calendar display, profile management, etc.)
• integration with Views and CCK. When we started these tools didn't fit our needs. They do now.

At present both of our modules are tightly coupled to our Datatel implementation. At Drupalcon there was some interest in how our system worked. We also attended a session led by the Development Seed folks where they presented an alternative approach to some of the issues we worked to resolve, and were struck by one of the things they said at the end, which (paraphrasing) was, “So, we invented a solution off on our own, and now we want to know what the Drupal community thinks of it as an approach.”

We have the same question. We could work to decouple our code from Datatel and share it, but that represents a significant time investment for us, so we're curious to hear whether folks have more than an academic interest in what we've built.

Beyond this case study, after we've finished our migration to Drupal 6, we'll put up a test machine so folks can kick the virtual tires and get a sense of how this works. At best we'll get to that early this summer. In the meantime, I am happy to answer any questions folks have, and if needed I can screencap/screencast additional aspects of the system. We can also work to get a case study of monster menus with more detailed information on how it works up on drupal.org if folks would find that useful.

Access Control