Proposal for the directory feature

[Wulfheart]

Hey Adam,

some time ago we had a discussion on Twitter/X regarding the directory feature for Curator. Unfortunately the search is currently broken and I am unable to link to it.
However, you mentioned that it was quite complicated an I wanted to pitch you my idea that might simplify it a bit.

Every field has a base directory from which all the capabilities are derived.
There are several capabilities every field can have:

• create directory
• delete directory
• rename directory
• navigate into subdirectories of base directory
• navigate into parent directories of base directory

The new configuration options on the field would look like this:

CuratorPicker::make(string $fieldName)
// specifies the base directory
->baseDirectory(string $baseDirectory)
// where Curator opens, useful if e.g. you want to open it where you last picked up
// and persisted it somewhere
->defaultDirectory(string $directory) 
->canCreateDirectory(bool $bool)
->canDeleteDirectory(bool $bool)
->canRenameDirectory(bool $bool)
->canNavigateIntoSubdirectories(bool $bool)
->canNavigateIntoParentDirectories(bool $bool) 

Furthermore there would be default if one of these has not been set which can be changed in the config.

@awcodes does this look good to you? Would you principally be open to merge a PR with this functionality?

[awcodes]

I'm always open to PRs. Biggest caveat here is how all of it is passed to the panel, because all of the functionality would happen at the panel level.

In my mind though the picker shouldn't care about any of it. The picker just opens the modal. And directories are managed in the panel Lw component.

There really is a lot to the functionality when it comes to moving media between directories etc.

[awcodes]

Like what happens if a picker defines a directory and limits its results to said directory, but then the media item gets moved to another directory. It would no longer be available to the picker. But would still be part of that picker field's data.

[Wulfheart]

Hm. That is an interesting question. I would argue that it is a matter of definition. If it gets moved while it is still shown in the browser we can't do anything about it, just like what happens when DB data gets updated by another user. So it shouldn't be that big of a problem.

[awcodes]

Maybe.

Still don't like CuratorPicker doing this. I still think it should be on the CuratorPanel.

[Wulfheart]

I am not sure about that.
My use case would be a CMS-like application. I want to be able to limit field A to a specific directory and field B to another directory. How could I achieve this using the CuratorPanel?

[awcodes]

CuratorPicker already has a ->limitToDirectory() method.

I just think that anything dealing with creating / deleting / moving directories needs to be on the panel and not determined by the picker. The Picker should only care about what records it is saving to the db for the record.

[awcodes]

But, yea, this can get very complicated very quickly. 🤣