saving user_id as uuid doesnt work with the voyager.users.show route
following the tutorial https://the-control-group.github.io/voyager/docs/v0.10/#core-concepts-bread-relationships for trying to add a new relation bettwen a new model article and user through author_id give error
SQLSTATE[HY000]: General error: 1364 Field 'author_id' doesn't have a default value
Request URL:http://localhost:8000/admin/%7B%7B%20selected_file.path%20%7D%7D
Request Method:GET
Status Code:404 Not Found
Remote Address:127.0.0.1:8000
Unique to none doesnt get savedadding new field for the user table, then making it available through bread, become only available for read but not with add/edit/remove.
Yup, that's because user bread has its own view, overriding the default BREAD views.
This is most likely to change in the future #673 point 1
I think we should remove the default user BREAD view for v0.11. Thoughts?
any maybe clean up the view files more ex.
@marktopper atm voyager media manager relay on the default storage, i believe it would better if we added a new attr under the storage array so the user can decide which disk he wants to use & maybe add an option to use multiple disks.
also added new error
- commenting out
storage.subfolderor usingpublicdisk, make the user avatar disappear.
@ctf0: Wonderful idea.
'storage' => [
'disk' => 'local',
'subfolder' => 'public/'
],
I am more than open for pull requests on this one.
About the error you are getting when commenting out the storage.subfolder. It is because there are no defaults for that configuration. Might however be added to avoid this.
- get rid of the php code
- reformat the html to be more easier to reason with
We also indeed need some refactoring 馃憤
the issue with storage.subfolder that its being called in the view files for the user avatars, which should be resolved from the VoyagerMediaController, so all the media files can follow the same rules.
disk option is added.
and new error
- console error once we enter a folder with images in media manager view.
There are more in it then that in order to get it to work, the controllers needs to actually use the disk.
Can you open a separate issue for that since it's a big issue.
i actually solved everything, the latest commit is incomplete, i will add the rest now.
however i only have 2 issues
1- the console error
2- if we made a new disk like
'another' => [
'driver' => 'local',
'root' => storage_path('app/public/again'),
'visibility' => 'public',
],
the images doesnt show up

not sure why yet.
Ohh nice work @ctf0.
However there might be a need for another configuration to set the public path.
Since in this case it would probably need to be /storage/another/xxx.png instead of just /storage/xxx.png.
actually if we used something else like locale or public we can upload a file to the root folder and the image will be served through storage/xxx.png as usual 馃槩
However I still believe it would be a good idea to make it into a configuration, so that users can do it their prefered way.
'storage' => [
'disk' => 'local',
'folder' => 'public/',
'public' => 'storage/'
],
Files located in:
APP-ROOT/storage/app/public/xxx.png.
Files served in url as:http://site.com/storage/xxx.png.
Changing the folder just changes where the files are saved, and changing the public just changes where the system tries to serve it in the browser.
So this is actually just the same as you did in https://github.com/the-control-group/voyager/issues/696#issuecomment-278296786
that's why we have the symlink for the app/storage to do exactly that
Files located in: APP-ROOT/storage/app/public/xxx.png.
Files served in url as: http://site.com/storage/xxx.png.
also relaying solely on the file system disks is better than adding extra configs for voyage, because now the user can modify the data inside the single disk from anywhere without giving second thoughts & it makes maintainability easier and less learning curve through out the entire app.
Good point @ctf0 馃憤
I have added this to the milestone of v0.11.
Hopefully we can get those things done in time.
Closing as all of this might have been done by now.
@marktopper btw did those pass the test in ur build ?
- changing a field type from Unique to none doesnt get saved
- altering a field order doesnt get saved
also u have any release date for v0.11 ? maybe we can add a new tab to the website for announcements :1st_place_medal:
v0.11 is released :)
Also I will have to remake the entire test for the database since it have been changed in v0.11
awesome 馃懐
Update
This issue has been automatically locked since there has not been any recent activity after it was closed. If you have further questions please ask in our Slack group.
Most helpful comment
I think we should remove the default
userBREAD view forv0.11. Thoughts?