PLATFORM
  • Tails

    Create websites with TailwindCSS

  • Blocks

    Design blocks for your website

  • Wave

    Start building the next great SAAS

  • Pines

    Alpine & Tailwind UI Library

  • Auth

    Plug'n Play Authentication for Laravel

  • Designer comingsoon

    Create website designs with AI

  • DevBlog comingsoon

    Blog platform for developers

  • Static

    Build a simple static website

  • SaaS Adventure

    21-day program to build a SAAS

Question By
Unsolved

Laravel Valet staging environment issue

travlongmore

Jun 2nd, 2023 10:02 AM

I've got my wave laravel application live and working nicely on DigitalOcean but when I try and do some work on my local environment I get: Disk [digitalocean] does not have a configured driver.

I'm not sure of the best way to get this setup to enable me to test changes locally and then commit the changes to Github so DigitalOcean can push it to the live site. Does anyone have any advice on how to do this the right way?

bobbyiliev

Jun 2nd, 2023 10:14 AM

Hey!

What I could suggest is trying the following:

composer dump-autoload -o

And if it does not help then try:

php artisan config:clear

Let me know how it goes after that!

travlongmore

Jun 2nd, 2023 08:17 PM

Hey Bobby! I tried those and still get the "Disk [digitalocean] does not have a configured driver" error.

It flags this line when loading the Laravel Valet test site:

img src="{{ Voyager::image(theme('home_promo_image')) }}" class="w-full max-w-3xl sm:w-auto"

The problem (I think) is the voyager.php config settings I think. For production the voyager assets path is set as:

'storage' => [
    'disk' => 'digitalocean',

That's what flags the error. I'm not sure the best approach because I obviously need that for the live site but for the local dev environment it doesn't work. Does that make sense? This is my assumption at least.

bobbyiliev

Jun 3rd, 2023 08:22 AM

Hi there!

The name of the disk in the config/voyager.php config file needs to match the disk definition in the config/filesystems.php config file.

Can you verify that you have a disk called digitalocean defined in the config/filesystems.php file?

As far as I remember, when we did the Spaces setup together for the production configuration, the name of the disk was spaces. If this is still the case in the config/filesystems.php file, then changing the storage disk name from digitalocean to spaces in the Voyager config, should fix the issue.

Let me know how it goes!

Best,

Bobby

travlongmore

Jun 3rd, 2023 11:20 PM

Thanks Bobby. I updated that but got a few errors. Turns out the league/flysystem-aws-s3-v3 package in composer wasn't working despite being added initially. Not sure what happened but after removing the vendor folder and composer.lock file I ran composer update and it's running ok now.

It doesn't see any files uploaded on the live site still but at least it's running in dev now. If you have any ideas on that one it'd be really helpful but I'm happy I can at least get working on other parts.

bobbyiliev

Jun 4th, 2023 02:44 AM

Hi there,

Happy to hear that you've got this working so far!

For the missing files, it is most likely due to the fact that some references of the files are stored in the database like the logo image location for example, so when you store data in the DigitalOcean database, it will not be available in your local database.

Let me know if this is the case!

travlongmore

Jun 4th, 2023 07:45 PM

Hey Bobby, I'm not sure how to figure this one out but it's not a huge issue. The Spaces settings appear to be working now but when I go to the test site the files from Spaces aren't showing. I had a look and they're referencing older files instead of the updated URL's for the Spaces files.

For example, on my dev environment on the homepage, the main hero image is referenced from home.blade.php as: img src="{{ Voyager::image(theme('home_promo_image')) }}

This is trying to show this file from Spaces which is an older one: themes/May2023/qHMhcccLHkwHItzUJSHC.png

The correct URL for the most recent image is: themes/May2023/fNA4q7nZfsrL0aCK757r.png

I'm not sure where I went wrong on this one but everything else seems to work. The Spaces settings in .env are correct and in config files so it's just figuring this part out.

bobbyiliev

Jun 5th, 2023 12:40 AM

Hey 👋

Yes, that would be expected, as when you upload the image, a reference to the image is stored in your database.

As your local environment and the App Platform environment are using different databases, the references to those images will be different.

If you were to connect to your database and check the theme_options table you will be able to see those references:

select * from theme_options \G

As the databases are different, when you make changes to your app deployed on the App Platfrom the changes will be made to the production database, and when the changes via the Voyager admin are made on your local site, the changes will be stored in the locally running database on your laptop.

Hope that this helps!

travlongmore

Jun 5th, 2023 03:40 AM

That makes total sense. Is there a 'best practice' or better way to run a dev environment so that it's essentially the same setup as production? I'm used to a different platform so this seems like I may have my setup wrong.

bobbyiliev

Jun 5th, 2023 05:56 AM

Yep, I think that your setup sounds very good. It is normal that your data would not be shared between your local and production environments.

What you could do upload your images locally and then once you push the changes also upload them via your production environment.