I am switching away from Dreamweaver into Aptana. I am using Codeigniter PHP.
Iam trying to figure a good environment setup. It is a small shop, 3 users. We have 2 external servers. One is for test builds for sites and the other is the live server for the sites.
I am used to Dremweaver where you can open a file from the remote site and it pulls it to your local. This does not happen in Aptana. It will open the remote file but then just saves it to the remote site.
So I need to come up with a way for the users to keep their files up to date as multiple people or working on the same sites.
The only thing I have figure so far is to just work off of the remote connections node and at the end of the day do a sync so your local has the latest files.
I would prefer to keep away from local testing environments. We have a testing server and that is what is for.
thanks
Sounds like a good opportunity to introduce version control like git there. Aptana has some git integration built in so getting started with that should not be too difficult.
Related
I am currently working on a Drupal project. Being a developer, I have often heard disagreements on whether it is better to develop on a local stack or on a shared development server. To anyone here with Drupal experience, do you have any insight or advice for me?
This is nothing Drupal-specific.
Everybody should work on their local machine. In a local development environment. There are thousands of options to choose from to make your own computer run a website locally. Start with MAMP maybe.
Use Git (and the Gitflow Workflow) to commit your changes to a repo where your co-workers can pull them from into their local environment.
Use deployment routines or webhooks to have your changes pulled onto the live server on every release automatically.
When developing things always move in two directions:
Database copies move down (from live to dev to local).
Code changes move up (from local to dev to live).
What should be good when multiple persons work on one and the same code instance at once? Nothing. Imagine all the conflicts that can arise from two persons working on one file at the same time. Insane!
I have a simple Wordpress website that is created using twelve twenty. I need to transfer it from server to my PC to be able to edit it and transfer it back to server. Now that I copied wordpress directory from server to my PC it asks me to reinstall it. How can I do it? Am I missing something? Is it possible to work on website locally and once it is done transger it to the server?
Reason for doing this are:
-don't want to loss data for wrong doing things.
-have a copy of website on local machine.
-easier to work on the local machine offline rather than bing online and accssing the server.
From my point of view , i would suggest u to back-up full website and database from server [every hosting control panels has option to backup same]
Connect via ftp and edit ur files.. there to make lots of changes when u want to move from local to server or server to local.
cheers!!!
Editing the files on a live site directly is a terrible, terrible idea. It invites any number of points of failure. If you're actively developing a site things will break at some point - it's part of the developing process - and you definitely want to break things locally, not on a live site.
There's actually several steps involved, all of which are too long to go into great detail, but here's an overview of what is required along with a few links to get you started. The first time you do it seems laborious, but once you figure it all out it actually only takes 10 minutes.
Firstly you will need a local environment MySQL and PHP environment to install it. As you're on PC look at WAMP; here's a fairly good tutorial on installing it.
If you have a lot of content on the live site you might want to import it into your local environment; you'll need to export the database (probably using PHPMyAdmin) and then import it into your local database. You will need to update a couple of database options so that it points towards your localhost. It's basically the reverse of the process detailed here: you'll be changing your-site.com to localhost:8888. If your site is relatively simple you could skip this stage*
Now you should be able to update your local copy of wp-config.php with the database connect details for your local database (usually it's just localhost for the host name and root for the user and password`). With that in place you should now be able to install WP.
Now that it's installed you can edit away to your heart's content on your local copy, safe in the knowledge that anything you do on your local copy doesn't affect your live copy. When you're ready to push your changes live you can use FTP to copy your local files to your live environment.
* For a lot of projects I don't actually go to the trouble of synching databases - if there's a live site that the client can change the content on it often becomes a futile exercise attempting to synch a database with a moving target. In those instances I'll just use a comprehensive set of test content that contains every conceivable type of content that could possible inserted in to the live site.
your going to love working on your project from your locally. Here's an article I found on wpmudev http://premium.wpmudev.org/blog/how-to-install-wordpress-locally-for-pcwindows-with-xampp/ which gives you a step by step guide for PC / Windows.
I've developed WP sites and themes before, but mostly independently, and mostly live via FTP.
This seems to be frowned upon, and it also seems like a stupid way to continue if I want to start with preprocessors, which look amazingly useful and fun.
So local development makes sense, with MAMP for the WordPress requirements, and something like codekit because I am no terminal ninja. But I'm also going to working within a team -- so, test server that everyone can access?
I used Logmein to get into someone else's system years ago, but I can't imagine that's standard practice.
This seems like a basic thing, and I'm sure there's knowledge that I'm missing, but how do people set something like this up? What are best practices for team projects?
Working with WP is tough on a team. I can explain what I typically do when working within a team:
Git
USE IT!! This is especially when two or more people are working on the same project. Once you start using it, you will use it even when it is just you working on a project.
A team I freelance with uses Bitbucket as it provides free private repos, and a program called Sourcetree (made by the Bitbucket team), which is a decent git GUI. The GitHub app is pretty decent as well, however Sourcetree has a few more options.
Wordpress Workflow
Each team member works locally using MAMP, because using CodeKit or Grunt and LiveReload just makes the world a better place, and load repsonse times are way shorter.
Just the WP theme folder that is being developed is pushed with git to the repo.
We include a sql export folder (named 'db') within the theme folder, typically structured like this:
THEME FOLDER
|-(theme files and folders)
|
|-db
|-/-local
|-|-/-team_member_name_1
|-|-|-/-(local sql exports)
|-|-/-team_member_name_2
|-|-|-/-(local sql exports)
|-|-dev
|-|-/-(sql exports from development site)
|-|-production
|-|-/-(sql exports from production site)
The local folder has a folder for each team member to put their exports in. These can then be merged as needed for the dev site. (Note: The db folder is never put on the production server-it's just used to pass sql exports back and forth with git)
It seems like no matter what, importing and exporting sql databases are the only hurdle in a streamlined workflow. We just try to keep doing it to a minimum.
So our basic flow of a project is:
Setup and install a WP dev site (www.devcompanyurl.com/wpdevsite)and database
Setup and copy of the site locally using MAMP
Connect theme files to CodeKit/Grunt
Establish project repo, use git to push a master set of theme files that the rest of the team will download and work from.
Then it's just a matter of pushing, pulling, and merging files, and doing the occasional .sql import.
Hope this helps!
I am currently using Komodo edit for coding, and have a set up where I am using MAMP and a local install of Drupal, and SASS to build my site offline.
Once its ready test online, I upload onto the remote site. However, then I am working sometimes on the remote site and sometimes on the local one, and finding some problems.
I'm not using SASS on the remote site, so I am working in the CSS file. I don't have all the Drupal panels in code yet, so I'm having to rebuild them on the remote site, and I'm making tweaks and changes on the fly.
I end up with two slightly different versions of the site and need to keep track of the changes I want to keep from both. What can I do to clean up my workflow?
It would be better if I could work entirely locally and then sync that to the remote environment.
With something like Netbeans I think I could have a local copy of the site running and then right click and upload each file onto the remote server so there are two copies of the file.
I could do with some advice as to what the cleanest set up is.
I have an actual Dev server with its own ip and a live server with its own ip but they both connect to the same mysql server. There are two databases set up, db1 and db2.
I use a php script with basic sql instructions to:
Check which db is in use.
Backup that db (say, db1).
Sync the databases
Import that db into db2.
Once that is done, I use this:
cp webdb2.settings.php settings.php
So I always have two databases available and can roll right back (in this case with:
cp webdb1.settings.php settings.php) if something when wrong.
This seems to be a pretty good system. I only ever work on the dev, and then push it to the live with the process above.
The best thing that you can do is work offline an then sync the content (themes/modules) when you have to.
If you work on both you could lose data or lose track of code changes.
My friend and I are collaborating on a ASP.NET powered website. To develop it locally, we use Visual Web Developer Express (good enough for our needs). Subversion (using Tortoise SVN) is our source control of choice with the repository residing on Unfuddle.com.
We run into problems when we need to update the live site - since there's no version control on it. Currently we use the "Copy to Website" feature in VWD which copies the files using FTP. Here are some problems:
VWD only keeps track of files uploaded by one user, so if the other user uploads a newer version of a file to the live site, VWD on my side cannot tell whether the live version of the file is newer or mine is.
There's no way to tell whether all the latest changes are available on the live site.
We have to be careful not to party all over the shared web.config file since the other user's local DB settings are different from mine, and of course, the live DB settings are a whole other story!
What do you guys use to publish to a live site? Does anything out there tie into Subversion so that we can automate the process and always guarantee that the live site is synced to a change list number? Also, how do you manage the different web.config file settings?
Thanks!
Well...
wait another 2 weeks and you have.... Visual Studio 2010. Lots of nice things for you:
Different web.config settings for local and production, so basically you can ahve one web.config and.... vs 2010 will automatically merge a delta file on publication. This is really a weak point so far. Check http://weblogs.asp.net/gunnarpeipman/archive/2009/06/16/visual-studio-2010-web-config-transforms.aspx
More modern publishing mechanism. Working alon gpackages. You need a host to support it, but seriously - the FTP publishing mechanism was retired a LONT time ago. http://blogs.msdn.com/webdevtools/archive/2009/02/09/web-packaging-creating-a-web-package-using-vs-2010.aspx
Any subversion tie in? Sure - any CI server can do that. Point is, though: you dont want. Version Control != website publishing. You dont publish every checkin. In non-trivial non-playing-around setups, changes are done on development, then moved to a test server, thne possibly to an integration server and then finally to production. You dont publish "as you go".