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.
Related
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.
I'm looking for a way to expose my test environment via a subdomain. Basically, I want to do the equivalent of the console --env "test" via URL. So someone accessing http://example.com will get the production site, but the external testers can go to http://test.example.com and will get the test environment, with test database and everything.
I thought just using SetEnv ENV "test" in my apache config would do the trick, but apparently it doesn't.
I'm fairly sure this is a pretty common thing, so can someone guide me to the solution?
It's really weird that you're trying to access test environment through url, but I'll guess you need some special configuration for WebTestCases.
You need to create app_test.php file in web directory, and boot kernel with 'test' environment parameter. To see how to do it, check out already available app.php and app_dev.php files.
After that, setup your apache to aim for app_test.php when you hit your url. Also have in mind that you will probably have to make apache ignore .htaccess because it will point it to app.php. You can do it using AllowOverride None.
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
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?
I'm working locally on a WordPress site for a client. The client keeps their install of wordpress in the server root, but because I have more than one client, I like to install everything in a client folder, like localhost/client. Normally it's a simple matter to add a rewrite rule to .htaccess, setting the rewrite base to be /client/. But today it's not working at all. Even if I put nonsense in the rewrite rule, the site works (which it should not, if the rewrite rules are in effect). The images references are still looking for root at localhost/, instead of localhost/client/, which means they are broken.
I looked into WordPress's documentation and found it has something called WP_rewrite, and there is a place to set parameters for it in wp-includes/rewrite.php). I set the root parameter to client/ but that doesn't seem to have any effect either.
One last thing: there is an .htaccess file in localhost/client/, and another one in localhost/client/wp/. I have them both set to RewriteBase = /client/, but I've tried just about every other sensible combination--no change.
So my question is: does WordPress do something else that would make the rewrite rules I set in .htaccess not work?
I'd recommend a small change to your local environment for a more flexible solution. Use virtual hosts. If you're running WAMP/MAMP, this tool is readily available to you. It allows you run a directory within your localhost as its own site, which you can access using a local-only URL of your choosing. I have my sites set up as sitename.local, for instance, so they all live in their own happy little ecosystem. Highly recommended.
Yes it does, you have to make some steps that will change entries in db before you move it to subfolder.
Here are detailed info:
http://codex.wordpress.org/Moving_WordPress#Moving_WordPress_Within_Your_Site
What you need to do:
copy everything as it is setup on your clients server i.e. in root folder
do the steps in above url, important are 4. & 5.; step 10. actually just go to permalink settings and click on "Save" button (or "Update" I do not remember how it says)
Now you can work :)
Are you modifying only theme or what?