Dear Developers who pushed for and sucessfully mangled a great platform with modern trends,
I've been using Drupal since Drupal 6 was new. That's 2001 for those who don't remember or never used it.
It made my life as a freelance developer running my own business very productive. I got a lot done for a lot of very happy clients. The modularity and abstraction of ideas and how things relate were one facet of it that just made it like nothing else.
As time went on something else about Drupal made it a shining star too. The fact that the software world has been obsessively consumed by Object Oriented Programming. I've written it, heck I was trained in it during college. Something about the fact you were introducing all these concepts and ideas that have nothing to do with programming the solution at hand though never sat well with me. It always seems people are trying to force some outside concept onto programming and as a result, overcomplicate it and make it take longer to develop, maintain, and debug.
I was always able to point to Drupal as a proceduraly written highly successful platform that served small and big companies alike and did it well. Perhaps I said that too much and pissed off the OOP tribe and now they've ruined one of the best platforms out there?
I'm not the only one saying the OOP trend is a costly mistake, not only dollars but for people like me who you know, like being productive. When a key Drupal figure comments on Drupal 8 as being not something you'd use if you want a sight up quickly anymore, that's a HUGE ISSUE. What have we gained? Nothing except a bad fad as far as I can tell. We've lost a LOT though.
I'm not the only one saying OOP is a mistake.
http://harmful.cat-v.org/software/OO_programming/
http://www.smashcompany.com/technology/object-oriented-programming-is-an...
Just two easy to find examples.
Not only did you guys make this catastrophe of a mistake in making Drupal 8 OOP, you chose the worst versions of it, using dependency injections, lots of interfaces, and basically copying something in large part that already exists. Look, if I wanted to use Symfony, and let me be perfectly clear I'd rather be chained to a chair and told to write assembly 20 hours a day than use Symfony, then I'D BLOODY USE SYMFONY.
Lets see other dumb modern trends you have destroyed drupal with. Composer. Check. Oh boy I sure love assigning 4GB of ram usage in order to install a module when drush would do it you know, well? I sure do love troubleshooting when composer goes wrong too oh boy what a great time. Drush going wrong was always very limited to the module you installed. Composer can jack up all these dependency trees and sometimes the only way to fix it is pray you have backed up recently enough. Now it's "recommended to only use composer" to install modules. What is wrong with you people.
Are software jobs so in rare supply these days that you have to create work for everyone else? Because that's what it seems like you're doing.
More modern trends you mutilated drupal with:
1) Tons of private properties. Man I sure love spending 3 hours to make a less efficient solution instead of just changing a variable I needed to change with my module in 1 line of code. How forward thinking and progressive!
2) Twig. Who in the hell thought phptemplate was a bad thing? I honestly think they should be banned from working in development ever again because they obviously are frightened of writing actual code, or so cynical or mean spirited that they just consider it a great idea to limit the power of a developer to... develop. Surely it's better to make all these other things in front of the twig templates and then limit what the templates can do, oh boy I sure love doing more work to accomplish less!
3) Objects objects objects. I sure do love chaining a ton of method calls to get the data I need instead of just accessing an array. What a great way to go. It's so much better to have to worry about plugging Use in the top of all my files instead of just calling a function or hook. Man I can't believe I lived in the dark ages of programming so long where if I wanted to do something it was easy and efficient and ran faster too! What a travesty I didn't have my life bogged down by object after object, that are all named for abstract ideas rather than anything useful to a solution you are actually trying to create! What a boon this drupal 8 rewrite is. If I was a manager I'd fire you all but I'm not so :)
4) Themes often now use SCSS and other "lets put more steps in there to accomplish the same thing" technology. Sure you can just use the generated files a lot of the time. Other times though they are part of something you have to alter. Don't forget they also all use twig now. What a great time to be alive when good tools can be made less powerful and more time consuming to use by coding tools for them to make work less productive in the name of saving you time.
5) Command line tools to spit out scaffolding for you. If your program needs this kind of tool your program sucks. End of story. P.S. It doesn't save me time. It makes it take more time because I have to worry about all of that even if the program spits it out and navigate around it when I code and worry that it's all correct when it often isn't. It introduces more points of failure which if you know anything about anything is usually a bad idea. Well, that's putting it softly. It's almost always an absolutely terrible idea.
So thank you devs who did this move, you've ruined something I loved, and made a few enterprise people happy (which if they knew what they were talking about, wouldn't be happy either). I know I'm not alone in this:
https://www.reddit.com/r/drupal/comments/6au8xn/goodbye_drupal/
Just one example. It has quite a few upvotes.
So who lead this coup de'tat on Drupal? Who can I blame. Because I want to add you to a list of people that did bad things for the world and set humanity back several years and cost them time and money.
Before you say backdrop exists, I know it does. Have you seen how a splintered community is way less effective though? I couldn't even trust installing their commerce module cuz it looked like 3 people used it. People don't know what backdrop is, they know what drupal is.
I have a perfect solution for this. Make backdrop drupal 8, and rename the current drupal 8 to something fitting. Like I don't know. I Worked On Drupal And Liked Symfony Instead So I Made Drupal Use Symfony And Other Garbage That No One Sensible Likes. A very fitting and useful name. I hope you like typing it out every time you need to talk about it, no acronyms or shortcuts allowed. We've disabled your ability to use those. Now first if you want to change the name you have to create a Plugin that extends the Name Title Entity class and implements a language interface, and make sure you edit your .yml and change the annotations and make sure you did it right because it's not like those have robust syntax checking anyway, and once you've done all that please make sure to register it in your services.yml file so other objects can have use to it. Trust us this is way better than just assigning a variable or calling a hook. Those are such primitive practices that worked for years and worked extremely well and we aren't moving forward if we don't distance ourselves from them as insanely as possible.
Please enjoy your new name Drupal 8, we worked hard to come up with it. Oh you don't like it? Well I guess you just don't know how to program then. Maybe you should learn to program so you can use all our cool features to rename it to something that makes sense. You'll thank us later. These people with lots of money sure like it! It has everything to do with exercising control over different groups and what they can or can't do to the code and enforcing that via code even though that has never worked right even once than the fact it's good programming but we like them more cuz they have money and we want to work for them cuz they have money.
Honestly I hate all ya'll who pushed for this. My only glee is that you have to use the crappy changes that you introduced and that's punishment equatable to purgatory. It's not enough though, because you're also making ME use it. And for that, flork you.
Comments
It's all a matter of opinion.
It's all a matter of opinion. I find Drupal 8's OOP structure, with Composer integration, to be hands down better than Drupal 7 in every way (Edit - well, except for complexity).
That said, that's me. I can see how D8 would be extremely frustrating if you don't understand OOP, and the Composer switch was a huge headache to figure out. So I get where you're coming from.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Complexity adding time to projects is objective not subjective
I was taught OOP in 2001-2005 when I got my degree in computer science and had to read gang of four back then. It's only got more stupid as time goes on. Composer I've had to unfortunately use for a ton of projects. I didn't have to figure it out to use drupal 8, I had to cringe when I saw they didn't even WANT you to get around using it.
This is why even talking about it with you people is usually a complete waste of time. You assume if someone doesn't like it, it's lack of experience or knowledge. You do exactly what that 2nd article linked that I posted, you use the no true scotsman fallacy. "You don't like OOP? Well no TRUE OOP programmer would think that. So you must not know OOP." You don't acknowledge that people can be in full know with tons of experience and still think it sucks, cuz that's usually what I find.
What does d8 accomplish outside making projects take longer? I read at a drupal conference even a key speaker there said this is very true about drupal 8. For that trade off I want something but all I got is a bunch of stuff that I never asked for and don't like when I got it. It's very awful.
"You don't like OOP? Well no
I didn't claim you don't know OOP. I pointed out how it would be a difficult change from D7 if you didn't know it.
Now that said, I've talked to very few D8 programmers who have said they prefer D7. You are an example if them - they do exist. But I've never understood the acrimony - Backdrop is there to be used, and no one is forcing anyone to use Drupal.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
The acrimony is very simple,
The acrimony is very simple, backdrop is put in an obscure location with a different name and has way less support than drupal 8. Going by the reddit link I gave alone a large number of devs disagree with the changes in drupal 8. Very large.
Put drupal 8 in the obscure location with a name no one knows and I'm fine with it. Make backdrop drupal 8. You guys have all this other stuff on other platforms don't ruin ours.
What does d8 accomplish
Personally, I find it way less hacky. More precise. More flexible for overriding and swapping out sections of the code altogether.
For example, I've recently written a module that overrides the whole login/registration system and allows users to re-use email addresses for multiple accounts on the system. Drupal 8's OOP methodology made this possible. The module would have been a major hack in D7 (I've been coding modules since D5, so I know the difference). It was done cleanly with Drupal 8.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
I do think that the
I do think that the retirement of Drupal 7 may see a resulting surge in the Backdrop community.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Nice rant. Fun links.
Nice rant. Fun links.
Some of the OOP in D8 I like. Some of it looks like over-engineering for the fun of it. Symfony, um, well, I don't mind the routing system. But no matter what, I find that I now really hate working on the D7 sites I still maintain. Config management with features and strongarm, ugh.
I don't hate maintaining d7
I don't hate maintaining d7 sites. They barely take any dev for the most part for me once they're done and I've never had any issue maintaining them. If D8 attempted to fix that it failed miserably because just making a new template takes more work by far.
Dear Arcsdev, totally I agree
Dear Arcsdev, totally I agree with you!
I have received the same (useless) answers, among other things, off topic.
Drupal 8 with the imposition of composers and other amenities out of the "smart" logic led me to abandon it, despite having still more than 100 active installations between D7 and D8, in favor of WordPress.
My comment about it https://www.drupal.org/forum/general/general-discussion/2020-06-19/goodb...
=-=
These types of posts make me grin. It's as if the ego of the poster needs to take the time to proverbially slam a door in anger. I certainly hope they feel better afterward.
Of all the posts like this that occur, I wonder how many of the individuals will be back as Drupal evolves. Drupal wasn't for everyone or every website before and isn't now. I agree that there will likely be a surge in backdrop over the coming years. I also venture that once core settles, contrib will pick back up. Pretty sure D8 into D9 had the most participation ever?
Many of these posts also reference in some way the lack of contrib activity. While there were some very giving developers that left due to the shift in core, I don't think that's why all who left backed away. Over the years, I've watched consumers of the modules become far more demanding than they used to be. Back in 4.6.x many who consumed modules also found some way of contributing back in docs, code, testing etc. When one reviews the profiles of most of the users now that are 'done with drupal' they seem to have contributed very little but then go on to state how prolific they are or how many websites Drupal will be losing or in some other way define how they've benefited from the work of others. In one of the comments above the user refers to Drupal as 'our platform'. Quite ironic.
If you didn't notice this
If you didn't notice this account is new before this I have never had a REASON to post on the drupal forums but yes your stupid changes to drupal's direction necessitated it. No I don't feel better, I feel worse because the replies here are ignorant and full of what you accuse my post of being: ego driven and full of irony.
You can bet money that not only will I be not using Drupal 8 but like Magento2 and other shitty platforms that emulate their design ideologies I'll be recommending fellow developers and clients away from it as long as I can still utter the words.
You also seem to think the only ecosystem that matters for drupal is contrib. Who pray tell is going to use use contribs if not for developers like me who have been recommending and using and putting sites together for people that actually put it to use? You scoff at the middlemen who utilize Drupal to solve real world problems and you scoff at anyone wth valid criticism and you scoff at the people who leave because of your bad decisions.
You make the bed you sleep in. Number of contribs don't mean as much as number of users. Magento2 has a ton of contribs and there's been a lot of people abandon it and it still has thousands of outstanding issues on it's github and lots of contributors. Drupal 8 split the community and I for one hope backdrop continues on while Drupal 8 becomes more and more obscure in the coming years and hope whoever did this is proud of the split they've cause because if they're anything like you then they're prob full enough of themselves to be just that. If this is the direction you're going it's definitely not the platform me and others signed up for and used so many years. You deserve not just every angry post and left developer but all the fallout you've created.
=-=
So, you are allowed to your opinion but no one else is allowed an opinion unless it fully aligns with yours? .... and somehow that makes me arrogant?
I'm not a core developer so blaming me for changes in the core that you don't agree with is totally misdirected.
So you talk about how
So you talk about how important contribs are then do none yourself? wow. What opinion should I value? Just cuz it's different? All you've done is be mocking and dismissive there's nothing of value in your post to even try to allow to be different. I know some people like OOP more or like complicated systems for no reason more, liking isn't really a valid reason to impose your likes on others though and change a system that has long existed into something it never wanted to be and should never be.
=-=
I've helped thousands of individuals on these forums. I've contributed my time to helping others over the past 11 years as my profile shows. Something you illustrated you had no time to do since you didn't even feel a need to create an account until you wanted to whine. I never said the only way to contribute to Drupal as project was via code/modules. In fact, I mentioned multiple ways consumers used to contribute.
If you don't want comments added that have a different perspective on all things or a subset of things in an opening post, then I suggest you create your own echo chamber on a domain in which you can exclude comments from those that have a different perspective. You, particularly in the overly-angry mindset you are in, may not find value in my comment but I assure you that others will.
VM is one of the most
VM is one of the most prolific posters assisting on these forums. Not every contribution to the community must be in code.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Drupal 7 EOL is November 2022
It has now been decided that Drupal 7 will remain supported until November 28, 2022 That gives those of us who still maintain a lot of Drupal 7 sites some more time to figure out what to do and what it will cost to upgrade these sites to Drupal 8. I maintain some legacy Drupal 7 sites for projects and events that are no longer active (i.e. the sites only serve as web archives). These are now all being converted to static HTML, making continued maintenance much cheaper for the client.
As for taking Drupal "off the island" (i.e. replacing things specific to Drupal with industry standard platforms, tools and practices such as Symfoni , twig, composer, PHPUnit), there is no doubt that this decision made the transition from Drupal 7 and earlier to Drupal 8 very rocky for developers (like myself) who had spent years hacking Drupal 5, 6 and 7 and have it in our blood.
However, all things considered, I think it was for the better. Moving to industry standards made available a vast amount of reusable libraries, reducing the burden of code maintenance. It also makes it easier for developers to move between Drupal and other development environments based upon the same industry standards.
And: If you prefer to make a living creating and maintaining fairly simple websites, there exists other free software CMS platforms based on the procedural paradigm (e.g. Wordpress, which even has an ecosystem that is much larger that that of Drupal). Nobody is forcing you to use Drupal 8 if you prefer procedural programming over OOP (as @arcsdev clearly does – as well as some of the people she/he links to).
However, when looking at the niche in the marketplace that is currently dominated by Wordpress, it is more and more taken over by interactive template based site builders such as SquareSpace and Wix. In the future, I don't see much room for something like Drupal or Wordpress in this niche (i.e. provisioning for site builders that just want to create a simple websites with stunning looks and limited functionality). In my opinion. the way ahead for Drupal to provide to professional developers a real alternative to Wordpress, Squarespace and Vix. I.e. a development tool that let developers create ambitious digital experiences that is outside the scope of Wordpress et al.
If Drupal 8 had just been an incremental upgrade of Drupal 7 (this is what Backdrop tries to be), it would at best continue to exist as an also-ran in a market niche that is currently being dominated by WordPress.
So: It has been a rough journey to go from Drupal 7 to Drupal 8, and I have not arrived yet, but I don't think that the Backdrop approach has much going for it, even if it had been branded "Drupal 8".
- gisle
Nice summary Gisle.
Nice summary Gisle.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Support ext good, assumptions on procedural = simple website bad
It's very much appreciated support is extended.
Just because something is "standard" doesn't mean it's good. Industry standards in software are egregious. If project time = p1 and using industry standards takes time i1 then project time is O(p1 i1), that is to say it is multiplicative on development time with p1 and i2 both being positive numbers above 1. In procedural systems without all this bloat my project time is O(p1) a much smaller value. This is simply better. Maintenance is the same. More to maintain means longer to maintain. More tools introduces more points of failure and more to maintain but can have a net savings, if the tool wasn't made to fix a problem "industry standards" created.
The issue isn't some rocky road to the top of a mountain. It's the fact that there is no non rocky road in modern development systems. Reusable libraries exist in spades, simply look at the GNU library and then see all it's bad imitations in something modern such as node.js, there's no lack of libraries because you use procedural.
Symfony, twig and composer all are steps backward and systems that use them every time I have to use them, take longer to code and maintain and that creates higher cost to my clients, which limits the number of clients I can have because not everyone is a big bankroll client. There's a ton of small and medium sized businesses out there that a few weeks added to a project means they can't afford it. This means less work for me. It means I can get less done. It makes it harder to run my business. It means I get less projects done which means I have less opportunities to grow my own business. The only people that industry standards benefit are people that benefit from gatekeeping the little guy because suddenly development costs multiplicative more and a few people employed by these big companies who find job security when they create problems, and tools to fix those problems, instead of creating solutions and avoiding over engineering and over complication.
I find simple in italics hostile and offensive. I find a multitude of things wrong with this paragraph of yours. I'll itemize them:
1) Procedural does not mean simple websites, it means not over-complicating by injecting ideas about how software should be coded instead of just solving the problem at hand. Over abstraction, over engineering, high surface area programs that use tools to fix problems they create are the industry standard. Exempting yourself from them is both freeing and a productivity boost. Being more productive allows you to make more complex websites with more limited resources. It frees you to make complex things if needed.
2) Wordpress is also going to OOP more and more. Even getting database results now defaults to an object instead of an array. Why? Cuz that's the cool thing to do apparently. Even though PHP natively supports a huge library for dealing with arrays but not nearly the same robustness for objects. But hey. That means it's OOP and that's good right...
3) I worked several places before starting my own business. One was doing yahoo stores for medium/small businesses. If you don't know how it works, it's software as a service and it's been that way for a very long time. Way before Wix and Squarespace existed. Software as a service is a predatory practice in my view. It has one benefit, people that have no other recourse can pay monthly to benefit from the features. However for everyone else, investing a bit in your own thing you have your own control over is better. The worst part is, if you want to customize something outside of the software as a service model, you have to work against their system and implement hacks with iframes, javascript, php scripts hosted offsite with iframes/ajax and more. Making the cost of development higher for the same features and working against a system that doesn't want you to freely edit it. It's purely awful for people that need custom solutions and only good for people that want to coast on the features already there for a monthly fee. And if they change something you don't like or get rid of something you need? too bad. You don't get a say. Long story short, software as a service is popular and every company wants to be a popular software as a service model. Microsoft knew this very early on. Adobe has gone to it. More have too. And more will. Because they have figured out it's more PROFITABLE. That is 2nd to it being better for you. Now I have to pay monthly fees to Adobe for photoshop when before I could buy a new version every 4 years or so and be fine. They learned how to make more money off me. That's not a good thing.
4) Drupal IS the free software CMS that most people used for most the projects I have to do. It is the most free too. Wordpress has paid modules. Drupal is just free. Drupal is also abstracted in a good way, unlike OOP standards today, where it makes it useful. All content is a node. Perfect! All nodes can have fields added. Perfect! If you see how wordpress does this it's inefficient and messy. Workable. But having everything stuffed into two tables makes querying slow and harder than it has to be. With Drupal essentially being deleted to become like everything else you're taking away an essential tool of people like me to be able to live and actually enjoy their job.
5) Software as a service will continue to be pushed because it's way more profitable. Smart people that need custom solutions will always exist and SaaS can't fill that role nearly as well for various reasons both covered in prior points and not. Drupal is not a blog software like wordpress, which sure it has expanded but the core of it is a blog software. It is successful b/c it has so much attention on it. So with Drupal too. Drupal though, is used by energy companies, by non profits, by groups of artists, and many more to make an anything web application site. It can fit any need because of the great core design principals of nodes are everything and nodes can be infinitely converted to do anything you want to do. Wordpress posts are not nearly well designed or flexible. Drupal is really the best tool for the job often times. And I'm strongly against anyone saying it needs to become something else or go another direction or become more homogenized into what everything else is. Instead I reflect your point squarely back at you. There are ALREADY a conglomerate of homogenized "industry standardized" piece of crap uses composer and symfony and twig platforms out there. Take your pick. Drupal does not need to and should not become one of them.
Thanks for this thread I
Thanks for this thread I agree with all of it. I wish they'd have come up with a better name than "Postnasal Drip" for the fork though... it sounds like that was their plan "yeah call it post-nasal and put it on the back shelf in the basement next to the cans of old paint".
Generally I'm looking for an architecture that puts everything in the database, no files. xwiki can do that, it's a breeze. I don't know of a cms that does away with the clunky code + files + database that you have to constantly juggle.
I agree
I am not a full time drupal dev with years of experience, but I do have some experience with Drupal 6,7 and 8. I also have a lot of experience with OOP and also PHP and Symphony experience.
Having worked on 2 Drupal projects recently within our team, I can honestly say that working with Drupal has complicated things immensely. At the time we believed that it was the right tool for the job, which is why we chose Drupal. However, we realised that building a website with a small amount of business logic has become so complicated that it would be easier just to use something else like Laravel as an API and build your own front end. Or use a BAAS or something similar. I have never been against Drupal and have even promoted it throughout the years, but recently I feel like it's become really cumbersome and complicated and I found myself constantly fighting against the internal Drupal rules and systems.
In our team, with the Drupal projects we work with, we constantly run into one issue after the other. It's a lot of trivial stuff, but in many cases feels like a simple problem should have a simple solution, not an over engineered solution. For the most part everything works fine, but it feels like it has certainly moved out of the general "business" space and moved into catering mostly for the "enterprise" space.
I totally agree with you in
I totally agree with you in the way that drupal 8 has become overly complicated. However OOP itself is not a problem here.
To me, the problem is that the drupal architecture starting from the database model and ending with the code is not a good fit for applying OOP. In Russian, there is a saying that can be translated something like "Pulling an owl on a globe", which I think, best describes what is happening now. You have shit ton of abstractions over abstractions plus static legacy code, which I think, will never cease to exist. As a consequence developers will always need to struggle with the components to make them work as they want. To make drupal "fully" OO the whole drupal architecture should be reconsidered. Many things need to be removed to sacrifice flexibility over maintainability, imho. But yeah, making drupal more enterprise-friendly comes with the price. And the price is costly.
Yes I agree, the OOP
Yes I agree, the OOP pretensions are the problem not actual OOP. The problem of the design is the problem of implementing a object-attribute-value OAV framework and have that be the database design. There is a framework I once used called Achievo Toolkit, brilliant OO in PHP in conjunction with a conventional database design. You could even map to a legacy database with ease, or use the output from a professional popular back then known as a "database developer". The "node" class in ATK was a very different notion than the "node" in PHP. ATK went even further than the many Java frameworks doing the same thing, in that it used flags in the node constructor rather than "annotations" (which cannot be dynamic). So ATK was very flexible and could solve business problems and dysfunctional situations that left Java in the dust, of course the problems it solves are then no longer billable, that's why it faded, it's too good too straightforward and too simple to work with so you can't make money with it. It still lives in github.
Wish I'd heard about Backdrop before trying to upgrade to D8...
Came across this comment while looking for answers as to why it's been so difficult to upgrade from D7 to D8.
I've recently gone through quite a lot of pain upgrading one of my sites from D7 to D8 - with the intention of subsequently upgrading to D9 (labelled as the "easiest upgrade ever" on Drupal.org so I was looking forward to that ;) ).
Most of the pain comes from the fact that I am on shared hosting, with no SSH access. Never a problem with D7, but makes using Composer / Drush impossible.
Finally got to the end of all the pain and looked at D9. Sadly my shared hosting doesn't have a high enough version of MySQL. Now this is my bad - I should have looked ahead to D9 requirements and checked. However, it does feel a bit galling that having moved from D7 to D8, with the best intentions, I've moved from a supported version to a now-unsupported version. Big facepalm.
In all my thrashing about looking for answers, this post was the first I'd read of Backdrop. Otherwise I might have gone that way... *sigh*
With all the work I've done so far, I guess I'm looking at changing hosting company to somewhere where I can afford a VPS, so I can use SSH / Composer / a new enough version of MySQL. Anyone got any recommendations?
Or should I cut my losses, throw away the work I've done, and move to Backdrop?
My two cents worth on Backdrop CMS
I can confirm that upgrading from Drupal 8 to Drupal 9 is pretty painless, provided the extensions you rely on have been upgraded.
As for hosting, I've created a note about the hosting options that exist: Wikihandbooks: Hosting options. For all my Drupal 9 sites, I've opted for IaaS, all set up on DigitalOcean Droplets. Yes, this is more expensive than shared hosting, but IMHO, it is well worth the higher price.
This is probably not the right place to ask, as those who prefer Backdrop CMS over Drupal have already jumped ship, and are no longer reading this forum.
But here is my two cents worth: I've decided to stick with Drupal. I create and manage websites for a living, and use Drupal (9) for clients that have ambitious requirements. (I also manage some WordPress and Grav websites for clients who demand less).
I admire the courage of the people behind Backdrop CMS, but their audience are Drupal 7 site owners that currently are frustrated with the process of upgrading from Drupal 7 to Drupal 8/9 . That is not a large audience. Looking at what's going on in their sphere, it seems their main focus is bringing already existing Drupal 7 extensions to Backdrop CMS. That, IMHO, is not very forward looking.
They officially state that: "Backdrop values the needs of the editor and architect over the needs of the developer". That probably chimes nicely with their target audience, but that value is probably not going to attract many developers to their team. To create free software, you need developers. Users (editors and architects) provide valuable contributions as well (e.g.: QA and advocacy), but they're not going to create much quality software.
I think the large pool of third party libraries that are available in Drupal 9 are there because they're easily integrated into the Drupal ecosystem thanks to Symfony, composer et al. It will be much harder to integrate those into the Backdrop CMS ecosystem, if they were to focus on that after exhausting the pool of unported Drupal 7 modules. I believe that is something that is going to make Backdrop CMS less interesting and less relevant as time goes by.
There are considerable Drupal talent in the Backdrop CMS leadership (PMC and CC). I wish those good people had spend their time creating better tools for editors, architects and site builders for upgrading existing Drupal 7 sites to Drupal 8 and later, instead of forking Drupal – but that's water under the bridge now.
Of course, that's just my opinion. I would love to hear other opinions and I would love to be proven wrong about this.
- gisle
Thanks, Gisle, for your
Thanks, Gisle, for your thoughtful and extensive response.
I'm not sure now whether I count as a "developer" or an "editor / architect". Eighteen years ago as a self-employed web developer, Drupal was my day job, and I used it to create dozens of sites. But for the past thirteen years I have been employed elsewhere, mostly developing in C# and .Net, and so Drupal has become a hobby as I maintain a number of sites for charitable organisations in my spare time. As I read more about Backdrop, I feel that maybe it's more suitable for me now than Drupal is.
Whether or not I make the move, I'll always be grateful to the good folks in the Drupal community. I've benefited from a lot of people's hard work when using Drupal, and received a lot of help in forums, etc, which always seemed very willingly given. So thanks folks.
You all should Just admit it!
You all should Just admit it! Drupal 8/9/10/11/12 is one big pile of shit 1000% more complex and time consuming than 7. And it is not faster!!!! I think this tells the whole story.
You all should Just admit it!
Very true. It went from the everyman's CMS in D7, to the enterprise CMS in D8. With that complexity comes a lot of flexibility and power. But the requisite learning is more than the everyman is going to want to put into it.
As someone who has built dozens of D6, D7, D8 and now D9 sites, I can assure you that it is indeed much faster - if used with the D8+ caching APIs. I was never able to achieve any speeds on D7 like the speeds I get from D8 sites. But, it requires an understanding of the D8 caching layer that was not part of D7.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Can you please send a link
Can you please send a link for good resources about Drupal caching APIs if possible. I have found it hard to understand to be honest (probably because of lack of time). I'm using Drupal Cache + Views Cache + Custom cached services + Varnish + Nginx, however very often I need to disable the cache system because of unexpected behavours, for example: some pages build in views, are not accessible, because the user is permanently redirected to user page instead (without any errors). The "only" solution for "fix" is to clear browser cache... I tried to increase the size for cache on server, but it only partially help (people with slower PC's will be suffering anyway).
Also when I buy the theme, I'm founding out that these themes are slowing down the Drupal's responsiveness very often.
I would be great if can have a "cookbook" with the recipes for optimising the website, like step 1, 2 3 ect with potential obstacles.
I don't know of a good
I don't know of a good tutorial on caching to be honest. But the two topics to understand are cache contexts - which essentially means the number of different ways an item is cached. For example, a cache context on language will cache the item once for each language. Or you could do a cache context on a URL query parameter, like ?something=value, you could do a cache context on the something query parameter, and the system would make a cache for each version of that URL query parameter. You need to this to add caches for anything that is cached, but should have variability.
The other concept is cache tags. Cache tags are applied to a cached item, and the cache tag is expired, that item will be rebuilt. So if you have a block that is built using data from Node 9, you would add a cache tag for Node 9 to that block. When Node 9 is re-saved (or deleted or whatever), the system will expire all cached items with the tag of Node 9, and they are re-built with the new information when re-requested.
Spend some time googling these and understanding them. Then you can start to learn how you add custom cache contexts and/or tags to nodes, blocks, pages, render arrays or whatever.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Have been with Drupal for 15
Have been with Drupal for 15 years. This is the best post I have ever seen on this forum. Can't say it better.
Drupal 7 EOL extended to November 2023
Drupal 7's End-of-Life extended to November 1, 2023 - PSA-2022-02-23 (Feb 2022), giving more time to decide whether to migrate to Drupal 9/10, switch to Backdrop, convert to static HTML, or something else.
Drupal 7 is alive and well
Drupal 7 EOL was first announced to be in 2020, then postponed to 2021, and then to 2022. It is now postponed to 2023. I've corrected the title of this topic to reflect this date.
Please also note that the November 2023 date is not final. A review will be conducted in July 2023 to decide whether to extend the life of Drupal 7 beyond this.
Drupal 7 still has a huge following. The stakeholders (i.e. the DA, Dries, and the Security Team) are not stupid. There is no way they are going to abandon its market-share just like that. As long as there is a sizeable amount of websites that depends on Drupal 7 (as of today, Drupal 7 accounts for a little more than half (52 %) of the installed base for Drupal), and there are someone around willing to maintain it, I am pretty sure its EOL will continue to be postponed (perhaps indefinitely). To just give this huge market-share away to the Backdrop fork (and others, such as WordPress) doesn't make sense.
I hope that the considerable talent that constitutes the Backdrop team will realize that Drupal 7 is alive and well, and return here to help with the continued maintenance of Drupal 7. The numbers speak for themselves: Drupal 7 currently has around 460 000 installs, Backdrop has 2310 installs.
- gisle
Update and consideration about Drupal and future
This discussion should also be updated in light of the latest Drupal developments.
As I commented above, having "forced" the Drupal developers to use Composer has kept a lot of new users away from using Drupal, which I have also considered. Then I studied Composer, I figured out how to use it (nothing so difficult actually) BUT it collides with some objective realities:
- Not all users have SSH access to their hosting (I myself had to purchase a fixed IP with the connection to be able to access via SSH) or DO NOT have the skills
- Many users who would like to use Drupal try it, then find themselves in front of the Composer wall, a community that almost always replies "You do it by writing a module", but NOT all of us are code developers
- Not all projects have the necessary budget to have: a backend developer, a frontend developer etc. And for this many new users have migrated (or stayed!) To Drupal 7 / Backdrop
- In a world where 90% of the operations are done via GUI, instead of going forward with Composer we have gone back (mind you, Composer does not give me any problems, it is the approach that was wrong)
- Let's be honest, the barrier created with Composer and the change from D7 to D8 / 9 has, in fact, created some damage to the base of use
- Let's stop identifying Drupal as a system ONLY for developers / programmers, it is reductive and also at the market level totally wrong as an approach
- Let's also stop saying that Drupal is used ONLY for enterprise sites, I have always used it also for small / medium-sized sites
Then all of the above is destroyed, rightly, with the realization that Drupal cannot force users to use Composer / coding etc. and the initiatives that (we hope) make Drupal more "user friendly" and less difficult are born:
https://www.drupal.org/about/core/strategic-initiatives/project-browser
https://www.drupal.org/project/ideas/issues/2940731
There's a lot here that's
There's a lot here that's right. But, as someone who was once solidly in this frame of mind, I'll be the first to say I was wrong about Drupal 8.
When Drupal 8 came out, I threw my hands up and said no more Drupal. It changed everything I knew about building drupal websites. For someone with barely any experience in php or command line, and who had never used Drush before, this was too much. Symfony? What the hell is this symphony command line I have to learn to now use Drupal?? And I, like you, went to the forums to lament the changes with others. I also posted a long diatribe like this, basically pointing out how the community changed everything and it wasn't clear why.
There's some legitimate concerns here. For example, setting up a basic Drupal site is considerably more complex than say a Wordpress website. I'm building a social media platform in Drupal 9, but I have the landing page for people to signup in Wordpress, largely because it took 5 minutes to get it setup with WP.
With all that said, I am a changed man. I have seen the light and I have come to appreciate Drupal 8/9. It is actually an extremely powerful platform.
First, Twig is a brilliantly simple theming language. I didn't know twig before I learned drupal 8, so it was totally new to me. I also did not know how to code complex PHP templates using conditional statements, etc. But with Twig, I am creating complex and context-based layouts that I was never able to achieve before. And that's because Twig is very easy to learn with simple syntax. My biggest challenge in programming is learning the syntax (all the little punctuations and operators). But twig changes that to almost a plain english style, which I appreciate.
While I have no great experience building custom modules, I can see the power behind the OOP approach in Drupal 8. The ability to call in other classes from other modules with a single line is pretty neat.
Learning symphony invariably forced me to learn command line, and now I do almost all my updates in command line. So hats off to Drupal 8 for forcing me to learn something new.
But, the problem Drupal 8/9 has created is it appears to have pushed a lot of fine folks out of the ecosystem. I went on a hiatus with Drupal for about 5 years. After I posted my diatribe I vowed never to come back. But, I eventually did. Because Drupal is a unique system. It's like getting a big tub of legos as a kid that are from all different kits. There's no clear instruction manual on what to build, but if you know how to use the individual pieces, the limit on what you can build in Drupal is your imagination and technical skill.
Automatic Updates in Drupal 10, ready by fall 2023
Dries announced yesterday (4 April 2023) in The evolution of Drupal's composability: from the command line to the browser the following, which sounds great:
There are currently two major challenges:
To prevent a big exodus of Drupal users and web sites running Drupal, these challenges need to be sorted out as soon as possible, to make them as easy as possible, and prevent squeezing out non-expert site builders, NGO's, small companies, etc.
Since the Automatic Updates feature's planned release is fall 2023, it would make sense to extend Drupal 7 EOL to November 2024, to allow Drupal 7 sites a year to upgrade to Drupal 10, and then have Automatic Updates included.
It would also be great if the upgrade path could be made smoother, by giving even more attention to the open source tool Acquia Migrate Accelerate, and people started blogging about it, creating issues for improvement, etc. to improve it and raise awareness of its existence:
PS. Here's a sister issue to this issue :) #3238659: Postpone EOL of D7 indefinitely (delay the beginning of ES extended support)
Drupal 7 EOL extended to January 2025
I am glad to see that Drupal 7 EOL has been extended to January 2025. This should allow Automatic Updates to be ready. Drupal 7 EoL Extended by 14 Months - Drupal 7 to receive official support till January 05, 2025.
Drupal 7 EOL is postponed to January 2025
The official Drupal 7 announcement about an Drupal 7 EOL extension is now out as PSA-2023-06-07. It is also says "This is the final extension of Drupal 7 community support", and there seem to be some other measures to discourage further adoption of Drupal 7 in the timespan from the summer of 2023 and up to January 2025.
Interestingly, according to the reported weekly core usage statistics Drupal 7 is still the version of Drupal that's used the most, followed by Drupal 9:
I have a few clients (i.e. NGOs) where my company provides hosting and support, but they do their own maintenance and development. For one of them I migrated their Drupal 7 site to Drupal 9 (and then to 10). About a month ago, they told me they wanted the Drupal 7 site back. They had a meeting among the webmasters, and decided that they prefer Drupal 7 over Drupal 10. Things like OOP, Symfony, and "this composer thingy" simply didn't agree with them. I have a feeling that they are not going to be happy when they hear about yesterday's announcement of losing community support in 2025.
The cost of paying for extended support from a third party is beyond the financial reach of these NGOs, and migrating to WordPress or Backdrop is also going to cost a lot – so I guess they're just going to keep on using Drupal 7 beyond 2025, hoping for the best.
PS: As for the other versions tracked, the usage percentages are:
Keep on using a version of Drupal beyond its EOL is clearly not unheard of in the community.
PPS: I have updated the title of the OP to reflect the new expected EOL.
- gisle
They told me they wanted the Drupal 7 site back
If I wasn't so busy doing Symfony related work for clients I'd likely be learning about Wordpress. Symfony Drupal is keeping me very busy and it is getting better but do have some serious deprecation fatigue and long term deprecation trauma to deal with.
Another thing worth noting on
Another thing worth noting on those usage stats is that, while Drupal 7 usage is shrinking, its decline is about the same speed as the decline in Drupal itself. If Drupal was a private, for-profit company, I'm pretty sure a boss would be looking at that graph and saying something's wrong here. Since it isn't, they'll go right along and end Drupal 7 and watch the D7 usage shrink until there's virtually nothing left of Drupal.
Drupal 8+ has become an
Drupal 8+ has become an enterprise level system now, that while extremely complex, is also extremely configurable, secure, and performant. The complexity has led to a smaller number of smaller Drupal sites, because it's a bigger hurdle for the average person to get into it. But it's in wide usage, and increasing, amongst governments and corporations, as it is very well suited to their needs.
Backdrop is a very good branch and continuance of Drupal 7, that sticks with the Drupal 7 style of development, and will be better suited to entities that were happy with Drupal 7.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
I am seriously considering
I am seriously considering going to Backdrop CMS. My only hesitation at this point comes from the fact that its usage is still very small. I am not confident that a new CMS branch will survive and thrive. Which could leave me in a dead end. I guess that would be true of any CMS though so I will probably go that way.
Should I use Drupal today?
I started work with Drupal more than 10 years ago. It was beta 7, and I felt in love with it.
More than 5 years I was an active freelancer and built a lot of project, wrote a tonn of modules for extended logic, import and export data.
More over, I was an enthusiast of automated migration old web sites to Drupal and wrote my own bunch of scripts, parsers etc.
But later my priorities of life had changed and now I far from IT.
In 2020 I built one site on absolutely new for me D9 for my employer as an additional part-time job. It was not simple, but I done it pretty well and fast.
Now I decide to build a site for my current employer. I completely forgot all about Drupal by the time.
Should I use it or I have to choose more simple WP?
If anyway Drupal, which version I have to use?
If you're able to build it in
If you're able to build it in WordPress, you're probably better off building it in WordPress. If you reach WP's limitations however, then Drupal is the tool. Version 10 is what you want to start with.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
For a new site, go for Drupal version 10
Currently, three versions of Drupal is supported:7, 9 and 10. Drupal 9 is EOL in two months (November 2023) and I have already upgraded all my Drupal 9 sites to Drupal 10. It is not a hard upgrade, but I no longer see any reason to start out with Drupal 9. Drupal 7 EOL is a bit over one year away (January 2025), but I have already noticed reduced community support (e.g. the important Devel module is no longer supported for Drupal 7). It is clearly not sustainable to base a new project on Drupal 7 today. For a new Drupal site today, Drupal 10 looks as the best option.
As for Drupal vs. WordPress (et al), well – that's a tough one. WordPress is clearly the easiest of the two to deploy and maintain, in particular if you're not comfortable with the CLI, but it is less flexible and extensible, and does not provide anything like Views except as a premium plugin. Personally, I'm leaning towards Drupal, but I guess it boils down to personal preferences.
- gisle
OK, now I tried to install
OK, now I tried to install D10 in my dev environment and at first look was unable to find any difference with D9.
Probably, I will use it for my new site, because I had a little experience with PHP Symfony 5, know it's infrastructure and basic parts like twig, dql etc. Drush and Composer didn't make a problems for me too.
Now I want to know, if D10 has enough modules, snippets (and free themes!) to create an advanced site, or it like D7 in 2010? In sense that D9 definately has from my previous experience.
Drupal 10 comes with a lot of functionality in core
A noted difference between Drupal 10 and Drupal 7 is that Drupal 10 comes with a lot more functionality in the box. My experience is that you do not need so much to rely on contributed modules when using Drupal 10.
As for themes, I find what's available on Drupal.org adequate, but this comes down to personal preferences.
- gisle
PHP FTW
According to w3techs, drupal and joomla continue to descend. drupal has less than half the market share it had 10 years ago in it's heyday (you remember the celebrity cast of characters back then, that will not return). Shopify Wix and Squarespace are ascendant. WP market share has begun to decline. The none category is still declining slowly. Personally as an IT guy I'd like to see a decline in framework/plugin hell across the board. I'm rooting for NONE. As a drupal WP <insert framework here> professional, you are learning a peculiar form of highly-leveraged quickly-obsolete knowledge, leaving a steaming pile of overreaching unmaintainable insecure garbage for your clients. Can't we just break it all down and build this crap into PHP and use composer to assemble packages? Also for the love of god can we break the code/database coupling and accept Continuous Migration as our personal savior?
You sure can, and nothing is
You sure can, and nothing is stopping you!
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Y'all ruined Drupal.
Y'all ruined Drupal.
I am one of the heaters here
I am one of the heaters here and I have to admit that after strugling a lot and a lot of hair pulling for about 1 year experience with D8/9 now 10, now i like it like i did with D7.
I still have to learn a lot. But in the end its good that you get better at what you do.
Missing Rules module was a huge drawback. But now we have ECA and its even better. Harder but better. This is what Drupal is now, even harder to learn but even better than before.
Walking it back...
I am not a Drupal Dev, I work primarily in Javascript frameworks. A decade ago, I built a lot of sites using D7 and it was great. I came back to build something quickly using D10 and the demo was not a good experience. I installed D10 and spent a couple weekends with it and it's not bad. Y'all ruined Drupal, but brought it back. I could use it some time in the future. Patience and up-skill.
You are silly and very very
You are silly and very very wrong. Today's software could not exist without OOP. OOP facilitates effective software design and maintenance of very complex code bases. OOP gives you fine grained modularity. Nobody is going to develop a complex content management system like Drupal or anything like it in Lisp, Haskel, or C. This message was posted many years ago. No one with any sense would sympathize with this person today. It is obvious the switch to the Symfony framework was an excellent (even necessary) thing to do.
Simpler is always better.
Drupal.org still running Drupal 7
It's been almost 9 years now, will we ever see Drupal.org switch to symfony?
Drupal.org is most likely the largest and most impressive Drupal based system on the planet. It is a proving ground for Drupal and is embarassingly so good that it cannot be "upgraded". We all know by looking at Drupal.org that Drupal 7 is actually handling 4 million nodes, likely over 20 million node revisions, likely over 30 million comment entities, millions of user entities, stable, scalable and reliable. I for one am looking forward to seeing the improvements made to symfony Drupal to be able to handle this kind of scale and performance.
@donpwinston, I suppose the xautoload module doesn't exist in your world?
https://www.drupal.org/project/xautoload
What?
That has nothing to do with what I said.
Simpler is always better.
Edited
***deprecated my own comment***
I've said enough already.
Edited
***deprecated my own comment***
I've said enough already.
Your statement is an amalgame
There's a variety of valid approaches and design patterns and paradigmes that maybe aren't "textbook" in the square sense but still are valid and useful.
One of the first lessons taught in the computer systems program that I followed was to seek for and maintain compatible APIs. Wordpress does a good job of this. 79% of the internet agrees.
Yeah, that's why Drupal.org
Yeah, that's why Drupal.org has migrated to Drupal 10.....wait, what?
Drupal.org is NOT on Drupal 10
Currently, only a few pages have been created (not migrated) on Drupal 10 and they are visible with the “new” prefix:
https://new.drupal.org/
All the main functionalities of Drupal.org are still on Drupal 7.
This means that the most important pages of Drupal.org will not be secure after January 5th, 2025.
/*_*/
http://www.xmacinfo.com
This means that the most
Not exactly. They will be the same pages they were on January 4th. Drupal.org will be on an unsupported version of core at that point. That can result in insecurity over time, but does not equate to it by default.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.