0

I am trying to follow this article to start a D8 site: https://www.drupal.org/node/803746

The article is for D7 but I think there are no much differences.

These are the steps I followed so far:

  • Cloned Drupal 8.2.x repository to my dev environment
  • Branched to 'my-project'
  • Created a remote repo, replaced it as my 'origin' and renamed Drupal.org to 'drupal'.
  • copied the example .gitignore as is, it by default ignores settings.php and vendor folder.
  • Ran composer install at root
  • Installed Drupal to local MySQL instance (after settings up Apache)
  • Committed and pushed files of the entire site to repository
  • Created staging environment and cloned from repository
  • Copied settings.php, dumped dev database and re-imported it to staging, and re-ran composer install at staging environment
  • I ran drush rebuild to refresh cache.

I expected this to be all and now the staging environment should be up and running, but it is running with now style, apparently the themes are not correctly copied.

So my first question is what did I miss, do I have to use composer to install core themes?

My second question is, do I have to re-install any additional theme or modules using composer on all sites? Or in other words, why is it a good practice to git-ignore vendor folder rather than install once on dev env and pull dependencies from repository?

Below is a screenshot for how staging main page looks like:

enter image description here

[EDIT] Checking the /admin/reports/dblog page, these was the warning that appeared a lot:

warning: file_put_contents(temporary://filexmZMo3): failed to open stream: "Drupal\Core\StreamWrapper\TemporaryStream::stream_open" call failed in file_unmanaged_save_data()
Improve this question
6
  • Drupal core comes with themes pre-installed and should work out of the box. Clear the caches and check your site and server logs. I recently answered another question where this was caused by CSS aggregation (you want that enabled, but you can check if it is the cause). As for the vendor folder, I suppose it is ignored because it can be easily replicated and would take quite some space otherwise.
    – Neograph734
    Jan 16, 2017 at 11:55
  • I forgot to mention that I ran drush rebuild after cloning to the staging env. I will add this step. Shouldn't that be enough?
    – Bishoy
    Jan 16, 2017 at 12:01
  • Your workflow seems fine, but it could be a server configuration issue as well. Try above suggestions (read logs and disable CSS aggregation) and see if it works. Alternatively try to install Drupal differently (composer, drush) and see if it changes anything...
    – Neograph734
    Jan 16, 2017 at 12:07
  • I guess it's a privileges issue as you pointed out, I can see a lot of access denied errors in log. I forgot to mention that my dev env is Windows and staging is Linux, hence the issue didn't show on dev env. All files are owned by root, should I manually set owner to www-data for all files? What happens when I pull new changes later?
    – Bishoy
    Jan 16, 2017 at 14:20
  • Give it a try, i have no idea of your configuration... And don't pull as root, best to keep that for system changes only.
    – Neograph734
    Jan 16, 2017 at 14:29

1 Answer 1

Reset to default
0

Because my dev environment was Windows and the staging environment was Linux, the temporary folder differs.

I had to fix it using the admin pages of the file system.

Later I found that I will need to do this every time I use drush config-import so I decided to overwrite the value in settings.php as following:

$conf['file_temporary_path'] = '/tmp';
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.