Troubles with deploying Grav updates - Am I doing it wrong?

Archive
1

I have a consistent problem with upgrading and updating Grav on my local server and then deploying it to my remote server. I get a broken site on the remote, even though the local is fine, every time.

Here are my steps:

  • Commit (Git) all local changes
  • Do bin/gpm selfupgrade
  • Do bin/gpm update
  • Do bin/grav composer
  • Do bin/grav clear-cache
  • Commit those changes
  • Run phploy to upload the changes recorded by Git to the remote server via FTP
  • Do bin/grav clear-cache on the remote server

That always give this this error when attempting to load the remote site:

Fatal error: Class 'CSSmin' not found in /home/bobrocke/public_html/materialize.bobrockefeller.com/system/src/G rav/Common/Assets.php on line 561

Fatal error: Uncaught exception 'RuntimeException' with message 'Could not find resource 'whoops.css' in any resource paths.(searched: /home/bobrocke/public_html/materialize.bobrockefeller.com/system/asset s, /home/bobrocke/public_html/materialize.bobrockefeller.com/vendor/filp/ whoops/src/Whoops/Handler/../Resources)' in /home/bobrocke/public_html/ materialize.bobrockefeller.com/vendor/filp/ whoops/src/Whoops/Handler/PrettyPageHandler.php:500 Stack trace: #0 /home/bobrocke/public_html/materialize.bobrockefeller.com/vendor/filp/ whoops/src/Whoops/Handler/PrettyPageHandler.php(126): Whoops\Handler\PrettyPageHandler->getResource('whoops.css') #1 /home/bobrocke/public_html/materialize.bobrockefeller.com/vendor/filp/ whoops/src/Whoops/Run.php(256): Whoops\Handler\PrettyPageHandler->handle(Object(Whoops\Exception\Error Exception)) #2 /home/bobrocke/public_html/materialize.bobrockefeller.com/vendor/filp/ whoops/src/Whoops/Run.php(327): Whoops\Run->handleException(Object(Whoops\Exception\ErrorException)) #3 /home/bobrocke/public_html/ma in /home/bobrocke/public_html/materialize.bobrockefeller.com/vendor/filp/ whoops/src/Whoops/Handler/PrettyPageHandler.php on line 500

The a bin/grav composer on the remote server fixes things.

What am I doing wrong?

2

The vendor/ folder, on the server, is correctly filled with the dependencies like in localhost?

3

Apparently not, but I don’t know why it shouldn’t be.

4

bin/grav install should do it

5

I think they’re not stored in the Git server due to .gitignore, try commenting the vendor lines in it

6

My .gitignore doesn’t include the vendor folder. On purpose. It does include composer.lock; should it not?

7

(I’m referring to https://github.com/getgrav/grav/blob/develop/.gitignore#L3)

8

It does in the current version, although in the next Grav release, composer.lock is removed from .gitignore because we’re going to use composer install rather than composer update to ensure versions in vendor are consistent.

9

I’m not using Grav’s default .gitignore.

10

Maybe I just need to do as rhukster suggested: just upload \user and update Grav on the remote server directly.

11

This approach has been solid for us, and has never been an issue. Also gives you the opportunity to thoroughly test out a grav release local before deciding to update the remote, independent of content usually (unless some new content or plugin requires the update).

I don’t even think when its just a content update though. I just make the edits, test it local, commit, and push… I usually don’t even bother checking the remote site because it’s so reliable, i just know it’s going to look the same.