I would like to develop a website for a company with a lot of different functions. I decided to use the Symfony 2.0 framework for the first time and started reading the documentation and also a video tutorial.
After a week reading the documentation I still have some general questions unanswered. It would be great if you could help me with them:
Which client OS do you recommend to work with Symfony2? Windows doesn't seam appropriate.
Can I develop the whole website on a local Apache server and than upload the files to a regular webhosting server and use it?
I bought a regular web hosting (www.cyon.ch) is this recommended? I can't use any console on it.
I'm really confused and I'm sure I'm asking quite some stupid questions. It would be great if you can help me understand better how Symfony2 works.
Thanks in advance!
Windows is OK, as long as you have PHP and MySQL. There are several package that can do the job.
You can. In fact you should. Common workflow is develop on localhost and test on test server, and then move to production server. You should use a SCM like git.
Theoretically you can. But you won't have access to many console features that are really useful, like updating the database schema, flushing cache, download dependecies automatically, etc. I know some people doing this (copying everything with vendors), that's heavy and insecure.
When it takes half a day to update the app, you don't hurry when you have to apply security patch. Unlike Wordpress or Drupal, Symfony has no other 'easy way' to update vendors and third party modules than command line interface. So it is really not a good idea. You can find a lot of VPS with full ssh access, that cost less than 10$ months.
I work on windows just fine. For wamp server, use Easyphp. Everything is easy to configure and most important; cli and apache users use same php.ini
Yes, but it is bad. You should use either svn or git. I find svn easier to use and both of them have UI variants: TortoiseSVN and TortoiseGIT.
No. You need console access and php5.3 minimum.
Related
Good day Experts,
I need to implement subversion on our WordPress websites.
I have never worked with Subversion before. I have however read-up on it and understand the principles.
We have a Development environment consisting of only one server hosting multiple (about 10) WordPress websites. Then we have a Production Environment that consist of 2 servers, one hosting only the WordPress Files, and the other hosting the WordPress databases. The production Environment is the live environment and we want to completely stray away from making any changes directly on here before it has not been tested via the Development Environment.
I need to implement subversion to basically track the changes on the development environment (obviously with functionality to roll back to a previous version if something goes wrong) and then to make it quick and easy for the team to publish to the Production Environment without having to use FTP – may I add that the sites is about 6GB in size on average. Also as it is the design and development team that is going to work with this it would be nice to have a GUI to work from. (I think they are going to give me grey hair if I need to train them on using console commands.)
Our hosting provider supports SVN and Git. I only have been looking at Git and like I said I understand the principles.
But what I cannot get my head around is how to implement this in our environment. Keeping in mind that this is WordPress Websites and that the Production Environment consist of 2 different servers. Like how do I push the database over to the production environment to a different server than the files?
Sorry if this is maybe stupid questions, but like I said I have never worked with any form of subversion before.
If anyone can send me in the right direction on how I could implement this. It would really be much appreciated.
Thanks in advance.
I'm working with Symfony2.3.4 and PHP 5.6.3.
I'm going to deploy a project I just finished and I need to do it "by hand", it means copying the project source code manually onto the production server in a company because I can't use any tool for it or anything of the like.
I've never done this before and for what I've googled so far it's hell. But what worries me the most is the matter of protecting my code once it's in the server, i.e.: no one sniffing around, editing, copying, plagiarizing it, etc.
I don't know if I'm making any sense or if this is an obvious question, I really really have zero experience deploying web apps so be gentle.
Anyone who has administrative access to the server can read and copy your code, including of course the server administrators (i.e. the hosting provider staff).
Of course any hosting provider in the world can do that and AFAIK it's never been a problem, because they usually are professional and don't do it.
The only solution I can think of is to setup a VPS where you have the only SSH access, but of course that means you have to setup the whole web server yourself... and that's even more complicated than simply deploying your code.
To answer your question, and if you really (really!) want that, you can checkout this SO question: Is there a code obfuscator for PHP?
But you shouldn't do that! As said, don't be scared by hosting providers, or setup your own server. :)
I develop on a local machine a Wordpress site and I'm now looking for a mechanism to deploy it easy and fast. I'm thinking about a DEV environment (located on my local machine), a STAGING environment (a subdomain on the client page, maybe staging.example.com) and of course a LIVE environment (example.com)!
My current workaround:
As I work with Aptana I'm able to sync my changed files with the deploy mechanism the IDE provides. Exporting my local database, finding/replacing the permalinks and importing the whole thing - finish! To deploy live, I have to replace all staging files with the live files.
This should be easier! Is there anyone out there, having a better workflow?
I'm open and really excited about your ideas!
Thanks a lot
greetings
Yep, it's frustrating and completely insane that Wordpress requires this process because they put absolute urls in the database. I develop in a similar fashion using multiple staging sites for qa and client review. After my first deployment with Wordpress I almost gave up on the platform entirely. All of the solutions recommended by core developers and others simply didn't work.
So I wrote a plugin: http://wordpress.org/extend/plugins/root-relative-urls/
that fixes the problem. With this plugin you don't need to do a search & replace on your content. No hosts file hacks, or dns tricks. With my plugin you can access the site via IP address or Computername or any type of forwarded host. And since it converts urls to root relative before they enter the database, you won't have to worry about them working between the different domain formats. And since they don't hard-code the scheme (http/s) in the url you won't have to worry about the 520 or so bugs that were reported in the wordpress trac database if you use SSL.
It's a staple for any wordpress project I work on these days. And I have written a couple other plugins to deal with idiosyncrasies that exist in the platform that you can check out here: http://wordpress.org/extend/plugins/profile/marcuspope
Hope that answers your problem.
I use Capistrano https://github.com/capistrano/capistrano/wiki/ for all my deployment needs and it is really good solution. You can simply script anything and it just works.
It could work for your deployment scheme too.
I also use Capistrano for both WordPress and Drupal deployments. I typically install modules locally for testing then push to test and production environments. For uploads, etc. I add custom tasks to manage syncing files stored in scm and those that are not. Here is a simple guide I put together.
http://www.celerify.com/deploy-wordpress-drupal-using-capistrano
We are a software development company and are using Wordpress for static portion of the web site. Naturally, all our workflow is built around version control: multiple developers -> continious integration -> staging -> deployment.
Our challenge with integrating Wordpress into our workflow is that its database is stuck like a bone in the throat: you cannot put it into the version control, easily roll back, promote from staging to production etc.
I am wondering what people do in similar situations? I would like to find a way to integrate WP into the development workflow and not the other way around :-)
Clarification we want to "develop" and test pages on the staging system and when ready then move them over to the production as part of the version upgrade process. We don't want to do full replication of the staging database to production.
That's a common question and one that I've worked on tackling. I've written some code to address these issues albeit the code's not ready for distribution. Basically the idea is to create scripts to import the content and then version control the scripts. (Actually my approach uses a custom import/export format designed to be easy to hand-modify, but the idea is similar.)
Anyway, there are some related questions over on StackOverflow's sister site WordPress Answers:
Questions tagged with the term [staging]
Questions tagged with the term [deploy]
UPDATE
Per the clarification, this would probably be helpful too:
Is there any way to draft a revision of a published page or post? What workarounds have you used?
Hope this helps.
-Mike
I've just hit the same problem. For now we are using MySQL dump files to export/import database content, but it gets ugly with several people working on the database changes.
Since the team that works on the project is all internal and consists of just a few people, I'm thinking into the direction of locking the database dump file in VCS. Subversion had this functionality built-in, but we are using git, which, I think, is conceptually opposite of any kind of locking.
Probably we'll have a workaround script with pre-commit hook to check for the existence of a lock file next to the dump. The person who committed the lock file will be the only one allowed to commit the dump. Once he finishes the work, he will need to commit the removal of the lock file.
It sounds ugly, I know. But I've thought about it for a while and don't see an elegant solution yet.
If you're only using WordPress for static content, then any tool/methodology for version controlling databases should work - for example, work the mysql command line tools into your CI and deployment routines.
I really like drupal somehow. But what disturbs me most is that i can't figure out a clear way of deployment. Drupal stores a lot of stuff inside the database (views, cck, workflow, trigger etc) that needs to be updated.
I've seen some modules that could be used for this task (eg features) and I'm not sure if they are sufficient. Yet they are only for drupal6 and i currently have to work on a drupal5 site where updating is not yet an option.
Any ideas?
This is a weakness. Drupal doesn't have the developer tools built in that make development and deployment easy like Rails does (for example). One problem is Drupal isn't aware of it's environment natively. Secondly, there are too many different methods and modules that require special care. It can get very confusing. But things are getting better with drush and drush make.
I'm assuming here that you have a development environment on your local machine and a live or staging server you upload to.
The first thing you have to do is work out how to get your database fixture and your code to and from your server to your development environment very quickly. You need to make this proceedure as painless as possible so you can keep different versions of your site in sync without much effort. This will mean you will hopefully be able to manage less change every time you deploy. Hopefully...
Moving the database around isn't too hard. You could use phpMyadmin or mysqldump but the backup migrate module is my favorite tool.
To upload code from your local repository or site can be done in a few ways. If you use a version control system like git, you can commit on your local machine and check out again on the staging server. There are also special deployment tools like capistrano you should take a look at. (if you know this stuff already it may benefit others to read). If you're using FTP you should probably try something different.
If you're working with a site that is still in production, you can afford to make small incremental changes to your local site, then repeat on the live site and down load the new version of the database when your changes are in place. This does mean you double handle the database but can be a safe way of doing things. It keeps both your database closer to each other and minimises risk.
You can also export views backup to your server in either your code or importing them into your live site. There is a hack to get around deploying cck changes here: http://www.tinpixel.com/node/53 it works OK but cannot truly manage changes like rollbacks. (Respect to the guy who wrote that)
You can also use hook_updateN to capture changes and then run update.php to apply them. I worked on a d5 site with dozens of developers and this was the only way to keep things moving forward. This may be a good option if your site is live or if you need all database schema changes captured in a version control system (so you can roll back).
Also: Take a look at drush and drush make. These tools can be of great benefit. I can't remember how much support is for d5.
One final method of dealing with this is not to use cck or views (and use hook updates). But this is really only suitable for enterprise sites where you have big developer resources. This may seem like a strange suggestion but it can negate this whole problem completely.
Sorry I could not give you a clear answer. This is because one does not exist yet. You'll end up finding your own rhythm once you get into. Just keep backups of your database if you can roll back to them easy enough.