I have still the same problem. I am not able to create a (empty) site using Neos CMS LTS Version 2.3.8 at Domain-Factory. Can someone help?
Meanwhile I tried another way to get a working Neos. I drop all tables from the database and afterwards I executed the following command:
$ ./flow doctrine:migrate
I got an exception:
Exception #1355480641 in line 137 of /kunden/xxxxx_xxxxx/Neos/neoscms/Data/Temporary/Production/Cache/Code/Flow_Object_Classes/TYPO3_Setup_Step_DatabaseStep.php
: Failed loading /usr/local/php5/ZendOptimizer.so: /usr/local/php5/ZendOptimizer.so: undefined symbol: zend_opcode_handlers
Fatal error: Cannot use $this as parameter in /kunden/xxxxx_xxxxx/Neos/neoscms/Packages/Libraries/ocramius/proxy-manager/src/ProxyManager/GeneratorStrategy/Eval
uatingGeneratorStrategy.php(68) : eval()'d code on line 340
The same exception was thrown when I tried to call the setup using webinterface. Only the table “flow_doctrine_migrationstatus” was created after executing the setup or the migration command.
Any help would be appreciated.
It seems nobody can help me.
I have asked the support of the provider DomainFactory regarding the failed loading of ZendOptimizer. They told me I should create a special php.ini for the domain and drop the entry for the Zendoptimizer.
I did it and now I got the same exception but without an additional exception log file. Again: I deleted all tables from the database and on the next step I executed the following command which was canceled with a fatal error :
$ ./flow doctrine:migrate
Fatal error: Cannot use $this as parameter in /kunden/xxxxx_xxxxx/Neos/neoscms/Packages/Libraries/ocramius/proxy-manager/src/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(68) : eval()'d code on line 340
Is anybody here who has an idea how I can solve this problem?
Hi Christian, maybe you are right. Actually I did not know it. The provider DomainFactory has offered a pre-installed version Neos CMS LTS Version 2.3.8 which I have selected.
After the installation the Neos.Demo package was available and working. Up to now I was not able to create a new package or site.
I am pretty sure it’s something about the PHP version. What does php -v say and can you find out what version of the ocramius/proxy-manager is installed?
The changelog Packages/Libraries/ocramius/proxy-manager/CHANGELOG.md is telling me that the version 2.0.1 has been installed.
Using the mydomain.de/setup I am able to perform the first steps before I get still the same exception:
Exception #1355480641 in line 137 of /kunden/xxxxx_xxxxx/Neos/neoscms/Data/Temporary/Production/Cache/Code/Flow_Object_Classes/TYPO3_Setup_Step_DatabaseStep.php:
Fatal error: Cannot use $this as parameter in /kunden/xxxxx_xxxxx/Neos/neoscms/Packages/Libraries/ocramius/proxy-manager/src/ProxyManager/GeneratorStrategy/EvaluatingGeneratorStrategy.php(68) : eval()'d code on line 340
Neither of the mentioned PHP versions is an actual CLI binary, which you should have for Flow and Neos. So you should figure out where your hoster has an actual PHP CLI binary (eg. PHP 7.0.24 (cli) (built: Oct 17 2017 00:34:37) ( NTS )) from my local system.
avoid the %PHP_BINDIR% at this place, since this is used to locate the CLI binary from the SAPI binary. Use the full path in the setting. Afterwards, you might at most need to flush the cache.
I used a new browser instance, but I’ve got still the same exception. Only one empty DB table was created (flow_doctrine_migrationstatus). I wondered a little bit: the (old) settings for the DB were still available in the setup form. (it was not removed by flushing).
has the same effect. I can find several settings with the right reference to the php-binary:
Even in the first line of the flow script: #!/usr/local/bin/php7-70STABLE-CLI
The DB configuration is stored inside the Settings.yaml, which is not flushed for good reasons
Anyway, I just out of curiousity installed the Neos 2.3 LTS on our DF account and the installation went really smoothly, it also already added the phpBinaryPathAndFilename to settings automatically so even the command line tool worked
So somewhere down your path a few things must have gone off road and now cause a lot of pain unfortunately Let’s try to get that solved!
I then further followed your steps from the first post, and after importing the new site (without the resource clean&publish, node repair) I also ended up with the exception about the Neos.Demo package.
What I then did however, was just flush the cache, rebuild it and then I could correctly log into the Neos backend again start working on that site. export FLOW_CONTEXT=Production ./flow flow:cache:flush --force ./flow flow:core:compile && ./flow doctrine:compileproxies && ./flow flow:cache:warmup
I always do the warmup with the below three commands because I occasionally had the proxy compilation fail and then things would not work. With this line things always work out correctly.
So maybe it’s better to just restart all over instead of trying to fix the broken setup?
Almost solved
I started from the scratch and I followed your instruction and finally I was able to log into the backend - Thanks again for your support.
After few seconds four errors were displayed:
Anyway I build a new page with some content - I was happy.
Later I recognized that I am not able to publish any content to the homepage. I was able to add elements to the Content Collection of the homepage (in the Structure Tree), but this content could not be published and was not displayed in the backend.
As you can see in the picture
The headline was displayed in “Structure Tree” but not in the “content canvas” nor in the “Property Inspector”.
Do you have an idea how can I solve this?
I don’t believe this is important: but for your info: I defined a siteName with an umlaut (ä).
./flow kickstart:site My.Seiten meinärger.info
The first three are in the default Settings.yaml that DF provides, but I’m not sure what they’re supposed to do, since there are no such settings in Flow Resource Management. You can just remove those lines, as they will currently not take any effect anyway.
As for the other three, those are from the Flowpack.Neos.FrontendLogin package and the messages basically tell that they use the old format for the requestPatterns setting. This still works, so the messages can be safely ignored. If you want to get rid of them, overwrite the Settings for those three requestPatterns in your global Settings.yaml to match the description here: http://flowframework.readthedocs.io/en/3.3/TheDefinitiveGuide/PartV/ChangeLogs/330.html#id26
Thanks for these hints. I was able to fix all six errors in the configuration. The other four problems “Error loading inspector” are still existing. I will open another thread because I believe the problem about inspector editor is a different one and I mark this thread here as SOLVED. Here a summary about the solution for all others who have got similar problems using Neos 2.3.8 at DomainFactory:
After installation drop the Neos.Demo site and create a new one
After that you are able to log into backend and you will see 6 errors in the configuration:
Settings.TYPO3.Flow.resource.publishing -> This property is not allowed here, check the spelling if you think it belongs here.
Settings.TYPO3.Flow.resource.fileSystem -> This property is not allowed here, check the spelling if you think it belongs here.
Settings.TYPO3.Flow.resource.mirrorMode -> This property is not allowed here, check the spelling if you think it belongs here.
Settings.TYPO3.Flow.security.authentication.providers.Typo3SetupProvider.requestPatterns.controllerObjectName -> expected: type=dictionary, null found: type=string
Settings.TYPO3.Flow.security.authentication.providers.Typo3BackendProvider.requestPatterns.Flowpack\Neos\FrontendLogin\Security\NeosRequestPattern -> expected: type=dictionary, null found: type=string
Settings.TYPO3.Flow.security.authentication.providers.Flowpack.Neos.FrontendLogin:Frontend.requestPatterns.Flowpack\Neos\FrontendLogin\Security\NeosRequestPattern -> expected: type=dictionary, null found: type=string
For solving these errors the configuration must be fixed: Error 1-3: can be solved by simple dropping the following lines from ./neoscms/Configuration/Settings.yaml
I am not sure whether this configuration is made in the right way (for Neos 2.3.8). I just copied and adapted it from Neos 3.2. Anyway the 6 errors were not displayed any more
The remaining issues can be tracked here: Some editors of inspector cannot be loaded after a fresh installation