search

platformsh / example-typo3

Starter kit for running TYPO3 on Platform.sh. Maintained by the TYPO3 Community Interest Group (CIG Platform.sh)
http://platform.sh/
GNU General Public License v3.0
16 stars 9 forks source link

PackagesState.php not writeable #18

Open joergRossdeutscher opened 7 years ago

joergRossdeutscher commented 7 years ago

I used the One-click-installer from platform.sh to setup TYPOP3. Worked like a charm. Created a new admin user, changed the password, changed some text on the demo site. All went fine.

Went away from my computer.

Came back to my computer later. Backend was still open, login had expired, tried to re-login. Nothing happened, login prompt re-appeared again and again. Didn't work.

Closed window. Opened a new window with the BE-admin-URL. Found an error-message instead login form:

“Oops, an error occurred! We could not update the list of installed packages because the file /app/web/typo3conf/PackageStates.php is not writable.“

Since I am completely unexperienced with platform.sh I made an ugly hack (the site is only for “playing with platform.sh“. I added “chmod 777 web/typo3conf“ to the deploy hook. Pushed to git, could login again. (To my surprise typo3conf shows as “locked“ again in the installer tool, however, I do not care at the moment.)

Being admin now, I looked at the “Extensions“ area, found it completely disabled since composer mode is active. Which is fine, I think.

How can I deal with the problem in a not-so-dirty manner? Possibly TYPO3 does not need that file when in composer mode (don't know), however, being kept from login is a problem.

ksjogo commented 7 years ago

The typo3conf folder itself is mounted readonly, so the 777 won't help there. PackageStates.php should not be written apart from the typo3_console inside the build hook, so I am surprised that some part of TYPO3 wants to change it. Does the error/trace show who tries to write?

joergRossdeutscher commented 7 years ago

OK, then I don't know why the BE worked again after chmod and another git push. I removed the chmod again, re-deployed, and now the site is still working.

For a real fix:

I am not working at a real project atm, I am just evaluating possible hostings, so I have not set up a up-to-date TYPO3 locally that I could use for debugging.

Anyway, my expectation on that topic is, that platform.sh should deliver what TYPO3.org declares and not make own, even more strict rules. That means: The folder typo3conf should be fully writeable. From a developers point of view I also agree here. My expectation is: I install, I login to the install-tool, everything is green because the TYPO3-requirements are fulfilled.

Can the folder be made writeable, or is that not possible within the platform.sh-way of creating environments?

joergRossdeutscher commented 7 years ago

Forgot to post the log entry…:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1382449759: We could not update the list of installed packages because the file /app/web/typo3conf/PackageStates.php is not writable. Please, check the file system permissions for this file and make sure that the web server can update it. | TYPO3\CMS\Core\Package\Exception\PackageStatesFileNotWritableException thrown in file /app/vendor/typo3/cms/typo3/sysext/core/Classes/Package/PackageManager.php in line 759

ksjogo commented 7 years ago

One of the main architectural points of platform.sh is to have a build step were the application is composed together and necessary files written, then freeze that, push it to the server and not change code anymore. You could mount the typo3conf writeable if you want and copy the installed extensions from somewhere else on deploy, but that's not something I see the need for. The warnings are right in the sense that this example is using a setup a bit different to a normal setup. But the structure is intended so I am more inclined to find a way to hide/greenen this warnings.

Regarding the PackageStates, I just did a clean install and reproduced your steps but did not run into that problem. I updated to 8.7.1 and some other newer deps though. That might have helped.

joergRossdeutscher commented 7 years ago

Thanks for clarification, I get the point, I like that idea. We will have to check if we still like the idea in a real-world-project. :-)

I can imagine that my problem was triggered by something obscure like „letting the session expire immediately on first run“, so feel free to close my report.