Brass Blogs: Web Design & Development

NOTE: October 5, 2010
Just letting you know that for some reason, some of this custom post type info does not transfer well. I used this one a site recently, and through SQL exports, I’ve discovered that the information within *some* of these fields does not get retained in an SQL export, and when you move your site, you lose some fo the info. Now, I don’t know if that’s just something in MY theme files for the project I was doing, or if it’s something in these examples that causes information to go missing, but I’m just making you aware of the possibility.Most likely it’s the former, since this doesn’t happen to ALL of the custom fields, but only a few.

I just wanted to make you aware so if it happens to you, you’ll already know I know, and I’m trying to figure it out.

As promised (from earlier today) I’m going to supply a small tutorial. Over the last few weeks, I’ve actually been bombed with requests on how to do this, and I’ve been happily passing out my code to anyone who’s asked for it. (I think it’s because of this comment I left on Liam McKay’s site. I guess it piqued a lot of interest.)

I will also say that, earlier today, I mentioned that the tuorial he provides was tossing up errors for me – which it did – but as it turned out (in my checking of the code I’m about to give you) that it was *my fault* – not his. So I apologize for saying that before. His tutorial – as it stands, works just fine in WordPress 3.0. it was my fudging with it to make it work with different field types what was munging it.

That being said, I won’t rehash Liam’s entire tutorial. He covers the basics of what’s going on just fine. I don’t feel it’s necessary to reinvent the wheel there, so I’m not going to rehash all of that here.

However, I’ve had several projects where these panels come in very handy. But I wanted to use something other than text input to retain the values. In some cases, using a checkbox or radio button would work much better. Makes it a lot easier for the client, you know? In. 2.9.x, I had this working just fine*, but the shiny, new updated version made it slightly more difficult to pull off. but I did it, because i needed it. So I’m going to tell you how I did it so it’ll help you.

You know, because I’m good like that.

If you’d like to download the basic plugin that shows the whole shebang, you can click here and take a gander: Add Post Meta Files

So the point of this is to expand upon the genius that is the Custom Write Panels Tutorial. A couple of things I will note is when I’ve used this in the past, and I wanted to do one set of stuff for posts, and a different set for Pages… it just makes everything a lot easier to just use this as a plugin instead of plunked into your functions.php file. For me, anyway, trying that just made my functions.php file immensely huge, and I was always fighting with conflicts. So I’ve found it easier to manage to just make ‘em plugins. But feel free to do what you like!

Now I’m thinking I could just use the array values to decide what types of Pages or posts these shoudl go on… hmmm… I feel an experiment coming on…

So the changes I’ve made to Liam’s tutorial is fairly simple, really. It’s basically adding a little bit more to your arrays in the beginning, and adding some conditional statements and foreach loops. At the very beginning, we set up a “key” value (which is the meta_value that’s placed in the database so we can find it and use the information later), and then we begin our arrays for the fields. The original tutorial only sets up arrays for the name, title, description and other assorted stuff. What we are going to do is also set up the type of field we want for each item, and a couple of “aesthetic” array values so it doesn’t look weird.


$key = "key";
$meta_boxes = array(
"input" => array(
"name" => "input",
"title" => "Input Field",
"description" => "This is an example for a regular input field.",
"type" => "text",
"rows" => "",
"width" => "100%",
"options" => ""
),
"textarea" => array(
"name" => "textarea",
"title" => "Textarea Field",
"description" => "This is an example for a textarea field.",
"type" => "textarea",
"rows" => "6",
"width" => "100%",
"options" => ""
),
"checkbox" => array(
"name" => "checkbox",
"title" => "Checkbox Field",
"description" => "This is an example of a checkbox field.",
"type" => "checkbox",
"rows" => "",
"width" => "",
"options" => array("1" => "checkbox 1",
"2" => "checkbox 2",
"3" => "checkbox 3",
"4" => "checkbox 4",
"5" => "checkbox 5",
"6" => "checkbox 6")
),
"radio" => array(
"name" => "radio",
"title" => "Radio Field",
"description" => "This is an example of a radio field.",
"type" => "radio",
"rows" => "",
"width" => "",
"options" => array("1" => "radio 1",
"2" => "radio 2",
"3" => "radio 3",
"4" => "radio 4")
),
"dropdown" => array(
"name" => "dropdown",
"title" => "Dropdown Selection",
"description" => "This is an example of a dropdown field.",
"type" => "dropdown",
"rows" => "",
"width" => "",
"options" => array("1" => "option 1",
"2" => "option 2",
"3" => "option 3")
),
"checkbox2" => array(
"name" => "checkbox2",
"title" => "Checkbox Field",
"description" => "This is an example of a secondary checkbox field.",
"type" => "checkbox",
"rows" => "",
"width" => "",
"options" => array("1" => "yes")
)
);


You’ll notice I have two “checkbox” types here. That’s because I wanted to show you that you can re-use these arrays, and vary how they will be used. In the first one, we’ve got a bunch of checkboxes – but the last one would be more of a “yes/no” type deal. (Check for “yes”, unchecked for “no”.) but that one’s just used as an example – any of these fields can be reused.

Now, the only other area we need to change is in the display_meta_box() function. Namely in the “foreach” loop contained within. We’re changing Liam’s basic function from this:


<?php
function display_meta_box() {
global $post, $meta_boxes, $key;
?>

<div class="form-wrap">

<?php
wp_nonce_field( plugin_basename( __FILE__ ), $key . '_wpnonce', false, true );

foreach($meta_boxes as $meta_box) {
$data = get_post_meta($post->ID, $key, true);
?>
<div class="form-field form-required">
<label for="<?php echo $meta_box[ 'name' ]; ?>"><?php echo $meta_box[ 'title' ]; ?></label>
<input type="text" name="<?php echo $meta_box[ 'name' ]; ?>" value="<?php echo htmlspecialchars( $data[ $meta_box[ 'name' ] ] ); ?>" />
<p><?php echo $meta_box[ 'description' ]; ?></p>
</div>

<?php } ?>

</div>
<?php
}
?>


To an extremely huge and expanded form that makes me wish I’d get to it and install some sort of code-formatting plugin. In all honesty, the beginning of the code above stays the same – you only need to change right around the foreach loop – just after the wp_nonce_field call:


<?php
function display_meta_box() {
global $post, $meta_boxes, $key;
?>

<div class="form-wrap">

<?php
wp_nonce_field( plugin_basename( __FILE__ ), $key . '_wpnonce', false, true );

$output = '';
foreach($meta_boxes as $meta_box) {
$data = get_post_meta($post->ID, $key, true);

$output .= '<p style="font-size:1.1em; font-style:normal;">' . $meta_box['title'] . '<br />' . "\n";
$output .= $meta_box['description'] . '<br />' . "\n";

if($meta_box['type'] == 'text') { // plain text input
$output .= '<input type="text" name="' . $meta_box['name'] . '" value="' . $data[$meta_box['name']] . '" style="width:' . $meta_box['width'] . ';" />';
}

else if($meta_box['type'] == 'textarea') { // textarea box
$output .= '<textarea name="' . $meta_box['name'] . '" style="width:' . $meta_box['width'] . '; height:100px;">' . $data[$meta_box['name']] . '</textarea>';
}

else if(($meta_box['type'] == 'checkbox') && (!empty($meta_box['options']))) { // checkboxes
foreach($meta_box['options'] as $checkbox_value) {
if($data[$meta_box['name']] != "") { // if array is empty, warnings will be issued, this circumvents it
$output .= '<input type="checkbox" name="' . $meta_box['name'] . '[]" value="' . $checkbox_value . '" ' . (isset($data[$meta_box['name']]) && (in_array($checkbox_value, $data[$meta_box['name']])) ? ' checked="checked"' : '') . '/> ' . $checkbox_value . '   ' . "\n";
} else {
$output .= '<input type="checkbox" name="' . $meta_box['name'] . '[]" value="' . $checkbox_value . '"/> ' . $checkbox_value . '   ' . "\n";
}
}
}

else if(($meta_box['type'] == 'radio') && (!empty($meta_box['options']))) { // radio buttons

foreach($meta_box['options'] as $radio_value) {
$output .= '<input type="radio" name="' . $meta_box['name'] . '" value="' . $radio_value . '" ' . (isset($data[$meta_box['name']]) && ($data[$meta_box['name']] == $radio_value) ? ' checked="checked"' : '') . '/> ' . $radio_value . '   ' . "\n";
}
}

else if(($meta_box['type'] == 'dropdown') && (!empty($meta_box['options']))) { // dropdown lists

$output .= '<select name="' . $meta_box['name'] . '">' . "\n";
if (isset($data[$meta_box['name']])) {
$output .= '<option selected>'. $data[$meta_box['name']] .'</option>' . "\n";
}

$output .= '<option value="">----------------</option>' . "\n";
foreach($meta_box['options'] as $dropdown_key => $dropdown_value) {
$output .= '<option value="' . $dropdown_value . '">' . $dropdown_value . '</option>' . "\n";
}

$output .= '</select>' . "\n";
}

$output .= "</p>\n\n";
}

echo '<div>' . "\n" . $output . "\n" . '</div>' . "\n\n";

} ?>


That’s really pretty much all there is to it. I’ll explain the pertinent information in bits, just to break it down into a more palatable chunk of information (I know that looks like a lot up there!) We’ll start with the array information.

Setting up the arrays
Basically, this is the only section you’ll really need to edit. Since the “checkbox” field has the most information, I’ll use it as an example to explain what’s going on.

"checkbox" => array(
Obviously, this is the beginning. It’s basically just setting up your field with a name that will be associated with the values. Makes sense, right? The array is the stuff that makes up the field, so you can manipulate what’s going on.

"name" => "checkbox",
The “name” of the field within the array. It does *not* have to match the one above, but I find it helps. This one is required. Gotta have it!

"title" => "Checkbox Field",
Optional. This is the text that will appear in the custom panel, the label of the field.

"description" => "This is an example of a checkbox field.",
This is the optional description. If there’s some ‘splaining that needs to be done for this particular field, I’ll use the description for that purpose. You can leave it blank if you like.

"type" => "checkbox",
Required. Here’s where get into the meat of it. This field here tells the code what kind of input type you want. Standard names apply.

"rows" => "",
Optional. For use only when using the “textarea” type of input.

"width" => "",
Optional. This is if you so desire to apply a width value to the textarea and text input fields. I usually so desire, so it’s there.

"options" => array("1" => "checkbox 1",
"2" => "checkbox 2",
"3" => "checkbox 3",
"4" => "checkbox 4",
"5" => "checkbox 5",
"6" => "checkbox 6")
),
This is your secondary array for your options. This pupply is pretty useless for textareas and text fields, but for checkboxes, dropdowns and radio buttons,it’s really handy. You can change the numbers to more associative type stuff – that’s your preference. But the second part (“checkbox 1″, “checkbox 2″, etc) are what your values and text for the fields are (same text applies to both).

Really, that’s all you need to know. If you go messing with the other part, I won’t be held responsible. But you can if you really feel the need to – I won’t come banging on your door to arrest you if you do!

Just so you know, you can assign where you want this stuff to show up. As it stands, it’ll show up in the “Write Post” area – which (as explained in the original tutorial) – is set in the create_meta_box() function (which is under the above-described array) in this line:

add_meta_box( 'new-meta-boxes', ucfirst( $key ) . ' Custom Post Options', 'display_meta_box', 'post', 'normal', 'high' );

You can have it assigned to Pages by changing it to this:

add_meta_box( 'new-meta-boxes', ucfirst( $key ) . ' Custom Post Options', 'display_meta_box', 'page', 'normal', 'high' );

or even – with the lovely new 3.0 feature of custom post types, assign it only to your custom post type. (in this example, we’ll say your custom post type is called “pictures”):

add_meta_box( 'new-meta-boxes', ucfirst( $key ) . ' Custom Post Options', 'display_meta_box', 'pictures', 'normal', 'high' );

Hopefully that helps you in your next project!

How to pull out the information
Silly me! i went and published this without telling you how to actually pull out this information and use it! That’s not very handy.

Unfortunately, I have to quickly make dinner (the kidlets are starving, apparently) so I will return shortly to tell you exactly how to do that.

Okay, so getting the info out and using it elsewhere is actually pretty simple. In the old version, you had to call every single item (because it wasn’t placed in a nice, neat array like it is now) via get_post_meta. If you had a lot of meat_key/meta_value pairs, that made for a lot of calls. But now, it’s one call (per key, as set in the top of the array), and you just pull them out with brackets.

So, within the Loop, you just need the single call:

<?php $fields = get_post_meta($post->ID, 'key', true); ?> (not “key” is hte same name set in the $key value at the very top of the array in the plugin/function). Now it’s a matter of simple calls to get the rest. Just want to grab what’s in the input and textarea fields?

Input field: <?php echo $fields['input']; ?>
Textarea field: <?php echo $fields['textarea']; ?>
note “input” and “textarea” within the brackets are the initial array names.

Works the same with the “Radio” field. Since radio buttons are a one-shot deal (you can choose one item only), it works in the same manner:

Radio field: <?php echo $fields['radio']; ?>

Dropdown is the same way as well – as long as only one option is chosen. If you allow multiple options to be selected, then you’ll want to deal with it the same way as you will your checkbox values. So, checkbox1 is a choice of 6 options. To obtain the checked values, we do a simple bit of code (using extra brackets, because it’s an array within an array) to do a foreach loop and yank out every single one of them:

Checkbox field: <?php if($fields['checkbox'] != '') {
foreach ($fields['checkbox'] as $value) echo $value . ' ';
} ?>

Checkbox 2 is a “yes/no” type option – so we can do a quick little test for that as well:

Checkbox 2 field: <?php if($fields['checkbox2'] != '')
echo 'yes'; // if the box is checked
else
echo 'no'; // if it's left unchecked
?>

And that’s all she wrote!

WordPress 3.0 “Thelonious” was officially released yesterday. Now, I posted before about the cool new features of WP 3.0. I’ve been using it since the Alpha, and I’ve been very impressed.

I’ve been getting a ot of questions in my inbox, as well as on Twitter, about how it’s going. A lot of people out there are pretty wary of immediately upgrading to a new version of WordPress, and typically wait until at least the first “patch” release before they’ll implement it.

Believe, me, as a user of WordPress since version 1.5, that’s my typical stance. I’ll wait until the first or second “security release” comes out before I dive into a new version. It’s actually a very smart move, and I don’t fault anyone for taking that safe stance – especially with clients.

However, this particular release was too mouthwatering for me to wait on. I have a pro-bono client that I’ve maintained for about three years now. It’s an extensive local nonprofit club in my area, that wants to “get into the new age” and go digital. In September, they will be beginning their new year, and they want to be completely paperless. They’ve had me code and test and manage their site during all of this time, and I’ve been constantly working on the site – as I learn new things that would streamline their site and it’s effectiveness, I apply it. However, there’s always been this one sticking point with me: their newsletter. Apparently, their newsletter isn’t a “normal” one, and I’ve had to hack and pray to get their newsletter to function the way it needs to. (Their list of requirements is seriously long, so I won’t go into it here.)

But then the clouds parted, and the angels wept when I saw WP 3.0 Alpha. Because of this particular client, I dove in. I NEEDED my sanity. I NEEDED this site to work as it should.

Granted, I’m not finished with it yet – when I say their list of requirements is long and convoluted, I mean it. THREE YEARS people. That’s how long I’ve been pulling at this thread, trying to get it to make sense and work right. And I have until the end of August to get it going good and proper. Because of this client, Iv’e actually gotten to dve in and get to know this new version, and I must say I adore it.

I’m positive there will be bugs and patches released – every WordPress version goes through this. But this time I actually got to participate in the process. I joined the WP Testers list and saw what these people do – and it’s amazing. There was one moment where I actually found a bug, and I briefly though about actually helping out and applying a patch for it – but I’m not secure enough in my skillz, so I didn’t. I reported, but I let someone else fix it – because I was sure that whatever fix I put in would break something else LOL but because I just sat back and listened to this list, I saw what was oging on, became familiar with things that really aren’t even in the Codex yet, and I got to toy with it like you wouldn’t believe. many of the plugins and functions I use work fine – but a few did not, and I had to fix them (I shall have to post what i did so others can benefit from this): two major ones (for me, anyway) were the Userextra/Usermeta plugins, and the function for Custom Write Panels, the tutorial as written by Liam McKay over at wefunction. LOVE Liam. He’s so smart – and very kind and helpful. But I feel all empowered and stuff because when I used his tutorial in 3.0, it broke – and I FIXED IT! (I also figured out how to add checkboxes, radio buttons, etc. for the fields too. There’s another post coming up I guess!)

Anyway, I just wanted to post about this because I know a lot of people out there are very wary. But I’m telling you, this one’s worth the risk. There’s so much goodness in this release that I just don’t know how you can wait. At the very least, you should download it and play on your own development server – it’s so worth it.

And yes, I know I haven’t upgraded this site yet. There’s a good reason for that – and it pretty much involves “new design so why bother?” LOL

Yes, I said it. And any of you who are WordPress fanatics probably already know about it. But I, being a lowly developer still on sabbatical, just heard about it this morning. I received an email from an old colleague of mine to inform me of this fun new release.

Rumor has it that WordPress 3.0 will be released on May 1, 2010 (just in time for my birthday!), and that it will include fun new features like combining WPMU with the regular WP installation (so you can have all the multi-blog fun of WPMU but using a regular single installation that’s not run by the MU – if that makes any sense!) We will also say bye-bye to Kubrick as the default theme, and hello to “Twenty Ten” to replace it.

As I said, these are rumors. But hearing just these juicy tidbits got me fairly excited. I haven’t really been this excited about WordPress in quite a while. I was so happy to hear this stuff this morning that I actually logged into the subversion access and downloaded the alpha, and installed it on my localhost – something I haven’t done in a very long time.

I’m going to tell you the cool stuff I’ve noticed right off the bat. Now keep in mind, this is just the alpha – which means the things I’m noticing could easily be changed. (This also makes me think that the May 1 release date is probably just for beta testing, because to actually have the release fully completed and issued as a release candidate by that date seems very ambitious to me.) But even so, just the installation process has such neat changes that I would be happy with just that! So do bearing mind that any of these things I’ve seen could be scratched at any point prior to beta testing for various reasons.

1. Better Installation Options
I can’t quite figure out the correct way to say this, so I went for the above line. it’s not that you have a crapton of new choices and options, but it seems to take security in mind. I’m not a “security guru” either, but I do know that when I install WordPress for anyone, I take certain steps to help aid in keeping it from being hacked. I do things like ensure the default “wp_” table prefix is changed in the wp-config.php file, and make sure I remove the default “admin” login and change it to something else.

3.0 takes care of at least part of this for you. Instead of assigning the default “admin” and random character password generated for you, you get to set it yourself during the installation process. As you can see (from the screenshot to the left) the regular same ol’ stuff is involved, but you can now create your own login name, and set your own password, without having to jump through the hoops of changing it after the installation process is complete.

I would also like to note that the old Authentication Keys (which you add to your wp-config.php file) have been expanded to include salts. Hackers will definitely have more work cut out for them if they want to break into your site. (Now, for each unique key, there’s a salt attached to it.) So I can definitely see how they are keeping security as a priority here.

2. Appearances
I can verify that the default theme (as mentioned above) is now “Twenty Ten“, but “Kubrick” and the old “Classic” are still standbys, and are still available to use.

But there is new awesomeness: the “Themes” section is now tabbed, so you can manage themes in one screen, and install new themes in another. Remember the old “themes.wordpress.org” site? Looks like we now have it in the back end of your WordPress area. You can browse through themes, select options for your search – very handy and totally cool. (it also appears you can do this with Plugins as well!) You can even upload your own custom theme work from the back end – no more need to FTP in and do your thing (just upload the .zip file and go!)

Total awesomeness – even though the “Widgets” area seems to be pretty much the same – you might notice a new option: menus. You can now create customized menus from the back end of your site – no more messing with tons of code to pull it off. Classes are even added to define your menu items (using “menu-item-Custom or “menu-item-page”, etc. and even further by assigning numerical items to each one for further CSS customization) to make it really easy to create a customized menu for yourself.

Even creating dropdowns is dead-easy – if you want a menu item to show up as the child of another one you’ve created, just drag-n-drop. Bam. it’s now a child, dropdown/flyout created.

Further coolness: you can create your own headers and upload your own backgrounds easily through the back end as well.

3. Exporting Content
Exporting now has new goodness: you can now define what you want to export. Before, all you had was an option to restrict your export to a particular author. Now you have the option to also restrict status, category, and what type of content (Pages? Posts? Or all?)

There’s still a lot of yummy stuff I haven’t completely trolled through yet – for instance I don’t see any indication that WPMU has been rolled into this as rumored. However, it does appear that you can download and install the BuddyPress plugin (which used to be solely for WPMU) and use it on single installations of WordPress. But this isn’t something that’s being saved for 3.0 – you can do it right now and use it with 2.9.x.

I stand freaking corrected! To enable “multiple blogs” on this, you just have to add the following line to your wp-config.php file:

define('WP_ENABLE_MULTISITE', true);

I’ll note here that – as with WPMU – it will not run on localhost properly just by using “http://localhost” or “http:/127.0.0.1″ – you have to have a virtual hosts setup. I have a tutorial on how to set up a local virtual host already, if you’re interested.Once you do that, and go under “Tools”, you will see a new menu item called “Network”. Hot damn, that’s cool. I picked up this tidbit on the wp-testers list, and from the discussion going on, this looks like a temporary thing. What I’m gathering is, at one time, there was just a button on the back end to enable this, but for some reason, it was removed in last night’s build, and this is the temporary solution while they continue testing.

All in all, this looks very promising to me. The new features that are put in here, I think, will not only aid the run-of-the-mill blogger to manage and control his own site, but I think that these initial things I see will also help developers who used to think that WordPress was too hard to code for become my competition

So, I currently (and temporarily) handle a website for a not-for-profit club in my area. I took over almost 2 years ago when I volunteered to help the current webmaster when she was out on a vacation. At that time, the site was pretty much done through this process:

• The person writing the article for the newsletter would submit a word document or HTML email to the newsletter editor, who would compile all of the information into one long Microsoft Word document.
• The Newsletter editor would then send that .doc file to the webmaster, who would pick through the entire newsletter to link things that needed to be linked, change copy (as needed) to fit the web and do other assorted things to the file to make it internet-ready.
• Such items would be to save all of the images in respective monthly folders
• The webmaster would also create the HTML file from within Word and upload everything to the server – resulting in seriously bloated code, as well as cross-browser inconsistencies.
• Doing all of this work also took a lot more time than was necessary, and archiving was completely manual.

So I decided to 1) give the site a new look, and 2) put it into WordPress so it was easy to manage everything. The new look wasn’t a problem…. but the newsletter was.

I’ve tried several “newsletter” plugins, some seemed promising, others were absolutely not – and none did exactly what I needed. So I began cobbling ideas and functions (and plugins) together to see if I could make something work. What I came up with worked rather well, but I’ve been using the system for almost 2 years now (and my term on the board as the newsletter editor is coming to an end – I have to hand this off to others who aren’t as “savvy” as I am) and in that time, I’ve seen the downside to what I’ve done, and how what was in my head doesn’t translate well to real life.

So now I need to revamp the back-end of this site to pull off my needs. There’s only a few places, really, that need redone – but they are biggies. I’m working to figure out the best way to do it. Here’s a few of the issues I have, and thoughts on how I can fix them. Keep in mind, these are thoughts only – not definites. I’m sort of thinking out loud here. In the end, I can see me writing some type of plugin, and it’s possible I would release it to the public, if it proves to be what others might be looking for.

The Current State of Things, from the Club Perspective
Basically, the club wanted a simple, informational site. Something that allowed people to easily get information on what the club is, how to join – that kind of thing. They also wanted some “fun stuff” – photos and events, news releases, etc – to be filler. But the meat of the site is a) getting people to join and b) the monthly newsletter.

They also have someone who handles the membership aspect of the club – she has an excel file that contains all the information for each member that she updates monthly. Club members get a “directory” once per year that lists everyone who belongs to it, and chairpeople use the list often to print out labels for mailings (like invitations to club events, etc.) However, using an excel file (especially when they like to export it as a Word document) makes it really hard to format this stuff, and too much time and effort, IMO, is put into something that could be made relatively simple.

What I have done
I converted the site to a CMS (WordPress) System. However, I began running into issues. The first one was the fact that the newsletter was due to be released on the 20th of the previous month. For example: the December newsletter would come out on November 20th. My only solution (thus far) as been to use the WordPress tagging system, and tag the articles by the month it was to be released, not the month it was published, so that the archives would correctly reflect the date of the article. The issue with this: the WordPress tagging system has no method of ordering by date – so right now the listing for the newsletters are in alphabetical order – not in order by month and year.

The tagging system also worked well, because there are several articles that chairpersons put out that are recurring – they say the same thing (or almost the same thing) every month – so really they are monthly reminders that a particular sub group or event is always out there., and if you’re interested in joining, it would tell you who to contact. So rather than having to repost the same information as a new post month after month, I can simply tag the article for the month and year of the newsletter it’s supposed to be in, saving me from having to rewrite it over and over again. The issue with this: is I have to manually tag each post over and over again. Some of the posts are getting REALLY long in the “tag” department. It would be so much nicer if there were some method to automate it. Like write a post once, and then schedule it to post on the 20th of every month, and then no one has to think about it again until the next year.

Another thing was the articles themselves. I have a rather convoluted system in place for setting who the authors are, and what order the articles display in. Now WordPress has a system in place so you can easily set another registered user as the author of a particular article. My original idea was that it would be supremely easy if I set all board members and activities chair members with their own login to the site, and they could write their own articles. That way, people had control of their content, all the editor had to do was go in and edit the articles and make sure the correct information was there, and publish everything. Life would be easier for everyone. Another plus was that if someone need to email the board, or their particular subgroup, all they had to do was login, check a box, write the email and send it. However, much to my chagrin, I’ve since discovered that no one is interested in this. (as a side note, it’s a little frustrating – since the point of doing all of this was to make their lives easier. They were all excited about this setup, but when I finally finished it and wanted to get a session together to show people how to do it – not a single person was interested.) They like the idea, but no one wanted to learn how to do it (even as simple as I made it) – I guess it falls under “old dog, new tricks” or something. So now I have a bunch of authors, but only one person actually doing anything – me.

The articles themselves have the same title every time. However, the interesting thing is, every 2 years, the board positions change. So I had to figure out a method to have the articles attributed to a position, not a particular person. I also needed the old information to stay the same – so if I updated a person’s position, the old articles (from when a different person held that position) would still have the correct info for that year. It also had to pull in the correct email address and phone number for that person.

The articles also had to appear in a certain order: the board positions in a particular order (that really couldn’t be set by a simple “ASC” or “ID” call), and then the sub-groups were listed in alphabetical order.

The issue with all of this: when I write a new post, I have to manually look up who currently holds the position, and their contact information, and add it every time.

If I could have a wishlist on how to fix the back end of this site, it would be as follows:

• Somehow make WordPress see the posts, and if it’s published between the 1st and 15th of the month, it archives it in the following month. (i.e. if an article is published November 13th, 2009, it would immediately date-base-archive itself into December 2009.) Then I would no longer have to tag everything every month, nor would I have to try to come up with some system to force the tags to display properly.
• Have some sort of system in place where the recurring articles would have a “default” post that shows every month, but for those rare occasions when they need to alter a word or two, they wouldn’t need to rewrite the entire thing for such a small change, and these recurring posts would re-publish themselves on the same day every month. Sort of like a simplified version of the “post revisions” you see in the back end. That would be cool.
• Somehow have the system look at the post title or category, and pull from another file or database entry as to who currently holds that position and their contact information and shove it into a custom field. That way, past entries have the correct information for them, while current has the correct info, and all you’d need to do is change the info in the “placeholder” file (or plugin).

Currently, I’ve also got the Tribulant.com’s Mailing List Manager plugin going. I really like it, but I would like it a lot better if I could streamline the management. Right now, I have to search for users when I need to do something – and it would be a lot “awesomer” if it behaved a little differently. There’s a lot to that, though, so it’s hard to describe what I mean.

I’d also like a nicer system for printing the newsletters. Right now, once everything is on the website, I have a print stylesheet set up to display everything properly to print (and mail out hard copies to members), but you have to know some CSS to make it lay out properly every month. An easier system would be terrific. Perhaps something as far as asking on individual posts what margin you’d like to set it at, and where the line breaks should be – that way messin’ with CSS wouldn’t be necessary.

And finally, I’d love it if the chairs and board members would be willing to learn to use the system so they can actually enjoy the benefits of what’s going on here. However, that’s not a coding issue – it’s a people one.

So that’s where I’m at with this. My term as “editor” ends in July 2009, and I have to hand the reins over to whoever gets the position after me. I also have to give the “webmaster” status back to the actual webmaster (who probably hates me now because she hasn’t done anything for almost 2 years – she probably thinks I stole it away from her!) I’d love to be able to hand it back over with everything in place, dead-simple and easy to use, and easy to maintain.

So please feel free to discuss – because I’d love some other great minds on this one! Obviously me banging my head isn’t coming up with a ton of terrific ideas all on it’s own! I’d love some input from others. Any ideas are welcome.