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
Related
I want to deploy a new Symfony 4 project (the symfony-demo) from local to a IIS web server. The project should stay in its own sub directory. The IIS webroot is two levels higher. When I go to public/index.php of my project (which is releative to the webroot in /sf/symfony-demo/), the templates are not shown correctly, since the server does not find the correct JavaScript directory in build/js/...), see screenshot
I call http://192.168.1.203/sf/symfony-demo/public/index.php, but fails to load from http://192.168.1.203/build/manifest.js.
On the server, I can not set the webroot or create virtual directores. Also, I have no command line. I need to do it via configuration in symfony or a correct write/rewrite rule in web.config file.
How can I set the sf- project root directory relative to the IIS webroot, in my case to /sf/symfony-demo/public ?
Can somebody provide a rewrite rule in web.config in /sf/symfony-demo/ or in /sf/symfony-demo/public? Or do I need to set the directory somewhere (prefix? asset?) in my project configuration files (e.g. \sf\symfony-demo\config\packages\framework.yml)?
Edit
I got it working somehow, there is a similar discussion and a solution for a symfony 2 project:
Symfony 2 project in nested directory
by adding in symfony-demo\config\packages\framework.yaml a line at assets :
base_urls:
- 'http://192.168.1.203/sf/symfony-demo/public/'
But somehow this looks strange for me to set the path this way. Setting here
base_path: '/sf/symfony-demo/public/'
does not work. I would expect to set the (relative) path explicitly somewhere, not a url. But where?
Also, setting extra.symfony-public-dir in composer.json like in
http://symfony.com/doc/current/configuration/override_dir_structure.html
does not work.
Regarding the rewrite rules:
Yes I read the doc, but I found nothing for web.config on iis for symfony on
https://symfony.com/doc/current/setup/web_server_configuration.html.
But I found a iis web.config for silex
[https://silex.symfony.com/doc/2.0/web_servers.html .
It looks like the web.config is not the real problem here.
Thank you for taking the time to read this. d.
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.
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.
I have to move an existing Drupal site from one server to another. I've done so by doing a mysql database export/import and copying over the files to the new server. On the new system, the root page comes up fine but if I try to go to any deeper directory levels I get a 404 Not Found Error.
so drupal.newserver.com -> works fine
but drupal.newserver.com/user -> gives me a 404 and happens,same for all subdirectories
Is there something that I'm missing that is part of a drupal export? Could it be related to the structure of the /sites directory which is under the webserver's docroot?- which has a folder named after the old server (ie drupal.oldserver.com but not drupal.newserver.com? Also, I noticed that there are _htaccess files and .hta files but not .htaccess files in the site files that I've copied over.
Sorry if I'm asking a bleedingly obvious question - I'm very new to Drupal. Thank you!
Check whether the clean url is enabled in your web server. To check try this:
drupal.newserver.com/?q=user.
Just to let anyone who might come across via a google search - I was able to get this to work . It turns out that while mod_rewrite was enabled, what I had to do was to enable the AllowOverride directive for the web directory in httpd.conf to be set to ‘All’. If it’s not set to this, the server won’t respect the .htaccess rules you put into the drupal directory. It’s been a while since I’ve worked with apache config files so it took a while to finally piece it together. The main breakthrough came when I realized that if I turned off clean-urls then the links worked but looked ugly and then was able to research clean_url.
I'm using multisite to host my client sites.
During development stage, I use subdomain to host the staging site, e.g. client1.mydomain.com.
And here's how it look under the SITES folder:
/sites/client1.mydomain.com
When the site is completed and ready to go live, I created another folder for the actual domain, e.g. client1.com.
Hence:
/sites/client1.com
Next, I created symlinks under client1.com for FILES and SETTINGS.PHP that points to the subdomain
i.e.
/sites/client1.com/settings.php --> /sites/client1.mydomain.com/settings.php
/sites/client1.com/files --> /sites/client1.mydomain.com/files
Finally, to prevent Google from indexing both the subdomain and actual domain, I created the rule in .htaccess to rewrite client1.mydomain.com to client1.com, therefore, should anyone try to access the subdomain, he will be redirected to the actual domain.
This above arrangement works perfectly fine. But I somehow feel there is a better way to achieve the above in much simplified manner. Please feel free to share your views and all advice is much appreciated.
Since it seems you want to reuse the files/ directory and settings.php from your development domain, I'd suggest using the default/ directory + symlinks to achieve your goals.
ie, during development
sites/default/settings.php
sites/default/files/
sites/client1.domain.com -> sites/default (symbolic link)
once you're ready to switch over to their domain:
sites/client1.com -> sites/default
You can then remove client1.domain.com from your virtual host (or continue with your rewrite, etc...).
It will accomplish the same as your method, but you get the added "protection" of all requests going to default in case you add an additional domain at a later date as an alias (for example).
If you're simply sharing core and module files between the sites, you can use a different symlink layout.
In my setup I have all of the shared files in a common, non-web-accessible directory:
/var/www/drupal
/var/www/drupal/sites/all/modules
then for each deployment, common files and folders are symlinked to those files.
/var/www/client1/public_html/index.php -> /var/www/drupal/index.php
/var/www/client1/public_html/includes -> /var/www/drupal/includes
...
/var/www/client1/public_html/sites/all -> /var/www/drupal/sites/all
Then you can place the site's settings.php and any modules or themes for only that site in the default sites directory
/var/www/client1/public_html/sites/default
This layout also offers you the flexibility to override any common files as necessary, such as .htaccess.
To move from staging to production, you will just have to modify your virtual-host configuration from the staging to production domain name.
If you don't like a ton of symlinks, another option is using the Aliased Multi-Site Support patch:
http://drupal.org/node/231298#comment-1420180
This will allow you to specify in configuration that any requests for client1.domain.com should actually use /sites/client1.com/ instead of /sites/client1.domain.com/.
Then when you move to production, you can just remove the configuration setting (though it doesn't hurt anything if you don't).
This feature is part of Drupal 7, but as a new feature won't be added to Drupal 6. More good news is that you won't even need to use it in D7 just for file paths, since instead of storing the full path to files in the database, they use a schema such as public:// or private:// which Drupal then maps to the correct file system path, allowing multiple storage types/locations with much better portability.