Twig Issues on Google App Engine Standard

[pdugas]

Q	A
Bug report?	maybe?
Feature request?	no
BC Break report?	no
RFC?	no
Symfony version	3.4.0

Apologies in advance for this being long. Want to make sure details I've collected so far are captured.

I am trying to get something more than a simple hello-world running on Google App Engine's Standard PHP environment. The primary hurdle is the read-only filesystem but there is a starter-project that has worked through the issue enough to get that simple app working. I had to adjust one minor thing to start - switch from Memcache to Memcached and update a few other settings here and there. Then I started adding other pieces that a more complicated app would need. Started with Doctrine entities - no problem there. Then started more complicated pages where I ran into what appear to be Twig issues that I've not been able to figure out. I'm looking for some assistance investigating this.

A quick aside... One of the concepts in the starter-project is to warmup the prod cache locally then deploy the results to GAE so everything that would be generated on the fly and cached is already there. The starter-project's authors found that the cache is somehow different when generated on different versions of PHP. GAE runs PHP-5.5.34. I set platform/php to this in my composer.json to hopefully prevent anything from getting updated too far to work up there. Anyway, the starter-project uses an extended Twig\Environment class that seems to overcome this.

The first issue I ran into was with a login form that used the csrf_token() function in Twig. Even with the extended Twig\Environment class from the starter-project, I'm getting an error from the baseclass' getRuntime() method indicating it was unable to load Symfony\Bridge\Twig\Form\TwigRenderer. I've no idea what the problem is but I was able to work around it by generating the token in the controller action and passing it to the render function. Users can login now.

Next, I discovered that once logged in, the template logic that decides whether the page header should have a /login or /logout link is busted. It's simply {% if app.user %} but that's never true even when the user clearly is logged in. No errors. As before, I was able to pass it ($this->getUser()) in from the controller instead of using the builtin variable and it worked.

I added FOSRest and some APIs with only one issue. The constructor for the FileCache class in JMS Serializer is throwing an exception because it's checking if the cache directory is writeable. I patched around it (commented it out) and pressed on. I added my own CacheWarmer that serializes my entities once and things were working again. JMS has since added their own CacheWarmer to accomplish the same.

Next I added EasyAdminBundle. Same issue as with JMS Serializer. It's using Doctrine's FileCache class for it's cached config and it's throwing when the cache directory isn't writable. Another patch and I'm past that.

Now I'm stuck... I'm getting a Twig error from EasyAdminBundle.

request.CRITICAL: Uncaught PHP Exception Twig_Error_Runtime: "An exception has been thrown during the rendering of a template ("Could not parse property path "[entities][]". Unexpected token "[" at position 10")." at /base/data/home/apps/pxxx/staging.xxx/vendor/javiereguiluz/easyadmin-bundle/src/Resources/views/default/list.html.twig line 1 {"exception":"[object] (Twig_Error_Runtime(code: 0): An exception has been thrown during the rendering of a template ("Could not parse property path "[entities][]". Unexpected token "[" at position 10"). at /base/data/home/apps/pxxx/staging.xxx/vendor/javiereguiluz/easyadmin-bundle/src/Resources/views/default/list.html.twig:1, Symfony\Component\PropertyAccess\Exception\InvalidPropertyPathException(code: 0): Could not parse property path "[entities][]". Unexpected token "[" at position 10 at /base/data/home/apps/p~xxx/staging.xxx/vendor/symfony/symfony/src/Symfony/Component/PropertyAccess/PropertyPath.php:116)"} []

I'm certainly no guru with Symfony or Twig but there appears to be something amiss with Twig in this setup. I've been poking around but haven't been able to make any headway. Looking for some guidance.

[weaverryan]

Hey there!

Could you push your test project to GitHub and samhare it with us? It’s certainly possible there are issues with a read only cache directory in some pieces, especially third-party libraries (FYI stuff from JMS is entirely independent of Symfony, while I’d love for it to work correctly, it needs to be handled on their repo).

If you have a test project on GitHub, some of these things could be investigated :).

Cheers!

[pdugas]

Working on getting an example going. What I have now is on an internal GitLab host and contains some proprietary stuff. I'm working today on a fork of the starter-project that demonstrates my issues. Standby...

[pdugas]

Ended up starting a new project rather than fork that one so I could start as clean as possible.

See pdugas/appengine-starter. The Current Status section in the README explains where things currently stand. I've not yet added Doctrine and JMS Serializer and other stuff to the effort yet thinking that I'd like to see if we can figure out the first Twig issue (cannot call csrf_token()) in case the solution addresses the others.

[theofidry]

@pdugas regardless of that possible issue you are facing IIRC Google allows you to ship a machine with your own container in which case you could have complete control of what's going on instead of relying on their machines with a deprecated version of PHP.

I would strongly recommend that even more in the case of Google which doesn't have a good track of records of being PHP friendly, they don't use it internally at all. They had enough different languages at a point and there was nothing PHP would bring over what was already being used so they banned it. The few PHP contributions you see from Google are from employees doing that on their spare time, they are not backed by actual Google products.

[pdugas]

Yes @theofidry, quite correct. Their "Flexible PHP" environment can use current PHP, allows filesystem access, and removes a number of other limitations. However, it also dramatically increases the cost for the service since it doesn't scale down to zero so during development, it can cost about $40/month. Using the more limited Standard Environment cost $0 unless it starts really getting used.

[goetas]

Same issue as with JMS Serializer. It's using Doctrine's FileCache class for it's cached config and it's throwing when the cache directory isn't writable. Another patch and I'm past that.

Regarding the JMS serializer, the v2.3.0 release introduced cache warm up feature (schmittjoh/JMSSerializerBundle#615) that should solve the issue

[pdugas]

Yes @goetas, thanks for that. Works fine.

[pdugas]

I've upgraded things to 3.4.1 and the error has changed. Now it can't load Symfony\Component\Form\FormRenderer instead of TwigRenderer. Feels like it's still the same root cause.

[pdugas]

Digging into the extended version of Twig\Environment and it looks like the issue it's addressing is that the version of PHP is part of the hash for cached templates so they've overridden the baseclass to remove that. The version of PHP in prod is almost certainly different that on the local machine where the cache warmup is happening. However, when I warmup the prod cache, I don't get var/cache/prod/twig at all. I do in dev. Makes me think something else I've changed from the original starter-project is wrong.

[weaverryan]

@bshaffer (who works at Google) is aware of this, and even has/had a PR on Twig to fix it (but I think it was closed)

[pdugas]

Been looking and can't find that PR. Any chance someone could point me toward it?

Is it twigphp/Twig#2471? If so, this has been worked around by the extended Twig/Environment class which removed the PHP version numbers from the hashing logic.

[xabbuh]

What is the state here? I am not sure what actually would need to be fixed here.

[pdugas]

There appears to be no interest. I've been unable to get the example app to work up on GAE's less expensive Standard PHP environment. Could be adjusted to work on the Flexible PHP environment but that ends up costing $40/month.

[mvrhov]

Choosing different hosting provider is usually a correct approach.

[pdugas]

Sure, no argument but there are some attractive features of GAE and Amazon's equivalent that would be useful for many of us. It handles scaling, memcache, database, etc. The standard environment spins down to $0 when not in use too. I personally would like to use it since I'm already using Google's platform for other services. I do see others choosing other hosts though. My $0.02

[fabpot]

I would be more than happy to merge pull requests that makes GAE work better for Symfony. It would be fantastic. But as I'm not using GAE, it should come from the community. We did a lot of work to make the cache read-only and consistent, so newer Symfony versions should work better out of the box. Having a special starter is probably not going to work in the long run except if it is actively maintained.

[pdugas]

Good point, I should restart this with SF4. Will see if I can make time to do so.

I recommend closing this issue.