Skip Luma theme when compiling static resources

[viktor-zhuromskyy]

I have a situation where I have custom theme (Porto, based off blank theme) installed and active, and prepackaged Luma theme is not active anywhere in my Magento stores, so no need to trigger compilation on it. BWT when I run static content compiler, both Magento/blank, Magento/luma and Smartwave/porto are being compiled. That would be fine, but I am compiling 6 locales for my multistore/multilang setup, and that takes awhile, believe me!

The command I trigger:
php ./bin/magento setup:static-content:deploy en_US fr_FR de_DE pt_PT es_ES it_IT

What can I do to pass a command to compiler to skip compilation of Magento/luma?

[buskamuza]

Hi @devdesco-ceo ,

just wanted to inform you that we're discussing this question. It is obviously, an important one.
Unfortunately, right now it's impossible to skip a theme.

[viktor-zhuromskyy]

Please make it an option in bin/magento console script.

[alankent]

(If you want a short term hack, you can delete the Luma theme directory under 'vendor' so Magento does not see it any more. Make sure you run the CLI to uninstall the theme as well so it disappears from database etc. http://devdocs.magento.com/guides/v2.0/install-gde/install/cli/install-cli-theme-uninstall.html. Yes, we need a better solution, but it may remove some immediate pain.)

[viktor-zhuromskyy]

CLI theme uninstall will not work since it is intended for use only with composer installed themes. :(

[alankent]

You might get away by just deleting the directory. Did you try that? There is a 'themes' table that gets lazily populated by theme names (when you go to the Admim page). So if you delete the Luma directory before you go to that page in the Admin, I think you should be fine. (Or write the one-line SQL script to delete the row from the table - that is what I was hoping the CLI command would do for you, forgetting that it also updates the composer.json file.)

[viktor-zhuromskyy]

yes, just deleting all "luma" directories helped.

[jasperzeinstra]

I also have a theme based on blank theme. But i'm not using blank or luma theme in any of my shops. For now i've only got two languages. But will be more in the future. I have to wait for static content deployment of blank and luma theme twice. But non of the shops is using these files.

We don't want to add extra deployment time to our process. So i'm really awaiting a solution for this problem. My static content deployment now takes about half an hour. I can imagine how long Viktor has to wait with 6 languages.

+1 for a solution. This long waiting time is unnecessary.

[pivulic]

We have 16 stores with 11 different languages, it takes us ~1h 40 minutes... So yes, +1 for a solution.

[viktor-zhuromskyy]

On everage it takes about one and half hour form me to compile 7 languages with 14 storefronts

[erikhansen]

+1 for a solution. We've run into this issue on a site with 5 locales and two custom themes. Having to compile the magento/blank and magento/luma themes doubled the setup:static-content:deploy time.

I would prefer an "exclude" flag be added (as opposed to "include"). Since the exclude flag will likely be hard-coded into deployment scripts, being able to specify which themes to exclude seems more useful. Some thing like this:

bin/magento setup:static-content:deploy --exclude=magento/luma,magento/blank

[alankent]

As a workaround, has anyone looked at using https://github.com/SnowdogApps/magento2-frontools with Gulp to generate the theme files for production? You list theme names and locales to compile, so easy to skip combinations you don't want. I was just not sure if it did everything for production (I have not tried it), but I would love to understand if there are any gaps.

[erikhansen]

@alankent I love how creatively you think about problems like this. I tend to try and stick with native tools for things like deploying to production, as they tend to be more stable/trustworthy. I am planning on reading through your blog posts about using Gulp for development to see what benefits it offers.

[alankent]

We need to improve the performance of our native tool. But Gulp is clearly faster and more interactive during development. I am honestly curious to see if it can do the full production deploy. Then it can be "use our built in tools if you don't want to think; use Gulp if you are willing to install one extra tool for a better development experience".

But to be clear, this is not my project - @Igloczek kicked it off and did all the work. I just made some suggestions along the way. If there were gaps moving to production, I was going to suggest to him to fix those problems as well ;-). The idea was more along the lines of "use the same tool during development and production, so the CSS files are identical". I think this is more important than using our "official" tool. It also means I assume you can use any gulp optimization plugins, and you can get more control over manual CSS file merging.

(And I have a final draft of a ebook on themes in the wings undergoing final review - if this works all the way to production, I may sneak that into the book as well.)

[erikhansen]

@alankent Yeah, it makes sense to use the same compilation technology in development and production to ensure consistent results. Per your previous question, I am curious to see if anyone is using https://github.com/SnowdogApps/magento2-frontools in development and production and to see how that is going for them. Maybe a tweet from you would get more feedback than this obscure ticket. :)

[alankent]

I might try that in a few days - I was hoping people expressing pain on this thread would be more motivated to give it a try - they had real world problems that are known to be bad, so if it works for them then that is a big thumbs up with concrete data.

[Igloczek]

@alankent Thanks for mention, but "Frontools" unfortunately are not 100% substitute of setup:static-content:deploy - I focused on styles compilation and this part works as expected, but there are also RequireJS and templates processing inside this CLI command and for now I'm not supporting it.

[Igloczek]

BTW. I forgot about little thing to do - I said in comments of some your blog post about --no-styles flag to this CLI command and I'm going to do this ASAP as PR to main M2 repo.

So, if you use setup:static-content:deploy --no-styles [...] + Frontools -> deployment process should be a lot faster.

[erikhansen]

I just finished writing Capistrano scripts to automate a Magento 2 build that we're launching tomorrow. The site has three custom themes + the two native themes. The total build process takes ~19 minutes, ~18.3m of which is running the bin/magento setup:static-content:deploy command. Being able to exclude the magento/blank and magento/luma themes from the command would remove ~7m from the deploy time. This should be fairly simple to implement and it would be good to know whether this is something Magento has on their roadmap and/or whether they would accept a PR to implement this functionality (I'm looking at all of you others that are experiencing the pain of this).

[viktor-zhuromskyy]

Nice! 1+

[antonkril]

@erikhansen, yes, we have this on roadmap, and yes, we would accept a PR. cc @buskamuza

[dimasch]

+1 for the solution.

[kirmorozov]

Just run in parallel for each store.
This is trivial case.

[buskamuza]

Related internal ticket is MAGETWO-49510

[hostep]

There is an open pull request which will support this btw:
#4294

[thdoan]

For those who cannot wait for @denisristic's PR to be rolled into v2.2, then you can merge the two diffs below for a quick fix (based on v2.0.7).

File .../vendor/magento/module-deploy/Model/Deployer.php
Deployer.php.diff.txt
Deployer.php.txt (merged)

File .../vendor/magento/module-deploy/Console/Command/DeployStaticContentCommand.php

DeployStaticContentCommand.php.diff.txt
DeployStaticContentCommand.php.txt (merged)

This change allows you to pass --theme=<theme> or -t <theme> to setup:static-content:deploy to deploy files only for the theme you specify. Example: magento setup:static-content:deploy --theme=luma

[denisristic]

@thdoan thanks for diff patch :)

In the latest version you can exclude theme by adding flag --exclude-theme=THEME (since that is what @devdesco-ceo asked)

Also, as for themes there are added include/exclude flags for languages (--language and --exclude-language) and for areas (--area and --exclude-area)

[thdoan]

Even though deploying to one theme cut down on the deployment time by several orders of magnitude, even a 10-second static deployment time adds up over time. This wasn't working out very well for our rapid prototyping workflow, so I came up with a method to reduce the time to almost instantaneous. If you feel that this may also fit into your workflow, then proceed...

On a high level, it is quite simple: (1) find the most recently modified files, (2) copy only those files to their respective directories in pub/static. Here are the steps in more detail (this assumes that you are in developer mode):

1. To find the most recently modified files, it's helpful if your code base resides inside a version control system, but not necessary. To give a specific example, let's say you modified the JavaScript file /path/to/magento/app/design/frontend/<Vendor>/<theme>/web/js/module.js. When you run magento setup:static-content:deploy, it copies the file to /path/to/magento/pub/static/frontend/<Vendor>/<theme>/<locale>/js. With this information in hand, we know that <theme>/web maps to <locale> under pub/static, so first cd to the web directory. From there, you can do git ls-files --modified --others to get a list of modified/new files relative to that directory. If you are not using Git, then there's likely an equivalent command (for example, in CVS this can be accomplished by doing something like cvs -nq update $1 | sed -n "s/^[?AMU] //p"; if you're not using version control at all, then you can get a list of files modified in the last hour by executing find * -type f -mmin -60 -print). You should see a plain list of file(s):

   js/module.js
   

2. To copy the modified files into their respective static directories, pipe the list of files into xargs. Using the Git example from step 1, the command should now look like this:

   git ls-files --modified --others | xargs -I {} cp --parents {} /path/to/magento/pub/static/frontend/<Vendor>/<theme>/*/
   

   The --parents option creates the directory structure if necessary. The * glob takes care of matching whatever locale you're in.

To put it all together, you can wrap this up into a nice little alias, e.g.:

alias deploy='cd /path/to/magento/app/design/frontend/<Vendor>/<theme>/web; git ls-files --modified --others | xargs -I {} cp --parents {} /path/to/magento/pub/static/frontend/<Vendor>/<theme>/*/; cd - 1> /dev/null'

If you are managing multiple themes, then you can convert this into a bash function that accepts a themes param and loops through each theme to do the same.

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.

[erikhansen]

@everyone following this thread: Magento 2.1.1 now supports being able to exclude/include themes, languages, and areas when running bin/magento setup:static-content:deploy. Huge props to @denisristic for this pull request.

So for example, you can now exclude Magento\blank and Magento\luma when compiling:

bin/magento setup:static-content:deploy --exclude-theme="Magento/blank" --exclude-theme="Magento/luma"

[erikhansen]

@hostep brought it to my attention that 2.1.1 also includes parallel asset compilation. I've tested this and compiling 5 themes on my local environment only took 30 seconds. As a result of this, I think the flags to exclude themes/locales are less useful since excluding them will make a much less significant impact on compilation time as it would have previously.

[hostep]

@erikhansen: not every hosting provider will have enabled the pcntl PHP module which is necessary for the parallel computing, so I think it still makes sense to have those extra flags.
Good news about those 30 seconds 👍 , guess I'll have to redo my tests (most likely I missed something, it was already very late last night :p)

[cacycleworks]

If Google brings someone here debugging a 2.2.2 install, please do not try removing the luma theme. It breaks /bin/magento...

Curiously enough, php bin/magento setup:static-content:deploy -f --exclude-theme="Magento/luma" takes roughly 90 seconds to run an a mostly empty site. And it took roughly 90 seconds without adding --exclude-theme="Magento/luma".

[BB-000]

"--exclude-theme="Magento/blank" doesn't exclude blank theme from compilation, I assume because it is the parent to my child theme. I know the blank theme hasn't changed though, so I still would like it excluded?

[hostep]

@BB-000: please follow #13165, it's probably expected behavior since Magento 2.2 got released.