Jupitercow, Inc

This generic example uses Dreamhost to demonstrate. Some info may change from server to server.

Set up the repository on the server

SSH into your host.

ssh [user]@[host]

You need to get to the point where you don’t need to enter a password anymore… You may need to restart terminal.

Make sure you at your account root or one directory above the live site directory.

cd ~

Make your GIT directory and move into it.

mkdir [yourdomain].git && cd $_

Create an empty GIT repository.

git init --bare

Create/Edit the post-receive hook in order to update the files when pushed to.

vi hooks/post-receive

Enter this into the post-receive file:

#!/bin/bash

# Replace this line with your real domain name
DOMAIN=[yourdomain]

echo "-= Transferring changes to $DOMAIN =-"

# Clearing git env
unset GIT_DIR
unset GIT_WORK_TREE
cd ~/$DOMAIN
git pull

echo "-= Done =-"

Set the permissions on post-receive file.

chmod +x hooks/post-receive

Change back to the parent directory.

cd ..

Clone the GIT repository into the site.

git clone [yourdomain].git [yourdomain.com]

Exit the SSH session.

exit

Add your SSH public key to the server

If you have not generated a public key before, you may need to create one.

ssh-keygen -t rsa

Add to authorized keys on the server.

cat ~/.ssh/id_rsa.pub | ssh [user]@[host] "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

Add your new remote into your local GIT repository

Change to your GIT repository.

cd [git repository path]

Add the remote. Here we are using “live” as the remote name, this could be anything. eg: “production”, “staging”…

git remote add live ssh://[user]@[host]/~/[yourdomain].git

Pust to test it out.

git push live master

Remove public access to .git

Keep the public from viewing the .git and .gitignore files in the new repo. You can place this in an .htaccess in the parent directory to affect multiple sites at once, or right into the main site .htaccess. This very simple rule returns a 404 error when trying to access anything starting with “.git”. This removes access and effectively hides the fact that they even exist.

RedirectMatch 404 /\.git

Sources

1. Automatic Git deploys on Dreamhost
2. How do I prevent apache from serving the .git directory?
3. Deploying on Dreamhost Using Git

1. Make a new directory and move into it.

   mkdir your-plugin-name; cd $_;

2. Download the WordPress Plugin Boilerplate.

   curl -LOk https://github.com/tommcfarlin/WordPress-Plugin-Boilerplate/archive/master.zip

3. Unzip the file..

   unzip master.zip

4. Move the files into your plugin directory and delete the zip file and unzip folder.

   rm master.zip
   mv WordPress-Plugin-Boilerplate-master/plugin-name/* .
   rm -rf WordPress-Plugin-Boilerplate-master/

5. Find and replace ‘plugin-name’ in the filenames.

   find . -type f -name '*' -exec sh -c 'mv "$0" "${0/plugin-name/your-plugin-name}"' '{}' \;

6. Find and replace strings within the files.

   find . -type f -exec sed -i '' s/plugin-name/your-plugin-name/ {} +
   find . -type f -exec sed -i '' s/plugin_name/your_plugin_name/ {} +
   find . -type f -exec sed -i '' s/Plugin_Name/Your_Plugin_Name/ {} +
   find . -type f -exec sed -i '' s/Your\ Name/First\ Last/ {} +
   find . -type f -exec sed -i '' s/email@example.com/your@email.com/ {} +
   find . -type f -exec sed -i '' s#http://example.com#http://yoururl.com# {} +

7. Start developing your new plugin!

This is just a summary of how to create a branch when starting development on a new feature.

1. Make sure you are in the root of your GIT project.

   cd ~/path/to/project/

2. Create a new branch.

   git branch <branch>

3. Checkout the new branch.

   git checkout <branch>

4. Work on the new feature making new commits as needed.

   git add <file>
   git commit -m "Started work on a new feature"
   #repeat

5. Merge the new feature back into the main codebase.

   git checkout master
   git merge <branch>

6. Delete the branch.

   git branch -d <branch>

7. Update version numbers.
8. View branches

   #all: local and remote
   git branch -a
   #just remote
   git branch -r

Using your terminal/command line on linux or mac.

1. FIRST: Update the version number in your readme.txt, and make sure the version is correct in the main plugin file.
2. Change to your plugin directory (`cd`).
3. Create a tag of the of the new version (change “1.0.4” to your current stable version number).

   svn cp trunk tags/1.0.4

   ls -a tags/1.0.4
   rm -rf tags/1.0.4/.git*
   rm tags/1.0.4/README.md

4. Update GIT staging.

   git add -A .

5. Review GIT changes.

   git status

6. Commit the changes to the GIT repo if all looks right.

   git commit -m "Updating as it gets added to WP repo"

7. Change directory back to plugin root.

   cd ../

8. Add items to SVN repo.

   svn add * --force

9. Review SVN changes.

   svn status

10. Commit SVN changes to the repo.

    svn --username [username] --password [password] commit -m 'Short description of changes made'

Using your terminal/command line on linux or mac.

1. Change to your plugin directory (`cd`).
2. Copy the trunk into your tags directory where “1.0.4” should be changed to your current stable version.

   svn cp trunk tags/1.0.4

3. If you are using a GIT repository within your SVN repository, delete the GIT files.

   ls -a tags/1.0.4
   rm -rf tags/1.0.4/.git*
   rm tags/1.0.4/README.md

First. Get approved at wordpress.org.

Once the plugin team approves the plugin, you can get started. This lays out everything using the command line, you can fill in with your GUI of choice as desired.

Change to your plugins new home on your computer locally. This should be an empty directory.

1. Checkout the repository from .org (must use “https”!). You will need to accept the certificate the first time, (p) for permanently.

   svn co https://plugins.svn.wordpress.org/sewn-in-xml-sitemap .

2. Change directory to the trunk

   cd trunk

3. Clone the plugin files from Github

   git clone git@github.com:jupitercow/sewn-in-xml-sitemap.git .

4. Change back to parent directory

   cd ../

5. Check the SVN status, you will see git files listed, we need them to not be seen by SVN

   svn status

6. Add SVN ignores to keep GIT out of your SVN repo on .org, the line break after `.git` is important

   svn propset svn:ignore '.git
   .gitignore
   README.md' trunk

7. Add `.gitignore` file to keep SVN out of your repo on Github

   *~
   .DS_Store
   .svn
   .cvs
   *.bak
   *.swp
   Thumbs.db
   /.DS_Store
   /.svn

8. Add everything to the SVN repo

   svn add * --force

9. Remove things if something went wrong

   svn revert [filename]

10. Create a tag to get started

    svn copy trunk tags/1.0.4

11. Commit the SVN where the username and password are from `http://wordpress.org/plugins/`

    svn --username [username] --password [password] commit -m 'initial commit'

Gist

https://gist.github.com/jupitercow/2c20dfc9cd870dde0e0d

I like taking part in the community. It makes me feel like I am part of something. A truly great, modern something. Jupitercow has been great for this, and we see it as important to make publicly available, at least some, of our new ideas to help give back to a community that has helped build this business over the past decade.

If I am being honest, though, the greatest reason to release as much as we can into the community for free is somewhat selfish: We get some truly excellent feedback from the community that makes our software so much stronger and much more versatile.

When we took over development for an out of date plugin that worked with Gravity Forms to allow users to update existing posts through a contact form, we did so because the pre existing version was not being updated or supported. We rewrote that almost from the ground up to create a plugin that started to really fill the need we had for it. However, once we released that plugin publicly, and even more so once we added it to the WordPress Plugin Repository, it has really become a great plugin.

The ideas and bugs found by the community so far, have been a huge help in making the plugin something that fits most use cases we through at it and is a much more solid experience.

The best thing about open source is that the people who use your application strengthen it every chance they get. If your code sits on a client site or two without taking advantage of what the community has to offer, you are missing out on a lot, and likely so is everyone else.

For developers working in WordPress, it is extremely important to make sure you use WP_DEBUG on your local setup and any development environments. Otherwise you are flying somewhat blind. Since you should not use it on your live servers, you can use this constant to trigger other events. One example is a really simple way to keep Analytics code from reporting activity on your local and staging sites.

In its most basic form, you can wrap the Analtyics code in the header:

<?php if (! defined('WP_DEBUG') || ! WP_DEBUG ) : ?>
	<script>
		[Analytics code]
	</script>
<?php endif; ?>

You could also add an action to create the same effect:

add_action( 'wp_head', 'custom_add_analytics_production' );
function custom_add_analytics_production() {
	if (! defined('WP_DEBUG') || ! WP_DEBUG ) : ?>
		<script>
			[Analytics code]
		</script>
	<?php endif;
}

The benefit here would be to put the analytics code into an area where you customize settings for a client site. A super simple method, you just need to make sure you are setting WP_DEBUG correctly.

Inspired by Chris Marslender from 10up’s great post on how to get your local server to use development or live server uploads on NGINX, I knew I needed a solution for my local Apache server.

This is a really simple solution to add to your .htaccess file. The result is that your server will simply use images from the live site whenever it doesn’t find a local version, so you don’t have spend the time and resources downloading them. A big time saver. Also a big headache saver.

Add before your WordPress code:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^wp-content/uploads/(.*)$ http://jupitercow.com/wp-content/uploads/$1 [R=301,L]

Where wp-content/uploads/ is the path to your local uploads directory, and http://jupitercow.com/wp-content/uploads/ is the link to your remote uploads directory.