I attended WordCamp Toronto for developers last weekend. It was a lot of fun. We were hosted by George Brown College again, and I’m grateful for their contribution. The venue was great. Below are my notes from the presentations that I attended.

Git, Capistrano, and WordPress

• nathanielks on github
• Highly recommends using git sub-modules
• Highly recommends using a VPS on your server

  It allows for complete control over your installation. Which means that you can set up git on the server, along with whatever else you want to

  This might also mean that I can work with Common Lisp on the webservers. Good stuff

• Capistrano

  Based on Ruby and the Rails framework

  There is a tutorial on how to use this on theme.fm

• Use rsync for client files and images in a seperate folder, so that git doesn’t have to deal with this kind of binary data.
• Use a local, staging (Ideally on the webhost to make sure that things work with their version of php and mysql, etc), and production repository.

  It is paramount to keep your production area safe.

Fundamentals of theme development

By Kirk Wright, freelance theme developer from Montreal

• Always use wp_reset_postdata() after using your own loop.
• Recommends the use of the following plugins

  Debug bar

  Debug bar extender

IDEs for PHP

Jeremy Clarke – WordPress Montreal

Use NetBeans

Panel: Your own WP development business

When consulting

• You can probably ask for twice your current amount, and clients would still be willing to pay for your services.
• Clients that want to pay the least usually want the most.
• You don’t want to work for clients that don’t respect your time and work. They will always want one more feature for their website and not want to pay for it.
• Read the book ‘E-myth revisted’

When you are designing your own product (Like a plugin)

When designing anything, pick 1 or 2 items that have to be there and compromise on anything else. Get the product out there and add the other features depending on user feedback.

Site migration

Rick Radko – WordPress Ottawa

• Don’t develop on the live site. Use a dev site.
• Dev site can be on a subdomain of the main server. This way the files and DB copy is local to the server. Quicker.
• When doing a site migration, don’t use a simple search-and-replace. This will break something. Just don’t do it.
• Use the search-and-replace script mentioned in the codex.

  Its called ‘searchreplacedb2’ or something like it.

• Vhosts

  Allows you to set up ‘virtual host names’

  Makes it easy to use other domain names

• If you have the dev site locally on your computer, you can change your computer’s hosts file to point to localhost when the live site’s URL is asked for.

  Adv: You don’t have to worry about search and replacing anything. Just copy all the files to the webhost when you are done.

  Disadv: You wouldn’t be able to visit the live site. You will have to comment out that line from your hosts file if you want to. Basically, you wouldn’t be able to visit both sites simultaneously.

• Online resources

  Backupbuddy and InfiniteWP – They say that they do site migrations, and they know about the serialization issue (Which is why you can’t do a simple search-and-replace).

  Make sure that any service you use knows about the serialization issue.

WP Theme Frameworks

Chad Mohr – SwitchWP

• Uses the premium Genesis framework – seems very happy with it.

  Very little coding required.

  Unique way of customizing sites – you only code the things that are unique to your project.

• Bones – base theme, responsive, html5
• Suffusion – lots of design options
• Types plugin – CPT, custom taxonomies, and custom meta boxes, all managed through the WP dashboard
• Recommends:

  Gravity forms

  Yoast SEO

Tips for presentation

Looking at a lot of presentations allows me the luxury of seeing what works and what doesn’t. Every speaker deserves kudos for putting themselves out there, and facing a sea of people focusing on them. Most people can’t do that, and its a willingness that everyone should have. So good for them, and congratulations for having walked (And talked) through it.

Once you get past that, its a matter of implementation. Some things work better than others. Here are the things that I noted. Its a list of things not to do, and thats half the battle.

• Do not live code in a presentation

  Too easy to get lost in the implementation and details, and lose the big picture.

• Do not show files of code

  Use snippets of code in your slides

• Do not talk about code

  Talk about the benefits of your code

  Talk about how people should use your tool. That is to say, the API.

  Talk high-level. Talk results. Not implementation.

  The reason is that the details will get forgotten by your audience in about 2 hours. If they want the implementation details, they can look at the source and/or the comments in your code, or a blog post detailing how you did something. Just point them to where they can get that information.

• Do not get into a conversation with 1 (or 2, or 3) audience member.

  Doing so will take away from your presentation, and alienate the other members of your audience.

  If you are having a conversation, turn it into a discussion and be sure to constantly invite other audience members to chime in. Do NOT alienate your audience. Make them part of the club.

• Stay on schedule

  Start and stop on time. It shows respect for your audience’s time. If you have to go over, let people know that you are doing so, and that they are welcome to step out if they need to do other things. Don’t make it awkward for them. And apologize for going over time.