|
|
|
| Re: A todo list to check if your application is finished ! [message #81964 is a reply to message #79445 ] |
Thu, 16 July 2009 10:48   |
 gouiggou
Messages: 44
Registered: October 2005
Location: Paris |
Member |
|
|
Just a little typo :
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<php echo $sf_user->getCulture() ?>"↵
lang="<php echo $sf_user->getCulture() ?>">
become :
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $sf_user->getCulture() ?>"↵
lang="<?php echo $sf_user->getCulture() ?>">
Jérôme M.
|
|
|
|
| Re: A todo list to check if your application is finished ! [message #81968 is a reply to message #79445 ] |
Thu, 16 July 2009 11:00 |
gouiggou
Messages: 44
Registered: October 2005
Location: Paris |
Member |
|
|
And a little optimisation for apache.
Avoid htaccess. Put it into virtual host configuration, and then tell apache to not read htaccess on each request !
<VirtualHost *:80>
...
<Directory "/monprojet/web">
Options FollowSymLinks ExecCGI
AllowOverride None
Allow from All
RewriteEngine On
# uncomment the following line, if you are having trouble
# getting no_script_name to work
#RewriteBase /
# we skip all files with .something
#RewriteCond %{REQUEST_URI} \..+$
#RewriteCond %{REQUEST_URI} !\.html$
#RewriteRule .* - [L]
# we check if the .html version is here (caching)
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
# no, so we redirect to our front web controller
RewriteRule ^(.*)$ index.php [QSA,L]
</Directory>
Alias /sf /var/www/common/symfony-1.2/data/web/sf
<Directory "/var/www/common/symfony-1.2/data/web/sf">
AllowOverride None
Allow from All
</Directory>
...
</VirtualHost>
[Updated on: Thu, 16 July 2009 11:10]
Jérôme M.
|
|
|
| Re: A todo list to check if your application is finished ! [message #81970 is a reply to message #79445 ] |
Thu, 16 July 2009 11:23 |
 |
El Riiico
Messages: 40
Registered: February 2007
Location: Paris |
Member |
|
|
The tip doesn't work on shared hosting environment, but it's definitively interesting on dedicated servers.
I'll test it and add it to the site with the "performance" tag.
As I'm very busy these days, it probably won't be before next week.
I may also add a small popup with the contributors list. Can I add your name to it, Jérôme Macias?
[Updated on: Thu, 16 July 2009 11:24]
http://symfony-check.org
|
|
|
| Re: A todo list to check if your application is finished ! [message #81988 is a reply to message #79445 ] |
Thu, 16 July 2009 14:47 |
gouiggou
Messages: 44
Registered: October 2005
Location: Paris |
Member |
|
|
Eric, you can add my name.
Jérôme M.
|
|
|
|
|
|
|
| Re: A todo list to check if your application is finished ! [message #86497 is a reply to message #86493 ] |
Mon, 12 October 2009 09:22 |
SonicM
Messages: 12
Registered: December 2006
Location: Germany |
Junior Member |
|
|
Deployment is the first step. But in most cases you have to update the site, be it bugs or new wishes. In this case I use svn update and delete then the *_dev.php files. But the problem are the files in the subdirectory ".svn". You can see all the files in the directory and if the webserver deliver .svn-base compiled, you can see anything like that: http://www.gutefrage.net/.svn/text-base/error.php.svn-base but if not, the file is readable.
I don´t think that it is a very big security problem, but everyone has the possibility to see what your directory structure is and which files you use. By the way, if you use svn to deliver the updated files to the webserver (svn update) the *_dev.php needn´t to be there to be read. see this link http://www.gutefrage.net/.svn/text-base/frontend_dev.php.svn -base
In this case the file is executed, so that none could read the content, but in other cases you can read it.
Like I said, it is not such a big security problem, but it is worth to remark it.
How do other symfony users update their projects? I mean debugging or adding new wishes for the customer? With svn export?
|
|
|
| Re: A todo list to check if your application is finished ! [message #86499 is a reply to message #86497 ] |
Mon, 12 October 2009 09:45 |
|
El Riiico
Messages: 40
Registered: February 2007
Location: Paris |
Member |
|
|
I insist, symfony deployment system uses Rsync, you could (should ?) use project:deploy not only for the initial commit, but also to deploy the modifications.
Here is a quote from the related sf documentation :
| Quote: |
With incremental transfer, only the modified data will be sent. If a file didn't change, it won't be sent to the host. If a file changed only partially, just the differential will be sent. The major advantage is that rsync synchronizations transfer only a small amount of data and are very fast.
|
You can check all the deployment options in your terminal :
php symfony h project:deploy
Of course you can use subversion for your deployments.
Subversion is a great powerful tool, but as using it for deployments doesn't follow symfony practices, so I won't add your advice to symfony-check, sorry 
http://symfony-check.org
|
|
|
|
| Re: A todo list to check if your application is finished ! [message #87346 is a reply to message #86889 ] |
Sun, 25 October 2009 13:35 |
|
Absolutely love the site - well done and well executed.
Going through it this morning in some details and found a few quick "typos".
- 'Customize the "Login Required" Page': About half-way down, there is a header that says "Display the error page to test it". I think that's just copied from the previous item - should be "Display the login page to test it". The next section. 'Customize the "Credentials Required" page' suffers from this same problem.
- Right below that, ordered list item #2, "preferencies" should be "preferences".
- 'Customize the "This Module is Unavailable" page' - First paragraph, "default/login" should be "default/disabled"
If I find any more, I'll post them. The site has been a great resource for us - glad to see everyone is pitching in.
Also, someone mentioned putting "checklist" in the meta tags. I thought you had put it in there, but I don't see it now. I'd throw "checklist" in both the meta tags and the title tag - when I google it, I get a blog about it.
Thanks!
[Updated on: Sun, 25 October 2009 13:40]
Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
|
|
|
| Re: A todo list to check if your application is finished ! [message #87350 is a reply to message #87346 ] |
Sun, 25 October 2009 14:58 |
|
Hey guys-
A few other tiny details:
- 'Delete "/backend.php/" from your uri'
- "Personnaly" should be "Personally"
- 'Optimize Apache: avoid .htaccess'
- "dealed" in first paragraph isn't a word - not sure what it should be.
- "can't be cached apache" should be "can't be cached by apache"
- "the server has to scann the" should be "the server has to scan the"
- "If you moving the .htaccess rules to your virtual host configuration file, the rules will be put in cache and apache performances will be improved." should be
"If you move the .htaccess rules to your virtual host configuration file, the rules will be cached and apache performance will improve."
- "apache configuration files on virtual host environments" should be "apache configuration files on shared hosts"
- Hmm, not sure about this: "Most often, you'll find the virtual host configurations in the bottom of the httpd.conf, but sometimes, they are moved in some vhosts.conf file."
Apache 2 places vhosts in a sites-available directory inside /etc/apache2
- "Unless If you added extra rules in it, the file is now useless." should be "Unless you added extra rules in it, the file is now useless."
- "but it could be on your configuration." - not sure what this means, does it mean that it could be in your executable "path"?
- "Your project really should have at least a README file where this kind to modifications are reported."
should be
"Your project really should have at least one README file where these kinds of modifications are reported."
- the final 2 paragraphs have pretty sloppy english
Thanks! As I said before, it's great, which is the only reason I care about the wording!
Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: A todo list to check if your application is finished ! [message #97132 is a reply to message #97130 ] |
Sun, 11 April 2010 16:58 |
Ninj
Messages: 6
Registered: March 2008
Location: France |
Junior Member |
|
|
I may have got it wrong, but when a file contains server-specific data, it should not be versionned. This could cause an svn-update on the server to erase connection parameter for example.
That makes me think that it's a good practice to completely separate and isolate server-specific data from the shared information.
Typically, databases.yml holds both server-specific parameters and project-wide data, which leads to this situation where a file that cannot be versionned needs to be updated by hand in case of strucutral changes.
-= Ninj =-
|
|
|
|
| Re: A todo list to check if your application is finished ! [message #97138 is a reply to message #97132 ] |
Sun, 11 April 2010 17:57 |
tinynumbers
Messages: 7
Registered: January 2010 |
Junior Member |
|
|
| Ninj wrote on Sun, 11 April 2010 09:58 |
I may have got it wrong, but when a file contains server-specific data, it should not be versionned. This could cause an svn-update on the server to erase connection parameter for example.
That makes me think that it's a good practice to completely separate and isolate server-specific data from the shared information.
Typically, databases.yml holds both server-specific parameters and project-wide data, which leads to this situation where a file that cannot be versionned needs to be updated by hand in case of strucutral changes.
|
But my understanding (and the way I'm working, using Symfony 1.4) is that databases.yml contains different configuration sections for the different environments (dev, test, prod, etc) all within the same file, but under different environment names, so there's no chance that database configuration changes to one environment will mess up a different environment.
That's why I wondered about this.
I currently keep everything in SVN, and when doing a deployment on the production server, it just consists of three commands:
svn update
./symfony project:clear-controllers
./symfony cc
Works fine for me.
|
|
|
| Re: A todo list to check if your application is finished ! [message #97140 is a reply to message #79445 ] |
Sun, 11 April 2010 18:54 |
Ninj
Messages: 6
Registered: March 2008
Location: France |
Junior Member |
|
|
Ok, I understand that you're using environments to hold parameters of different servers (your local server in "dev", you remote production server in "prod"...)
Well, that's not really the purpose of environments. They exists so that you can easily manage a dev and a prod version on a server, for instance. But I guess there's nothing wrong in doing as you do.
In your case (databases.yml holds parameters for both the prod server and your local install), you can version it.
Hope that helped!
-= Ninj =-
|
|
|
|
| Re: A todo list to check if your application is finished ! [message #97143 is a reply to message #97141 ] |
Sun, 11 April 2010 19:17 |
Ninj
Messages: 6
Registered: March 2008
Location: France |
Junior Member |
|
|
Exactly, you got it
With the exception that, personally, I mostly see cases where that shouldn't be. Environments are here to be switched, i would say almost dynamically. You test your pages in DEV, and then to be sure it works, you use the PROD environment. And when you encounter an error in PROD, you go back to DEV to get details.
The principle behind environments are obvious: you shouldn't play with prod database when doing your tests And tests are to be ran both locally and then on the remote server after svn update. You're never sure what works on your computer will work the same on a hosted server. That's where you see that you need a DEV environment in both your local and the remote versions.
Think of that: a user reports to you an error on your prod site. The first thing to do is to try to reproduce it. Then you switch to the DEV mode on your server (thus changing the DB used) and try to get more information. When you know what's happening, you come back on your computer, make changes, and commit it. On the server you update, test to see weither the bug is effectively gone, and you're done!
Well, you could answer to me that, merging your approach and the usual one, a solution would be to create more environments : DEV & PROD for remote server, and LDEV & LPROD for local developpement. Why not? But that's up to you!
-= Ninj =-
|
|
|
|
Members
Search
FAQ
Register
Login
Home
