3

i have to run setup:upgrade command when ever installing new module in magento2.

otherwise its giving error in front end.but if any user browsing on this time it will give error.how to handle this situation? In magento1 there will be no problem.

There has been an error processing your request

Exception printing is disabled by default for security reasons.

Error log record number: 1145810894775

Improve this question
3
  • I only notice this error after clearing my cache, is your cache enable or disable? – Renon Stewart Jul 23 '15 at 13:02
  • cache enabled.. – Sivakumar K Jul 23 '15 at 13:04
  • 1
    While creating a custom module, I notice that if I change only the module version number the site would continue to function but after clearing cache the site would stop work. Then I would have to run setup:upgrade command to get it working again – Renon Stewart Jul 23 '15 at 13:13
2

Magento 2 is even less suitable for a one click install extension approach than Magento 1.

I would recommend a deployment workflow where you do your upgrades on a build or staging system and then synchronize the files to the live system after testing.

Example setup

Move your Magento installation outside the document root, for example to /var/www/example.com/release/1 and create /var/www/example.com/htdocs as symlink to /var/www/example.com/release/1/pub. Then /var/www/example.com/htdocs must be configured as document root in your vhost settings.

To easily switch the symlink to a new release, you have to move some files outside of the release directory and replace them with symlinks to the new location:

  • pub/.htaccess
  • pub/media
  • pub/static
  • pub/var
  • app/etc/config.php

(I hope, I didn't forget anything important. For Magento 1, it is .htaccess,media,var,app/etc/local.xml)

A new release will be copied from the staging server to /var/www/example.com/release/2, the symlinks to the files/directories listed above will be created within, then the main symlink is switched from release/1 to release/2. So the actual update is one atomic operation, if you don't count flushing cache and triggering database update scripts.

All this can be easily automated, so once you have set it all up, deployment gets easy again, and you can be much more confident that it works.

Update: OK, as I understand now, you get an error during the database update. I fear the best solution for that is to go into maintenance mode for this (hopefully very short) period:

touch var/.maintenance.flag
setup:upgrade
rm var/.maintenance.flag
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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