Posts tagged as:

drupal

Tools I use: Personal Web Presence

by Pearlbear on May 6, 2011

I’ve had a web presence of some sort since way back when most personal URLs looked something like: http://somecollege.edu/~username. In 2002 or so, I ditched HTML for a series of CMS systems for my personal stuff. I started out using the CMS I wrote in Perl, called XINA. (Those were the days.)  Anyway, that was then, and this is now. Here’s what I use.

Software:

  • WordPress – you already know it and love it. I use it for this blog, only. I used to have two blogs on WP – this blog and my personal blog, but I moved my personal (and author blog) to Drupal, to integrate it with other stuff I had online.
  • Drupal – I use Drupal for my personal blog and also other purposes, like the website for my intentional community. My main personal site will be migrated to Drupal 7 soonish. My main sci-fi author site is already on Drupal.
  • Dokuwiki – my woefully neglected and out of date technology wiki is on Dokuwiki. Dokuwiki is a very cool tool. It’s a wiki, but everything is stored in files instead of a database. It makes it quicker, and also much more easily migratable. The annoying part is that it is one more wiki markup to learn (I wish SOMEONE would finally agree to make a wiki markup standard!!)
  • In the relatively rare case where I need to use HTML/CSS for web pages (there are a few legacy sites I maintain for friends) I use Bluefish (on Ubuntu.)

What I like most about WordPress is that I don’t really have to do any work to use it, or tweak it. I love how easy it is to use.

I love Drupal for its flexibility – and for my personal stuff, it’s really great to be able to mix and match stuff (like I actually have two different blogs on that site, but it’s really only one blog… Drupal is ace at that sort of thing.) I keep debating about whether or not to migrate this blog to Drupal. Stay tuned.

Hosting:

All of my personal stuff is on Dreamhost. I say this with some hesitation. I have hosted with Dreamhost since 2007. They are worker-owned, pretty green, and their newsletters are quite humorous. They give free accounts to nonprofits. Their service has improved over the years, but they ultimately aren’t all that reliable. They have downtimes (a really bad one recently,) Drupal often barfs on Dreamhost during admin tasks, and you can’t run Rails apps reliably at all. I’m going to spend the spring and summer migrating all of my domains (there are plenty!) to a VPS on Linode (this will be my chance to play with IPv6, too. I already use Linode as a development server.)

Tagged as: , , ,

Open Source vs. Proprietary: CMS

by Pearlbear on April 4, 2011

Content Management Systems are an essential part of the communications function of nonprofit organizations. There are a myriad of options, open source options are among the most popular, possibly the most popular.

I’m going to focus here on the nonprofit sector, and options that are most common among nonprofits.

On the proprietary side, there are a number of options, and they fall into three categories:

  1. Single-source proprietary custom CMS (from one web shop, or web host)
  2. Proprietary CMS as part of a large package (such as from Convio or Blackbaud)
  3. Proprietary stand-alone CMS (such as Sharepoint.)

You already know what I think about option 1, so I won’t belabor it here. Many people have found that option 2, using a large package, which includes donation pages, event management, etc. can be a really good option, and I certainly don’t want to say that this is not a good idea – I think it can be – but it also can be quite costly – and for many organizations, it’s overkill. And there are open source options that can do much of the same work for much less money.

There are not a lot of stand-alone proprietary CMS systems in nonprofits these days. Microsoft Sharepoint might be the most common I’ve heard of. Ektron is another one that I’ve heard folks talk about, as well as ExpressionEngine. The advantage of using Sharepoint for Microsoft-centric shops is that there is full integration with lots of internal network resources.

The open source options are many, but the big four: WordPress, Drupal, Joomla, and Plone, stand out from the pack. As you know, I am pretty loyal to Drupal (and secondarily, WordPress) but I have to say that Joomla and Plone are solid, wonderful projects, with great communities, and active development, and will serve you well. Check out Idealware’s newish comparison of the four – it can help you figure out what’s best based on your needs.

Other open source options that I think are worth looking at include: Alfresco, which is heavy on the document management functionality and DotNetNuke, which is based on .NET, and somewhat popular among Windows users. Two up and comers I am very interested in following include Radiant and Refinery, both based on Ruby on Rails. There is also Django-CMS, written on top of the django framework (a python framework.)

If you’re really interested in open source CMS options, and looking not for data on features, but for data on popularity, marketing, community and such (a good idea if you are, for instance, a shop deciding what CMS systems to develop with and support) check out this report from Water and Stone (a digital marketing agency.)

I think on the whole, though, the number and richness of options on the open source side is quite a bit better than that on the proprietary side, and until I get an answer to this question, I can only guess that open source options have won over proprietary ones in the nonprofit sector.

Tagged as: , , , , , ,

{ 5 comments }

Drupalcon Highlight Reel

by Pearlbear on March 31, 2011

I didn’t make it to Drupalcon Chicago, but, thanks to the organizers of the conference, it doesn’t mean I need to miss the sessions. I’ve been looking through videos both the regular sessions, as well as the ignite sessions (thanks, @gregoryheller), and here are my highlight presentations (this does reflect what I’m interested in more than it reflects what’s the best of DrupalCon):

Tagged as: ,

Drupal/Salesforce Integration

by Pearlbear on March 23, 2011

A bit over a year ago, I wrote a post about the status of Drupal/Salesforce Integration. I figured it was time to do an update.

At the moment, if you want to integrate Drupal and Salesforce, you have three options:

  1. Use the contributed modules (or have a developer install and configure them for you).
  2. Use Jackson River’s Springboard.
  3. Roll your own (or have a developer roll your own for you.)

I’m going to talk in much detail about #1 in a bit. I’ve not had any experience with Springboard, but it’s important to understand that it is not open source, and is only maintained by one shop. That is going to be an inherent weakness – no matter what. I don’t know enough about it to match it to the contributed modules, but it’s hard to imagine that it’s possible for it to keep up, given the nature of open source development. All of that said, it’s supposed to be an interesting all-in-one sort of option, so it’s probably worth a look.

Rolling your own is always a precarious proposition. I frankly can’t imagine much of a situation where  it would be preferable to modifying what’s available and contributing the mods back.

So what is the status of the Drupal modules? Right now, there is an alpha release for Drupal 6, which is alpha in that very humble open source sense – it’s being used in quite a number of production sites. It includes some great stuff. You can see an overview here, in the slide deck for a talk given at NTC last week, which compares the integration of Salesforce with 3 of the big open source CMS platforms, Plone, Drupal, and Joomla.

There are four major projects:

  • Salesforce Suite, which includes:
    • The API – the core module that does the communicating with the Salesforce API
    • Contrib – a module that provides support for import/export from contributed modules
    • Export Queue (experimental) for queuing exports
    • Import – importing data from SF
    • Match – for matching objects before creating new ones
    • Node – for linking Drupal nodes to SF objects
    • Notifications (experimental, sort of – it’s worked quite well for me) – allowing Drupal to handle SF outbound messages
    • User – matching users to SF objects
  • Salesforce/Ubercart – provides integration for Ubercart. Uses the Salesforce Suite API
  • Salesforce Feeds – allows for feeding SF records into Drupal via Feeds. Also uses the Salesforce Suite API
  • Salesforce Webform – Allows for passing data from a Drupal Webform to Salesforce. Currently does not use the Salesforce Suite API, and cannot be used on the same site as the Salesforce Suite, but hopefully that will change soon.

All of these modules are actively maintained, there is an active base of folks using and contributing (including me) and there are plans afoot for Drupal 7, with big improvements. Of course, there are still some snaggy spots, and it helps if you know some about Salesforce to have this work really well, but I’ve gotten good results doing two-way sync of user and node data with the Salesforce Suite, as well as used the Salesforce Feeds module some.

If you use Salesforce, want integration, and are pondering a CMS choice, definitely check out the overview slides. If you are using Drupal, want integration, and considering a CRM, definitely consider Salesforce. And if you are already using both, and looking to find ways to integrate them, drop me a line, I can either directly help you, or point you in the direction of folks who can.

 

 

Tagged as: , , , ,

{ 2 comments }

WordPress vs. Drupal … fight!

by Pearlbear on February 15, 2011

As a user and developer of WordPress since 1.x something, and a developer and user of Drupal since 4.7, I figured that with the release of Drupal 7, this would be a great time to do a comparison of the two.  If you want a really detailed look, please read the very exhaustive, recently released, updated Idealware report on OpenSource CMS, which includes Drupal, WordPress, Joomla and Plone. I did the research for the original report released a couple of years ago, so it’s been a while since I’ve come back to comparing these two platforms. Also, this is primarily going to be from the developers point of view, although I’ll talk some about user interface and experience.

(A caveat: I have more experience, especially with larger sites, in Drupal than in WordPress, so there are things that I may be missing. Feel free to make comments on what I got wrong.)

WordPress started out with a focus on ease of use for bloggers and content creators, and secondarily providing a platform for developers to build plug-ins and such. WordPress was born as a blogging tool, primarily, and has expanded outside of that realm, to encompass different kinds of content management use cases. Drupal started out primarily as a web content development platform, with a strength in community features. A focus on ease of use didn’t come about until Drupal 7.

At this point, both Drupal 7 and WordPress are pretty easy for end users to add and edit content, and do pretty simple administrative tasks (moderate comments, etc.) They both have a very nice array of canned themes available to use, and they both have some customizable themes (themes that make it easy to customize without needing to know much HTML or PHP – like Thesis) available. Getting a site up and running in both platforms is pretty easy, although neither are really ready for non-techies to take on. That said, most good webhosts have one-click installs of both CMS platforms.

WordPress still has only two content types: Blog Posts and Pages. You can’t have different kinds of pages, or different kinds of blog posts, or some other content type (news, events, etc.) that aren’t one or the other. That is a deal-breaker for many kinds of sites. There are plug-ins that allow you to create custom content types – I haven’t tried these, so I can’t comment, but it seems a big deal that this is core for Drupal, and an add-on for WordPress. And it seems that this, and the absence in WordPress of a way to easily control the way that lists of content are presented and viewed are the major platform differentiators. That said, many, many websites need neither of these features.

And if you want to get more deeply under the hood, both platforms require some understanding of the respective platforms (how plug-ins work in WP, how modules work in Drupal), and probably a bit of PHP, HTML, or AJAX to add bells and whistles to the theme. Given some big changes in the core of Drupal, such as adding fields to nodes, as well as image handling in core, some things are much easier dealt with in Drupal  7 than previous versions, getting close to the ease of use of WordPress in that regard.

Kinds of sites probably best done in WordPress:

  • Blogs
  • Community Blogs
  • Simple brochureware websites

Kinds of sites best done in Drupal:

  • Large community sites where you need different kinds of content generated by users (blogs, wikis, job postings, etc.)
  • Complex, document-heavy library sites, or sites that need document management
  • Sites where you want complex control over multiple content types – how they are created and viewed
  • Magazine/Newspaper like sites where you want to control how lists of content are displayed and ordered
  • eCommerce sites
  • Sites with deep integrations to CRM platforms and web services

Kinds of sites where it’s a tossup:

  • Medium or large websites with lots of content, but relatively simple organization
  • Community blogs with many authors and identified, authenticated users

Bottom line: They are both such amazing, solid platforms, with rich, deep ecosystems of plug-in/module developers, implementors, designers, etc. that it’s hard to go wrong picking either platform, as long as you are clear on the feature set needed.  They have rock-solid core development teams, security updates, and over all good code, which you could hardly say about either platform 4 years ago.

Also, I have to say, as much as I have respect for other Open Source CMS platforms, IMHO, 98% of websites can be served by either of these platforms. That’s what’s true right at this moment. 3 or so years down the pike, I’m going to be looking at platforms based on Ruby on Rails – as Rails gets more mainstream, and solid CMS platforms start to mature, that will be the space to watch for. But that’s another blog entry, isn’t it?

Tagged as: , , ,

{ 24 comments }

What Drupal and Salesforce have taught me about coding

by Pearlbear on June 30, 2010

I’ve been spending a fair bit of time in the last couple of years learning to code in a new way. It reminds me of a transition I made in coding from having written stand-alone applications for varied computers, to writing code for the web. When I was in college, grad school and early in my academic career (this dates me – from the early 80s to early 90s), I spent a lot of time writing stand-alone applications, mostly in Pascal and C. The shift from that kind of code, to writing for the web was a lesson in protocols, constraints, and different ways of troubleshooting.

The transition from writing free-form web applications, to writing modules for Drupal, or APEX customizations for Salesforce, is another set of lessons in protocols and constraints. First, it’s not enough to understand the syntax and form of the language (this is especially true for APEX – and beware the required test coverage!) One has to understand how the surrounding application works – what APIs or methods one can use, and how. And unlike long standing languages, there aren’t lots of detailed cookbooks and that sort of thing lying around – a lot of it is learning from other folks, as well as just learning by trial and error.

And, in my small forays into learning frameworks like CakePHP, Ruby On Rails, and others, it seems like these days, coding for the web is many lessons in constraints – which is a good thing, I think. Even though it feels like beating my head against a wall, it’s nice to know that I won’t “dump core” and break Salesforce (although I for sure have broken Drupal on occasion!)

Tagged as: , , ,

{ 1 comment }

Amazon S3 for web server backup

by Pearlbear on June 30, 2010

I’ve been getting to know Amazon S3 lately, and there are some great things about it. I think it is one of the long list of unpredicted successes that resulted from the near-ubiquitousness of open source software on the server side. We’ve been using it for “offsite” backup for drupal sites for a while now. We have a script going which runs by cron daily to do the backups.

There are a number of ways to do this. We started using S3fs as a way to mount an S3 bucket in the filesystem, then just copy the files to S3. One of the scripts we’ve use is here. (We also use rsync.) However, S3fs isn’t very actively supported or in development. So we’re thinking of moving to use S3cmd, which works really well, and is still under active development.

Tagged as: , , , ,

{ 4 comments }

Why use contributed Salesforce modules for Drupal?

by Pearlbear on March 24, 2010

Lobo’s comment on my post yesterday prompted me to complete this blog entry that I’ve been ruminating on for a while. I wrote a blog entry a while back on the state of Drupal/Salesforce integration. What I didn’t say is that a number of shops that have done Drupal/SF integration for production sites chose not to use the contributed modules – they built (or are building) their own custom Salesforce/Drupal integration modules.

A few months ago, in preparation for a couple of projects, and a big push into this area for our company, I was faced with a strategic choice – go it alone, and build our own integration module for client projects,  or plunge into using and working with the contributed salesforce modules. Truth is, it wasn’t really a choice for me – I’ve got using and contributing back to open source projects in my DNA somehow. Although we certainly could have chosen, like others, to go our own way, we have committed ourselves to using, and contributing to the modules on drupal.org.

What we lose:

  • Complete control over development process and direction
  • Not having to fix other people’s bugs in order for stuff to work

What we gain:

  • Not having to reinvent a number of wheels
  • An easier upgrade path
  • Build on the work of others
  • Collaborate and learn

The work done so far on the modules is really solid – and it’s getting better. There is a great new maintainer, and increasing activity and contributions. There are also a number of other module integrations (like Ubercart, Webform, and FeedAPI) that are moving forward. Integrations with Views and Actions are also moving being considered (it’s instructive to look at the issues queue). This is stuff that would be hard to match, and makes building integrations for different kinds of sites easier.

So beyond just my own personal preference, I think that there is much benefit, both for our clients, and for us as a company, in hitching our wagon to theses contributed modules instead of going it alone.

Tagged as: , , ,

Drupal 7

by Pearlbear on March 16, 2010

I’ve been doing a bit of playing around with Drupal 7 in my copious spare time (not a whole lot of that!) I’ve also been keeping track, a bit of how the development process is going, and what things will look like. One thing to say – it feels like as big an improvement as Drupal 6 was to Drupal 5.

Of course, mostly, Drupal is only as good as it’s contributed modules (that’s a bit more of a stretch, now, because many of the key contributed modules, like CCK, are now in core Drupal.) So when folks like us, who build sites that depend on Drupal 7 can start using it is a bit up in the air, although there is a movement to get many modules ready for Drupal 7 at it’s release. But some may well not make it. We’re guessing that we’ll start building production sites in Drupal 7 starting in late summer, early fall, depending on requirements.

A note: the standard process for deprecation of old Drupal versions is that when a new version of core comes out, the one two versions back stops being officially supported. So Drupal 5 will no longer get security updates and the like. Already, many module developers have stopped supporting versions of their modules that work on Drupal 5. (The salesforce module maintainers recently made that decision, as have others.) So certainly a site running Drupal 5 won’t stop working, but it will become vulnerable without security updates to core or modules, and it will get increasingly difficult to maintain and add features to. So it might be a good idea to budget the time and money to upgrade as soon as possible if you are on Drupal 5. If you are on Drupal 6, you’ve got a while yet, but Drupal 7 certainly has some great advantages, particularly in user experience, to look at.

Tagged as: , ,

Drupal Commerce

by Pearlbear on February 17, 2010

Although it’s not often used in nonprofit settings, the Drupal module (or, more correctly, a large suite of modules) called “Ubercart” is a pretty amazing tool if you need to create a shopping cart system. We’ve implemented it for organizations that want to sell fees for events, sell items, and take donations. It doesn’t have many of the strengths of CiviCRM, but it has a lot of useful features if you want to sell things, or combine selling things with taking donations, memberships and selling event tickets.

A while back, I’d heard of the Ubercore initiative – a group of developers working to bring Ubercart to Drupal 7 (there was quite a delay between the release of Drupal 6 and the availability of Ubercart for Drupal 6.)  That initiative is now called “Drupal Commerce. (other site here.)” It is basically meant to be a rewrite of Ubercart for Drupal 7. It looks to be something to watch. Gregory Heller of CivicActions wrote an interesting conceptual piece on the integration of Drupal Commerce and CiviCRM that’s worth a read. (By the way, there is a module done by DharmaTech that integrates CiviCRM and the current Ubercart.)

Tagged as: , , , ,

{ 1 comment }

← Previous Entries