Hi,
on the installationprozess comes the following Error (see picture) and the installation stops.
By install only the original Core 8.3.5 and then after install Commerce 2 with composer i have no problems...
Strict warning: DateTime::createFromFormat(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in Symfony\Component\HttpFoundation\Response->__construct() (line 207 of /my root/vendor/symfony/http-foundation/Response.php).
Symfony\Component\HttpFoundation\Response->__construct('', 302, Array) (Line: 37)
Symfony\Component\HttpFoundation\RedirectResponse->__construct('http://www.test-2.tecmawi.eu/core/install.php?rewrite=ok&profile=commerce_base&langcode=de&continue=1&id=1&op=start') (Line: 867)
batch_process(Object, Object) (Line: 619)
install_run_task(Array, Array) (Line: 540)
install_run_tasks(Array) (Line: 117)
install_drupal(Object) (Line: 44)
Strict warning: DateTime::createFromFormat(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in Symfony\Component\HttpFoundation\Response->__construct() (line 207 of /my root/vendor/symfony/http-foundation/Response.php).
Symfony\Component\HttpFoundation\Response->__construct() (Line: 160)
_drupal_log_error(Array, 1) (Line: 584)
_drupal_exception_handler(Object)
The website encountered an unexpected error. Please try again later.
RuntimeException: Failed to start the session because headers have already been sent by "/my root/vendor/symfony/http-foundation/Response.php" at line 207. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 145 of /my root/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (Line: 163)
Drupal\Core\Session\SessionManager->startNow() (Line: 194)
Drupal\Core\Session\SessionManager->save() (Line: 181)
Symfony\Component\HttpFoundation\Session\Session->save() (Line: 622)
install_run_task(Array, Array) (Line: 540)
install_run_tasks(Array) (Line: 117)
install_drupal(Object) (Line: 44)
Greeting from Sunny Hamburg-Germany
Comments
Comment #2
frank hh-germany commentedComment #3
bojanz commentedRead the error and the backtrace, it's not coming from any Commerce code.
Looks like the server's timezone (in php.ini) is either empty or misconfigured, causing a strict warning that breaks Drupal's batch.
Thus, you'll need to either fix the default timezone, or disable strict warnings (both in your php.ini). Contact your host if you don't have access to the php.ini
Comment #4
frank hh-germany commentedHi bojanz,
thats my server php.ini. To configure this i must contact the hoster.
But, commerce 2 on Drupal 8.3.0 has no problems make and a original D8.3.5 core singleinstall runs perfect.
php.ini in root
Comment #5
bojanz commentedI just installed the latest commerce project base (with Drupal 8.3.5) on a PHP7 ubuntu server with strict warnings enabled. No errors produced.
Can you try installing via install.php, instead of using Drush? Let's see if that makes a difference.
Comment #6
frank hh-germany commentedHi bojanz,
unfortunately I have no idea of Drush.
I'm glad I got it with Composer.
If Drush also works over SSH (Putty) and you write me a small guidance, I will try it.
Generic question: Is with Commerce 2.x-dev also downloaded the dev version of the Drupal Core?
My server runs on Linux with appache and is managed in the basic configuration by the host.
I think there is somewhere a wrong sign or forgotten blank.
Small cause, great effect.
Greetings from Hamburg-Germany
Comment #7
bojanz commentedSorry, I thought this was an error produced by Drush, I now see that it isn't.
No, the most recent stable version of Drupal core is fetched, 8.3.5 currently.
Comment #8
frank hh-germany commentedBy Rewrite Address to
core/install.php?rewrite=ok&profile=commerce_base&langcode=de&continue
Comes the following Errormessage
The Installprocess wath stop.
Is there a way to an older Commerce Install with composer? How can i get this?
Comment #9
bojanz commentedUsing an older version won't help you because your problem is not coming from code, it's coming either from a server problem or something you did while deploying/moving the files.
I suggest installing a vanilla Drupal 8.3.5 install and then following the "Existing site" instructions instead: http://docs.drupalcommerce.org/v2/getting-started/install.html
Comment #10
frank hh-germany commentedMy Steps:
1. Install with Composer
2. Openening the the URL (here comes the first Info to the Symphony-Error "
Strict Standards: DateTime::createFromFormat(): We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /my root/TEST/vendor/symfony/http-foundation/Response.php on line 207")3. Follow the Installations way
4. Installation abort on Step 4 "Install Site" and the Language wath switch from German to English
"I suggest installing a vanilla Drupal 8.3.5 install and then following the "Existing site" instructions instead: http://docs.drupalcommerce.org/v2/getting-started/install.html"
By this way runs the installation.
But with the timeerror and without abort installation > See www.test.tecmawi.eu
After the installation the error is gone ???
Ok, i call in the next Minutes my host. Let's see what he told me.
Info
Comment #11
frank hh-germany commentedHi bojanz,
thanks for response.
My hoster said that it could therefore come that by a previous php error message, by the missing the date time zone the further installation process is aborted.
As a solution he suggested me to create a user.ini file in the root directory.
It works.
This means, however, in the reverse conclusion, that the restrictions during the installation process, with regard to actually small errors, were sharply tightened.
For posterity:
In the main or root directory, create a file called .user.ini, where you will find all php directives.
Before you disable the Maintance set this in yuore user.ini
As far as I know works from the user.ini but not the opcache.
Please set the Issue to fixed
Greatings from Hamburg-Germany
Comment #12
bojanz commentedKeep in mind that most hosts don't actually show strict warnings, cause PHP advises that production installs turn them off.
So, your host brought this upon themselves.