Allow developers to get the current crud entry based on route parameter

Bug report

What I did

Referenced $this->crud->entry->[property] within a CRUD controllers setupUpdateOperation() function when editing an existing entry.

What I expected to happen

A reference to $this->crud->entry to exist.

What happened

The reference to $this->crud->entry is null.

What I’ve already tried to fix it

Nothing.

Backpack, Laravel, PHP, DB version

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

PHP VERSION:

PHP 7.3.15-3+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Feb 23 2020 07:23:33) ( NTS ) Copyright © 1997-2018 The PHP Group Zend Engine v3.3.15, Copyright © 1998-2018 Zend Technologies with Xdebug v2.9.8, Copyright © 2002-2020, by Derick Rethans with Zend OPcache v7.3.15-3+ubuntu18.04.1+deb.sury.org+1, Copyright © 1999-2018, by Zend Technologies

LARAVEL VERSION:

v7.29.3@93f6d565a07045baa0e4b941ae1f733cd5984d65

BACKPACK VERSION:

4.1.27@bd1bab5dde08df20eebd730ca3a2992e1bf334f7

[tabacitu]

Boy do I have good news for you guys 😂🥳🎉🎈

The existing $this->crud->getCurrentEntry() does just that 🤯😂, and can be used inside setupUpdateOperation() just fine. So this sounds to me like a documentation problem, rather than a feature request right?

[pxpm]

That’s a valid and very good solution.

Technically if you know how to write stuff inside setupXXXOperation you know how to write it inside edit(). There are developers that prefer to ovewrite edit and create and add the fields there etc. you have $this->crud there too.

There is documentation on how to overwrite crud operation functions https://backpackforlaravel.com/docs/4.1/crud-operation-update#callbacks

Not sure if it’s something we should provide in core, or even how to do it properly in core if we do it.

We cannot use setupUpdateDefaults, The defaults for every operation, are loaded along with the CrudPanel, so even if you go to ListOperation, you will have the UpdateDefaults loaded. What you setup inside setupUpdateOperation is what is specific only for that operation, and we run it only when the specific operation is called. That said, if we do it inside defaults, sometimes we will have the entry, sometimes don’t.

Having an helper function like getEntryFromUrlAttribute($attribute) does not sound bad at all. That way we could tell devs if they want to get the entry inside the setupXXXOperation they could use it, even if we don’t do it as a default for the operation.

I am in for anything that helps developers (like myself) to speedup our development, we here (Backpack) just need to make sure that we don’t pollute (more) the CrudPanel with very niche cases.

I don’t think this is a niche case and it could be helpfull for anyone who needs it.

That said, even if we don’t make this into core I would probably just create an addon that adds this functionality to the crud (Crud is macroable, very easy to add anything without polluting the core)

@tabacitu @promatik what you think about this ?

I think yesterday somebody asked about the same in gitter. (changing fields based on the current editing entry).

Thanks for the suggestion @selected-pixel-jameson .

Wish you the best, Pedro