Planet Drupal

If you're heading to Drupalcon San Francisco in April, here's your chance to get in for free! I'm giving away two pairs of tickets over at DrupalModules.com.

The contest ends November 30th, so don't miss out!

This mini-HOWTO will guide you though the integration procedure for both Drupal and Gallery2, with assistance of FCKeditor and G2Image. If you hope to insert your photo album images into Drupal without a heavily embed style, this should be your cup of tea.

Why not integrate with Drupal's gallery.module?

The most simple answer should be: keep everything simple. I hope to keep my Drupal and Gallery2 installation isolated for a simpler management, as different system coming with different specific requirement. What I only hope to do is to reuse the existing resource coming from Gallery2, so user don't need to upload a single image twice.

Why not use Drupal's image.module + img_assist.module?

They are in different design so I use both solution. I use image.module + img_assist.module for tiny amount Drupal-only images, for fast layout design and so on, e.g. insert some image when writing a blog post as like as this mini-HOWTO. You won't hope to: 1. create a new album in Gallery2, 2. upload images and manage their title, 3. go back to Drupal and choice your image though FCKeditor, how fancy!

Demo Drupal and Gallery2 setup

In this HOWTO I will install Drupal and Gallery2 as path below:
www2:/# ls -la /var/www/
total 60
drwxr-xr-x 13 www-data www-data 4096 2009-11-07 12:49 .
drwxr-xr-x 18 root     root     4096 2009-05-29 09:13 ..
lrwxrwxrwx  1 www-data www-data   10 2009-11-07 12:49 content -> drupal-6.x
drwxr-xr-x  9 www-data www-data 4096 2009-07-02 04:55 drupal-6.13
drwxr-xr-x 10 www-data www-data 4096 2009-11-07 12:13 drupal-6.14
lrwxrwxrwx  1 www-data www-data   11 2009-10-27 14:40 drupal-6.x -> drupal-6.14
lrwxrwxrwx  1 www-data www-data   11 2009-11-07 12:49 gallery -> gallery-2.x
drwxr-xr-x 11 www-data www-data 4096 2009-11-06 16:01 gallery-2.3-developer
lrwxrwxrwx  1 www-data www-data   21 2009-10-30 09:14 gallery-2.x -> gallery-2.3-developer

Why a lot of symlink? Because whenever upgrade is required, I just need to download the new version and relocate the symlink target. No path or URL will be changed.

So if my server with URL http://example.com/ and Apache DocumentRoot on /var/www, Drupal and Gallery2 will be accessible though:
http://example.com/content/
http://example.com/gallery/

Moreover, Drupal's FCKeditor is already installed in:
/var/www/drupal-6.x/sites/all/modules/fckeditor

Where G2Image already installed in:
/var/www/drupal-6.x/sites/all/modules/fckeditor/plugins/g2image/

Download G2Image here, and also read its general installation guideline.

G2Image Drupal-specific configuration

Edit the /var/www/drupal-6.x/sites/all/modules/fckeditor/fckeditor.config.js, and add the following line:
FCKConfig.Plugins.Add( 'g2image' ) ;

I add the G2Image button to both DrupalFull and DrupalFiltered, so it should look like:
['Image','G2Image','Flash','Table','Rule','Smiley','SpecialChar','DrupalBreak'],

Now edit the /var/www/drupal-6.x/sites/all/modules/fckeditor/plugins/g2image/config.php as below:
$g2ic_gallery2_path = "/var/www/gallery-2.x/";
$g2ic_embedded_mode = TRUE;
$g2ic_use_full_path = TRUE;
$g2ic_gallery2_uri = '/gallery/main.php';

Ok that's all :D

Test the setup

Create a new node, activate the FCKeditor, and you should have something similar as below:
drupal_g2image-001.png

When click on the G2Image button, you should able to browse your album, select and insert your images:
drupal_g2image-002.png

Once insert your editor should look like:
drupal_g2image-003.png

Ok so now save the node and review it. Enjoy :D

After noticing that in the community, some people are seeking a central community 'hub' Feature Server via which to upload and share their Features, I bough featureservers.org and set up http://community.featureservers.org to do exactly that.

read more

Everyone knows the top-tier Drupal modules, but with over 4,000 5,000 modules available for Drupal it's no surprise that many useful ones go unnoticed. As part of its mission to raise awareness of these unsung heroes, Palantir is presenting this series of articles on modules that carry more than their weight in code.

In part 2 of our 5,046 part series, we present: Suggested Terms

read more

By default, the Drupal Lightbox2 module supports the flvPlayer flash movie player, which is not Open Source. However, Drupal has a 100% Open Source video player called Flashy. Here's a quick method of overriding Lightbox's setup to use Flashy instead of flvPlayer.

Assumptions: This article assumes that you already have Lightbox2 configured, and you already have fields configured to use Lightbox2's video support. All we are doing here is swapping Flashy in for flvPlayer.

read more

AT&T, the largest provider of local long distance telephone services in the United States, is using Drupal on for an add-on site called AT&T Apps Beta.

The website requires you to log in so there isn't much to explore without creating an account. Either way, AT&T Apps Beta is a platform for connecting highly involved AT&T customers with access to the latest and greatest mobile applications.

Can you see a pattern here? Another large organization using Drupal to build an add-on site. Once an organization has its feet wet with Drupal after implementing a couple of micro- or add-on sites, you start to see Drupal bubble to the top of the organization or to larger and larger web properties. Either way, it is great to see one of the largest technology companies use Drupal. Another win!

Services is a module that makes it easy to provide web services using Drupal. What services doesn't do is to allow the definition of separate API:s. This is something we need to fix if we want to turn services into a real web-service framework.

Consider the following: Today all installed services are always available on all installed servers and they all have to use the same authentication method.

This is what makes services practically useless as a building block for other modules, and what makes is nigh on impossible for API:s to coexist in one Drupal install. This worked fine when services only was used for integration with a single Flash/Js/external application; when it was installed by the developer/admin to solve one specific task.

Now we're nearing a point where both blog api and pingback implementors are looking to leverage services for their modules. This is great, as our goal must be that everybody implementing any kind of web service should look to services (core inclusion on the far horizon). Unfortunately it's not possible with the way services is constructed today.

The proposed solution

What I propose, and have gotten quite far with implementing, is to introduce the concept of separate endpoints. Endpoints allows modules and administrators to define separate API:s. By this I mean that each endpoint will provide the following information:

• which services should be exposed
• with what server and on which path they should be exposed
• how should the clients authenticate themselves

The endpoints can be customized completely independently of each other. Endpoints can also be created directly through the administrative interface. The plan is to use ctools for the endpoint information, which will give us exportables for API:s, correct handling of loading of definitions from code and database, overrides et.c.

I'm really exited about the possibilities that this provides, and how it ties in with features. I see it as absolutely essential for services continued development, and not as a good-to-have extra. That is not to say that it needs to be implemented exactly as I've done it. But we need the core functionality.

The current state of 3.x

I'll illustrate with some screenshots from a site running the endpoints-branch from github:

This is the new (when say new throughout the post I mean "my proposed new") first-page for services admin. It lists the services endpoints in the installation and some brief info about the path, server and authentication module that's used, and it lists the active services for the endpoint. The services that are listed may be fully or partially enabled.

This is a shot of the edit endpoint page. Here you can choose the path for the endpoint and which server and authentication module that should be used in the endpoint. Here you can see that the oauth module has gotten a new configuration which is OAuth context, described pretty well in the form: "The OAuth contexts provides a scope for consumers and authorizations and have their own authorization levels. Different services endpoints may share OAuth contexts and thereby allow the use of consumers and tokens across the services endpoint boundraries."

This page allows you to select which services and controllers will be exposed at the endpoint, and allows the authentication module to supply options for each controller.

What I like the most is the ability to define a services endpoints in code. Here we have the conglomerate module that I'm currently working on that defines it's own endpoint. This way modules can expose their own API:s and own authentication settings without disrupting each other.

The same goes for oauth_common, where modules now can define their own oauth contexts. Both these are perfect candidates for chaos tools integration, and ties in perfectly with the features-way of thinking.

Endpoint branches:

• Services
• REST Server
• OAuth Common
• Services OAuth

This is a recolourable multi-column liquid/fixed layout theme, that uses the Color module to change the theme colour without any need of coding.
It has an optional frontpage layout that uses promoted pages as a full page slideshow. Also built in is the ability to have different banner headings (and logos) for different sections of the website. available now from our store

For a few months now, every project at work is handled in an agile way with the SCRUM principle and our development team gets a free day every two weeks to work on their own projects using the same technique. This gives us a good overview where we are and what we want to do in the future. Most projects during our free time is done on modules we're using in projects which we're contributing back to the Drupal community. Most of my time went into Node displays and Display suite and after a few iterations we're pleased to announce some good news!

The original version of ND and ND contrib is now available in the 6--1 branch and will be maintained only for bug fixes. We've not yet released an official version, but the API is finally frozen, so you can start testing without fearing to upgrade in the future. New features will go in the 6--2 branch which is dependant on DS. There is no real upgrade path between both branches, so make sure you make the right decision before starting on a project.

DS, short for Display suite, is an API which makes it possible to control the display of any data object (nodes, comments, users ..) in every context (full node, full user view, teaser, ...). The project page lists modules which are already available, some of which are pretty stable (nd) while others still need some love (ud and cd).

As you can see in the picture, we still have a lot of tasks we want to implement, but it's really keeping us focused and motivated :)

With drupal 7 the concept of an entity gets introduced in drupal, thus nodes, comments, users, terms - all these are drupal's entities. Most important the also new field API is able to support any entity!

So how will this affect the drupal landscape?

read more

Checkout view being currently disabled in ViewVC is a very good opportunity to remind everyone that linking to your README.txt file in CVS does not count as documentation on your project page!

Here are some things I, or anyone else, can do with a proper documentation page in what used to be called the handbooks section of drupal.org:

• Correct it.
• Expand on it.
• Clarify things for newbies.

read more

I was upgrading The Watcher module to Drupal 7 today and found myself having to test a lot of email sending. Looking around in vain for a fake email system to log emails to the disk instead of sending them out into the interwebs to risk getting called the dreaded meat product, I decided to write one using the new pluggable mail system interface in Drupal 7.

Previous versions of this have existed in the past, but I couldn’t find anything in devel currently. Here’s how it works. If you want to save your mails locally to files:

Step 1
Install Devel
Step 2
Apply this patch (until it gets committed) – Review here: http://drupal.org/node/625062.

cd sites/all/modules/devel
curl http://drupal.org/files/issues/develmail-625062-1.patch | patch -p0

Step 3
In your settings.php file:

$conf['mail_system'] = array('default-system', 'DevelMailLog');

That’s it!

Unless you set anything else mails are saved to files/mails/$to-$subject-$datetime.mail.txt

Example

Bonus
You can change the directory with
variable_set(’devel_debug_mail_directory’, file_directory_path() . ‘/mails’);

Or the file format
variable_set(’devel_debug_mail_file_format’, ‘%to-%subject-%datetime.mail.txt’);

Till next time spammers…

I'm a big fan of having an automated deployment process. It's really the web development analog to the "one step build process", as described in the Joel Test. In the past I have used various shell scripts to perform this task, but I have recently become a convert to Capistrano (or "cap" for short). With Capistrano, uploading your code to the test server is as simple as typing cap deploy. When you're ready to launch in production, it's just cap production deploy.

From capify.org:

Simply put, Capistrano is a tool for automating tasks on one or more remote servers. It executes commands in parallel on all targeted machines, and provides a mechanism for rolling back changes across multiple machines.

In detail, here are the features that got me hooked. There's a lot more that cap can do, and I'll describe some more tricks in part 2 of this post.

• Atomic deployments with error checking. Cap uses a set of symlinked directories, and the links are updated during the final step. It also won't allow a deployment to keep plowing ahead if an intermediate step fails. This makes your deployment atomic; it will either fail or succeed entirely.
• Fast rollback. If something does go wrong, getting back to the previous state is as simple as cap deploy:rollback.
• Parallel execution. If you use multiple servers in a load-balanced environment, cap can make managing them easier.
• Multistage deployments. "Stages" are different server instances of your code. You may have different servers for development, content entry, and production. With the Multistage extension, cap can share code for common tasks between these stages.

read more

I'm going to be doing a talk in a couple of weeks called "10 reasons why Drupal (might) kick your CMS's a**" to a local group of web tech folks, only a couple of which use Drupal. I have some ideas, but wanted to crowdsource this a bit and see if I can get some input from the community. I have a very limited exposure to other popular CMS's, so any input on comparing and contrasting Jooma, Wordpress and Drupal would be appreciated. Also, any nifty graphs or diagrams that might hit the points home? So far, here are some items on my list:

• Caching - The various caching tools enable Drupal to perform nearly as fast as static HTML
• Community - Lots of IRC participation, local user groups, positive leadership
• No forking - The community hasn't yet reached the point where a schism caused forking.
• Central module repository - This has meant that all projects are supported in similar ways (version control, issue queues, etc) and that they are GPL compliant. Also, this adds exposure for the modules and they get vetted by the community.
• Drupal is a programming framework plus a CMS - Drupal does a lot of heavy lifting, and helps you organize your code in a meaningful way other folks can plg into.
• Drupal modules don't have to hack core to work - As opposed to other CMSs
• Drupal scales well - And this will only get better with Drupal 7 and the new database layer
• Drupal is mature - It's been around a while, it's stable and is being supported by a lot of big projects (need some good diagrams here)
• Extendable data structures (i.e. fields in core) - Makes all data flexible at the interface level

I'd love to have some good visuals for this, and I'd also like to get some ideas on what I might be missing. I will gladly open source this presentation as well once it's complete.

Thanks!

Raincity Studios is listed along side 9 other companies in the current issue of WE. The West Ender Cover Feature:Made In Vancouver.

Our city is a hotbed of creativity and entrepreneurial spirit. From the fashionable to the ecological, here are 10 businesses — new and established — we think are at the top of their game.

We are honored and exited to be featured with some of Vancouver's greatest and most innovative companies.

Here's what they had to say about Raincity:

RAINCITY STUDIOS

What it is: trailblazing online-community host

Why them? Rising from the wreckage of 2002’s internet bubble bust, technologist Robert Scales was in search of something new. At the time, Vancouver’s open-source and Web 2.0 scene was very much in its infancy, and Scales set out to chart new territory in what was then known by his contemporaries as the Wild West of new media. He became the sole founder of Raincity Studios in 2003. Since then, the influential Gastown headquarters of the social media and technology consulting firm has evolved, becoming known as the pioneering hub of Vancouver’s new-media scene. True to the multifarious nature of open-source technology itself, Raincity Studios is difficult to define in one stroke — the company creates templates for websites built in Drupal (an open-source content-management system), delivers graphic-design services, and helps companies build websites which, in turn, build community capacity. Sounds like the future? Well, it’s all happening now. (RaincityStudios.com)

Also on the " Made in vancouver" list:

• The prominent Vancouver shoemaker John Fluevog
• Small Potatoes Urban Delivery, a personal favorite since 1998.
• Pyrrhais, jewelers to the stars
• Cheeky Umbrella supplying Vancouverites with dryness accessories.
• The Co-operative Auto Network, an awesome idea, catching on fast.
• Portobello West, Vancouver’s original fashion and art market.
• .. and a few more..

In our opinion, this list is only a small fragment of the amazing talent that is present in this city.

As Vancouverites, we are lucky to have an empowering community and amazing support to help us harvest the innovations and creativity that is found here.

Without this community and the support of our friends, employees, family and peers, perhaps we would be telling a much different story today... Thank you everyone for the support you have given us over the years.

This blog post is a by-product of my preparation work for an upcoming talk titled "Why you should be using a distributed version control system (DVCS) for your project" at SAPO Codebits in Lisbon (December 3-5, 2009). Publishing these thoughts prior to the conference serves two purposes: getting some peer review on my findings and acting as a teaser for the actual talk. So please let me know — did I cover the relevant aspects or did I miss anything? What's your take on DVCS vs. the centralized approach? Why do you prefer one over the other? I'm looking forward to your comments!

Even though there are several distributed alternatives available for some years now (with Bazaar, git and Mercurial being the most prominent representatives here), many large and popular Open Source projects still use centralized systems like Subversion or even CVS to maintain their source code. While Subversion has eased some of the pains of CVS (e.g. better remote access, renaming/moving of files and directories, easy branching), the centralized approach by itself poses some disadvantages compared to distributed systems. So what are these? Let me give you a few examples of the limitations that a centralized system like Subversion has and how these affect the possible workflows and development practices.

As a long-time Drupalist, I have to confess a wandering heart. Over the past couple years, I've grown more and more interested in other software and bigger-picture issues, branching out from the trials and triumphs of developing sites with my favorite CMS and looking increasingly at issues of integration and platforms. However, recent news has brought Drupal itself right back into the center of my thinking. With all respect to the Wu, I have to bite off a venerable hip-hop-ism in light of the recent run of news: Drupal Rules Everything Around Me.

The two bits of news I'm most excited about came through last week. First was the relaunch of Whitehouse.gov on Drupal. A lot of the reporting on that event (both pro and con) was typically fuzzy technology journalism — even prompting some correctional responses to the FUD — but overall I think the NY Times Circuits Blog got the essence of the story right:

To some, the White House shift to Drupal from a proprietary software package represented a serious seal of approval for open-source software.

“While open source is already widespread throughout the government, its adoption by the White House will almost certainly give permission for much wider uptake,” wrote Tim O’Reilly, who publishes books and holds conferences about open-source software.

The truth is that the use of Open Source code (Drupal or otherwise) for the whitehouse.gov site probably says very little about what functions that site will exhibit. Given my back-story with the Howard Dean campaign I admit I get a thrill from seeing our technology win out, but the site itself isn't going to change radically: it will remain a tightly controlled, top-down public relations website for the President. The "political ramifications" here are small, if not nil.

However, the business ramifications are very real. The addition of an ultra-high-profile site to the roster of Drupal adopters, likely the biggest signal launch so far, is the latest in a series of signs that Drupal is growing past the initial "early adopter" user base that's been driving the market for the past three or four years.

Following on that event, Dries published a blog to let us all know that Drupal is in the visionaries quadrant in the latest Gartner research report on "Social Software in the Workplace." This is a very good sign for future adoption of the software, and a major coup for Acquia's marketing efforts:

This is another important step towards increasing enterprise/institutional adoption of Drupal as a platform. Along with the other great developments we're seeing with "Drupal products" (or distributions, if you prefer) and strong growth in the training sector, 2010 looks to be a very bright year for Drupal. It's an exciting time to be a member of this community, and a participant in this rapidly evolving market.

When we talk about video streaming, many people still think of expensive hardware, dedicated uplink capacity and a complicated server side video encoder. However, nowadays video cameras in mobile phones and online streaming services can solve most of the problems for us if we sacrifice a bit on video quality. Drupalcamp Prague was just over this past weekend, and while I was busy presenting two sessions, demoing Acquia Gardens in a third one and speaking of contributing to Drupal in a fourth one, István Palócz was trying to ensure live streaming of the conference will be online.

In practice, the only hardware he used was a Nokia E51 mobile phone. Although it was attached (glued) to a laptop as seen in the picture, the laptop only served as an immediate camera stand. The phone was indeed plugged in almost the whole time to avoid the battery becoming empty, but the streaming was done solely using the phone hardware. Features used to stream were built-in wifi support in the phone, so the streaming can use the event's wifi service to stream the video and the Ustream broadcasting application available for some Nokia and Android phones. Though there is an iPhone app available, that does not support broadcasting.

With a capable phone, wifi and a ustream account, István was able to stream almost the whole event. Outages included when he actually needed to grab lunch so did not arrive back on time for the session and when he got a call. Still, those watching the stream were happy to see the sessions live and enjoy some of the program. I'm not highlighing this streaming technology for its stunning quality (although video quality definitely depends on the camera in the phone). You can check some of István's recordings to see the quality. It's the simplicity of the solution that is amazing. Just plug in your supported phone to a power outlet and stream over wireless. Way to share with the Drupal community!

Know of any similarly simple streaming solutions?

read more

Sorry, I couldn't resist :)

While I was writing my article on how to do deployments and workflow with Drush_make and Aegir, it occurred to me that once upon a time, I wrote an Installation Profile to build a Feature Server using the fserver feature itself, with the other required components such as Features, CCK, Views, etc per Development Seed's Recipé.

read more

One of the great things about Drupal is that you can run more that one site off one installation. This saves disk space and load on your server, it also saves maintenance time. With only one installation to manage and update the time spent administering your site drops greatly.

So, how do you setup a multi-site? well, it’s very easy.

1. Firstly install Drupal as you would normally. Download it into your web root, copy the settings.php file, add a files directory, setup a database. etc. The domain name for this site for example would be http://www.example.com.

read more