Front end in dev mode requires SuluAdminBundle

[Swader]

Not sure why this happens, but it happens only in dev mode. Prod mode in website.php works just fine.

I tried clearing the cache, with and without warmup.

[danrot]

Hm, that's really strange... It looks to me like it loads the routing file app/config/admin/routing.yml instead of app/config/website/routing.yml, can you check that?

[Swader]

I tried, but cannot figure out where to check this.

If it helps, here's a full screenshot of the situation with debug mode on: https://drive.google.com/file/d/0BxDWUuqQgPlqWE5Md1BSbTlsNjg/view?usp=sharing

[danrot]

Under which URL are you accessing the website? Are maybe the rewrites defined in web/.htaccess not applied?

[Swader]

I don't use .htaccess, I'm on Nginx. So admin works in both dev and prod, but website works only in prod mode.

[danrot]

Running out of ideas... I think it's easier if I try to get your vagrant box running, and try to figure it out on my own.

[Swader]

Agreed. Let me know if you get stuck, but the procedure should be simple enough.

[weaverryan]

@Swader do you have your project on a public github repo somewhere? Some configuration file is getting loaded incorrectly somewhere - for website.php, the app/config/website/routing.yml should be loaded - but it looks like app/config/admin/routing.yml is being loaded, but I don't see why (it doesn't happen for me locally).

I'd love to see a bit less configuration in general in Sulu - with the 2 kernels (which is a cool idea), it ends up that there are a lot of configuration files to look at. The MicroKernel in Symfony 2.8 (https://github.com/symfony/symfony/pull/15990) might help, as you could move a lot of the logic of which files to load into the kernels themselves as simple if statements, instead of having one config file load another one, etc (which works nicely, but becomes less clear when you start having many configuration files).

[Swader]

@weaverryan project is sulu-standard really, just tweaked for performance on Vagrant. Only difference is forcing dev mode in website.php rather than prod:

defined('SYMFONY_ENV') || define('SYMFONY_ENV', getenv('SYMFONY_ENV') ?: 'dev');

If you follow the procedure here you'll get to the same point, but really, it's the standard sulu install (all differences described in that post). There's also another aspect of this same bug (presumably) in #553

[danrot]

@weaverryan You are right... I am also struggling with this configuration from time to time... This micro kernel sounds interesting, but I couldn't find any documentation, is that still missing?

[Swader]

Update: problem avoided by forcing the SYMFONY_DEBUG constant to be false, or by simply passing false instead of the constant as the second param of WebsiteKernel. Unclear on why this happens.

Fix suggestion: make it easy to know what needs to be done to activate dev mode. This is something that's not exactly clear in other Symfony apps either - there's many constants and settings that can be tweaked, each depending one on the other. Perhaps a config value for "env-mode" would help. This confusion is why my way of activating dev mode (see my reply to @weaverryan above) did not work.

[weaverryan]

@Swader What do you think a better way might be? Perhaps a .env file that - at the very least - holds something like SYMFONY_ENV and SYMFONY_DEBUG flags?

Also, your post has some really interesting things to get the VM to run quickly, some things I hadn't thought of before. Also, there are a few parts where there may be a simpler way (e.g. the autoloading speedup) - I'm going to look at that and get back to you if that's ok. I tried yesterday, but conference internet kept the homestead-improved image out of my grasp :).

[danrot]

@Swader I've already written that to you, but I also put it in here so that every interested can see that. The problem was that there is an error when redefining the cache dir as explained in your article. Because of this both kernels used the same cache, which can't work.

[Swader]

Argh, totally ignored that cache context thing, will fix, thanks! But... does that mean prod mode doesn't use cache? I mean, why does it work in prod mode?

@weaverryan definitely, get back to me on that, looking to speed things up as much as possible. Also looking to streamline the vendorfix shell script into something more reusable across standard ZF / Symfony apps (those two FWs are the biggest IO offenders and suffer the most when using shared folders).

[danrot]

Actually it does, I think it depends on which kernel is called first. If the AdminKernel is called first it might also not be a problem, since it contains all the bundle the WebsiteKernel needs as well. But I suppose the behavior when two kernel share caches is always unpredictable.

[Swader]

Mmm, indeed.

Okay, altered the article and tested context specific cache, works like a charm now. Thanks @danrot for taking the time to take a look - I wish I hadn't applied that fix first, would have been easier to avoid all problems if I hadn't left that in. Closing this, and this also closes #553

[weaverryan]

@danrot No docs on the MicroKernel yet - it just got merged. But it'll be there in the next few weeks, before 2.8 gets released. I think it would be a pretty straightforward thing to implement, just to help the configuration loading be a bit more clear :)

[danrot]

@Swader I am happy to help :smiley:

@weaverryan I have created a separate issue for your MicroKernel suggestion: https://github.com/sulu-io/sulu/issues/1757