MECU
commented
6 years ago Seems like the root cause was this in routes/web.php
Route::group(['prefix' => 'admin'], function () {
Voyager::routes();
});Closed MECU closed 6 years ago
MECU
commented
6 years ago Seems like the root cause was this in routes/web.php
Route::group(['prefix' => 'admin'], function () {
Voyager::routes();
});
fletch3555
commented
6 years ago Not sure why that isn't working for you. The Voyager Facade is registered by VoyagerServiceProvider, which is autoloaded correctly per the logs you posted.
fletch3555
commented
6 years ago @MECU, is this still an issue for you? I haven't seen any other similar complaints, so it's most likely something you've done as opposed to a bug in Voyager. If you're still having issues and have more information to provide, please do so and we'll reopen this. Thank you.
kitsunekyo
commented
6 years ago @fletch3555 i'd like to note that i have the exact same issue.
its working perfectly fine on homestead but when moving the package to the remote, I get
Class 'Voyager' not found in routes/web.php, which is where i add the Voyager routes.
homestead: php 5.6.32-l+ubuntu16.04
remote: php 5.6.30-0+deb8ul
rest is exactly the same. most recent composer version, flushed the vendor file and did a composer install again on the remote. but i always get the above error.
fletch3555
commented
6 years ago Do you have terminal access to that remote server? Can you confirm that the VoyagerServiceProvider is loaded?
kitsunekyo
commented
6 years ago thanks for replying so quickly. :) yes. i do have terminal access.
what i've done now is paste the vendor and bootstrap contents manually per scp on the client server. and now it works.
it might have something to do with the composer install.
is a php artisan voyager:install required for deploys? shouldnt be right? i already have it installed on my homestead, migrated the db manually
fletch3555
commented
6 years ago As long as you copy everything (including vendor and the database), No, voyager:install won't be needed. Having said that, you may run into issues if your local instance isn't a perfect match to the remote. If you install packages that expect php 7.1 because that's what you have locally, then push that to your remote with 7.0, it could very easily break. For this reason, I would recommend not pushing vendor and running composer install on the remote server. Just make sure composer.lock is pushed so you get the expected versions.
github-actions[bot]
commented
4 years ago 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.
Description:
During install into an existing Laravel 5.5, I got this error:
After the migration process succeeded and the last success file was
Seeding data into the databaseI tried to run
composer dumpautoloadwhich errored out when it tried to runphp artisan package:discoverwhich gave the same error.I then tried
php artisan config:clearwhich gave the same error.It seems the auto-register isn't working, though it did work successfully after the initial composer requre when the package:discover ran.
Steps To Reproduce:
Full copy paste of console