Symfony 4 front controller - symfony

Symfony 4 resigns on app.php and app_dev.php front controllers. Now it will be only one index.php. We can manipulate dev and prod environment in .env file. Please tell me is it only one way to change environment? I can't do that from the browser (as it was previous app and app_dev files)?

You control what is in the index.php file, so you can arrange to include a different env file according to the rules that you decide.
For example, you can set a variable in the Apache vhost or Nginx FastCgi configuration, based on the URL you are visiting from - such as APP_ENV=/home/myname/app-name/dev.env or on a live server: APP_ENV=/etc/app-name.prod.env set as you like, or you could list both of them in the index.php and choose which one from there - although taking the option out of the code and setting it in a server configuration would probably be safer in the long term.

Related

Symfony: generate prod url in dev environment

I am wondering if it is possible to choose environment when generating urls with the symfony routing component.
In a controller
$this->generateUrl($route, $params);
generates / in prod envrionment and /app_dev.php in dev.
There doesn't seem to be a parameter for the environment so that you could generate productive urls in dev environment. I just don't want to use something like str_replace all the time.
This would be great:
$this->generateUrl($route, $params, 'prod');
For your understanding, I am working on a cms project where I have to match uris against the database where they are stored without app_dev.php.
Any ideas?
More of a hack than a proper solution, you can set the Context's $baseUrl to be '' (as it would in production environment) before calling the generateUrl and reset-ting it back after the call. The RequestContext->getBaseUrl is consulted each time the complete Url is built.
In our case, we had to build Urls without the app_dev or app.php because our frontend was an AngularJS based application matching the URLs. In this case, since we dint want the app_dev or app.php at all, we created an EventListener that does a
$this->router->getContext()->setBaseUrl('');
Router component workflow doesn't include any of app.php or app_dev.php files. It only works with the pattern which comes after php file in the query string, whatever that file is.
So you're not able to do that. You only can use .htaccess file config to manage what file will be used as a default one, no more.

Symfony2 VirtualHost

Symfony2 has by default 2 environments. Dev and production.
What's you default vhost config and why? Do you point directly to app_dev.php or do you rewrite the .htaccess to redirect to it?
Do you have 2 vhosts or did you rewrite the entry point (index) to read a config to easily change environments?
On production, I'll just have one entry point and point directly to it and leave the .htaccess there.
Please post your approach since Symfony2 doesn't tell me anythign about this. It only says that we should point our vhost to the web dir.
Maybe you always add the app_dev.php part to the url? What are you doing. Tell me your experience.
I did read the other stuff here about this.
Follow Sf2 recommandations and let your vhost point to web directory. The provided .htaccess file will automatically redirect to app.php if no index is specified, and you type app_dev.php to access dev environment...
If you want to install a vhost dedicated to dev environment, make it rewrite URL to point on app_dev.php.

BaseURL in symfony 2

I have an application in Symfony 2. It is deployed on IIS server.
The problem is, I need to get it work on multiple URLs:
www.somedomain.com/myapp/app.php - for production
www.somedomain.com/myappdev/app.php - for testing
myapp.localhost/app.php - for development
How can I do that? I need to correctly generate URL for resources(js, css files). Also after deployment, generated URL are missing the /myapp/ (/myappdev/) segment.
You can prefix your routes with /myappdev by adding it to your app/config/routing.yml file under the prefix key.
If you use relative URLs for the resources then you won't have a problem with the domain it's on and it will work anywhere you put it.

Symfony 2 - What to do before going live?

Until now, I've been writing Symfony 2 applications and never was responsible for launches. So I've only called Smyfony 2 over app_dev.php and only used a development configuration. Now I have to take care of a Symfony 2 launch, what do consider before going live?
Where can I set different configurations (DB connection, etc.) for different environments and how can I invoke them?
How can I make sure the application can't be called via app_dev.php on the live server?
And of cure any other tips on what to keep a eye on while pushing a Symfony 2 application live.
First of all, we have documented this: http://symfony.com/doc/current/cookbook/deployment-tools.html That article just answers the first and third question, the answer on the second question:
How can I make sure the application can't be called via app_dev.php on the live server?
You should point the root directory of you website to the web directory. For instance, if you site lives in:
mysite.com/
public_html/
... your site files/directories
You should make it like this:
mysite.com/
app/
...
src/
...
vendor/
...
public_html/ <--- this is the old web directory
...
app.php
You can read how to change the web directory in public_html into the documentation too: http://symfony.com/doc/current/cookbook/configuration/override_dir_structure.html
The reason to do this is to secure all your application code. The user just can't access all app/., vendor/. and src/. files and so it can't read the configuration and can't read the parameters.
At last, you can change app.php to index.php to get urls like mysite.com/app.php/blog/foobar. But it is better to create a simple HTACCESS mod_rewrite rule to send all requests to app.php, so you can access the page with mysite.com/blog/foobar.
.htaccess in the root:
RewriteEngine On
RewriteBase /
RewriteRule ^(.*?)$ app.php$1
Where can I set different configurations (DB connection, etc.) for different environments and how can I invoke them?
if you haven't changed too much your project, your config files are under app/config
How can I make sure the application can't be called via app_dev.php on the live server?
Same, if you haven't change to much the project, the only thing you need to care about is make sure your web server runs the website from /web (the .htaccess does the rest)
And of cure any other tips on what to keep a eye on while pushing a Symfony 2 application live.
You can keep an eye on the log files in app/logs

Drupal base_url incorrectly writing extra subdomain

We have a basic drupal multi-site installation on a RHEL (RedHat) server.
For some reason when viewing the site, the asset URLs (CSS/JS) all point to the wrong subdomain.
Our site URL: http://drupal.sandbox.domain.com the drupal index page loads up with asset URLs being written as: http://drupal.sandbox.sandbox.domain.com.
Why would drupal add in the extra .sandbox subdomain?
The .htaccess file has been left as the default, also attempted to set RewriteBase to /, but there was no change. The sites/default/settings.php file has the base_url set to: $base_url = 'http://drupal.sandbox.domain.com' but Drupal is overwriting this somewhere. Setting the $base_url to the IP of the server causes the assets to be linked to the correct location (using the IP rather than the actual domain), but this is not ideal.
I've tested using the same configuration on an Ubuntu Server without any problems. I'm not sure exactly how to track down the cause of this problem.
EDIT: It seems that the server is resolving the domain and immediately overwrites the variable containing a string of the URL.
e.g.:
$base_url = 'http://drupal.a.domain.com'
die($base_url); // shows: http://drupal.sandbox.a.domain.com
This is not a Drupal-specific problem. This can easily be checked by creating a standalone PHP page and using the same code to test. Being that the variable is overwritten immediately after it is set shows that PHP/Apache is the one doing the overwriting.
It is possible for Apache to overwrite input and output. See: What would cause PHP variables to be rewritten by the server?

Resources