HTML & CSS (CCW Part 2)

After you’ve figured out navigation, layout, and sent out requests for content, it’s time to start building your site. This lesson deals with basic HTML and CSS along with best practices using for both.

There are many web editors out there, but for this lesson I’ll be using Dreamweaver’s basic starter page for my example.

Starting on the build

So, let’s have a look at what a blank page looks like in code. A basic Dreamweaver HTML page is shown below:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Document Title</title>
</head>
<body>
</body>
</html>  

There are six parts here that make up a solid base for your page. Your Doctype, html  tags, head tags, meta data, the title tags, and last the body tags. All are part of the HTML code.

HTML (HyperText Markup Language)

Your HTML is the skeleton for your CSS. It supports the body of your webpage while CSS provides the muscles and skin. Therefore, if your HTML is incorrect, it doesn’t matter if the CSS is perfect, your website will fail.

First off, let’s talk about HTML and XHTML (Extensible HyperText Markup Language). HTML is mainly comprised of tags like the example above. XHTML is not very different from HTML- except that it’s stricter which allows browsers to process the code faster and eliminate errors caused by incorrect markup.

For example, <img src=”example.jpg”> would not display in XHTML because the ‘img’ tag is not closed. To display correctly, it would need to look like this:<img src=”example.jpg” />

Yes, the ‘/’ needs to be at the end of every tag to close it in XHTML.
HTML is not so picky and will take either <img src=”example.jpg”> or <img src=”example.jpg” />.

Generally, it is good to use HTML for your doctype, but practice XHTML within the HTML. Why? Because it’s better for the browser.

XHTML within HTML

By following all the XHTML rules you help the browser load pages faster and it’s less confusing to search through. That’s where XHTML is a plus- however, you may not know all the rules of XHTML, or you might miss a rule by accident, rendering your whole page useless until you find the problem. HTML doesn’t care about little mistakes, so by using XHTML style in and HTML page, you cover accidental code flubs so that your page will still work when you open it.

Some major differences in XHTML and HTML

HTML

<br>      <hr>       <img src="example.gif">
<P>Something</P>

XHTML

<br />      <hr />      <img src="example.gif" />
<p>Something</p>

For more on XHTML rules:           http://www.w3schools.com/xhtml/xhtml_html.asp

HTML Basics

NOTE: I’ll be writing in XHTML, but I use it within an HTML framework. Keep this in mind.

What is a “doctype” and why is it on my page?

First off, the doctype declaration should appear before any other markup on your page. Why? Because it is an instruction to the web browser about what version of the markup language (eg: HTML, XHTML and their variants) the page is written in.

For more on this see:            http://www.w3schools.com/tags/tag_DOCTYPE.asp

Placement

The placement of code in the HTML specifies what elements are within elements and their hierarchy to other elements. For example, let’s say I wanted a box within a header. I would have:

<div id=”header”><div class=”box”>Box Content</div></div>

The ‘div’ tag calls the CSS to place the header on the page and insert the box into the header. It is very important to close your divs as it tells the CSS styling to stop past the ‘</div>’ point. It is also important to nest your tags to avoid conflicting style properties or code errors. To style the elements for each div tag, you must go into the CSS and not the HTML. Remember that most HTML is strictly for organizing.

<head>…</head>

Your ‘head’ tags should contain all information a browser needs to render the content in the ‘body’ tags as well as information pertinent to search engines and browser needs for your page.

Tags used in the ‘head’ are:

<title> ... </title>      displays title of page for the browser to put on the tab or on the window’s title bar
<meta />  gives data for search engines to organize your page by/tells what your page is about
<base />   specifies a default address or a default target for all links on a page
<link />  gets a resource reference such as a CSS style sheet

An example for calling a style sheet is below.

<link rel="stylesheet" href="style.css" type="text/css" media="screen" />

So, what’s going on here?

Well, ‘rel’ says that the relationship between the current document and the linked document is that it’s a style sheet, ‘href’ calls the actual style sheet from its location,  ‘type’ tells us that the style sheet  is formatted in text/css, and ‘media’ tells us that it’s for a computer screen.

If you wanted to make this style sheet for a phone, you would change ‘media=”screen”’ to ‘media=”mobile”’. ‘media’ allows you to have multiple style sheets on a page that target different devices. (ex: style sheets for mobile, print, and screen)

<body>…</body>

Your ‘body’ tags contain the page elements that will show up in the browser window. Organization of these elements is key. Keep your tags correctly nested. I can not stress this enough. Keeping tags well organized in your code will help in a lot of ways.

Some commonly used tags in the ‘body’ are:

<h1> ... </h1>  creates a heading with h1-h6, h1 being the largest and h6 being the smallest
<p> ... </p>    organizes content into paragraphs
<a></a>  designates a link
<img /> places an image within the page
<br /> puts a break in-between text
<hr /> creates a horizontal rule- ie, a line- between elements
<strong> ... </strong>   strong emphasized text (bolds text)
<em> ... </em>  emphasized text (italicizes text)
<ol><li> ... </li></ol>  ‘ol’ is an ordered list, ‘ul’ is an unordered list, ‘li’ in both ‘ul’ and ‘ol’ is a list item
<div> ... </div>  tag defines a division or a section in an HTML document- mostly used to call style elements from the CSS
<form> ... </form>  used to place a form element within the page

Some natural hookups:

There are some tags that naturally have certain things following them.
For example, <a href=”...”> ... </a>.

‘a’ says that it’s a link and ‘href’ tells the link where to go. <img src=”...” /> ‘img’ says that the element is an image and ‘src’ tells the location of the image you want displayed.

Putting together CSS and HTML using ‘div’

The ‘div’ tag when used with CSS will either have ‘id’ or ‘class’ attached to it.

ex: <div id=”...”> ... </div> or <div class=”...”> ... </div>

A ‘div’ can have multiple classes attached, but only one id. Also, a certain id can only be used once on a page where as a certain class can be used multiple times.

ex: <div id=”container” class=”numberone” class=”numbertwo”> ... </div>

BEST PRACTICES

  • Put CSS in the header just above the </head> tag. (In order to have all styles ready for the body when it loads.)
  • Put links to scripts as well as scripts themselves (ex: jQuery, mootools, javascript) at the bottom of the page- just above the </body> tag. (This encourages faster page loading.)
  • Keep things well organized and, when necessary, document where your div tags end like so: </div> <!-- example div ends here -->
  • Nest your tags.

CSS (Cascading Style Sheets)

Getting the look

The main styles of the site, look and layout, are controlled mainly through CSS. If you need to edit the presentation of an element, div, or id use CSS. CSS and HTML together make a website fast loading and easily customizable. Using a CSS style sheet, you can change an element of your site across all the pages that have that element simply by editing your CSS. This cuts down on mistakes and makes your time spent on code more efficient.

CSS Example

Some examples of CSS.

h1 {
font-size: 2.6em;
padding:5px 0 20px 0;
}
#content {
padding-top:15px;
font-family:Verdana, sans-serif;
}
.sec-nav {
padding:0;
margin:0 0 30px 0;
}
li:visited {
color: #00CC00;
text-decoration: none;
font-weight: bold;
}  

Writing style

Before we get into the guts of this operation, I’m going to tell you about how people write the optional parts of code.

There are 3 types of naming conventions:

  • camel case
  • dash
  • underscore

Let’s say I have something in my CSS I want to call “Slider Thumbnails”.   Well, spaces are defined as starting something new, so I can’t use the above. Solution- one of the 3 naming conventions.

Camel Case:      sliderThumbnails

Dash:                  slider-thumbnails

Underscore:      slider_thumbnails

Which do I use? I use underscore because it seems easier to read for me, but this is all subjective. You pick the style that works best for you. What is important is that there are no spaces within the name.

About CSS

CSS can be used in three different ways: inline, internal, and external.

Inline is when you use ‘style’ attached to an element to build CSS for a single element within the HTML.

ex:   <p style=”color:red;”>…</p>

Internal is when you place your CSS styles in the ‘head’ tags.

ex: <head>
<style type="text/css"> p  {color:red;} </style>
</head>

External is when you have a separate style sheet and link to it from the ‘head’.

ex: <link rel="stylesheet" href="style.css" type="text/css" media="screen" />

The external style sheet will have formatting like this inside it: p  {color:red;}

What is a CSS format?

CSS creates a selector for HTML to use when you group elements you want styled on your page. The selector then has notes on what properties you want added and what you want the properties to be.

ex:   selector { property:value; }

There are 2 ways of organizing CSS: single line and multiple line – both are correct so it’s a matter of preference which one you use.

selector { property:value;  property:value; }

selector {
property:value;
property:value;
}

Your selector can be named anything you want. (With the exception of element selectors.)

Different types of selectors

There are different types of selectors: element, id, class, and pseudo.

Element selectors retain their proper html titles such as ‘body’, ‘p’, ‘h1’, ‘ul’, ‘ol’, ‘a’, ‘img’, etc… and do not use any identifying features. ex:  img

Id selectors use ‘#’ before a name and are unique.  ex:   #container

Class selectors use ‘.’ before a name and are not unique.   ex:   .thumbnail

A pseudo selector uses ‘:’ and must be attached to an element selector.    ex:    a:hover

As stated before in the html section, an ‘id’ is unique and the same id can’t be used numerous times on a page. Use ‘id’s for main containers and other large boxes on a page. A ‘class’ is not unique and can be used multiple times on a page or multiple times on an element.

For more on this see:            http://css-tricks.com/the-difference-between-id-and-class/

Property and value

A property in CSS tells what you want to style within the selector and the value tells how you want it styled. For instance, I would like a red boarder around my header.

ex:   #header  {border-color:red;}

“#header” would be my selector while “border-color” would be my property. “red” is the value I want displayed as the “border-color” on the “#header”.

There are many different types of properties. Some deal with position while others handle styles and spacing. For a full list of properties, see http://www.w3schools.com/css/css_reference.asp and scroll down to CSS Properties.

Decoding CSS

Let’s take apart this CSS.

#wordmark{
background:url(images/wordmark.png) top left no-repeat;
width:709px;
height:112px;
position:absolute;
top:0px;
left:10px;
text-indent:-9999px;
margin:0;
}

It’s an ‘id’ named wordmark.
It has a background image placed in the top left and the image is not repeated.
It’s 709×112 pixels, and its position is absolute on the page with the coordinates being top 0 and left 10. It has a text indent of -9999px, which means the text is hidden off the page, and the margin is 0 so other elements will come right up against it.

Most CSS properties are easy to figure out. Especially in things they control. Just use common sense and in most cases- what you think it does it what it does. Some tricky properties are ‘color’, which actually controls the color of your text, and ‘margin’ vs ‘padding’.

Margin determines the amount of space around your element.
Padding determines the amount of space within your element.

Bundle up

Sometimes you want to specify a lot of things that actually all relate to one property. Well, there is a way to do that.

background:#990000 url(images/footer-bg.png) top left repeat-x;
font:bold 1.7em/175% "Lucida Sans",Lucida Sans Unicode,Verdana,Helvetica,sans-serif;
border:1px #ccc dotted;
padding:4px 0 4px 4px;
margin:3px 0px 10px 15px;

This helps lighten your code and makes things run faster. It also makes things easier to find.

BEST PRACTICES

  • Separate your sections with descriptive headers. (ex: /* styles for slider */)
  • Use CSS to style all links and header elements so that they appear the same throughout the site.
  • Watch out for conflicting CSS. In order to remove conflicts, sub list the element when necessary. (ex: #containingDiv h1)

What is a WordPress theme?

Whether you plan to build your own theme or apply an existing one, an important part of getting started with WordPress is understanding what a theme is — and what a theme is not.

It would be easy to say a WordPress theme allows you to customize the way a WordPress blog or website looks. You might refer to such a thing as a skin. WordPress themes can and usually do affect the look of your site/blog, but that’s not all they do. Here’s how the Using Themes page of the WordPress Codex describes the difference:

Fundamentally, the WordPress Theme system is a way to “skin” your weblog. Yet, it is more than just a “skin.” Skinning your site implies that only the design is changed. WordPress Themes can provide much more control over the look and presentation of the material on your website.

A WordPress Theme is a collection of files that work together to produce a graphical interface with an underlying unifying design for a weblog. These files are called template files.

I tend to think of a skin as something that would only control things like the color, layout, and typography of the information on a website. WordPress themes control those things, but they also have the ability to control which information is displayed. In other words, you don’t just use your theme to show a blog post in a certain typeface with a certain background color, you use the theme to control whether your home page shows an excerpt of each post or the whole post, or whether the date the post was written shows up underneath the title, or a hundred other similar things.

To really get how this works, it helps to understand the difference between the back end of WordPress and the front end.

The back end of WordPress is a MySQL database organized into 11 tables (as of WordPress 3.0). You can read more about the tables that are set up in the default installation on the Database Description page of the WordPress Codex.

The database, or back end of WordPress, includes the content of the posts and pages you write as well as a lot of other information that gets added and edited as you work inside the WordPress Admin Panel.

The front end of WordPress is pretty much whatever the theme says it is. So when you choose a theme, or build your own theme, you determine which information gets pulled from the database, where that information shows up within the structure of your site, and how it is displayed to the user as far as colors, fonts, and other properties that can be controlled via CSS or other means.

In that sense, a WordPress theme controls not only how your website looks, but what the website actually is.

Organization and Introduction (Crash Course in Web Part 1)

Over the past year I’ve found myself doing more and more teaching on web development. Considering how much I’ve invested in it, I decided to post some of my updated lessons here on WebTide for others to look over.

The first lesson deals with organization and planning while further lessons will handle coding. As these lessons were originally intended to be handouts for a lecture, please feel free to post any questions on the material in the comments section. I can’t promise I’ll get to them all, but I’ll try.

Setting up structure for a website

Most people don’t know how essential good navigation is- but every website I’ve ever built has required at least an hour of debate over navigation.

Navigation is very important as it organizes the content flow on your site. While planning the navigation, make sure to stress the user’s point of view. Role-play if you must. Imagine you know nothing about how the company works and just want to find something- where would you most likely look for it? This should help you construct the primary navigation. Lesser links can be placed in a sub navigation that’s not as prominent or used as secondary navigation within pages.

People generally don’t like clicking more than 3 times to find what they want- but they also don’t wish to be stuck on the first page for hours searching for the link they need. To help solve this problem, use umbrella terms in your main navigation and let your secondary navigation fine-tune the section. In the best possible situations you’ll only need these two levels. Larger sites with more content may require further links, but place them within the page to avoid confusion or frustration.

Tip: When working out your navigation, don’t fixate on users who are only going to visit your site once. Plan for those who will be visiting your site frequently and make sure their content is easily accessible.

Create a navigational chart

In order to make sure everything is correct, mock up a navigational chart. In this way, clients will be able to see the site’s flow and easily edit mistakes. This heads off a lot of arguments before you start coding since some people need to see navigation before they understand it. Two recommended ways to create a navigational chart are in outline style or as a data tree. Both have inherent hierarchy when created and allow for easy secondary navigation insertion.

Create a content layout model

How information is displayed on a page is also important. Remember that your users will usually be looking for one specific bit of information and won’t want to read your entire site to get it. Make things easy to spot on a page by using well-defined headers and bolding/italicizing only very important elements.  Organize your page in a way that will allow the user immediate access to the information they want with a simple scan.

For each page, your content layout will naturally differ depending on the type of information. Understanding your audience, and what your audience wants, helps identify which elements are important, and where these elements should be placed. The one exception would be your home page, which should focus on emotional impact in addition to user needs. This impact is often accomplished by having a picture, illustration, or good typography showing what the organization is about.

When working on a home page layout, you may find that sketching out your ideas can be very helpful. They don’t have to look professional, they just act as a visual guide to help place your content. Use a grid and plan your layout with boxes and squiggles. This helps you figure things out before you start coding and saves time.

BEST PRACTICES

  • Have main umbrella navigation terms for your main menu and keep them short.
  • Keep important information within 3 clicks of the user.
  • Advocate for the users of the site.
  • Outgoing links should never be placed in your main navigation, though there are some exceptions.
  • Keep in mind that companies tend to know their customers and business. If they insist on something you think is bad practice, compromise or give in depending upon the situation.

Getting comfortable with content

When it comes to reading a site, people want content to be clear, concise, and legible. In order to facilitate this, shorter sentences are used and body copy fonts are mostly sans-serif. There’s a good reason you see Verdana and Arial on the majority of web pages. Every computer has them pre-installed and they’re easy to read at smaller sizes.

Request content before you start coding the site, but after you’ve got the navigation planned. It takes time for people to write and by letting them know what you want, before you need it, the process will go much smoother. However, there may be times when you’ll need body copy and none is available. This might crop up while you’re building a site and want to see how content will look in your layout. For this, most turn to the old printer’s resource of Lorem Ipsum.

Lorem Ipsum is dummy text and has been used by the printing and typesetting industry since the 1500s. When websites came along, the same principles were used in their creation and thus the text made the leap from paper to screen. Just make sure that Lorem Ipsum is erased when you get the actual content.

Trivia: Lorem Ipsum is Latin and comes from Cicero’s “de Finibus Bonorum et Malorum” which was written in 45 B.C.

Image content is another beast altogether. A few things I recommend are getting a professional photographer or going to a stock photo site. With professional images your site will look better and inspire more trust with users. Also make sure your image conveys the same message as your text. Think of a few adjectives that describe your organization. Do those adjectives apply to your pictures? If not- don’t use them.

BEST PRACTICES

  • Request content ahead of time.
  • Use bolding and italicizing sparsely for only important elements- the more bolding and italicizing you have, the less important and more confusing those elements become.
  • Make sure your content is edited for grammar and spelling.
  • Use professional images that convey your organization’s purpose throughout the site.

WORST PRACTICES

  • Don’t center your content- especially with paragraphs.  Centering rarely looks good and reading from a jagged edge is hard on your users.
  • Using too many fonts is confusing. Limit yourself to 2 different fonts (usually one serif and the other sans-serif) and use one font for headings and one for body copy.
  • Some fonts are downright inappropriate for their subject matter. Comic Sans gives a childish feeling and unless your site deals directly with children- don’t use it.
  • Stay away from site traffic counters or gif animations. They date your site like nothing else.



Welcoming our newest team member

Rachel Carden officially joins the Web Communications team today, and we’re excited to have her on board.  She is a talented designer and developer who comes to us from Samford University, and is a UA graduate who is excited about being back at the Capstone.  She’s a great addition to our web community at UA, and we’re looking forward to seeing her contributions!

Permalink options for custom post types in WordPress

I recently did some work with custom post types in WordPress. As I finished setting up my first custom post type, the last thing I got hung up on was customizing the permalink settings for the new post type. It’s a really easy thing to do, but it took me a few minutes to figure it out, so I wanted to write a quick post describing the options in case that would help anyone else.

Obviously before you can deal with the permalinks settings for your custom post type, you have to have a custom post type. Today’s article does not address that (at least not comprehensively), but there are plenty of great resources that describe that process. Here are some of the ones that have been helpful to me:

Let’s say you’ve defined a custom post type called “Helpful Hints” with the following settings (this code would go in the functions.php file within your theme):

<?php
add_action('init', 'my_custom_init');
function my_custom_init()  {
register_post_type('hints', array(
	'label' => __('Helpful Hints'),
	'singular_label' => __('Helpful Hint'),
	'public' => true,
	'show_ui' => true,
	'capability_type' => 'post',
	'hierarchical' => false,
	'rewrite' => false,
	'query_var' => false,
	'supports' => array('title','editor','author','thumbnail','excerpt','comments')
  ));
}
?>

As you might guess, the part we need to work with to modify the permalink settings is the rewrite argument. The default of rewrite is true, but in the code above we have it set to false. Having it set as false will disable so-called “pretty URLs” (even if you have “pretty URLs” enabled in your general permalinks settings) and result in your custom posts having URLs like this:

http://www.yourwebsite.com/?post_type=hints&p=323

Remember, the URL above is not the default, but I wanted to show you the “ugliest” URL first and work up from there. As you can see, the post_type shows up exactly as we defined it in register_post_type (hints) and the post ID is added to the query string as well.

If we change the rewrite argument to true, we’ll get this instead:

http://www.yourwebsite.com/hints/how-to-do-something

This is the default when you have “pretty URLs” enabled in your general permalink settings. That is, if we included no rewrite argument in the register_post_type arguments, this is what we would get. Again, remember that the text for the slug (the part after the .com/) will be taken directly from the post_type, not from the label, or the singular label, or anything else.

In most cases, that will probably be sufficient. But suppose for a minute that you don’t want just “hints” to show up as your slug. Let’s say you want something a little more descriptive, maybe something like “helpful-hints.”

You can do this by adding an array that assigns a slug in the rewrite argument:

<?php
add_action('init', 'my_custom_init');
function my_custom_init()  {
register_post_type('hints', array(
	'label' => __('Helpful Hints'),
	'singular_label' => __('Helpful Hint'),
	'public' => true,
	'show_ui' => true,
	'capability_type' => 'post',
	'hierarchical' => false,
	'rewrite' => array('slug' => 'helpful-hints'),
	'query_var' => false,
	'supports' => array('title','editor','author','thumbnail','excerpt','comments')
  ));
}
?>

Since the default value of rewrite is true, we’re already going to have a “pretty URL,” but the slug array gives us a more descriptive URL without affecting anything else as far as labels and such. The result looks like this:

http://www.yourwebsite.com/helpful-hints/how-to-do-something

To review, for a WordPress site that has “pretty URLs” enabled in the permalinks settings, here’s how your custom post type permalinks will display with various rewrite settings:

  • By default: Rewrite is set to true but with no custom slug. The post_type will be used for the slug in the URL.
  • Rewrite set to false: The URL will revert to a query string in the URL that includes the post_type and the post ID. This will happen even if your site has permalinks enabled in the general settings.
  • Rewrite set to true with slug defined: This will result in a pretty URL with any slug you choose.

One final thing to keep in mind here is that anytime you change the rewrite settings in your code, you will need to open your permalinks settings screen in the WordPress Admin panel to flush the rewrite rules. Without doing that, your changes will not go into effect. For more information on this, check out ticket #13022 on the WordPress trac.

WordPress University webinar on Higher Ed Experts

Just a quick announcement about a unique professional development opportunity in the new year…

It’s no secret that we in Web Communications are big fans of WordPress, and we’ve addressed our use of WordPress as a content management system for institutional sites here plenty in the past.  Now we’re partnering with Higher Ed Experts to conduct a webinar on using WordPress in higher education.  The WordPress University webinar is set for March 22, 23 & 24, 2011, and our WordPress guru and developer Matthew Muro will be delivering the second panel, titled “How to create a branded WordPress theme for your decentralized units.”  Other participants include Mike Richwalsky from John Carroll University and Stephanie Leary from Texas A&M University.

If you’re interested in exploring the use of and application of WordPress in greater depth and getting hands-on with using WordPress to manage your college/division/department web site, I’d encourage you to sign up for the webinar – it’s going to be a great class.  If there is interest from multiple areas, we can possibly organize a group session on campus – just let me know in the comments section or shoot me a message.


WordPress University:
Strategies, tools and shortcuts for WordPress-based higher ed websites
March 22, 23 & 24, 2011 – 1PM-2PM ET
More Information and Registration

Restrict Categories – My Experience Writing a WordPress Plugin

Two months ago today I released my first WordPress plugin, Restrict Categories, and in that short time it has already reached over 1,000 downloads.  I thought this milestone was a good chance to write about my experiences developing a plugin.

Background

A couple of months ago, I was doing some research for a project here at Web Communications and it needed to have a particular functionality within WordPress.  We needed to control which categories certain users would be able to edit and post.  At first, I had hope this was possible because I discovered several plugins that appeared to accomplish what I wanted.  However, I quickly realized that none of them worked or didn’t really do what I wanted them to do.  My options were slim: 1) fix one of the broken plugins or, 2) write my own.  After trying to fix a couple of the plugins that had promise, but failing to do so, I started the process of developing my own.

Where to start?

The first place I looked was the WordPress Codex and leaned on it heavily in the early goings.  Specifically, I looked at the Plugin Development pages.  The pages I relied on the most were Writing a Plugin, Adding Administration Menus, Creating Options Pages, and the always helpful Function Reference.

I also think it’s beneficial to check out WordPress Coding Standards, Inline Documentation, Internationalization, and Data Validation.

Initial Development

In very basic terms, this is what I needed my plugin to do:

  • Display a list of all user roles (Administrator, Editor, Author, etc)
  • Display a list of all categories next to each role
  • Allow the plugin user some way to select categories and assign them to that author
  • On the Posts screen, display only those posts with categories from those selected above

Tackling development on this went in pieces.

  1. Create the basics of what I need to get my settings page to show up in the WordPress menu
  2. Get a list of user roles
  3. Get a list of all categories
  4. Combine all of these things on my plugin page and have a process that saves the information to the database
  5. Use that information to filter the Posts screen for restricted user roles

Some of these steps were easier than others and there were many days where I tried one thing, thinking it was the solution, only to be deterred and abandon it for a different route.  But, after a week and a half of trial and error, I finally had a working plugin.

Getting my plugin in the WordPress Plugin Directory

If you’ve ever wondered how people get their plugin on the WordPress.org site, you first start with the Plugin Developer Center.  I signed up and then began my learning process with SVN (Subversion).  Having never used SVN before, I was a bit unfamiliar with where to start or what program to use!  If you are on a Mac, your best bet is to use Terminal.  There are some graphical interfaces that are supposed to make it easier, but I then found it hard to follow the SVN directions from the WordPress documentation.

Anyway, once I figured that out, my plugin was soon live and being displayed in the “Newest Plugins” section.  Very cool.

Improvements

In many ways, Version 1.o had many of the pitfalls that most newbie WordPress plugin developers fall victim to.  In fact, I’m pretty sure I was committing a couple of these Top 10 mistakes.  I was also getting some users with errors.  So, I began troubleshooting my code as well as looking into how to make my plugin better.

For the first couple of revisions, the updates were mainly bug fixes.  Then, I decided to test it in the alpha version of WordPress 3.1.  One of the changes they made to the Posts screen inadvertently would allow a restricted user to bypass all restriction and they could get to a post they weren’t allowed to view.  What was even worse was that I couldn’t figure out how to fix my code to make it work with new Posts screen.  Uh oh.

So, I reached out to the WordPress community asking for a solution.  I asked a question on the wp-hackers mailing list and, when I couldn’t get a workable solution there, headed towards the WordPress Stack Exchange.  Luckily, someone responded with an answer.

I was resistant to the “solution” presented to me at first because I felt I was so close to the answer and was getting the run-around.  What I was really doing was not wanting to do the work to change my code.  However, once I actually took the time to work this solution into my code, I realized it was better.  This wasn’t the last time that asking a question in the community led me to a better solution.

It took two months and 1,000+ downloads to make me a better WordPress developer and a better PHP coder.