[Bug] CrudControllers with setFromDb() don't work with DBAL v3

Bug report

What I did

A simple CRUD that uses setFromDb(), for example Countries with:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class CreateCountriesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('countries', function (Blueprint $table) {
            $table->increments('id');
            $table->string('code', 2)->index();
            $table->string('name', 75);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('countries');
    }
}

What I expected to happen

The default CountryCrudController to work if you do nothing. So this to work:

<?php

namespace App\Http\Controllers\Admin;

use App\Http\Requests\CountryRequest as StoreRequest;
// VALIDATION: change the requests to match your own file names if you need form validation
use App\Http\Requests\CountryRequest as UpdateRequest;
use Backpack\CRUD\app\Http\Controllers\CrudController;

class CountryCrudController extends CrudController
{
    use \Backpack\CRUD\app\Http\Controllers\Operations\ListOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\CreateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\UpdateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\DeleteOperation;

    public function setup()
    {
        /*
        |--------------------------------------------------------------------------
        | BASIC CRUD INFORMATION
        |--------------------------------------------------------------------------
        */
        $this->crud->setModel(\App\Models\Country::class);
        $this->crud->setRoute('admin/country');
        $this->crud->setEntityNameStrings('country', 'countries');

        /*
        |--------------------------------------------------------------------------
        | BASIC CRUD INFORMATION
        |--------------------------------------------------------------------------
        */

        $this->crud->setFromDb();
    }

    protected function setupCreateOperation()
    {
        $this->crud->setValidation(StoreRequest::class);
    }

    protected function setupUpdateOperation()
    {
        $this->crud->setValidation(UpdateRequest::class);
    }
}

What happened

“Class 'Doctrine\DBAL\Driver\\PDOMySql\Driver' not found” error was thrown when going on the list page, so the ListOperation is unusable. Click here for stack trace.

Screenshot below:

What I’ve already tried to fix it

Gone through the change history for AutoSet.php but it doesn’t look like the last few changes are the one that pushed it over the edge…

I used a panel that uses sstFromDb() about ~4 days ago, it was working, then I ran a composer update, and… now it’s not working. The problem is - we’re just asking everyone to run a composer update for security issues this week. And the version everyone’s going to get… will break CRUDs that use setFromDb().

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

### PHP VERSION:
PHP 8.0.2 (cli) (built: Feb  4 2021 18:57:55) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.2, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.2, Copyright (c), by Zend Technologies

### LARAVEL VERSION:
v7.30.4@9dd38140dc2924daa1a020a3d7a45f9ceff03df3

### BACKPACK VERSION:
4.1.37@f829c37501d2f015bc5a4c93ef6dbc4533354ba8

[tabacitu]

I cannot… so indeed, it looks like it’s not a Backpack problem, it’s a Laravel problem. Basically…

THE PROBLEM: Laravel 7 does not work with DBAL v3, despite the fact that it’s installable.

THE SOLUTIONS:

A) Keep Laravel 7 but downgrade DBAL to version 2, by doing composer require doctrine/dbal:2.* as instructed here. This is a one-second solution, but it will add the dbal depenendecy to your project’s composer.json. Remember to remove that line when you upgrade to Laravel 8 - you don’t actually need it.

(or)

B) Upgrade to Laravel 8. That’ll fix it, Laravel 8 properly supports DBAL v3.

---

Unfortunately:

• neither we nor Laravel can retract support, since there are multiple tags supporting it;
• starting Oct 2020, Laravel 7 is no longer receiving bug fixes, so I’m pretty sure this problem will NOT get fixed in Laravel;
• I expect everybody on L7 who runs composer update to run into this problem… and we’ve just asked a bunch of people to run composer update; so I expect a lot of people to run into this issue…

I’m not very happy with the solutions, but honestly… I don’t see what we can do about it, other than document the solutions (above) and point people here. Open to ideas!

I’ll close the issue. Please leave a reaction or comment if you’ve run into this problem… so that we at least know how many people got f*$#ed by this L7 issue.

Cheers!

[pxpm]

I will change my bet to be L7 the problem here.

Can you reproduce the issue in the same environment as I am ? L8 @tabacitu ?