Reasons why to host or open your store through us

We offer eCommerce hosting for you at less than a fourth the cost of companies like eBay. BigCommerce, Magenta and others

We use Drupal 7 as the base site - the most flexible and powerful open source CMS system currently available - meaning ther is actually a huge support staff out there working on keeping it all ruinning well and we are the the interface to them.

First there are some honest things you should know about Drupal.  Let us start with its shortcomings

6. Drupal is a heavy resource hog.

Under the hood, Drupal has a really powerful hook system, which auto-detects and auto-loads functionality. All a developer has to do is follow a specific naming convention, implement a specific hook, and the code gets auto-discovered and called in the appropriate spot. This power comes at a cost -- Drupal has to load every single enabled module on every single request to see if it implements a necessary hook. Since PHP is process-based and doesn't have any long-running threads, this means there's a performance hit.

On low-end commodity hosting, there may not be enough RAM available for the web server to load a large Drupal site. And there is NOT - a user is at the mercy of the hosting company they go with - unless they opt for a VPS system.  Generally one needs to allow PHP to use at least 128MB per request, and on some large sites running lots of modules, even more. If you only have a couple GB of RAM available, you could run out with 20 active requests.

Fortunately, hardware is relatively cheap, and with the various caching strategies typically used with Drupal, obe can get sites speeding along. But this does mean you need quite a bit more hardware to run a large site than you would with a static site or a leaner, more efficient framework.  This does not even begin to address issues with modules that may be poorly written or supported - if "supported" at all.   Meaning often no one answers your issue.

5. It's PHP.

PHP -- is easy to learn, easy to understand, and pretty powerful. But it has a number of flaws. Historically it has had a slew of security problems due to a bunch of convenience things that went so far as to conveniently include remote code in every request, if you passed a certain GET parameter! These are pretty much a thing of the past -- PHP 5 did away with most of the glaringly easy ways to hack PHP sites. But PHP has kept the reputation for having shoddy security baked in...

Two weaknesses of PHP: are no threading/inter-process communication, and very poor Unicode support. Lack of long-running threads, worker threads, or other things along those lines means that a huge percentage of the Drupal framework needs to get loaded on every request -- it can't just sit there in RAM waiting to get called. Drupal does not really have a way of registering functions that implement hooks -- it does cache many of them, but not all.

The Unicode issue finally addressed in Drupal 7.50 is now here but is complicated to implement - and most small hosting companies are not going to rush to do it.  UTF-8 has been around for way over a decade now, but PHP still cannot accurately tell you the length of a Unicode string. This is supposed to be fixed in PHP 6, but for the time being, this means doing much localization work in PHP involves having your own string management functions.

If you want to run an online business or presence - you just do not need to be a programmer to it too.

4. Version wars.

Drupal 7 is out and  Drupal 8 is the big push with little of no module support for what really matters. Drupal 6 and 5 is no longer supported. And we're still building most of our sites in Drupal 6 still has the most modules that worked well and cross upgrade modules if they exist mean other modules and ways to do things from Drupal 6 which is a really steep learning curve.

Drupal 8 isn't yet the slam-dunk answer. The reason? There are still a ton of very useful modules that are not yet even available for Drupal 7 -- and many that are not even close.to working right and worse they are semi abandoned or have such weak support it is enough to pull your own hair out,

Drupal has a horrible reputation for painful upgrades. I would say that's largely an issue of the past -- most module maintainers provide decent upgrade scripts, upgrades tend to happen with no data loss and very little functionality change.

But as a highly commercial platform (not proprietary, mind you, just used by lots of businesses) customers need to pay to get modules updated to the new releases, since most of the development of contributed modules is done by companies, who get paid to do the work. In fact this is the new Drupal model and the support forums and days of free support are waning. And as long as it's cheaper to roll out a D7 site, and few other compelling functionality reasons to upgrade to D8, not many clients are willing to foot the bill to get the job done.

3. Abandoned modules

Or worse, modules that get replaced by an entirely different approach.

In the early days of Drupal, most site building was done by people programming custom modules on top of the Form API and the various other parts of the Drupal internals. Enough of these were generalized and shared back to the community that the next phase was characterized by thousands of single-purpose modules -- install exactly what you need for each feature you want to provide, and perhaps need over a hundred on your site.

Now the number of modules you need is getting to be far MORE becasue feature of other modules are left out -- we have more general minimal sinlge purpose, extremely powerful modules like Views, Rules, Display Suite, Features, and Context. As a result, the single-purpose modules are becoming obsolete, and developers pretty much abandon them.

This is actually a good thing -- these power modules really let a site builder build exactly what they want. But they also each have their own learning curve abd bigs you cannot nail down easily -- it's not as simple to drop in and turn on the functionality you want, you generally need to configure the behavior you want after installing the power module. This makes the Drupal learning curve even tougher for people who just want a site -- if you don't know how to use the power modules effectively, you can easily get frustrated when you find exactly the module you want -- but it hasn't been updated for 2 years. Or if you've been using a module for years, and it's no longer supported -- and there is no clear upgrade path to something else.

This is where Drupal has both dropped the ball and  turned professional. Site building in Drupal takes a lot of knowledge to do rapidly. And that's not knowledge even the best non-Drupal developers can get quickly -- so much of this knowledge is very specific to Drupal. Knowing which power modules can address the shortcomings of Drupal core, knowing when it's time to drop in a power module, knowing how to use the interface -- these you can figure out. But how do you even know the power module exists?

Worse - there is sparse documentation with the module or it is wrong - or worse on the Internet the same module for Drupal 6 is the one everyone talks about and mixes up and you have to know when they are talking Apples to Oranges.

That's why good Drupal freelancers and shops are expensive -- they're in demand, and they can do amazing things very quickly. The answer for most people and companies is buy tge hosted solution in one place.  that is how Acquia now works where father Drupal now lives

2. Caching

Caching in Drupal is perhaps the biggest thing that mitigates the memory hogging, the performance issues, and so much more, making Drupal as fast as most any other platform out there. But it's also a curse.

In short, if your Drupal site is misbehaving, a surprising number of times clearing the cache fixes it. Drupal caches things at a lot of levels: during a request it caches every node it loads. The menu/URL system that drives every request is cached. Blocks and pages can be cached -- but by the time you reach the page level, you can no longer use caching if you have anything personalized on the page (such as shopping cart contents). Drupal also combines javascript and css into compact files.

Then there's system caching. We run a PHP opcode cache to get more out of PHP. We tune MySQL so that most of the database is cached in RAM. On some sites file-based caches are set up to skip Drupal entirely, or set up reverse proxies. And then there's Memcache for yet another layer of caching.

The problem with caching is making sure it gets regenerated when something changes. Generally the system is pretty good about clearing out changed data, but there are definitely lots of cases where this doesn't happen correctly.

Caching is really a band-aid for the poor performance of Drupal, the dark side of having so much programmer power. The upside is that it works surprisingly well, and makes Drupal competitive. But it takes knowledgeable system administration to get the maximum performance, or to scale to handle large traffic loads. And it is a source of quirkiness, a bit of an X-factor that can make problems harder to identify and locate.

If it is not obvious with Drupal being so database intensive - one MUST have solid state drives on the database server to get good performance.

1. "Drupal Developers"

How do you know if you've found a good Drupal developer? Lots of people claim to develop in Drupal, but there's a huge range in the quality of the result you get, and it's very hard to tell without working with somebody a while whether they know the platform well, or whether they're going to be learning at your expense.

We are all going to be learning at your expense. Development is about solving problems -- once they've been solved, they don't need further development! This is largely a question of experience, but there is an element of talent as well -- the talent to see where the crux of a problem lies, and be able to sniff out the heart of the matter. That is a talent, but more important is experience. We have learned a ton by making mistakes. We know how to roll out changes to production sites without breaking them (or at least keeping the broken time minimal). We know how to undo our changes if something goes awry. And things go awry in complicated systems more often than we would like. Experience has taught us to build systems to protect every move, much like a rock climber scaling a tough wall -- while there are a few "rock star" climbers who may free-solo El Capitan, most people who attempt that end up dead. Smart climbers use protection so that if they make a mistake, the rope stops their fall.

This is a general credo in any IT shop

Making changes in sites that are already live is quite similar, and to do this smoothly, the protections need to be there from the start -- you don't scale half the wall before putting on your harness and trying to find your ropes.

The problem with inexperienced Drupal developers is they don't know how to protect themselves from the future. In Drupal circles, there's a phrase "killing kittens" -- if you're modifying Drupal core code, that's what you're doing -- something terrible. And the reason is that the next upgrade will clobber your changes. There are safe ways of changing just about anything you need to do -- but "Drupal developers" who are just trying to get your site launched and don't care about long term consequences don't bother with doing it correctly.

Horror stories and complaints are plentiful and no one is listening

 

Most dont understand why a major version upgrade from another Drupal must be a royal pain in the ass! When only one thing, zero coding or anything works with a few clicks on aWordPress site.

It's because Word Press's engine is like a tiny Lego motor, so upgrades are a matter of snapping it out and snapping in a new one. They just don't change that much.

Same thing goes for changes within a major version of Drupal.

But when you go from one major version of Drupal to the next, it's like changing the entire kind of engine. Drupal 6 had a regular gasoline engine, peppy and good. Drupal 7 moved to a diesel powerhouse, capable of hauling big loads, but also a bit of a hog. Drupal 8 is looking like a hybrid diesel-electric engine, efficient, powerful, capable of powering 300-car ferries.

With each of these engine changes, you pretty much need to rebuild the entire vehicle to make the new engine fit, change the filtering systems for the fuel supply, and much much more.

Some say, storing everything in the database is the #1 reason Drupal is a problem. Trying to coordinate database versions among a team of developers across dev, staging and production environments is the single biggest pain point in developing a Drupal site. They think Drupal might actually be a decent platform when this problem is solved.

The problem is they do not realize there are only two ways for a computer to have long terms memory - ROM or Hard Drives.  If we have to explain the silliness of this kind of statement - belief then it is hopeless for you to read further.

The Features module is used to coordinate staging structural changes that are in the database, to export configurations to code.  It is a bit cumbersome, and doesn't cover everything -- but more and more it covers the vast majority of what we would want to deploy between different instances of the site.

Combined with drush to update or apply the features quickly, and git to merge in any conflicts, most database changes are completely manageable.

Drupal is challenging, but that's a flip side of the power and flexibility that comes from being able to change the data structure on the fly through the interface -- and with the current tools, a lot less of a problem, and why you do not want to try to "do this at home"

Others have said yhere are so many things wrong with Drupal they really have no idea why any decent company would use it.  They claim they tried it and  had numerous issues with it, a couple of which were:

- Modules not getting bug fixes / support, which then meant we had to delve right in and in some cases it would have been quicker to simply write the module ourselves.

- Flexibility, or rather lack of, primarily due to the terrible performance / heavy resource usage, we found it quite limiting in what sort of site Drupal was suited to, ideally it seems to be for content sites that have enough traffic to warrant a dedicated server and where most of the content is not updated that much so caching can act as a crutch. Which was pretty useless for a lot of "social media" sites which are updated a lot as Drupal's performance was simply unacceptable. Same goes for when we were being nice and doing say a site for free, for a small charity, they don't have the money (or traffic to merit) a dedicated server that Drupal seems to need.

- It is a badly written mess, not just in terms of code, but the actual mechanics of many aspects of it, for instance implementing the design, all our designers who are quite at home with templates / HTML, could not stand the bitty, over complex, all-over-the-place nature of Drupal.

In the end they went back to a framework, they perform better, are written better, they are easier to debug, are more flexible and once you've got a some basic common modules/plugins/admin written then they are quicker to develop with.

These points are well taken and frankly why you should not try to learn and sue Drupal yourself to run a site you do not want to learn to program as a hobby also.

Much of this is true -- modules getting out of date, heavy performance/resource needs, and some over-engineering in many places that make it more complicated to do things than should be necessary. With Drupal 7 some of these things got worse, not better.

But at the same time going with a framework gets you there quicker but with less power. If one is proficient and experienced building on Drupal, you can get a lot of functionality deployed very, very quickly compared to a framework.

The main reason to use Drupal is to get moderately sophisticated sites up and providing value to your organization quickly. To do this successfully, you definitely need to be very knowledgeable about what works and what doesn't, what modules to use and which to avoid, and when to just write some quick custom modules from scratch. But you also need to be knowledgeable about a framework to develop something solid there, too -- you have more work to do to get a moderate level of functionality built and deployed quickly.

For large custom sites, either Drupal or a framework can get extremely successful results, with different development challenges along the way. With Drupal, you're going to be dealing with caching strategies, memcache, custom modules -- but it certainly can scale up to the largest scale. With a framework, you have to build more (and if you're not careful can still end up with performance issues).

"- Modules not getting bug fixes / support, which then means you have to dive right in and in some cases it would have been quicker to simply write the module ourselves."

Oh no, that means you have to write some code yourself as well as understand the flow of the code and what the module does in the API

Having to the write the code yourself rather flies in the face of a major alleged selling point of Drupal - i.e - that there are all these modules that provide functionality saving you the time / effort, but of course that would require them to be kept up to date, which seems a big issue with the non-core modules.

Which leaves you in the position of having to write modules yourself, you can do that in frameworks, that are much better written, more flexible, can be run on half the number of servers (sometimes less) and are generally more pleasant to work with.  But . . . that is why "open source" is also called "open sore'

But before you can fix software, you need to know what its author intended it to do, which means you need a specification. And so many Drupal modules don't have one.  Compare with the documentation for an average Drupal module.

A complaint about missing bug fixes is one thing, but the question is if all the complainers who had to fix it themselves are then also contributing their fixes? Drupal.org is a community and after Drupal 7 something went wrong with it. I think that there are working drupal systems out there with bug fixes that are now never committed back to drupal.org. When the community breaks, then drupal.org breaks and we all suffer.

That is the state of Drupal today

That about sums it up. The biggest problem simply learning Drupal is dealing with modules used as examples in the learning books are out of date and not maintained. Then, when one learned the software, it is discovered that you will be spending and wasting a huge amount of time testing and maintaining modules. It is truly module madness, even with GIT.

It's not quite that simple. Yes, WordPress can make very nice user-friendly solutions, for their relatively simple problem of providing a blog/news/brochure site. But for any site more complicated than that, upgrades are never a simple button-push process -- at least not without carrying a big risk of something going drastically wrong.

Drupal has an entirely different philosophy of upgrades. Most Drupal developers (at least competent ones) are working on far more complex sites than a typical WordPress site, so the assumption is that upgrades should be done very carefully, in a test environment, with code management and deployment processes in place. Not a single button click-and-hold-your-breath type of operation.

In this context, a command-line solution is far more preferable -- it lends itself to scripting, automated testing, and catching things that break before they become embarrassing problems in a production site. To me, WordPress's single-button upgrade process carries so much risk in it and puts so much out of your control that I would be terrified to use it.

But I would say, stick with it -- Drupal 8 is becoming much more like other frameworks you may have used. In fact, it is basically becoming a Symfony application. Aside from becoming much more object-oriented than it's ever been in the past, there are a huge slew of improvements -- configurations managed in code, a REST server in core, page-wide context objects, an entirely new theme engine using Twig... really exciting stuff from a coding and site management standpoint.

No system is perfect, there are always tradeoffs. But if you're a coder who ran screaming from Drupal in the past, take a look at what's going on in Drupal 8 -- you might find a system worth revisiting!

If you are not a coder - you will find it WORSE

Drupal is not a screwdriver, or a hammer -- it's a professional tool that takes a long time to master.

In the hands of somebody experienced, Drupal can be a very quick, effective way to get a simple "business card" site launched. In the hands of somebody who doesn't know Drupal well, they're going to spend a lot more time figuring out the tool than it will take to build a site in an easier platform.

One can build and launch simple sites in Drupal, with content, in under 3 hours. And we're working on systems to roll out site skeletons in under a half hour.

If you gave me WordPress to do the job, one can certainly do it, but it would be like taking away a tablesaw and screw gun, and giving back a skillsaw and hand screwdriver.

It's not that Drupal is the wrong tool for the job -- it's just the wrong tool for novices. And professionals of all kinds generally bring their favored tools to the project, whether it's construction or web development -- if you trust the professional, you should let them pick the tools...

That is why you should host with us

English