Drupal 8 maintenance is a terrible nightmare

By sprite on 20 Jan 2017 at 09:28 UTC

Drupal8 maintenance/updating is a nightmare.

1. It is readily apparent that Drupal 8 cannot be upgraded by hand because of the giant black hole known as the /vendor directory where core keeps 3rd party libraries/components, and where contrib modules also install yet more libraries/components, all of which must be tracked by various .json files in order to fully recognized by the system.

2. The only way to update Drupal 8 is via the command line using the archaic and brittle, (even poorly named) "composer" utility. It would have been more aptly dubbed "conductor", nor composer.

3. Using the command line utility composer requires:
- command line (CLI) access, something many Drupal users don't have on their server environments
- the CLI php environment needs to be able to allocate about 1GB of memory for PHP in order for composer to run.
- - (see error report below)

4. Drupal is being distributed in some ways, and installed in such a way that it appears extremely difficult to fix so that the archaic and brittle composer utility can perform an update.
- - error reports below)

5. Attempting to run a Drupal8 update via the CLI and a "mere" 512MB of ram allocated to PHP yields the following error:
--
php composer.phar require "drupal/core ~8.2"
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in ./website.net/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.
--

6. Attempting to maintain any Drupal8 components, core or modules, yields the following error on some installed and operating Drupal8 (but not all, and the configuration differences are difficult to ascertain)
----

Problem 1
- Installation request for drupal/drupal No version set (parsed as 1.0.0) -> satisfiable by drupal/drupal[No version set (parsed as 1.0.0)].
- drupal-composer/drupal-project 8.x-dev conflicts with drupal/drupal[No version set (parsed as 1.0.0)].
- Installation request for drupal-composer/drupal-project ~8.2 -> satisfiable by drupal-composer/drupal-project[8.x-dev].

--
(In the context just above, Drupal 8 is installed and running, but the various "assemblies" and the composer code aren't well written enough to recognize that their .json configuration files are incorrect.)

- There have been various reports of bug above, answered by incredibly cryptic responses and even more cryptic "patches" to various .json files and vendor components that claim to fix the problem.
- - (haven't been able to get any of the available patches to work)
----

7. Conclusion

Over time, it is difficult to imagine that the Drupal8 adoption rate is going to be very high, when the system is difficult to maintain, requires command line interface utilities to maintain, and which is essentially a huge black box when something is wrong with its .json configuration file ("assemblies").

Comments

It is readily apparent that

Jaypan commented 20 January 2017 at 10:29

It is readily apparent that Drupal 8 cannot be upgraded by hand because of the giant black hole known as the /vendor directory where core keeps 3rd party libraries/components, and where contrib modules also install yet more libraries/components, all of which must be tracked by various .json files in order to fully recognized by the system.

For this reason specifically, I decided not to use composer for 3rd party library support when updating the jQuery Colorpicker module to Drupal 8. I didn't want to cut off users who can't use composer.

6. workaround ...

sprite commented 20 January 2017 at 11:37

I was able to workaround 6. above.

Separate from the problem installation, I have another Drupal8 installation that is working properly with composer.

I was able to copy over the composer.json and composer.lock files from the D8 installation that works with composer and just use those. I had also copied over other Drupal8 core files in the process as well. However, afterward a full "composer update" re-copies and updates every completely anyway.

Essentially, most installations share a lot of code, so the fact that this was possible makes sense.

With the update composer.* config files, I have been able to use composer to update the entire D8 that couldn't be updated with it before.

I also installed some additional modules using composer.
Installing a module with composer also records it in the composer.* config files.
The module must still be enabled in the D8 modules UI though as well.

Despite all this trouble, it is apparent that in the long run, composer, is the only way to maintain a D8 installation, regardless of the current bugs, problems, and related hassles.

Given all this, my every experience with D8 re-confirms my impression that it remains in a beta condition and that only D7 should be used for production website building.

spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

This is why I still use Drush

onejam commented 20 January 2017 at 14:30

This is why I still use Drush to update Drupal 8 core.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

not a complete solution

sprite commented 20 January 2017 at 19:29

There are some D8 components that cannot be updated with drush, for which composer is the only way to install or update them, such as D8 Commerce 2.x and its dependencies, and others as well.

spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

I've done every update since

fkelly12054@gmail.com commented 21 January 2017 at 01:33

I've done every update since 8.0 (probably at least a dozen) by downloading the tar.gz, uploading to my Cpanel server, extracting into a new directory at the same level as the "old" Drupal8, copying in the new core and vendor directories and most of the files in the root. Usually I leave htaccess alone unless there is a note in the readme.

No command line, no composer, no drush. I'm not even sure I could set them up on my shared hosting service at < $10 per month. I'm not about to spring for a VPS for my limited needs.

Over in the issue queues side of this site, and even here in Forums, there are many experts who disparage doing updates this way ... never update your web site directly! they say. And technically, it appears that Drupal may be headed to an era when composer and command line access is required. I can't tell from all the techno-babble over in the issue queues. Seems like a translation of the babble would go something like: our PHP modules have gotten more and more complex and require libraries that need to be extracted live from the packagist site and we can't possibly go on supporting this at Drupal.org. But I'm not sure that applies to production level (stable releases) Drupal web sites. See:
https://www.drupal.org/blog/drupal-8-will-no-longer-include-dev-dependen...
and note it only applies to development.

I'm not even sure I could set

Jaypan commented 21 January 2017 at 02:08

I'm not even sure I could set them up on my shared hosting service at < $10 per month.

You can install them both for a single user, though your server settings may prevent some parts of them from working.

I've found it perplexing,

adminMN2023 commented 8 February 2017 at 18:23

I've found it perplexing, since starting in Drupal recently, how difficult upgrading is after spending years in Joomla and Wordpress. Had trouble recently with an upgrade to 8.2.6 from 8.2.5 - but it worked after reading your Cpanel method. (so thanks for that!)

If Drupal wants to keep Drupal an exclusive club for Dev's - all Drupal has to do is continue the status quo, and it will scare the faint-hearted away, but with that may go the wide spread adaptation they are hoping for. I will keep plugging away as I'm the audience Drupal wants (I think) and I see the inherent power in it. But paths like upgrade ease, and unpolished cores will be the death knell for many. As primarily a designer - I don't mind forays into code and maintenance - but add patches, composer, drush, questionably polished cores (wrestling with group filters now), and so on and so forth - it takes away from getting the work done. (I want to drive the car - not manufacture it.) :^) Having said all that - I'm pumped about what I think it can do once I get a handle on it.

it will scare the faint

CatsFromStonehenge commented 12 September 2018 at 08:48

it will scare the faint-hearted away

Agreed, but it's not just going to scare off the faint-hearted, I feel like I'm going to have to go through lots of pain to learn how to update something which should be moderately easy. I'm tempted to dissuade a client from using Drupal for this reason.

the nightmare of updates

mrandy543 commented 1 March 2019 at 13:07

totally agree. I have used it for many years, but having just started doing a new site on D8 I have been stopped in my tracks by the first core update . I'm also more of a designer who is comfortable with html and css but not a programmer, and don't really use SSH (or want to start learning it).

The old update method was a bit fiddly but it worked, I figured D8 would have simplified things and to be honest I expected a one click update button for core, like you do with modules in the D7. Instead it has taken a huge step back. My best option now is to switch to something like Wordpress, or maybe stick with D7 for new projects in the hope D9 does something about this and makes it more user friendly again.

I would expect to see a lot of unsecure D8 sites going forward, where the updates get put off by people.

Some help??

tjtj commented 1 March 2019 at 13:20

https://jamesrome.net/drupal/installingDrupal8

But the components in Vendor are not updated

tjtj commented 24 October 2018 at 14:50

If you run php composer update on your freshly extracted directories, you will see that the components inside Vendor (Symfony in particular) are not updated. In addition, you will have to remake drush. Why isn't it included in the distributed Vendor directory.

drush watchdog-show is the only way to find errors when you (so easily and often) get locked out of your GUI by the dreader "server has encountered an error..." message.

Better not use Webform

tjtj commented 2 January 2019 at 14:16

If you install Webform from the GUI, the entities are not set properly. So alas, your solution does not work. I update the way you do and then run composer update, which may or may not work. And with a fresh Drupal core, why are there any updates to things like Symfony?

Core contributors are listening

cilefen commented 22 January 2017 at 03:38

We hear the complaints of people struggling for various reasons to adopt composer workflows. "Technobabble" is how the sausage is made—not sorry about that. Composer is neither archaic nor brittle. It's one of the things credited with saving PHP as a matter of fact. Google it.

"Do not require composer for building sites, do not leave non-experts behind" https://www.drupal.org/node/2845379

I worked in (and managed) a

fkelly12054@gmail.com commented 23 January 2017 at 00:43

I worked in (and managed) a sausage factory for 30+ years. I'm retired. I love using Drupal 8 and appreciate the work that the developers and committers put in. My site, which up to now has used the tar.gz means of installation is current and works fine.
I've spent a couple of hours reading through:
https://www.drupal.org/node/2845379 (Do not require composer for building sites, do not leave non-experts behind)
as well as:
https://www.drupal.org/node/2845378 (Stop offering .tar.gz downloads)
as well as a couple of other threads,
https://www.drupal.org/node/2477789 (Use Composer to Build Sites ... which spans 2 years and 134 comment)
and more recently,
https://www.drupal.org/node/2538090 (Allow the Update Manager to automatically resolve Composer dependencies)

If the Drupal sausage makers can accomplish what Bojanz suggested in #5 of 2538090, everyone should be happy ... basically (as I understand it) embedding composer capabilities in the update manager.

A solution that doesn't work in many shared hosting environments will reduce your installed base considerably.
@cilefen thanks for visiting this side of the tracks and for providing the link as well as the countless hours you spend on Drupal.

Do not require composer for

onejam commented 10 February 2017 at 19:12

Do not require composer for building sites, do not leave non-experts behind

Let's not kid ourselves on. Most of the big Drupal companies here are investing their money, time and contributions into Drupal 8 to complete in the enterprise market. These are the agencies that dictate the direction of Drupal 8 now.

Good or bad, that's not for us to decide anymore as i feel this community is really trying to attract more larger web agencies to contribute and for good reasons, majority of the D8 contributions are coming from large companies.

Therefore, these are the tools you will be expected to use in most large web agencies these days. So either you learn and adapt for this market or move on to something that is aimed at smaller businesses and sole traders, such as Backdrop CMS or WordPress.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

...

Wolf_22 commented 2 November 2017 at 15:37

Sure, it's arguable but from what I've seen, most "big web agencies" launch proprietary and or cloud-specific platforms. Why? Because the market evolves in such a way that clients want coverage for intrinsic and extrinsic situations. CYA. It also affords the given business entity the freedom to bypass additional professional development costs thereby making things like Git, Composer, et al, irrelevant for their staff or clients. Adding to this, organizations or companies hate to waste money on things that frequently change. Sure, today you're keeping up with the Joneses by getting in bed with Composer. Git is fantastic. Drush is the coolest... But tomorrow, it's likely something..."better." (It's always pitched that way, right? Sigh...) Anyway, they hate that chaos because expenses inflate, which enables budgetary chaos, which puts them into a different pivot than what they would normally be doing had they not needed to mess with that noise...

Additionally, while big companies might be investing in Drupal now, make no mistake that they are merely the byproduct of a platform that grew from ubiquitous entry of laypeople, an architecture that fostered melting pots of experiential improvement initiatives that (at one point) were fortunately agnostic of myopic developer tunnel-vision. This is why the Drupal community always rocked: It wasn't held ransom by only 1 particular kind of mindset, and in turn, this seeded the many contributions Drupal (and its community) always enjoyed. Sadly, it looks to be changing for the worse the more Drupal initiatives are strong-armed into what a few believe is tomorrow's fantastic web world.

This whole debacle represents a death blow that could've (at minimum) been softened way before the snowball even began to roll down the hill as the technology exists to fix the entire situation, but despite this, the supposed experts, inner-circle, whoever decided to overlook this fact through sacrificing the core values of the Drupal community with a rigid my-way-or-highway mantra. This never works and in some way or another, it will come back to bite. In fact, one could argue that it's happening now.

Disagree

CatsFromStonehenge commented 12 September 2018 at 08:52

You seem to be the classic developer making excuses for something remaining difficult. I've come across some developers before who get off on making and retaining complexity, when a simpler method could be utilised.

Note, even trying to install drush was a hassle on my server. I followed the instructions (http://docs.drush.org/en/master/install/) but there is no drush in /vendor/bin. It looks like I have severe pain ahead. I'm seriously tempted to dissuade the client from using Drupal, and to move to WordPress instead. It will be far easier moving the Drupal 8 prototype to WordPress, than learning the obfuscated and overly complex update procedures.

In actual fact...

cilefen commented 12 September 2018 at 09:08

In actual fact I was pointing at a mainstream industry practice and saying “this is mainstream”. You interpreted quite a bit out of that!

Fair enough

CatsFromStonehenge commented 12 September 2018 at 09:42

Fair enough, but there ARE lots of developers out there who do intentionally love generating and retaining complexity, due to reasons of ego or ignorance. Ignorance that complexity means brilliance.

To quote Einstein:

The definition of genius is taking the complex and making it simple

I have always tried to make my code easy to understand, by adding comments, and avoiding obfuscated code, even if that meant a slightly longer-winded piece of code (which modern compilers would make the same anyway).

I've seen lots of people defending the complex nature of Drupal updates. None that I've read, convince me that it is anything but ego or having fallen in love with complexity for other reasons.

There's a cognitive delusion happening with Drupal. I've seen people say it's more secure than WordPress, but if updates are more difficult, then people will apply them less often, thereby leaving security holes. It's also easy to add two-factor authentication to WordPress's admin login. There doesn't seem to be much common sense being used in the conversations. I see defence-mechanisms kick-in whenever Drupal is fairly criticised. Instead of Drupal developers saying, "Hey, what a good idea", I more often see them say "Yes, BUT, blah blah blah, so no improvement needed". This is so arrogant. Let's be honest about this.

PHP is archaic

alex.a commented 1 January 2019 at 23:43

"Composer is neither archaic nor brittle. It's one of the things credited with saving PHP"

It seems that PHP is archaic and brittle. I wish Drupal 8 was written in another language like Go or Java, or even Python (as others have done), where it could continue the great Drupal concepts (Content Types, Fields, Views, Modules, Themes), while freeing itself from PHP's limitations. Seriously, if you went through all this trouble to refactor Drupal 8 in such a major way, why did you stick with PHP? If you had used Java, you might also be able to keep backward compatibility with Drupal 7 modules, by using an embedded Java PHP interpreter and a compatibility layer.

Big projects need packaging, 3rd party libraries, code reuse, and deployment systems that other languages have had by design from the start (e.g. Java's packages and jar files). Composer promised to fix these PHP deficiencies, but Drupal's adoption of it is half baked (still in 2019), so there are issues like: Should I use composer as a development tool (like jar/maven for Java, or make/gcc for C/C++), or as a distribution tool (like apt)? What is the recommended way to install Drupal or its modules? Should I use the tar files or composer? Should I use composer directly in the production server, or use it in a development/staging box and then copy the resulting file tree to my website? If I use the tar files, how come some modules require composer? What is the purpose of the geofield tar file in drupal.org/project/geofield, if the installation instructions state that I should install it with "composer require drupal/geofield"?

If composer lets people reuse 3rd party code, so modules are no longer restricted to the facilities provided by Drupal, then how come all the code in the examples and in the contrib modules belongs to "namespace Drupal\..."? Can I write a module with a class that uses my own namespace that doesn't have "Drupal" in it? In Drupal 6 and Drupal 7, I could write a module named "mymodule" that had a class named MyModule in a file called MyModule.inc that did not mention "Drupal" at all. I could then use this class from any other drupal module, simply by adding "dependencies[] = mymodule" in the .info file. The only attachment my classes had with Drupal was that they had to be packaged in drupal modules, but if I really wanted to use them elsewhere, I could repackage the same code differently without changing the class files at all. In Drupal 8, the same class would have "namespace Drupal\mymodule" in it. This seems a step backward. Why does the Drupal 8 Island suck my classes in its namespace?

It seems that PHP is archaic

Jaypan commented 2 January 2019 at 02:53

It seems that PHP is archaic and brittle. I wish Drupal 8 was written in another language like Go or Java, or even Python (as others have done), where it could continue the great Drupal concepts (Content Types, Fields, Views, Modules, Themes), while freeing itself from PHP's limitations.

Which PHP limitations are holding Drupal back?

Seriously, if you went through all this trouble to refactor Drupal 8 in such a major way, why did you stick with PHP?

What is the argument for not sticking with PHP?

If you had used Java, you might also be able to keep backward compatibility with Drupal 7 modules, by using an embedded Java PHP interpreter and a compatibility layer.

Maintaining backwards compatibility has until now not been a goal of Drupal. The idea is to keep core slim and lightweight, and not maintaining legacy code.

If they had switched to another programming language for D8, it would have essentially lost all D8 developers. The small number that also have the other language as a skill may be able to switch over, but the rest would be left behind. This to me seems like it would be the death knell for any project, to lose 99% of its developers.

Which PHP limitations are

alex.a commented 2 January 2019 at 20:51

Which PHP limitations are holding Drupal back?

The limitations that composer is trying to solve. You said that composer "saved" PHP. Saved it from what?

Using another language for Drupal is somewhat of a crazy idea. I put it out as a hypothetical thought experiment.
The article that I mentioned described a team of Drupal Developers switching over to Python. One of the reasons was PHP's long term decline.

I see these PHP limitations that have caused Drupal to waste a lot of time catching up with language features that are taken for granted in other languages:

A site starts showing warnings when switching to a new version of PHP (e.g. running D7 on PHP 7.2).
Refactoring from procedural to OOP. In other languages you would have done OOP from the start. On the other hand, doing OOP from the start doesn't prevent the need for a major refactoring later, but at least you'd keep the same paradigm.
Changing the way classes are loaded (and written), using namespaces, etc. Other languages got this right by design.
Using more 3rd party libraries (getting off the island). That's the norm in other languages.
And even keeping backward compatibility might be easier with other languages that have interfaces which make it easy to make adaptors that adapt an older API to a newer one and abstractions that isolate the implementation from its use.

The idea is to keep core slim and lightweight

Then how come it expanded 10x from D7 to D8?

A compatibility layer would not have to be in core. It could be a separate package that would be dependency only for old-style modules. The backward compatibility problem is another topic, but I mention it as it relates to the choice of language.

I generally like the changes in Drupal 8, and I admire Drupal's boldness in making such widespread changes. I may even come to like composer. But, I'm also frustrated, along with many others, with several issues, the latest of which is:

Unclear and incomplete installation procedures (composer vs tar). This is a new problem in D8 that didn't exist in previous versions.

The limitations that composer

Jaypan commented 2 January 2019 at 22:15

The limitations that composer is trying to solve.

Composer is a PHP library manager. It is not part of PHP at all. Are package managers part of other languages? If they are, then how is Composer as an external system worse off than package managers that are part of the core language? Honest question, as I did not know that other languages had this functionality. And what other limitations does PHP have as a language?

You said that composer "saved" PHP. Saved it from what?

That wasn't me. And I don't feel PHP needs or needed saving - it's one of the most widely used programming languages in the world.

I see these PHP limitations that have caused Drupal to waste a lot of time catching up with language features that are taken for granted in other languages

Ok... but I'm not seeing the problem here. You said PHP didn't have those things, and now does. So what exactly is the problem?

Then how come it expanded 10x from D7 to D8?

That doesn't follow. If they had kept support for legacy code, it would have expanded 20x, and taken twice as long to develop.

Unclear and incomplete installation procedures (composer vs tar).

Personally, I think they should stop trying to pretend Drupal 8 can be installed without Composer. Composer is a requirement. At first, one I really wasn't happy with, due to the additional overhead in technologies developers would have to deal with, particularly since Composer is a command line tool. But now that I understand it, how it works, and how it can be used to manage a Drupal site, I see why they went this route, and beyond that, I have a hard time seeing how Drupal 8 could be Drupal 8 without it. There is an initiative to create a GUI to be able to manage Composer functionality through the admin interface. I think that will improve things significantly when it is released.

PHP composer vs Java maven

alex.a commented 3 January 2019 at 09:24

"Composer is a PHP library manager."

It is as you say. I'm trying to figure out why it's causing such pain for Drupal users.
For reference, Java packages classes into jar files, which are just zip files with a .jar extension. They resemble Drupal's tar or zip files for modules, except that they are not meant to be unpacked for deployment. A typical Java application may have lots of jar files in a directory. A jar file may have several packages (e.g. namespaces), just like a Drupal contrib tar.gz file may have multiple modules and multiple namespaces. A commonly used library manager for Java is maven, which seems very similar to composer. It uses an xml .pom file per library (like composer.json/composer.lock) that defines dependencies. Maven is used to compile java code (thus creating jar files), to download dependent jars from a central or other repositories, etc. But it's clearly a development tool only. It's not used to install an application at a production machine. And it is not even required to be used by developers. It just makes things easier, because it is widely used. There are also competing dependency managers. In my view, Drupal should use composer like Java projects use maven.

"Composer is a requirement."

If Composer is not used at runtime, it should not be a requirement. In fact, it should not be a requirement for the end user or the end developer at all, except for contrib modules that are distributed through drupal.org (so that drupal knows how to find their dependencies). The requirement for the site builder should be where modules and libraries are placed. I should be able to use another package manager, other than composer, to accomplish that. Drupal's module system where I drop a module in ./modules and a library in ./libraries seemed to be working well. Why let composer dictate a different way? If I know what libraries a module uses, why should I not be able to install those libraries at my Drupal site by hand? If I find that it takes too much time to chase all dependencies, then I may be convinced to use composer to save time, but forcing users to learn composer in order to install one module with one dependent library is contrary to the PHP way of doing things simply by dropping code to the right place. Composer could be highly recommended to build a directory with Drupal + contrib modules, which can then be deployed at a production site.

What is the proper place to ask questions and discuss composer in Drupal? Is the "ideas" project the right place?

Composer issues

ressa commented 3 January 2019 at 10:11

Thanks for sharing your thoughts @alex.a. I see Composer as the biggest blocker for Drupal growth, and agree with much of your criticism. Here are a few issues where Composer is being discussed:

It can be fixed

alex.a commented 3 January 2019 at 16:20

"I see Composer as the biggest blocker for Drupal growth"

I'm sure it can be fixed. I'm surprised that it hasn't been fixed yet. It doesn't seem such a hard problem.

Please help in that case.

cilefen commented 3 January 2019 at 17:32

Please help in that case.

An aside on PHP

alex.a commented 3 January 2019 at 09:55

"You said PHP didn't have those things, and now does. So what exactly is the problem?"

The problem is that it took so long for PHP to add these things, which has slowed Drupal down. And PHP still does not have things that Drupal/Symphony already uses (@ annotations).

PHP did not have a standard way of using packages or classes. It used to be "include" or "require". Now it seems to be "use". For reference, Java has had a single way to reference classes and packages from day 1, that allowed it to use lots and lots of libraries, without naming conflicts:

package org.example.mymodule;

import org.example.drupal.annotations.FieldFormatter;
import org.example.drupal.Class1;

@FieldFormatter(id="code",fieldTypes={"string"})
class Class2 {
    void foo() {
        Class1.doSomething();
    }
}

Java has annotations (which were added to the language after a few versions). Drupal/Symphony uses similar annotations but they are in comments (evidently because they are not part of PHP). So comments contain code (!), and removing a comment breaks the application!!


namespace Drupal\mymodule\Plugin\Field\FieldFormatter;

use Drupal\Core\Field\FormatterBase;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;


/**
 * @FieldFormatter(
 *   id = "code",
 *   label = @Translation("A-Code formatter"),
 *   field_types = {
 *     "string",
 *   }
 * )
 */
class ACodeFormatter extends FormatterBase implements ContainerFactoryPluginInterface {

I wonder how Drupal can last

diego.paroni commented 16 October 2017 at 20:00

I wonder how Drupal can last for a long time, if most of its users, who worked well with drupal 7, will migrate to simpler cms, leaving the Drupal community ever smaller.

I have asked myself the same

7loops commented 2 November 2017 at 00:09

I have asked myself the same question. I see a lot of issues and not just composer related. I hope things turn around some day but for now it doesn't look promising.

Yeah, I built and maintain

michaelw_dc commented 9 March 2018 at 05:45

Yeah, I built and maintain several Drupal 8 sites, and I gotta say. This new Drupal is turning me off from Drupal--not because of Composer, but because of all the other problems I've run into. Updates have gone from being moderately troublesome 1 time in 4, to critically troublesome 1 time in 2.

I'm having a hard time imagining Drupal maintaining its market share with this. Here's hoping things smooth out. Now back to my late night efforts at troubleshooting my latest Drupal 8 update problems.

Continuous updates on Drupal 8

andreaciravolo commented 12 March 2018 at 06:54

Continuous updates on Drupal 8
Definitely an obsession. I totally agree with you.

Agreed!

Matt B

English

commented 21 August 2018 at 05:58

I will not be upgrading or installing another Drupal 8 site. It is now far too complicated. I'm sure the devs and contributors think Composer is great and wonderful, but it the problems outweigh the benefits for everyone else.

Agreed

CatsFromStonehenge commented 12 September 2018 at 08:54

Yes, I'm going to dissuade a client from using Drupal. She was persuaded by a friend of hers who loves Drupal, that it is powerful and amazing, he's the sort of person who mocks WordPress. However, WordPress makes updating easier, which means more WordPress sites will be up to date, and they'll, therefore, be more secure!

I have definitely abandoned

massimoi commented 3 October 2018 at 15:27

I was an expert in D7, I've studied a lot of D8 and made some sites (3-4).

Every time I need to upgrade or add a module, it's a nightmare...

I will migrate to something else, but D8 bye bye

I can empathise

CatsFromStonehenge commented 3 October 2018 at 22:10

I don't blame you. The developers who have the expertise to fix this don't listen or justify the nightmare as being ok. Upgrades are needed so often that not fixing it becomes ridiculous. I've been asked to use D8 by a client, however, in future I will just turn down the work. I'd rather be less well off than to have to tolerate the BS of D8 upgrades... that's how bad it is.

Developers listen:

cilefen commented 3 October 2018 at 22:21

Developers listen:

https://www.drupal.org/project/ideas/issues/2958021

I know this comment will be attacked, yet here I am, still trying to help you.

Agreed. I'm considering ditching Drupal for this reason.

CatsFromStonehenge commented 12 September 2018 at 08:43

Yes, for this very reason I am tempted to dissuade a client from using Drupal, and instead persuade her to allow me to develop her website using WordPress.

I am guessing I'll have to spend a few days learning how to update Drupal. I had a development website that's now permanently broken due to a drush update. I feel the update process is developed by people with no interest in making it easy, but instead are on some kind of ego trip with intentionally making things difficult. That's a harsh accusation, but like I said that's what it SEEMS like. If that wasn't people's intention, then they've succeeded in it seeming that way.

I am dreading the day ahead, learning how to use drush. I'm even struggling to install drush. I followed the instructions here http://docs.drush.org/en/master/install/, but there is no vendor/bin/drush after following those instructions. It's difficult not to feel a bit angry.

Sorry you feel this way. But

onejam commented 12 September 2018 at 19:15

Sorry you feel this way. But if you want to keep up with today's development, there's nothing egotistical having to use these tools because it can help simplify your workflow as things are becoming more complex due to using 3rd party vendor libraries to add the additional functionalities. This is why we need composer as it helps to manage and update all the required 3rd party vendor libraries that Drupal 8 requires.

Otherwise, an alternative drupal you might want to take a look at is https://backdropcms.org/ It is a version of Drupal 7 (extended).

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

Composer is a bit of a

Jaypan commented 3 October 2018 at 22:47

Composer is a bit of a nightmare to figure out how to use with Drupal, as there doesn't seem to be a comprehensive guide to using Composer with Drupal, anywhere. I've actually written a 3-part blog post on this, and will be publishing it in the next couple of weeks. I gave up on Composer when I was originally using it with D8, and managed to hack something together. But now that I understand how to use Composer and Drupal together, they actually make Drupal maintenance a dream - if you understand it. If you don't, it's a nightmare.

Fortunately there are efforts to make it easier for developers to work with, that should improve things for developers.

Thank you

Matt B

English

commented 4 October 2018 at 05:15

Thanks Jaypan, I look forward to reading the blog! The fact it needs to be in three parts to explain this says something though...

The fact it needs to be in

Jaypan commented 4 October 2018 at 05:40

The fact it needs to be in three parts to explain this says something though...

It says I'm too pedantic! :D

:-)

Matt B

English

commented 4 October 2018 at 05:46

:-)

Sounds great, I also look

ressa commented 4 October 2018 at 07:36

Sounds great, I also look forward to reading it! Remember to post a link here when it is ready, or perhaps will it show up on Drupal Planet?

Sounds great, I also look

Jaypan commented 4 October 2018 at 12:08

Sounds great, I also look forward to reading it! Remember to post a link here when it is ready, or perhaps will it show up on Drupal Planet?

I'll post a link here for sure. I don't think it will automatically show up on Drupal Planet, though I'll look into how to make that happen.

Awesome, thanks. Getting your

ressa commented 4 October 2018 at 12:23

Awesome, thanks. Getting your blog posts on Drupal Planet would give many more Drupal users a chance to read them, and the more focus we can get on developing and documenting Composer best practices, the better.

One of the rules of usability?

CatsFromStonehenge commented 4 October 2018 at 09:53

One of the rules of usability?

If it needs a big instruction manual then the design is convoluted. Exceptions? Large Hadron Collider.

WordPress updates are easy. You could write a simple single web page describing how to do it.

Can you see the problem?

Jaypan commented 4 October 2018 at 12:02

Can you see the problem?

Yes and no.

I see it as a problem if you don't understand it, it's definitely a usability issue. But on the other side, as someone who understands how to use it, I actually think it's really good. Not to say it couldn't be better, but it's a major step up from any earlier version of Drupal. As a developer, I wrote custom code for soooooo many things I saw elsewhere, that had no Drupal equivalent. Rebuilding the wheel in Drupal. Composer extends Drupal to the entire web, and lets you re-use code from anywhere, not just Drupal.org. Let me give an example.

In Drupal 7, I wrote a number of modules that integrated with 3rd party sites using OAuth2 authentication. Originally, I wrote my own custom Drupal code to do the integration, then I started using the OAuth 2 module to do this. But the OAuth2 module itself was a custom Drupal integration with OAuth 2, and required Drupal developers to maintain it on a Drupal level.

With Drupal 8, when I want to integrate with say Instagram, I do the following:

1) Create a custom Drupal module

2) Add composer.json to the module, and include the dependencies to the official (or at least best maintained) instagram PHP SDK for integrating with their API.

3) I call that library from the module I developed.

Now when the module is installed with composer require drupal/mymodule, composer will automatically include the Instagram library into the vendor folder, and my module can use it to integrate with Instagram. If there ever any changes to their API, the SDK is updated as well, meaning I don't have to go in and redo my whole Drupal module, I can just change the integration with the library. If I've coded my module in an API fashion, Drupal sites that use my module will not even see or have to make any changes whatsoever, as they should never be calling the SDK directly, only calling functions in my module that integrate with the SDK.

The move to Composer was the correct move to make in the long run. Unfortunately, it's not been an easy switch, a major part of which is the lack of proper documentation - which has always been a problem throughout the Drupal community, though one that has been improving a lot as of recent years. It most definitely could have been done better, but right now the focus needs to be on improving both documentation so that people aren't left confused, as many posters in this thread clearly are (including myself, if you go back to my first reply in this thread). Fortunately, there are initiatives in place for this, and hopefully we can see a much easier UX for site builders and developers.

Sorry, I wanted to address

Jaypan commented 4 October 2018 at 12:07

Sorry, I wanted to address this other point in as separate issue:

WordPress updates are easy. You could write a simple single web page describing how to do it.

How long is a piece of string? I could make my three-part article/blog into a single web page, or I could even scale it down into a couple of pages in Word. But one of the major issues here is the lack of documentation, so I wanted to write something clear and distinct in detail, in an easy-to-understand manner. So I organized it into four articles. Not all of it will need to be read, as I broke it down into:

Past 1: Understanding what composer is, and how it works.
Part 2: Managing a Drupal 8 site with Composer and GIT
Part 3: Converting management of an existing Drupal 8 site to Composer and GIT
Part 4: Composer and module/theme development

So the update process itself is really only part 2, and most site builders would probably only ever really need to read that part, though part 1 would make things more clear for them.

Life after drupal...

Matt B

English

commented 18 October 2018 at 18:21

https://torchbox.com/blog/torchbox-has-dropped-drupal/

Are you planning to learn

onejam commented 23 October 2018 at 06:36

Are you planning to learn Python as well? this is more developer centric framework. The great thing about Drupal is having an UI for site builders to accomplish a lot without having to write a lot of code. The trade off is it takes more time pointing and clicking about but building custom modules would have taken even more time and resource. Wagtail is great for developers that want to get things done quicker in code.

My only complain about Drupal 8 is the lack of modules, which now makes it a very costly upgrade process than previous versions. However, it has been said that future Drupal version will be backwards compatible so once moved to Drupal 8, i hope we can put all this major upgrade mess upgrade behind us moving forward.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

Not planning to learn python,

Matt B

English

commented 23 October 2018 at 06:35

Not planning to learn python, the point is the arguments given for moving away from Drupal.

If you are assessing other

onejam commented 23 October 2018 at 06:44

If you are assessing other open source cms, have a look at: https://www.concrete5.org/

Concrete5 already have what is called 'Layout Builder' which is still experimental in Drupal 8 built-in for over a year now. Personally, i think it's a bit more way ahead of Drupal in this area but lacks many modules to extend the system.

-----------------------------------------------------------------
We build engaging websites and intuitive designs that will benefit your business.
Duvien

I agree that this is a Nightmare

tjtj commented 24 October 2018 at 14:59

I upgraded one of my sites from Drupal 7 to 8.6.2 yesterday and took notes as I went along. I think that these steps are all required to do it (although there are still site errors after the upgrade. I would appreciate comments from the Drupal experts:

Create a database, database user (with all permissions) and a database user password. Most hosting environments let you do this from a mySQL link in the Control Panel. You can administer the database using phpMyAdmin, also accessible from the Control Panel.
Unpack the Drupal 8.x distribution in a directory and open that directory in a Web page.
Follow the installation instructions and eventually you will be shown the site home page.
Be sure that your webpage hosting environment for PHP is at least PHP 7.0. The newer the better. Be sure that your command line PHP version is also at least 7.0. The command-line php version may be a blocker. It is still version 5 on 1and1, for example.
Install composer by putting this php file into the Drupal directory https://getcomposer.org/installer. Run the installer:

php ./installer
Link composer.phar to composer (for convenience):

ln -s composer.phar composer
Install drush using composer:

php composer require drush/drush

ln -s vendor/drush/drush/drush ./drush
Although Drupal has a GUI interface for managing modules, in Drupal 8 it is better to install them using composer because it correctly makes the two composer.json and composer.lock files. Also, they are placed in the modules/contrib directory rather than in modules. Unless you are doing Drupal development, use the --no-dev option in the following:

php composer update --no-dev

Confusingly, it asks you

Discard changes [y,n,v,d,?]?

y - discard changes and apply the uninstall

n - abort the uninstall and let you manually clean things up

v - view modified files

d - view local modifications (diff)

? - print help

and you want to answer yes. Answer yes a second time to actually update the symphony files inside the Drupal distribution
At this point, it is a good time to check that your site is still working. Check for errors:

./drush watchdog-show

or do this from the GUI Reports/Recent log messages. Using drush can help you to find errors if your GUI breaks with the infamous "The website encountered an unexpected error. Please try again later." message.
Update your database using the update.php web page, or using drush

./drush updatedb
Now install your initial module set using composer. I recommend stopping occasionally to check that your site is still working. Installing admin_menu totally trashed my site. If you are updating your site from a previous version of Drupal (6 or 7), install all of the modules that were activated in your old site, and make a list of those unavailable in Drupal 8. Using composer to install modules also installs their required libraries; installing from the Extend menu does not.

php composer require drupal/your_module_name
While you are doing the above, use the GUI Extend web page to find and activate each newly-installed modules to be sure nothing is going wrong.
Clear your caches after any big change to see the result

./drush cr

and now is a good time to back up your database using phpMyAdmin. Also zip up your Drupal directory, for example:

zip -r d8-10-22-2018.zip d8
Every time there is an update for the Drupal core, you need to replace the core and vendor directories and all of the .php files in the main directory. You then must run steps 7 and 8 and 10 again.
You should now run a status report. You will probably find the following, but you should NOT fix this until your site is moved to its final location.

TRUSTED HOST SETTINGS

Not enabled

The trusted_host_patterns setting is not configured in settings.php. This can lead to security vulnerabilities. It is highly recommended that you configure this. See Protecting against HTTP HOST Header attacks for more information.
If you are upgrading from a previous Drupal version, now is the time to run your update. Be sure to install all of the update modules first.

https://www.drupal.org/docs/8/upgrade/drupal-8-migrate-modules

especially Migrate Drupal UI unless you wish to upgrade using drush. It is a good idea to copy all of your public files to the new site (if you want them) before the upgrade.

That sounds like a hassle,

Jaypan commented 24 October 2018 at 23:41

That sounds like a hassle, but it looks like you had it easier than it can often be.

That said, that is about upgrading between Drupal versions, whereas this thread is about maintaining a D8 site with Composer, which is a fairly different topic, though there is some relation insofar as how you would upgrade from drush managed D7 sites to a Composer managed D8 site.

It is much harder on Drupal 8

tjtj commented 20 November 2018 at 14:55

The big issue to me is that the Drupal 8 maintenance GUI essentially should no longer be used. That makes it hard for every user. If Composer is the way to go, why wasn't it baked into the GUI? For example, why doesn't Extend/Update just run composer update? And the Install new module option should run "composer require drupal/new_module".

I now dread Drupal core updates. It IS a hassle, and it is still too easy to screw up your site. In addition, Composer requires 768 MB of php memory to run, and the cheapest hosting options do not provide this, so it has cost me more money to run Drupal 8! See https://jamesrome.net/drupal/hosting

That makes it hard for every

Jaypan commented 20 November 2018 at 19:51

That makes it hard for every user. If Composer is the way to go, why wasn't it baked into the GUI?

This is an initiative that is being worked on at the moment.

In addition, Composer requires 768 MB of php memory to run, and the cheapest hosting options do not provide this, so it has cost me more money to run Drupal 8!

You don't actually need Composer on your production server. Part two of my blog series will go into that (I'll add a link to this thread when I post it later this week).

I think therein lies a lot of

adminMN2023 commented 20 November 2018 at 19:57

I think therein lies a lot of the issue. People think composer is required. Hardline devs want you to think Composer is required. Composer, for people that want to deal with it DOES make it easier regarding upgrades and maintenance. However - it takes a whopping 3-5 minutes to upgrade via FTP. I could probably do it in 2, but I get methodical and set in my ways.

When Composer is part of the GUI - I will adopt.

Having said that - Jaypan's post is awesome at explaining what Composer is and how it works. He's made a lot of unsolicited effort for the collective good.

I'll add to the thanks for

fkelly12054@gmail.com commented 20 November 2018 at 21:53

I'll add to the thanks for Jaypan's article. It's a valuable start to explaining a complicated and confusing topic. I'll also add to the statement that you don't want Composer running on your production server updating your production site. And I doubt it will ever work properly on the type of inexpensive shared hosting plans many of us use.

I've hacked around enough to get a 8.6.3 site running using Composer on a Windows 10 computer with Wampserver. Amazing what it can do quickly that way once you get through the involved setup process. I've even tested getting a few of my contrib modules installed and my contrib theme. That works but it's going to be a bit of work to get ALL contrib stuff working and synchronized with the production site to the point where I can update locally and then "push" to production. I'll be interested to see in future articles how the database side is handled. Right now I can dump a database from production and get it running locally but some links are broken. Also, if you have a zillion images in a fairly complicated directory structure under sites/all/files you obviously don't want to be pulling and pushing these from production to local and back. Looking forward to see what the recommendations are for coordinating such files and the database.

I'll also add to the

Jaypan commented 21 November 2018 at 00:30

I'll also add to the statement that you don't want Composer running on your production server updating your production site. And I doubt it will ever work properly on the type of inexpensive shared hosting plans many of us use.

I address this topic specifically in Part 2, and how to deal with it.

I'll be interested to see in future articles how the database side is handled.

This on the other hand is not addressed at all, as DB updates are part of the Drupal codebase, and not related to Composer. Composer manages the Drupal code, and the Drupal code manages the DB. Basically, any time you run

composer install

You wouldn't be doing any harm to also run update.php, or use Drush to do it. It's a good practice.

Exactly

onewomanbiz commented 30 November 2018 at 16:48

Exactly. The trouble with Composer and other third party tools is the bloat and overload on the host server. Not everybody can afford, needs or should require a dedicated server to run Drupal.

Echoing previous posters views, this is just dev voodoo. It take all of 5 minutes max to update versions, whether it be Drupal 7 or 8 through FTP or hosting control panel.

It reminds me of web designers who insist the only way to design a real website is using jekyll or other cmd language. They're like the guy who demands a handcrank to start his car because key or contactless ignition is for the ignorant.

Drupal is supposedly open source, for everyone, yet development seems to be focused on ensuring it require special external ongoing paid services for every install, update or migration.

Live Wordpress sites represents 46% according to Google, Drupal about 4%. That's a metric to analyze if Drupal is to enlarge it's user base.

Echoing previous posters

Jaypan commented 30 November 2018 at 23:00

Echoing previous posters views, this is just dev voodoo. It take all of 5 minutes max to update versions, whether it be Drupal 7 or 8 through FTP or hosting control panel.

If you are running a single production server, with a single developer, that's fine. But when projects become collaborative, with staging, production, and feature branch environments, and continuous development, using a control panel or FTP is simply not feasable, nor even nearly close in functionality to be a replacement for a proper GIT and or GIT/Composer workflow. As Drupal is built to be able to handle Enterprise level sites, it needs to be managable through this type of workflow. For people working a single instance, generally sites like that would be better off being built in a less robust system like Wordpress than in Drupal.

Live Wordpress sites represents 46% according to Google, Drupal about 4%. That's a metric to analyze if Drupal is to enlarge it's user base.

It's not a competition. Sites that can be made in Wordpress almost always should be built in Wordpress. Sites that require the power of Drupal should use Drupal.

If you are running a single

Wolf_22 commented 30 November 2018 at 23:49

If you are running a single production server, with a single developer, that's fine. But when projects become collaborative, with staging, production, and feature branch environments, and continuous development, using a control panel or FTP is simply not feasable, nor even nearly close in functionality to be a replacement for a proper GIT and or GIT/Composer workflow.

The only issue with your comment is that it glosses over project requirements and specifics.

I've personally worked on projects that had multiple environments with multiple people, multiple modules, all sorts of dependencies, etc. We never needed Git, Composer, Drush, Drupal Console... Adding those things into the operations would've only added more headaches.

Another thing... "Enterprise" can mean a lot of stuff. In this case, I think the majority of those within the Drupal community have been using it all over the place without specifying specifics but the 1 constant in every dialogue where it was used was a theme of people being uncharacteristically restricted or restrained from a level of usability and development freedom they once enjoyed with Drupal. So if that's how we're describing this monolithic marvel of technological advancement, then I'd say it fits perfectly. Look, it says a lot about those that have done all this but it also exposes peoples' intentions that are responsible for this mess to begin with. Drupal is not on a good path right now, regardless of the tools one things it should using. There's just too many people out there with a sour taste in their mouth from this situation to reaffirm this.

It's not a competition. Sites that can be made in Wordpress almost always should be built in Wordpress. Sites that require the power of Drupal should use Drupal.

Careful... That comment comes across as arrogant, myopic, and hypocritical all at the same time. You shouldn't start off saying it's not a competition only to basically marginalize those that build sites with Wordpress by describing their efforts using patronize or condescending narrative. Nobody likes that guy and since I've personally seen Wordpress sites that were awesome when compared to some of the best Drupal sites, well, it's just flat-out wrong. Not trying to be a jerk or anything but c'mon. I've seen your posts in the past and I know you're smarter than that.

I've personally worked on

Jaypan commented 1 December 2018 at 00:46

I've personally worked on projects that had multiple environments with multiple people, multiple modules, all sorts of dependencies, etc. We never needed Git, Composer, Drush, Drupal Console... Adding those things into the operations would've only added more headaches.

Figuring them out is a headache. Once you know them, they make things much ~~easier~~ more powerful, and they provide stability in continuous development.

That comment comes across as arrogant, myopic, and hypocritical all at the same time. You shouldn't start off saying it's not a competition only to basically marginalize those that build sites with Wordpress by describing their efforts using patronize or condescending narrative.

What's condescending? Wordpress has better UX and easier content editing, and is simpler to develop in. In my opinion it's much better suited to a large number of sites than Drupal is, whereas for a lot of sites that require the scalability, flexibility in permissions, and ability to act as a hub, Drupal is going to be a better fit. That's my point, it's not a competition, they have different strengths. Wordpress is better suited to many smaller businesses, whereas Drupal is better suited to institutions, government, and enterprise level companies. This is why it's not a competition, and the number of Wordpress sites compared to Drupal isn't really a meaningful number.

Drupal is not on a good path right now

I have to disagree. Our company is dealing with clients in Industrial and government sectors, and Drupal is only getting better and better when working with these industries. Drupal 8 is a technological wonder under the hood. Its data management is second to none. The ability to use it as the back-end for apps, websites, and providing extendable APIs to deliver data is excellent. The ability to use it as a hub (using Composer) is bounds above Drupal 7.

Drupal has turned into a very complex, extremely powerful, amazing system. Unfortunately, this means that many smaller developers have been left behind. The Composer integration is a clear example of that. It's unfortunate, but that doesn't make it a bad system, it just makes it a less appropriate choice than others (like Wordpress) for many developers.

the power of Drupal

onewomanbiz commented 1 December 2018 at 00:51

The power of Drupal? Marketting hype. World class sites, government and enterprise level websites are running on Wordpress. In fact the vast majority of Enterprise CMS based websites are Wordpress. That speaks volumes to WordPress's flexibility, useability, power and robustness in the real world.

"It's not a competition", Who said anything about a competition? Market share speaks to real world business results, competitions are for academia.

Drupal used to have unique features like views that Wordpress lacked but such is not true anymore. At the end of the day both are good CMS.

I love Drupal and use it every day, as well as WordPress. However, when discussing with client's the option to go down the Drupal path, it's essential they be aware of issues and business constraints, now and future, no update automation, very heavy server bandwidth usage, requirements for external installs like composer, the very limited (compared to WP) number of core feature extensions among others.

The power of Drupal?

Jaypan commented 1 December 2018 at 01:20

The power of Drupal? Marketting hype. World class sites, government and enterprise level websites are running on Wordpress. In fact the vast majority of Enterprise CMS based websites are Wordpress. That speaks volumes to WordPress's flexibility, useability, power and robustness in the real world.

It's a great tool!

"It's not a competition", Who said anything about a competition? Market share speaks to real world business results, competitions are for academia.

Well, the comparison was made:

Live Wordpress sites represents 46% according to Google, Drupal about 4%. That's a metric to analyze if Drupal is to enlarge it's user base.

I don't see how that's not an implication that wordpress is leading something, and that Drupal needs to catch up.

I love Drupal and use it every day, as well as WordPress. However, when discussing with client's the option to go down the Drupal path, it's essential they be aware of issues and business constraints, now and future, no update automation, very heavy server bandwidth usage, requirements for external installs like composer, the very limited (compared to WP) number of core feature extensions among others.

And yet, people still use it. One has to wonder why, if it's got all these problems...

What do you mean by "You don

TD44 commented 13 November 2019 at 04:19

What do you mean by "You don't actually need Composer on your production server". Is it not required on production server but it is on dev server?

No, it is not a requirement !

mmjvb commented 13 November 2019 at 08:03

With Composer being a developer tool it has no place on production. Assuming you have separated environments for development, testing and production. It is the choice of the developers to use it in development. You bring the result of it to test and production.

That is a big assumption

tjtj commented 13 November 2019 at 14:44

Most of us using a hosting site do not have the luxury of developing on a separate site. And as I said elsewhere, all the modules now say "Install using Composer." The whole Module GUI in Drupal is something that site maintainers should not use any more! If Composer is required, why hasn't the Extend tab been updated to use Composer?

If Composer is required, why

Jaypan commented 14 November 2019 at 13:50

If Composer is required, why hasn't the Extend tab been updated to use Composer?

It's not technically required, but it's very unclear on how to manage Drupal without it.

That said, there is core initiative to overhaul Drupal and Composer integration so that Drupal is not off limits to people who don't know how to use Composer.

Not entirely unclear at all.

adminMN2023 commented 14 November 2019 at 14:07

Not entirely unclear at all. Don't use extensions that require it. I think, though, fkelly and I are the only D8 users in the universe merrily praddling about without Composer. I learned D8 in a couple months with free videos online, built a decent site utilizing exposed filters to do some pretty cool stuff, and can't write a line of code outside HTML. I am your prototypical non-dev. :^D

I've mentioned elsewhere in

Jaypan commented 20 November 2018 at 05:08

I've mentioned elsewhere in this thread that I was writing a series of articles on using Composer and Drupal. I've just posted the first of the series: Drupal and Composer: Part 1 — Understanding Composer.

Part two should be out later this week, or early next week.

I've now published

Jaypan commented 30 November 2018 at 23:12

I've now published: Drupal and Composer: Part 2 — Managing a Drupal 8 site with Composer

hot button topic

onewomanbiz commented 1 December 2018 at 01:43

No worries Jaypan. have a beer and chill it's Friday.

cheers

I posted that 9 days ago - I

Jaypan commented 1 December 2018 at 03:35

I posted that 9 days ago - I just edited it today.

I've now published Drupal and

Jaypan commented 3 January 2019 at 06:25

I've now published Drupal and Composer: Part 3 — Converting Management of an Existing Drupal 8 site to Composer.

cache

tjtj commented 3 January 2019 at 14:35

Shouldn't users also delete the cache directory?

I've just posted the fourth

Jaypan commented 21 January 2019 at 23:57

I've just posted the fourth of my blog series on using Composer:

Drupal and Composer: Part 4 — Composer for Drupal Developers

The problem isn't with

gippy commented 30 November 2018 at 17:43

The problem isn't with Composer. The problem is that a few project contributors were able to insist that composer be used if the module were used (Address). This broke the maintenance process for THOUSANDS of users who were using Drush to update modules. The Drupal community and its BDFL let them by with it. You can't get a module approved if the indentation of one line of code is anything other than 2 spaces, but you can break THOUSANDS of websites if you are a big player in Drupal. Once you begin using Composer then everything is broken the next time you use Drush to update your website. The guys who suckered everyone in using composer knew better and they didn't give a damn. And they were quite snippy about anyone who questioned using composer. The sorry truth is that the big players in Drupal and its BDFL couldn't care less.

Now I know why

tjtj commented 30 November 2018 at 18:17

But I am very sad. I have 6 sites that are now really hard to manage, even WITH composer.

And why weren't we warned about abandonment of the GUI when D8 was touted as God's gift to mankind.

The guys who suckered

Jaypan commented 30 November 2018 at 23:11

The guys who suckered everyone in using composer knew better and they didn't give a damn.

I seriously doubt that anything was done in the interests of doing anything other than making Drupal a more robust system. I'm open to being proven wrong, but considering the thousands and thousands of hours people put into developing Drupal, almost all of it volunteer, comments like the one above without something to support them are counter-productive. I understand the frustration - I couldn't figure out Composer at first either (which is why I wrote the tutorials I linked to above after I figured it out). But sniping at people who have built the system we all get to use for free, just isn't appropriate in my opinion.

This is the point.

adminMN2023 commented 14 November 2019 at 14:09

This is the point.

Care to elaborate?

mmjvb commented 14 November 2019 at 15:19

@CB1_Dru1 Seriously interested in what you consider to be the point. Not sure we can see what you are replying to. Please elaborate.

Sorry!

adminMN2023 commented 14 November 2019 at 15:32

Sorry!

"... insist that composer be used if the module were used."

This seems to be the tail wagging the dog. Meaning - the scope, or point of entry, in regards to module development was either:

a) short sighted (meaning did not see how dev's would approach module dev)

b) not thoroughly defined (in regards to what dev's can and can't do)

c) or some mixture of the two

Hindsight is always 20/20 though - and so we are at this point. I was really excited to learn Drupal. And found D8 fun to learn. It's just a shame the composer issue/mythos/whatever is such a barrier to entry.

Really really disappointed

ColoradoDave commented 7 December 2018 at 02:22

Been using Drupal for everything since 2007. Really intricate and super-functional stuff. Had lot's of custom modules developed, did a few of my own, worked out complex theming, and so on and so forth. Used it for sites at work, for family, for friends, etc...

I do not consider myself a developer, but I can handle complex tasks on both the front and back ends. I can deploy a Linux Server, install a LAMP stack, create websites from scratch, or use a wide variety of frameworks. I am as comfortable in a CLI as I am in a GUI.

Waited years for Drupal 8. Started using it in late beta for several important sites.

What an unbelievable mistake that was.

Did I say I was not a developer? Drupal was a heavy damn lift pre-D8, but well worth the learning curve and effort to really take advantage of it. I had never heard of Composer or Symphony. I don't know what they do, or how to use them. I have proven I can learn anything .. that is not the issue.

The issue is I ended up spending hours upon hours just trying to get my head around a whole new domain that I HAVE NO DAMN INTEREST IN! I get it, it can make things easier to maintain. It can check for dependency issues. I still don't care.

All I want to do is be able to update the Core when a new update comes out. Update a module when a new module update comes out. After dinking around for what .. over two years now ... I still am running crap old D8 code on two sites because I just am not motivated to take the time to learn how to navigate this latest technology gauntlet. It's running, and I don't want to tear it down and/or break it. I have proven to myself over a long period of time, that it's just not happening. It's time to admit that I have to move on and know I will always think fondly of those D4, D5, D6, & D7 sites I built. I've simply had to drop Drupal for new stuff and the path of least resistance was WP. God I miss content types.

Sometimes people do not realize that exact moment in time when a subtle change in direction, ends up being a complete game changer. This is that fork. Understand, this is not just about my apparent inability to learn the skillsets demanded of me, it's about every single person I build a site for, who are now wanting to use that as the point in which they start learning how to maintain, and edit, and adapt their new website. That's just not going to happen on D8.

Thanks for all the great years Drupal 4-7. I had high hopes for you as well D8, but I just feel like choking the crap out of for being so ignorant of what the market as a whole really needed.

"God I miss Content Types"

adminMN2023 commented 7 December 2018 at 19:20

"God I miss Content Types"

@ColoradoDave - Look up Custom Post Types UI & Custom Fields (plugins) in WP.

---Signed, God

Note to God

ColoradoDave commented 8 December 2018 at 04:17

God, you rock. I had tried Toolset Types which has paid modules .. and then they expire .. and so forth. So this looks great. Will give it a try. Thanks for taking the time to respond.

There is a bit of irony here where the Drupal Forum is the place to figure out how to get off Drupal.

Understand, this is not just

Wolf_22 commented 7 December 2018 at 19:55

Understand, this is not just about my apparent inability to learn the skillsets demanded of me, it's about every single person I build a site for, who are now wanting to use that as the point in which they start learning how to maintain, and edit, and adapt their new website. That's just not going to happen on D8.

Have you tried Backdrop? That's where a lot of people are migrating to.

Backdrop

ColoradoDave commented 8 December 2018 at 04:18

Thanks for the suggestion. Had a look, and it seems interesting since they have a migration tool. Have a great weekend!

"Composer is a requirement."

adminMN2023 commented 3 January 2019 at 13:49

"Composer is a requirement."

-- No, it's still not. Yet people now openly say it knowing it's false.

I think one would find it

cilefen commented 3 January 2019 at 14:50

I think one would find it difficult to install the address module without Composer.

So many issues ... all mixed up here

fkelly12054@gmail.com commented 3 January 2019 at 15:52

Clearly from reading the issue threads on the other side of this site, the role and workings of composer are unsettled and a work in progress. I've personally run every update from 8.0.0 to 8.6.4 using the tar.gz manual method on a shared hosting site with no command line. Due to excellent work from the core committers and developers it usually takes 15 minutes or less on my "production" site. Just an unzip and a few directory deletes and copies. Of course, I lengthen this by doing backups first and by testing on a localhost site I have using Wampserver and mirrors my production site (same modules, same files).

That said, there are no doubt some modules that have dependencies that require composer. I don't need nor anticipate needing any of those modules.

I've tried to future proof myself by using Jaypan's excellent articles plus a host of other documentation (which is scattered all over the place) to set up a local test environment that uses composer. But of course, you need a Wampserver or equivalent (PHP, Apache, MYSQL databases with convoluted password commands, setting up virtual hosts including figuring out how to edit Windows HOSTS files) getting composer and drush running properly including messing with your Windows Path statements and figuring out what drush files to set up in Windows/user/myuser/appdata/roaming/composer/vendor/drush/drush directory. And I just mention that to indicate that getting a local setup that will support composer installations is not a walk in the park.

Even with Jaypan's latest article (#3 in the series) I don't know how to move from my local environment to the shared hosting. I'm not going to run composer on my production site because (a) it's not recommended and (b) it's not technically feasible ... I will never have command line access there. I do already have the same modules and versions running both locally and on the shared production site. So, I guess I could do an update locally, test it, then create a local based tar.gz of the Drupal directory, FTP it to shared hosting and do the manual update much the same way I do now. Then, if some module with dependencies that required Composer was needed on my site, I could set it up locally and include the tar.gz of that in what I upload.

But still that seems like a lot for something that's not needed. Which raises two other issues that have been troubling me.

1. For any given release of core + a given set of modules at specific release levels: if you run composer you will get one and only one tar.gz. Right? So, (a) if all you need is the core distribution plus a few modules that don't require composer or (b) if all you need is the core distribution plus a few modules that you set up with composer locally then you really would not need anything but a tar.gz replace method? No? No composer on shared hosting. No git. No drush on your shared hosting (handy as it is locally).

2. Quite honestly many of us running "simple" sites really don't need or benefit all that much from the monthly release updates. Even the major (8.5, 8.6, 8.7 release levels (forgive me if I have the terminology wrong)) don't do so much for those of us with simpler sites. Yeah, if media had been fully realized in 8.6 it might have been handy. But "experimental" modules are best confined to a test site while the developers work out the details to make them reliable. And what this is leading to is that (except for security releases) the majority of use should be doing perhaps one Drupal update a year. And that should be a tar.gz upload from a tested local site ... perhaps set up using composer, perhaps not.

And I just mention that to

fkelly12054@gmail.com commented 4 January 2019 at 15:47

And I just mention that to indicate that getting a local setup that will support composer installations is not a walk in the park. "

I guess it's not normal to quote yourself but in this case it's instructive. So, yesterday after posting this I saw that the Drupal 8.6.5 core release was available. So, I went to my command line and ran composer update. And, it can be a THING OF BEAUTY. Even a skeptic like myself who has done his updates "manually" is impressed by watching it download core and all the modules and update everything and then have the status report on my locally installed system come out clean. One command line prompt to do all this! Impressive.

But then I went to do drush core:requirements just to see how that would work. And my previously working drush was fouled up beyond recognition. After a few hours of monkeying around including following the instructions at:

https://github.com/drush-ops/drush-launcher

I was able to get drush working. I think that the root of the problem was that I needed to put some kind of version code and limit into composer.json for drush and that composer updated me to a non-appropriate version. But not sure.

In short good news and bad together. I guess that's how we make progress.

Let's try installing address without composer

alex.a commented 4 January 2019 at 17:33

I don't know how to install address without composer, but let me try and see what happens:

First, install it with Composer to see what it does. Then see how it could be done without Composer.

Install drupal in a new directory, using composer.
Go to that directory, find and delete all .gitignore files. run "git init; git add .; git commit".
Now install drupal/address: "composer require drupal/address"
run "git status" to see what changed.

Here's what installing drupal/address did to my newly created drupal directory:

It installed a whole bunch of directories in ./vendor, such as:

    behat/
   bin/phpcbf
   bin/phpcs
   bin/phpunit (really? what for?)

bin/simple-phpunit (?)

...

drupal/coder (what?)

...

First of all, now that I looked, I see a whole bunch of development/test code that should not be on my production server. Should I enter this as an address bug?

Edit: I have logged the problem of dev libraries at https://github.com/drupal-composer/drupal-project/issues/443

In the meantime I figured out that I can remove all those dev packages by running "composer update --no-dev".

After doing this, drupal/address is much more manageable. It just has one library and modifies the autoload files minimally.

End-Edit

Anyway, all these directories are easy to install by hand. Just download one or more tar/zip files with them from drupal.org/project/address. Such files are not there yet, but they could possibly be created automatically by drupal.org for each module (using composer). They should have all the library dependencies of the module (excluding any drupal core or drupal module dependencies). I can even do this myself, just tar them from my test composer machine and send them to my production server. So I'd be using composer somewhere, but not really on my site.

Now let's see what other files are changed:

    modified:   composer.json
   modified:   composer.lock
   modified:   vendor/composer/autoload_classmap.php
   modified:   vendor/composer/autoload_files.php
   modified:   vendor/composer/autoload_namespaces.php
   modified:   vendor/composer/autoload_psr4.php
   modified:   vendor/composer/autoload_static.php
   modified:   vendor/composer/installed.json

Since I won't be using composer on my site, I probably don't care about composer.json and composer.lock

Skipping installed.json is probably harmless as well.

But the php files seem important. I don't know the specifics of what PSR0 and PSR4 are, but I assume it's a way to tell PHP where to find various classes.

So this is the problem. I can't think of any easy way to modify these files myself. I don't really want to. It doesn't feel right to have to do this in order to add a new module.

So this is where I run into a limitation of PHP or design issue of Composer or Symphony or Drupal.

I don't know enough to fix this, but couldn't composer create a separate set of autoload_*.php files for each module? I could then download these files from drupal.org along with the module (they could even be automatically packaged in the module itself) and then I (or drupal) could run a simple PHP function to merge them together. Perhaps it could be done automatically when I run ./update.php. Drupal does some sort of scanning of my code anyway. How does it know how to find the classes in a module I'm working on?

"...but couldn't composer

cilefen commented 3 January 2019 at 18:35

"...but couldn't composer create a separate set of autoload_*.php files for each module? " is not wrong per se, but in the end it would be easier to read the documentation (you did not use the --no-dev flag for example) and use Composer the way it was designed. Or, work with the Composer team on adding the improvements you need. Or, write a new PHP dependency manager that works the way you feel a dependency manger to work. These things can't be fixed in this forum.

This forum is a place to complain, so please continue doing so. But to help on the usability of dependency management in Drupal 8, please participate on the ideas queue issues that someone was nice enough to locate and post here yesterday.

If you are working on more than the most trivial project in PHP these days (except Wordpress), get used to Composer as a dependency manager. That's just reality.

I'm going to stop following this issue now.

I did read the documentation

alex.a commented 3 January 2019 at 19:36

"it would be easier to read the documentation (you did not use the --no-dev flag for example)"

I did read the documentation:

https://www.drupal.org/docs/user_guide/en/install-composer.html

The documentation says that to install a module with composer (e.g. geofield), you do this:

composer require drupal/geofield

There is no --no-dev flag mentioned, and if I try to add one, I get an error:

composer require --no-dev drupal/address
[Symfony\Component\Console\Exception\RuntimeException]  
The "--no-dev" option does not exist.

I believe I did use --no-dev when I installed drupal core (I did not get phpunit with create-project).

I wasn't just complaining. I am trying to find solutions and to actually understand Composer and Drupal 8 (which, by the way, I've used with custom modules that I wrote, without using Composer).

You can stop following this thread, if you want, but you have been very helpful here, listening and responding to users, and that's why I got more involved. I am aware of the project/ideas issues you mentioned but I was intimidated with some of the technical talk in issues like this:

https://www.drupal.org/project/ideas/issues/2958021

"If you are working on more than the most trivial project in PHP these days (except Wordpress), get used to Composer as a dependency manager. That's just reality."

Is Drupal to be installed only by people who are proficient in PHP and Composer?

I recently installed Nextcloud without knowing anything about Composer. I see now that it uses Composer, but I did not know it before today. I wonder how they've solved the problem that we're talking about here. I can install plugins from the Nextcloud UI, without using the command line.

can't use --no-dev

tjtj commented 3 January 2019 at 20:24

Some of my modules (or drush?) put it back in.

Thus is the dichotomy of the

adminMN2023 commented 1 March 2019 at 15:07

Thus is the dichotomy of the user base. Non-dev's work is belittled and trivial.

It does seem that way...

Wolf_22 commented 1 March 2019 at 15:22

100% agree. And there's no excuse for it.

If you're being belittled,

Jaypan commented 1 March 2019 at 21:31

If you're being belittled, you should report it to the site admins, as that would potentially be in violation of the code of conduct.

It bit me again

tjtj commented 3 January 2019 at 18:33

So the latest D8.6.5 came out, and I need to update my 6 sites. First 2 worked using my usual manual method of copying the new core, vendor, and php files to my Drupal directory and running composer update. But the third site died badly. My theme is not displayed on the home page.

Accessing my site from another unlogged-in computer, I get Fatal error: Declaration of Drupal\publishcontent\Plugin\Menu\LocalTask\PublishContentLocalTask::getTitle() must be compatible with Drupal\Core\Menu\LocalTaskDefault::getTitle(?Symfony\Component\HttpFoundation\Request $request = NULL) in /home/kacbtnor/public_html/modules/contrib/publishcontent/src/Plugin/Menu/LocalTask/PublishContentLocalTask.phpon line 14

Well, of course there was a patch for this issue, which I had installed previously, but the update removed it.

A patch that stops drupal from working should be pushed to the non-dev version immediately. How is a user to know that the release version will kill his site??

Now on another site, I get

Message TypeError: Argument 1 passed to Drupal\Core\Extension\ThemeHandler::addTheme() must be an instance of Drupal\Core\Extension\Extension, null given, called in /home/orcmaorg/public_html/core/includes/theme.maintenance.inc on line 72 in Drupal\Core\Extension\ThemeHandler->addTheme() (line 202 of /home/orcmaorg/public_html/core/lib/Drupal/Core/Extension/ThemeHandler.php) #0 /home/orcmaorg/public_html/core/includes/theme.maintenance.inc(72): Drupal\Core\Extension\ThemeHandler->addTheme(NULL) #1 /home/orcmaorg/public_html/core/includes/bootstrap.inc(742): _drupal_maintenance_theme() #2 /home/orcmaorg/public_html/core/lib/Drupal/Core/EventSubscriber/MaintenanceModeSubscriber.php(121): drupal_maintenance_theme() #3 [internal function]: Drupal\Core\EventSubscriber\MaintenanceModeSubscriber->onKernelRequestMaintenance(Object(Symfony\Component\HttpKernel\Event\GetResponseEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #4 /home/orcmaorg/public_html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #5 /home/orcmaorg/public_html/vendor/symfony/http-kernel/HttpKernel.php(127): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object(Symfony\Component\HttpKernel\Event\GetResponseEvent)) #6 /home/orcmaorg/public_html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #7 /home/orcmaorg/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #8

Message	TypeError: Argument 1 passed to Drupal\Core\Extension\ThemeHandler::addTheme() must be an instance of Drupal\Core\Extension\Extension, null given, called in /home/orcmaorg/public_html/core/includes/theme.maintenance.inc on line 72 in Drupal\Core\Extension\ThemeHandler->addTheme() (line 202 of /home/orcmaorg/public_html/core/lib/Drupal/Core/Extension/ThemeHandler.php) #0 /home/orcmaorg/public_html/core/includes/theme.maintenance.inc(72): Drupal\Core\Extension\ThemeHandler->addTheme(NULL) #1 /home/orcmaorg/public_html/core/includes/bootstrap.inc(742): _drupal_maintenance_theme() #2 /home/orcmaorg/public_html/core/lib/Drupal/Core/EventSubscriber/MaintenanceModeSubscriber.php(121): drupal_maintenance_theme() #3 [internal function]: Drupal\Core\EventSubscriber\MaintenanceModeSubscriber->onKernelRequestMaintenance(Object(Symfony\Component\HttpKernel\Event\GetResponseEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #4 /home/orcmaorg/public_html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #5 /home/orcmaorg/public_html/vendor/symfony/http-kernel/HttpKernel.php(127): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object(Symfony\Component\HttpKernel\Event\GetResponseEvent)) #6 /home/orcmaorg/public_html/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #7 /home/orcmaorg/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #8

How do I fix this?? I haven't a clue.

Wow. the update removed my theme, and the libraries directory.

re. the patch: that's up to

fkelly12054@gmail.com commented 4 January 2019 at 15:27

re. the patch: that's up to the maintainer of the contrib module you reference. Better to put the request in their issue queue. Or patch your code yourself if you have the ability. Some patches are just adding and/or subtracting a couple of lines.

re. the theme ... I'd check your composer.json and make sure your theme is "required".

A different target ... Is that what the Drupal community wanted?

diego.paroni commented 19 January 2019 at 09:38

Drupal 7: about 1'000 files,
Wordpress: about 1'500 files,
Drupal 8: about 15'000 files.
For non-complex sites, it is suicidal to use and update Drupal 8.
Drupal 8, goodbye!

Fatal error fixes are not put into security upgrades

tjtj commented 2 February 2019 at 16:05

in https://www.drupal.org/project/drupal/issues/3000677

A core update regressed to introduce a fatal error. There is a patch for this, but users must find it, and know there is such a patch. Then after installing the patch, the next security update for core breaks the site again because the patch was not applied to core since it is a "security update."

At the VERY LEAST, the list of required manually-applied patches should be put into the core Release Notes!

Today is Groundhog day, and I am reliving this bug over and over.... But the excuse below is a perfect example of what makes Drupal 8 a nightmare.

tjtj CreditAttribution: tjtj commented 16 days ago

Seems to me that a critical bug that stops sites from working needs to be put in any new release. It is very time-consuming to update the core and remembering how to get around this bug, and repatching it is a real issue. I spent a morning doing the updates

edit

NEW

Comment#97

cilefen CreditAttribution: cilefen as a volunteer commented 16 days ago

Status:

Active

» Fixed

@tjtj You will have to make a case that security releases are also bugfix releases (or with criticals) in another issue. We are not going to change the policy in this issue.

Availability is one of the pillars of security

tjtj commented 3 February 2019 at 14:01

I argue that if a server is unavailable, it is insecure. Just like with a denial-of-service attack.

It isn't an excuse. It is an

cilefen commented 1 March 2019 at 14:37

It isn't an excuse. It is an explanation of release policy. There are reasons for releasing *only* security updates in security releases.

I think this policy needs review

tjtj commented 1 March 2019 at 15:07

I had to do at least 3 core updates in the last month, all of which caused a lot of hair tearing, and wasted my time unnecessarily. Releasing a new Core that will not run does no one any favors.

That is fine but no policy

cilefen commented 1 March 2019 at 21:56

That is fine but no policy will change solely because of comments here. Open a real issue if you feel security releases should happen on HEAD, or bugfix release + criticals + security fixes.

Somethings went wrong with

AmeDSL commented 4 February 2019 at 10:40

Somethings went wrong with this Drupal 8 Release, take a look the usage statistics
So, if you consider then Drupal 8 was released a few years ago...It's not a big deal, It's just a small shiner?
Maybe Drupal 8 it's hard to maintain, It's different architecture i means it's so hard to make custom module or custom code or somethings like that? Take a look to the available modules for D8 and compare it with D7 availables . Take a look to the availables themes. Really dunno. Surely, Drupal has always taken a lot of work to be confident with, but now it's too hard to work with. If the long road to Drupal 9 w'll be similar to that, i can't figure out about Drupal' future. We're in the "click here to install" era. Really hope am totally wrong in my poor analysis.

Drupal 8.6.8 did it again

tjtj commented 7 February 2019 at 15:21

https://www.drupal.org/project/drupal/issues/3031128#comment-12961022

Total lack of QA. Stress for D8 admins.

8.6.10 is end of the line for us

rockandroller commented 22 February 2019 at 16:47

Sadly, Manual upgrade simply does NOT work as advertised anymore .

COMPLETELY UNEXPECTED after three years of using drupal.

Yes, it was ALWAYS a pain, but it always used to work.

500 error on update.php after manual update this time around, due to some include error in /vendor

So much for the "rush emergency critical security patch" update...

Suggest posting in issues

fkelly12054@gmail.com commented 22 February 2019 at 17:25

Suggest posting in issues queue under core 8.6.10 together with exact steps you took *. Perhaps the files you uploaded didn't get completely into place. I did manual update on 8.6.10 with no issues ... Cpanel on shared hosting: new core files to old, vendor to vendor, base files over base files, run update.php, all fine. Your statement "it always used to work" is instructive. I've done over 50 manual updates of minor versions since 8.0.0 with only a couple of glitches. Usually those glitches show up in the core issues queue within a couple of days.

And a copy of the include error message.

Another voice heard from... I

adminMN2023 commented 25 February 2019 at 14:17

Another voice heard from... I had no problem manually upgrading the latest core update using Cpanel.

Two Sides

ColoradoDave commented 1 March 2019 at 23:02

Side 1 - We have developers (mostly working for free) who want to create a powerful, scalable, functional platform that can be used to build a wide-array of web sites/apps. This is cool.

Side 2 - The real world.

One has to ask why people are using this thread to vent. Do they just want to complain and spend their time pointing out how broken they perceive Drupal to be at this point?

The real reason is very simple. It is because they/we bought into Drupal and are having a hard time wrapping our heads around the fact that the platform we chose and used for so long is no longer usable .. at least by us.

From the dev's perspective, I get it .. It's not really that hard, and certainly not hard at all in the scheme of the technical software domain.

But the world changed, and the audience that gives a platform like Drupal the legs it needs to succeed. grab market share, and be ultimately successful, are the ones who have been dismissed by the core Drupal community as non-essential to the mission.

I guarantee the conclusion in the end will be that there is no mission, there is no platform, there is no future, without the masses of regular users, casual builders, and not so technical semi-professionals who are now among the dismissed.

You can argue (again and again) they have not been dismissed, but it is a pointless argument that echos in the vacuum of the thousands upon thousands who have already hit the exit door.

As was mentioned earlier, it's a point and click world. Your competition is so far ahead at this point you can't even see the tail lights. Drupal forked off on some dirt-side road where those who are left can be heard chanting "Point & Click is a Fad! Long live the Command Line!!"

agree 100% with "side 2"

rockandroller commented 2 March 2019 at 03:46

Drupal 7 core updates have always been TEDIOUS, compared to say Joomla.

Docs somewhat SCANTY.

Years ago I wasted a whole day TRYING to install DRUSH, just wouldnt work.

I gave Composer a try a few weeks ago, was also FREAKISHLY DIFFICULT and the "installer docs" were quite lame. ( After pulling the plug on D8 last week, I did eventually trudge through a composer installation - for something else!)

I was invested enough in Drupal 7 to jump through the hoops for manual updating.

I will NOT invest in Drupal 8, when the first time I try a "supposedly simple and straightforward" core update (critical security patch, wasnt it?) IT CRASHED AND BURNED.

Maybe it was because I had set up a multi-site installation?

Hard to tell, since THE DOCS ARE SCANTY ( not to mention irritatingly structured, in my view)

Anyway that is THREE DAYS WASTED trying D8, and clearly its headed for further complexity. Three years ago I was HOPEFUL there would be a 'one-click-core-update" BY NOW.

Simply TOO MUCH WORK TO DO, and the CMS framework is supposed to make life EASIER, not more complicated.

Signing off! Good luck, and thanks for the fish...

You may be interested to know

gippy commented 7 March 2019 at 19:52

You may be interested to know that Backdrop core can now self-update. https://backdropcms.org/news/backdrop-1-12-released

In the light of my long post

John_B commented 13 May 2019 at 08:44

In the light of my long post in this thread about my experience that Drupal 8 long-term maintenance has proved so expensive that I think it would be unethical to recommend D8 to small clients without a 'health warning', I think it is time to come off the fence about Backdrop CMS and get behind it.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

I wrote a shell script that updates Drupal 8

tjtj commented 18 April 2019 at 22:34

After like 6 core updates in the past 6 weeks, I decided to write a shell script to do the grunge work automagically. Use it at your own risk.

https://jamesrome.net/drupal/drupal8_update

Drupal is not on a good path

John_B commented 13 May 2019 at 08:49

Drupal is not on a good path right now

Perhaps Japyan will agree if this is qualified to say that Drupal 8 is not a good path for smaller organizations: I have worked on several Drupal 8 sites commercially, and for relatively low budget clients Drupal 8 has not offered an affordable value-for-money proposition. The worst is a mature Drupal 8 built with care by a skilled Drupal developer a couple of years back, with some complex features, for a non-profit largely run by one person. The stream of bugs, small and large, if repaired at commercial rates, would probably be sufficient to close the operation for want of funds. Knowing that this is how it goes, I am unable to recommend Drupal 8 except where I think the budget could handle the costs.

There are a few reasons for the high costs. A series of composer bugs is one. Another is that where the database schema is incorrect, owing to a bug in an otherwise good contrib module, D8.6 was working and D8.7 stopped working as did most commands in drush and drupal console, with only a core error message, and that has proved very elusive, even with Phpstrom. The general complexity of the codebase makes most debugging difficult and some debugging horrifying.

Most of us old Drupal hands appreciate many great things about Drupal 8, and have some confusion or mixed feelings. My confusion was resolved when I commented on Jeff Geerling's post Drupal 8 successes and failures: I asked myself the question, 'has Drupal 8 provided a good value proposition to my clients so that I can continue to recommend it?’ The answer is that for most clients of the size to run a site with one freelance developer, Drupal 8, wonderful as it is, has proved a very poor choice, and will probably remain so for some time to come, unless the client’s budget is unusually large for a small operation.

@Jaypan I have enjoyed your blog posts on Composer. Since one source of the problems has been with composer, I wonder whether you would consider writing a fifth article dealing with some Composer problems and solutions. A few issues which have cost me (and, to the extent I bill for my time, my client) a lot to work out include the following:

when I took over the site composer did not work at all. it just put out message 'could not resolve your requirements'. The reputable Drupal shop who managed it before said, 'oh that is easy, you just have to delete the core folder before every command' (solution: remove composer-merge plugin from composer-json);
updating Drupal core from 8.6.15 to 8.6.16 fails, you always get 8.7.x, whatever you put in composer.json or run with composer require (the fix is to use the webflo/drupal-core-strict);
the webflo/drupal-core-strict allows me to get 8.6.16 but, perhaps because its repo is out of sync, I still had some files from 8.7.x which broke the site;
where a patch failed to apply, the module to which it relates, which I need, was automatically reomved;
modules installed as dependencies of unused modules are lost if the parent module is removed: for example my site had a copy of Drupal Commerce which has never been installed, so I removed it. However, Address module, which we need, was only present because it was a dependency of Drupal Commerce, and was auto-removed after composer remove drupal/commerce was run;
running composer on bare-metal Linux on one of the most powerful ‘workstation’ laptops available, each command takes an age to run and in reality this does add to the cost of debugging, so with containers it can only be slower.

A post on Composer gotchas could be an excellent addition to an excellent series.

To be fair in cost terms we have moved away from nightmarish major version upgrades to Drupal. Also to be fair, I have to accept that we must spend time to learn over again what we learned on Drupal 6 or 7. On the other hand, a mix of composer problems, and the opacity of Drupal 8 when debugging, has brought costs of their own. Unless you have Phpstorm paid for and set up to use xdebug--and don't get me started on how broken Dev Desktop, the poor person's dev environment, has become in D8--you have little chance.

Yes, Drupal 8 is fantastic if your customers are in the market for the website equivalent of a Ferrari, or a combine harvester with enough electronics on board to run Starship Enterprise. For lower budget customers, it is beautiful, and just works, until it just doen't. At that point they will need to take a mortgage for the repairs. That is my experience.

@cilefen (or anyone else who takes an interest in core) since you posted 'Core contributors are listening', I think we would benefit from some people opening issues in this area. Given Dries's aspiration to reduce cost of ownership, we need a core meta-issue 'Make Drupal more robust'. Not 'Reduce cost of ownership' because that will probably be read as 'provide a good UI for composer', which is all very well until it too breaks, then there is yet another moving part to debug, at a cost and complexity far beyond many site owners. It could be a meta-meta ticket containing other meta tickets like the one which should be opened 'Make Drupal more tolerant, with better error messages, where the db schema is incorrect or corrupt'. I am reluctant to open such tickets myself beause I have so little to do with core dev and others could do it better.

Even then, Drupal 8 will remain stupidly over-complex for what it needs to do on most sites, but so is Windows 10 over-complex, and mostly it works. There are things which could be done to make Drpual 8 less forbidding and expensive for the majority of owners. Other suggestions appear in my comment on Jeff Geerling's post, linked above.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Perhaps Japyan will agree if

Jaypan commented 13 May 2019 at 08:46

Perhaps Japyan will agree if this is q1ualified to say that Drupal 8 is not a good path for smaller organizations

For the most part, I would agree. That said, I don't think it's absolute, it can work for smaller organizations, but more often than not, is overkill which can end up leading to over costs, much along the lines of those you described.

@Jaypan I have enjoyed your blog posts on Composer. Since one source of the problems has been with composer, I wonder whether you would consider writing a fifth article dealing with some Composer problems and solutions. A few issues which have cost me (and, to the extent I bill for my time, my client) a lot to work out include the following:

I don't mind the idea of adding an additional post, the problem is that I wouldn't be able to properly support it. I'm not a proper Composer pro, I just spent a lot of time figuring out how it works with Drupal. Unfortunately I haven't spent as much time figuring out how to fix it when it doesn't work.

If you put together a nice forum post though, outlining your findings above, where people can discuss amongst each other, I'd be happy to add it to the end of at least one of the posts, to give people a place to go for additional support.

As a side note, I've now started a second series of blog posts on the Configuration API. First post here: https://www.morpht.com/blog/drupal-8-configuration-part-1-configuration-api

Two parts have been published, with the rest to come over the rest of the week.

Good. I am off to read that.

John_B commented 13 May 2019 at 14:57

Good. I am off to read that. Also look forward to your views on whether to commit config. Doing so is rather convenient, but I am working with an experienced colleague who insists it is a terrible idea, mainly because of the number of secrets in config.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Good. I am off to read that.

Jaypan commented 13 May 2019 at 21:50

Good. I am off to read that. Also look forward to your views on whether to commit config. Doing so is rather convenient, but I am working with an experienced colleague who insists it is a terrible idea, mainly because of the number of secrets in config.

I think committing config is necessary, but requires a secure server - same as anything else.

I've now published Part 2,

Jaypan commented 13 May 2019 at 23:54

I've now published Part 2, and Part 3, with Part 4 to come tomorrow, and Part 5 the next day.

Part 4 has now been published

Jaypan commented 14 May 2019 at 23:07

Part 4 has now been published:

https://www.morpht.com/blog/drupal-8-configuration-part-4-extending-api-...

And the final part: https:/

Jaypan commented 15 May 2019 at 22:27

And the final part: https://www.morpht.com/blog/drupal-8-configuration-part-5-module-develop...

Ludwig?

Matt B

English

commented 30 July 2019 at 07:32

Just came across this - it looks promising: https://www.drupal.org/project/ludwig - seems to be a way to work around contributed modules wanting composer dependencies. Has anyone had any success using ludwig?

ludwig for all

alex.a commented 30 July 2019 at 07:41

Ludwig is the way to go, in my opinion, except that it should not be done manually by the module developers, but automatically for all modules, by drupal.org. All modules with 3rd party library dependencies should automatically get ludwig-fied. I wrote code that takes any drupal module and creates a ludwig companion module that adds the dependent libraries. I was envisioning making this a service and eventually drupal.org doing this. I am busy with other things now, but for me, this is the solution. If I need a module with dependencies, I generate its ludwig companion module (on a dev machine that has composer) and install it on my production site the old-fashioned way (without composer).

Drupal 8.7.7 did it again

tjtj commented 4 September 2019 at 13:26

The core that was just released has a fatal error. See https://www.drupal.org/project/drupal/issues/3078671#comment-13246391

Is there no QA in Drupal core releases?
This illustrates a fatal problem with using so many contributed modules that are in an iffy state of development. It seems to me that the Core release should gather the correct set of components, and just install them.

The composer-based process is rotten to its core. Pun intended.

The composer-based process is

Jaypan commented 4 September 2019 at 14:27

The composer-based process is rotten to its core.

The issue you linked to is not a Composer problem. Rather, Drupal core was pinned to a dev version of a library. Dev versions are not fixed, and therefore the code cannot be relied upon. The code being used introduced a conflict that is causing the error. It has nothing to do with Composer - Composer has simply added the library it was told to add. The problem was in the library it was told to add. Had the library been a fixed version, this bug would not have come into play, and would have been caught during testing.

As to why it is this way? Because it is. Developers develop and get the things they think they need to get. Other people see it, and bring up other things. And sometimes, things slip through the cracks and don't get found until they are bugs. That's the name of the game.

You ask if there is QA testing - not exactly. There is automated testing on core; unit, kernal and functional tests. But with all testing, automated or otherwise, someone needs to imagine the test scenario, and put that out to be tested, before it can be tested. If no one thinks of that scenario, then it doesn't happen. When it turns into a bug, the bug gets fixed, a test gets added, and we all move forward with a system that is a little more powerful, now that the bug has been patched and will be permanently tested for. It's unfortunate, and no one likes a situation like this, but it's not an intentional situation, and considering we're at Drupal 8.7.7, and four years into D8, it's not a blatantly obvious bug to have noticed until now either. The code is open source, and yet it wasn't noticed by anyone.

Alas, the patch did not work

tjtj commented 4 September 2019 at 15:15

For me at least, the patch to composer.json did not work. So what to do?

I guess I will no longer update core immediately upon release.

Is a new version of core being released? Can composer automatically patch composer.json?

The issue being discussed

fkelly12054@gmail.com commented 4 September 2019 at 15:29

The issue being discussed seems to relate solely to Drupal 8.8, which is totally in development status working towards a release date in December.

The most current production core release is 8.7.7 and was released on 9/4/2019. There have been no issues filed against it.

From what I've seen since the release of 8.0 four years ago, there is a pretty rigorous quality control process for production releases. Dev releases, almost by definition are sketchier. If you are using dev versions of contrib modules and dev versions of core you should expect some issues. That doesn't add up to (IMHO) the conclusion that Drupal maintenance is terrible.

The Drupal core developers are working on improvements to Composer in conjunction with the 8.8 release later this year. Right now it seems to be a work in progress (composer and Drupal 8, I mean). I use the tar.gz releases on my production site with little or no problem. I also don't use dev releases of anything.

The issue being discussed

ColoradoDave commented 4 September 2019 at 17:38

"If you are using dev versions of contrib modules and dev versions of core you should expect some issues.
That doesn't add up to (IMHO) the conclusion that Drupal maintenance is terrible."

I agree! That is a misplaced allegation by the poster, and unfortunately hijacks a valid thread. However, all of the "other" complaints about Drupal 8 maintenance identified on this thread are valid. ;-)

No this 8.7.7

tjtj commented 4 September 2019 at 18:02

And I posted the link to the issue. The dev modules are not ones that I installed. They are part of core, and should have not been allowed.

Not true, you installed them!

mmjvb commented 4 September 2019 at 18:30

They are not part of core, they are dev requirements. When you have them installed, the only one to blame is you! Should have used --no-dev or removed webflo/drupal-core-require-dev. My assumption is that you don't do development and therefore don't need them.

I think the documentation is to blame

gisle

he/him

Norwegian Bokmål

Norway

commented 5 September 2019 at 05:34

The only documentation about installing Drupal 8 with composer is here:

https://www.drupal.org/docs/develop/using-composer/using-composer-to-ins...

and it instructs people to install the dev version of core. This installs a lot of libraries not required for running Drupal in the vendor directory and pins the dependency to that particular version of the core - preventing the core from being upgraded until they are removed.

To fix this if you want to upgrade from 8.7.6 to 8.7.7, just do:

composer remove "webflo/drupal-core-require-dev"

and answer "yes" to the question about removal, and you should be able to update afterwards.

I think a big part of the frustration people have with composer, it that the documentation available on Drupal.org about using composer is not written with site admins as the target audience.

However, in this case I believe those who prepared this release also goofed up, as a clean install after exercising the thermonuclear option does not work either, see: https://www.drupal.org/project/drupal/issues/3079333

And to add to the joy of using composer, the --no-dev option does not work: https://www.drupal.org/project/project_composer/issues/3079348

- gisle

That is not a dev version of

cilefen commented 5 September 2019 at 11:25

That is not a dev version of core. It is the dev version of drupal-project.

Then, why "require-dev"?

gisle

he/him

Norwegian Bokmål

Norway

commented 5 September 2019 at 11:37

If it is not a dev version of Drupal core, why does it have a "require-dev" section?

As far as I am able to tell, having that section there prevents me from both installing and upgrading the site with composer. I removed it this morning. No harmful effects observed so far.

- gisle

drupal-project does not

cilefen commented 5 September 2019 at 12:42

drupal-project does not install a dev version of core. It is ordinary for project templates like drupal-project to install from its own dev branch, whilst installing stable versions of everything else.

If you do not develop Drupal software then the removal of this troublesome library likely won't affect you.

That was my first reaction as well.

mmjvb commented 5 September 2019 at 12:29

What was meant was --dev as opposed --no-dev.

Unfortunately, the issue is not limited to 8.8.

mmjvb commented 5 September 2019 at 11:11

@fkelly: The issue is the removal of the branch alias for the selenium driver dev branch. It is not something under control of drupal core. We are waiting for upstream activity (stable releases) to solve the bug in drupal core. The bug is using that alias as version in the dependency (require) and relying on commits not yet available in a stable release. It should use the version constraint ^1.4@dev now. There are issues in the core queue for 8.8 and 8.7.

@gisle: The bug was introduced 4 years ago. You need the workaround (bringing back the branch alias). A simple require dev-master as 1.3.x-dev for the selenium package. Obviously, it needs to be restored before use.

All the detailed issues can

John_B commented 4 September 2019 at 20:05

All the detailed issues can be argued various ways, and usually a good case can be made that they are not Drupal's fault.

The bottom line is that if you make a website for a small business, small magazine, club, church, synagogue, small to medium-sized charity, university department--in short if you make a website in any of the areas where Drupal has always shone--Drupal 8 will give you many great new features you may or may not want, and will demand a much higher level of skill, time and money to run than a D6 or D7 site. That is my experience.

By far my worst experience has been in taking over a site built in the early days of Drupal 8, by a competent developer, and some D8 sites will prove an exception and will go smoothly, so I am speaking about a trend, not an absolute measure. Depending on the business model, it will either bite into contractor's profits, or it will bite into the client's financial resources, or both. There is a mix of reasons, and Composer headaches is by no means the whole story. Clients and website owners should be warned that an upgrade will likely lead to ongoing higher costs, as well as offering them great features they may or may not want.

Whether you like the D8 architecture or think it is technically 'better' is more a matter of taste and engineering judgement; (does anyone know what all those libraries in 'vendor' do? and are they really all secure from upstream poisoning? and does the opaque D8 code really work better than the more comprehensible and debuggable code of D7?) To the different question, does Drupal 8 bring more costs and headaches, along with its advantages, than Drupal 7 did, the answer from experience is easy. Of course it does.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

How to maintain Drupal 8 with composer is a secret

gisle

he/him

Norwegian Bokmål

Norway

commented 5 September 2019 at 14:25

I think this forum topic has evolved as the canonical topic for those seeking information about Drupal 8 maintenance, so I will just share this:

I have recently been informed by cilefen (one of the core committers), that using drupal-project to install Drupal 8 using composer, as documented here "is not really supported" (i.e. it might break – and in my experience, it usually does). Please see https://www.drupal.org/project/drupal/issues/3079333#comment-13247801 for the exchange.

AFAIK, the recommended procedure for maintaining Drupal 8 with composer is currently a well-kept secret.

- gisle

You misquoted me. That's not

cilefen commented 5 September 2019 at 14:45

You misquoted me. That's not fair.

is not really supported here

... as in, on drupal.org. Thanks anyway!

Sorry about the misquote

gisle

he/him

Norwegian Bokmål

Norway

commented 5 September 2019 at 15:02

I've corrected it in my own documentation - http://wikihandbooks.com/drupal8/intro_drupalinstall.html#dload

Not being supported here implies that it is supported somewhere else. Care to share that piece of information with us?

- gisle

I thought I did so in https:/

cilefen commented 5 September 2019 at 15:15

I thought I did so in https://www.drupal.org/project/drupal/issues/3079333#comment-13247801

Sorry. Yes, you did

gisle

he/him

Norwegian Bokmål

Norway

commented 5 September 2019 at 15:18

I didn't see that it linked to github. My bad.

- gisle

Why is require-dev the default??

tjtj commented 13 November 2019 at 14:32

One must be very careful when adding modules to not bring all the development junk into one's site. All the project sites say something like "install using Composer: "composer require drupal/project" but this will bring in all the dev stuff.

You really need: composer require 'drupal/captcha:^1.0' --update-no-dev --update-with-all-dependencies

To prevent development stuff, remove it

mmjvb commented 13 November 2019 at 15:51

For site building there is hardly any need for those development version constraints. The only benefit is that it restricts the versions. So, just remove whatever is in require-dev.

And how is someone supposed to know this?

tjtj commented 13 November 2019 at 15:55

Drupal was (is??) supposed to be a plug and play system. How is the casual user supposed to know to do this? Again, the default should NOT be require-dev.

Of course Drupal should be

John_B commented 13 November 2019 at 17:51

Of course Drupal should be plug and play. It is easy for developers to be impatient of people who do not do things 'properly.' I suspect that the great majority of Drupal sites before Drupal 8 do not have a separate dev environment, and a substantial subset are run without use of command line even, let alone access to good local environment or a remote environment which supports Composer's ludicrous memory consumption. This includes many charity sites doing fairly complex things on a tight budget.

Much of this thread revolves around the fact that Drupal 8 has abandoned this important and hitherto grateful majority of its user base, including some larger sites which are not run 'correctly', in favour of the wealthiest clients and providers. At the same time, most core developers deny this plain fact: their denial is not dishonest, because they have convinced themselves that it is true, perhaps assisted by the fact that they do once in a while work on a simple site for a friend, and think that after all it is not so difficult. It is difficult and expensive in many ways. Only one of several problems is that introducing Composer as a de facto dependency has, in the real world, increased rather than decreased maintenance headaches--a little for those with excellent Composer skills, significantly for devs who are not yet Composer experts, and massively for many hobbyists and site builders.

It is what it is. No point in grinding away complaining because they have taken away our old Drupal and replaced it with a tool which glitters for the shareholders of the wealthiest Drupal shops. Let us rather use Drupal 8 when our job requires it and our clients can afford it, and celebrate Backdrop CMS as the flowering of what Drupal 8 could have been :-)

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Since Drupal 8.0 there have

fkelly12054@gmail.com commented 13 November 2019 at 18:12

Since Drupal 8.0 there have been at least 50 "minor" releases. I've installed all using the tar.gz. Aside from the core distribution I use about 29 contrib modules. I have a local setup which I test the tar.gz upgrade on. It mostly mirrors my public site on a shared server where I don't have command line access. Steps: unpack the tar.gz locally, copy /core to core, vendor to vendor and the files in the base directory over the old ones (except htaccess). Run update.php. If there is a contrib module update, copy the tar.gz to the /modules directory delete the old module, unpack and run update.php. Test. Replicate the process on my public site. Takes maybe a half hour for both. Not such a terrible nightmare.

I recognize that some contrib modules may not work this way because dependencies need to be resolved by a composer like thing.

Over in the issue queue (developer) side of drupal.org it looks like they are making good progress on making Composer easier and more reliable to uses. One of the things they are saying is that when they have all the pieces in place it can be used to create a tar.gz that is identical to the one provided by core now. When that happens I'll look again. And when they have comprehensive and intelligible documentation that is reliable. Even when that happens what I'd do is run composer on my local site (which exactly matches the production one), test, then create my own tar.gz and upload that.

If you have some contrib modules that are in dependency hell and require Composer you might try that process now.

My script works...

tjtj commented 13 November 2019 at 18:20

https://jamesrome.net/drupal/drupal8_update

It has been working quite well for me. It can take a long time to back up existing files, and Composer is not fast. But it is now a no-brainer for me.

But this brings up a question: If tar.gz of the release works, what is composer doing with all sorts of things in the core and vendor directories? Why aren't the core releases complete unto themselves?

" As a result, there have

fkelly12054@gmail.com commented 13 November 2019 at 21:42

" As a result, there have been a half-dozen Core updates in the past month "

I do not see a half dozen core updates in any month. I see one update a month, usually in the first 5 or 6 days of the month. For instance 8.7.9 released November 6. If they did a half dozen updates a month it would drive me to distraction. From what I read in the composer related posts in the issue queues, composer should generate exactly the same set of files that are in the tar.gz that Drupal.org provides. This would be true for the base directory, the core directory and the vendor directory. What differences are you seeing between your composer generated directories and the tar.gz from Drupal dot org?

I guess a script could help if I had six sites. But for one site it's pretty butt simple. Unpack the files in a new directory. Copy base files to base files, core to core, vendor to vendor. Update.php, run status report, and test. A few cache clears along the way help too.

There is a lot of good work by a number of very expert people taking place under the rubric of:

https://www.drupal.org/project/ideas/issues/2958021

There are links to related issues in that issue too. I'm hopeful that when this all gets completed we'll have an end to nightmares and the ability to install and maintain sites at any level of complexity. But for now, if you are seeing that core releases are not complete it would be good to know specifically where they are incomplete.

Composer doesn't do all kind of things unless you tell it to.

mmjvb commented 13 November 2019 at 21:46

When you clear out require-dev there is no need for the --no-dev, as you are not whitelisting packages the --with-dependencies makes no sense, it is ignored. You could use --dry-run to see the impact of `composer update`. Obviously, what it will do depends on the contents of composer.json, composer.lock and installed.json in vendor. In general it updates outdated packages.

sums it up for me

mrandy543 commented 14 November 2019 at 09:29

John_B has summed it up for me. Having used Drupal for over 10 years as small business, we are now planning to move to either Backdrop or Wordpress going forward. There is clearly a step up in the base skills needed to configure and run a Drupal site from v8 onwards and whilst I was comfortable with D7, I don't feel we will have the ability to run a D8 site.

I can understand why larger sites need a more complex solution and guess that's where it is heading, but organisations like ours need a button that says "update", rather than 3 days fighting with composer for every update. I guess the target audience going forward is organisations that either have a web team that can implement Drupal or have a budget to pay an implementation partner. Small / medium sized businesses that want to build / run their own site are no longer part of the target market.

As John_B says "it is what it is", but it's a shame as I did like Drupal after so many years using it.

No, it is not a requirement !

mmjvb commented 14 November 2019 at 10:26

There clearly is no step up in the base skills needed for D8, it works the same as D7. Yes, there are new ways to do things, but you can still work the way you did.

Have I missed something then

mrandy543 commented 14 November 2019 at 13:57

Hi mmjvb.

With D7 I used to copy files over using Filezilla or maybe via cpanel, and then run the update.php, and that was pretty much it when updating. Job done. When I ran a test site of D8 I couldn't update the site this way anymore and it told me to use Composer (which I had never even heard of before). I then tried wrapping my head around Composer and eventually gave up.

I'm not a developer or hosting expert and have virtually no coding experience beyond the ability to badly hack a bit of php when really desperate (and it works 50% of the time). Editing vectors artwork or keyframing animations not a problem, but coding and working with things like SSH is something I do (badly) because I'm occasionally forced to.

It's probably fair to say I was always at the bottom end of the audience for Drupal and I do recognise that, but I get the impression that bar has now lifted and where I used to sit just above it on D7, I feel like I now sit firmly below it with D8.

I can appreciate if you sit well above that bar it might not look to have moved, but for those of us sitting right on it, it certainly feels to have moved a lot.

If you think I am mistaken though I'd be genuinely interested to know why?

Not so

tjtj commented 14 November 2019 at 14:55

Many modules must be installed using composer (e.g., webform). And, after my shell script unzips the distro and copies the files to www/core and www/vendor, composer still updates many things in core and vendor, for example:

- Installing symfony/dom-crawler (v3.4.35): Loading from cache
- Installing symfony/css-selector (v3.4.35): Loading from cache
- Installing jakub-onderka/php-console-color (v0.2): Loading from cache
- Installing jakub-onderka/php-console-highlighter (v0.4): Loading from cache
- Installing dnoegel/php-xdg-base-dir (0.1): Loading from cache
- Installing nikic/php-parser (v4.3.0): Loading from cache
- Installing symfony/var-dumper (v4.3.8): Loading from cache
- Installing psy/psysh (v0.9.9): Loading from cache
- Installing webmozart/assert (1.5.0): Loading from cache
- Installing webmozart/path-util (2.3.0): Loading from cache
- Installing webflo/drupal-finder (1.2.0): Loading from cache
- Installing symfony/filesystem (v3.4.35): Loading from cache
- Installing symfony/config (v3.4.35): Downloading (100%)
- Installing stecman/symfony-console-completion (0.10.1): Downloading (100%) ...

None of these are MY modules, and I have no-dev. So just copying core and vendor and the php files is not sufficient.

Many modules must be

fkelly12054@gmail.com commented 14 November 2019 at 20:44

Many modules must be installed using composer (e.g., webform).

I just (11/14) went to the webform module on Drupal.org. Downloaded the webform module tar.gz onto my local system. Untarred it in my modules directory on my localhost based system (i.e.) not my public shared server. Went to extend. Enabled webform and webform UI. Enabled the simple webform example they provide and looked at the the results. Granted that's not a thorough test but so far I don't see any need for composer for this.

I will grant that there are modules that require composer to install. Webform doesn't seem to be one of them.

Edit: later, reading the documentation for webform on drupal.org it does appear that composer is needed to install many needed components (libraries) of webform. So I probably just have a skeletal version of the module installed. There is a composer.libraries.json file in the module that lists all the dependencies. My mistake.

... more reading. It appears that some of the projects being worked on in the issue queues will be "fully-baked" (more or less) at the time of the 8.8.0 release in December 2019. That might be a good time to re-explore composer. I'd rather reference the documentation on drupal.org than go spelunking around a half dozen projects on github without knowing which, if any, are fully supported by Drupal core.

Not to beat a dead horse but

fkelly12054@gmail.com commented 15 November 2019 at 16:34

Not to beat a dead horse but ...

1. I've said that updates of core are not that frequent. Imagine my surprise when I discovered 8.7.10 a few days after 8.7.9. Installed from the tar.gz locally in about 10 minutes but still a p.i.t.a.

2. In running the reports/status report after updating I got a bunch of messages from webform like this:

"Algolia Places 1.16.4 (CDN).
Please download the Algolia Places library from https://registry.npmjs.org/places.js/-/places.js-1.16.4.tgz and copy it to /libraries/algolia.places or use Drush to install this library.
CKEditor: Autogrow 4.11.4 (CDN).
Please download the CKEditor: Autogrow library from https://download.ckeditor.com/autogrow/releases/autogrow_4.11.4.zip and copy it to /libraries/ckeditor.autogrow or use Drush to install this library. ... this list goes on for a dozen plus libraries.

To me this implies that I could find the necessary libraries and install them manually if I wanted to really use webform. And it looks like a really spectacular module in its capabilities. I just don't need it for my personal site. I suppose that composer would find and install those same libraries and dependencies if you used it to install webform. That would be a convenience.

Worth noting that there is some up to date (November 2019) documentation relating to the composer project on Drupal.org at:

https://www.drupal.org/docs/develop/using-composer/starting-a-site-using...

Though it's pretty clear that non-developers would be better off waiting for 8.8.0 to hit the streets before rushing in.

To me, at least, it's really important to have "official" documentation.

Which is why you must use composer to install webform

tjtj commented 15 November 2019 at 16:41

with --update-with-all-dependencies

Note also, that installing modules using composer puts the modules in modules/contrib, but leaves them in modules if the module was installed before. You must ssh in to manually delete the old version of the module or you keep getting update messages.

https://www.drupal.org

TD44 commented 15 November 2019 at 17:15

https://www.drupal.org/project/webform/issues/2948002

https://www.drupal.org/project/webform/issues/3094592

Webform is not an emergency i guess. Unlike CKEditor? I'm lost..

8.0 - 8.8.0 pains

tjtj commented 12 December 2019 at 15:15

On one of my sites (all on A2 hosting.com). when I try to install Drupal 8.8.0, I can no longer run Composer since the maximum 2 GB of php memory is not enough, and Composer gets killed.

Some people claim that merely updating core, vendor, and the php files is sufficient to update Drupal without running Composer, but alas (why?) drush is not included in the distribution vendor directory, and even

composer require drush/drush --update-no-dev
Using version ^10.1 for drush/drush
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies
killed

does not work. But the site will not display unless the cache is flushed, so how does one do this with no GUI and without drush?

How do I proceed?

John_B commented 12 December 2019 at 15:30

How do I proceed?

The general idea is to put a development copy of the site on your laptop or some other development machine where development takes place, and run composer there, then commit the code to git, and push your code updates to your hosting account also using git. If that sounds like a lot of work, it is one sense not--it is the kind of workflow already in use for many or most of the larger, professoinally run, sites often with multiple developers which Drupal 8 is designed for and where the higher costs of Drupal 8 are sometimes acceptable. It is of course a lot more work than simply applying updates to a live site using drush, which is possible with Drupal 7, though discouraged for mission critical sites.

One shared hosting company where I have a 'premium' level account did increase my access to RAM to allow me to run composer. Generally 4GB is enough, though I tihnk they allow me 6GB for this situation. It surprised me that they agreed to this, and one cannot rely on the host agreeing, but it may be worth asking.

Speaking of shared hosting, I met someone who had installed Drupal 8 using a script installer that comes with cPanel (such as Softaculous) and had continued to run updates using the same tool, and had, to my surprise, found that the site continued to work.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

It is really not practical

tjtj commented 12 December 2019 at 19:08

1. I manage 6 small sites for non-profits. It is really not practical to move them from, my home computer to my isp. Many things are different, such as passwords, etc.

2. Which host are you using for 4-6 GB?

3. Since now, all modules bust be updated with composer, this workflow would require many syncs/week, each one taking hours!

An environment (Drupal) that requires this has somehow missed the point. When I started, I could manage everything with the GUI. I bit the bullet and started to use Composer. Now that too has failed.

The host which did that when

John_B commented 12 December 2019 at 19:20

The host which did that when I asked for it, I think as a one-off, is Squidix, what they call 'semi-dedicated' so I do pay more than for basic shared hosting. I find them good. No host is perfect.

If they were sites I looked after I might be tempted to upgrade them to Drupal 7 or Backdrop CMS. There comes a point with relatively low-budget sites where the costs in time and skill for Drupal 8 just does not jibe with reality, though to be fair I think D8 is getting better. WordPress in my experience is pretty reliable, but also pretty horrible in architecture, with most of the good plugins requiring a regular fee, so personally I would tend to use WP for the simplest sites on the whole, where Squarespace is a good option. For flexibility and mostly moderate maintenance load, Drupal 7 or Backdrop are winners.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

how can one downgrade to D7?

tjtj commented 12 December 2019 at 19:41

Also, D7 support will end soon. Seems as if I am screwed.

Not at all. Support for

John_B commented 12 December 2019 at 20:22

Not at all. Support for Backdrop CMS will continue.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

You're not screwed but it's

Wolf_22 commented 12 December 2019 at 20:29

You're not screwed but it's obvious that you (and everyone else who hasn't jumped ship) will have to endure the additional maintenance inconveniences until the functional divides are somehow bridged in the Drupal admin UI like we all enjoyed back in Drupal 7. It's almost embarrassing to see just how far Drupal 8 regressed in that department...

I run a "small" site on

fkelly12054@gmail.com commented 12 December 2019 at 19:52

I run a "small" site on shared hosting also. I've never even tried to run composer there and will never. Running it against a production site is nuts, even assuming the shared hosting plan would give you the access (resources) you need. From the time you started running it and including any time you needed to resolve problems until you had it fully completed you would be out of service. If it failed you'd be restoring from backups and starting again some later day once you'd figured out what went wrong and how to correct it. And I'm not about to run a staging version of my site on shared hosting.

Locally, Windows 10, I run several "test" versions of my site using Wampserver. I can have as many as I want. One is a quasi-mirror image of my hosted site ... all the core and contrib files downloaded together with a dump of my production database. When a Drupal update comes along I download the tar.gz, replace the "mirror" core with the core, vendor with vendor and the base files in the root directory with the tar.gz base files. Then run update.php, check out reports/status, and splunk around on the site to make sure everything runs. Clearing cache several times along the way of course.

Once that works (and it usually does the first time) I go into cpanel. Create (or rename) for the latest release (say Drupal880) then upload the tar.gz into it. Unpack it. On my hosted production site delete core and vendor and the base files (again excepting htaccess). Copy core to core, vendor to vendor, and base files to base files. Run update.php. Clear cache. Check out status reports. Check out site.

Granted there are some modules that will require composer. I don't currently use any of those.

I have run composer to install Drupal updates on my localhost. Even installed a module such as webform that requires composer. But I'm not using that in production. I believe the developers have made significant progress in "normalizing" composer during the 8.8.0 process but I'm not sure that all the pieces are in place where you can follow the documentation from the 1st step to the last reliably. I will keep experimenting with that. If it works reliably and I have to go to Composer what I'd do is get it working locally, The create my own tar.gz which reflects my own core plus my own contrib modules and upload it and do the copies I described earlier.

Drush is a great tool that I've used locally. I don't know why I'd need it on my production host. Likewise, Git may be a great tool but it takes me about 15 minutes total to move my tar.gz from local to shared hosting and have it copied over. Not sure what the savings of using GIT would be.

I am surprised about not

John_B commented 12 December 2019 at 20:26

I am surprised about not using drush in production. Pantheon offer drush access to the production site and I cannot imagine living without it. For example if the site goes down, so you cannot reach the admin forms, and a cache clear would bring it back, drush is the easiest way to do that. Also it is handy for database updates, running mysql queries (assuming you don't have phpmyadmin for example), running cron and watching for the error messages coming back from Salesforce (if you use it--just an example), generating a login for a user whose password you do not know to check a bug report, import config (on D8), disabling a module causing problems (on D7) etc etc. I use drush on production sites all the time, and it is a life saver when the UI is unreachable, as can happen in the best regulated circles!

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Concerning your environment

Wolf_22 commented 12 December 2019 at 20:41

Concerning your environment management, I came really close to suggesting that you look into installing and using the "Habitat" module to make your staging and development life a little easier but since it isn't yet offered for Drupal 8, I guess I won't suggest it. Ugh... (I use it for my Drupal 7 site and it made migrations and environment replication a breeze.)

Drush is critical

tjtj commented 12 December 2019 at 23:50

When you get the dreaded "site encountered an unexpected error",

drush watchdog-show

is the only way to figure out what is happening. It is also the only way to clear the cache if you cannot get the GUI to work.

But I guess I am confused. If one merely needs the distribution core and vendor directories, what does "composer update" actually do?

I had a similar problem with

AmeDSL commented 12 December 2019 at 20:44

I had a similar problem with the last Drupal update. I solved the following:

composer global remove drush / drush

Then

cd ~

and

export PATH = "$ HOME / .composer / vendor / bin: $ PATH"

therefore

composer global require drush / drush: 9. *

Finally

drush up --security-only

That´s my two cent

Drush 8 still works for Drupal 8

ressa commented 13 December 2019 at 13:45

Actually, Drush 8 works together with Drupal 8. Sure, updating to the latest update 8.8.0 will end with an error message, but the update itself actually succeeds. I would wish that upgrading Drupal 8 with Drush 8 was part of the Drupal test suite, since so many still use it, so errors such as these could be caught in advance.

Greg Anderson (one of the maintainers of Drush) recently stated that efforts for Drush 8 and Drupal 8 is "best-effort only" which I interpret as, that it will probably work in the near future: https://github.com/drush-ops/drush/issues/4277#issuecomment-563327818

Also, the Automatic Updates initiative is coming along, and is getting closer and closer to working for tar-ball version of Drupal 8, which will serve as another update alternative.

I have been using Composer together with Drupal 8 the last few years, but only for customers with dedicated security teams, ready to roll out security updates on the designated evenings, should there be any.

Currently I am getting ready up to upgrading a Drupal 7 site to Drupal 8, using the tar-ball version and Drush 8. I will not use modules which require Composer, but of all the modules I could be interested in, I think only Search API Solr falls into that category.

Webform, for example, can be installed without Composer, and optional third-party libraries can be downloaded with drush webform-libraries-download.

Here's how I tested upgrading from a non-Composer driven Drupal 8.7.4 to Drupal 8.8.0 with Drush 8, in Lando (Drush 8.2.3 included) if anyone else wants to also try it:

# Get tarball version of Drupal 8.7.4
mkdir drupal8 && cd drupal8 && curl -sSL https://ftp.drupal.org/files/projects/drupal-8.7.4.tar.gz | tar -xz --strip-components=1

# create Lando instance and start it
lando init --source cwd --recipe drupal8 --webroot . --name drupal8
lando start

# install Drupal 8
drush site-install --db-url=mysql://drupal8:drupal8@database/drupal8 --account-pass=content -y

# get latest admin_toolbar module
drush dl admin_toolbar && drush en admin_toolbar admin_toolbar_tools -y

# log in
drush uli -l http://drupal8.lndo.site

# update from 8.7.4 to 8.8.0
drush up --security-only -y

Local composer updates

tjtj commented 13 December 2019 at 13:22

So, does "composer update" need the site database installed to update the site files?

No Composer

ressa commented 13 December 2019 at 13:47

My example is for running a non-Composer Drupal 8 ("tar-ball"), so composer is not supposed to be used. Updates (drush up) can be run locally and files uploaded, or directly on the server, of course with lots a back-ups ready, should anything fail.

Note: I added a bit of text ("a non-Composer driven") in my previous comment to clarify the process.

No such thing `non-Composer Drupal 8`

mmjvb commented 15 December 2019 at 22:57

By definition any Drupal 8 is Composer based. Initially, Composer was used to assemble Drupal 8. The eco-system insisted on using Composer for building sites. Fortunately, that is provided as an option in addition to traditional workflow.

Unfortunately, earlier version of Drupal didn't use drupal/core as package, core was provided as part of the package itself. That meant a manual update procedure. No problem for developers, disaster for site builders. All other distributions and drupal-composer/drupal-project used drupal/core, allowing easy update with Composer. Now, with D8.8 the package drupal/core is used instead of including it.

So, does "composer update"

Jaypan commented 15 December 2019 at 22:09

So, does "composer update" need the site database installed to update the site files?

No. Composer does not work with the database, it is only for management of the code base.

Still not enough memory

tjtj commented 16 December 2019 at 00:11

So, I moved the files to my home server, ignoring the database. But composer still runs out of memory (at 1.6GB) even though phpinfo says it is using php.ini in /etc/php/apache2 (I recall), and that file has a 40 GB memory_limit. So I am still stuck.

mmjvb, not sure what changed with drupal/core, but is that what makes composer now run out of memory with 8.8.0?

Composer increases the

cilefen commented 16 December 2019 at 01:30

Composer increases the default memory to 1.6 GB so in fact the PHP INI value probably isn't being read here. I think when Composer runs out it prints a link to https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors

Prefix the call to Composer as shown below and it should work if the system has sufficient memory. Yes, there is a hefty increase in memory needed. Yes, this happened to my production sites. Yes, I will find out more about why.

php -d memory_limit=-1

The change to usage of drupal/core made it ...

mmjvb commented 16 December 2019 at 09:04

available for Composer to update. Although it adds quite a lot to the workload of Composer, doubt that it is the cause of running out of memory. Obviously, a poor composer.json may cause memory issues. Try

COMPOSER_MEMORY_LIMIT=-1 composer install

or share your composer.json to see whether it is infra related.

This worked!

tjtj commented 16 December 2019 at 15:44

But, when I run composer update, it removes my core directory!

https://www.dropbox.com/s/1wpasjy6ang8hag/composer.json?dl=0

What is wrong?

My restored site is still broken

tjtj commented 17 December 2019 at 15:33

I went back to a restored Drupal 8.7.10. But my site is still broken, and I don't know how to fix it.

phpmailer throws errors:

phpmailerException: Invalid address (addAnAddress to):
me@gmail.com in PHPMailer->addAnAddress() (line 931 of
/home/kacbtnor/public_html/vendor/phpmailer/phpmailer/class.phpmailer.

So I tried to remove phpmailer:

kacbtnor@mi3-ss36 [~/www]# composer remove drupal/phpmailer
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- The requested package symfony/debug (locked at v4.4.1, required as ^3.4.0) is satisfiable by symfony/debug[v4.4.1] but these conflict with your requirements or minimum-stability.

Removal failed, reverting ./composer.json to its original content.
kacbtnor@mi3-ss36 [~/www]# composer remove symfony/debug --update-no-dev
symfony/debug is not required in your composer.json and has not been removed
Loading composer repositories with package information

However, symfony/debug is not in composer.json. I also did

composer update --no-dev
Loading composer repositories with package information
Updating dependencies
Package operations: 0 installs, 1 update, 6 removals
- Removing drupal/coder (8.3.7)
The package has modified files:
D coder_sniffer/Drupal/Test/Arrays/ArrayUnitTest.inc
D coder_sniffer/Drupal/Test/Arrays/ArrayUnitTest.inc.fixed
D coder_sniffer/Drupal/Test/Arrays/ArrayUnitTest.php
D coder_sniffer/Drupal/Test/Arrays/DisallowLongArraySyntaxUnitTest.php
D coder_sniffer/Drupal/Test/Arrays/disallow_long_array_d7/DisallowLongArraySyntaxUnitTest.1.inc
D coder_sniffer/Drupal/Test/Arrays/disallow_long_array_d7/disallow_long_array_d7.info
D coder_sniffer/Drupal/Test/Arrays/disallow_long_array_d8/DisallowLongArraySyntaxUnitTest.2.inc
D coder_sniffer/Drupal/Test/Arrays/disallow_long_array_d8/DisallowLongArraySyntaxUnitTest.2.inc.fixed
D coder_sniffer/Drupal/Test/Arrays/disallow_long_array_d8/disallow_long_array_d8.info.yml
D coder_sniffer/Drupal/Test/Classes/ClassCreateInstanceUnitTest.inc
284 more files modified, choose "v" to view the full list
Discard changes [y,n,v,d,?]? y
- Removing doctrine/instantiator (1.3.0)
- Removing behat/mink-selenium2-driver (1.3.x-dev)
- Removing behat/mink-goutte-driver (v1.2.1)
- Removing behat/mink-browserkit-driver (1.3.3)
- Removing behat/mink (dev-master)
The package has modified files:
D tests/Driver/CoreDriverTest.php
D tests/Element/DocumentElementTest.php
D tests/Element/ElementTest.php
D tests/Element/NodeElementTest.php
D tests/Exception/ElementExceptionTest.php
D tests/Exception/ElementHtmlExceptionTest.php
D tests/Exception/ElementNotFoundExceptionTest.php
D tests/Exception/ElementTextExceptionTest.php
D tests/Exception/ExpectationExceptionTest.php
D tests/Exception/ResponseTextExceptionTest.php
12 more files modified, choose "v" to view the full list
Discard changes [y,n,v,d,?]? y
- Updating symfony/debug (v3.4.36 => v4.4.1): Loading from cache

It is quite unclear what to choose from the prompt. I don't want to discard changed. If I pick n, it aborts, so I picked y. And symfony/debug is put back in.

Help please.

Bad workflow!

mmjvb commented 17 December 2019 at 16:23

Unfortunately, it was decided to combine require/remove with update in Composer. It only works in very simple setups. That is why you need to use --no-update on require/remove. This way you only change composer.json. It allows you to find out the update with --dry-run. Suggest to whitelist any dependency that needs changing instead of --with-dependencies.

Note that Composer unfortunately updates any package within the version constraints. Introducing minor version when you probably don't expect it. Prefer the more conservative approach of only patch releases. That does require you to provide version constraints on packages that are dependencies.

That helped, but...

tjtj commented 17 December 2019 at 16:49

kacbtnor@mi3-ss36 [~/www]# composer remove symfony/debug --no-update
symfony/debug is not required in your composer.json and has not been removed
kacbtnor@mi3-ss36 [~/www]# composer remove drupal/phpmailer --no-update
kacbtnor@mi3-ss36 [~/www]# drush updb
[success] No pending updates
kacbtnor@mi3-ss36 [~/www]# drush cr

and I still get phpmailer errors.

Error phpmailerException: Invalid address (addAnAddress to): me@gmail.com in
PHPMailer->addAnAddress() (line 931 of

symfony/debug is not a direct dependency.

mmjvb commented 17 December 2019 at 17:36

Meaning it is not mentioned in the require of your project. Probably a requirement of one of the development meta packages: webflo/drupal-core-require-dev or drupal/core-dev. Use depends to find out what requires symfony/debug.

Before you remove modules, they need to be uninstalled in Drupal. Unless of course you are going to replace it with different version.

There is no need to update the database when there are no changes. The composer remove doesn't remove till you composer update. There is no composer update mentioned above.

As you didn't do anything, the results are the same! At least it gives you the opportunity to do things right!

Remove modules from drupal before removing them with Composer. With Composer use --no-update on require/remove to make the change to composer.json. Use install/update to make the changes to vendor. Run update.php to apply database updates as a result from the changes in code.

You've started to discuss a

Jaypan commented 18 December 2019 at 02:02

You've started to discuss a specific support issue, rather than Drupal 8 maintenance. Can you please create a new thread to discuss this issue, so as not to detract from the current discussion.

Thank you.

sorry

tjtj commented 18 December 2019 at 13:44

I shall do so

Upgrading to 8.8.1

tjtj commented 19 December 2019 at 18:35

I followed the instructions at https://www.drupal.org/docs/8/update/update-core-via-composer#s-special-considerations-for-upgrading-to-drupal-880-and-later, which helped my above issues. But now there is another security patch to core.

I changed composer require drupal/core-recommended:^8.8 --update-with-dependencies to

composer require drupal/core-recommended:^8.8.1 --update-with-dependencies

and 8.8.1 is listed in my composer.json. ("drupal/core-recommended": "^8.8.1")

But 8.8.1 does not get installed. "composer update --no-dev" says nothing is to be installed or updated.

So how do I actually get 8.8.1 installed??

Well, I just copied the 8.8.1 core into my drupal directory, and this seemed to work. But can it be so simple? In 8.7.x, composer update did all sorts of things in the core directory.

So what is the correct procedure for updating 8.8.x cores?

composer why-not drupal/core:

cilefen commented 19 December 2019 at 18:36

composer why-not drupal/core:^8.8.1

That is not the problem

tjtj commented 19 December 2019 at 19:25

There is no installed package depending on "drupal/core" in versions not matching ^8.8.1

That in a way signifies that

cilefen commented 19 December 2019 at 22:06

That in a way signifies that 8.8.1 is installed. Are you certain it is not?

Yet another gotcha -- composer changed its requirements

tjtj commented 22 December 2019 at 16:42

https://www.drupal.org/forum/support/upgrading-drupal/2019-01-20/composer-update-issue-867

I had to downgrade composer to get update to work. Am now trying https://github.com/WebKings-ca/gocomposer

But this broke my site alas

No change in requirements

mmjvb commented 23 December 2019 at 15:34

You are doing things the wrong way! To update core with composer it needs dupal/core as requirement, NOT part as project! Composer doesn't update your project, it updates your requirements with their dependencies.

There haven't been situations with Drupal that required a downgrade of Composer. You need to make sure you run the most recent version. The objective is not to succeed when there is an issue. The earlier version succeeds and leave you with the problem. The recent version reports the problem, up to you to solve it.

Suggest to google composerize for getting away from drupal/drupal with merge plugin.

Again, this has nothing to do

Jaypan commented 23 December 2019 at 01:51

Again, this has nothing to do with the current topic. Please open a new thread for your questions.

Test Drush update from previous versions to Beta

ressa commented 23 December 2019 at 09:46

To better catch situations like the errors which were shown after updating a non-Composer based installation from 8.7.10 to 8.8.0 with Drush, I have created the issue #3100841: Test Drush update from previous versions to Beta.

I created this post:

TD44 commented 4 January 2020 at 10:09

I created this post:

https://www.drupal.org/forum/support/installing-drupal/2020-01-03/difference-between-composer-create-project

Is it possible to switch from drupal-composer/drupal-project to drupal/recommended-project

And what is the best?

Stuck again

tjtj commented 26 May 2020 at 16:27

One of my six Drupal sites (created using https://www.drupal.org/docs/8/install/add-composer-to-an-existing-site) refuses to update when moved to my hosting ISP. All sites use the same ISP.

I can update the site at home. I then zip up public_html and export the database, and move them to my host. I have to make some changes on the host (which is why this is a lousy way to do things) for example, the trusted_host_patterns, and some .htaccess things. But everything is really the same.

But on my hosting ISP, composer update and composer require do nothing. There are no error messages, it says composer.json is updated, but no files are changed. I have to update modules using wget into modules/contrib, which is clearly wrong.

If I try to update the database from the GUI, I get

In order to run update.php you need to either have "Administer software updates" permission or have set $settings['update_free_access'] in your settings.php.

I am admin, and have this permission. I made a second admin account, and get the same message. drush updb works from ssh pane.

php on my host is 7.3.18; at home it is 7.2.5, but I have also tried using 7.2 on the host.

In addition, since all modules are updating for Drupal 9, I have to update modules multiple times a day, which is why administrating my six sites is a time-consuming pain. Two sites require that I set permissions on sites/default to 775 to get updates to work.

None of this is standard

Jaypan commented 26 May 2020 at 16:54

None of this is standard behavior. It really sounds like you need a doctor to look at your system and figure out what's got it all messed up.

I have rebuilt it multiple times, always with the same result.

tjtj commented 26 May 2020 at 17:39

Where do I find a doctor? This is a poor non-profit site.

It must be something in the database, but if I drop the database, I lose all the content. Is there a way to export the content other than in the database?

And the chmod issue is a well-known problem: https://www.drupal.org/forum/support/post-installation/2019-12-09/fresh-install-drupal-880-composer-require-could-not for example. But the problem is in the composer.json scaffolding file.

Drupal is no longer for simple sites

gisle

he/him

Norwegian Bokmål

Norway

commented 26 May 2020 at 18:14

Where do I find a doctor? This is a poor non-profit site.

I am not trying to be snarky here. But I think there is a lot of insight insight in Dries 2017 keynote from DrupalCon Vienna: https://www.drupal.org/blog/state-of-drupal-presentation-september-2017 . We were indeed warned.

I make a living from selling managed hosting to (mostly) poor non-profit sites, and it used to be a breeze with Drupal prior to Drupal 8. Then Drupal 8 came along, and I had to learn how to maintain (mostly very simple) Drupal 8 websites with the help of composer, etc. (after first trying really hard to do it "old school" with drush – and failing). There was no way I was able to to it as cheap and efficient as before. I migrated some of those poor customers to a flat file WCMS (it's simple enough, but has more bugs than a rainforest, and with no community to speak of, you're on your own) to keep it cheap, and doubled the price for those that preferred to stick with Drupal.

- gisle

Where do I find a doctor?

Jaypan commented 26 May 2020 at 19:10

Where do I find a doctor? This is a poor non-profit site.

There are various places you can look. I’d start with the Paid Support section of the forum here. You can also look at freelance sites and try to hire someone there as well.

Note however that you do NOT want someone who is not experienced in Drupal development. Someone who does not know Drupal may find a fix, but not knowing Drupal may screw something up worse You want someone experienced in Drupal development. You can ask if they have Acquia back-end specialist certification. This isn’t a requirement, nor is it a guarantee that you’ll get someone who can fix the problem, but someone with the certification is a somewhat safer bet.

But on my hosting ISP,

John_B commented 26 May 2020 at 18:46

But on my hosting ISP, composer update and composer require do nothing.

Specifically, composer update rarely works on shared hosting, and is not meant to. It runs out of memory. Besides there is an odd bug which causes it to make certain key files unwritable by the hosting account owner on cPanel hosting, whilst sometimes displaying ownership and permissions which suggest they should be writable.

The idea is to run composer update drupal/[module-name] on your local site on the laptop, commit changes to git, and push them to hosting. Even where you have those skills it still takes longer than the kind of simple workflow which would work on D7. And when composer or drush update-database throws a hissy fit it can cause a headache which is sometimes cured only by days of work.

The discussion about the problems of running Drupal 8 has been done to death. Whilst Drupal 8 is getting more stable and those major headaches become rarer, 8 is not a good fit for low-budget sites, either at the development level or the updates level or the hosting level. The D7 fork, BackdropCMS, would be a better choice.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

hmmm...

gisle

he/him

Norwegian Bokmål

Norway

commented 26 May 2020 at 19:37

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors.

And just now their home page produces a WSOD. Not the best advertisement I've seen. (I assume they will be back up soon).

- gisle

I'm not sure why the site is

Jaypan commented 26 May 2020 at 19:56

I'm not sure why the site is down, but having worked on a project with John personally, I'll vouch for his company. I'd be comfortable hiring him for Drupal projects.

Site is down because it is

John_B commented 26 May 2020 at 20:16

Site is down because it is shared hosting which does not support composer update! and because I have been getting as much work as a I need and was not looking for new customers--though I would not turn away work which is a good fit. Still, it does not look good. I will go and fix it.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

I'll respond to your original

fkelly12054@gmail.com commented 26 May 2020 at 20:14

I'll respond to your original post. It doesn't seem like folks have read it at all carefully.

The reason you run Composer locally rather than on a shared server is, as stated in one of the posts, it can be difficult to get Composer running on a shared server where you don't have root access. PHP memory limits are one of the problems. Besides, the general recommendation is not to run Composer on a production site. It seems like you are able to run composer locally. Assuming the local site is an exact replica of the the production site on the shared server, you should be able to zip up your files and replace those on the shared server. Then create a dump of the local database and replace the one on the shared server. Of course you have backups before doing this.

At this point you should be able to login as admin on the shared server, put the site in maintenance mode and run update.php. I'd make very sure I had admin access to the site ... go to config and reports and check site status. Maybe give cache a clear from config. Then try update.php. You mention not replacing .htaccess ... or at least making sure you have the appropriate one on your shared server. Trusted host settings have to be right.

You should NOT be running composer on the shared server. That just duplicates what you've done locally. Locally it gives you a set of files you can use on the shared server. It's analogous to the older tar.gz update process except it should include updates for your contrib modules as well. Check the output from composer locally and see if there are any warning messages and the like.

With Drupal 8.6.6. just coming out, Drupal 8.9 on the way, and Drupal 9 not far behind and with module maintainers under the gun to make their code Drupal 9 compliant this will be a challenging period for all.

work flow is impossible without changes for the environment

tjtj commented 26 May 2020 at 22:44

Since I have 6 sites on separate ISP accounts, and just one home server, it is impossible to make everything the same. For example the trusted_host_settings, and base_urls. It is also very time consuming because on my host A2hosting.com, public_html must be in group nobody, and one must wait 4 hours for a cron job to do this. By A2 is great otherwise, and gives me enough memory to run composer if I ssh in. See my comparison of some hosts: https://jamesrome.net/drupal/hosting

Since Composer is now used for module updates, at the present time, one would have to upload each site one or more times a day to keep updated. This is impossible realistically.

Even home where my Linux machine has 32 GB of memory, it is difficult to run composer with enough memory. I have to preface composer commands with COMPOSER_MEMORY_LIMIT=-1

Basically, there seems to be a fundamental problem with composer's large amount of memory usage. I envision this will get worse in Drupal 9. I hope not.

It should be possible to run

John_B commented 27 May 2020 at 06:50

It should be possible to run composer without setting memory limit expressly if your php.ini for php cli use has a high enough memory limit. Of course on shared hosting it is not usually possible to adjust the php cli memory limit, even if you can change it for the site.

Drupal 9 is not likely to be any worse.

On the basis of my experience, there are situations where I positively recommend Drupal 8, but only after warning the client that the budget will need to rise compared with Drupal 7 or BackdropCMS.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Since Composer is now used

Jaypan commented 27 May 2020 at 16:09

Since Composer is now used for module updates, at the present time, one would have to upload each site one or more times a day to keep updated. This is impossible realistically.

To be honest, this doesn't make sense to me. I've worked in companies that managed 10x that many sites, and didn't have this issue. It sounds like you've got an edge-case in your server setup if this is happening to you.

I agree, meaning I too did

John_B commented 27 May 2020 at 17:34

I agree, meaning I too did not understand why things are so difficult. It is true that Drupal 8 and its modules have way too many updates, which is a burden. However, a minority of the updates are security updates, so they can wait for a few days or weeks or months. And for the majority of sites, the majority of security updates can be delayed after checking the security advisory to ensure the the issue is not urgent.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

But on my hosting ISP,

xaa commented 27 May 2020 at 14:22

But on my hosting ISP, composer update and composer require do nothing. There are no error messages, it says composer.json is updated, but no files are changed. I have to update modules using wget into modules/contrib, which is clearly wrong.

On the prod server use composer install instead of composer update.
As other mention it composer require should be used locally.

On prod., don't use composer at all

gisle

he/him

Norwegian Bokmål

Norway

commented 27 May 2020 at 14:40

On prod., don't use composer at all!

If you set things up correctly, the only place you need to use composer is on the staging server. Just use some syncing tool (I use Unison), create a script to edit certain settings strings (e.g. trusted_host_patterns and file_private_part, and Bob's your uncle.)

If you don't know how to set up this yourself, hire somebody capable to do it for you, for instance by posting in the Paid Drupal Services forum.

- gisle

That is perhaps 6-12 syncs a day

tjtj commented 27 May 2020 at 15:50

composer require locally only means 6-12 syncs a day with my host. Just an awful workflow. But I will look at unison.

Composeur

hazit commented 5 June 2020 at 07:13

I completely agree with the sentiment expressed in many of these posts. This Composeur - er, sorry - Composer business does seem to signal the demise of at least some of the founding ideals of Drupal - that it be an accessible tool and not just one for coding elites.

For those who get to do development all day and get paid for it - more power to you! I get that some tools continue to develop in sophistication and that users of those tools need to evolve and adapt. That's cool.

But there is some serious mixed-messaging around Drupal now. One the one hand its an expansive kind of 'yay - this is a tool for everyone' story and then on the other hand there is Composer. Clearly it's not for everyone.

Just scan some of the posts chastising novice questions about dealing with this thing. Often they seem quite circular: 'if you are not using drush you are an idiot'; 'if you are still using drush and not using Composer for everything then you are an idiot', 'if you are using Composer and not drush on shared hosting you are an idiot', etc etc.

The documentation around Composer is also absolutely awful - particularly compared with that available for most modules etc.

I'm going to have to persevere and just deal with it, but I just thought I would chime in with a note of support for the original post.

update method

DrupalDope commented 6 June 2020 at 03:07

I solved my upgrade problems by using a quick&dirty method to update Drupal:

1- download full package
2- delete modules,sites and themes directories from package
3- upload the package to your drupal installation, overwriting all
4- visit update.php

The above method will work for smaller upgrades, such as keeping a Drupal site current by applying all security updates and for most small jumps like from 8.4 to 8.6 for example.

Some contrib modules may cause errors when doing larger upgrades or jumping major versions, such as upgrading from 8.0 to 8.6 or from 7.8 to 8.4.
I can't help but to think it's poor form that the updater isn't able to tell which core version the contrib module is compatible with.

In this case, do "small steps", i.e. when upgrading from 7.8 to 8.6, do one step at the last 7 version, then one at the first 8.0 version, etc.
If some modules cause update problems, search for the module versions that were current at the time of the core version and install these versions instead.
This will work, but might require some trial & error.

I have been so far able to update all Drupal sites that way, even older versions.

I can't help but to think it

Jaypan commented 6 June 2020 at 03:07

I can't help but to think it's poor form that the updater isn't able to tell which core version the contrib module is compatible with.

That’s what composer is for and does. It’s a project manager, one of the features of which is to confirm compatibility. So the functionality you mention already exists if you use Composer.

I have tried 4 times to get

DrupalDope commented 6 June 2020 at 07:10

I have tried 4 times to get composer up and running with existing sites - it never worked, and every time it took way too much time to setup, I wasted lots of hours.
I found this rather neat-looking tutorial: https://drupalize.me/tutorial/use-composer-your-drupal-project?p=3233
But it already fails because there is no windows version of it. The tutorial also uses git and drush...

Composer remains a no-go for me, as I can't easily start to use it for existing sites.

If dependency data is available to composer, why can't it be made available for display (i.e. only in an informative role) to the updater?

Drupal needs a way to update that doesn't require any other tools than file upload. The alternative is losing a significant part of the userbase.

Your step 3 is wrong!

mmjvb commented 6 June 2020 at 06:32

Its purpose is to replace what you have with what comes from the package. In order to do that you need to remove what you have and upload from the package. That way things no longer needed are removed. The reason they need to be removed is that they MAY have an effect when they remain.

Also you'll loose customizations this way. Hope you have a backup of the scaffold files. You need to apply your changes to files like .htaccess and robots.txt

it's quick & dirty.

DrupalDope commented 6 June 2020 at 07:18

it's quick & dirty.
yes, I guess in some cases unwanted files might remain.
obviously it's not as perfect as a viable, working, clean and simple update procedure. please point me to one and I will use your method instead.
however, as I couldn't get any other update method to work, this is the way for me right now.

I don't usually make changes to .htaccess and robots.txt files

scaffold files... that's something composer uses, useless as I can't get composer to work.

and no, I don't lose any customizations this way, because my customizations are all in the modules, themes and sites folders.

if Drupal wants to solve this problem for the numerous people who are currently unable to update their Drupal sites, here is what we need:

-a very detailed tutorial on how to setup and use composer to update existing sites, using Windows 10 as a platform.

I think the interested userbase will be able to use WAMP or a similar tool for local development and update of the site (XAMPP was way too complicated and unflexible for me, for example). Then they just need to upload the updated website to the webhost.

As mentioned : Quick & Dirty and WRONG

mmjvb commented 6 June 2020 at 08:20

No need to to use a different method. Just use your method, called manual method, but do it right!
But you are right, you are allowed to create your own problem by doing things incorrect.

You are also wrong when claiming scaffold is something Composer. Scaffold is something Drupal, regardless whether you manage it manually, drush or composer. It is a collective name for files part of Drupal, but not part of core or vendor.

using the manual method as

DrupalDope commented 6 June 2020 at 08:35

using the manual method as described on drupal.org breaks my sites.

I have asked for months how to update, but never got a working solution.

Impossible to manually update existing drupal sites unless not deleting the "vendor" directory.

it has something to do with this warning on the "manual update" page:
https://www.drupal.org/docs/updating-drupal/update-core-manually

If you have installed any contributed modules with 3rd party dependencies using Composer, you need to use the other update options as these instructions will overwrite your vendor/ directory.

It's nice to give a warning, but no solution for updating such an existing site is provided.

Again, I would be delighted to get composer to work if someone provided me with instructions on how to achieve that on Windows for an existing Drupal 8 site.

When doing the right things gets you undesired results it is

mmjvb commented 6 June 2020 at 08:49

reason for investigation.

Doing the right things is not enough, it is also necessary to do things right. Even when doing both it is no guarantee for not running into problems. It is very possible it reveals mistakes made in the past.

Suggest to ask for assistance analyzing the problem you experience in your situation rather than concluding there is a general problem.

thanks for that actionable

DrupalDope commented 6 June 2020 at 09:34

thanks for that actionable and material solution!

a tutorial on how to get composer to work on windows 10 with an existing site would be entirely sufficient.

can we agree there is a need for this?

I want to convert my sites to composer, but I can't.

All I ask is to be provided with a way to "composerize" my sites using the mainstream tools I have at my disposal.

I have:
- Windows 10
- WAMP
- Drupal 8.8.6 site installed and working on WAMP
- Composer is installed and working

what now?

Why do you develop websites on Windows 10?

gisle

he/him

Norwegian Bokmål

Norway

commented 6 June 2020 at 10:23

a tutorial on how to get composer to work on windows 10 with an existing site would be entirely sufficient.

can we agree there is a need for this?

It is obviously a need for this, but who is going to write it? I've tried to run composer on Windows 10 and concluded: Life it too short for this.

If it gives you so much grief, why do you develop websites on MS Windows 10?

Don't get me wrong, I use Windows 10 myself - it is a great platform for MS Visual Studio, Android Studio, MS Office and Adobe Creative Suite - just to mention some of the products that I use daily on Windows 10.

But I also have a home computer set up to run Gnu/Linux (Ubuntu 20.04 LTS to be precise), where I use the terminal to run composer, drush + a development environment that match my production web server. Home computers are so cheap these days that having two (one for MS Windows 10 and one for running Gnu/Linux) is not going to break the bank. If you also think that time is money (I do) the time you save by running composer and other tools native to Gnu/Linux on that platform very fast pays for the extra hardware.

- gisle

I live on Windows 10.

DrupalDope commented 6 June 2020 at 11:18

I live on Windows 10.

My email is there, my browsers, I have my habits, my little tools, etc.

I have only one screen. I don't want to be disconnected from life - i.e. whatsapp, line, email, etc. while I work on the linux box.

I also travel a lot.

I also have no wish to invest even more time to learn installing things and developing on another platform. It all distracts from creating content and functionality.

Is it a good thing for Drupal to require Linux for updating sites?

How much of the userbase is being excluded?

I have only one screen. I don

gisle

he/him

Norwegian Bokmål

Norway

commented 6 June 2020 at 11:48

I have only one screen. I don't want to be disconnected from life - i.e. whatsapp, line, email, etc. while I work on the linux box.

So do I. And that screen is on my Windows 10 laptop.

So I connect to my Gnu/Linux home computer using X-Win 32 (not free). Some folks use PuTTY (free software) instead. I also use Unison to automate syncing between dev and prod, but that is not strictly necessary, pscp let you do it as well (but not automatic).

I also travel a lot.

And the Internet let you connect to any computer that is connected to it, so that should not be a problem.

Just for the record: I used to hate composer (check out some of my older forum posts). It has grown on me since then.

Is it a good thing for Drupal to require Linux for updating sites?

I never said that Drupal require Gnu/Linux for updating sites. But I think composer is necessary for updates these days (at least for me, old school manual updates don't work with Drupal 8 and 9).

All I said was this: Developing on a cheap home computer running Gnu/Linux in order to use composer and other CLI tools works for me (YMMV). I am not trying to dictate you, just telling what I experienced (as are others here) that may work as a practical solution to the problems you are facing.

Another developer here (John_B) seems to be doing fine using a Gnu/Linux system on top of Windows 10. Maybe that is a route that is a better fit for you than the one I've taken?

- gisle

OK, I'm interested. As I

DrupalDope commented 6 June 2020 at 12:43

OK, I'm interested. As I already wrote above, I am really interested in getting this to work.

The home computer thing probably isn't what I want, since I want to be able to develop on the same machine, and I don't want to be dependent on the internet connection, which might be down or might not have the necessary bandwidth.

The Windows Subsystem Linux is an interesting proposition, I wonder if I will be able to switch php and mysql versions as easily as with WAMP and whether I will be able to access the websites and files from windows... I'll try to educate myself on the subject.

It's really mindblowing that there is no ready-baked information on this. There must be literally thousands of people in the same boat.

BTW, if someone is reading this, I am currently using WAMPserver to develop drupal site on windows. It works very well except for the updating part.
What I really like in WAMPserver is that to change PHP or MYSQL versions, or even parameters like PHP memory, or loaded Apache modules, it can all be done with a simple mouseclick, it all comes pre-installed, ready to use, including the vhosts.
Is there an equivalent for WSL 2 / ubuntu ?

I wonder if I will be able to

John_B commented 6 June 2020 at 12:46

I wonder if I will be able to switch php and mysql versions as easily as with WAMP and whether I will be able to access the websites and files from windows

You can access your files form Windows. Linux subsystem files are buried somewhere in a directory you probably do not normally visit, I do not remember exactly where, but you can put a link on the desktop. For interacting with the Linux subsystem I quite like cmder, just open it and type 'bash' and you are in. You can also connect to Linux subsystem on Putty with IP 127.0.0.1 as I recall.

As for switching PHP versions etc. I find that once you learn, most things are faster on command line. However, it does take a while to learn. I see no reason why you could not install a control panel such as Virtualmin on a local machine, though I never have.

In order to get your various local domains you working in a Windows-based browser you will probably need to add them to your Windows hosts files. If you are working with a single default site, just 'localhost' may do, as per this tutorial for a command-line setup: https://polso.info/how-install-drupal-8-and-composer-windows-10-bash (though the tutorial is out of date because it is using php5, not php7.3).

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

I'm a visual person. I'm good

DrupalDope commented 7 June 2020 at 04:28

I'm a visual person. I'm good at 3D/4D pure geometry, languages and pattern recognition - I like procedural programming, not OOP. I'm not a person who can memorize too well exact commands and I'm not good at abstract learning. This causes me to be super slow when I'm using command line. I'm unable to remember exact commands, so I write everything down. I only use command line when installing servers or when there is a problem. I have no time to learn the intricacies of unix servers, I need ready to use how-tos. The mistakes I do lead to even more wasted time when I fix them. The other day I did a chgrp -R / thinking that was the current directory - much fun I had after that. Took me 8 hours to fix.

Nothing is quicker and safer than a simple mouseclick to change a php version on WAMPserver.

I'm ready to try using WSL with ubuntu, but I really want to find a WAMPserver equivalent to speed up all the configuration stuff.

I like Virtualmin as a

John_B commented 7 June 2020 at 06:52

I like Virtualmin as a control panel, though it is rather complex and fully featured, becuase unlike cPanel it can be combined with command line interaction. I have never installed it on Windows Linux subsystem but others have, e.g. https://codingjungle.com/tutorials/development/lamp-webmin-with-wsl-in-w...

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

thanks - I have the feeling

DrupalDope commented 7 June 2020 at 07:11

thanks - I have the feeling Virtualmin is not the tool I want, it's too close to managing the webserver, while I want a tool that manages the LAMP stack.
Entering "sudo service apache2 restart" in command line or editing php.ini files with a text editor are things I want to avoid.

When using Virtualmin you

John_B commented 7 June 2020 at 07:28

When using Virtualmin you never need to touch command line if you so choose, once it is up and running. It is a bit complicated to find your way around.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

I'm not yet sold on

DrupalDope commented 7 June 2020 at 08:44

I'm not yet sold on Virtualmin - what's your experience with it? Can you just create a vhost, drop files in there, create a database, import an SQL file through phpmyadmin and it will work? how are the hosts accessed through the browser in Windows? does the vhost work locally? what if I need to switch to older or newer versions of mysql or PHP?
And what is it like to work on WSL2 for website development? Can I just push files around Windows and ubuntu? how do you edit the files? does copy-paste work from Windows to WSL2 and back?

Or if developing on ubuntu/WSL2 isn't directly possible, how can I access the files through windows for development?

Many thanks for your insights

You can do all those things

John_B commented 7 June 2020 at 08:45

You can do all those things in Virtualmin. Maybe search for simper alternatives.

As for Windows hosts, you will have to edit your Windows hosts file. As far as I know that is also true of WAMP. I have never used Virtualmin for local dev, so cannot actively recommend. It is just an idea which may be worth testing. I used it a fair amount for online servers in the past and like it, though there is a learning curve.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

with WAMPserver no editing of

DrupalDope commented 7 June 2020 at 09:22

with WAMPserver no editing of the hosts file is needed.

ok, so you have no experience in using virtualmin on ubuntu with WSL2.

excuse my frustration... I still haven't found anyone with experience in what I try to achieve.
you see me running around the internet grasping at straws, doing all kinds of contorsions and pouring in hours after more hours just to get my Drupal sites updated. so far I have achieved nothing and I have been sitting on this update problem for years now.

Drupal has to find a way out of this mess or it will leave many users behind.

Attempts to get one-click

John_B commented 7 June 2020 at 09:37

Attempts to get one-click updates into Drupal are still in beta. See https://www.drupal.org/project/automatic_updates and follow the links. Maybe worth a look.

If Drupal continues to frustrate, maybe migrate the sites to WordPress. Or if you are comfortable with drush, migrate to BackdropCMS.

WordPress migrations are a bit of a pain though some online services using automated scripts for a modest fee do much of the heavy lifting. I have done it. Where there is budget for a custom Drupal to Wordpress migration, there is https://anothercoffee.net/. Anthony has huge experience in this field, and believes in careful planning and high standards.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Drupal is not the issue here.

DrupalDope commented 7 June 2020 at 10:12

Drupal as a CMS is not the issue here. Drupal is best suited for my website development requirements, the only really big problem are the updates.

Wordpress is unsuited for a number of reasons, a big one is that it doesn't support multilingual sites, another big problem is the mess that Wordpress is. I can't work with Wordpress.

I suspect that one-click updates require a working composer.json file. Building that file for existing sites is my problem for which I am desperately searching a solution.

I like Drupal, I like developing on WAMPserver, everything is fine except the updates with that damn vendor directory.

Troubleshooting

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 10:23

For what it is worth, here is a link to my field notes about troubleshooting when composer refuses to update a site: http://wikihandbooks.com/drupal/cli_composer.html#cp8_trouble

- gisle

thank you gisle, I'm sure

DrupalDope commented 7 June 2020 at 10:34

thank you gisle, I'm sure that will be useful for some.

I really need a solution to make the composer.json file for existing Drupal sites.

The thermonuclear option

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 10:47

I understand that you need to make the composer.json file for existing Drupal sites. I've been there myself. But sometimes, the only thing that works is the thermonuclear option (where you nuke the site and start afresh, rebuilding the site package by package). I would love to hear about a less labour-intensive way of doing it, but so far I haven't heard about one that works.

Composer is extremely unforgiving about tiny errors in composer.json, composer.lock, and that huge sinkhole known as vendor. I've yet to see a receipt for just adding the files that composer depends on it to an existing site that works. If one of those three files is fubared, and you've run out of debugging options, updating that site using composer is not going to work, and the only thing that will restore sanity is the thermonuclear option.

- gisle

Installing modules one by one

DrupalDope commented 7 June 2020 at 10:57

Installing modules one by one is not that tedious, but does the thermonuclear option include a way to import content from database?

I guess all of the things you mentioned are fubared.

Are you really suggesting that in some situations there is no way to convert a working Drupal site to composer? That would be even worse than I feared.

Composer is only about the codebase

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 11:06

Composer is only about dependency management of the codebase. It does not even know about the site's content (which all lives in the database).

When you've got a healthy codebase, you migrate the database using whatever database tool you're happy with: contributed extension Backup & Migrate, phpMyAdmin or mysql/mysqldump. You do this independently of how you arrived at a healthy codebase. Just remember to run the database update script after migrating the database, in case the updated codebase has any database updates queued. You can do this from the GUI or from the CLI.

And I am not at all suggesting that there is no way to convert a working Drupal site to composer. I think I've successfully converted more than one hundred different Drupal sites from using drush to manage updates of the codebase with composer so far. You just need to use the right tools, and know how to use them.

If you are not willing to use the right tools, or you refuse to learn how to use them, it will of course be a lot harder to do such conversions.

- gisle

Well, if you read my posts in

DrupalDope commented 7 June 2020 at 11:21

Well, if you read my posts in this thread, you will know that I don't refuse to use the "right tools", I just don't have a convenient access to the "right tools".

I am relieved that a site's database can be simply imported.

Regarding learning how to use the right tools: I am someone who needs precise instructions. I am unable to learn from abstract magistral demonstrations and then apply them.

I will try applying these instructions and then report how it went:

https://www.drupal.org/docs/installing-drupal/add-composer-to-an-existin...

Maybe it is worth repeating

John_B commented 7 June 2020 at 11:25

Maybe it is worth repeating the recommendation of Jaypan's series on Composer, starting at https://www.morpht.com/blog/drupal-and-composer-part-1-understanding-com.... It is not a simple recipe. Nevertheless, it clarifies things, and like cooking some knowledge of the basics makes it easier to follow recipes.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Jaypan's series changed my opinion on composer

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 11:51

I second the recommendation of Jaypan's series on composer. That series changed my opinion about composer from downright hating it … to just disliking it.

I cannot really bring myself to liking composer: It can't be installed on cheap shared hosting, has an enormous appetite for memory, a steep learning curve and the official documentation suck – but Jaypan's series go a long to mitigate the remedy the faults in the official documentation.

- gisle

I second the recommendation

Jaypan commented 7 June 2020 at 14:23

I second the recommendation of Jaypan's series on composer. That series changed my opinion about composer from downright hating it … to just disliking it.

Yay... I think :)

by the way, I have another

DrupalDope commented 7 June 2020 at 11:10

by the way, I have another question - I would like to benefit from your experience of working with composer.

So, I would like to know if composer will mess up things even more when it meets a misconfiguration, or does composer restore the initial state when it fails?
Is restoring a file backup sufficient to go back to the previous state after composer failed ?

Composer restores when it

John_B commented 7 June 2020 at 11:19

Composer restores when it fails.

Composer update often fails on shared hosting because it requires a lot of memory. The better hosting support departments will raise the memory available if you say composer is failing. Drush normally works on shared hosting.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

Composer restores when it

John_B commented 7 June 2020 at 11:21

Composer restores the original code when it fails. In an ideal world you also have the code in git so you can roll back in the event of a failure. For small sites I find git adds overhead rather than making life easier--until things go wrong and you need it!

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

thank you

DrupalDope commented 7 June 2020 at 11:22

thank you

Computer says "no"

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 11:22

AFAIK, composer does not change state if it fails, That means that there is no need for a rollback to the initial state.

At least for me, when composer fails, nothing happens. The site simply will not update. It is a bit like that skit in "Little Britain" - https://youtu.be/AJQ3TM-p2QI . The hard part then is to figure why the computer says "no". Sometimes you can't, and need to go for the thermonuclear option.

AFAIK, you don't have to restore. If composer fails, nothing changes. You're just stuck with a webite that you're unable to update (which of course is not what you want, in particularly if that update you want to do is a security update).

- gisle

this is like running a

DrupalDope commented 7 June 2020 at 09:44

this is like running a gauntlet of headaches.

I found out my Windows 10 was running WSL 1, which is not compatible with Virtualmin because of some obscure error with jcameron-key.asc "IPC connect call failed".

so I want to upgrade to WSL 2, but it requires joining the Windows insider program with a Microsoft account and activating full telemetry.
*sigh*

*** please, when will it stop ***

so I just gave ubuntu on WSL2

DrupalDope commented 7 June 2020 at 08:37

so I just gave ubuntu on WSL2 a try.

ubuntu itself works, I don't know about LAMP yet, tried to install KDE plasma on it, but it doesn't start. it was super-slow to install too.

If you want to use Windows 10

John_B commented 6 June 2020 at 10:56

If you want to use Windows 10, as I do, you can always install the Linux subsystem and run a LAMP stack there. It is easer than dual booting, and easier than running Docker and the other compicated solutions. Of course, developers like to over-complicate things, but then if you did not enjoy verbose code, a byzantine 'bubble-up' caching system, and a plethora of libraries managed by a dependency manager which is itself a dependency, you would not have chosen Drupal 8 in the first place.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

you would not have chosen

DrupalDope commented 6 June 2020 at 11:10

you would not have chosen Drupal 8 in the first place.

There was no informed choice to make, since Drupal didn't advertise its issues with updates. On the contrary, the manual update method has always been presented as a viable option. it isn't anymore.

also, I have come so far now that I don't really have another choice than to stick with Drupal.

This is why I only have one drupal site left

Matt B

English

commented 6 June 2020 at 11:11

I've been reading these comments as they come in over the years. This maintenance nightmare is why I have only 1 site left on drupal!

This site makes a case for

John_B commented 6 June 2020 at 11:23

This site makes a case for Windows being good for running Drupal: https://www.drupalonwindows.com/en/blog/installing-drupal-8-windows#comp...

MS have included a Linux sub-system for good reason, and I do use it as an important part of Windows for developers. If you don't want to learn and use it, why not use a Windows-friendly CMS such as Umbraco? However, the guys who wrote the site I linked would disagree with me about Windows being unsuited to Drupal. Of course, everything to do with Drupal, be it Linux or Windows, does involve a lot of ongoing learning.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

getting Drupal 8 up and

DrupalDope commented 6 June 2020 at 11:52

getting Drupal 8 up and running on Windows is not the issue. And even that 2016 article is about using IIS... I guess by now almost everyone is using WAMP.

my issue is about how to convert an existing Drupal site to composer... on Windows.

actually, I might have found

DrupalDope commented 7 June 2020 at 10:42

actually, I might have found a way out of that mess.

one of my webhosts has both composer and drush installed.

so, in order to make that composer.json file, I could just upload the current Drupal site to a staging vhost, and do all the work there to make that composer.json file.

and then I don't need WSL2 or Virtualmin or anything and can happily keep using WAMPserver on windows.

If you do this - what shall you use the WAMP server for?

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 13:12

If you have your staging host in the cloud, what's the purpose of the WAMP server on Windows? And for what purpose are you creating composer.json?

Just to make clear: You don't need composer.json to run a Drupal 8 or a Drupal 9 website. The whole purpose of composer is to manage dependencies in your codebase during development/staging. Your production Drupal website will run just fine without composer. But you want composer to sort out the entanglements that arise from updates, because doing it any other way is a true PITA. To sort this out is always done by making sure all updates of the code base take place directly on the staging server (using composer require ... commands). After updating on the staging server, you then copy the updated codebase (modulo composer.json and composer.lock) to the production server.

Most of those pesky dependencies you don't even know about. They come from extensions you've installed on the site, and composer simply keeps track of them, and when your website needs to be updated, composer ensures that the correct versions of the libraries you use are downloaded to the vendor directory and stay correct during all those updates.

So if you do any change to the code base on the WAMP server, and just upload those changes to the staging vhost, you will introduce changes to the codebase that composer know nothing about. I shall guarantee that this is going to break your site and you will probably not be happy when you experience this.

So if you want to run composer on a vhost in the cloud, you cannot make any changes to your codebase on the WAMP server on Windows. All changes to the code base must then happen on the vhost in order for composer to track them.

- gisle

I don't have my staging host

DrupalDope commented 7 June 2020 at 13:44

I don't have my staging host in the cloud.
But I could make one there for the sole purpose of getting a clean composerized Drupal - hoping I will not run out of memory, because it's shared hosting.

Then - once my Drupal has been cleanly composerized - I will take the site back to WAMPserver on my Windows machine.
Composer is installed and working on my Windows machine, so my hope is that I will be able to perform any future updates on my Windows machine.
And I will use Composer to install modules to the Drupal site on WAMPserver.

Is that a viable course of action?

I cannot see why you need a vhost, then

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 13:58

If you have composer installed and working on the WAMP-server on your Windows machine, I cannot see what you gain using a vhost on shared hosting for anything.

If that is the situation, you shall be able to use composer directly on your WAMP-server to get your present Drupal website composerized. You probably have more memory on that WAMP-server than you'll get on bargain basement shared hosting.

And then, of course, perform any future updates on your Windows machine, making sure you install any extensions to your codebase using composer.

Maybe I am missing something, but if you are able to run composer on your WAMP server, you have no need for a staging vhost.

I think all this detour about a Gnu/Linux home computer (me) and WSL (John_B) was because we assumed that composer would not work on a WAMP-server.

- gisle

we come back to the problem

DrupalDope commented 7 June 2020 at 14:09

we come back to the problem of converting an existing site to composer.

all instructions I could find for converting an existing Drupal site to use Composer are written for Drush and Linux. there are no instructions for Windows.

Instructions for using composer to composerize an existing site

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 14:32

If you are talking about these instructions:
https://www.drupal.org/docs/installing-drupal/add-composer-to-an-existin... - I may have bad news. These instructions did not work for me a on a Gnu/Linux vhost when I tried to use them (but that was about a year ago). I just ended up with a broken site that could not be updated.

I see that these instructions have changed a lot since last time looked at them, so don't let my bad experience from 2019 scare you off. The release of Drupal 8.8.0 improved a lot things vis a vis composer, so they might work just fine in 2020.

But I'll try to find time to write up the exact instructions that I use to composerize an existing Drupal 8 website. It doesn't use bash or drush or any other Gnu/Linux specifific tools, so it should work fine on a WAMP-server with composer.

It will take me some time to write it down, so if you follow any alternative route (including the one linked to above), please report the result here. I advice others on this, and want to be able to share the most up to date information about this topic.

- gisle

many thanks to you if you

DrupalDope commented 7 June 2020 at 14:58

many thanks to you if you write that.

so far, there are 3 docs I had a look at:
Jaypan's
Drupal's
Drupalize.me's

I will of course give it a try.
But of course it would be better if the whole process could be completed on Windows.

Composerize an existing website

gisle

he/him

Norwegian Bokmål

Norway

commented 7 June 2020 at 19:59

OK, here it is: Composerize an existing website.

The only CLI tool needed is composer (no drush or bash). I don't have a WAMP-server so I am unable to test it, but if it doesn't work, just complain and I shall try to sort it out. (I have tested it on Gnu/Linux, and it works on that platform.)

- gisle

You need drush

tjtj commented 8 June 2020 at 00:52

If you get that awful white screen of death, the ONLY way to see what is wrong is to do drush ws.

wow, thanks, that was quick!

DrupalDope commented 8 June 2020 at 04:28

wow, thanks, that was quick!

I have a question though - if I use a module like this one for example: https://www.drupal.org/sandbox/nextonizh/2918108

how would I include it ?

See https://blog.wturrell.co

John_B commented 8 June 2020 at 06:48

See https://blog.wturrell.co.uk/install-drupal-8-sandbox-module-via-composer/

When I used it I seem to recall needing to tweak it (or my understanding of it) so you can also search for 'sandbox module composer' for other explanations.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

You don't need drush, and thanks to John_B!

gisle

he/him

Norwegian Bokmål

Norway

commented 8 June 2020 at 07:31

@tjtj,
no, you don't need drush. Just make sure you visit: Configuration » Development » Logging and error and select "All messages", and you will get the error on the screen instead of a WSOD,

@John_B,
thanks for the link to blog.wturell.co.uk. I've added it to the instructions. If you remember, or somebody else is able to figure out, what that tweaks is, please let us know, and I'll add to the instructions.

- gisle

You cannot with a white screen of death

tjtj commented 8 June 2020 at 13:55

If the GUI is gone, you need Drush!

You get a white screen with the error message

gisle

he/him

Norwegian Bokmål

Norway

commented 8 June 2020 at 14:36

@tjtj,
when the Drupal GUI is gone, you get a white screen with the error message, and the call stack as well. The error message is the same message as the one you can inspect with drush ws. So you really don't need drush to see this. See screen dump below.

Right-click on the image to see it full-size.

- gisle

I never get the stack dump

tjtj commented 8 June 2020 at 18:40

I only get the encountered an error message.

Drush is really handy too for other things.

Upgrading from Drupal 8 to Drupal 9 is no easier

tjtj commented 18 September 2020 at 18:40

It is all about the modules not being ready. I wrote up what I had to do for anyone else having problems:

https://jamesrome.net/drupal/d8-d9

No joke

Silverngold commented 19 September 2020 at 20:36

Just a designer here with no code knowledge whatsoever. I rely on Cpanel. Just updated to drupal 9. Could not update php. Switched back to 8.9 and everything was fine. Tried 9 again to be sure and same result. Back to 8.9 and working fine. I'm happy with 8.9. funny even when I go into updates it says I am up to date but 9.0 is ava. I'll check it later this year and give it a whirl.

PHP version

fkelly12054@gmail.com commented 19 September 2020 at 20:45

Cpanel user here also. Inmotionhosting. My Cpanel has a new feature known as Multi-PHP where you select your PHP version ... also can set up error logging there. Cpanel used to have a simple drop down for selecting PHP version. You might want to look around your Cpanel and see if Multi-PHP is available. PHP 7.4 has fixed at one nasty bug that lower versions of PHP had and that newer versions of Drupal triggered. I'd contact my hosting service help desk if I didn't see a way to update the PHP version.

Of course, going to Drupal 9, you have to make sure that all your contrib modules are ready.

PHP 7.4

Silverngold commented 19 September 2020 at 21:46

fkelly, I have a reseller account at inmotion. Multi-PHP is what I use. Set PHP to 7.4. I"m sure it is the modules. Updates just told me everything is up to date. Maybe I'll try it one more time and see just for kicks.

php module is not ready for Drupal 9

tjtj commented 19 September 2020 at 22:02

Hence my blog about updating modules. Is this the LAST time that modules will need to be changed to go to Drupal 9.1,... 10.0?

Yes, as TjTj mentioned in his

fkelly12054@gmail.com commented 20 September 2020 at 02:28

Yes, as TjTj mentioned in his blog post, there is a Drupal module that tests the readiness of your Drupal contrib modules for Drupal 9. Or just look at them individually. There's no shortcut, really: I'm waiting on one of my contrib modules to be made ready and have no option but to wait.

I think we can be sure Drupal core will always be ready for new PHP versions before they upgrade. It would be suicide for Drupal otherwise. But as for contrib modules, you are on your own or dependent on the good graces of your contrib maintainer.

It is the php MODULE that is not reaady

tjtj commented 20 September 2020 at 12:21

It provides php filter.

Another issue is that there are many modules that have patches available. Why can't they be committed to the dev versions so that we can mange things with Composer and without applying patches in it?

And Composer 2 is a big improvement in both speed and resource requirements, but it fails because many plugins are not ready. Why not?

Abandoned modules

gisle

he/him

Norwegian Bokmål

Norway

commented 20 September 2020 at 13:05

There are more than 46 000 modules in the Drupal eco-system and it inevitable that some of those modules are abandoned by the people that once maintained them. People change jobs, lose interest or no longer has the spare time for this type of volunteer work. When nobody is around to maintain the module, patches are no longer committed to repo, and those who still want to use the module must apply them locally.

The Drupal community has a well established procedure for Dealing with unsupported (abandoned) projects, but a lot of the users that rely on abandoned projects shy away from taking on this type of responsibility. That means that a lot of our abandoned modules just stay abandoned. If you don't like it, now you at least know what you can do about it.

- gisle

The raw answer

Stephen Camilo commented 27 October 2020 at 17:47

I guess that the raw answer is that Drupal 8 can be used for small and low budget projects, but is best suited for Enterprise level projects.
https://alexrayu.com/blog/why-drupal-8-not-small-websites

It all works now! --Almost

tjtj commented 11 February 2021 at 15:33

I am pleased to report that with Composer 2 and a proper composer.json file, running "composer update" in 9.1 updates any of my sites in just a few minutes with no memory issues. The KoolAid tastes good.

However, on all of my sites (6) now that everything is in the web subdirectory, the update GUI no longer works. Somewhere along the way, my authentication as admin gets lost, and I get no permission to do this error. I posted this as a bug and also in the forum, bug to no avail. Same as https://drupal.stackexchange.com/questions/246076/cant-install-modules-from-ui-when-site-placed-in-subdirectory.

and https://www.drupal.org/project/drupal/issues/3189080

Sorry, Composer rocks. :)

bcgreen commented 6 April 2022 at 21:30

Sorry, Composer rocks. :)

John_B commented 12 April 2022 at 05:35

Sorry, Composer rocks. :)

Managing Drupal with Composer rocks like banks relying on the internet to manage your money rocks. Whoever came up with that idea must have been a brilliant "engineer". It rocks as long as it works, and breaks your heart when it stops working.

I have been there, longing for the simplicity of "drush dl", when trying to straighten out a complex, unmaintained 2015 Drupal 8 site partly managed by Composer.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

I personally have to agree

Jaypan commented 13 April 2022 at 01:44

I personally have to agree that Composer rocks. I personally couldn't imagine going back at this point.

That said it can be particularly frustrating trying to deal with conflicts, as it often doesn't explain the problem well at all.

I now have 1 Drupal site left

Matt B

English

commented 14 April 2022 at 05:01

I now have 1 Drupal site left. The move to Drupal 8 / Composer was to much of an overhead, proving the Drupal is only needed for complex use cases that Google Sites, Wix and the other options for simple sites cannot handle. Now on Drupal 9 with PaaS that supports Composer, it works well. I can't say it rocks, but I guess that depends on what you get excited about!

Composer is pretty good, and

John_B commented 14 April 2022 at 06:26

Composer is pretty good, and greatly improved. It is a source of gremlins on poorly maintained sites which in my experience can take a great deal of work to resolve.

A lot of things about D8/9/10 raised the bar for amateur site builders, cementing the idea that Drupal is a tool built by developers for developers. That is not necessarily a bad thing.

I am deeply sceptical of the orthodoxy that with Composer, projects and libraries should not be committed in git. It looks like a recipe for upstream poisoning, and a point of failure (if the repos are down).

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

I am deeply sceptical of the

Jaypan commented 14 April 2022 at 07:10

I am deeply sceptical of the orthodoxy that with Composer, projects and libraries should not be committed in git.

I've actually heard recommendations going the other way as well - that Composer shouldn't be used on production environments, and instead the libraries should all be committed to GIT. The idea being that having Composer on a server where it could be used to install code, is a security risk.

It looks like a recipe for upstream poisoning

In recent years, I've reached a point where I don't build without end to end tests for all functionality. Tests are run before deployment, to ensure that there has not been upstream poisoning.

and a point of failure (if the repos are down).

This isn't such a big deal, as repos are not pulled at runtime, rather just during deployment. So when a repo is down, it can throw a wrench into deployment. Butto be honest, I've never actually seen it happen. Packagist has solid uptime, and the Drupal repos are pretty consistent as well.

I've actually heard

John_B commented 17 June 2022 at 07:49

I've actually heard recommendations going the other way as well - that Composer shouldn't be used on production environments, and instead the libraries should all be committed to GIT. The idea being that having Composer on a server where it could be used to install code, is a security risk.

Not sure how this works with continuous deployment? I don't do CI or CD but I think I must work out how to set up at least a CI and testing pipeline.

I would be more comfortable committing vendor libraries. However, the authorities (for example an otherwise good presentation by someone from Acquia at DrupalCon Portland) tell us very clearly that it is wrong to commit libraries & contrib, and have made it very difficult to do, as it breaks autoload:

Commit copy of site at /path/to/dev including all code apart from web/sites/, inc. vendor/.
Push.
Pull to second copy of site called stage.
cd [/path/to/stage]
drush @self.dev cr
[success] Cache rebuild complete.
PHP Fatal error: Cannot redeclare composerRequire605db4f3e16dc17f47e05c5aebf0dc28() (previously declared in /path/to/stage/vendor/composer/autoload_real.php:54) in /path/to/dev/vendor/composer/autoload_real.php on line 54

I'd be interested in your thoughts or any serious defence of committing vendor directory, in the context of the problem (a) with CI/CD, and (b) with drush aliases.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

by now, it is safe to say

dehcar

Arabic

commented 30 April 2022 at 10:53

by now, it is safe to say it's easy to say GoodBye Drupal for us small/non-profit midgets, the ego to keep it and make it harder is beyond non tech savvy folks
Aquia defined and found it self as enterprise solution

**updated

seems i wasn't keeping up, Dries already announced it makes no sense thinking about small projects: this was an error Quoting without checking if true

seems i wasn't keeping up,

Jaypan commented 30 April 2022 at 21:36

seems i wasn't keeping up, Dries already announced it makes no sense thinking about small projects

Do you have a link to that?

link to that

dehcar

Arabic

commented 29 May 2022 at 01:51

sorry wasn't on recently, i was catching up reading small articles then a followed up thread of communications, stated that Dries explained in his Key note that there is no need to keep thinking about none coders site builders, since Drupal is majorly made for big Govs and giant tech companies it makes no sense being shackled by such problems,

but i couldn't find a comment or in Dries Blog this statement, the thread said it was mentioned in a video keynote but i haven't had time to watch all videos,

sorry no link as proof i should retract that statement

Dries September 2017 keynote?

gisle

he/him

Norwegian Bokmål

Norway

commented 29 May 2022 at 16:06

I believe that you were thinking about Dries September 2017 keynote, were he said that:

Drupal is no longer for simple sites

I provide custom development and managed hosting for NGOs and others that don't have the budget to hire an agency. I make use of three CMS platforms that all are claimed to be "free software": Drupal, Grav and Wordpress. Drupal is by far the best of these three to work with, including when one is creating and maintaining a small and modest website. So I respectfully disagree with Dries' 2017 sentiment that "Drupal is no longer for simple sites".

It is true that OO Drupal has a rather steep learning curve. Those who monitor these forums can see that I still have a lot to learn. But the friendliness and quality of the Drupal community is unmatched by any other CMS, and the software engineering standards adhered to by the security team, core developers and some contributors are also very high. Having learnt the hard way that the real cost of software is the cost of maintenance, I will say that Drupal maintenance stacks up real well these days.

- gisle

I think the distinction to be

Jaypan commented 29 May 2022 at 19:43

I think the distinction to be made is that Drupal can be used for simple sites, and is often a good solution for them, but for someone who doesn't know Drupal and wants to learn it to build a simple site, Drupal may not be the right choice. It's extremely powerful, but there's a lot of power to sift through to learn the requisite parts to build a simple site. I'm comfortable using it to build a simple site (https://www.drupal-module-review.com - shameless self plug, built in a weekend), but it takes hundreds of hours of usage to get to the point of being able to build simple sites in a simple manner.

thank you

dehcar

Arabic

commented 30 May 2022 at 04:13

thank you for pointing out where it was mentioned, the person rephrased it, i don't blame him/her,

By all means am no tech savvy, but i know my way a Little bit more than a normal user around Drupal but i lack skill to code so less than a programmer.

and the answer to the Big Question, WHY PEOPLE STILL USING IT DESPITE IT'S FLAWS, IMHO is that Drupal excel in certain areas that makes people go back, for example role management, theme don't control business logic and how Drupal deals with content

one biggest problems i see is themes / theming the website or out of the box looking good, am loving Olivero already i hope they make it eCommerce compatible too and reduce a little bit the size of things,

Been trying to make a switch to WordPress, i think Drupal UI/UX administration is bit better than WordPress, I don't know why WordPress is Touted to be easy, or maybe am just now used to Drupal's logic,
i opened my eye in Drupal 7, and built a now dead eCommerce project solution for a small Shop, i think Drupal commerce is far better than WordPress too, though WordPress has colossal amount of plugins to do your biddings, when that happens i start thinking am i lacking lot of knowledge or Drupal feel like built to be a backbone for others to extend with code only as lot of plug-ins dies unless they have prominent roles, that's where i feel Drupal is beyond normal site builders especially if they try something beyond writing articles or having a simple eCommerce site

Drupal 8 is a horrible CMS. I

superfedya commented 14 November 2023 at 01:38

Drupal 8 is a horrible CMS. I liked so much Drupal 6, but 8 is another thing...

I spend many hours to debug composer. It make the system very fragile and hard to manage. Drupal 8 modules are full of erreurs, I often had the problems after update modules.

I hope Drupal 10 is better... If not, is there another, more logical CMS?

Yes, Drupal 8 was a horrible CMS

gisle

he/him

Norwegian Bokmål

Norway

commented 14 November 2023 at 10:17

superfedya,
yes, Drupal 8 was a horrible CMS – in particular prior to version 8.8. It is now also well beyond its "best before" date, as it reached EOL in November 2021- I.e.: The version of Drupal this topic complain about is not relevant anymore. For the record: Composer version 1 was horrible too, buggy and a resource hog. Composer version 2 is very much improved.

This particular topic is from January 2017. That's nearly seven years ago, and IMHO, much of what was being said here (including my own posts) today appear very dated, and not at all relevant in November 2023.

Drupal 10 is very much better. Minor updates (e.g. from version 10.1.5 to 10.1.6) takes me less than a minute. Major updates (e.g. from version 9.5.11 to 10.1.6) takes me around 15 minutes on average. Both processes are glitch-free for me, and have been so ever since I learned to use Composer correctly for setting up and updating a Drupal website.

Caveat: Composer has a very steep learning curve, and it very unforgiving if you don't really understand how to use it. If you're not willing to learn and to use Composer (or not able to because of hosting restrictions), do not use Drupal 10 as your CMS.

As for alternatives: Those mentioned most often are Backdrop CMS and WordPress, along with no-code solutions such as SquareSpace. If you decide to not buy into a Composer-based workflow and ditch Drupal 10, the best of luck whatever you choose.

- gisle