I've migrated two simple modules to Drupal 8, and created one specifically for D8. I can tell you that D8 is a much better setup on the programming side. D8 is finally following modern programming paradigms, such as dependency injection, twig templating, OOP that makes sense, composer support, PSR-4, PHP7 support, and more.
Can't wait to start building much larger sites with D8 and when there's more contributed content for it.
Developer of Pathologic [1] here. Code-wise, D8 is really a whole new paradigm for the system, so if you've given Drupal a look in the past and rolled your eyes at the PHP 4-ness of it all, I really encourage you to give it another look with fresh eyes in the future.
In terms of user-facing features, I think the greatly improved support for multilingual sites is the most exciting new feature (especially as just this week I've been encountering headaches related to i18n implementation on a D7 site… argh).
Kudos for the reboot. I haven't touched Drupal in maybe 7 years, but I gather it must be orders of magnitude easier now to develop a site with modern software engineering tools than it was then.
However, this reasoning feels wrong:
If we were to ignore these market forces, Drupal would be caught flat-footed and quickly become irrelevant.
Wordpress is still the same big ball of mud it was 10 years ago and it powers 1/4 of the internet.
I would argue that Drupal's target is much different than Wordpress'. Yes, Drupal has a tiny bit of focus on small sites, but Drupal can't contend with Wordpress, not even close. Wordpress is much faster to setup and get a nice looking site up and running.
Where WP falls short is in the enterprise market, and this is where Drupal's ideal customer is. Drupal powers Tesla, Whitehouse.gov, Weather.com, Economist, NY.gov, and other major sites. So for Drupal to remain relevant to these types of clients it has had to play catchup. D7 changed a lot from it's initial release, and a lot of contrib modules helped make it a decent enterprise-level solution. But D8 is a whole new beast that really sets the bar pretty high. You can literally build anything in Drupal, and with it's new focus on having "headless" RESTful services, it can be used to power your entire content strategy (pushing content to apps, other sites, etc).
The above three drush commands get a site technically functioning, but it's typically a long way off being a "nice site" or being "up and running" in the push to production sense.
WordPress's out-of-the-box post install experience is a lot nicer and a lot closer to being a "finished" and ready site.
I mean, I don't just mean setting up a bare site. Between setting up content types, fields, putting in content, downloading additionally needed modules (which got better in D8 with Views/Twig/CKEditor in core), and how much custom theming has to go into a Drupal site, I feel like WP is generally much faster to deal with and has more beautiful themes/widgets that you can just plug n' play.
However, I'm not an expert in WP dev. But I wouldn't recommend Drupal to a very small business that needs a basic site. For that I would recommend WP, squarespace, wix, or equivalent. I would only recommend Drupal if someone needed some enhanced functionality, in which case, Drupal is a great platform.
That's presuming they can have command line access and the tools/know how to install drush. I suspect a lot of WP installs start with a single click button on a graphic UI.
There are solutions catering to SAAS/application-specific hosting for both. Wordpress.com / Drupal Gardens as well as containers and configurations scripts you can use to get a jump start.
Both have similar philosophies in the sense you can login and immediately start switching on modules/extensions you want to use. Both are CMS.
How much experience do you have using wp-cli? Drupal/drush are a long long way off perfect but comparing drush to wp-cli is apples and oranges.
wp-cli is extremely brittle even for very simple download+install, produces very poor defaults in terms of file/directory permissions and general on-filesystem stuff, and this is before you get into things like drush's many other functions for general admin or its extensibility.
That is not a criticism of wp-cli's developers though, as about 99.9% of its limitations are down to the Wordpress core team's complete disinterest in accommodating its functionality well or in providing a codebase that fits into a modern deployment setup in any reliable, well-considered way.
The work done on wp-cli is really commendable: it seems to be battling against quite a tide.
Very true indeed. I've done maintenance on a few WordPress sites and every time i opened up a new theme or plugin i thought "this can't possible be as worse as the last one." Boy, was i wrong.
Not if you don't have the stupid PHP filter installed (it was ripped out of core for the Drupal 8 release, praise be to the heavens; for those unfamiliar, it was basically <textarea> plus eval()) and you're using decent version control.
it's moving further up the chain. it is not hard to find a graphic designer who fancy themselves as wp experts because they can copy pasta css, install a module or two and ftp it to $3/mo shared hosting.
but honestly that is what many clients want, make it look pretty and don't bore me with your "best practice" and "you need to apply 12months worth of critical security patch's" mumbo jumbo.
As the operator of one of the larger Drupal-powered sites, I'm looking forward to playing with some of the news features and functionality (first on my personal site). Granted, I still dread making the transition from D7 to D8 for my production site with 200k registered users, 53k nodes, and 3m unique monthly visitors.
As mentioned in someone else's post, it is PortableApps.com. I left it off as I didn't want to be self promotional in the reference. Mine is far from the largest Drupal site, so other sites like Weather.com and The Onion have done more with large-scale scaling in terms of multiple servers and the like. Personally, for PortableApps.com, I've used Advanced CSS/JS Aggregation [1] and LABjs [2] to help quite a bit in terms of caching along with offloading images and static scripts to a CDN (MaxCDN in our case). Moving the MySQL data from a standard server-based instance to Rackspace's Cloud Database instance and the Drupal install from a dedicated server to a cloud server that can be up/downgraded helped as well. All while keeping costs to about the same as the old single dedicated server.
> Mine is far from the largest Drupal site, so other sites like Weather.com and The Onion have done more with large-scale scaling in terms of multiple servers and the like
Don't forget https://www.whitehouse.gov - it's a Drupal 7 site, and I imagine it gets a fair amount of traffic.
Quite true. They did have one of the largest Drupal sites for a while. I'd wager that the articles that explored how they did it would be a little outdated now as I think they were on Drupal 6 when they switched platforms.
There are a lot of great posts and case studies about weather.com, which is a solid example of drupal in a high performance environment.
Performance has been a specialty for me in my own drupal career. Drupal 8 is a whole new ballgame, though. Cache tags are built in from the ground up, and the page render/caching engine is built to mimic a reverse proxy. Rasmus Lerdorf (creator of the PHP language) benchmarked a pre release of drupal 8 at >2500 page views per second with 20 concurrents.
That's it. And I run Drupal on my personal site as well as you noted. I have a handful of other Drupal sites and a couple WordPress sites I help with, too. I'll probably upgrade my personal site first and my internal test sites running on local server instances to play with.
Not to brag, but 3M is by far not one of the largest Drupal powered sites, just one property of the company i work for has more than 40M active users a month & 350M pageviews
I never claimed it was the largest. Just one of the larger ones, particularly as it has a community of 200k registered users all using community forums (most Drupal sites are more in the 100s to 1000s of users). It's the largest I know of offhand managed entirely by a single person and not using any specialized front-end caching or load balancing between the actual Drupal instance and the end user. There are much larger sites run by large companies with all kinds of specialized code and handlers like The Onion, Weather.com, etc.
I like that people are constructively discussing about Drupal without bashing PHP. I'm pretty surprised about it. Good luck to the Drupal project. Being a symfony developer myself I know that it's a great framework and Drupal surely benefited a lot from the integration.
I'm skeptical about investing anymore time into Drupal after using 7 extensively for the past few years. Any work I've done was mainly custom module development, soap, rest apis, aws integrations, ecommerce, etc. Pretty app heavy stuff. It's not well suited for these tasks but it can do them if you get creative. This, of course, has great overhead and complexity.
I'm going to look closely at other options. It seems at this level that Drupal has been outgrown and that once you hit that point, for me, it feels like pressing the reset button and starting over. I'm bummed it has a growth ceiling.
I also feel strongly that the productivity level is deceiving. You race out of the gate with clicky this and module that, to later find working with a custom data model to be extremely painful or that you can only do things via interface and not in code. Unit testing, at least in 7 is non existent. Short term gains and long term pains. It does not feel like it was ever designed with developer speed and procutivity in focus.
So while I'm curious to hear of the new release I also just feel you can't teach an old dog new tricks. Part of this is the.community it has built for itself. Time will tell. I have a feeling D8 is between a rock and a hard place. At some point a framework is just way better. Tool for the job I guess.
I agree. While there are probably a bunch of use-cases where Drupal is a good solution, I find that it doesn't hit any 'sweet spot' that I care about.
For very simple sites I'm inclined to use a static site generator.
For relatively simple sites that need a CMS, I use Wordpress (much as I dislike it). The clients are often familiar with it, and it is pretty easy to set things up. And if I'm going the Wordpress route, I might as well take advantage of the high amount of plugins and the complete (and often cheap) themes that target specific industries.
For anything more complicated, I used to be in the Drupal camp, but now I opt for a framework approach. Rails, Express, or something like that. With every single site I've built in Drupal I always ran into the problem that the time spent on 'clicky this and module that' eventually outgrew the initial speed advantage, and I would have been better off doing these things in code in a environment optimized for this approach ('true' frameworks).
I think it's analogous to how many of my clients insist on using Wordpress and paying more for that instead of a static site. They would've been better off with a static site that I update for a small fee, or perhaps even a small lesson in FTP-ing and editing a file, but they wanted the 'option' of logging in and changing stuff. But many of them never do.
Similarly, the choice of Drupal sometimes seems to be primarily project managers who want the 'option' of making complex changes through the admin interface, just so they have the option. Never mind that the complexity tends to be high enough that you need a programmer anyways to pull it off, so you might as well just go the framework way.
One of the most challenging projects I've worked on was building a Drupal 7 site. I was fresh out of college and had absolutely no Drupal experience. In retrospect, I am confident that there were likely easier ways to do many of the things which I wanted, but at the time everything felt like an uphill battle.
The biggest challenge was the UI; I had to build something against mocks from photoshop, meaning it had to be pixel-perfect and identical to what the client had agreed to. Most contrib modules didn't have a way to easily customize the output (as far as I could tell), so I either had to modify the code of the module to produce exactly what I needed or just write the functionality myself (typically choosing the latter). Had I been working with a Drupal guru there may have been a way to avoid this, but who knows? It seems other commenters have mentioned needing to customize the modules themselves.
This was a very poor experience for me. D8 looks like a large improvement, but I was so thoroughly burned by the lack of clarity and community support that I doubt I will touch Drupal again.
Aside from the inexperience issue (D7 and later really do give you the power to override theming on just about anything), you should never promise a client that a web design will replicate a mock-up with pixel perfection. It's impossible; there's just too much that's out of your control. A web design mock-up is more of a guideline that can be followed pretty closely, but never perfectly replicated.
To people using Drupal in production: can you share what you consider to be the sweet spot for using Drupal? Also, are you mostly using existing components, or leaning more toward custom development?
I've worked on many Drupal sites, and I would say the sweet spot is a client who is going to budget $10k+.
Basically, under $10k budget means you should be looking at simpler, pre-baked solutions, like Wordpress, Squarespace, Shopify, Wix, static HTML, etc..
I've worked on Drupal projects from $25-250k+, and it can handle pretty much everything (sometimes requiring a lot of TLC tho).
There are so many contributed modules that can help build things out, but I always need some type of customizations requiring (usually a few) custom modules per project. It all depends... I did one project that had dozens of crazy features that we broke out into 70+ custom modules...
But yea, I would say the sweet spot is a customer who needs a pretty large site with a lot of functionality. My 2 cents anyway.
This is some very useful insight, thanks! I've been asking this since at times, fully custom development (I ship Rails apps mostly, since 2005) is not the way to go, so I'm looking for other options where using modules (either custom or purchased) could help.
I would like to make a point that a very nice thing about the Drupal community is a lack of paid modules. There is a conscious effort to either open source or custom develop. There are not very many "paid extensions." The community seems a lot more focused on creating low level tools that you can use to build a finished product.
This is in part due to the relative complexity of setup. You do not get your grandma performing a one click install of Drupal and then spending $40 on a theme and buying an extension or two from a marketplace.
The focus on earning money with Drupal really seems to be in being a good developer and knowing how to use the thousands of opensource tools that are available to Drupal. You do not see people cranking out apps or modules for drupal and selling them in a marketplace. This really sets it apart from it's php cousins Magento and Wordpress.
I would recommend for larger-type websites, and not so much for performance-based applications. However, ignoring my own advice, we did build a todo list app powered by Drupal & React.js and it works pretty well: http://www.135list.com
You can literally build anything in Drupal, although I'm not sure you should...
I would suggest you consider drupal as a basis for your fully custom sites. You start out of the box with a well supported, standards based system for the basics: user management/authentication, data modeling/storage/query, routing, path handling, HTML templating etc etc. It has a huge ecosystem of modules, also effectively out of the box, for third party integrations and all sorts of esoteric requirements. So you start writing your custom code on an established base with a strong API for modification and integration, which means less custom code to support.
In a Drupal custom module you can do or change literally anything, and you can write whatever architecture you like for your individual component. You just have to integrate with the Symfony2 router and dependency injection container. Pretty cool stuff.
Unfortunately, the book I usually point people to [1] when they ask a question like that is not yet updated for Drupal 8. Frankly, we're probably going to be in that awkward state where supply for learning resources for D8 is greatly overwhelmed by demand for a little while at least. But it's OSS; if all else fails, you can trace the source code, assuming you've got the PHP chops.
I used Drupal (6 and 7) in a small bank (80/100 internal users, 500+ financial advisors), building the external public site and also a an internal site used mainly to share documents, modules, faq etc.. with the network of advisors.
It replaced a commercial solution bringing more clarity (but that was also thanks to stricter rules in place defining types of docs, fields etc..), better graphic appeal (but just because the previous one was really crap) and also great search experience thanks to Apache Solr.
As I am a sysadmin, not a developer, I used all built-in modules except one that I modified in order to integrate the authentication with another business system via webservices (only code I developed). As I am also not a graphic, I worked with an external one (that prepared design in PSP so it was a bit a pain to convert it to template)
At that time (2009 I think) I reviewed few other options (WP, ezPublish, plone) but I chose Drupal because the authorisation system with roles etc.. was much more powerful than WP one.
I mostly use existing components, because they're there and (usually) of high quality and integrate well together. But on a project of any size you'll need custom development. If your project is so small you don't need any custom development, you might have been happier with a simpler CMS in the first place. I've always liked the description of Drupal as a content management framework.
Thanks for your input, appreciated! A bit of custom isn't a problem (I'm used to do everything custom usually!), but it's good to know there are truly useful existing components which can play well together.
Yes indeed. There are so many existing useful components that there's a whole section of the Programmer's Guide to Drupal [0] called "Common Drupal Programming Mistakes: Programming Too Much." Almost all the Drupal code I write is either integration or patches to existing projects.
I'm building with Angularjs and Express right now coming from a Drupal experience. At every turn I'm looking to Drupal and Drupal contributed modules to solve problems, for example, media asset management. If I had to to solve for internationalization, document versioning control, publishing workflow, publishing workflow with versioning control (lol), integration with a full-text search engine, micro data markup, and several other common problems, I would start with Drupal which also provides a fully functioning REST server that integrates with all these things seamlessly. That is the miraculous part, the seamless integration. It is plug and play, but sometimes I have to open up the insides and write 'glue code' to bridge the different components. Also, I have to export configuration from the database into code which is possible. I'm talking Drupal 7. Can't wait till I get a Drupal 8 project.
There's over 60 videos. It's sponsored by http://Acquia.com (the biggest fish in the Drupal pond) and created by http://OSTraining.com, who are one of the top sources for Drupal videos.
Actually, D8 adds a few (optional) modules which add some nice UI flourishes to simplify things for administrators and content editors. The stock administration menu module has been greatly improved and made more user-friendly out of the box, and there's many places where you can now do in-place editing of content. Also, everything is responsive out-of-the-box, including the content editing forms.
Also, Overlay is gone. (Sorry about that showing up in D7. Some of us tried to stop it, but…)
Pretty much everything under the hood has been rewritten. It is a very different CMS than D6/7 was. Whether or not all those changes are for the better, is up to you to decide.
I have very mixed feelings about Drupal. On one hand, it does have a lot of functionality available in third party modules; but the quality and completeness of them varies wildly, and most require custom code in order to be useful.
Another issue is maintenance. I don't think I've ever met a well-maintained contrib module; even ones that seem to be actively maintained aren't what I would call "well" maintained...reported bugs don't get fixed, patches don't get accepted or commented on (I have a half dozen bugfix patches spread across three or four projects, including one for something in core, that have gotten no response, some for months). While Drupal doesn't suffer from the crass commercialization that has befallen much of the WordPress ecosystem, it seems only companies paying for development get any sort of response. I don't have a problem with developers prioritizing paying customers (I do it with my own Open Source software, as well); but, when someone sends a patch that fixes a bug, at least comment on why you don't want to integrate it or give some guidance on what would make it acceptable for integration. I am beginning to feel like submitting a ticket to the Drupal issue tracker, even with a patch to fix the problem I'm reporting, is a waste of my time. If it were one project or module, this wouldn't be such a big deal; individuals get busy. But, I can't think of any Drupal module or project that I've ever had a good experience reporting issues on. And, if I didn't know that development is still ongoing, and that many new sites are being developed with Drupal, I would assume this extraordinarily poor level of interaction in the tracker was indicative of the impending death of the project.
There is also an academic love of complexity and abstraction in Drupal, almost to the point of absurdity, at times. Every new release introduces vast swaths of new terminology (often used in ways slightly unlike the rest of the industry use the term). Entities, nodes, rules, entity bundles, content types, views, entity references, delta, features, fields, hook, machine name, taxonomy, etc. About half of these do not mean what I would have guessed or are used in subtly different ways from what I would have guessed. And, it's impossible for a casual Drupal developer to stay on top of this stuff; it moves so rapidly, and is so poorly documented, one has to read code. And, there's a lot of code. Somehow, despite all the abstraction, most modules include huge swaths of code, and aren't particularly re-usable. Even very simple functionality seems to require pages of code. It's often more of a pain in the ass to make the re-usable components work in some way that the developers didn't think of than it is to implement from scratch. Partly this is my own shallow knowledge of Drupal, but I see experts building out entirely new modules to address very similar use cases to other modules they've made, so I'm not alone. Somehow, despite WordPress' much uglier code base, I'm generally able to implement stuff more rapidly than in Drupal; and many things that seem really locked down and hard to change in Drupal seem easy in WordPress.
The upgrade path is literally disastrous for non-core modules. One literally can't get from point A (a Drupal 6 site) to point B (a Drupal 7 site) without writing a lot of migration code, unless you're only using the most basic of core functionality. I'm months into a migration from D6 to D7. The new(-ish) Migrate module requires writing code, sometimes significant amounts of it, and is extremely poorly documented (and uses a bunch of its own jargon in confusing ways; the number of contexts in which the word "migration" is used for different purposes makes my head explode), and in-place upgrades don't exist for a large number of modules, including pretty important ones (like Project Issue, the module used by Drupal.org for its own issue tracker...it has no working upgrade path, at all).
I see the benefits that Drupal 8 brings. And, having worked with Drupal 7 for a few months now during this migration, I see that the direction is a positive one. But, I find myself being angry a lot whenever I work with it, because there's so much forward momentum (everything changes! all the time!) but nobody seems to give a shit about bugs, major usability problems, or providing a reasonable upgrade path. Really basic stuff that ought to go without saying, really doesn't in Drupal.
So, it's a real love/hate relationship. Which is true of every CMS I've ever used (and I've used a lot). I have decided to stick with Drupal through at least one more iteration and will launch our Drupal 7 site in a few days (if I'm lucky), but I don't know if I'll ever migrate to Drupal 8.
Yep. I took a big long break from Drupal, but thought it would be appropriate for a project I started building yesterday. In two days I've found as many bugs:
5 months ago, a maintainer with direct commit access to Views (a module with ~1M reported installs, probably the highest priority module, has been included into core in the latest Drupal release) committed and released some code without tests. Change intends to add help text to an admin UI, but also causes that text appear on the end-user UI. These changes made it into a release without any kind of oversight, and could have been reverted easily after being discovered and reported 2 months ago, but the issue remains in the released stable version.
Someone added some code which tries to filter an array, but forgot to pass the array in as an argument -- the code immediately complains and puts many red notices on the page when invoked -- how this was missed I have no idea. This was fixed hours after the bug was introduced a month ago, but the bug made it to a "stable release" and not the fix, so anyone installing the module in the typical fashion is affected for basically no reason.
May I suggest taking a strong look at ProcessWire? You only need to deal with fields, templates and pages and all content is in a simple to understand tree hierarchy. I switched to it from WordPress 2.5 years ago and haven't looked back. Great developer community as well.
While it looks nice, it isn't in the category of software I would use. I don't need a CMS, per se.
I use Drupal for commerce with subscriptions, support ticket tracking, forums, software license management, and, only peripherally, for content management. So, it's not the "CMS" part of Drupal that matters to me. I need an ecosystem that contains a bunch of functionality that operates reasonably well together. Drupal, for all its warts, does actually have most of the code I need already written. While it's taken me months to migrate to Drupal 7, it would have taken years to implement all of the functionality I need from scratch (our website is not our core competency or what we're selling, it's a tool for supporting our actual products, so I don't have a team...it's just me).
This is probably easier to maintain (code wise) using different root folders, but configuring the http output folder within apache or nginx configuration.
Yes. Drupal itself is moving away from multisite and toward this kind of setup. Disk space is cheap now. Unless you're talking about literally thousands of sites, and you have the Drupal expertise on your team to manage that kind of setup, use separate root folders.
Create these directories. Add a settings.php file to each. Add stuff to sites.php if needed. example.com.a and example.com.b should definitely work. Not too sure about the other two because I haven't created a site in a multi-site setup that is 2 subdirs deep, but it is easy enough to try.
Can't wait to start building much larger sites with D8 and when there's more contributed content for it.