This is my command extension file:

<?php

namespace App\Console\Commands;
use Illuminate\Support\Facades\Mail;
use Illuminate\Support\Facades\Config;
use App\Mail\Recurr;

use Illuminate\Console\Command;

class SendEmails extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'email:send';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'send email';

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        parent::__construct();
    }

    /**
     * Execute the console command.
     *
     * @return mixed
     */
    public function handle()
    {            
        $this->info('Email: ' . Config::get('settings.contact_email_unpaid'));
    }
}

The idea is to send an email to the email configured.

Outputs Email: (null) for some reason..

If I do this, I don't get "hola1" only after the the second request I get proper value.

route::get('test',function(){
    Backpack\Settings\app\Models\Setting::where('key','MP_TOKEN')->update([
    'value'=>'hola1',
    ]);    
    echo Config::get('settings.MP_TOKEN');
});

wouldn't it be easier to have a

Config::set('key',value);

to store value properly?

If you try to composer require backpack/settings and you have MongoDB as default DB, you get this error

PHP Fatal error: Call to a member function prepare() on null in /Users/Dev/laravel/backpack/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 333

I think it's related to this: https://github.com/jenssegers/laravel-mongodb/issues/888

Hi, first want to thank you for these very useful packages but I get errors when working with a postgreSQL database. Here when I try to install the migration files for the settings package I got this error.

SQLSTATE[42601]: Syntax error: 7 ERREUR: syntax error near LIKE LINE 1: SHOW TABLES LIKE 'settings' ^ (SQL: SHOW TABLES LIKE 'settings')

But with MySQL everything is working fine.

Problem

On settings interface I click on the 'edit' button of the row I wanna edit. I add the text and click save, doesn't save.

This is what my DB looks like

If I add a value there, and then go to the user interface, I see that value on the list view, but not on the form view.

The update goal is allow user change the settings table name and route path. Even though normal case it will use default value. For my case, I use another settings package by spatie, and it conflict with backpack table name and route. Hence, I make this update, so allow other user to do some customisation in their setting.

1. I added config/settings.php, allow to change the default table name and route.
2. Change migration to migration stub so can generated by current time
3. vendor:publish added publish config file, if not publish will use default value.

First PR to backpack.

Bug report

Settings don't get loaded when running console apps. This is giving me problems with my Functional Testing.

I'd be interested to know why CLI is excluded, and whether it can be enabled?

What I did:

Setup as instructed, everything is working. I then tried to run FunctionalTests using PHPBrowser (via CodeCeption).

What I expected to happen:

For my settings to be available in all versions of the app.

What happened:

The settings don't get loaded because Backpack\Settings\SettingsServiceProvider::boot() specifically excludes loading them when running on the command line.

What I've already tried to fix it:

I've changed: if (!\App::runningInConsole() && count(Schema::getColumnListing('settings'))) { to if (count(Schema::getColumnListing('settings'))) {

(removing !\App::runningInConsole() &&) and it's now working as expected.

Backpack, Laravel, PHP, DB version:

Settings: 2.1.2 Backpack CRUD: 3.5.10 Laravel: 5.7.16 PHP: 7.2

Plain casting to an array does not convert nested arrays, which causes attributes parameter remained as stdClass by default.

This PR fixes that behavior, making attributes an actual array that doesn't break edit page.

Bug report

What I did:

Follow the steps to upgrade to CRUD 3.3

What I expected to happen:

Latest version of this package to install (2.0.24)

What happened:

Some old version was installed (2.0.8)

What I've already tried to fix it:

The dependency in composer.json is specified as "3.2.", it should be "3.2.|3.3.*" or something like "^3.2.0". It might solve some other issues, like #58 and #59.

Backpack, Laravel, PHP, DB version:

0.8, 5.5, 7.0, MariaDB 10.1

Bug report

Got an alert with DataTable warning: table_id=crudTable Ajax Error

What I did:

updated to Backpack 3.3

What I expected to happen:

Show my settings table

What happened:

What I've already tried to fix it:

Followed the link in the alert

Backpack, Laravel, PHP, DB version:

Backpack 3.3 Laravel 5.5.21 Php 7.1

Running the DB queries clashes with artisan cli when no database is available.

Meaning you cannot install/run artisan without setting up a database which makes deploying with systems like Envoyer, Codeship, Deploybot impossible.

WHY

In documentation it says: field (Backpack CRUD field configuration in JSON format. https://backpackforlaravel.com/docs/crud-fields#default-field-types)

As new to backpack, I lost an hour trying to figure it out Why my settings weren't working while I was setting field name to title or logo or whatever.

BEFORE - What was wrong? What was happening before this PR?

If somebody writes field name to something else than value, the update operation isn't working.

AFTER - What is happening after this PR?

We make sure always field name is set to value

How did you achieve that, in technical terms?

Always overwriting $field['name'] = 'value';

Is it a breaking change or non-breaking change?

Non-breaking change

How can we test the before & after?

??

Bug report

What I did:

What I expected to happen:

{"name":"value","label":"Job Progress and Timeline", "title":"Timeline", "type":"repeatable","fields": {{"name": "job","type": "text"},{"name": "createdate","type": "datetime"}}}

What happened:

ErrorException Trying to access array offset on value of type null

What I've already tried to fix it:

Backpack, Laravel, PHP, DB version:

PHP VERSION:

PHP 7.4.8 (cli) (built: Jul 9 2020 11:30:39) ( ZTS Visual C++ 2017 x64 ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies

LARAVEL VERSION:

v7.22.4@30e851a2b3a2af73fba0b7f4fa22b04260db98e7

BACKPACK VERSION:

4.1.15@6c751de946a9c8511dd32eb7bfa3ca6a568849f5

Settings syncronization with config/settings.php

Command settings:sync helps you keep production settings in sync with config/settings.php It doesn't override "value" field

Package now publishes config/settings.php

Backwards compatiblity

What could go wrong?

If user upgrades to this version, then doesn't have any config/settings.php file and runs php artisan settings:sync it'll use dummy settings in the package, removing user settings in their database.

This is not a likely scenario of a cautious programmer running any command in production, but it'll be a good security check to have. (I'm not sure how to check for config/settings.php in user code only)

The setting->description describes what the setting does, but we are never able to see the full description in the admin panel. We are able to see a truncated description in the index view of the settings i.e. "Email addresses separated by comma, to b[...]" but when we edit that setting, we don't see the description at all. The description provides useful information on what the setting does and should be shown on the edit page as a disabled field, similar to the setting->name. I made it a textarea instead of text in case the description is overly long.

Add support to SettingsServiceProvider.php to cache settings using the Laravel cache. This slightly improves our performance by storing all the settings in whichever cache we use. For high traffic sites this saves a lot of database access.

So, the current implementation of the SettingsServiceProvider::boot() method prevents caching of the settings, forcing 2 queries (one to detect the table, one to load settings) on the DB. It's more efficient for larger sites to cache all settings in memcached or redis, instead of querying the DB on every page hit.

I looked into extending the provider, but that might be a bit messy.

If you define a static method for it on the Setting model, then using a config value to point at the FQCN. We could then override the Setting class and extend it to allow caching.

Just some food for thought.