Stranger in a familiar land: Comparing the novice's first impression of Drupal to other PHP frameworks

Drupal 8 adoption is flagging. Why? I tried to lay my biases and assumptions aside and set out to find the answer. What I found surprised me.

I decided to perform an experiment. Placing myself (as much as possible) in the shoes of a senior developer without any Drupal experience, I attempted to get a new "Hello World" site up and running in four different PHP frameworks: Wordpress, Laravel, Symfony, and Drupal.

I set a few ground rules for myself:

  • Start at square 1. Google "Drupal" (or Wordpress, etc.).
  • Use only information found organically via my Google search and subsequent clicks.
  • Take the path of least resistance. In other words, choose the easy way when more than one option exists.
  • Avoid the command line when possible.


  • Time required.
  • Number of clicks in web browser.
  • Number of CLI commands run.

I do not claim that this experiment was purely objective or scientific. The fact is that I do have plenty of Drupal, PHP, and CLI experience and I'm not a good representation of the average Drupal novice. However, I think that the exercise did provide a rough sense of the developer experience.

My system setup before beginning:

  • Operating system: Mac OSX 10.13.3
  • Installed libraries:
    • PHP
    • Git
    • Composer
    • Vagrant
    • Virtualbox
    • MAMP (MySql, Apache, PHP)
  • Presumed knowledge/skills:
    • Ability to create new VirtualHost entry in Apache (via MAMP)
    • Ability to create new MySQL database (via MAMP)
    • Ability to use CLI to execute basic commands (cd, cp, mkdir, git) and to copy and paste commands from docs.

TLDR; these are the results:

Broken into 3 categories:

  1. Creating a site via path of least resistance
  2. Creating a site explicitly on my local machine
  3. Creating a site explicitly on a free, organically discoverable hosting provider

Creating a site via path of least resistance

Framework Clicks Commands run Local Total Time
Wordpress 7 0 no 1:14
Symfony 3 3 yes 1:55
Drupal (pantheon) 11 0 no 5:04
Laravel 3 9 yes 17:28

Creating a site on local machine

Framework Clicks Commands run Total Time
Symfony 3 3 1:55
Wordpress 7 0 7:51
Laravel 3 9 17:28
Drupal *20+ 0 *15:00+

* Spoiler, I gave up counting clicks and reading docs on after 20 clicks and 15 minutes.

Creating a hosted site

Framework Host Clicks Local Total Time
Wordpress 7 no 1:14
Symfony (heroku) 10 no 4:21
Drupal (pantheon) 11 no 5:04
Drupal (acquia) 8 no 16:34

Wordpress is a clear winner for the fastest and simplest setup via the path of least resistance, which is (no suprise) on a hosted service. Symfony was the clear front runner for setup on my local machine.


Hosted Site

In each case, setting up a new site with a free hosting provider (when available) proved to be the simplest solution. But, the experience of doing it with Drupal was the least intuitive.

Drupal is the only framework that made me choose a hosting provider and navigate through a hosting UI to find the framework's homepage. I was presented with the choice between Patheon, Acquia, and 1&1. As an (imagined) Drupal noob, I had no idea which to pick and I was tempted to veer off course to research the providers.

Instead I chose Pantheon purely because it was the first option listed. I later learned that the ordering of hosting providers is randomized. With Pantheon, I was walked through an 11 click and 5 minute process that eventually dropped me onto the homepage of my new Drupal site. I decided to try the Acquia path just for fun. 8 clicks and ~16 minutes later, I was back on a Drupal homepage. This process was not without some consternation.

With both Pantheon and Acquia, I found myself in the unexpected territory of a hosting provider's UI. In the case of Acquia's UI, it took me a full minute of staring at the screen before I could determine which link would actually "get me into Drupal." This blog post describes the experience well (with screenshots).

If I hadn't already been somewhat familiar with both Pantheon and Acquia, I would have found it bewildering to navigate through a landscape of environments, servers, and workflows before even seeing Drupal. It left plenty of room for improvement.

Let's move on to the experience of setting up a new site locally.

Local site

In terms of the technical setup, both Symfony and Laravel had superior developer experiences, primarily because both provided out-of-the-box development environments.

Symfony had a surprisingly easy set of instructions that did everything from create the project to launch the web server in less than 2 minutes. Wow. I wish Drupal would replicate that. We have a lot to learn from the Symfony community. I didn't need to think about LAMP stacks or VMs at all.

Laravel on the other hand, provided a ready-to-go Vagrant box for my needs. While somewhat weighty and complex, it was wonderful to have a clear go-to solution that just worked, albeit slowly. I'm not a huge fan of Vagrant, but I am a huge fan of plug n' play.

Wordpress and Drupal had similar setup experiences from a technical perspective. Both required a tarball download and the configuration of a LAMP stack. For many developers, particularly those new to PHP or those on Windows, LAMP stack setup isn't trivial. It can be a serious impediment to require that users first research, choose, and set up a LAMP stack. It reminds me of Carl Sagan's quote "If you wish to make an apple pie from scratch, you must first invent the universe." It feels like you need to invent the universe before building a Drupal site.

Choosing and providing a standard solution for this, as Laravel and Symfony have, would be a great improvement. Drupal claims to be developer focused, but Symfony and Laravel do a much better job of enabling developers out-of-the-box.

But let's move on to the biggest and most interesting difference.

The biggest difference

The experience of navigating Drupal documentation as an (imagined) novice was confusing, frustrating, and ultimately demoralizing. After 20 minutes of clicking back and forth between various conflicting and competing documentation guides, I was seriously questioning whether I even wanted to finish this blog post.

I'm going to give a play-by-play of my user experience, and wrap up with a summary with the underlying issues that it reveals.

I began by Googling "Drupal" and clicking on the first organic result, I spotted the "get the code" link pretty quickly and followed that with a click on "Download Drupal 8.4.4". A little redundant, but I wasn't feeling annoyed yet.

I was taken to the release page for Drupal 8.4.4, which was filled with release notes, known issues, and a slew of information that was irrelevant to my purposes and somewhat overwhelming. Ignoring 90% of the page content, I clicked "Download tar.gz" and then hunted down the sidebar content to find "Learn how to install Drupal". I've already clicked some form of "Download / get code" three times at this point, but I'm feeling like I'm almost done. If only.

I land on the Installing Drupal 8 section of the Drupal 8 docs guide, the first line of which reads:

"Chapter 3 of the Drupal 8 User Guide covers server requirements".

I ask myself...

  • "Am I not in the Drupal 8 User Guide? "
  • "Is that a different guide?"
  • "Should I read that instead?"

I decide that I should follow the link. This takes me to Chapter 3. Installation of the Drupal 8 User Guide which is a completely different set of docs. I think to myself, "this is weird, but I'm going to go with it." I also notice that I'm on Chapter 3, which means that I may have skipped over important information.

I decide to start at the beginning and visit Chapter 1. Understanding Drupal. This is filled with information on Drupal terminology, licensing, data types, and architecture. In fact, there are 19 sections that preceed the Installation chapter. I am decidedly not interested in learning this yet, I'm just trying to get a basic site running! My experiences with Wordpress, Symfony, and Laravel did not subject me anything like this as a first step. I'm going to abandon the background info and go back to Chapter 3.

I encounter "3.1. Concept: Server Requirements", which gives me an overview of various types of web servers, including Hiawatha and Microsoft IIS. I'll skip over that and get down to business. Next is "3.2. Concept: Additional Tools," which tells me all about Drush, Git, Composer, Devel, Drupal Console, Coder, and other tools. I still haven't found any instructions and I'm starting to doubt that I made the right choice in following the Drupal 8 User Guide to get a quick start. I decide to go back to Installing Drupal 8 section of the Drupal 8 docs guide, where I initially started.

I'll start with the first section, "Before a Drupal 8 installation". This contains a preamble with the words:

Documentation for Drupal 8 on is found in two separate areas... The basic differences between the two documentation areas are discussed here.

I decide that I'll click the link because I do want to know what the hell is going on with the documentation. I'm rewarded with the following choice snippets of text:

if you are trying to find a clear step-by-step guide here at (d.o) to achieve exactly what you want to do, (first of all, "Good luck,")


Which guide you should start with? I can not answer that, since by all appearances to me, the documentation at d.o has all the appearances of being a war waged on two fronts.

and a literal cry for help:

If you, like me, cherish daunting challenges, and welcome the prospect of helping with what I loosely, and comedic-ly, refer to as the 'train wreck' that the d.o documentation is... And if you find pleasure knowing you have made contributions which help thousands of people, without a need for gratification from others... Help.

Are. You. Kidding. At this point the farce is wearing thin. Drupal is a great framework and I've been proud to be a contributor and member of the community for many years. As I go through this exercise, I'm becoming embarrassed on behalf of Drupal.

I decide to just push forward. Read the docs, install Drupal, and go take a walk. I continue reading "Before a Drupal 8 installation". I don't get halfway through the section before I am told to see another guide on Local server setup. That guide has 10 chapters of its own each with multiple sections. There is no way I need to wade through all of that to get a Drupal site set up. Forget it, I'll just use MAMP since there is no clear recommendation or clear path forward.

Before I even leave the "Before a Drupal 8 installation" section, I encounter this text:

h1. Three Drupal sites per live site

By the way, when you have a live Drupal site, you will at times have a total of three Drupal sites running on your computer or web host.

Ignoring the fact that I'm reading a section that starts with "By the way," this is just wrong. No one runs 3 versions of the same Drupal site on their local machine, and those who have multiple environments in the cloud may or may not have three of them. Why is this section even on a "Before a Drupal 8 installation" page?

Why would a "Before a Drupal 8 installation" page contain this:

Before you do make changes to your live site, you will want to grab a copy of your Drupal codebase, and your Drupal database, and use them to create a backup site to make sure you have what you need to recreate your live site as it is in the event that your changes to your live site go horribly wrong, for whatever reason.

You can, of course, delete the 'backup' installation after you establish that your backup codebase and database are 'good', but be sure to keep at least three separate sets of that codebase/database set, in three separate locations.

Three separate locations mean separate online companies or separate USB drives/hard drives in separate locations. This will prepare for a disaster: for example, a fire at your home/place of business, or one of your online storage facilities getting hacked into.

I just wanted to install Drupal. I'm 20 clicks into a rat's nest of documentation, I've stumbled across three different guides, one apparent documentation war, a suggestion that changes to my live site may go "horribly wrong," and instructions to place my non-existent Drupal site's backups onto three separate USB drives stored in geographically disparate locations in case of fire or hacking.

I stopped counting clicks at this point and restarted the exercise using the knowledge that I already have. Even then, it took longer than getting WordPress set up locally (for the first time ever).

Honestly, if I were evaluating Drupal, this experience alone would make me choose a different framework.


As compared to other popular PHP frameworks, the experience of setting up a new "hello world" Drupal site as a novice is uniquely difficult and frustrating.

The first major roadblock encountered is documentation, which is sprawling, conflicting, redundant, and disorganized. To compete with other frameworks, we need to have clear, concise, and consolidated documentation that explicitly indicates the recommended/supported/official way to do things. I understand that Drupal is flexible and allows us to do things in infinite ways. It's not unique in that way. We can still provide clear instruction.

The technical process of setting up a Drupal site isn't the worst, but also not the best in any category. It lacks the "out-of-the-box" tools that Symfony and Laravel provide for getting quickly spun up on a web server, and it lacks the simplicity and speed of Wordpress.

I think that Drupal can be a framework for ambitious sites and also one that is a joy to use, even for novices.

We need to ...

  • Improve our documentation.
    • Docs should be clear, concise, and consolidated
    • Docs should explicitly indicate the recommended/supported/official way to do things
    • Docs should be both curated and very easy to contribute to
  • Provide an official, documented, out-of-the-box solution for spinning up new Drupal sites quickly and easily on a local machine.

I am frankly hesitant to jump into the fray and help solve these problems. The scope of the technical and documentation problems isn't intimidating. The fact that there are many stakeholders and a pre-existing controversy is intimidating.

To be successful, we need coordination from the Drupal Association to make changes on We need buy-in from the community to support an "official" solution for local development. We need collaboration from the Drupal User Guide maintainers and the Drupal 8 Guide maintainers.

Given those challenges, I'm hesitant. But I'm still willing to give it a shot.

If you're in a position to help address these challenges, contact me. Let's fix this.

Drupal is very developer focused. So should the documentation be written for the developer - in which case assumptions must be made about what knowledge they have - or for the beginner - who may or may not have development experience?

By putting so many eggs in the composer basket, we now support the old way of developing and maintaining Drupal websites, and a new improved way. So how should the documentation cover things like module updates?

Deployment as a process with various environments for development and testing is a good development practise. Is it the responsibility of the Drupal Association to document those too?

I don't have the answers to these questions, but I have thought about them, especially as there are developers in my team who are new to Drupal and have struggled with understanding it after reading the documentation pages.

So should the documentation be written for the developer?

I think we could set some ground rules.

  • The primary audience should be site builders. The secondary audience should be developers.
  • Top level documentation can address both audiences, but information meant for "developers only" should be clearly marked as such.
  • We should never document more than 2 ways to do something in top level documentation. The third, fourth, etc. ways should be on separate pages. Providing too many options is counter productive.

This would only work if the docs were curated and not simply a "free for all," as is the case now.

Deployment as a process with various environments for development and testing is a good development practise. Is it the responsibility of the Drupal Association to document those too?

Let's start at the beginning. If we get to the point where we have already improved the docs for all of the basics, then let's examine how far the scope should be extended.

In reply to by grasmash

Telling site builders they should just read the api is not helpful, but is usually the advice most often given.

SB's just want to get something up and running.

I think the Umami Installation Profile from the Out Of The Box initiative is a great demonstration of how things could/should work for site builders.

and current documentation for developers outside of 'read the api docs' is hit or miss on most things.

Yup, that post pretty much sums up my experience.

Been a professionnal WP dev for 7 years now, but my boss wants to have another tool to our arsenal, so trying to learn Drupal.

Going from Beginners guides to other Setting up your first drupal guides, running scripts that I have no clue what it does. I can't make what is what. Its confusing, nothing seems to work, and the god damn twig templates that take forever to update are crap.

Really, it's completely demoralizing. I should try the same exercise with WP, but right now I'm wondering how anybody does anything with drupal.

In reply to by Frédéric Pilon

I'm kind of in exactly the opposite situation: I've been a professional Drupal dev for 7 years now and this year started trying out WordPress to see what the fuss is about. WordPress is a wonder to work with having come from Drupal, I often find myself thinking "wow, doing this was such a pain to do in Drupal" when discovering the ease of adding functionality. To further drive this point home I now built, launched and operate two WordPress sites now in only ~3 months of using it.

The only thing I miss really is Views. I know you can do custom queries in WP but it'd be really nice to have a UI to generate and manage them like Views. That being said, there is still functionality in Views that is a complete mystery to me because it is poorly documented.

I totally agree! The output to efforts ratio is very low for drupal. I don't even understand how it can sustain the competition this way. It really needs to level up on improving exactly the experience you've covered here.

Drupal console seems to step towards improving upon this experience.

After almost exclusive Drupal development for over five years I have spent the last two years developing exclusively with Laravel and Symfony (I am a contractor and these are the projects I ended up with, I have have development experience in other languages and frameworks prior to Drupal).

Searching for help and information whether official documentation or unofficial has been SOOOO much more productive with Laravel and Symfony. Symfony in particular the free books and documentation are so good I think that is why there are so few Symfony books relatively speaking. The barrier to entry to writing a Symfony paid for book that actually adds anything is much higher.

My Gawd...thank you for doing this. This is Drupal's elephant in the room, and it has been for years. In my opinion, there should be a fully-fledged, first-class Documentation Initiative for core, just like the Media Initiative or Out of the Box Initiative, with all the support those initiatives enjoy.

Some random thoughts about what this could consist of:

* Official documentation should not be editable by any random person. There should be specific documentation maintainers, and they should be mentioned in MAINTAINERS.txt. All documentation changes should be run past subsystem maintainers first, then the documentation maintainers, who verify that the changes being made are accurate, well-organized, well-written, and properly proofread.

* Documentation should be a commit blocker. If your patch will introduce a feature in core, it should have approved documentation changes before it is committed. (Committers could then publish the pending changes once the corresponding feature lands in core.)

* Documentation should include liberal use of screenshots and video. Documentation maintainers should be able to kick documentation changes back for lack of supporting images/videos.

* People who work on documentation should receive full-fledged commit credits. Documentation is holy work and needs to be as prestigious as contributing code. There are many contributors who would do a killer job of documenting, if it wasn't such thankless, second-tier work.

* A Documentation Initiative should be concerned with making the proper changes to that would facilitate a good documentation workflow. It would probably need to have two phases: first, to decide how official documentation will work and be governed, then actually implementing that.

* Official documentation should be typographically attractive. Nothing sucks worse than walls of text in an ugly font without enough spacing. If there were a Documentation Initiative, it should have at least one web designer creating and implementing a consistent style guide.

This was tough to read because I, like you, have made a career out of working with Drupal. I’m pessimistic that anything will be done to fix things without a massive coordinated effort.

This is a very sobering post. Thanks for putting this together.

In reply to by Justin Winter

You can't make a 'massive coordinated effort' to fix anything until someone admits something is broken. People are so busy patting themselves on the back and proclaiming how great Drupal 8 is, no one is even beginning to look at what it will take to fix it.

Requiring composer to do something a basic as adding an 'address' type field to a basic site is ludicrous. Yet anytime time someone points this out, they get shouted down about how to correctly do dependency management.

The latest asshat decision to require react for admin screens is no different.

The BDFL model is breaking down-- the emperor has no clothes but everyone in the 'circle' is busy telling him how beautiful his wardrobe is.

I'm a quadruple Acquia certified Grandmaster Developer who's been using Drupal exclusively since version 5 and have yet to do a Drupal 8 project. I keep waiting to feel the need to-- and I just don't.

And the more then venture capital backed BDFL forces decisions on the community the less I feel like contributing anything back.

So keep whistling past the grave yard...

Thank you for writing about this. I think the Drupal Association needs to take more ownership of this problem. Writing documentation by committee just doesn't work, because you end up with the mess that you went through. I don't think any community member should be able to add to or edit documentation, at least not unless it's done through pull requests and a proper review process. We need leadership here.

Why not put a Helpsystem in Drupal, with links to Descriptions or YouTube movies (like in the Webform Module)
Just an idea.

I totally agree with these points. You have made a very professional research on the topic. Drupal documentation is a pain as also as installing a Drupal site.
By the way, except from Pantheon, Acquia and other online services to try Drupal there is also the fresh one (I am the owner of it) which is similar to but allows to spin a Drupal Distribution in seconds.

As part of this issue: we try to attack this problem. We hope the endgoal is to have just a single command to be executed which sets up everything you need, from a webserver, databbase to Drupal itself.

Feel free to chime in there and report how useful it would actually be to have some an ease of setup.

Thank you so much for this sorely needed article. No wonder Drupal 8 adoption is flagging. And should you have made it through installation don’t think updates are clear and concise either. For starters you have four options. I installed a test site on a LAMP stack on a Windows machine with Composer and thought it would be easy. The page describing the fourth option for updating with Composer starts with the warning “This documentation is incomplete.” Sure enough the commands for updating modules and the database are given, but it’s so incomplete I can’t find the command for actually updating core!

I think the reasons for Drupal 8 adoption flagging are different. Every senior developer will be able to insall Drupal or Wordpress in a few minutes. Possibly, slow adoption is caused by the fact that destroying Drupal as a CMS for small sites and making it harder to use for slower businessed has created bad PR that also makes it less desrable for larger businesses as well. Drupal strategists thought that they will quietly drop support for small websites, but will attract better develoeprs and larger projects. Instead, they have lost a part of the community, created negative PR, that has in it's turn hit the adoption of version 8 as a whole. I think that was the worst miscalculation, that continues to bring Drupal market share down even now, when it is at last usable and chieseled up.

In reply to by Alexei Raiu

I agree that this likely isn't the main reason that Drupal 8 adoption is flagging. But, I think that it's a contributing cause.

I agree that we should work on making Drupal better for smaller sites, and I think that means making Drupal much more usable "out of the box." However, tackling docs and the local dev stack seem like necessary prerequisites for lowering the barrier of entry. We should then (or in parallel) work on a host of other issues that also affect adoption.

I've only been seriously pursuing Drupal for around 2 years now and it's been quite an experience. I am definitely a front-end/designer type so I hate setting up my dev environment. I have found 3rd party websites or conversations with individuals to be much more helpful than the d.o documentation in almost every case.

I wish there was a quick-start guide designed for someone like me who came from a WP background and just wanted to get something up and going. I tried a ton of different ways to get started and wasn't sure how to make any of them really work well until I found my current process. I tried Drupal console, MAMP with a manual installation, Vagrant, a bunch of different command-line methods that involved a copy/paste of a long long command and then hoping that at the end of it a functioning site would emerge, nothing made sense and I never saw how to transition my local work to a live site until I started using Kalabox.

I know Kalabox is no longer in active support and that really makes me sad, but here are some of the reasons it makes things super easy for a beginner:
-GUI that allows for a new user to click a button and create a new site. If the author was able to download Kalabox, he'd have a site up and running in a few minutes like WP and it would be pretty simple. I just created a new site on my computer and it took 3 clicks in Kalabox to do it. I know hardcore devs prefer the command line, but it took a long time for me to get comfortable on it because I never touched it before Drupal. Having a GUI meant that it was clear, obvious, visual, simple. Want a new site? Click the big "Add a new site" button.

-It did everything invisibly. For someone coming in totally new who just wants to start up a Drupal site and play around with it, it's perfect. You click the "add a new site" button and, without you knowing about it, Kalabox is spinning up a Docker container and configuring the database and everything else you need. When I'm ready to understand that stuff, I can dig into it. But if I'm just going to try out Drupal, I don't want to spend a couple days understanding the best way to configure my local environment before I even see the home page of the site.

-It's got presets for different flavors: Backdrop, D8, D7. If I'm new and I want to try out some of the different ones, I can easily try creating sites and if I want to delete them, no big deal.

-It's got integration into Pantheon which allows me to get an understanding of the multiple layers of the dev process: (local/dev/test/live). It would be great to have this level of integration for other hosts, but at least having it for Pantheon makes that process really nice. Previously, I hadn't worked in this way so this has helped me as I've been growing in my skills and processes.

I really just feel like the best thing about Kalabox is the fact that it's visual and simple. For someone who is coming in new, and even if they're comfortable with the command line, having something straightforward, a couple clicks and they are getting their new environment up and running, and knowing that they have a real, robust environment, not just something that they'll necessarily need to change later, I think it makes everything that much more polished.

There’s a lot I agree with in this blog post. Quite possibly one of the most significant things we can work on to grow adoption is the experience of a new Drupal user.
That experience is made of many things; code yes but docs, governance, mentoring, etc have greater potential?

I really enjoyed reading your post, laughing out loud at times (which I rarely do). I am often in a position where I'm expected to onboard PHP devs or themers with little or no Drupal knowledge. I set up a Docker-based "starterkit" at which is meant to get new devs up and running with a fully configured ready-to-use site in 1 command, albeit a command-line command (./scripts/

In reply to by howard

I agree that Drupal adoption is flagging, but Google Trends does not demonstrate this accurately. All Google Trends shows is searchability and popularity in searching topics. If you want to review actual adoption trends you should review real install data from services like or

Everything in Drupal 8 requires more code and takes longer to develop. That's not progress in my book.

It's conceivable the community could split and fork Drupal 7.

While there are a lot of resources wit different options around the internet about starting to use Drupal (on local or on a server) it is really sad that our official documentation is so confusing. :(

Worth to mention too, that I always thought (and I do) that it is an own goal that (which luckily seems to be survive after patrick_de's – who worked on it for years – quit ) is not recommended on the Try Drupal page. See:

The more WP sites we get, the more Drupal stands out a superior product to me in every where. 15min to set drupal up is nothing if its going to save you 40 hours compared to a WP site in the end.... The only thing WP has on Drupal are it's drag and drop page builder tools, I can't think of anything else. All i come up with a list of Drupal functionality that isn't present in vanilla WP installs. We are constantly coming up with PHP workarounds for WP functionality from prior WP devs because they dont follow standards, I always feel like the walls are closing in on WP, because of how hardcoded and outdated the app is.

In WP you will find multiple plugins for the same functionality whereas in Drupal, devs team up and merge projects. Because in Drupal it's about the community and a hi-fidelity DX while Wordpress is all about ME, and it caters to novice users. Drupal 8 is an amazing product, and the reason adopting is slow is because there is a lot of low level PHP "devs" out there. Drupal 8 development involves knowledge of PHP, OOP, and general programming concepts, which makes it a fucking blessing for me, but for shitty WP devs they will struggle because they are use to outdated hooks procedural WP mess. Drupal is more powerful out the box and I don't need to add a bunch of a plugins to get standard web functionality which should be included with all CMS as of 2018.

And with my server setup with composer it takes about 2mins to set up a full d8 site from start to finish with CLI. So yeah. Have fun with your WP.

Commenting here as I did on Twitter.

We at the DrupalConsole project, are trying to make the user experience with Drupal more simple.

For this case. You can use DrupalConsole `quick:start` command and have a fully working Drupal8 site almost as fast as with Symfony. It will vary depending on your internet speed and how long composer delay to resolve dependencies.

Link to the original tweet to check the images

DrupalConsole also provides the `site:new` command to download Drupal asking you for the project to clone from (drupal/drupal, drupal-composer/drupal-project:8.x-dev, acquia/lightning-project, acquia/reservoir-project)

This may interest you as well. another example of what are we doing. How to try 8.5 and umami fast and easy using one command.

Thank you. Thank you. Thank you! You've written what I've been experiencing and thinking for YEARS. Drupal is a great piece of software, but WHY does it have to be so hard to get started with? I've been using Drupal since about 2006. I've been using WordPress also (since the original version release). WordPress TROUNCES Drupal when it comes to these types of issues, as illustrated in your article. I would PREFER to use Drupal for my client projects, but it doesn't make sense, if it takes me 5-10 times as long.

I've been working with Drupal for over six years, and it's been a deeper progression.

First from content strategy and design/UX, then step-by-step into planning, designing, and managing ever-larger projects from the ground up.

From an architectural/code standpoint, I can well understand the major changes needed for Drupal 8, but the on boarding experience certainly needs help. At the time of my first ground-up D8 launch, I had built over 10 sites in D7, of various complexity.

So, it should have been fairly straightforward to get a D8 site (and a small one at that)—right?

Unfortunately, not the case. For me, it was also a frustrating search from a number of disparate sources on getting the build stood up, and then on properly deploying. Now that I have it under my belt, it's far easier, but this shouldn't be that frustrating. Many potential users would have given up had they had to face the same challenge.

As someone who organizes Drupal Meetups, and advocates for the platform in the design community (where Drupal has a long-standing negative impression), vastly improving the onboarding experience is imperative to growing the community and improving Drupal as a whole.

Ignoring non-expert users in the process will be to the detriment of the whole community.

Impressed with the level of self reflection here. Seems like plenty of opportunity and ideas to resolve what is really not that hard of a problem.

We've been talking about this over the past few months as well, especially when comparing to the initally-simpler JavaScript ecosystem (as it ignores setting up databases and web servers that you often need for a real site). It turns out PHP's built-in webserver has come a long way, and drush makes it very easy to get going as long as you avoid the GUI installer requirement and importing a real MySQL database from a production site.

This is something I've been noticing for a while now. What is the most likely reason someone is going to take the route of least resistance? To test a product. Having better documentation only hides the primary problem, that the installation is unintuitive.

So why not have a download on the home page with a simple built-in server, built-in database, one click install that sets up the basic site? Make it a simple choice: I want to try Drupal. Ok, which industry are you in? Publishing. Here's a preconfigured site for you, sir. Now that the user could see and test this preconfigured site (a distribution, if you will - I will get to this right away), he can choose to use composer, he can choose to create a site from scratch, hell, why not run a site in docker? But that's not what the initial download is about.

Now, distributions aren't a bad thing per say, but they suffer from a similar problem than the old Symfony Standard Edition did - they might offer too much or too little, depending on needs and they aren't readily configurable. What they should be instead is Drupal's version of Symfony Flex - recipes for features that I can add to my site with a single command. If I can install a site with a click and then customise it as I see fit from there, the learning curve is substantially easier and the required documentation reduced.

Reply from Dries, including ideas to improve:

I am an experienced drupal developer/site builder/ linux admin. Have run and created many drupal 7 and a few drupal 8 sites; but debugging composer errors has been a nightmare. Installing drupal used to be so easy. Configure apache, create a db, make sure drush was installed, git clone of drupal 7 or scp a tarball and I was up and running in 10 min or less. Now there is composer and all of it's require files, the documentation is crappy, the people helping really don't want to help and when long time drupal enthusiasts complain about drupal8 they are not taken seriously. If I put a drupal8 site on a server with drupal 7 sites then drush 8 or 9 doesn't work with drupal7. Drupal 8 doesn't respond to ubuntu's apt-get drush.
So I'm going to put drupal8 on its own server either with docker or whatever pre-built solution is on drupalvm. I am sad that this is the direction drupal has taken. I was happy not to have to navigate Pantheon and Acquia for any of my sites, as I saw friends really struggle with those platforms if they wanted to do anything more complex than an 8th grade school project. Our company has migrated some sites to word press. So easy - I had it up and running in 5 min, just added it to one of the test servers running my drupal 7 sites, and I had never installed word press! People are tired of feeling like they need to learn 5 new tools in order to do something that used to take just a few minutes. I will hang in there with drupal, but we need better specific drupal/symfony/composer documentation, including a large troubleshooting section.

I have started moving away from drupal, as it gets more complicated and much much harder to solve problems. Drupal is getting harder and harder to install and run. If you want new drupal users they need an easy way to deploy a website with basic features. This is not just a documentation problem its a drupal/symfony/composer problem. And its all in what we call people

Drupal serves developers and has turned its back on builders.

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.