The list was long.  Too long for one 40-minute presentation.  So we put together this blog post as an appendix of sorts to give you more detail and better explanations of the more complex command-line approaches (fastest and easiest) to moving your databases and sites from a development environment to a production site.

Our New Project Checklist

To save ourselves hours – no, days of time when we’re ready to launch, we send all of our new clients this simple checklist to solicit all of the credentials and information we might need as we build their website.

Here you go.  Feel free to copy/paste and redesign to your needs.  You’re welcome .

Moving Your Database

Transferring a database can be a nightmare without the right tools. Did WP’s export function cover everything? What happens if you’re using a plugin that doesn’t play nice with that? The easiest way to move your database live is, of course, to actually be developing on the live DB in the first place, but for large sites that will have ongoing work, that’s not an option. You’ve got to have a quick and easy way of copying your database.

So, there are two options:

phpMyAdmin. First, your host probably has an installation of phpMyAdmin that will allow you to access, export, and import your databases. This is your best bet if you aren’t comfortable working in a shell account via SSH (Secure Shell).

When you log into phpMyAdmin and select your database, there’s an EXPORT tab near the upper right. Navigate to that, select everything, and export it as a gz-compressed file. Create your new live database (likely via your host’s control panel), then open that in phpMyAdmin as well, and do the reverse: Go to IMPORT, and upload the DB dump you just downloaded.

Option 2? SSH. This one’s easy: Create the destination db first, then do the following:

mysqldump -u [dev username] -p [dev database name] > dump.sql
mysql -u [live username] -p -D [live database name] < dump.sql


You may need to supply the -h [hostname] or -P [port] parameters, but that’s the gist of it. How you move the dump file between servers is up to you, but using scp (try man scp) is much better than the old download/upload. You just copied the db. One last thing for security: rm dump.sql

Fixing WordPress Options and Entries

You’ve cloned your database. If you were working on a subdomain, you now have a problem: Your WordPress installation will be pointing at the wrong place. There are two entries in the wp_options table that determine where links point, “siteurl” and “home.” One points to the root of your site, one to the root of your WP installation (these are often, but not always, the same thing).

If you’re using phpMyAdmin, navigate to the wp_options table and edit those two settings to match the new site.

If you’re using SSH, enter mysql -u [live user] -p -D [live db], then enter the following SQL:

UPDATE `wp_options`
  SET `option_value` = 'http://your.live.site/'
  WHERE `option_name` IN ('siteurl','home');

If your site root and wp install differ, enter that twice and substitute WHERE `option_name` = ‘siteurl’ or WHERE `option_name` = ‘home’.

Another issue you may encounter if you’ve added a bunch of posts that link to one another: The links in your posts are probably pointing to the development site. That’s cool, we’ve got a SQL formula for that, too. If you’re using phpMyAdmin, you’ll want to bring up the SQL tab for this one:

UPDATE `wp_posts`
  SET `post_content` = REPLACE(`post_content`,'http://old_url/','http://new_url/')
  WHERE INSTR(`post_content`, 'http://old_url/');

You’re all set. Close phpMyAdmin or type exit if you’re using the command line tools.

Let’s move the site itself.

Moving Your Files

This part’s for SSH; If you don’t have SSH access, sorry, you’re stuck doing it via FTP. This’ll make moving files painless. There are two situations:

Same server: cp -R ./dev_dir ./live_dir (substitute directories appropriate to your server)
Different servers: use rsync or scp to copy your blog files.

We like to move files directly from server to server to save time. Depending on your connection, moving a large WP install can take over an hour via FTP. This method will most likely take less than a minute, given the speed between two servers and not having to transfer it all twice. You can do this via a mobile tether and not have to worry about your bandwidth being throttled.

In fact, if you’ve got an iOS device, check out Prompt from Panic, Inc.

Once your files are moved, update the database credentials in wp-config.php, and you’re good to go.

Using Beanstalk for Deployments & More

We’re big fans of Beanstalk (www.beanstalkapp.com) for version control and deployments. If you’re going to be maintaining the site you’ve just launched for any amount of time, it’s probably a great idea to look into using Beanstalk.

Why? Deployments. Deployments are awesome. Once you’ve used them, FTP will become a miserable experience by comparison (not that FTP needs any help there).

Here’s why it’s so awesome: You can set up automatic and manual deployments to multiple locations from your SVN or Git repository. It works over FTP or SFTP (recommended) for SVN. If you’re using Git, you may prefer deploying via capistrano.

When using SVN, we like to automatically deploy to the development site from /trunk. If you like branches and merging, you can set up a deployment from /branches/live to the live server, but Versions (a popular Mac SVN client) can’t merge. If you’re not down with doing merges, you can deploy from /trunk just fine, just be sure you’ve got it set to manual deployment – it’s safer for the live site if pushing code is always 100% intentional.

That applies to git as well, except you’d be deploying from tags (master, live, etc) instead of SVN paths.

Chris Coyier of css-tricks.com recently published a pretty cool screencast that walks through getting deployments set up. Aside from MySQL acting up, it’s a smooth process.

Mac users will likely want Magic Bean for deployment notifications and not having to log into the website to manually deploy.

Odds & Ends

WP plug-ins we find ourselves using a lot:

• Redirection by John Godley: Easy to manage redirections from the client’s old site.
• WP-Help by Mark Jaquith: Write documentation that lives in the WP admin area.

You might also check out any of a number of security-related plug-ins.

Need an SSH client? It’s built in to mac and unix/linux environments (just open a terminal), but if you’re working in Windows, we recommend Putty.

For reference, here’s the presentation:

1. Tell me about yourself, where are you from, what’s your background?

Originally from Delaware, caught the programming and art bugs early on. Went to college at first at Virginia Tech for Computer Science, but ended up leaving; Not enough Comp Sci in my Comp Sci. Ended up moving to FL and getting a Graphic Design degree instead, with much smaller class sizes and more focused classes. The intent was to get a Web Design degree after that, but it became increasingly obvious to me that I could teach those courses: I’d been building websites for longer than most of the professors.

I’m part Comp Sci, part Graphics Guy. Also, I’m sorry for that sentence.

2. How you ended up at Big Sea:

After college, I took a job as an in-house jack-of-all-trades designer. Print, web, conventions, you name it. Cool job, until you get tired of the subject matter. Then you’re increasingly compelled to try something more interesting. In my case, I resigned and went to work for myself, building and launching Listy.us. I learned a metric ton about building web apps, had a blast, but ultimately the project flopped. Got a job at a local charity doing web development for a bit, but it wasn’t quite right for me.

When Jessica tweeted that Big Sea was looking for a developer, I jumped at the chance.  Some Twitter messages, emails, and a Skype conversation later—best interview process ever, by the way—and I was working at Big Sea. It’s an awesome environment with great people.

3. What do you like about working in web design/development?

It’s a creative problem solving job, basically. I think the easiest way to explain it is the idea of Flow, i.e. it’s an almost perfect mixture of challenges and successes. There are some rough bumps here and there (“Why won’t you work? Whyyyyy?“), but in general it’s really rewarding.

That, and the people are pretty awesome. Probably the best community of any industry.

4. What types of projects DO you like working on best?

Ones with documentation… (glaring at OpenCart)

In all seriousness, I love a project where I have input on every stage of it and get to work from the ground up. There’s a great feeling of accomplishment when you can say “I helped build that!” as opposed to “I helped modify / fix / redesign that.”

Opportunities to learn and implement new technology are great, too.

5. New technologies or skills you’re eager to learn?

A lot of the new JavaScript based tech that’s been evolving in the past few years have been catching my interest. Coffeescript + Backbone is my latest playground, but I’ve got my eyes on RaphaelJS, among others.

Sass is pretty awesome as well, we need more opportunities to use that in projects.

PHP 5.3 and 5.4 have nice features. I’m looking forward to those, but I figure they won’t be something you can rely on having in all environments until the heat death of the universe.

6. What is your favorite place to be?

Outside, in shade, 74 degrees and breezy, with a beer and a laptop. Extra points for sound of leaves or water. Negative points for wind chimes; screw wind chimes.

7. If you had $1,000,000, what would you do with it?

Spend my days building web apps to try and have a positive impact on the world. I’ve got a bit of an altruistic streak that manifests when I don’t have to worry about paying bills, and no shortage of interesting ideas.

Follow James on Twitter (@tkstudios) and connect with him on Facebook and LinkedIn. Twitter’s your best bet, really.

And it hit me: we are not emergency designers.  We never have been.  We ask tough questions and spend time in discovery and research.  We dig and dig before we ever start designing.  We make recommendations.  We’re not “yes” people; we’re “why” people.  When you tell us your website needs a feature, we don’t just agree; we ask why. Then we push you (and ourselves) to dig up a better answer or provide a foundation to back up your request.

And yet, we end up “hurrying up” more often then I’d like.  We tend to take on emergency projects even though they don’t fit our general mold of process and project management.

It’s not that we can’t build a site quickly; we certainly can.  It’s more along the lines of our initial approach to a project.  Once we get to the design and development stage, we’ve already done our due diligence and the process can fly. But we like to know we got there with good reason and research.  We like to know the stakeholders are all on board with what we’re about to produce, and we like to know that every conversation that needs to be had has been had.

We’ve had a virtual onslaught of new project inquiries in the past few weeks.  And that’s a great thing, of course. We’ve been working hard on great projects and launched this gorgeously redesigned site and have been out writing, speaking and getting to know folks. Our clients give us fantastic referrals to everyone and anyone. We’re busy and loving it.

Of the new inquiries, a handful are really great, qualified, well-fitting projects for our team. Clients who want us to spend the time digging and learning and researching before we build; who want us to labor over the details and create really polished, beautiful web and mobile apps.  Who want us to thoroughly test the products before they launch.

And another handful are looking for “emergency” designers to take over a project that went south or start on something immediately that was supposed to be done last week (I need this 200 hour project launched by mid-February!).

Next time you have an emergency, open this box.

To these emergency clients, how fast we can get them a proposal reflects on how fast we can turn the project around – when in fact, the two are not at all related.  We need time to spend doing our research before creating a proposal. We need time to determine the best platform and approach and our own resource assignments.  It’s a complex matrix and it all takes time to do it well.

That said, we’ve taken on quite a few projects that weren’t going well and turned them around – but those clients recognized that the process would take both time and hard work.  They brought us realistic expectations and we turned out some awesome work.

It’s amazing when expectations meet reality, isn’t it?

I’m feeling liberated in this realization.  It’s yet another “red flag” for my arsenal of client selection tools that help us determine fit for new projects, and a step forward in solidifying our approach to design and development.

Do you find yourself providing emergency design services?  How to you react and how do those relationships turn out?

They’re going to look for a “Log In” link in the upper right corner.

They’re going to try to get in touch using a “Contact” page.

Sticking to expected navigational and architectural structures on your website – especially when you’ve got a lot of content or a complex hierarchy – helps establish trust with your visitors.

Rules, boundaries, roadmaps, breadcrumbs, met expectations - all serve to help your visitors feel comfortable to explore even farther, to dig deeper and keep clicking.   Just like fences encourage kids to explore the full expanse of playground, visitors want to know that your site meets their predetermined website schema so they can feel comfortable pushing the boundaries.

The breadcrumbs, the visual cues that fit expectations, the comfort in navigation serve as reminder that they are safe from harm (“the unknown”). As long as they remain in that secure environment, they can confidently and freely enjoy themselves.

One errant click that lands them somewhere they didn’t expect – or worse, leaves them without a clear path back to from where they came – and you’ve lost their trust.

Straight from the research on website schema’s by Bellman & Rositer, “ease of navigating the website strongly influences attitude toward the site, which in turn increases the strength of beliefs about the new brand’s attributes and also, fairly independently, overall attitude toward the brand.”

Can you think of a time when you visited a website that didn’t meet your expectations and how that made you feel about the company, brand or product?

Starting a new year is a great time to start working on new limits, new approaches and new systems for your business and your life.  So, our intentions are as follows:

For the business:

1. Move to a more client-centric design approach by building partnership agreements rather than one-off build contracts.
2. Make it all responsive. Or at least adaptive. There is no excuse for fixed-width any more.
3. Learn more, and more and more. Every Friday afternoon is designated self-improvement day. That means learning through tutorials or videos, reading or working on personal projects.

Andi‘s intentions

1. More personal communication; less email. Talk it out. Touch base and catch up. Plan regularly scheduled phone calls with all ongoing development projects.  Travel if necessary for kickoff and important milestone meetings. Go the extra mile.
2. Give back to the community. Speak more; attend more meet-ups; finish the book I’ve started writing three different times.  Share my knowledge more.
3. Plan better. Stick to an organized, well-structured project planning approach and spend more time on thorough contracts with detailed SOW agreements.

Charlene’s intentions

1. Go responsive. Just dig in and make it responsive. It’s not exactly a brand new concept. Just do it already.
2. Get Sass(y). CSS is awesome and SASS just adds MORE awesomeness. We all need something new and fresh in our lives sometimes–this is it.

Jessica’s intentions

1. Better time management. Follow the schedules and to-do lists I make, but don’t use nearly enough. Say “no” more, prioritize better and spend less time browsing the wonders of the internets.
2. Write more. I’d be happy if I wrote about just about anything at this point as long as it’s more significant than emails, texts and Facebook updates.
3. Move quicker. Send the stupid email, don’t stare at it in Drafts for an hour. Get things out of “planning” and into “production” faster.

James’s intentions

1. Give back more. Finish the next version of one open source project, start another one, and help others with theirs. Use GitHub to interact, not just for versioning things.
2. Play and learn more. Tinker with new technology on a weekly basis. Watch more screencasts. Read more books. Always have a podcast handy.
3. Take over the world. Muahahahaahaaaa!

Keith‘s intentions

1. Find a balance between efficiency and properly documented code/projects.  We work in a client driven business – budgets and timeframes conspire to sacrifice the proper documentation of code and projects for on time delivery. this year i want to find more of a balance – a few extra hours documenting code will make future updates easier and save time in the long run
2. Take more pictures! My hobbies shift from year to year and I’ve been ignoring this one for too long. I want to shoot more panorama shots of the downtown St. Pete area. Here’s one that i took in Charleston.
3. Work on pace.  Ever hear the old saying “start out like you can hold out”?  I’m going to work on applying that this year. Too often, I procrastinate; looking for motivation to tackle a big project and then code in a burst. I’ve found that if I work steadily, but more slowly, I can get more accomplished because I end up turning out more code.

Now you’ve seen ours and you can hold us accountable (seriously – hold us accountable!).  What are your professional intentions for the year?

Does Using a 3Rd Party Api to Publish to Facebook Decrease Engagement? Update!  Maybe Not.

Facebook claims they fixed the bug causing updates posted by 3rd party applications (like Hootsuite, Twitter, TweetDeck, etc.) to have 80% lower engagement than those posted directly on Facebook. Despite EdgeRank Checker tentatively agreeing (sort of), I’m skeptical.

We hypothesized that there were four possible reasons why this was happening:

1. Facebook penalizes 3rd party API’s EdgeRank – FIXED
2. Facebook collapses 3rd Party API updates
3. High chance of being scheduled or automated
4. Content is not optimized for Facebook

First of all, as they mention, they’re comparing apples to oranges. Impressions are a measure of who sees the content. Engagement is a measure of who interacts with the content. In addition, the actual algorithm penalizing apps is only part of the problem.

Given that:

1. to my knowledge, Facebook is still collapsing 3rd party updates,
2. the actual quality of the posts is often worse, and
3. people have the ability to hide all updates by certain apps from their feed,

I still believe 3rd party posted content will receive fewer impressions and (especially) engagement than content posted directly through Facebook and formatted accordingly.

Link to the study by EdgeRank Checker.

Facebook’s Hybrid News Feed Has Smaller Pages Swimming Upstream

Facebook released the hybrid news feed in September 2011. A subsequent month-long study found that “most Pages experienced a decrease in impressions, while larger Pages (especially those with 100k+ fans) tended to experience an increase in engagement.”

Link to the study by EdgeRank Checker.

Keep in Mind What Fans Are Expecting When They Like Your Page

• 33% of consumers say “When I want to communicate with a brand, I post on the brand’s Facebook Page.”

Source: CMO Council

• 47% of consumers say “When I connect with a brand online for a customer service or support issue, I expect answers within 24 hours.”
• 67% of consumers say “When I Like a brand on Facebook, I expect to be eligible for exclusive offers.”
• When it comes to “why I Like a brand” (what consumers said), vs. “why we think people Like brands” (what marketers said), marketers and consumers are on very different “pages” (pun intended).

Link to the study by CMO Council (PDF).

Why Fans Are Unfollowing Your Brand on Facebook & How to Stop Them

• 46% – The information was not interesting.
• 46% – The information was published too often.
• 39% – The brand is no longer of interest to me.
• 23% – The brand published information I did not appreciate.
• 14% – Information was not published often enough.

“Engagement in Facebook brands’ walls is down 22%,” said Syncapse CEO Michael Scissons. “But declining engagement has less to do with brand fatigue in general than with marketers doing a bad job and shoving boring [content] at consumers.”

“At DDB, Bernbach taught us to behave with respect for the consumer, recognizing that brands are in the hands of consumers, not marketers. Facebook is making it more relevant than ever today. Brands got blinded by the technology, forgetting about the basics of relationships in the way they interacted with consumers,” said Sebastian Genty, DDB’s planning director. “They need to learn to behave like any human being, with respect and transparency. Rhythm is key, as in any new relationship.”

Link to the Study by DDB & Oppinionway.

So What Have We Learned?

• Increase your Affinity score by consciously working to get fans engaged on an ongoing basis.
  • There’s nothing worse than being boring! Be interesting and controversial. Start a debate. Ask questions. Have people fill in the blank. Create a poll. Post trivia and quizzes.
  • Respond to Likes on posts with questions and always respond to comments to keep the conversation going.
  • Give things away and offer discounts. When you do, use the words  ”coupon” and ”$ off” (not % off). Here are 26 ideas and an app to help you out.
  • Promote your Page offline, on your website and use the Open Graph to make it easy for your fans to participate outside of Facebook.
• Improve Edge Weight by posting photos, videos and links which generally have the highest Edge Weight. This doesn’t have to be hard.
• Don’t overwhelm people.
• Keep posts at 40-80 characters or less.
• Post one to four times per week and never more twice per day.
• Optimize updates for Facebook.
  • Although using 3rd party tools can make it easier, avoid them when possible.
  • Tag other Pages and Events. When possible, use your personal profile to tag other people.
  • When posting links, choose a good picture.
  • Avoid hashtags, shortlinks and other evidence of cross-posting.

We’ll be posting a Part 3 all about the timing of posts soon. Stay tuned!

If you haven’t already looked at Facebook’s new Page Insights, look them over today. Do these studies back up what you’re seeing with your brand? Do they contradict? Let us know and be sure to Like the Big Sea Facebook Page!

Here are a few key lessons we learned in 2011:

Charlene: Repository. Repository. Repository!

No matter the size of the project, if you’ve got more than one person working on a website your best bet is a versioned repository for safekeeping. This year I worked on my first large project with over 10 developers in different locations. Oddly enough, we had minimal issues as we all chugged along updating, committing and updating again to the repository. During an earlier project, which I must mention was much smaller in scale and included only three developers, large chunks of work had been written over several times which caused obvious frustrations, etc. And so the repo went up and so did productivity levels. Duh.

Jessica: Work with amazing people. Always.

Here’s the thing about life: we’re all (hopefully) going to be here for a while. One of the things I figured out early on in life is that you should love what you do. I use the cliche “If you love what you do, it won’t feel like work” way too often because I think it’s 100% true. And believe me, I love the internet! Then I learned, it’s not just about loving what you do, it’s about loving who you’re doing it with.

Work with people who care deeply about those around them (like Andi). Work with people who are great at what they do, and embrace attack new learning opportunities and challenges (like Charlene with GitHub earlier this year). Work with people who are passionate about the quality of their business and brand. Work with people who make you laugh. Work with people you want to grab a beer with. Work with people who inspire you and push you to be a better person.

Keith:  Preparation and planning are key to a successful project.

No matter how many times I have heard this in the past, I still have to fight the urge to just jump in and start coding right away. Spending the time up-front to plan out what I’m going to do results in cleaner code and more efficient use of the client’s budget. Projects are dynamic and we can’t anticipate every problem, but a little preparation goes a long way in smoothing out the bumps along the way!

Keith: Communication is more important than you think it is.

This year, I’ve learned all about the value of keeping clients informed. A small note to update them on your progress (even if you don’t have anything to show them) helps them to stay involved.

It works with co-workers too! In the crazy web world of multitasking and complex projects, it really helps to let everyone know what you’re up to and what you’ve done. Document everything you can in a central location so everyone is up to date. It doesnt have to be a novel – a few short sentences will keep everyone on track. It reduces duplicate effort and empowers everyone on the team to fix issues rather than having to rely on a single person.

James:  There’s still a ton to learn.

I’ve been at this web design & development thing for most of my adult life. It’s only getting faster and more complex, and that’s really exciting. 2011 reinforced the lesson that building a library of modern resources and taking the time to sit and absorb new ideas and techniques (be they from books, blogs, or screencasts) is vital to our profession. Never stop learning. Play with new ideas. Be curious.

Andi: Communication is the key to managing expectations.

Managing expectations is one of the most important aspects of project management. When there is no clear process and we let projects sway and bend, clients and team members don’t know what to expect (or when).  The problem we continually encounter is that every client is different.  Some come to us completely prepared to immerse themselves in the process; others have other obligations and commitments that keep them from being totally involved.  We need to make them fully aware of what’s to come when we start the process, and keep them apprised should anything pop up to change that process.

I’ve already put together some documentation to use as a skeleton for every new project, and anticipate much clearer direction at the start of each project going forward.  We’ll all know what’s going to happen, when, and if any obstacles pop up along the way.

————-

What did you learn in 2011 that you think would be helpful to our team or the web design community?  Helpful to your business or others?

Better late than never, right? We’ve had a crazy November but it’s slowing down a bit, just as it should, so we can spend more time with our families over the holidays.

For that, I’m thankful.

Big Sea has grown by leaps and bounds this year. We’ve had the opportunity to work on some amazing projects, with amazing people and have brought on amazing talent. It’s been a growing-stretching kind of year; a finding-our-groove kind of year.

For all of these things, I am thankful.

Thank you to the talented Jessica Barnett for helping get us organized and on-task. For showing me how important it is to spend the time necessary to dig through the minutia and for making me slow down and think when I want to push forward.  To Charlene Foote for your enthusiasm, creativity and hard work.  For taking the chance on Big Sea and taking over the creative reigns.  To James Sylvanus for the same enthusiasm, and for being awesome in every way, presenting the possibilities and opportunities for improvement.

Thank you to Jared Fager and Mike Van Winkle, for listening to me rant and being available with helpful, friendly and thoughtful critique.  To Aubrey Goodman for sharing passion for a pipe-dream – and making it happen. Thanks for being friends and colleagues.

For the past three years, I owe just about every bit of gratitude in me to the amazing Keith Morgan, who is patient beyond words and incredibly skilled at his craft.  You’ve talked me off more than one cliff and helped me hit “delete” rather than “send” on quite a few occasions.

I’m thankful for our amazing clients, who trust us with their vision and their fortunes.  We really do have some strong partnerships and I hope that 2012 brings even more success.  Your passion, creativity and boundless energy for your project provide inspiration and motivation beyond compare.   I am eternally grateful that I’m able to help so many people build their dreams – and that doing so is my dream (I love my work).  I’m making plans to help foster these partnerships in the next year in ways that previously weren’t possible.

And yes, Thanksgiving has passed but I’m feeling grateful and reflective (again) this holiday season that I’m able to live a life I love, surrounded by kind, passionate people who support me, my business and my family.  We work and work and often overlook the little things that make it all possible.

For all of these things and more, I am thankful.

1. Document Your Code.

This is the most obvious item, and the one that nobody likes to do. It seems like a waste of time, but taking a few seconds to explicitly say what everything does will save everyone time and headaches in the long run. What seems intuitive now can take a few minutes to interpret down the road, depending on stylistic differences and familiarity with the system. Your documentation could save someone an hour or two of digging through code a few months down the line.

Being able to tell what something does, in plain english (or whatever your project’s common language), with only a glance, saves time and keeps frustration down. It’s just good business.

1.5. No, Seriously, Document Your Code.

Using TextMate? “doc[tab]” above a PHP function will add a DocBlock. There’s probably a similar shortcut for practically every IDE.

Releasing a framework or library to the public? Please, please provide docs. Even just in code. Nobody wants to dissect the whole system every time a simple task arises.

2. Use Descriptive Variable Names.

$product_discounts > $pDiscounts > $pd

It all gets compiled into a symbol table anyway. Use variable names that clearly describe their purpose and contents. This is the cheapest and most effective documentation you can do. Take a look at this:

// get the discounts for each product
foreach($product_list as $product_id) {
  $product_discounts[] = $discount_model->get_discounts_for($product_id);
}

While it may not be optimal, it still makes the point. Reads nicely, right? Now try this:

foreach($plist as $p) $pd[]=$dm->dFor($p);

Does it take less time to type? Sure.

Will it make your current and future co-developers very unhappy? Yup.

Don’t do it.

The same goes for function names. If you find yourself documenting a function with “Does what it says on the tin,” you’re doing it right (you should still document the parameter(s) and return value(s), of course).

3. Follow the Conventions of the System

This is a short one. If you’re working in an MVC environment, don’t put a few hundred lines of controller logic in the view. Don’t put model logic in the controller OR the view.

Generally if things are structured a certain way, keep them that way, unless you have a very convincing reason to do otherwise (and if you do, document it).

4. Refactor Repetitive Code

I once knew a professor who said (paraphrased) “If your function is longer than ten lines, you should split it up.” I’m not going to advocate that kind of strict line count rule, but at least follow this simple one:

If you find yourself cutting and pasting code, consider making it a function. The same goes for if a particular set of tasks can be described by a function.

Here’s an example:

$this->collection[] = $this->load->something(‘first’);
$this->collection[] = $this->load->something(‘second’);
$this->collection[] = $this->load->something(‘third’);
$this->collection[] = $this->load->something(‘fourth’);
// and so on…

Inline rewrite: 

foreach(array(‘first’,’second’,’third’,’fourth’) as $thing)
  $this->collection[] = $this->load->something($thing);

Function rewrite (generic):

// if you have access to $registry from this scope you don’t need it…
function load_things(&$registry, $thing_array) {
  foreach($thing_array as $thing)
    $registry->collection[] = $registry->load->something($thing);
}
 
load_things($this, array(‘first’,’second’,’third’,’fourth’));

Of course, if you have hundreds of items in there, you’d either have to type them all out or make some optimizations. Which leads me to…

5. Multiple Lines are OK!

Break up the following over multiple lines if your language allows it: Strings, arrays, SQL statements, and long function calls.

Take the following SQL for example: It’s pretty short now, but if there were a few more joins and constraints, it’d be a nightmare to maintain on one line.

// This is completely valid in PHP. Using {} interpolation is a personal preference.
$prefix = DB_PREFIX;
$sql = “SELECT * FROM {$prefix}things AS t
   LEFT JOIN {$prefix}other_things AS ot ON t.id = ot.id
   WHERE t.id = ‘{$this->db->escape($id)}’
   LIMIT 0, 100”;

In the case of long function calls, consider using an associative array (or dictionary) to pass in extra parameters. They have the added benefit of naming what they’re passing. Example:

do_something(“things”, 2, 455, 299, 200, 349); // no meaning without looking up docs

…versus…

do_something(“things”, array(
  ‘x_offset’ => 2,
  ‘y_offset’ => 455,
  ‘x_skew’ => 299,
  ‘y_skew’ => 200,
  ‘whatever’ => 349
)); // meaning is clear!

The more you can do to make things clear, the better. Nobody likes scrolling through a concatenated string 1000+ characters long on only one line.

6. Pick Common Conventions

Choose some well-thought-out conventions for your project(s) and have everyone stick to them. Even something as simple as standardizing tab widths and types will save some serious headaches. Take CodeIgniter’s style guide for example: Probably a bit overkill in some cases (OR versus ||, for example), but it has some great ideas, and it keeps things readable across the project.

All you really need to build a blog is great content, but there are definitely some tools that will help grow and engage your readership. We build a lot of blogs, and we’ve compiled our list of 5 essential tools you’ll need to build, syndicate and promote your blog content.

1. List managers.  Email and feed subscriptions are a blogger’s gold, so make sure you’ve got opportunities for people to subscribe to email, feeds, whatever.  Feeds alone won’t drive long-term, sustained traffic you need to build your ad dollars, so make sure you start an email subscription and deliver a weekly newsletter to pull out some of your archive content.  We prefer these tools:
   • CampaignMonitor.  We use CM’s CreateSend product to set up professional newsletter templates and manage email subscriptions.  We can’t say enough awesome things about the tools they’ve created for our clients to use.  If you want us to help you set up an email list and professionally designed templates, get in touch.
   • Feedburner.  Redirect your feeds through Google’s Feedburner product and set up email subscriptions as well, for inbox delivery of your RSS feeds.  Simple, free.
2. Opt-in Sign-up Forms. Now that you’ve got your lists ready, how do you get subscribers? Ask them to sign up, silly. Everywhere. Make sure you ask them in your sidebar, at the top of your posts, after they read a great article. There are a gazillion (yes, that many) plugins to help you build your lists. While we generally write custom code for these, there are plenty of easy plugins out there, like these.
   • Referrer Detector. This is especially great if your posts are syndicated or inexplicably promoted through other sites and media. You can create specific greetings for visitors from referring sites at the top of your blog, and include a link to sign up for your feed or email list.
   • Campaign Monitor Ajax Forms helps you add your email list sign up boxes anywhere on your blog – as a widget in a sidebar or through shortcode on any page.
   • Feedburner forms are super simple to paste into any text widget or the HTML tab of your editor, but if you need help, use Feedburner Anywhere to grab subscriptions.
3. Sharing Tools. Easily the most often requested “plugin” that everyone needs/wants. There are many ways to encourage syndication of your content through social networks, and thousands of plugins to support whatever you want to do. We think style is important, so we like to keep our sharing tools subtle and in-line with the design of a blog. As such, our favorite plugins are:
   • Norcross‘s great Simple Social Sharing. The easiest, most elegant way to add the like/tweet/digg/share icons to the footer of every post. No settings, no fuss, no muss. That’s it.
   • Share This. If you want options, use the free and easy Share This plugin.
4. Comments! WordPress themes all account for simple commenting systems, but to really encourage discussion and help folks interact and share content, use a plugin to assist. Plenty of discussion abounds on these plugins, so have at it. I find it’s a personal preference of the blogger I’m working with.
   • Akismet. Start here. Akismet fights spam in your comments like no other. All you need is an API key, which is free.
   • Disqus. We like Disqus because it’s feature-rich and ridiculously simple to use. Inline media embedding (hello, video!), mobile commenting and great notification systems make it worth the 2 minutes to install.
   • Facebook comments. This may be the wave of the future, or at least the very near future. You can add the ability for users to use their Facebook accounts to make comments that (might) get published to their FB profiles, thus helping to spread your good word.
5. Search Engine Optimization. You’ll never go anywhere without some Google love, so be sure your pages and posts are ready to rock.
   • Google XML Sitemap generator. Get this, use it. Submits your blog’s sitemaps to Google whenever you write a new post or add a page.
   • All In One SEO Pack is a great do-it-all SEO plugin. If your theme isn’t already loaded with SEO goodness, this plugin gives you the ability to write all of your custom titles and meta-data without doing any extra work. Or, you can fine-tune all you want using their interface.

Ok, so what’s missing? Sidebar content (widgets). Analytics. Putting together an editorial calendar. Managing syndication across your own social networks. Advertising and monetization. Image and layout managers, galleries and featured content promotion. Archive and search tools.

The list of what’s missing is longer than what’s here – which is to say that there is no one-best-path to success as a blogger. You’ll need to write, write and write more to find out what works for you, your content and your readers – but the list above is a great place to start.

What are your favorite must-have blogging tools or plugins? Do share.