WebEnabled - A solid service for Drupal developers (if you don't get how it works, keep reading)

200908041150.jpg

WebEnabled is really neat, so neat you have to give it a few minutes to sink in.

If you're a Drupal freelancer or web shop, you spin up new Drupal sites all the time. If you've been doing it long enough, you've probably figured out ways to make the process quicker and cleaner. If you've got a team, you've most likely established a system that allows multiple people to work on the same project. You've got a system for demo-ing Drupal to potential clients and for capturing your work so that you don't do the same stuff over and over. However, if you're considering adjusting your current workflow, have some gaps that need to be filled, or are starting from square one, then it's worth your while to meditate on what WebEnabled can do for a moment.

After signing up for WebEnabled, the first thing you'll want to do fire up an 'application'. WebEnabled has a one-click installer, which installs the latest versions of Drupal 6, Drupal 5, Drupal 7 dev or Acquia Drupal. While cool, a one-click installer is not novel in itself. What is novel is the feature set that accompanies the application. You can set up an app on a fresh .webenabled.com sub-domain, or link it up with your own domain. You can share applications with other users, which makes team-driven development a snap. SVN is also supported out of the box, if you roll with version control. Once you have your app set up, you can clone it. Imagine this workflow: You have a few different flavors of sites you work with, say blogs, e-commerce sites and social networking sites. If you start from scratch, you end up running the same configuration every time, installing the same modules, making some basic theme adjustments. If you've been doing this long enough, you've probably got a folder and database set up locally which you copy every time you start a new project. WebEnabled take this one more step: Fully automated cloning, complete with database config changes, a new database and new SSH account. Again, all this with just one click. It's hard to get simpler than that. After its cloned, you can continue to make improvements to the base site.

Okay, so we've got the ability to create a new site and clone it in just a couple of clicks. Perfect for solo folks, but what about managing default installations with a team? Here's one place where the number of options in WE is a little overwhelming, and detracts from the central awesomeness which is that if you want team-driven development, you can have it. For one, you can use integrated Subversion to manage team development with version control. Version control is a common solution to the problem of team development, but you can also connect different WE accounts to the same project to give several team members access to work with files directly.

The above feature set was enough to get me excited, but WE does one more really unique thing that I personally think is brilliant.

In the Drupal community, there's a lot of work sharing that goes on. Users contribute modules, themes, documentation, and support so that other users don't have to go through the same rigamarole that they did. Fixing people's problems is a two-way exchange. You help people, and earn a name for yourself, and perhaps meet some of your other goals (financial or otherwise). One thing I haven't seen is a good method of sharing base installations. Install profiles and the Patterns module can do something similar, but they take time that most folks don't have. People can package up distributions and share those, but maintaining a distribution is a daunting task that's difficult to do well.

WebEnabled allows you to publicly share your default installation, again with one click. What this does, in essence, is elegantly fill this missing gap for a community-based mechanism of sharing base installations. One doesn't need to go so far as to create and maintain a distribution, and updates made to the default install are automatically available, so there's no overhead in making the default install public. A WE account is required to initially import the default install, but because the free WE account allows up to 3 application installs, there's no cost to download. A public URL is given to a shared install, so you can promote the install however you'd like.

A plan is in the works to provide a marketplace so that developers have the option of selling their default installs. This would work in the same fashion as the free / premium theme model. Supporting this model means that people can actually derive some financial motivation to construct good default installs, and that could benefit the Drupal community and help users at all levels.

One more use case - Drupal training

One thing I think is worth mentioning is that WE is being used by at least one Drupal training firm to get their students set up and learning Drupal. It's easy, ubiquitous, and the only thing that you have to help people set up is an SSH browser of some sort. I can see WE being used for all kinds of Drupal training, both by instructors demonstrating, and students following along.

Criticisms and Concerns

From a User Experience standpoint, the interface assumes that you're a seasoned developer, and I think that might be a mistake, especially considering that students and new developers provide some really solid use cases. So, there are some gaps in documentation and some of the messaging was a little cryptic. There were several points during the initial setup where I asked myself 'okay, what's next?' Once I sorted those out, moving forward was reasonably clear.

I get the feeling that WE is still wrapping their head around their target markets. If I hadn't talked to one of the WE developers, the site wouldn't have called out to me to re-think the way I was doing things. It took a longer conversation to get enthusiastic about it, and to think about ways to incorporate WE into my workflow.

At it's core, WE is a hosted solution. While they've got a bit of a head start, with the open availability of Aegir, and with the Garden / Fields Acquia hosting projects, they're going to have some formidable competition in the marketplace really soon. WE is already stepping up their marketing, and that's good to see. WE has the opportunity to fill a real niche amidst some different rising options, but they will need to carve it out and perhaps even define it as they go.

My experience experimenting with WebEnabled left me pretty excited about its future. I can see that it's headed in a good direction, and it already has what appears to be a solid platform for creating default installs, supporting team-based development, and distributing the install packages. WE can be an awesome addition to a Drupal developer or firm's toolbox, and solves some rather difficult problems quite elegantly.



Comments

That's really interesting. This is the first I've heard of WebEnabled. Do their templates take advantage of Drupal's multisite feature? One-click installation is pretty hot, but having to update each one individually would be a bummer.

Hi Scott,

WebEnabled *can* run a multisite inside an application container (fancy way of saying vhost) just fine, and it can be cloned etc. However you cannot at this time clone one multisite instance - the whole vhost would have to be cloned together.

I agree with you on the downside of having to separately update each individual site (especially for instances with many multisite apps) - the flip side is the ease of managing and separately configuring each application independently. At the end of the day it's a tradeoff and the right answer will be different for everyone.

The good news is that if you configure your applications consistently, in theory you could automate your updates with some scripting and drush to reduce some of the time required to deploy updates...

Cheers,
-Jason

I've been using these guys for several months now and can't say I recommend them. Can't wait for Pantheon to open to the public!

Their vhost setup is weird. They run Apache as the account owner so if you want to remove file write permissions for Apache (as you should) you also have to remove permissions for yourself which means any time you want to do an update or add a file or whatever, you have to go and change the file permissions. Their facility for updating modules is terrible and the Drush interface won't work if the permissions are tightened as above. Note, the Security Review module barfs because of this issue as well. There's a button for Drush core update but what they don't tell you is it also updates every single module! WHOA! Not cool. So I just end up doing updates the old fashioned way.

Your website will have a 2nd URL that is an internal server address, but accessible from the web. I had to ask how to setup .htaccess so that webcrawlers wouldn't get confused by this. What a pain to fix.

The standard file manager is eXtplorer which in its own right is just fine, however it's not something you'd want to leave active on a live site. It is a PHP app that lives in the root of your site. At least cPanel ran separately on my previous host.

There's no way to determine how much disk space you have used. I have two Drupal sites configured, yet I cannot do a backup of the environment because I get an insufficient space error - on a 35GB account - huh? Also, if you do a backup/restore it effectively clones the site and in the process changes all the passwords and the internal site address, so you have to go and edit the changes you made to .htaccess, noted above. What a mess.

On top of all that, they are extremely poor at responding to issues, including twice now in one month where the server just stopped responding because allegedly I ran out of RAM (1.2GB burstable to 2GB) when there was virtually no activity - not at all a high volume site to begin with. They never responded to most of the issues outlined here - just flat out no response. On one issue, two people responded with opposite opinions.

Their servers are quite fast however. WebEnabled looks good on paper, but the whole idea is to offer a "push button" environment to save the headaches of Drupal server management and they fail miserably at that.

If Pantheon doesn't materialize soon, I'll be off to linode.

I'm surprised and dismayed that you didn't escalate these issues through our support. We'd be happy to help answer your questions and address some of the points you mentioned here.

I asked one of our sysadmins to address your concerns in this post. I hope this helps... If not, please contact support and ask to be put in touch with me, Salim Lakhani.

And if you do decide to move to Linode, we'd be happy to help you make the switch so your downtime is minimal.

Salim.

===================
"They run Apache as the account owner so if you want to remove file write permissions for Apache (as you should) you also have to remove
permissions for yourself which means any time you want to do an update or add a file or whatever, you have to go and change the file
permissions"
===================

The author seems to be familiar with shared hosting setup with
mod_php, which much less secure than ours. With such a setup, PHP
scripts are running as the 'apache' user, which means that they are
able to read the files of all all users of the server, not only the
files of the site to which the scripts belongs. As it relates to
write permissions, in case of this insecure hosting setup site owners need to make 'upload' directories world or group-readable, which means that any PHP script is able to write to upload directories of any site on the server, not only those of the sites to which the scripts belongs.

On "remove file write permissions for Apache (as you should)": again,
the author assumes that you "should" remove write permissions for
Apache in case of the insecure setup described in the above paragraph.

This policy results in a situation in which PHP scripts which belong
to other sites are unable to write to files which belong to other
sites, but are able to read such files, which could result in leaks of a sensitive info. With our setup, which the author considers insecure, owners of other sites (and their PHP scripts), do not have ANY access to files which belong to other site: neither read nor write access.

===================
"Your website will have a 2nd URL that is an internal server address, but accessible from the web. I had to ask how to setup .htaccess so that webcrawlers wouldn't get confused by this. What a pain to fix".
===================

The internal address is there for user's convenience and for
debugging... internal address access by web crawlers can easily be
disabled using robots.txt.

===================
"The standard file manager is eXtplorer which in its own right is just fine, however it's not something you'd want to leave active on a live site. It is a PHP app that lives in the root of your site."
===================

We do not have eXtplorer by default. There is a KB article
which describes how users can install eXtplorer if they would like
to. We recommend that you secure eXtplorer as you like. If you
want to remove it, then feel free.

===================
"There's no way to determine how much disk space you have used. I have two Drupal sites configured, yet I cannot do a backup of the environment because I get an insufficient space error - on a 35GB account - huh?'
===================

True. Some Dashboard pages displaying info about user's plan
do not account for {with backups, without backups, with backups full}options and display available disk space for 'without backups' option, whereas the default option is 'with backups'. So, when the users consult their plan info, they can see e. g. 'Small 35GB', whereas really it's 10 GB (with disk space reduced in favor of backups).

===================
"Also, if you do a backup/restore it effectively clones the site and in the process changes all the passwords and the internal site address, so you have to go and edit the changes you made to .htaccess, noted above. What a mess."
===================

Correct. Our 'restore' function really creates a new site, not
restores the contents of an existing site from backups. we are
going to implement a 'replace-vhost' function soon.

===================
"On top of all that, they are extremely poor at responding to issues,
including twice now in one month where the server just stopped
responding because allegedly I ran out of RAM (1.2GB burstable to 2GB) when there was virtually no activity - not at all a high volume site to begin with."
===================

We are not and cannot be responsible for application bugs of users'
applications which could result in excessive memory usage
even "when there was virtually no activity".

It is surprising to me that the Anonymous user above had such negative things to say about WebEnabled (WE). I think Salim's response above (he is the President WE) covers everything nicely - there's not much I can add to that.

But I'll try anyway... One point I will speak about is their service - any time I've had an issue, I've gone through the normal support channels (live chat support and filing a ticket) and have always received fast answers and/or resolutions.

In the spirit of full-disclosure, WE does sponsor a podcast I participate in, but we wouldn't say all the good things we do about WE unless they were true. They're a fantastic Drupal community sponsor and participant who are trying to make it easy for developers to spin up and manage dev sites (among other things!)

-mike

Ok, but the bottom line is convenience and it wasn't there for me. I ended up doing a lot of work I'd have to do on a typical VPS whereas I was hoping for a more push-button GUI that would save me time.

This issue with write permissions has more to do with malicious code on your own site that can then write to files, not so much with other sites on the server. If my site is compromised I don't want some script to be able to destroy or steal, so I disable write permissions for Apache. But once you do that, Drush and eXtplorer no longer work. I didn't see any other suggestions for supplanting eXtplorer save for cPanel which requires a license - but still, without write permissions, you can't do any file management.

On the recommendation of your security team, I had to add a special version of .htaccess that forced robots to observe the robots.txt file for the internal domain and not index duplicate content. But if I have to do a environment restore, this file has to be edited to reflect the new internal server address. More work.

The disk space issue is a joke really. I have no way of knowing how much disk space I have. With just two modest Drupal sites, I am repeatedly told I have just a few hundred megabytes left, and often don't even have room for just one backup (typically under 2GB). It doesn't make sense to me to reserve 25GB of disk space for compressed backups, for sites that use less than 10GB uncompressed. I also don't believe I'm using anywhere near 10GB. I think the system made a mistake and allotted the space for the original shared dev account, to the VPS. Nothing else makes sense.

If my site gets "Slash Dotted", or anything similar, I want to know that the host can absorb it without paying exorbitant fees for RAM I don't ordinarily use. But that wasn't the case for me. Twice in the last two months both sites I host crashed every 2 minutes citing insufficient RAM. An examination of the server and Drupal logs showed no unusual activity. Nevertheless the RAM condition persisted for 8+ hours. The real problem with server resources is that you have no tools for assessing and analyzing issues like this, and disk space too. So how can you keep the host honest?

I made several posts to the support forums and never got any response. Just go and look at the number of questions from people that get zero response. I sent numerous tickets for support that were hastily, and often poorly addressed, just like the response to this forum post - it reflects a "tough luck" attitude I just don't need. I need to save time and NOT have to deal with all these f@%$ing headaches. That was the premise under which I bought into your service philosophy - pushbutton ease.

The customer may not always be right, but if he's unhappy, you lose - a simple customer service concept that a surprising number of companies fail to understand. Part of it is the "software is priesthood" culture that often pervades geekdom. At any rate I'm actively searching out a new host.

Hey, I'm sorry to hear that you're unhappy... but you still have not contacted me about your issues. We'd be happy to refund the charges from last month, find you a new VPS hosting company and help you move. Email me at SL at webenabled. Salim.

I forgot to add that eXtplorer could and should be run as the Group rather than the Owner, but what about Drush? I can't control that.

What I'd like to see is a panoply of services in one place, with features like offered by Dropter, and server monitoring like from Nagios. Of course I can install Aegir myself, but better if it's all done for me. Pushbutton ease. Make it so I never have to do any setup or work from the command line. Make my job easier and I'll gladly pay top dollar. Time is money!