Hi,
I'm trying to use Drupal 8 for the first time (after years of using d6 and d7).
I have enabled the "admin menu" module, dev version and after this action i have the white screen WSOD.

I can't disable the module by the admin/modules page because i obtain a WSOD.
I delete the "admin_menu" folder in modules folder, and the WSOD is solved but in my dblog there are many php errors and if i try to flush the cache i have another WSOD.

I try to run update.php and rebuild.php but nothing.

Any suggestion for disabling the module?
Thaks

Comments

VM’s picture

I'd put the module folder back and disable using drush.

http://drupal.stackexchange.com/questions/72927/manually-disable-a-module

slewazimuth’s picture

You don't disable modules any more. You uninstall them.

With a drupal 8 version of drush:

drush pmu MODULENAME

To rebuild the cache:

drush cr

marco.falconi’s picture

Before this problem with D8, i never used Drush.
I'm reading tutorials and trying to connect with SSH to mi server but i'm having a autentication problem..
However, if the solution is only to use Drush i can try all ways to connect to my server, or i install Drupal 7.
Thanks

VM’s picture

create a local environment in which drush can be used. If you've followed best practices you can roll back the database to the state it was in before you deployed the additional module.

D7 one could disable the module by setting the status to 0 in the database. D8 schema changed. I venture the status is stored in a blob in one of the tables.

escoles’s picture

Please clarify: Does that mean that a command line tool is now required to do Drupal 8 administration?

mmjvb’s picture

It does make it much more convenient to do so, including for troubleshooting and fixing anomalies. It definitely beats using a restore for those situations where a restore looses a lot of work or takes a long time.

So, while not a requirement, strongly advise you to explore avenues that allow cmdline access to your site. That is, when you value your site and can't live without it.

escoles’s picture

That's good to hear -- though I keep encountering modules that have no user interface other than Drush (e.g., almost all core importe/migration functionality seems to require using Drush), or which can only be properly installed using Composer. 

mmjvb’s picture

Don't know whether you can do everything they allow via cmdline but basic functionality should be possible to do.

Indeed several modules don't tell you how to use it without composer. That doesn't mean you can't, you may want to check the module Ludwig and see whether you can use that to install. Otherwise it is the same old way of figuring out how to get the required scripts available. Suggest to file a support request at the module for installation without composer. That is if you are still interested in such a poor service!

escoles’s picture

Thanks for the tip on Ludwig. Looks like it only works when the module author(s) elect to provide support for Ludwig, or module installers manually add support after the fact, which kind of defeats its purpose: the main reason to avoid using Composer is so you don't have to re-learn how to use it every time you want to manage your Drupal site, and Ludwig seems to require you to learn Composer arcana and then implement them for  every new Composer-requiring module you install.

The philosophical problem here is that D8 is moving in the direction of requiring a very steep DevOps learning curve to do anything much in a non-managed environment. D8 administration now effectively requires competence in bash, Composer, Drush and Drupal Console, as well as mastery of an entirely new paradigm. If I put it that way, it's a pretty hard sell in an IT environment that can't afford dedicated Drupal specialists or doesn't do everything via managed services, especially with any degree of staff turnover. The "simplified" solutions, like Kalabox, add several more layers of complexity to the work lives of people who may have months-long request backlogs.

'Such a poor service' is the Windows server on which I currently run several websites for my institution. Drush won't work for D8 on that server because D7 is also installed. It also won't work properly on my local dev machine, for similar reasons. 

(I've been building Drupal websites for a long time. Not being able to get Drush working on a server is not remotely unusual.)

mmjvb’s picture

Not wanting to learn cmdline is not accepted as a valid excuse and I agree with that. Ludwig provides a solution for those that can't use cmdline/composer. It used to be documented for using the module library. Now you need to provide it yourself or request it. That documentation should enable you to create it yourself. Consider that not worse than the way it was with using library.

Disagree with you about D8 moving in that direction. Drupal has always been like that. Unfortunately, the introduction of composer was done very badly. But, consider that just poor release/product management. Dries announced the desire to change that with D9. Doubt very much whether they will deliver. Have seen some bad decisions already that set them up for failure. Before D8 you had the choice how to manage your site. With D8, the eco-system (contrib modules) took that away.

There is no reason for drush not to work. You do need different versions for D8 as for D7. Building/managing sites and managing infrastructure are different disciplines.