What about translatable fields? In my own project I use https://github.com/spatie/laravel-translatable and create new field with tabs for each language.

Hi,

I wanna use the InlineCreate operation and do some things on create and update methods.

When I have the request as argument : public function store(StoreRequest $request){ ... } I have this error : Too few arguments to function App\\Http\\Controllers\\Admin\\OrderItemCrudController::store(), 0 passed

And when I remove request from argument, and use this in the method : $this->crud->request->request->get('...') I have this error : Cannot access protected property Backpack\\CRUD\\app\\Library\\CrudPanel\\CrudPanel::$request

Is there a way to get the request with the InlineCreate operation ?

Thanks for your help,

summary Enables users to add an array of items, with multiple columns if they need, with re-ordering and deleting.

preview

usage

database column type should be either json or text

$this->crud->addField([
            'name' => 'products',
            'label' => 'Product',
            'type' => 'array',
            'properties' => [
                'name' => 'Item Name',
                'desc' => 'Description',
                'price' => 'Price'
            ],
            'max' => 5,
            'min' => 0
        ]);

$this->crud->setColumnDetails('products', [
            'type' => 'array',
            'display_field' => 'name',
            'label' => 'Products',
            'list' => true
        ]);

Hey there!

I have to say, this was a wonderfully pleasant surprise to find. I've been looking for a usable Admin package for laravel for a few days and boom! Yours showed up. Wonderful work!

I wanted to check in with you before I started diving in to deep: the model tables currently sort based on the entries currently in the view, but is there any wiring in place to order based on all the models in the database? If not, I'll dive in and see what I can contribute!

Imagine I want to add a task:

Priorität and Status are selects with related models. Now I would like to add a new item for Priorität on the fly without leaving this page.

A nice solution would be a modal where I could add an item and after saving and closing the select list would be automatically updated.

Does anyone already have implemented such a functionality?

Hello again guys! \o

Here we are around relationships once again :D

Short story short this can be seen as #3272 and #3250 merge.

Let's break this down.

Relationships: BelongsTo

The foreign key is stored in the current model table. BelongsTo display as a select with the option to add new items via InlineCreate

public function icon()
    {
        return $this->belongsTo(\App\Models\Icon::class, 'icon_id');
    }

$this->crud->addField(['name' => 'icon']);

Relationships: HasOne / MorphOne

Both are very similar, the difference beeing the database structure. The key is in the foreign table as oposed to BelongsTo. There is no specific field for this relation, it displays the user desired field type. Supports BelongsTo relations in the foreign model.

In backpack the usability of both is the same:

// HasOne

public function address()
    {
        return $this->hasOne(\App\Models\Address::class);
    }

$this->crud->addFields([
     [
           'name'    => 'address.street',
           'label'   => 'Street column in address table',
     ],
     [
           'name'    => 'address.icon',
           'label'   => 'Icon is a BelongsTo relation in address model',
     ],
]);

// MorphOne

public function comment()
    {
        return $this->morphOne(\App\Models\Comment::class, 'commentable');
    }

$this->crud->addField([
     [
           'name'    => 'comment.text',
           'type' => 'ckeditor',
           'label'   => 'text column in comments table',
     ],
]);

Relationships: HasMany / MorphMany

They are similar but at the same time kind of different. The key is stored in the foreign model table.

There are two ways of dealing with this relationship, either using a select to select from a prefefined list of items, or creating the items along with the model.

Let's first break down the HasMany.

public function postalboxes()
    {
        return $this->hasMany(\App\Models\PostalBox::class);
    }

Developer can setup this relation to be a select:

[
                'name'    => 'postalboxer',
                'label'   => 'HasMany - selectable',
                // 'force_delete' => true, //optional - explained bellow
            ], 

When using this approach backpack does not impose a way of dealing with the data. The default behavior is:

• check if developer provided a fallback_id, this key can be used in case database column is NOT nullable but developer don't want to delete the entry (the selectable option) from database.
• check if the column is nullable, if it is, set the value of the connected key to null.
• if no fallback is provided, and null cannot be used in database we just delete it.

The optional force_delete => true say backpack that even if column is nullable in database, we should delete the entry when removed from selections.

This was the behaviour intended in https://github.com/Laravel-Backpack/CRUD/pull/1453 I think.

This select approach is available also in MorphMany but does not make much sense to use it there as the morph table requires morphable_type and morphable_id.

For MorphMany and the HasMany creatables it's recommended to use the new repeatable field to create the related items.

// MorphMany

public function stars()
    {
        return $this->morphMany(\App\Models\Star::class, 'starable');
    }

$this->crud->addField([
    [
        'name'    => 'stars',
        'label'   => 'MorphMany - Starts',
        'pivotFields' => [
            [
                'name' => 'title',
                'type' => 'text',
            ]
        ],
    ]
]); 

Behind the scenes this field would be converted to a repeatable field that would allow to create the amount of desired stars. Same for HasMany :

 public function postalboxes()
    {
        return $this->hasMany(\App\Models\PostalBox::class);
    }

$this->crud->addField([
    [
        'name'    => 'postalboxes',
        'label'   => 'HasMany - creatable',
        'pivotFields' => [
            [
                'name' => 'postal_name',
                'type' => 'text',
            ]
        ],  
    ]
]);  

Relationships: BelongsToMany / MorphToMany

They are both very simillar so is the usability in backpack.

Both provide both interfaces select and repeatable. The select best for when we just want to connect two entities. The repeatable when we want to deal with pivot data.

REPEATABLE

IMPORTANT: to work with pivot tables you need to explicitly tell what pivot fields you are about to edit using ->withPivot() from Laravel.

public function recommends()
    {
        return $this->morphToMany(\App\Models\Recommend::class, 'recommendable')->withPivot('text');
    }
public function dummyproducts()
    {
        return $this->belongsToMany(\App\Models\Product::class, 'monster_productdummy')->withPivot('notes');
    }

$this->crud->addField([
    [
        'name'    => 'recommends',
        'label'   => 'MorphToMany Recommends - with pivot fields',
        'pivotFields' => [
           [
            'name' => 'text',
            'type' => 'text',
           ]
        ],
    ],
]);

$this->crud->addField([
    [
        'name'    => 'dummyproducts',
        'label'   => 'BelongsToMany - with aditional pivot fields',
        'pivot_wrapper' => [ //optional explained below
            'class' => 'form-group col-md-6',
        ],
        'pivotFields' => [
           [
            'name' => 'notes',
            'type' => 'text',
            'wrapper' => [
                'class' => 'form-group col-md-6',
            ]
           ]
        ],
    ],
]);

The interface for this field is common for both, a Selectable Entity to relate and the optional pivot fields to add along.

pivot_wrapper configures the wrapper for the select of related entry.

You can also pass along more options like ajax and data_url etc, they will be streamlined for your "Select Related". Basically the options you could pass to any relationship field, but pivot_wrapper needed to be overwritten because the "main" repeatable field also has a wrapper.

SELECT

To work with this relations as regular select you don't need to provide the withPivot. You will also be able to create new "relatable entities" using inline create.

public function products()
    {
        return $this->belongsToMany(\App\Models\Product::class, 'monster_product');
    }

public function bills()
    {
        return $this->morphToMany(\App\Models\Bill::class, 'billable');
    }

$this->crud->addField([
    [
        'name'    => 'bills',
        'label'   => 'MorphToMany Bills - selectable',
    ],
]); 

I'v created https://github.com/Laravel-Backpack/demo/pull/218 in demo that has all this relationships setup, tables etc.

Don't forget migrate & seed.

This is the most upvoted feature in our feature poll. So it's the first one we can tackle, now that we have v5 ready for launch.

Let's do this!!! 💪

The Problem

I've studied all previous PRs for this:

• 2016 - https://github.com/Laravel-Backpack/CRUD/pull/165
• 2018 - https://github.com/Laravel-Backpack/CRUD/pull/1257
• 2020 - https://github.com/Laravel-Backpack/CRUD/pull/3420
• 2021 - https://github.com/Laravel-Backpack/CRUD/pull/3753

As I said in https://github.com/Laravel-Backpack/addons/issues/11 ... this is a tricky problem to solve... because the developer needs can be so very different. In various places, people ask:

• for the "source" to be a select, others radio, checkbox, checklist, select2_from_array, etc;
• for the "source" to be multiple fields, not just one;
• for the "action" to be "hiding";
• for the "action" to be "showing";
• for the "action" to be "hiding and disabling";
• for the "action" to be "calculating the value";

I'm ashamed we haven't done anything to solve this until now. Literal shame. But... the reason we haven't merged any of those... is that I didn't see way for us to cover what most devs need, most of the time. We would only be covering a particular use case, which would most certainly have meant we would be adding features and niche use cases to it for years, as people report them. And that simply wasn't a good idea, to take on such a big maintenance burden... when it's not that difficult to do it in JS, for the people who needed it. You could do it in create.js and update.js and you have a solution, for your project alone, with maximum customizability. That's why I've been suggesting "creating an addon for it" to devs who have made PRs for this... because they were niche solutions, and for sure somebody would have used it... but not everybody would have been happy with it.

I didn't see how we can build this feature/field/whatever so that most people will be happy with it. But now... I think I do. And it's sort of what @pxpm suggested here... but without the AJAX calls, which I think are unproductive and bound to fail.

And thanks to the open-core split... we can start adding more and more feature, right into backpack/pro.

The Solution

What if... instead of wanting to define the JS behavior in PHP... we accept we have to write a little bit of JS for this? And have Backpack make that bit of JS so easy to write, it's a pleasure? In Backpack v5, thanks to the script widget, we can do:

Widget::add()->type('script')->content(asset('/path/to/js/file.js'));

So what if...

Step 1. We make it even easier, by providing a convenience method on CRUD, that also allows for inline content. Something like:

CRUD::addJavascript('/path/to/js/file.js');

// or even

CRUD::addJavascript("alert('what you want to be done here')");

Step 2. We make it dead-simple to write ALL of the combinations above, by providing a selector and a few actions on the crud javascript object (it's already onpage, usually used for working with DataTables). So that what JS you actually write looks like this:

// option 1 - probably needs jQuery
crud.field('agree').on("change", function() {
    crud.field('price').show();
});
crud.field('agree').onChange(function() {
    crud.field('price').show();
});

// option 2 - maybe doesn't need jQuery
crud.field('agree').addEventListener("change", function() {
    crud.field('price').show();
});

// of course, you should be able to do a few other stuff with your `fields`, but the minimum would be:
crud.field('price').show();
crud.field('price').hide();
crud.field('price').disable();
crud.field('price').enable();
crud.field('price').value(); // aka .setValue(), aka .val()

I believe this would solve all cases people have already expressed... but also fix the cases people haven't expressed yet. Which I'm sure will come up, in real apps, right after we introduce a feature with limited customizability. But by moving this logic to JS... it opens up the possibility for you to do... anything you want. It's JS, and you have complete control.

Thoughts, anyone? Am I missing something? Or is this a solution we could all get behind? I'm eager to prototype this, to see if we can launch it with Backpack v5 this week 🎉 I have a feeling it's either a lot simpler than I expect... or a lot more difficult 😅

Can't tell if this idea is incredibly good... or incredibly stupid 😅 Let me know.

Bug report

What I did:

I created a FormRequest like I would normally do with Laravel...via art make:request StoreFooRequest. I updated the CRUD controller's store() method to use this request.

What I expected to happen:

Once the validation on the form request passed, then the new data would be stored.

What happened:

Type error: Argument 1 passed to Backpack\CRUD\app\Http\Controllers\CrudController::storeCrud() must be an instance of Backpack\CRUD\app\Http\Requests\CrudRequest or null, instance of App\Http\Requests\StoreFooRequest given

What I've already tried to fix it:

Not much, other than to take a quick look at Backpack\CRUD\app\Http\Requests\CrudRequest to see what was so special about it.

Backpack, Laravel, PHP, DB version:

More or less the latest, across the board.

Extra:

Perhaps I've missed something, but Backpack\CRUD\app\Http\Requests\CrudRequest appears to add no value. It seems that Backpack\CRUD\app\Http\Controllers\CrudController::storeCrud() should require Illuminate\Foundation\Http\FormRequest (or some sufficient contract/interface).

I'd be happy to put together a quick PR, but I wanted to find out if this would be a waste of time before I did it and to perhaps figure out why this might not be a good idea.

refs: #3218

Problem: When using include_all_form_fields with ajax fields the repeatable values in the form would not be sent with the request because they only got their value parsed when the submit button in the main form is pressed.

Solution: Create an event handler in repeatable fields that we can fire when doing the ajax request and parse the values of the repeatable instances to be sent along with the main form fields.

Bug report

I believe export buttons feature was forgotten with this update, as far as I understood, the div id='datatable_button_stack' is not in the list.blade.php.

What I did:

Added the export function $this->crud->enableExportButtons();.

What I've already tried to fix it:

I added the div next to the search stack div in the list.blade.php file, and it started to work.

<div class="col-xs-6">
    <div id="datatable_button_stack" class="pull-right"></div>
    <div id="datatable_search_stack" class="pull-right"></div>
</div>

This causes a kind of design flaw, because the buttons there are not very beautiful :)

Backpack, Laravel, PHP, DB version:

CRUD 3.5

controller

 $this->crud->addField([   // Upload
    'name' => 'image',
    'label' => 'Image',
    'type' => 'upload',
    'upload' => true,
    'disk' => 'uploads' // if you store files in the /public folder, please ommit this; if you store them in /storage or S3, please specify it;
]);

model

public function setImageAttribute($value)
    {
        $attribute_name = "image";
        $disk = "public";
        $destination_path = "/uploads";       
        $this->uploadFileToDisk($value, $attribute_name, $disk, $destination_path);
    }

config/filesystem.php

'uploads' => [
                    'driver' => 'local',
                    'root' => public_path().'/uploads',
                    // 'url' => '/photos/',
                    // 'visibility' => 'public',
                ],

WHY

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

If the file is stored in a private S3 or private S3 compatible bucket, the image fetching will fail. This PR was modify based on https://github.com/Laravel-Backpack/CRUD/pull/4466

AFTER - What is happening after this PR?

If 'temporary' key is true, use temporaryUrl() instead of url() and support param "expire" to set expiration time in minutes.

HOW

How did you achieve that, in technical terms?

This PR is thanks to @ziming based on this PR https://github.com/Laravel-Backpack/CRUD/pull/4466

Is it a breaking change?

No

How can we test the before & after?

Create a private S3 bucket, dump some files there and try.

WHY

Because we had 4000+ CSS and JS files in CRUD, so the v6 to main diff was unusable. Now, we point v6 to main-without-assets. That way, we can actually tell what the differences are.

When everything's ready to merge, we can merge everything into main:

• this branch (main-without-assets)
• v6
• any other feature branches that hadn't been merged to v6

Hello,

We're using Backpack on a project but have noticed that the purple you use is not accessible on a white background (nor is the blue alternative).

They both fail to meet WCAG AA colour contrast ratio. Whilst we're aware that we can create overrides for these, it would be nice for the wider world (and especially those with any visual impairments) to have this available by default.

Alternatively, a simple-to-implement "primary colour" configuration variable would be great, so that we could change this to something accessible without needing to go through the full custom config route.

Thank you.

Pasted image from https://webaim.org/resources/contrastchecker/:

Bug report

Hi,

I tried to save files in the pivot table, but when I saved, I got this output in the database: [{}]. My setDiplomaDocumentAttribute() function does not seem to be used.

What I did

CRUD :

 'subfields' => [ 
                            [
                                'name'      => 'diploma_document',
                                'label'     => 'Fichiers',
                                'type'      => 'upload_multiple',
                                'upload'    => true,
                                'wrapper' => [
                                    'class' => 'form-group col-md-9',
                                ],
                            ],
                        ],

Model:

public function diplomas()
    {
        return $this->belongsToMany(Diploma::class, 'user_diploma','user_id','diploma_id')->withPivot('diploma_document');
    }   
    
public function setDiplomaDocumentAttribute($value)
    {
        $attribute_name = "diploma_document";
        $disk = "local";
        $destination_path = "diploma_documents";

        $this->uploadMultipleDiplomasToDisk($value, $attribute_name, $disk, $destination_path);
    }

What I expected to happen

Files are saved

What happened

Files is not saved and the value [{}] appears in the database.

What I've already tried to fix it

I tried to call the function in CRUD but I get a [null] value in the database.

'subfields' => [ 
                            [
                                'name'      => 'diploma_document',
                                'label'     => 'Fichiers',
                                'type'      => 'upload_multiple',
                                'upload'    => true,
                                'function'  => function($entry){
                                    $entry->setDiplomaDocumentAttribute();
                                },
                                'wrapper' => [
                                    'class' => 'form-group col-md-9',
                                ],
                            ],
                        ],

Backpack, Laravel, PHP, DB version

PHP VERSION:

PHP 8.1.3 (cli) (built: Feb 16 2022 08:20:53) (NTS Visual C++ 2019 x64) Copyright (c) The PHP Group Zend Engine v4.1.3, Copyright (c) Zend Technologies

LARAVEL VERSION:

v9.45.1@faeb20d3fc61b69790068161ab42bcf2d5faccbc

BACKPACK VERSION:

5.4.11@ffbadcdb6478822646600b2cd763490caa927155

Here's what Pedro and I though about... we might already support spatie/media-library... just know know it or have it document it. The only thing you need to actually use that library is change the way you get and set your files on your model.

Well... you can easily do that in Backpack v5... using model events... https://backpackforlaravel.com/docs/5.x/release-notes#define-model-events-directly-on-fields

Pedro, please check if we already support this. If we do... woohoo 🎉 Let's document / make it easier / smth.