I’ve been working on finishing up a personal drupal project at Poodle Breeder Source.com, and have been working with Drupal on this project. This will be one of many Drupal projects I’ve done over the past 6 months, and I really love the flexibility of Drupal, and the large amount of modules that are already up and running.
However, I’ve been Extremely Disappointed in the capabilities for e-commerce with the system.
I’ve tried implementing several different modules that should handle the functionality that I’m trying to obtain, but have yet to get any of them to work properly for what should be quite a simple task, and as mentioned in this post, I’m not the only one that feels the ability to charge users to post a specific content type should be a core feature of Drupal.
Let me first explain a little more what my intentions are for the site. When a breeder comes to the site, and would like to list their services in the directory, they should be allowed to register, and create a single, or multiple posts of a certain content type in Drupal that will be displayed in a special section of the site for breeder listings. These listings should be hidden from the public until either the breeder has paid for the individual post (preferred method), or has completed an upgrade to their account type, which will then allow them to post unlimited times in the custom content type (non-preferred method).
I’ve tried the following modules, and will comment on the usability and problems I encountered with each one.
- e-commerce
- e-commerce is the largest and most robust module with all sorts of options to configure. However, using either current stable versions of 3.4, or even attempting their alpha release of v4, the simple paypal checkout never work properly, and never report back to the system using either PayPal’s IPN or PDT. Limited documentation on the individual portions/modules of this large feature set make it impossible to configure properly to work with PayPal. And the fatal omission of an uninstall feature make it cumbersome to remove.
- lm_paypal
- lm_paypal is a smaller module that is intended to handle the following according to the information: “This module provides an interface to PayPal using Instant Payment Notifications (IPN). It is designed to work with Drupal 4.7 (and Drupal 5.0.0 dev) and supports paid memberships (subscriptions), donations (tip jar) and paid adverts (classified ads).”
By definition, this module should have done exactly what I needed by using the paid advertisement module which allowed you to configure a specific content type that would require payment in order to publish live on the site.
Again though, a lack of documentation made this system impossible to set up properly, and reporting from PayPal was not authorizing the transactions, so the advertisements were never being published. This module looked like just the thing, but the dev team that put it together seems to either be completely incompetent, or rarely update the project. (Still listed in HEAD version)
- lm_paypal is a smaller module that is intended to handle the following according to the information: “This module provides an interface to PayPal using Instant Payment Notifications (IPN). It is designed to work with Drupal 4.7 (and Drupal 5.0.0 dev) and supports paid memberships (subscriptions), donations (tip jar) and paid adverts (classified ads).”
- paypernode
- paypernode is an addition to the e-commerce module that adds a product type where a user must pay to have the ability to post a specific content type. (PERFECT!!) However, through several installations this feature never worked properly, and combined with the e-commerce cart/PayPal issue mentioned previously, this has never worked properly unless manually assigning the paypernode credits to a user.
- paypalnode
- paypalnode was an interesting idea that never suited the proper purpose for my implementation, however, might work well for various other types of sites.
Rather than charging for a single node type at a set amount, the paypalnode module allows you to charge a fee for each category (Taxonomy) term that the post is applied to. So in this case, where taxonomy is being used to classify the colors & size of dog breed, the breeder would have to pay for each term, which isn’t really optimal in this case. Because of the limitation of functionality in this system I never made it to payment testing, so I can’t verify if it works properly in that aspect or not.
- paypalnode was an interesting idea that never suited the proper purpose for my implementation, however, might work well for various other types of sites.
So, needless to say, I have spent countless hours pouring over poorly managed code trying to avoid reinventing the wheel. But the wheels I’ve found are all flat and full of nails, so I’m left with a compromise in functionality by putting together a couple modules that DO actually work, and implementing some of my own custom functionality that will apply to this and other similar breeder directory sites coming out soon.
I’ve settled on the following modules, where they do work well for their purpose, but fall a little short in functionality I need, but are easily enough modified to my own purpose. However, the modifications are requiring full hacking of the modules, breaking me free of any further updates without careful comparison of the new versions and my modified code.
Fee is a Drupal Module with the following features:
This module allows an event web site to charge fees for attendance. There can be more than one level of fees, each with a different amount and different description. The module assumes that the entire site is for a one-time event, suitable for subdomains.
Views integration is provided, with several fields exposed to views, such as gross amount, net amount, currency, and whether the user has paid or not. Note that this requires the bio module so users are represented by nodes.
Bio is a Drupal Module with the following features:
The Bio module allows each user to create one (and only one) “bio” node. Any node-type can be assigned as the bio or Bio module can provide its own node type. The bio can display on the users’ profile pages and/or it can add “View [username]’s [Bio]” links to nodes.
Combined with CCK in Drupal 5, Bio module can provide a more flexible, more *efficient* solution than Drupal’s core Profile module. If you’ve wished that user profiles were complete first-class nodes — available to your content search index, available to nodeapi-based modules, and themable through node-[bio].tpl.php, then Bio module is a quick-and-simple way to go.
So, after combining these two modules, I’m left with the problem of a user only being allowed to create one bio/listing/advertisement/profile, which in some cases could need to be more, but by changing the pricing model, and functionality in categorization options a breeder would have, I can live with this.
The major additions that are being implemented on top of these two modules are the ability for expiration dates / and notices to be sent to users regarding their listing being expired. Cron setup to automatically remove expired profiles, and other such features.
After all this work, I’m freaking pissed that a fantastic product like Drupal isn’t including a decent feature to allow for this built in. There are only a handful of Drupal modules that weren’t put together by idiot programmers, and that actually work well right out of the box, are heavily documented, and supported. All the rest are hack jobs by amateur programmers with a barely sufficient knowledge of modular programming, and Drupal in general.
Get with the program Drupal, and include PayPal IPN support, and paid nodes in your system. This is a huge feature that can be easily modified to TONS of needs that arise when building a site.
0 Responses to “Drupal 5 & E-Commerce Setup Woes”