Programmatically add BREAD

[packytagliaferro]

• Laravel Version: 5.4
• Voyager Version: Current
• PHP Version: 7
• Database Driver & Version: MySQL

Description:

Is there a way to set up Voyager programmatically? I always prefer to set up the admin programmatically (like Backpack) for a few 2 main reasons:

• I dont want an Admin to be able to change anything to the db, just do want they need on the tables I allow them to
• I run Forge and constantly update so db migrations hooked into my GIT are to valuable to get rid of

Any docs or options would be great because this is so much nicer looking/feeling than other admins, but I need those options to consider not just making a custom one.

[abdgad]

Can you please further explain what you mean by setting up Voyager programmatically? And what is the issue with Voyager and your migrations?

[packytagliaferro]

Yes, basically right now I use Backpack for Laravel and pay per site (also willing to pay for Voyager so you know since I like yours a lot more but maybe lacking some features) but their system I add everything I need to operate the backend via the actual code base.

Example: if mid way through a project I need to add a new table, say products (which happens a lot) all I have to do is:

• Create a new migration for the table, model and controller
• In the Model I set my relation as usual
• In the Controller I add some code so Backpack will be responsible for CRUD on this table (https://laravel-backpack.readme.io/docs/crud-example)
• Add the new route in my routes file and a link in their sidebar view
• Then I commit to my master branch in git which runs the migrations on live database and forge pulls in the new code to use on the server
• Done! No need to edit the live admin since everything is merged with code.

Although this is not as easy as your system there are features I think that most people developing more than a website wont want to give up like

• Using migrations (for version control and Push To Deploy to server)
• Controlling it in the code (for version control and Push To Deploy to server)
• Also both of these let me control what the admin can use (I dont want someone adding a db table on live server without me knowing about it, specially with version control)

I didnt see this workflow option but might have missed it.

[packytagliaferro]

Any more information on this?

[Widcket]

I solved it by adding seeds:

MenuItemsTableSeeder.php -> Create new menu entries here DataTypesTableSeeder.php -> Register BREAD for new tables here DataRowsTableSeeder.php -> Configure the details for every field in said tables

By default Voyager seeds will only run on installation (php artisan voyager:install). You probably don't want to reinstall Voyager ever time you want to seed the DB, so make sure to add a reference to every seed file in DatabaseSeeder.php. Then you can seed the DB by running php artisan db:seed.

[packytagliaferro]

@Widcket I will take a look at this. I have never really worked with seeding anything. I am assuming I can add all these files in my application root and set up forge to run them when I push so I dont have to edit the actual package in any way.

[Widcket]

@packytagliaferro You don't have to modify Voyager itself, just the seeds that Voyager generates for you when you install it. These are in project root/database/seeds.

[lancepioch]

Labels: bugfix, invalid

Close (Solution found)

[joshlewis]

@Widcket It's unclear to me if what you're suggesting is what @packytagliaferro needed, so I recommend that @lancepioch not close this yet. If I understand what @packytagliaferro is saying, it's a major (and in my opinion, important) feature request.

Imagine a team of developers all developing a web application together, and Voyager is one part of that web application.

One of the developers adds a column to a table in the database, and then adds BREAD to that table. He wants to share his work with his teammates, so he goes to check it into git, which of course they're using because every software team uses git or some kind of version control system. I mean, we're having this discussion on GitHub, are we not?

He notices there's nothing to check into git, because all the changes he just made were done only in the data within the database. He wants a way to easily export / represent his modifications from the database into the file system, and have those changes respected by the Voyager install of anyone who has those files in place. Yes, he'll write a Laravel migration to add the column, but what about the Voyager part, with his BREAD configuration? That can't be easily represented in the file system and checked into git.

This is by far the biggest problem my team is currently having to adopting and increasing our use of Voyager in many of our web applications. It's absolutely critical that this feature is added ASAP in order to have Voyager actually compete and win against other systems in its class.

[packytagliaferro]

I agree with @joshlewis @lancepioch . As of now I can not switch to Voyager from Laravel Backpack (which I pay for and will pay for Voyager as well). Being able to create the admin via controllers (like Backpack) is essential for teams and version control. Even a solo project I use Forge so I can create the whole admin in my Admin controllers, commit it, push it to Git and boom ... my production, dev and staging sites all now share the same admin. With Voyager now I would have to go into every environment to change, add, update the BREAD.

[vistiyos]

I would propose to add export functionality that create a JSON file for every table that you can import in all your environments. I think this will work better that make those changes again and again

[fletch3555]

BREAD is configured as rows within the data_types and data_rows tables. You're free to export/import those tables yourself.

We're looking into the feasibility of having a migration/seed generator, which may provide this functionality automatically, but it's still a ways off (unless someone from the community builds it and submits a PR). If anyone would like to take a shot at this, ping me on slack, and I would be glad to work through the requirements with you.

I recommend against the JSON export, in favor of the migration/seeder functionality.

[tenebrousedge]

I've been exporting the voyager tables with orangehill/iseed. This also allows the generation of seeds for tables other than the ones voyager uses. To my mind, this method would fulfill any need for data export functionality.

[joshlewis]

Why are we closing this if we agree it's a valid feature request?

[handiwijoyo]

Sorry I mistaken thought the issue is solved by using package like https://github.com/orangehill/iseed without run into the detail.

I will reopen this then and will accept suggestion on how we handle bread changes.

[joshuadegier]

Seems like this is exactly what I just wrote down at the Slack channel. I'm also missing the part where you're able to easily share the BREAD configurations of the tables. If I understand @fletch3555 correctly the only thing missing in our shared repository is the data from data_types and data_rows?

Having to use iseed feels wrong, tho it will work for the time being. But I don't want to seed in a production application, which I have to if I add a new BREAD after launch. My best guess would be something similar to the migrations in a default Laravel installation.

(1) Create a .json file representing the configuration for a single table (2) Create a new command voyager:refresh-bread-config to refresh the data in the database based on the json files (3) When you edit an existing bread, the configuration file is being overwritten

This way, if I was to change the BREAD for Posts and another developer would as well, we'd have a conflict over what version to use. And this is the kind of behaviour we're after, right?

A pitfall in this setup is what would happen if you pull the latest version, modifiy the BREAD config for a table and forget to voyager:refresh-bread-config. Maybe adding a file that monitors the last refresh against the filemtime of the most recent editted config and the Voyager admin can display a warning or even totally block BREAD functionality until the configuration is either refreshed or you explicitly agree that you wan't to overwrite any new changes.

Besides the configuration, also having a migration for the tables you make would be useful. I've used https://github.com/Xethron/migrations-generator to create a migration for a table generated from within Voyager to have it available in version control. I guess there are ways to have this automated as well when creating or editing a database table from within Voyager.

[joshuadegier]

I've started working out an idea, roughly what I'm going to try to do is:

• (1) Change the BreadAdded and BreadEditted events to receive $request->all() besides the $dataType and $data
• (2) Use the BreadChanged event to dispatch a SaveBreadConfigurationToFilesystem listener
• (3) The json_encode($event) (I guess I also need serialization here) is then saved to {$event->dataType->slug}.json in a new directory (database/bread/) which is published when installing voyager

The above is working so far. Next steps are to create a new refresh method on the VoyagerDatabaseController which deletes the current data (safely) and then adds the data from within the configuration files. This is all wrapped within Database Transactions to prevent false data when something goes wrong along the process.

There still are a few things I need to be aware of:

• I need a way to compare the filemtime of the newest saved configuration to the updated_at timestamp of the last editted record in data_types. This can be used to determine wether a user needs to refresh the BREAD configurations to stay in sync with his/her team. Also, I have to take timezones into account I guess.

• When a table slug is renamed $event->dataType->slug changes and thus there is a possibility that there are duplicate files. I'm not sure how to catch this yet, maybe using the $event->dataType->id field as unique identification and adding a descriptive string to the end of the filename, e.g. type_1_posts.json.

• When refreshing the configuration I need to use the delete method of VoyagerDatabaseController (also need to use storeBread and updateBread of that same controller), some of the logic of these methods need to be extracted to a function to be used in the refreshBread method.

• In order to prevent updates of the BREAD in production, a new setting must be added, disable_bread_configuration_in_production. This disables the ability to EAD the BREAD configurations in production.

• A new commando voyager:refresh-bread-config can be run from within the console in production in order to have the latest configuration loaded.

• A separate, but in similar, problem for version control exists for the Admin menu.

[amirmasoud]

Is there any firm solution? It's more like Drupal way, any way to version control this configs properly? Personally I prefer some sort of config file.

[b4dnewz]

Just for the records or anyone like me which had this error: "This action is unauthorized." after creating custom BREAD programmatically.

I've followed the message from @Widcket which point to the good direction but I encountered a permission error and I has to modify also: PermissionTableSeeder so the full list should be:

• MenuItemsTableSeeder.php -> Create new menu entries here
• DataTypesTableSeeder.php -> Register BREAD for new tables here
• DataRowsTableSeeder.php -> Configure the details for every field in said tables
• PermissionTableSeeder.php -> Add the BREAD permissions to table

[Ulimn]

Any progress on this?

[DrudgeRajen]

Check this. A package on top of voyager which listen to BREAD events and generates the seeders for BREAD.

[subooom]

@b4dnewz Hey I did all of them but the problem now is it says route not defined for say voyager.slug.index , voyager.slug.destroy etc. How do you define the routes for custom tables? I thought an entry on the data_types table along with on the data_rows table would suffice.

[MrCrayon]

@subooom Yes, routes are generated for all data_types defined in db but you need to follow Laravel conventions or set the table name in your model. If you have more questions please join Voyager Slack channel, you can find the link in the readme.

[subooom]

I have followed the Laravel convention which is basically plural names as table names. I'll try setting the table names in the model and let you know.

[fletch3555]

This issue is incredibly old at this point. A couple workarounds have already been posted and v2 will have this functionality. Closing.

As mentioned by @MrCrayon, further discussions can be had in slack.

[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.