Voyager: issues under v0.11

[ctf0]

• Laravel Version: 5.4.12
• Voyager Version: 0.11
• PHP Version: 7.0.15
• Database Driver & Version: 5.7.17

Description:

1- opening media manager show error in console & it can make clicking the top right avatar un-responding.

2- expanding the side panel doesnt persist when navigating away.

3- nested menu with more than one sibling, you cant move the first item unless u started from bottom , to reproduce

• go to menu builder
• click on builder next to admin menu
• scroll to item named more and try to un-nest the first item "it wont work"
  
  
  
  • now try to un-nest the second item "it will work"
  
  

4- cant create timestamp columns ex.created_at & updated_at because it needs a default value.

5- enum field type is not-supported but its avail under posts > status, so how we can have the same functionality for other tables ?

[abdgad]

can you please explain issue 4.

[ctf0]

@abdgad
try to create a timestamp field, u will get an error that this column cant be created because it doesnt have a default value.

issue updated with ss.

[abdgad]

Issue 4 has been fixed.
Issue 5: Enum type exists so that Tables that already have an ENUM column don't cause a "Type doesn't exist" error. But you can't create an ENUM column. If you want to do that, you'll need to create a migration for it.
But I suggest you don't use ENUM in the first place. It's better to validate values in PHP. For example:
it's better to store these status values ['PUBLISHED', 'DRAFT', 'PENDING'] in the PHP source code. So people can know what values are allowed just by reading the src. And validate the value in PHP before inserting in the DB. In my opinion this is a better approach.
Read more at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/mysql-enums.html

[ctf0]

sweet, actually i don't use enum as mostly we have json field type now,
so we can use it from the bread, and in the view it will be a drop down which display them and the value saved in the table ex.posts > status will be equal to that.

and if the user wants more usability, then he can make a different table for status & create a relation with the model he wants.

[Frondor]

2 - It's supposed to be like that, because "sticky" behavior with cookie was messing with mobile UX. Probably a toggable new css class with a media query would make the job, but at the moment you only have to mouse over the sidebar to expand it (compacted because of big BREAD tables with lots of columns).

[ctf0]

@Frondor for mobile u have more than one solution, either with @media as u mentioned or with js to check touch devices.

also in the prev version, it was being saved in a cookie i think which was working most of the time as expected,
still for many users who will be using the dashboard, 90% will be viewing it on wide screen.

[Frondor]

The cookie was not the problem, but the UX.
And no, because every time you clicked a menu item, the next page loaded with the sidebar opened. That means you can't see more than a few pixels of the next page, so you had to close sidebar manually after each request. Also, there's no point to have a sticky sidebar feature on mobile devices. That's why the cookie method is now obsolete, and not a trend anymore tho.

still for many users who will be using the dashboard, 90% will be viewing it on wide screen.

That doesn't mean you have to provide a bad UX for the other 10%.
And I can assure you that if you set up voyager for another person (client), most of those non-developer persons shall log in mostly from mobile devices. So I wouldn't say 90% is an accurate value.

[github-actions[bot]]

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.