Show what failed when a site install fails.

Created on 3 December 2019, about 5 years ago
Updated 25 May 2023, over 1 year ago

When a site installation fails, there is very little shown to the user.

It was only last year that I added the Exception log message to the Drush logs... See 2260f5d50a6b2c4d859383b74265653dc4180fb4

However sometimes, that isn't enough information. If a PDOException happens, for example, it does not show the user what happened.

In this branch, I have added $e->getTraceAsString() to the error logs.

In response to people who say that this might be too much information for users, I would say, a failing site install should only ever be shown to someone that would need to know why it failed.

Most "aegir" users would be creating sites on stable platforms, so "install" tasks should always pass if the aegir site is configured properly.

✨ Feature request
Status

Fixed

Version

4.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States Jon Pugh Newburgh, NY

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

    • Jon Pugh β†’ committed cab8045b on 2953349-drush9-composer
      Issue #3098258: Send the trace to debug drush logs, not error. Do the...
    • Jon Pugh β†’ committed d53bddf9 on 2953349-drush9-composer
      Issue #3098258: Send the trace to debug drush logs, not error. Do the...
    • Jon Pugh β†’ committed dde7c0db on 2953349-drush9-composer
      Issue #3098258: Send the trace to debug drush logs, not error. Do the...
  • Status changed to Fixed over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States Jon Pugh Newburgh, NY

    Provision 4 now installs by execing drush site install.

  • πŸ‡΅πŸ‡±Poland memtkmcc

    Do we have any reference for the changes committed to Provision 4 and Provision 5 branches?

    I have looked in the patches for a few months back and both look like heavily experimental sandboxes without any issues referenced, so they almost look like private repository not intended to be used by the community?

    My questions arise since we plan to backport many accumulated patches from our BOA fork to bring the Provision 3 up to speed to fully support both PHP 8.1/8.2 and Drupal 9 and then we considered creating separate branch for the work being done on the Drupal 10 support, which is quite separate effort and can't be continued in the 3.x branch, while changes in 4.x and 5.x look pretty drastic without any documentation to figure out either backward compatibility or at least compatibility matrix -- like supported Drupal core, PHP and Drush versions.

    I have already noticed many patches there similar to our attempts to overcome the limits of 3.x branch, so making this work more transparent could certainly help in avoiding reinventing the wheel.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024