Planning on doing an ESL site, what modules should I use?
joemer - July 5, 2009 - 14:05
Hi, I am planning on making an ESL site where a teacher can post lessons and quizzes and some parts are only accessible by paid students. Payment maybe on a monthly basis. Should I use drupal for this? And what modules should I used? Thanks.
At the moment Drupal's
At the moment Drupal's multi-lingual capability has some very serious flaws and limitations. I am an EFL teacher, and would not currently use Drupal for such a site unless you are an expert in php/SQL, so you can attempt to fix the language bugs yourself.
> Payment maybe on a monthly basis
If you want to take credit card payments, be aware that it is expensive. The cheapest solution I've encountered (until you begin to take more than twenty thousand dollars/euros annually) is currently google checkout, which takes 3% of each transaction with no fixed monthly fees. After twenty thousand, a proper 'internet merchant' account probably becomes more viable. However I don't think there is a google checkout module for Drupal. Thus, you might have to manage your customer's access/permissions manually.
Also, taking payments means that you'd probably want to use the 'private' file-system method. Be aware that this method breaks some of the modules that you may be relying on to handle the very files you're trying to protect.
I do think it is possible to build such a site with drupal, and in fact there are one or two I already know of, but I suspect they had serious financial backing and a duo or team of full time professional developers. If you're just a teacher looking to make some extra cash by providing your expertise and resources online, then I think this type of website would be an extreme challenge, especially if you are working full time as well. I've just spent an entire year building a multi-lingual website for my school (700 hours). It was a very time consuming and frustrating experience, and there are still many aspects of it that don't work properly or aren't as easy for the user as they should be. However, I should add that none of the other top 5 CMS software solutions would have done it better either.
To clear up some
To clear up some misconceptions (although they're really not relevant to the OP):
1) Google Checkout *is* available in Drupal, with Ubercart. Has been in there for more than a year.
2) PayPal does *not* require you to pay $30/month to accept credit cards. I've been accepting credit cards through PayPal for almost 10 years, and never once paid a monthly fee.
3) The issue of how "expensive" a payment method is has no bearing on whether or not to use Drupal for this task - you are stuck with the cost of the payment processor regardless of what CMS you use, or even if you code your site entirely by hand.
4) "private" files are a red herring - both Ubercart and eCommerce have their own file download mechanisms that let you control access to your downloadable files. Neither interfere with Drupal's normal file handling.
5) i18n may be a red herring as well. Just because he's selling ESL materials doesn't mean the site is targeted at more than one language. Think about it...
In short, there are numerous ways to accomplish the OP's task in Drupal, and it would be both cheap and easy to do. Not at all the huge expensive challenge -Anti- makes it out to be.
<tr>.Please note that TR's
Please note that TR's response appears near the top of this page but is actually also in response to certain posts below, which are chronologically before his above post.
Well put.
I would add that PayPal doesn't require customers to create a PayPal account--customers can simply enter credit card information and pay that way.
--
CiviHosting - Drupal Hosting at its Best
> Google Checkout *is*
> Google Checkout *is* available in Drupal, with Ubercart. Has been in there for more than a year.
Not listed here: http://www.ubercart.org/payment
Not listed here: http://drupal.org/project/ubercart
And http://drupal.org/project/uc_google_checkout is only for D5
> PayPal does *not* require you to pay $30/month to accept credit cards.
OK, conceded.
After looking at the paypal website I see they have a standard account and a pro account.
The website I used which compared several gateways was wrong, outdated, or intentionally biased.
> The issue of how "expensive" a payment method is has no bearing on whether or not to use Drupal for this task
It would if there wasn't a drupal module that supported the newest, cheapest gateway.
> Just because he's selling ESL materials doesn't mean the site is targeted at more than one language
He's not selling materials to other english speakers to use in their lessons. As far as I can tell the site intends to supply learners with teachers and resources. People who are learning a new language still need things like interface and instructions in their first language. Only the lesson and exercises should be in the target language. Unless the students are at an advanced level, you can manage a lesson utilising only the target language if you are there in person to give other cues like alternative explanations, gesture and realia.
> "private" files are a red herring - both Ubercart and eCommerce have their own file download mechanisms
Conceded, if you're sure about it. I thought the ONLY way to protect files was to keep them above root? Thus any privacy solution would use the same mechanism as the drupal file system and *still* break modules that weren't specifically written to take it into account?
> Not at all the huge expensive challenge -Anti- makes it out to be
I stand by my advice. If this is a teacher wanting to make extra money, and wants to develop the site whilst still working full time, and is new to drupal, I still think building such a site is an extreme challenge. I'm an EFL teacher. I have GB's of resources. I know dozens of teachers who would use an LMS if it earned them some spare cash. I've just spent every moment of my spare time in the last year building a school website. AND I WOULD NOT EVEN DREAM OF BUILDING AN EFL/LMS SITE, EVEN AFTER A YEAR OF USING DRUPAL; IT IS SIMPLY TOO DIFFICULT/TIME CONSUMING/FRUSTRATING. By suggesting it's easy, I think you're being misleading due to your blinding loyalty to drupal, or perhaps because you have forgotten how difficult it actually is for beginners.
Anyway, instead of attacking my response, why not actually answer the question; go ahead and tell the OP what modules he should use and how easy it will all fit together?
First of all, I'm not
First of all, I'm not attacking you, I'm correcting some incorrect statements you have repeated several times in this thread. From these statements I can see you don't know a lot about Ubercart. I do, so I know these statements are wrong, and I want to make sure that the casual reader of this thread does not come away with the wrong impression about Ubercart's capabilities.
To address your specific points:
Google Checkout is in Ubercart core and is currently included with all versions of Ubercart, both D5 and D6. It is not an add-on module. It does not have to be downloaded separately. It originally started life as a contribution, but was moved to core a year ago. The link you point to is for the old, out-dated contribution.
"the newest, cheapest gateway" is a purely subjective description. I can tell you that neither Google Checkout nor PayPal is the cheapest. Google Checkout isn't even the newest (take a look at Amazon Payments, for example - an Ubercart interface to this is just about to be released). Nor does "new" bring any advantage - I'd rather have an old, established, proven payment gateway anyday, since it's my money they're dealing with. Regardless, both Google Checkout and PayPal have a number of faults. There are detailed discussions on ubercart.org about this if you're interested. Ubercart supports maybe a dozen different gateways, allowing you to pick a payment processor that is appropriate for your needs.
I understand that. You missed my point, so let me be more explicit about it. I said "Just because he's selling ESL materials doesn't mean the site is targeted at more than one language". The point you are missing is that i18n is used only for the case where you want to present the same content in more than one language. It is *not* needed if you simply want to make a non-English website, or if you want to mix content (some English, some non-English) that doesn't get translated.
Let's take a concrete example. If his customers are Spanish speakers who want to learn English, then his website (menus, taxonomy, shopping cart, etc.) will be in Spanish. Instruction will be in Spanish and show equivalent English words or phrases, quizzes, audio clips, etc. At no time do you want to *translate* this content into another language. English lessons for Spanish speakers will make no sense if translated into Russian, for example. Nor do you want to translate the website interface into something other than Spanish if your customers are just Spanish speakers.
The only time i18n would come into play is if you are selling ESL materials for more than one primary language. That is, if the web site had one set of materials for Spanish speakers wanting to learn English and another set of materials for Russian speakers wanting to learn English. In that case, the website interface will need to be available in more than one language, but all the ESL-specific content will by necessity be unique and will not require i18n. It is for this exception that I said "i18n may be a red herring as well" (emphasis added).
Your repeated stated assumption is that the OP is an individual with limited resources. In which case it is unlikely he will be running a virtual Berlitz out of his basement. Much more probable is the case I laid out with one primary language, where i18n is completely unnecessary. As for the exception, you probably *still* don't want i18n, because you will be selling to entirely different markets and the overlap in content will be minimal. I'd do a multisite installation, personally.
As for ease of use.. When I was looking for shopping cart software almost two years ago I saw a post somewhere on the Internet that mentioned Ubercart. I looked it up, downloaded it, then found out I needed to install Drupal first (I had not heard of Drupal before). So I downloaded and installed Drupal, then installed Ubercart, then started learning. By the end of the first day of playing with the software I had a functional store with 50+ products entered (copied from my old web site), and 100+ pages of information (also copied). Plus I had a partial port of my website theme (that took weeks to get it to work the same across different browsers, but that's another story...). ONE day from nothing to a fully-functioning store. It's even easier than that these days, because of fine books like Using Drupal.
Let me repeat my first post in this thread, in case you overlooked it:
"To answer your question, the Ubercart module for Drupal allows you to sell access to parts of your site. Ubercart also allows you to sell downloadable files. Ubercart also lets you sell subscriptions and make recurring charges."
In short, what he needs is Ubercart. Period.
<tr>.> I want to make sure that
> I want to make sure that the casual reader of this thread does not come away with the wrong
> impression about Ubercart's capabilities.
Perhaps you should get them to fix the project page and documentation then, because I based my information on that. If you're worried about misconceptions, the project page has far more influence on people's perception of ubercart than individual forum posts. But I do appreciate your verbose post assuring us that google checkout is indeed natively supported by the D6 version of the module.
Well, the OP certainly has contrasted opinions to base a decision on:
On one hand, his site will be easy and can be 'done in a weekend', he won't need to use multi-language, and the cart, which is handling subscriptions to the site, will also somehow protect all his uploaded resources.
On the other, it will likely be difficult and challenging, and may take hundreds of hours to get the language, permissions, file system and file handling, and cart to all work together properly.
I wonder which is closer to reality, and which is closer to the fanboy propaganda that this forum is infamous for? If I ever do build an EFL site and it turns out to be as easy as you suggest, I vow to post an apology here.
_
When presented with two opposing opinions it is likely the "truth" lies somewhere in between. However, in this case, much more relevant will be the skills of the person untertaking the site-- which, again, the op does not mention. You've made an awful lot of assumptions in your replies that are not supported by the op. That doesn't mean they're incorrect, but at this point, unless the op posts back, there's no way to know for sure and speculation is just that-- speculation.
Also, I don't see anything in TR's posts that would indicate "fanboy" to me-- however, in any case, the opposite of "fanboy" is just as incorrect. I'd like to give the benefit of the doubt and assume you genuinely want to help people Anti, but I frequently find your posts overly negative, completely bound to your particularly narrow vision of the ideal use case, and sprinkled with incorrect information presented as "fact" (ie there's no way to protect files while using the public file system setting). If drupal is so inadequate in your opinion, one has to wonder why you bother with it.
In any case, there's really no cause to get hostile with someone for pointing out when you've posted incorrect information. Personally, I very much appreciate being corrected-- the very last thing I want to do to an overwhelmed newbie is send them on a wild goose chase because of incorrect information on my part.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
OK, let's end this
OK, let's end this discussion. But first:
· I only answered this thread because I had some things in common with the OP:
- I am an EFL teacher.
- I have also been using drupal for a year like the OP, and have built one site, like the OP.
- A few days ago I did some cursive research regarding payments, because a friend had a business idea.
If it wasn't for those things I wouldn't even have touched this thread.
I expected for others to make their own contribution and opinion, and perhaps disagree with me.
I did not expect this kind of attitude.
· My original post presented very little as fact. Look at the phrases:
"...a proper 'internet merchant' account probably becomes more viable. However I don't think there is a google checkout module for Drupal. Thus, you might have to manage your customer's access/permissions manually. Also, taking payments means that you'd probably want to use the 'private' file-system method. I do think it is possible to build such a site with drupal, but I suspect they had serious financial backing and professional developers. If you're just a teacher looking to make some extra cash..."
I think it is quite clear that I'm giving MY opinion based on MY experience of Drupal.
· I was quite angry due to Hershel's condescending, unnecessary posts.
I mean seriously, did you READ that bullshit? Can anyone blame me for taking offence?
So I was understandably overly-defensive toward TR.
> and assume you genuinely want to help people
I have tried to contribute to about four questions for every one that I have to ask.
In other words, I've posted to 800 threads, but less than 150 of those are my own questions.
However, after this unpleasant experience I don't think I'll be doing that any more.
At the moment Drupal's
Could you clarify some of these flaws, limitations and bugs so that we could address them? To randomly claim that there are "bugs" doesn't help anyone.
I am uncertain what exactly this comment is supposed to mean. I have built many sites with Drupal that take payments and no modules have ever been "broken."
There is no need for that. There are ready-built ways to automatically handle paid-for memberships in Drupal and while there may be no Google checkout module ready today, there are several other checkout options which work quite well. I have used them, including for the purpose of paid-for memberships and in my experience they work just fine.
To address the original question, doing paid for memberships can be done in Ubercart or eCommerce. Once you have that, then limiting access to certain pages or sections of your site can be handled by various permissions-enhancement modules.
It is true, however, that Drupal is not necessarily an easy system to master for a beginner--there is definitely a steep learning curve initially. Hiring a professional to setup a complicated site is often the most efficient method of beginning with Drupal.
--
CiviHosting - Drupal Hosting at its Best
> Could you clarify some of
> Could you clarify some of these flaws, limitations and bugs so that we could address them?
> To randomly claim that there are "bugs" doesn't help anyone.
Are you trying to suggest that there are no issues in the i18n or locale queues?
All I am stating is that there are some bugs listed there that are potential show-stoppers, and
some that will cause very large headaches when designing a site where language is CENTRAL
to the site's purpose. I'm sure many would agree with me.
If you are looking for bugs to fix, then I'd really appreciate being able to translate my horizontal
primary and secondary menus. Block titles are also currently untranslatable.
> I am uncertain what exactly this comment is supposed to mean.
> I have built many sites with Drupal that take payments and no modules have ever been "broken."
Paying for downloadable files means you need to protect them using the 'private' file system.
According to the issue queue and forum posts, the private file system breaks some file-handling modules.
> To address the original question, doing paid for memberships can be done in Ubercart or eCommerce
Yes, but the supported gateways are extremely expensive if you are only taking in a couple of thousand of dollars, as a new language site would in the first year. The cheapest one, google checkout, is not yet supported by the carts, and so there will be no interaction with drupal's permissions.
I'd really appreciate being
Excellent. Pointing out specific issues will be helpful for the original poster. He was, you recall, asking for advice to help him make a decision as to whether or not to use Drupal.
Now we can see what you are trying to point out. What you are attempting to communicate is this:
====
If you plan to use downloadable files as your "protected resources" then you should be aware that there are some modules which will not work in conjunction with this. Of course, if you plan to simply use nodes for protected resources, then you should have no problems at all.
====
This is also more clear now. What you are trying to share with us is this information:
====
If you want to use the very cheapest option for a payment gateway, that being Google Checkout, then you must handle memberships manually. If, however, you are willing to invest a bit more in an alternative gateway, then Drupal will handle paid memberships for you automatically. So you must consider which is more valuable to you--your money or your time.
====
--
CiviHosting - Drupal Hosting at its Best
> He was, you recall, asking
> He was, you recall, asking for advice to help him make a decision
> as to whether or not to use Drupal.
Currently he has no idea what a primary menu is, how it is translated, or how
that might affect his site design. So why, at this point, go into details? All he
needed to know was that multi-lingual sites currently have serious limitations.
So, are you going to follow me around the forum and rewrite all my posts, then?
I don't know who you think you are, but I don't appreciate your uninvited, pious
condescending 'corrections' to my posts.
If the OP doesn't understand something I've said, let him ask.
If you have your own advice to give, then write your own post.
Otherwise, kindly mind your own business.
You've made me really rather angry.
_
I don't really want to jump into the fray here, but I just need to set the record straight regarding one important item: you do not need to use drupal's "private" file system setting with ecommerce.
The OP doesn't mention anything about selling files (nodes can be protected in other ways that have nothing whatsoever to do with "private files") which, afaik, would be the only reason for considering using the "private" drupal setting-- and there are other (imo, better) ways to handle access restricted downloads that don't involve the drupal "private" setting.
EDIT: also, for simple payment acceptance that only requires paypal, the http://drupal.org/project/lm_paypal module is a nice simple option.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
> The OP doesn't mention
> The OP doesn't mention anything about selling files
As an EFL teacher, and I can't imagine a language-teaching site that doesn't have downloadable
worksheets and resources for the students; audio resources, for instance, are extremely important.
The point made was, you can protect the node content, but you can't protect direct-linking to a
file without using the 'private' files system, as far as I know.
However, I will concede that students can legitimately download resources and then just torrent them.
So the private file system doesn't add *that* much protection. If the resources are good, they'll be
illegally shared whatever protection is in place.
> there are other (imo, better) ways to handle access restricted downloads that don't involve the
> drupal "private" setting
I'd be interested to know what they are, because I need to protect our school files from direct linking
but I couldn't use the private file system due to module conflicts.
> the http://drupal.org/project/lm_paypal module is a nice simple option
Accepting credit card payment with paypal costs 30$ per month + 3% of each transaction.
A standard paypal account (3% for each transaction) doesn't accept credit card payments.
The customer has to:
· create a paypal account
· transfer money to their paypal account
· transfer money to the seller's account
· the seller has to bank-transfer it to his account.
Google checkout saves 360$ a year, and more importantly, is more trustworthy than paypal.
_
Regarding public/private, i currently use the method described at http://www.drupalcoder.com/story/406-mixing-private-and-public-downloads... though there are a couple of modules that try to make this easier (downld and private_upload).
As for my paypal comment-- i never said it was cheaper, I said it was simpler. Many people are put off by the complexity of ubercart and ecommerce-- especially for just taking membership payments. I merely point out that for paypal only payments, lm_paypal is a viable alternative.
As for google checkout --as with anything else in drupal, when someone who needs it puts forth the effort and/or funding for a module it will be upgraded/created.
_
Don't be a Help Vampire - read and abide the forum guidelines.
If you find my assistance useful, please pay it forward to your fellow drupalers.
Hi, I am planning on making
To answer your question, the Ubercart module for Drupal allows you to sell access to parts of your site. Ubercart also allows you to sell downloadable files. Ubercart also lets you sell subscriptions and make recurring charges.
<tr>.Thanks
Thanks, for your inputs, I'll try to do what I can. Thanks.