The Basic Anatomy of a WordPress Site

Before we continue documenting the birth of Kelley’s site, I feel I need to define some terminology, and try to explain the “anatomy” of a WordPress site.
First of all, let me mention that the folks over at WordPress already do a smashing job of explaining their software.
If you have experience setting up WordPress sites already, and are looking for technical insights, you have come to the wrong place. My purpose, here, is to help explain the functionality of WordPress to people who have no experience whatsoever with blogging or Web design, and who would rather not even know the technical reasons for any of it. I realize this doesn’t make a lot of sense to some of you; but there really are many, many people out there who just want a Website they can build easily and maintain with as little effort as possible, without having to know how any of it works. These are people who find their passion in other places, and I respect that.
That said, let’s proceed.
I have intentionally kept this site very basic, so it would be easy for me to demonstrate things on it without a lot of clutter in the way. So let’s take a look at it.
The Main Body Area
This is the area where the actual blog entries reside - the area you are reading right now. WordPress refers to this as “Content.” You can easily change how many blog entries display on the the home page (this one), whether you want to cut the entries short with a “read more” link , and other ways.
Beginning with version 2.1 you have the option of having a regular home page as your front page, or your blog entries. With a regular home page, your blog would be another menu choice.
The Header
On this site, the header is composed of the name of the site (Empowered By WordPress), a description of the site (Powered by you…), a background image (the red striped image), and a menu that lists the static pages of the site (more on those later). The header is usually the first element that you may want to customize to suit your own needs. We could easily, for instance, replace the red-striped image with a photo or our company logo, or something similar. This will make more sense to you when we talk about choosing themes and customizing.
The Sidebars
The two columns on either side of the main body area are called “sidebars.” They are what will hold the other elements of your site, like links, categories, search tools, recent blog entries, archived entries, photos, video streams, RSS feeds, advertisements - pretty much anything else you want to add you your site. These are also where you will implement most of the plugins you add to the site. I will talk more about the other elements and plugins later, so don’t feel you have missed anything.
The Footer
This is the area of the site where credit is given. Never, ever remove the credit to WordPress or to the theme designer from the footer of a WordPress site. There are a lot of people who have donated their time to this free, open-source project, and it is never good form not to give them due credit.
Common Sidebar Elements
By “sidebar element” I mean the different elements or “modules” you can have on your sidebars. You have the option of having all or none of these elements (and any number of others), and can move them around all you want (this task is easiest if you have a “Widget Ready” theme - more on that later). Remember, too, that this is where you will be placing most of your “plugins” as well.
Let’s look at the ones that are on this site, first. On the right sidebar you see:
Pages
This element will list all of the “static” pages (pages that have information that does not change unless you edit it) you have on your site. On this site, the static pages are “about me” and “empowering services.” Notice that these “pages” have static information on them - your posts will only show up on the “home” page you are on now. Also, notice that those “pages” also show up as menu items on the top of the site. You will not need to do this manually. If your theme comes with a menu, every page you create will automatically show up as a menu choice on that menu.
Links (or Blogroll)
Underneath “Pages” you will see two headers: “Empowered Sites” & “Resources.” These are both part of the “Links” element. On many themes, you will see this called “Blogroll,” because it is used by bloggers to list the other blog sites they find of interest, and think you might too. But, essentially, they are links. You can have one long list of links, or you can categorize them like I did here (Empowered Sites and Resources are link categories). To include a link on your site, you would enter the URL and a description, and put it into a category if you would like (more on that later).
Meta
This element is usually used as a place for you to login to your administrator account (to post, make changes, add things, etc.), and to provide links to the RSS feeds on your site (more on that later), and any other sort of maintenance stuff.
Moving to the left sidebar now (I will talk about the other two items on the right sidebar in a bit):
Search
Your visitors can use this feature to search your site for any information they want. There are also a number of “search” plugins that allow them to use your search function to search Google and other sites as well for the same information.
Categories
Categories are how you, literally, categorize your blog entries or “posts.” A visitor to your site can then click on any category, and see all of the entries you have made on that topic/category. Categories have another important function, though. They are used to “tag” your site in the social bookmarking indexes, and are also used by some search engines as keywords (a lot more on this later). So choose your categories wisely…
Recent Posts/Recent Comments
These list the latest blog entries you have made, and the latest comments visitors have made on your entries. Again, any of these elements are optional, so you could just as easily not list these if you chose not to.
Archives
This element lists your “archived” blog entries by date. You can also use a “calendar” element to accommodate this - where the user clicks on a date on the calendar to see the entry for that day.
Sidebar Widgets and Plugins
Now, let’s talk about the two elements I skipped on the right sidebar, as well as the two remaining elements at the end of the left sidebar.
Perhaps you have an account with Youtube or Flickr or Myspace or something similar, and have heard them mention putting a “badge” on your site that links back to your photos or videos or whatever? If so, those are examples of “widgets.” If not, don’t fret, you will know all about such things if you stick around - but don’t think you need to - your site will do just as well without such bells and whistles.
The way it works, is that the “badge” or “widget” is really just HTML code that you simply (and I do mean, simply) copy and paste into a text box, and then place that box where you want it to show up on your site - all of the images and “functionality” really reside back at the original site (be it Youtube, Flickr, etc.). Don’t worry, there will be a lesson on that later.
So at the bottom, right sidebar of this site you will see “STATS” and “SPAM BLOCKED” - both of these elements are widgets. They are simply a bit of code pasted onto the site, that tell the remote site what to display, using your personal settings. You could just as easily be telling Flickr to display some of your photos, or Youtube to display a link to one of your videos.
STAT is a widget created to display how many visitors there have been to this site in a while (the figures come from the Gostats Website).
SPAM BLOCKED is used to display figures from a plugin called “Akismet” that helps eliminate spam-comments on your posts.
Please note that I am not using the terms “widget” and “plugin” interchangeably. A widget is a snippet of code that you can “place” onto your site, a “plugin” is an extension, or add-on that needs to be installed in order to be used. But much, much, more on plugins later.
And on the left, I have widgets for my two favorite WordPress resources: Westhost Hosting and Template Monster. Both of these sites provided me with badges (they have many to choose from) that I could use to display their “ads” (for lack of a better word) on this site. You can do the same with Google ads or Amazon listings, or any number of ways to make a few pennies a month on your blog. I prefer only to list things I know my visitors will need eventually.
The End
Hopefully, this tremendously long entry has helped you make a little more sense of a WordPress site. I especially hope that it helped you see just how very flexible and user-friendly one of these sites can be.
Now, I am most anxious to get back to Kelley’s site, as she has just emailed me her theme choices…

1. Kelley Burrus Says:
   I wouldn’t change ONE WORD of this post–it was very easy to follow and digest!
   
2. deltina Says:
   Glad to hear it. Thanks for letting me know, Kelley!
   
3. ladydeborah Says:
   This information is great! It is easy to follow and to understand.
   

Leave a Comment

Building a Web 2.0 and Social Media Optimized Site with WordPress

So, you’ve armed yourself with knowledge about Web 2.0 and social media, and now you’re really ready to tap into the power of the new, social Web? If you’ve decided to build your own Web 2.0 and social media optimized Web site to that end, here are a few steps you can follow to get started:

The most effective way to easily build an optimized site is with WordPress. Yes, WordPress is a blogging platform, but it can also be used as a content management system (CMS) to power your entire Web site.

Use these resources to get a good feel for how WordPress operates:

• WordPress
• The book, WordPress for Dummies

And, for an explanation of the basic elements of a WordPress site, check out “The Basic Anatomy of a WordPress site” post 

Planning your Site:

Make an ambitious list of what you would like to have on your site. Don’t hold back on an idea you may have for your site based on an assumption that it will be too difficult or too expensive to implement.

The plugins available for WordPress are at:

• http://wordpress.org/extend/plugins/

This site will give you ideas on the types of things you can add to your site. You will discover that you can easily utilize plugins to accomplish seemingly difficult functions.

I find these are pretty typical functions most entrepreneurs, small businesses, authors, and publishers are looking for:

• Image Galleries
• Streaming Video
• E-commerce
• Amazon Widgets
• Blogs/Podcasts/Vidcasts
• Random Quote Generators
• Newsletters
• Mailing list sign-up
• RSS feeds from other sources
• Events listings
• Forms for submissions
• Social Media Newsrooms

Choosing a Theme:

• Go to http://themes.wordpress.net/

Make certain you only search for themes that are “widget ready.”

• You can also purchase themes from TemplateMonster.com. Again, make certain any theme you choose is “widgetized.”
• Do not choose a theme before you plan your site, however. You want your theme to accommodate your content, not vice versa.
• Choose at least twelve themes that you like. You will find that you will not be able to use many themes that you choose for various reasons.
• Try and look only at the overall look and feel of a theme, with the idea that the colors, fonts, images, and most anything else can be customized to fit your needs.

Installing WordPress and Beyond:

• Use the following documentation to help with all of these steps:
  • http://codex.wordpress.org/Getting_Started_with_WordPress
  • http://codex.wordpress.org/WordPress_Lessons

• Installing WordPress
  • Choose a host. WordPress works best on a WordPress-friendly host. I use WestHost. They are affordable, reliable, and have fantastic tech support. Their personal starter plan for $6.95 a month is all you will likely need.
  • For a list of other WordPress-friendly hosts, go to WordPress.org.
  • Carefully read the installation guide on WordPress.org. WordPress is installed differently when you use it as a CMS than if you only use it to blog.

• Next Steps
  • Installing your theme
  • Customizing your theme
  • Deciding which plugins you need based on your initial plan
  • Installing and setting up your plugins (Always read the readme.txt file!)
  • Setting up your sidebars
  • Building your pages
  • Posting blog entries

Understanding Dynamic WordPress links

With most CMS environments like WordPress, there is a learning curve to understand how the URL structures work. When I was first learning how to develop WordPress themes, I would look through other themes to help get an understanding of how to call different templates or directories and I would often get mixed up. When a developer is transitioning from basic HTML website development to using a framework like WordPress these are important principles to understand. Here is a list of my most commonly used URL functions with example usages. These are all based from the Codex in WordPress.org.

Blog Name

You can use the Blog Name parameter to display the name of your blog ( or Website ) anywhere! For example, maybe you want the title tag for your site to just display the name of your website. You would do the following:

<title><?php bloginfo( 'name' ); ?></title>

Note: This is not an SEO recommendation by no means so don’t take it as that. ha You will probably always rank for the name of your website

Website URL

The URL parameter displays the URL of your website. This is very self explanatory, but many times I see themes using absolute URL’s ( http://www.wproots.com ) and not using the relative URL. Below is how you should display your relative URL. This is especially important if you plan on distributing the theme as the URL will continually change.

<?php bloginfo( 'url' ); ?>

Stylesheet Directory

For me, there isn’t another parameter that I use more than the stylesheet_directory parameter. What the stylesheet_directory does is reference the directory where the style.css file is in your theme. Here is an example of calling an image located in your images folder through your HTML.

<img src="<?php bloginfo( ‘stylesheet_directory’ ); ?>/images/myimage.jpg" width="…" height="…" alt="…" />

Note: Don't get confused when you see the term stylesheet in the parameter. All this is doing is referencing the directory or folder where the style.css file is located in the theme.

Template Directory

Template_Directory is a lot like the stylesheet_directory parameter except the usages are a bit different. The template_directory refers to the directory the theme templates are located in. From my experience, most basic WordPress themes do not use this parameter as it is not necessary to handle that basics of theme development. The template_directory parameter becomes very functional when building more advanced themes or applications. An example of this would be if you are using an MVC type structure or more complex theme options panels and you need to reference files deeper within the theme directory.

<?php bloginfo( 'template_directory' ); ?>/classes/myclass.php ?>

Again, I would highly recommend using these built in WordPress functions when developing themes and plugins. Let me know your thoughts and how you find them most useful!

Upload Media in WordPress Meta Boxes

Recently I was working on updating the Pro Photo theme and wanted to find a good solution for uploading media through a meta box. Previously, users had to click the little camera/music icon to upload images and we were getting a lot of support from people wondering how to add images. So basically, I am going to show you how we created an upload media button through meta boxes.

Step 1

First you will obviously need to create a metabox if you currently don’t have one. If you don’t have any meta boxes you can read our ultimate guide to meta boxes or on the codex.

Step 2

Secondly, there will be a callback in the add_meta_box function that you will need to locate. In my example, I am going to use an example callback function of media_uploader_box. Now that we have our callback function, lets begin to add some content and data to it.
We begin with a base function:

view sourceprint?

001	<?php function media_uploader_box(): global $post; ?>

002

003	<?php endif; ?>

Next if you want, you can add some css styling to your function. I will add a background color of #ccc.

view sourceprint?

001	<?php function media_uploader_box(): global $post; ?>

002

003	<style> .media-upload h2 { font-weight: bold; } </style>

004

005	<?php endif; ?>

Now it is time to add the necessary jQuery to call the media uploader popup.

view sourceprint?

001	<?php function media_uploader_box(): global $post; ?>

002

003	<style> .media-upload h2 { font-weight: bold; } </style>

004

005

<script>

006	( function( $ ) {

007

008	$(document).ready(

009

010	function()

011

{

012	$('#upload_image_button').click(

013	function()

014

{

015	tb_show('', 'media-upload.php?post_id=<?php  echo $post->ID; ?>&type=image&amp;TB_iframe=true');

016	return false;

017

}

018

);

019

}

020

);

021

022	} ) ( jQuery );

023

</script>

024

025	<?php endif; ?>

There are some points to make note of in this example. First, notice that we are attaching the click function to the upload_image_button ID. So when that ID is clicked, it will call this jQuery. Next, if you look at the URL structure being used in the popup we are using the post_id. What this will do is attach the media unique to this post. In our case we wanted to upload images inside of a custom post type and only have those images be registered with those posts.

Note: If you are looking to just add a general media uploader which is not post specific then replace line 15 above with the following:

view sourceprint?

001	tb_show('', 'media-upload.php?type=image&TB_iframe=true');

Step 3

Third, we now need to create our html for the meta box and for our button.

view sourceprint?

001	<?php function media_uploader_box(): global $post; ?>

002

003	<style> .media-upload h2 { font-weight: bold; } </style>

004

005

<script>

006	( function( $ ) {

007

008	$(document).ready(

009

010	function()

011

{

012	$('#upload_image_button').click(

013	function()

014

{

015	tb_show('', 'media-upload.php?post_id=<?php  echo $post->ID; ?>&type=image&amp;TB_iframe=true');

016	return false;

017

}

018

);

019

}

020

);

021

022	} ) ( jQuery );

023

</script>

024

025	<div class="media-upload">

026	<h2>Upload Media</h2>

027

<table>

028	<tr valign="top">

029	<td><input id="upload_image_button" type="button" value="Upload Media"></td>

030

</tr>

031

</table>

032

</div>

033

034	<?php endif; ?>

All that is going on here is that we are adding a title and table with a button. Simple stuff.

Step 4

The last step in the process is to make sure and include our necessary scripts to make the popup work. We are going to enqueue the given admin scripts from the core.

view sourceprint?

001	<?php function media_uploader_box(): global $post; ?>

002

003	<style> .media-upload h2 { font-weight: bold; } </style>

004

005

<script>

006	( function( $ ) {

007

008	$(document).ready(

009

010	function()

011

{

012	$('#upload_image_button').click(

013	function()

014

{

015	tb_show('', 'media-upload.php?post_id=<?php  echo $post->ID; ?>&type=image&amp;TB_iframe=true');

016	return false;

017

}

018

);

019

}

020

);

021

022	} ) ( jQuery );

023

</script>

024

025	<div class="media-upload">

026	<h2>Upload Media</h2>

027

<table>

028	<tr valign="top">

029	<td><input id="upload_image_button" type="button" value="Upload Media"></td>

030

</tr>

031

</table>

032

</div>

033

034	<?php endif; ?>

035

036	function admin_scripts()

037

{

038	wp_enqueue_script('media-upload');

039	wp_enqueue_script('thickbox');

040

}

041

042	function admin_styles()

043

{

044	wp_enqueue_style('thickbox');

045

}

046

047	add_action('admin_print_scripts', 'admin_scripts');

048	add_action('admin_print_styles', 'admin_styles');

049

050

?>

Thats it! Now if you are like most people and are looking to just quickly copy and paste the above code and expect it to work you might be sorely disappointed. The main point to reiterate is that you must name this function the same as your callback when you are adding the meta box. Again, if you are not sure what this means take a look at the add_meta_box function and how the callback works.
If you have any questions or comments please let me know below.

Add Search to bbPress WordPress Plugin

When working with bbPress I found struggles to get search to work properly, and hopefully after this article you wont have the same struggles I had. I didn’t see any point in building what is already built so I decided to first search the WordPress plugin directory to see what was currently available. After a few different plugins I settled on using Search bbPress from Stephen Carroll. Search bbPress works by extending the default WordPress search to include the bbPress custom post types. Now you know the basics, lets get started below.

This tutorial assumes you want all your theme search results being displayed in a table like your forums are structured.

Step 1:

Download and install the Search bbPress plugin. You can either search for the plugin from your WordPress dashboard or simply go here and download the plugin. Once you have installed the plugin go ahead and activate it. Nothing fancy or exciting will happen (that you can see ) but it’s working.

Step 2:

Go to your widget section under Appearance -> Widgets. Drag the default Search widget to the sidebar that you would like to display it in give it a title and that is it for step 2.

Step 3:

This step is where things could get a little tricky. Since bbPress forums are displayed using tables most likely the results look a little weird since your theme’s search.php doesn’t have the results being displayed in tables. If you think the results are just fine then you are good to go from here.
In my case, I wanted to have my results displayed in tables so I had to open the search.php and style.css files in my editor and make some changes.
Results in a table
First you need to find the loop in the page. The loop should look something like this:

view sourceprint?

001	<!--?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?-->

002

003	// Content inside the loop

004

005	<!--?php endwhile; else: ?-->

006

007	<!--?php _e('Sorry, no posts matched your criteria.'); ?-->

008

009	<!--?php endif; ?-->

Since we want each result to be inside a table row, we need to add the following inside our loop.

view sourceprint?

001

<tr>

002	<td><a href="<?php the_permalink() ?>><?php the_title(); ?></a></td>

003

004	<td><?php the_time('l jS F, Y - g:ia') ?></td>

005

</tr>

If you are not familiar with tables the tr stands for table row and the td stands for table data. So what this is doing is adding a row with the title and the time inside of the row. Now, we need to finish up the table information that will go outside the loop.
If there are results that are found, we want to display the table and give the table columns a headline. I am going to break up the loop and add a title to the results stating the results for what I searched for.

view sourceprint?

001	<?php if (have_posts()) : ?>

002

003	<h1><?php printf( __( 'Search Results for: %s' ), '<span>' . get_search_query() . '</span>' ); ?></h1>

004

005

<table>

006

<thead>

007

<tr>

008	<th>Title</th>

009	<th>Date</th>

010

</tr>

011

</thead>

012

013

<tbody>

014

015	<?php while (have_posts()) : the_post(); ?>

016

017

<tr>

018	<td><a href="<?php the_permalink() ?>><?php the_title(); ?></a></td>

019

020	<td><?php the_time('l jS F, Y - g:ia') ?></td>

021

</tr>

022

023	<?php endwhile; ?>

024

025	<?php endif; ?>

026

027

</tbody>

028

029

</table>

Now you should see your results being displayed just like your forum tables are displayed. Something I would recommend adding to your pages is a simple line of code to limit the number of results on your page.

view sourceprint?

001	<?php $posts=query_posts($query_string . '&posts_per_page=20'); ?>

You can change the 20 to the number of results you would like to display.
Here is the final code to display your search results.

view sourceprint?

001	<div class="search-results-wrap">

002

003	<?php $posts=query_posts($query_string . '&posts_per_page=20'); ?>

004

005	<?php if (have_posts()) : ?>

006

007	<h1><?php printf( __( 'Search Results for: %s' ), '<span>' . get_search_query() . '</span>' ); ?></h1>

008

009

<table>

010

<thead>

011

<tr>

012	<th>Title</th>

013	<th>Date</th>

014

</tr>

015

</thead>

016

017

<tbody>

018

019	<?php while (have_posts()) : the_post(); ?>

020

021

<tr>

022	<td><a href="<?php the_permalink() ?>><?php the_title(); ?></a></td>

023

024	<td><?php the_time('l jS F, Y - g:ia') ?></td>

025

</tr>

026

027	<?php endwhile; ?>

028

029	<?php endif; ?>

030

031

</tbody>

032

033

</table>

034

035

</div>

If you have other questions regarding how to display your forums or how to use bbPress shortcodes, see the following posts:

• How to setup and install bbPress forum
• bbPress Shortcodes

WordPress Plugin Development Strategies

When you begin building a WordPress plugin, there are a lot of things you need to keep in mind: the functionality of the plugin, the target audience, how it is going to be distributed, how you are going to provide support for it, etc. There is another aspect of the development process that is often overlooked or pushed to the sidelines, and that is the set of general strategies you are going to use during your development.

When I say “general strategies”, I’m referring the things like the basic file / folder organization, the naming scheme for your files, the organization of functions within files, and the way that resources are loaded. It is best if you make an effort to keep these aspects constant throughout your development. When you use the same basic strategies for each of your projects, and throughout each individual project, you will find that it dramatically improves your workflow and the overall quality of your work.
Imagine you are writing a plugin that has upwards of 10,000 lines of code; which do you think is easier to enhance and debug, a plugin that has the 10,000 lines separated into meaningfully named files and folders, or a plugin that has all 10,000 lines in a single file? If you have answered with a single file, then I’d highly advise you to think about it a little longer, or challenge yourself to go write a very large plugin, and do it all in one file. You will quickly find that it’s highly disadvantageous.
I would like to discuss and share several aspects of my personal development strategy. Some of these are simply things that should be done because WordPress Coding Standards dictates that we should (with good reason), and some of them are strategies that I have simply found to be extremely helpful in development.

Use a Unique Prefix for Everything

This is one of the first rules of development, and it should never, ever be broken. When you write your plugin, everything absolutely must receive a unique prefix specific to your plugin. This includes function names, class names, global variables, option names, database tables and more.
The primary reason for always, without exception, using prefixes is that it prevents conflicts. If two plugins (or themes) use the same name for a function, and both are active at the same time, they will cause a fatal error, since all function names must be unique.
For example, you might have a function in your plugin like this:

view sourceprint?

001	load_plugin_scripts() {

002	// script loading happens here

003

}

But this is a terrible name, because if any theme or other plugins also has a function named load_plugin_scripts, a fatal error will be thrown. Let’s imagine for a moment that your plugin is named “Load Posts with Ajax”. I usually create my prefixes by taking the first letter of each word in the plugin’s title, so our prefix will be “lpa_”, or “lpwa_”, which means our function should be this instead:

view sourceprint?

001	lpa_load_plugin_scripts() {

002	// script loading happens here

003

}

Define Constants for File Paths and URLs

This mostly applies to large plugins, but can be useful with smaller ones as well. The absolute path to your plugin’s folder can be used for including extra plugin files, loading templates, and a few other things. I usually define a constant with the path to the plugin’s directory like this:

view sourceprint?

001	// plugin folder path

002	if(!defined('LPA_PLUGIN_DIR')) {

003	define('LPA_PLUGIN_DIR', plugin_dir_path( __FILE__ ));

004

}

Remember that “LPA_” is the prefix we created for our plugin above.
It is also a good idea to define a constant for the plugin directory’s URL. This will be used for loading assets, like images, CSS files and Javascript files.

view sourceprint?

001	// plugin folder path

002	// plugin folder url

003	if(!defined('LPA_PLUGIN_URL')) {

004	define('LPA_PLUGIN_URL', plugin_dir_url( __FILE__ ));

005

}

While these constants are not entirely necessary, they do make things easier in the long run. Instead of figuring out the file path or URL every time you need it, you simply call the constant. In large plugins this can save a lot of time.

Organize Your Plugin Into Multiple Files

When you are working with a plugin that has a large amount of code, then separating it into multiple files is one of the best things you can do. You should separate your code into “blocks” that are organized based on what they do. For example, all of your short code definitions should go into a file called “shortcodes.php” (or similar). All of your code that relates to loading CSS or jQuery should go into a file named perhaps “scripts.php”.
By separating your code into “blocks” that are each placed into meaningfully named files, you make your job as the developer much easier on yourself. It is suddenly dramatically easier to locate the code you’re looking for, especially when debugging errors. When you want to enhance the functionality of your plugin, perhaps by adding another short code, you immediately know where the new code should go: shortcodes.php.
With smaller plugins, this is not always the case, however. A small plugin with just 100 lines of code could easily be all placed into a single file and still be very manageable, but even in this case, I would still advise you to separate it into multiple files. The main reason for doing this is that it opens the door to further development and expansion. It is a lot easier to organize your plugin early on when there is only a small amount of code than it is to reorganize later once you have thousands of lines.
Once your plugin is separated into multiple files, you will pull the files into the main plugin file like this:

view sourceprint?

001	include_once( LPA_PLUGIN_DIR . 'includes/shortcodes.php' );

Note that I advise you place all of your extra files into sub directories as well. I usually place my files into a folder called “includes” (because these are included into the main file), and this directory will often have sub directories within it as well.
My plugin folder structure usually looks something like this:

• my_plugin_folder_name
  • includes
    • admin-pages
    • templates
  • js
  • css
  • images

Format Your Code

There is very little more frustrating to a developer than opening some one else’s code and finding that it is a formatting nightmare. Messy code is usually bad code. A very simple way that you can dramatically help yourself in your development, and help anyone that works with your code, is by taking the time to format your code nicely and consistently.
Code should have even indention (I prefer tabs, not spaces) and consistent line breaks. When a chunk of code is nested inside of conditional or switch (or other) statements, it should be indented. Take this bad code for example:

view sourceprint?

001	if( $conditional ) {

002	do_action('some_action_here');

003	execute_some_function();

004

}

While there are only two lines inside of the conditional, this is still much harder to read and follow than a block that is properly indented:

view sourceprint?

001	if( $conditional ) {

002	do_action('some_action_here');

003	execute_some_function();

004

}

Just imagine how hard it is to read a plugin that has 100s or 1000s of lines of code that isn’t properly indented. It becomes a debugging nightmare.
Do yourself and everyone else a favor: indent and format.

Do Not Reinvent the Wheel

There are a lot of APIs and methods built into WordPress that are designed to make your job as a developer easier, so utilize them and save yourself the trouble of building your own solution.
For plugin options, use the Settings API. This API can be a bit confusing to work with at first, but once you figure it out, it is really quite simple, and extremely powerful. Tom McFarlin wrote a phenomenal tutorial series on using the Settings API, if you are unsure about it then definitely check his series out.
For showing data in your plugin in a table format (like Posts and Pages), there is a class called WP_List_Table. This class will do all of the heavy lifting for you, including pagination, filtering, bulk actions, etc, all you have to (to start at least) is provide an array of data to populate the table with.
When creating custom admin screens, make sure of core WordPress CSS. There is absolutely no reason to write dozens (or hundreds) of lines of CSS to style your custom admin pages when, instead, you could use the core styles included with WordPress. There is a pretty decent guide to admin styles at One Extra Pixel.
There are many other general strategies that you can use during development, but these alone will help you tremendously if you choose to follow them.

Options for Responsive Themes

Over the past six months it seems that there has been a large push for responsive design so I felt it necessary to layout a few different options for your next WordPress theme. Below is a list of recommended frameworks and grid systems to get started with.

Bootstrap from Twitter

12-column grid with fixed and fluid width layouts

Skeleton

960px grid system

Columnal

1140px fluid width system

1140 CSS Grid

12 column fluid system that starts at 1280px

Gumby Framework

960px grid with fluid or fixed layouts

Foundation 3

12 column fluid system

---

The above list is by no means comprehensive although I have personally used many of these options and would recommend them for your next WordPress theme. Feel free to take a look at these options and let me know what you prefer to use for your themes.