Month: August 2014

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.