Read

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.

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.

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

• Install FCKeditor Using WYSIWYG API
• Getting Started With FCKeditor
• Understanding Input Formats

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

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.