Deploying a new theme fails

[avra911]

When deploying a new theme, it fails because setup:static-content:deploy runs before setup:upgrade and there is no such theme found in theme table in database.

Error thrown is:

Unable to load theme by specified key: '<vendor>/<theme>' 

Wonder if static content should not be moved after setup upgrade.

[erikhansen]

@avra911 Are you certain that running setup:static-content:deploy before setup:upgrade fixes this issue? To verify that it does indeed fix it, if you try to do a deployment and it fails, you could SSH into the server, cd to the failed release directory, and then run the commands in the order you mentioned to see if you're successfully able to run setup:static-content:deploy.

I don't know whether it is fixed in 2.1.5, but as of 2.1.2, if Magento was running in production mode, you had to manually insert the new theme into the themes DB using a command like you can see in this comment: magento/magento2#2797 (comment) I'm wondering if this might actually be your issue, not the order of commands in this Gem.

[avra911]

Yes, @erikhansen, I connected to the server, checked static-content-deploy which failed, then run setup:upgrade which added the theme into database, then run again static-content-deploy and it did the trick. The only problem I noticed with record in theme table was the TYPE column was set to 1 instead of 0, but that is a different thing.

[erikhansen]

@avra911 Interesting.

The problem with moving setup:upgrade to run before setup:static-content:deploy is M2 is put into maintenance mode right before running setup:upgrade and doesn't come out of maintenance mode until after the release is finished being deployed. This results in a small amount of downtime (maintenance mode). If the setup:static-content:deploy command has to run before setup:upgrade, then that would significantly increase the amount of time the site would be in maintenance mode.

I'm sure @davidalger will have an idea for the best way to handle this.

[avra911]

Yes, I am aware of that too. Adding the theme manually in database seems a decent workaround, I posted here to find other ideas.

Thank you, @erikhansen!

[udovicic]

I can confirm this issue, as running setup:static-content:deploy before setup:upgrade will fail. However, I do not think that reversing the order is the right way to go. This is only the edge case where you push new theme, which is not that often.

Perhaps you can add some flag that can be set on deploying new theme?

[davidalger]

This is only the edge case where you push new theme, which is not that often.

Exactly why this wasn't accounted for when I built the gem initially :)

Reversing the order of the commands is definitely not a good working solution, as it will heavily increase the downtime from seconds to minutes.

What I think makes sense here actually is to simply wait till Magento 2.2 is released soon. I haven't had the chance to build a test repository with 2.2-dev yet to see how it interacts with this gem, but the static content deployment is no longer supposed to require a database connection. They are doing this so that Magento can be build on a CI server and then that image pushed to cloud servers via whatever mechanism on wishes to use, but that change should solve this in some way as well, as the static content deploy command will no longer be relying on what's in the database to determine what to deploy. I'll find out more when 2.2 is released and I can test with the GA release.

If anyone wants to propose a working solution to solve this on 2.1, I'm all ears, but given how infrequently the issue occurs (since nobody I know deployed a new theme ever day) I can't really justify the time to try and build a workaround into this gem if implementing the workaround is either going to have negative side-effects across the majority of deployments or take a significant amount of effort to develop.

[mttjohnson]

I just ran into this on a deploy of 2.2.2 where the initial deployment was done with a clean install of 2.2.2 and then a new theme was added to the repo, and when it was deployed it failed during the static content deploy "php -f bin/magento -- setup:static-content:deploy -f en_US"

The database did not have the new themes in the database theme table, but static content deploy was trying to build static assets for the new theme even though it wasn't yet in the database. When it tried to build the static assets for the new theme it seemed to be failing at different points when making calls to Magento\Framework\View\Asset\File->getSourceFile()

#0 ./vendor/magento/framework/App/View/Asset/Publisher.php(73): Magento\Framework\View\Asset\File->getSourceFile()
#1 ./vendor/magento/framework/App/View/Asset/Publisher.php(61): Magento\Framework\App\View\Asset\Publisher->publishAsset(Object(Magento\Framework\View\Asset\File))
#2 ./vendor/magento/module-deploy/Service/DeployStaticFile.php(89): Magento\Framework\App\View\Asset\Publisher->publish(Object(Magento\Framework\View\Asset\File))

After only running setup:upgrade and setup:di:compile the setup:static-content:deploy worked fine and completed without errors.

[erikhansen]

I've run into this issue multiple times over the past months (including on 2.2.2). My workaround has been to insert the new theme records from my local theme entry into the DB of the site I'm deploying to (the solution mentioned here).

According to the details at the bottom of this issue it looks like the core Magento issue should be fixed in 2.3.

[KevinMace]

I've also just run in to this issue in 2.2.2, I'll give the discussed work arounds a try.

[dverkade]

Still present in Magento 2.2.3, which I can reproduce as mentioned in #100

[wintermute-84]

this is becoming a problem when we constantly testing/ developing themes on one of our projects...
A flag to specify to use full setup:upgrade would be preferable.

[davidalger]

As this is not an issue in this tool but due to how Magento handles themes, I'm going to close this out. Unfortunately doing a full setup:upgrade before static content deployment would make deployments take significantly longer and eliminate zero-down deployments when the upgrade was actually unnecessary.

Where frequent deployments of new themes are made, my suggestion would be to add a custom routine to your specific project to insert the theme record before static content deployment runs. Cheers!