Looking for something in particular?

• Home
• Blog
• About
• Gaming
• Plugins
• Free Stuff
• Wishlist
• Contact

Plugin: Sexy Comments v1.4 Released!

August 3, 2007 | 201 Comments

Introduction

This has been a long time coming and I am happy to announce the release of Sexy Comments v1.4! With this version comes a lot of changes...so be sure to read the installation section! Along with simple optimizations and general restructure, the following features are now available:

Feature List

• Ajax comment preview (new feature)
• Author post highlighting
• Avatars
  • Either display/hide avatars
  • Select your avatar service of choice (Gravatar and MyBlogLog options are available)
  • Specify maximum avatar dimension (Gravatar Only)
  • Customize default/trackback avatars
• Comment Reply-To (new feature)
• Comment Themes (new feature)
• CSS overriding
• "Number of Comments" message customization
• jQuery inclusion toggling

Installation & Upgrading

1. Download Sexy Comments v1.4 from the WordPress plugin directory
2. Unzip that little sucker
3. Place sexy-comments folder in your wp-content/plugins directory (it should look like this: wp-content/plugins/sexy-comments/
4. Log in to your WordPress plugin admin page and activate the plugin.
5. In the plugin admin page, click the SexyComments sub-menu.
6. Customize the settings until you have something that works for you.
7. Locate your theme's template file that displays comments (typically comments.php). Remove the comment output loop and replace with:
   PLAIN TEXT
   PHP:

   1. <?php sexycomments::show($comments); ?>

8. If you plan to use the Ajax features or the Reply-To features, you will need to do two things.
   1. Enable jQuery and jQuery Form Extension via the Plugin > SexyComments administration page.
   2. Locate the template file that contains the comment submission form (typically comments.php near the bottom) and replace that chunk of code with:
      PLAIN TEXT
      PHP:

      1. <?php sexycomments::form(); ?>

   NOTE: Be sure not to touch the section that generates the form for adding comments! This plugin does not re-create the comment creation form.

9. Lastly, consider disabling the plugin CSS and taking the example CSS provided and customize it to suit your theme's color scheme.
10. You should be all set, now! w00t w00t! Go make a MyBlogLog or Gravatar account if you don't already have one and upload an avatar. Gravatar tends to be pretty flakey so I'd suggest using MyBlogLog.

FAQs

• Q: What is this "comment loop" you speak of?

  A: Ah, yes. That thing. Well, its anatomy looks similar to this (there will be some variation from theme to theme):

  PLAIN TEXT
  PHP:

  1. <?php if ($comments) : ?>
  2.     <!-- some HTML is typically here -->
  3.  
  4.     <?php foreach ($comments as $comment) : ?>
  5.         <!-- the output HTML of each individual comment -->
  6.  
  7.     <?php endforeach; /* end for each comment */ ?>
  8.     <!--...more HTML -->
  9.  <?php else : // this is displayed if there are no comments so far ?>
  10.     <?php if ('open' == $post->comment_status) : ?>
  11.         <!-- typically a blank area or a place with a comment -->
  12.      <?php else : // comments are closed ?>
  13.         <!-- closed comments section -->
  14.     <?php endif; ?>
  15. <?php endif; ?>

• Q: Ok...so I just upgraded to a new version and there is nothing in the SexyComments admin page...WTF?

  A: Yeah. Sorry about that. In this version, the directory structure has changed drastically and Sexy Comments should no longer live in wp-content/plugins/sexycomments.php OR wp-content/plugins/sexycomments/sexycomments.php, but instead it should be in wp-content/plugins/sexy-comments/. Make sure that the plugin is in the correct location of your plugins directory.

• Q: What happened to sexycomments_print($comments)? I used to use that to get my comments to display...will it still work?

  A: Along with a directory structure overhaul, this version had a large code overhaul as well. The old function (sexycomments_print) is deprecated but will still work for the time being. I greatly urge you to move over to the new function call sexycomments::show($comments) as that is the new *impoved* function.

WordPress Plugin: Sexy Comments

April 5, 2007 | 76 Comments

Unhappy with my theme's comment display, I recently re-coded a sexier comment display as a plugin so others can sexify their comments as well.

Download the plugin.

Features

• Forum-thread-like comment layout: User information to the left, comment to the right.
• Author post highlighting
• Altered Trackback/Pingback Display Formating
• Avatars
  • Either display/hide avatars
  • Select your avatar service of choice (Gravatar is the only option until I find more avatar services)
  • Specify maximum avatar dimension
  • Customize default/trackback avatars
• "Number of Comments" Message Customization
• CSS Overriding

Installation

1. Download and unzip the sexycomments.zip
2. Place sexycomments folder in your wp-content/plugins directory
3. Log in to your WordPress admin panel and activate the plugin, then visit the SexyComments submenu of the plugins tab.
4. Customize the settings until you have something that works for you.
5. Locate the template file(s) in your theme that loops over and displays comments. Remove that comment output loop and replace with:
   PLAIN TEXT
   PHP:

   1. <?php sexycomments_print($comments); ?>

   NOTE: Be sure not to touch the section that generates the form for adding comments! This plugin does not re-create the comment creation form.

6. Lastly, consider disabling the plugin CSS and taking the example CSS provided and customize it to suit your theme's color scheme.
7. You should be all set, now! w00t w00t! Go make a Gravatar account if you don't already have one and upload an avatar.

Sweet Image Manipulation: OH NOES!

February 12, 2007 | 4 Comments

Thank you. That is all.

Remote JavaScripting Example - Part I

September 22, 2006 | 5 Comments

At Plymouth State we work in a multi-server environment and often wish to display dynamic content from one server in an Ajax-like fashion on another server's website. My co-worker, Zach Tirrell, and I have drummed up a solution that works to keep our layout and logic separate, while still serving our end users in a smooth, seamless, non-iFramed manner.

I'll walk through the creation of a simple search 'widget' that relies on dynamic data to populate a drop-down box.

The Tools

- PHP
- JavaScript
- XTemplate
- RemoteJSOutput: a simple script by Matthew Batchelder (me) and Zach Tirrell

Step 1: create your template

This widget is fairly simple and thus has a simple template. The template syntax is simply XTemplate syntax.

I'll name it widget.tpl and store it in a templates directory.

Step 2: simple template output

First we'll just spit out the template. Lets create a PHP file to do this. We'll call it widget.php

Check out your widget so far. Its plain. Lets change that.

Step 3: add dynamic content

We want the drop down list to hold BorkWeb articles. We'll add that in now.

Note: this is where you would normally pull from a database, an RSS feed, or some other source. For simplicty, we'll be using a simple PHP array. Whoop-de-doo. Here it is:

Check out your widget now. It has been populated with some data! w00t! Now to make it work, we return to our beloved widget.tpl template file.

Step 4: make the template work

We're going to add in some javascript. Lets make the dropdown list redirect the user to the selected article when the drop-down box changes.

I'm going to add this on our select box:

The template should now look like this:

Step 5: prepare script for remoting

Now that our lovely widget is functioning, lets prepare it for inclusion in other locations. This is simple using RemoteJSOutput (a simple script written by Zach Tirrell and myself).

We'll include that PHP class and use it as follows:

Now check out your widget. Ugly, huh? Well, don't worry, thats the way its supposed to look for now.

Step 6: place your widget somewhere

Now that we have that beautiful chunk of code in operation, place it on a webpage somewhere.

Put this:

on any page you wish to test your widget!

Optional Step 7: create a wrapper

If, like me, you aren't a fan of including RemoteJSOutput.class.php all over hell's half acre, you can create a wrapper. This not only allows you to minimize the code you have to repeatedly place everywhere, but it also keeps your widget.php script functional on its own!

Here's an example wrapper I'll call get_script.php which will display wrapper_widget.php (step 3's PHP file, renamed):

So rather than using the script tag that Step 6 suggests, we'd use:

Conclusion

This method is simplistic and is simply touching on the topic of widgetization. I will be following up with dynamic user interactions in Part II, and finally discuss an open-standard widget library with xml definitions. Stay tuned :)

Download

Oh, and here's the code used in this tutorial all zipped up.

Finally. A Cool Looking Human Clone.

May 16, 2006 | 6 Comments

After the success of cloning Dolly The Sheep, I am pleased to announce that scientists have finally perfected the Human clone. Check out the perfection as my clones check my tomato-mushroom-and-basil quiche, fetch me a cup of water, put bread in the breadbox, and place utensils in the dishwasher...all while I snapped their photo. All I can say is that my wife is one happy woman. Here are my clones:

Writing Your Server-Side Ajax Handler

March 22, 2006 | 19 Comments

In my recent post on 'Ajax; Templating; and the Separation of Layout and Logic,' I refer to an Ajax Handler that sits server side to handle Ajax calls. Some elaboration is in order.

As I have stated in the past, I'm a huge fan of Prototype AND I choose PHP as my language of choice...so my examples will be using both, but the idea is portable.

Set up your Functions

Before you create a handler, you need a set of functions that the handler can reference. Here's an example:

Now that we have the functions all set, we'll set up a handler that receives Ajax calls and calls the appropriate functions.

The Eval Method - A Dynamic Handler

This method is one that I toyed around with for a while and I'll admit that its pretty simple and clean but there are some drawbacks. We're going to make a few assumptions: All requests will be GET (this is to keep things simple for this example) and we will keep the complexity of .htaccess sweetness out of these examples and assume that each call will be passing a function variable that specifies the function we are calling. I'll get to those in a second...but first I'll show you the handler code in this Eval Method:

The Variable Variable Method - A Dynamic Handler

This method (compliments of PHPDeveloper) is simpler than the Eval Method and just as dynamic.

The Switch Method - A Basic Handler

This method handles each call individually. The reason for using switch rather than if-elses is simply because your application will most likely possess a large number of Ajax-ified functions and those if-elses would be ghastly to read and decrease performance...the Switch statement is much cleaner.

Make a Choice

Which are you going to use? While the Eval and Variable Variable Methods contain very small amounts of code in the handlers, the logic has simply been shifted to the functions themselves. Increased Ajax-geared logic within the functions themselves reduces portability. However, in the Switch Method, logic is organized in a fairly easy to follow manner while making use of very generic functions that can be used in multiple fashions. Obviously, the Switch Method is my preferred choice :)

In Closing

Handler scripts make the Ajax magic happen and the separation of handler logic from your application logic is just as important for robust development and debugging as the need for separation of layout and logic. Play around with the above methods and see which works for you. If you have a method all your own, I'd be interested to hear it!

Ajax; Templating; and the Separation of Layout and Logic

March 10, 2006 | 141 Comments

The Background

I have often mentioned my process of expanding my proficiency of Ajax. Through my journey I have made a number of wrong turns and hit my share of stumbling blocks. All of that has been a learning experience and I'm learning still. I began fiddling with XMLHttpRequest as many do - blissfully ignorant of the many frameworks that exist to make Ajax super easy. My code was bloated with some neat...'features' (pronounced: bugs).

Then I discovered the Simple Ajax Toolkit (SAJAX), which was simpler than doing raw XMLHttpRequest but really not all that simple. My latest step into the world of Ajax, and the toolkit that holds my love (currently) is Prototype...and I like my Prototype served with a side of Script.aculo.us. *drool* UPDATE: I now use jQuery for all my Ajax and DOM manipulation goodness.

While Ajax is the cause for the article, the heavy focus is on templating. For the past few years I have been using XTemplate as my templating library (I'm a PHP buff) and have been happily separating my logic from my layout...unitl I ran smack dab into the power of Javascript. My PHP still kept its separation from HTML as is the purpose of XTemplate, but it was my HTML that became littered with little nuggets of Javascript all over the place. No matter the method to my Ajax madness, this was my problem.

What Exactly Is Templating And Why Do It?

Templating is definately not new and its use has been debated back and forth for quite some time. But like I stated above, the goal of templating is to keep logic separate from layout which is a good thing for a couple of reasons:

1. Less clutter. Face it, HTML and whatever server-side scripting language you choose to use are two different beasts. Mixing them together is visually unappealing making code hard to read...and hard to read code is hard to debug.
2. Coders can develop code. Designers can develop layout. With templating, you are able to achieve this separation and avoid the need for a developer to butcher a designer's layout to make it function with an application. Each can design/code on their own then combine their efforts with ease.
3. With separation such as this, applications are more easily skinned and/or receptive to complete UI overhauls.
4. Did I mention less clutter?

Let me give you an example of what I mean with a simple Goodbye Cruel World application:

Here's the PHP script: goodbye.php

Here's the Template: goodbye.tpl

Here's the output:

Goodbye Cruel World! Bork, bork, bork!

Obviously that is an extremely simplistic example. With XTemplates I can get pretty complex and include files, loop over and parse out some complex block structures, assign arrays into template variables, etc. If you want to see a more complex example of a template, check it out here.

Templating Seems Sexy, How Does It Work In An Ajax-ified Environment?

I thought you'd never ask. For this, I have created a diagram to detail how I combine Ajax, PHP, and Templating all in one.

It all works like this:

1. A User makes a request to view a page
2. The server-side script calls a series of application functions that generate blocks of templates
   1. Each section that can be updated/rendered by Ajax calls are separated into their own templates, which enables them to be called on initial page load and separate Ajax-triggered calls from the client.
3. The complete template blocks are sent to the user as a rendered page.
4. As the user interacts with the interface, two specific things can occur:
   1. An Ajax.Updater (see Script.aculo.us) is triggered, which makes an Ajax callout. The callout is sent to the Ajax Handler (which is a PHP script) which handles the call and invokes the appropriate application functions. Those functions initialize template blocks and output HTML. The HTML output by the server is received by the client and inserted into the User Interface.
   2. An