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!
Related
I'm working on figuring out deploying a Wordpress site from BB Pipelines to AWS EB. It all makes sense except for one thing, I want the repository to only contain the theme and plugin files.
I do not want the full WP directory being deployed each time. Media would be handled via an S3 bucket and the DB would use RDS.
What is the best way to get WP installed but only have the theme and plugins deploy through Pipelines? And when I want to update to the latest version of WP, how would that work?
Or am I going about this wrong?
The simple solution, and best practice in my humble opinion, is to repo the entire WordPress installation, including the WordPress core, and all your custom themes and plugins.
Having the entire installation in one repo solves many problems: you can can tag and release versions, and you can install all software locally with a simple git clone.
Regarding the file system, definitely consider EFS instead of S3. It is much more reliable and easier to mount in a linux-based system. Make sure and define set the file path environment variable, so you can point WordPress to the files. You will want mount this outside of the software file tree.
I have been running this kind of setup for 3 years with no problems. We do releases through the code deploy service daily. Very straightforward and easy to maintain.
To upgrade WordPress just check out the current version from the repo, then apply the upgrades release, do comparisons, test commit and release.
I have a wordpress site that I am finally getting into git. Previously I was editing changes locally and uploading via ftp. I want to come up with a strategy to be able to do the following:
Update my git repository with any changes made on the ftp server (plugin updates etc). That I will then sync that down into my local copy
Push locally tested changes into git and then deploy via ftp (I know how to do this part)
I don't know the best way to approach 1 and I'm very new to using git (usually use svn).
Thanks
Using a conventional development workflow on Wordpress is challenging.
Because WP puts too much in the database, including site config, it makes syncing changes from one environment to the other a real pain.
We have a number of WP installs (against my better judgement) and organise our workflow like this.
You might lighten this process if you're not part of a dev team and are going alone.
Local Dev
codebase changes only. Including shortcode development and templating. This lives under a GIT workflow (branches, tags, etc). Plugin/framework updates are installed here, and tested before adding to the gitball.
Beta Live
All content is built here, with any code based changes being requested as needed. Testing is carried out here, responsive, UAT etc.
Code changes are pushed up via deployment scripts which trigger either a GIT pull, or by syncing files via ssh:rsync. heres a good resource on how to use git hooks for this.
Live
For live deployment, we use a WP database migration plugin to get content across, and the git repository to push tagged releases up to the live server. We also use the sync tool to pull down up to date copies of the database to our local dev machines.
I'm sure there are lots of other opinions on what's best, and how to implement them.
My opinion
The fact is is that WP is a bad choice for websites that require a lot of under the hood attention. It was never designed for this, and consequently is a real pain to force into a proper development cycle. If I must use a CMS, I generally use Drupal for sites that need more functionality, its a steeper learning curve, but more than worth it.
You could follow a git flow pattern. This consist of three main branches:
master
release
develop
Preform all of your development in the develop branch which you would build and test locally. Then when you are ready to test on a server merge your changes into the release branch for testing. When everything checks out you can then merge into your master branch. From here you can either manually ftp the files from the master branch like you have been or set up a deployment hook to automate deployment to your server when changes are detected.
As your project grows you can implement a couple of other branches to further maintain your build. You can base a new branch feature off of develop when you need to add a new feature then merge it back into develop following the flow back up again. As well as a hotfix branch to take care of any bugs "on the fly" straight off the master branch.
Here is a good example of the git flow pattern:
[http://nvie.com/posts/a-successful-git-branching-model/][1]
This article goes into a lot more detail about the git flow pattern and is an awesome resource!
Be sure that whenever you start a new development phase you merge from master to develop so you know you are starting with the most recent version of your project.
I ran across the VCCW project and despite my unfamiliarity with Vagrant and Chef, decided to give a try. I followed their instructions and obtained the VCCW project itself by installing the GitHub Windows program and cloning the VCCW GitHub master repository. I should also mention that I have very little experience with Git.
Anyway, now I have VCCW Wordpress running on my machine, but I've no clue what to do from here. I wanted to set up a better and more formal Wordpress development environment so I could write my plugin and modify a theme, but I don't know where I should do that. I know where the actual Wordpress installation resides on my file system, so I suppose it would be easy to work from there, but I don't know how (if at all) that interplays with the Vagrant workflow - ie, when it comes time to use Vagrant to deploy my site, will my changes to the "www" folder (which was created by vagrant up) be captured? Somehow I doubt this. Just looking for any help as to how all these fancy new tools work with each other and what a humble PHP developer like myself should do to get started.
Edit: One more question: which IDE, if any, can I use in conjunction with this arrangement? Create a new project from existing sources, and let it pollute my deployment folder with project files?
From the Vagrantfile, it looks like you should look in ./www/wordpress after provisioning.
VCCW includes deployment tool WordMove.
You can deploy WordPress into your server from vccw if you set Movefile.
Movefile will be created automatically after provisioning, so you should add your server configuration in Movefile.
http://vccw.cc/#h2-10
https://github.com/welaika/wordmove
I like to use a simple Git workflow for static web sites but I build Joomla and Wordpress sites a semi-regular basis too. However I am at a loss as to how to use Git with with database driven site development.
For a static site I would 'Push' to dev.websitename.com, then push to www.websitename.com once the dev site checks out. How would I mimic that process with database driven site like wordpress or joomla.
Thanks in advance for you insight!
You can definitely use Git with your website code, such as changes to your WordPress theme/plugin, exactly as you would if you are developing a static website.
However, you wouldn't use it for your database. Git provides version control for code, while WordPress and Joomla already manage content stored in the database. Plus, Git wouldn't understand a database, so it wouldn't have any advantage over a periodic backup, which you should already be doing. Take a look at running a dev copy of your site for how to download your database directly from your server.
By the way, if you use Git with WordPress/Joomla, you should add e.g. cache, logs, tmp to .gitignore. There are also lots of tutorials out there--try searching e.g. http://google.com/search?q=wordpress+git.
In addition Chris, you may want to embark on your Git workflow without the handy script approach (at least initially). The script approach and using Git hooks can sure seem sexy (well, because they are) and handy too, but initially why not go with a more manual cmd line approach, which will also help you familiarize yourself with Git.
Once you've got your repo setup (GitHub, Bitbucket, somewhere else) and you've pushed your latest to it and are ready to deploy to production or staging, just login to your host and from wherever you've initialized the git repo (site root, example: /site) just do a:
git pull origin master
This will fetch and merge your code. Good idea to test this on a dev/staging environment and if the merge goes well then do it in production.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-