Read

Drops that you read.

Write About Drupal - And Get Paid For It

I have a lot of ideas about what people want (or need) to learn when it comes to Drupal. My ideas are a function of what I want to do with Drupal and this strongly influences the things that I research, learn, then teach others. My research reveals that there are a lot more things that people want to learn about Drupal. Certainly more than I can offer personally on this site. There are many good Drupal sites and blogs out there but I also know that many people who are working with Drupal and have ideas about the platform are not blogging about Drupal for a variety of reasons. It would be nice to hear from people in that situation because I think they could bring a lot of good knowledge to the table. There are also situations where people are writing about Drupal but their site might not have the reach they would like since they spend most of their time doing other things. Either way, I'd like to be able to help these folks get their knowledge to the wider community.

What I would like to do is create a platform for people who want to write about Drupal so they can reach the wider community and do so without either having to set up their own separate website or spend an inordinate amount of time promoting their own site. At the present time (according to Google Analytics) this site receives about 75,000 page views per month from 23,000 unique visitors. We also have over 900 subscribers to the main FeedBurner Feed and syndication via Drupal Planet. So what gets written here tends to get seen by a decent audience. I'd like to give you the opportunity to get your Drupal ideas, opinions, tutorials, etc. in front of that audience. If you write something good and I decide to publish it here I will pay you for it.

Bookmark and Share Bookmark or Share Post

Adventures In Authentication

A Capital Region Drupal meetup (the first of its kind I believe) is scheduled for March 6th and I hope to be able to talk about authentication and identity. Just a couple of years ago the issue of authentication and identity on Drupal sites was limited to the functions of the Drupal login system. I remember that the first module I ever utilized to improve the login process was LoginToboggan. LoginToboggan adds such nifty features as logging in with name or email address, placing a login form on pages not accessible to anonymous users and much more. It's a great module and I still use it today. Since then we've also seen a few social networks like Twitter and Facebook increase greatly in popularity. So while millions of people create accounts on those services they may not necessarily want to create an account (and have to remember another password) on your Drupal powered site.

Lucky for us Drupal site builders that the big social networking players realized that in order to get even bigger they would need to reach out to other sites. They have done so via APIs such as Facebook Connect, the Twitter API and Google Friend Connect. All three of these services allow someone to login to a website with their credentials from each of these services. So this allows people to log in to your Drupal site with their identity from Facebook, Google, or Twitter. Pretty cool, eh? All you need are the modules that make the connection between your site and these services.

Modules do exist for each of the three services mentioned above. Facebook Connect, Twitter, and Google Friend Connect all allow you to authenticate users to your site. They require varying degrees of technical expertise to set up and the exact functionality varies too. The good part is that they all seem to excel at verifying the identity of an anonymous visitor to your site, at least temporarily. The bad part is that they really don't fit in with the normal Drupal account creation process. If you're just looking for someone to be able to authenticate temporarily to add a comment they work great. If you want someone to be able to quickly create a full account, with access to all of the features of your site, with Google, Facebook or Twitter credentials then the modules fall short. What seems to work best is a hybrid approach where a user first creates an account on your site and then later connects to their account on the social network. After that they can log in with one of these services (provided you add the right links) and get all the benefits of a member of your site.

Bookmark and Share Bookmark or Share Post

Making Drupal Easier

In my capacity running this site I get a steady stream of inquiries and requests for assistance with everything from initial installs to theme issues to the configuration of modules and more. I have to admit that while I do the best I can to offer advice on these issues many of them are outside the scope of my knowledge. In fact, sometimes when I get inquiries I'm struck by two thoughts that underscore the nature of Drupal. The first thought is that I have a lot to learn. The second thought is that Drupal is one complex system. These thoughts lead me to some blanket advice that I believe can help a lot of people who are just getting into Drupal and scratching their heads about how to tackle what may seem like a monster task.

As I said I have a lot to learn about Drupal. This is after almost four years of building sites with the platform. So the first pieces of advice that with help the hike up Mount Drupal easier are to expect to keep on hiking and focus on the ground in front of you. To put it in clearer language, Drupal requires continuous learning and it's best to focus on learning what you need to know now instead of being in awe of all that you've yet to learn. This situation is not unique to Drupal. The necessity for constant learning is required with any system that is being constantly improved. This is worth pointing out because every day more people are getting introduced to Drupal who came from a world of closed source systems or html-based, non-dynamic websites. What was once relatively static is now a moving target...forever!

A Commitment To Learning

So a commitment to open source web systems is a commitment to learning. I think that Drupal is a complex system. It's also a powerful system and because of that you can do great things with it. I think what draws people to Drupal tends to be the shortcomings of other systems (I once heard someone say that WordPress was like a gateway drug for future Drupal developers) as well as the well known possibilities of Drupal. Those possibilities come with an overhead though. That's why some other advice I would give to people who are new to Drupal is to spend three hours learning for every hour that you try to do something with Drupal. There's no science in that ratio but I've come to believe that initially that this works better than if you flip it around and spend three hours of doing for every hour of learning. 

As far as I'm concerned toying around on a development site is akin to learning. I'm surprised at how many emails I get that start out with something like, "I'm new to Drupal and working on a site for a client..." For the clients sake I say this. Build that learning time into the development estimate. Because it's better to take longer and get it right than to rush it and force inferior process or functionality on the client. Drupal is just not a start today, launch next week (or even next month) system if you're not very familiar with it. The extra time for learning is worth it. It's worth waiting a few months to launch a site that you can be confident does what you want it to do while at the same time you're confident that you can manage it. What's the down side of this approach? The only possible downside is that you spend all this time and Drupal ends up going away or falling apart somehow. That's not happening. So what you're doing is making a valuable investment in the future of how systems are developed on the web.

Focus On The Task At Hand

Then there's the second part about putting your head down and focusing on the ground in front of you. The world of Drupal code is vast. Just look at all the modules on Drupal.org. There are more every day. And older ones are being improved upon to add new functionality. What that means is that if you are new to Drupal and you are keen on packing your first site launch with every feature found in Facebook or MySpace then you're going to run into trouble. Start a list of things that you would like people to be able to accomplish on your site. Prioritize that list and then focus on the top three things. Research the possibilities for making those three things work very well. If you can't make one of those things work well then skip it and pick up number four on the list. Keep in mind that you're implementing these things in addition to getting used to the core Drupal functions like administering the site. You are much better off launching a site with three things that work rock solid than ten things that work half way. You'll be swamped. You'll feel overwhelmed. And you might blame Drupal. Blaming Drupal for being overwhelmed is like blaming a mountain for how high it is. Drupal mountain is big. Take it one step at a time and you'll enjoy the hike.

Get To Know The Admin Functions

I have some other advice to offer. When you first get started with Drupal take a stroll through the admin section. Click on every link you can find in the core admin section. Study each page so that you can see what's available. Perhaps make notes about things you don't understand about the interface or the available options. There's a lot going on in the back end. All of it is important to the site that you will create and maintain for many years perhaps. I know that there is an urge to start doing something more right away. I've been there so I can't point fingers. But when you're done doing whatever it is come back and make a point of clicking all of those links. I've gotten so many notes from people who had probably slapped their foreheads after I pointed some simple out. My responses are usually delayed so I always hope that they were able to find out via Drupal.org or some other Drupal forum. That investment of time in the admin area can hopefully prevent some undue frustration.

My hope is that the advice in this post can help to make the transition to Drupal easier for some people. There's another more universal benefit of all this effort as well. In many ways the situation with Drupal mirrors other parts of our lives. Drupal is constantly changing. So are our lives. New functionality is constantly appearing just as new opportunities and tools are popping up in our lives. Change and complexity is all around us. So learning to slow down, be patient and embrace learning, especially in the early phases of introduction, is a very good thing. The benefits of such an approach extend to other areas. At least I think so. Oh, and one more thing. Have fun with it. Drupal should be fun. If it isn't then perhaps it's time to slow down and focus on the fundamentals.

I'll conclude by letting you know that I consider myself to be about as average as any person who builds Drupal sites can be. I've done some programming in my time but never PHP. I used to work with Dreamweaver, like so many have, but even then I wasn't a web developer by trade. These are the philosophies that have helped me, as a non-developer, get to the point where I can make some things happen with the Drupal platform. There's lots of other sage advice to be had especially at in-person Drupal meetups and on Drupal.org. This is just one more drop into the sea of Drupal advice because the goal of this site is to help you learn one drop at a time.

Bookmark and Share Bookmark or Share Post

Options For Managing Comments

Comments are the lifeblood of most websites that aim to be social. Drupal based sites are no exception. In fact the feedback I'm seeing is that many people who are new to Drupal get involved with it because building a robust social network using Drupal is easier than something like WordPress which is heavily focused on blogging. That doesn't mean that you won't have to put some thought into how to set up your commenting if you're building a Drupal site.
 

I like Drupal's built in comment system. It has nice features like threaded comments,  a comment approval section, search indexing of comments and the ability to turn comments on and off for each individual node. Out of the box the comments are very usable for low traffic websites. But if you expect a lot of activity on your site then your comment needs will require putting more thought into how you set things up. Your first big choice will be to decide whether you should build on the existing comment system using contributed modules or if you should use a 3rd party commenting system like Disqus, JS-Kit Echo or IntenseDebate.

If Drupal's built in comments are so good then why even think about shutting them off? As good as the comments are they don't necessarily meet all the needs you might have. For example, if you expect a lot of commenting but don't want to have to do a lot of maintenance and configuration on your Drupal site then a 3rd party system might be good for you. Let's say you want site visitors to be able to authenticate themselves using Google Friend Connect, Facebook or Twitter which are the most popular social networking services in the U.S. right now. You could utilize at least two contributed modules to make your site do that. But you would also spend quite a bit more time doing that than you would just configuring the Disqus module which gives you all of those features which are available via the free (for now) Disqus service. You can see a sample of how Disqus integrates on the module developer's site here. Another attractive feature typically included in these systems involves notifications. Moderators and comments can either subscribe to comments via an RSS feed or by email. Notification features can help to create a community on your site and keep people coming back for repeat visits.

The mileage you get out of 3rd party commenting systems will vary. When you opt for an outsourced approach for such a large portion of your site you also lose some control. Most services will keep a backup of your comments in case you decide to switch back to your native comment system. That doesn't mean that re-importing the comments back into Drupal will be easy. Your site may also be affected by the performance of the servers of the 3rd party service. If their servers have a problem then your site will likely load slowly or comments might not show up at all. So be aware of the trade offs.

If you want people to create accounts on your site in order to comment then you'll want to stick with the core comment system. The 3rd party offerings may authenticate users but they don't create a user profile on your site. If that's the way you're going then there are some contributed modules that you'll want to know about that can enhance the core Drupal commenting experience.

Identity

These modules help to establish the identity of commenters on your site.

Spam

These modules help to limit the effects of spam on your site.

  • Mollom - Offers spam filtering via text analysis and captcha presentation.
  • AntiSpam - Offers access to the Akismet, Defensio and TypePad spam filtering services.
  • Captcha - Allows you to present a CAPTCHA (which is a challenge image) to commenters.
  • Comment Lockdown - Applies a set of rules that make it harder for comment spam to get through.

Notification and Moderation

These modules provide notifications of new comments and assist with moderation.

  • Comment Notify - Allows registered and anonymous users to get comment notifications via email.
  • Watcher - Similar to Comment Notify.
  • Comment Moderation - Adds features that improve the comment moderation workflow.

So you've been presented with a lot of options here. The modules listed above certainly don't represent a complete list. You're welcome to link to your favorite ones in the comments. The approach you take will depend on the goals you have for your site, the number of comments you receive and your level of technical knowledge with respect to Drupal and the 3rd party services (such as Disqus) and APIs (such as Facebook Connect) that I've mentioned. 

Bookmark and Share Bookmark or Share Post

WYSIWYG Editors: Issues And Options

The WYSIWYG (stands for What You See Is What You Get) editor is one of the most important features of any content management system. It's the glue that allows html neophytes (present company included) to format their posts just right without having to delve into the html code itself. The screen captures below show what the beginning of this post looks like with and without the editor.
 
Without the Editor
With the Editor

 
The difference in the ouput of the two editors this particular post is subtle because I haven't added any extras (such as bold, italics, or alignment) to that first paragraph. But I think many people (especially folks new to web development) will agree that the wysiwyg editor view is more familiar and more inviting when it comes to creating content. There are certainly many more possibilities for those who don't have html skills.

Which Editor?
As of Drupal 6 there isn't a wysiwyg editor that is part of the core release. So that means if you want to have pretty post editing then you'll need to select a module of choice, install, configure and hope like heck that it works for you. But what editor to choose? Some of the more popular ones are FCKeditor (seen in the screenshot above), TinyMCE and BUEditor. Because this is open source the landscape with respect to wysiwyg changes over time. FCKeditor still works with Drupal but there's a new version called CKeditor that represents the next generation. Another interesting but less popular option is Whizzywig.

Once you've made your choice of editor then you need to get it installed and configured which is not necessarily the simplest task. In the case of FCKeditor and TinyMCE you download the actual editor separately from the module then upload the files to somewhere in the directory of the module. This is a step that often causes a bit of confusion. Thankfullly there's now a module called Wysiwyg that eases the integration process for these editors. If you use Wysiwyg then you can just upload the editor's files to the sites/all/libraries folder which you would create and then use the Wysiwyg module to configure the editor. Wysiwyg makes it simple to try out different editors and it supports the most popular editors.

Having tried installing different wysiwyg editors as both standalone modules and via the Wysiwyg module I've come to the conclusion that the Wysiwyg module is the way to go. The one issue that I have had with the Wysiwyg module is the fact that you may not have access to all of the various configuration settings that you would if you installed the standalone editor module. The upside is that you have a much simpler install and configuration process.

Let's Talk Images
The inclusion of images is a very important topic that comes up when discussing wysiwyg. Content creators want a simple way to include images in their posts. Most editors make it easy to link to an image but uploading and inserting images into posts typically causes problems. IMCE (installed on over 60,000 Drupal sites) is a very popular option that works well for me. There are some headaches that occur when using IMCE with a standalone editor module. This is where the Wysiwyg module offers additional benefits. The IMCE Wysiwyg Bridge allows you to easily use IMCE along with your editors that are enabled via the Wysiwyg module. For the moment this only applies to TinyMCE and FCKeditor but it could change in the future.

It's worth noting that I think that IMCE works best when using it for inserting images into posts and not when you're looking to create a standalone image gallery. Because while IMCE does do thumbnails it doesn't create galleries or cover more advanced actions like cropping and watermarking.

Beware Input Formats
Input formats are something that you want to consider when using wysiwyg editors. Drupal comes standard with 3 input formats, Filtered HTML, Full HTML and PHP code. For the most part if you're editing posts with a wysiwyg editor and insterting images then you want to use Full HTML. Notice that I said you want to use Full HTML. What about your users? If people are signing up to write blog posts then you probably want them to use Full HTML too. But if you allow anonymous comments you probably want to have a more restrictive format like Filtered HTML that only allows certain tags.

Input formats can be a very complex topic. Make things easier for yourself and have a look at the Better Formats module. Better formats offers you more flexibility with your input formats for content types. My favorite feature is that it allows you to specifically assign an input format per role. The simplest example of this is giving authenticated (signed in) users access to Full HTML and giving anonymous (not signed in) users access to Filtered HTML. It also gives you separate options for nodes and comments. This is very helpful and allows you to fine tune your content editing much more than allowed by the core features.

Drupal 7 And Beyond
It appears at this time that Drupal 7 does not include a wysiwyg editor by default. A recent post I saw indicates that there will be, "Improved support for integration of WYSIWYG editors." That being the case installing and configuring wysiwyg editors will continue to be an important skill for some time in the future for Drupal site developers. Whether or not that's a good thing or a bad thing will depend on who you ask. Hard core, old school developers would probably rather choose and configure the editor they like best rather than being stuck with what the Drupal community decides is the best option. People newer to Drupal development would probably prefer a default editor that also handles post images as well. I think that a good compromise would be to have a default editor that admistrators can choose to disable in favor of a different editor.

If this is a subject that you're passionate or curious about then see the Wysiwyg group over on Drupal.org. Lots of good information and discussion over there.

Additional Learning

Bookmark and Share Bookmark or Share Post

The Power Of Drupal Views

 When people ask me why I would ever use Drupal to build a website instead of other platforms like WordPress or Movable Type I typically have one answer, "CCK and Views." That could be interpreted as two answers but since the modules go hand in hand I'll call it one. I've written about the basics of CCK before so I recommend that you check out that post if you're interested in understanding CCK better. This post is about the Views module.

Views is a module that offers Drupal site developers (you I presume)  great flexibility of choices for displaying content. Views provides this flexibility by offering up a graphical user interface (pictured below) that allows you to query the Drupal database for content and choose the format of the content display without having to write SQL queries. I've written plenty of SQL queries in the past for business purposes and if I never write another one I won't be disappointed. If you want a much closer look at the interface I'm speaking of feel free to check out one of my videos that shows you how to do something practical with views.

Views Interface

Views Interface (Drupal 6)

Three Basic Types of Views

There are three basic types of views available in the base module. You can display content as a page, block, or RSS feed. When I say "content" I mean entire Drupal nodes or individual fields. For example, the page at http://learnbythedrop.com/cckandviews is a "view" that lists x number of nodes. When you list the node you get the Title + Body, plus links to comments and any other fields that would display when you are viewing a node. If you choose to display fields instead of nodes, then you can pick and choose individual fields from your nodes to display. For example,. the page at http://learnbythedrop.com/archives displays the Title (linked to the node), (Number of) Views, (Number of) Comments and (Number of) Votes fields.

The one thing that the views mentioned in this paragraph have in common is the fact that they are "page" views. Page views differ from other views because you assign a path (like http://learnbythedrop.com/archives) that displays the view as a page on your site. You can also create your list in a "block" view. When you choose block the content that you add to the view will be available on the block page (at admin/build/block) for configuration and placement just like any other block on the site.

You should put a little bit of thought in to what types of content you display in a block vs. a page. Blocks work well with lists of titles linked to nodes (see the "Recent Drops" and "Comments" blocks in the right sidebar), whereas a page might work best with full nodes or a collection of fields. Lucky for you that the views module has a very handy "live preview" feature that allows you view the results of your query while building your view.

The third type of standard view is the RSS feed view. This view outputs lists of nodes as an RSS feed that people can subscribe to in a feed reader such as Google Reader. If you have set up a page view that has the same content as the RSS feed you have the option to associate the RSS feed with that page and a small orange RSS Icon will appear on the page. See the bottom of the page at http://learnbythedrop.com/gallery for an example of how this looks.
 

Style Options

Drupal views also have several standard "style" options which differ depending on the type of view you choose. RSS, for example, is really a style option for your view. But if you choose to set up a page or a block view you have different options as to how the final display will appear. Some examples of style options are unformatted, list, grid and table. If you're creating a page full of nodes then you'll likely choose "unformatted" as your style. But if you're choosing a page with individual fields (like http://learnbythedrop.com/archives) then a "table" style might work best. For blocks that have lists of titles linked to nodes I typically choose the "list" style. Once again, the live preview option is your friend when making these types of decisions.

The "grid" style is an interesting choice if you're displaying just a couple of fields and want to repeat the content across and down the page. I've implemented this style on my view at http://iheartmets.com/metstweets, which shows a grid of recent tweets about the New York Mets.

Bookmark and Share Bookmark or Share Post

Changes To Project Pages On Drupal.org

You may or may not have noticed some subtle changes to the layout of project pages for modules over on Drupal.org. A few things have changed. Links for project issues and feedback have been moved from the bottom part of the page to a larger block on the left side of the page.There is also a search field that allows for a keyword search of the issue queue and a link to subscribe to the issue queue via email. I was a little confused when I first realized there were some changes so I thought it was worth posting to give those a heads up who might be confused too.

Click To View Full Image

Bookmark and Share Bookmark or Share Post

Twitter And Your Drupal Site

Twitter is the hottest social network on the web right now so it's reasonable to think that Drupal site builders would be seeking different ways to integrate their sites with Twitter.Thankfully, there are a number of ways that Drupallers can leverage the power of Twitter on their sites.
Twitter Module
The Twitter module allows you to post to or grab user data from Twitter. The module allows you to add the user and password for a site wide twitter account that will post items to Twitter when they are published to the Drupal site. You can choose which node types will send a notification to Twitter and add some additional default text to the post as well. There is also an option to let users input their personal Twitter account information so that their tweets can be imported to their profiles on your site.
 

Twitter Node Settings

Twitter Post Example

Imported Twitter Statuses

Tweet Module

The Tweet module adds a link that makes it very easy for site visitors to share your nodes on Twitter. The link to share with Twitter is displayed in the "links section" on nodes and teasers. The tweet link can be presented as an icon and the module project page points to some free "tweet this" buttons that you can use.

Tweet Link Example
 

Feed API

Twitter offers a wide variety of feeds that you can then import to your Drupal site using the Feed API module. Once imported via the Feed API module you can customize the presentaton of the tweets using the views module. Each user has their own RSS feed (here's mine) that is linked in the right sidebar of their profile page. Twitter searches via http://search.twitter.com also generate RSS feeds as well. Here's a feed link generated by a search for "drupal" on Twitter. You can get even more granular feeds from Twitter if you use their advanced search feature. For example, here's a feed generated from a search for "drupal" and my username on Twitter. The feed only displays the tweets from me that mention Drupal.

Tweets Imported With FeedAPI

Bookmark and Share Bookmark or Share Post

Drupal And The Cloud

I have been spending quite a bit of time lately pondering how Drupal site builders can use "the cloud" to their advantage. I've been using some cloud resources for a while without giving the larger implications much of a thought. As traffic to my sites grows I've considered how to handle the challenge of maintaining (or even improving) performance while continuing to add features to my site.

So what I wanted to do was share a few ideas and links that I have found (and maybe even implemented) while pondering cloud computing in the context of my Drupal sites. Buyers please beware. I don't consider myself and expert on any of this stuff. But like many Drupal developers I'm curious and learning as I go.

Amazon Web Services

Amazon offers a number of interesting services through their Amazon Web Services division. Amazon S3 provides pay as you go, expandable storage for all kinds of files at a very reasonable price. I have an account on S3 and use the great S3 Fox add-on for Firefox to manage my files. I've been using S3 to host a variety of navigation images and icons for my sites. This strategy helps to improve performance since it balances the load of the site between the web server where you host your Drupal site and Amazon's servers.  It is possible to use S3 to automatically store and deliver primary content, like photos and videos, uploaded to your site using the Media Mover module. I haven't tried the module yet but I plan to do so soon.

If you're interested in getting started with S3 please have a look at the Getting Started With Amazon S3 screencast.

One of the issues people have had with S3 is the fact that it is not a content delivery network (CDN). The files you send to S3 sit on a server at a static location and are not optimized for the fastest delivery to different locations around the world. Amazon solved that problem recently by introducing Amazon CloudFront. So if you're distributing media to the masses you can have it delivered via CloudFront and optimized for the location of the request for the file. The CloudFront pricing is very reasonable but will be added to the cost of Amazon S3 usage as well because files delivered by CloudFront are uploaded to Amazon S3. In very basic terms, when you upload a file to Amazon S3 you get two urls. One url is for delivering the file via S3 and the other is for CloudFront.

I'm using CloudFront to deliver the videos that power my recently added Learn By The Drop site guide. If you want to explore the possibilities of using CloudFront I suggest that you check out Getting Started With Amazon CloudFront.

More recently I've considered the merits of Amazon's EC2 elastic computing service. EC2 allows you to create an expandable server where you can run all kinds of web applications. This is definitely an option for more advanced developers who know how to setup servers and rock the command line. But it is getting easier to use and understand as companies race to offer user friendly tools for the EC2 service. EC2 is attractive because you can get a powerful server that can expand as your Drupal site expands and you only pay for what you use. It's unattractive because of the technical complexity and the fact that it's really not economical for smaller sites. My simple calculations estimate that a basic EC2 instance for Drupal will cost you about $60 per month plus bandwidth charges. I've no doubt that $60 is a great price for a server but most sites won't need the kind of horsepower EC2 offers. 

Here are some links related to EC2 and/or Drupal that you can take a look at to learn more.

How To: EC2 For Poets | WorkHabit Drupal EC2 AMI Screencast | Drupal In The Cloud | CloudKick

Google Docs

I've been using Google Docs to replace some functions that would otherwise be handled by Drupal. Last year and this year I wanted to include a baseball schedule on my Mets fan site. With a csv file in hand I considered importing it to the Drupal database but decided to use a spreadsheet on Google Docs and embed the file in a page on my site. You can see the results here. I've also found Google Docs helpful for creating surveys using their "forms" feature. You can create an embeddable form whose data is saved to a spreadsheet on Google Docs. I'm using this technique to collect data from my Drupal Use Survey. What you essentially get from the service is a simple database that is hosted by Google.

There are always lots of questions about using 3rd party services to outsource your Drupal site functions. Some people have privacy concerns. Others worry about the reliability of the 3rd party service affecting their site performance. These concerns are valid. So I think it's smart to consider the Drupal-only way vs. using Google Docs when adding functionality. Google Docs is worth considering for collecting and/or displaying data if the content involved is not the primary content for your site. It keeps the size of your database down and (assuming Google's performance is solid) removes a bit of load from your web server.

Stop Sharing Spreadsheets, Start Collecting Information

Mosso: The RackSpace Cloud

I found Mosso only recently and I could see that it was a step in the right direction in helping the average Drupal developer to deploy their site on a powerful server. The service is billed as, "The fastest, easiest way to put sites in the cloud." It sounds like Mosso offers you the power of a dedicated server with greatly simplified setup and management. It differs from Amazon EC2 because what you get with EC2 is basically an empty space whereas your space with Mosso is filled with the goodies you need (MySQL, PHP, etc.) to run a Drupal site. Mosso's pricing starts at $100 per month, which is at least $40 more than the Amazon service. But there's definitely value in the simplicity of a managed environment where less technical ability is required.  

Services like Mosso will appeal to those who want a high performance Drupal site but don't have the technical ability (or the desire to hire someone) to deploy a high powered web server. Cost could become a downside if your sites get popular. Mosso estimates that a top 1000 Technorati blog could cost about $800 a month on their service. Then again if your sites suddenly get very popular other hosts might shut you down (for exceeding bandwidth limits) while Mosso will allow you the room to grow in an instant.

If you're curiousity has been piqued then take a look at Installing Drupal 6 On Mosso.

Drupal And The Cloud

There are a lot of great tools and services that can help developers achieve benefits that were previously only available to those who could afford to spend thousands of dollars per month. It's an exciting time as competition builds in the race to bring the cloud to the average web developer. I have no doubt that Drupal developers will be able to take advantage of many of the things that come along.

Bookmark and Share Bookmark or Share Post

Connecting With Facebook

I spent quite a bit of time yesterday updating my I Heart Mets site to Drupal 6. One thing that I added that wasn't included in the Drupal 5 version of the site was support for Facebook Connect. I made the connection using the Facebook Connect module for Drupal.

Adding Facebook Connect to the site was pretty simple thanks to the module. I followed the directions in the Read Me file for the module and things seem to work fine. This is one of those modules where you need to download files from another site (in this case Facebook) and perform some configuration on Facebook as well. That's why it's very important that you consult the Read Me file for the module.

The Facebook Connect module adds a number of features that can help you to grow a community site.

  1. New users can sign up using their Facebook account information.
  2. Users can use their Facebook picture as their picture on your site.
  3. Users can import their Facebook profile information into their profile on your site.
  4. Users can invite their Facebook friends to join your site.
  5. When connected users comment on your site they can have a message published back into their feeds on Facebook.
  6. If a user is logged in to Facebook they can login to your site simply by clicking the "connect with Facebook" link.

I think that adding this feature to a Drupal powered community site makes a lot of sense because it seems like everyone is on Facebook right now. These features make it easier for users to interact with your site and also eases the process of having them introduce the site to their friends.

I have included some screenshots below that show some of the features added when you use the Facebook Connect module.

Bookmark and Share Bookmark or Share Post
Syndicate content