The preliminary DrupalCon San Francisco session schedule was released yesterday, and I wanted to get an overview of all of the sessions and so I created the following graphic:
As with every year, the schedule is bound to change a bit between now and the actual DrupalCon as there are still some conflicts and sessions to be confirmed, but this will at least start to give you an idea of some of the sessions that will be happening.
For more details on these, then be sure to check out the full schedule here.
Todd Nienkerk of Four Kitchens explains the concept of CSS grid systems and gives some tips on how to get started with working with the 960 grid system. He talks a bit about the 960 Grid System Drupal theme as developed by dvessel, who was actually able to get some of his content-first innovations ported back into the 960 framework. He also briefly mentions the 960 Gridder module that sets up a javascript overlay to verify that your design is properly lining up. He talks about the general trends of CSS grids and some specific resources that help with getting started on creating a grid-based design.
Provides a TinyMCE plugin to provide an indented, syntax-highlighted (colorized) HTML source view. Much nicer than the built-in TinyMCE HTML source editor.
Depends on the Wysiwyg module (http://drupal.org/project/wysiwyg), CodeMirror library (http://marijn.haverbeke.nl/codemirror/) and a correctly configured TinyMCE editor (versions 3 and up).
Read INSTALL.TXT - you need to download the latest CodeMirror library before enabling the module.
A similarly named project - Wysiwyg syntaxhighlighter integration (http://drupal.org/project/wysiwyg_syntaxhl) provides syntax highlighting that will be shown to end users - i.e. code snippets in <pre> elements.
This one highlights the syntax in TinyMCE's HTML source view.
Coming back from an excellent time (and an excellent talk, updated slides here) out at SxSw Interactive, I've been thinking once more as always about what it really takes to get Drupal "to the next level."
Clearly there are multiple fronts we are proceeding along as a community. The amazing development work being done in core and contrib is obviously key, as are the boundary-pushing efforts to integrate more and better infrastructure for enterprise-scale use-cases, as is the continuing drive to test everything in an automated/continuous basis. However, I wanted to throw out yet another thing we should be thinking about as a development community: monitoring.
Now to be clear, I'm not talking about what you can get out of Munin (although that's nice). It's good to know your server load, but what I really care about is my page execution time, my per-bootstrap memory consumption, my most-frequently run (or longest running) queries. Many of the pieces are there in terms of code already written into the devel module and others, but we don't have anything to compare with what other platforms are doing to expose the internal metrics of their application:
NAT-ng comes from NAT module, a helper module used to maintain node-term relationships, i.e. when a node is created a taxonomy term is created automatically using its title and body in any associated vocabularies. This module also attempts to preserve hierarchical relationships where possible.
InstallationIf you are moving from NAT module to NAT-ng you should rename 'nat' table to 'nat_ng' by executing this SQL query:
RENAME TABLE nat TO nat_ng;
This module provides a new widget for the userreference CCK field type.
FeaturesThis module uses the api of the tweet module to display a link to identi.ca
Currently you need http://drupal.org/node/744712 to make this module working. Sadly this is on needs work
As I've blogged about this before, work on localize.drupal.org's improved functionality was going on heavily in the past weeks. We launched a staging site with interface improvements almost a month ago, and kept adding small improvements on top of that.
Given all the great feedback on the new user interface, it was time to finally launch it on the live site. Here is a rundown of the most important improvements.
cocoate.com posted a photo:
I recently created a module that uses the Google Analytics API to capture the top ten nodes of various content types by day, week, and all time. This is a great option for any site that needs to use caching, and can’t use the Statistics module.
People on a mobile device are not ‘browsing’, but rather they are looking for a specific piece of information. Use the clearest and simplest language instead of a discursive style for site content.
Divide pages into usable but limited size portions.
If pages are too large they will take a long time to load. There are limitations on some mobile devices as to the largest page they can accommodate. Also, we don’t want our users taking a big hit on their (sometimes) limited data plans.
On the other hand, if a page is too short then the user may require multiple page requests to read the relevant information.
Scrolling
The layout of the page should be such that the user can use a simple repeated scroll. The majority of mobile sites scroll vertically, so elements should be “stacked” in this way. Some content requires a secondary scroll, such as maps or some images, but should be avoided wherever possible.
Turns Drupal into a multi-group email list.
OG Mailinglist allows users to start new discussions by email and post comments on existing discussions by simply replying to emails. You get the best of both worlds: a browser-based discussion site and an email-based list.
See the INSTALL.TXT file for system requirements and prerequisites.
EXAMPLE:
Suppose you have implemented Organic Groups and have three topical groups: "Web Programming", "Technical Help", and "Politics". Users normally go to the group page and click "Create Story" to start a discussion. With this module, a user simply emails "web-programming@yourserver.com" to start a new discussion. The subject becomes the story title, and the body becomes the story body.
Using the regular Drupal notifications framework, all users in the group get an email telling them of the new discussion. These users would normally click the link to make comments. With this module, a user wanting to post a comment simply hits Reply and sends his or her comment. The reply mail also goes to the "web-programming@yourserver.com" address.
In many ways, your Drupal site becomes a mailing list manager. Users never have to visit the site to start or participate in discussions. The module automatically detects new or deleted groups and is always up to date.
SECURITY:
I recently agreed to take on two new roles in the Drupal open-source project: maintainer of the core Search module, and documentation volunteer coordinator, specifically for the in-code API documentation that’s displayed on api.drupal.org. I’m excited to be part of helping Drupal 7 come together, but to make it really successful, we need your help to get Drupal 7 documented! We need to get the API and Module Update Guide documentation fixed up, so that module developers can make their modules available for Drupal 7, and we need to get the Handbook updated for Drupal 7 so that less expert users can figure out how to use it.
Pretty much anyone can help in this effort. To get you started, we have a page listing what needs to be done, and both Ariane (arianek) and I (jhodgdon) are often available on IRC (#drupal-docs or #drupal-contribute). So feel free to jump in at any time!
Also, if you’re headed for DrupalCon San Francisco in April, please consider coming for the Sunday or Thursday sprint days. We will have documentation sprints going on, and people available to get you started, point you to tasks, etc.
Thanks!
DXMPP creates a themeable browser chat client for an XMPP server.
At its core, it uses the Strophe library to connect via long AJAX pulls (aka Comet) to an XMPP server. Users are automatically registered and associated w/ Drupal users, and it also automatically synchronizes User Relationships.
By default, the themeable chat sessions are displayed via JavaScript in a fixed bottom position on the page. The roster expands, and an icon (via ImageCache, if enabled) representing each user will expand a chat box next to it.
I've successfully gotten the module to integrate with ejabberd, although there are other alternatives, such as OpenFire, both licensed under GPL.
After enabling and configuring your XMPP server, you'll also need to copy the Strophe library somewhere in your /sites/all/libraries folder. The module will automatically discover its location.
Look here for more helpful links and documentation for the set-up and configuration, which can be difficult at best, especially when you're first starting out with XMPP.
You may also consider joining the Drupal XMPP group.
I have a "system" that I have built in Drupal 6 for tracking employee time off. I used actions, triggers and php snippets to get this all working. I have a form for creating a time off request, which launches an approval workflow and email notifications, and that ends with (if the time actually taken) a record that records that time, and reports that HR uses for determining vacation and sick balances.
However, as I add more and more features and logic, I begin to wonder if this wouldn't be better as a module, simply because of the sheer number of triggers and actions, and the growing complexity of those php "snippets".
So the question here is, what are appropriate guidelines for determining when a "system" should be a module? I know this is somewhat of a nebulous question, but I feel like I could pretty much go on forever with what I'm doing, but also realize that at some point nobody following me will ever be able to figure out how it all hangs together.
It'd be great to hear what prompted some of the experts here to write modules, particlularly in the light of the power of actions and triggers, as well as modules like rules and workflow.
Joyce
Drupal Dojo