This tutorial is geared toward both the novice user installing sIFR for the first time and to those who have done it many times before. If this is your first time working with sIFR, you should know a few things before getting started:

• To work with sIFR and follow along here, you’ll need Adobe Flash.
• sIFR requires both JavaScript and Flash to work. In the absence of either, it will fall back to displaying regular text.
• Don’t try testing sIFR locally, or nothing will work. It needs to run on a server, either remotely or on a local XAMPP install.
• sIFR is not intended to replace large blocks of text. Try to use it sparingly, for headers and small snippets of copy only. Too much sIFR will bog down your site, increasing page load times.

1. Accommodate those without JavaScript

The very first thing you should do is to make sure your to-be-replaced text looks correct before using sIFR to replace it. If you don’t do this now, you’ll spend more time later switching between your sIFR text and your regular text (they end up using different stylesheets) to make sure they both look right. It’s better to take care of the non-JavaScript people first.

When you’ve gotten your text where you want it, move on to step #2.

2. Download the sIFR files

Download the latest version of sIFR and unzip it somewhere on your computer. For this tutorial, we’ll be working with sIFR release 436.

3. Open sifr.fla

When you unzip the sIFR archive, you’ll see four folders: css, demo, flash, and js. You can completely ignore the demo folder. Click into the flash folder and open sifr.fla.

4. Modify sifr.fla

Once you’ve opened sifr.fla, you should see something like this:

The white rectangle in the middle is called the stage or the canvas. Double click it and you’ll see this:

Double click the stage again to select the text inside. Delete everything, then type a single character (glpyh) of your choice for each font style you’d like. For instance, if you only need normal and bold styles, enter two glyphs: one for normal and one for bold. Make sure all of your glyphs are the same letter.

Of course, you’ll have to choose a font that supports all of the styles you need. In this tutorial, I’m using Arno Pro, which has bold, italic, and bold italic glyphs.

5. Choose your font

Select all of your glyphs, then look to the right of your screen for a dropdown menu like the one highlighted below:

All of your characters will now be the default “normal” style of the chosen font. If your font supports additional styles, the “Style” menu will be active. Highlight each individual glyph you want to change, then choose a different style from the dropdown. In the example below, I’m about to make the second glyph italic:

For fonts like Arno Pro, which have tons of glyph styles, you may be tempted to pick a “caption” or “extra wide” style. These will not work, since HTML only supports normal, bold, italic, and bold italic.

TIP: If you only need to display one style on your site, then you only need one glyph on your stage. I.e., if you only want to display bold, then type one glyph and bold it. You don’t need any more than that.

6. Add additional glyphs

If you anticipate using special characters (for example, Ñ, β, £, «, ™), you’ll need to embed them in your Flash movie. Right beneath the menus you just worked with is a “Character Embedding” button which, when clicked, pops up a window like this:

The basic glyph sets are already chosen for you, along with a list of extra characters. Choose the additional character sets you want (if any) or type special characters in the list, then click OK.

7. Publish your movie

When you’re happy with your font, go to File › Publish Settings. Untick the box near “HTML” since we won’t need to output any HTML files. Next, click the “Flash” tab near the top to adjust your settings.

The only setting you should change is JPEG quality. I always set it to 100, since there’s almost never a difference in file size between 80 and 100. This ensures your replaced text looks as good as possible. You can, of course, adjust this setting to try and reduce the size of your Flash movie.

Once this is set, click Publish.

8. Rename your movie

Go back to the folder that has your sIFR files and click into the “flash” folder. You should now see a sifr.swf file, which is the movie you just published.

It’s good practice to rename your movie after the font it contains, since it’s not uncommon to replace more than one font on a website. This naming convention will make it easy to know what’s what.

I renamed my movie arnopro.swf.

9. Open sifr-config.js and configure

Now it’s time for the hearty, meat-and-potatoes part of the tutorial. You’ve got your movie; you just need to tell your site where to find it and what to do with it.

Go to your sIFR folder, click into the “js” folder, and open sifr-config.js.

There are instructions in the file, but here are the basics:

• On line 15, change the variable name to match your font’s name and change the path to point to your swf file. For example:

// what you see when you open the file
var futura = { src: '/path/to/futura.swf' };

// an example of what you should change it to
var arnopro = { src: 'http://www.3roadsmedia.com/flashstuff/arnopro.swf' };

• Now is a good time to upload everything to a web server so you know the path to your movie. You won’t be able to test sIFR by just calling the movie from your hard drive.
• Do a find/replace to swap out all instances of futura with the name of your new font.
• Tell sIFR how to display your new font by adding CSS selectors and style rules (see the next step)

10. Tell sIFR how to display your new font

All of the styling for your Flash-based font is handled via sifr-config.js, starting on line 53.

A couple of pointers:

• Be sure the font name after sIFR.replace matches the name you specified in line 15
• The “selector:” tells sIFR which HTML element to target with the style rules. sIFR supports most HTML elements, but if you want to target things like :first-child, read this article on how to do it.
• You can target multiple selectors at a time by using a comma-separated list; e.g.:

selector: 'h1, h2 a, #footer h3',

• When using hex colors, always use the full six digits. Three-digit CSS shortcuts do not work here. For instance, use #003300, not #030.
• If you’re getting a funky colored box behind your replaced text, add this line to each of your selectors:

wmode: 'transparent'

• To style hyperlink hover behavior, do something like the following:

css: [
   '.sIFR-root { color: #000000; }',
   'a { color:#9f2321; text-decoration:none; }',
   'a:hover { color:#99e232; text-decoration:underline; }'
   ]

11. Include the sIFR files in your web page

For this tutorial, I’m assuming you already know how you want to style your font, so you can configure first and hook up second (sounds like I’m inviting some derisive snickering…).

sIFR requires 3 files to work: sifr.css, sifr.js, and sifr-config.js.

Add these files to the <head> section of your web pages by copying/pasting this:

<!-- sIFR files -->
<link rel="stylesheet" type="text/css" href="http://path/to/sifr.css" />
<script type="text/javascript" src="http://path/to/sifr.js"></script>
<script type="text/javascript" src="http://path/to/sifr-config.js"></script>

12. Upload everything and test

Upload everything to your web server and load your web page. If all went as planned, you should see your new font instead of that old, dreary thing you’re replacing:

If you don’t see your new font, go through this checklist:

• Double check the paths to all of your files.
• If your JS files are linked properly, make sure you entered the right path on line 15 of sifr-config.js.
• If that’s linked properly, try to load the Flash movie directly. If you don’t get anything, you may not have Flash installed or it may be turned off.
• Make sure JavaScript is enabled in your browser.

Once you’ve got your replaced font showing, tweak your CSS in sifr-config.js until things are exactly where you want them.

13. Tweak the CSS

The final step is to tweak your replaced text. You may notice it’s a bit off in some places, or that it wraps in the middle of a word. The solution is to edit sifr.css, which is located in the “css” folder of your sIFR download.

Once you’ve opened that file, scroll to the very bottom, where you’ll see this:

@media screen {
 /* Example:
 .sIFR-active h1 {
 font-family: Verdana;
 visibility: hidden;
 }
 */
}

This is where you make your edits (you can leave the rest of the file alone).

A common fix you may need to implement is preventing your replaced text from wrapping in the middle of a word. This is caused by the replaced text taking up less space than the sIFR text. The solution is to increase the font size, letter-spacing, or width of the replaced text. If you do this in your regular CSS file, you may find that your regular (non-sIFR) text is too large.

In this case, you’d create a new rule in your sifr.css file to make the font larger only for the replaced text; e.g.:

// regular CSS file
h1 { font-size:20px; }

// sifr.css
.sIFR-active h1 { font-size:28px; visibility:hidden; } 

Regardless of whether you edit sifr.css, you must include it in your <head> section.

Post script: frequently asked questions

You’ve got sIFR up and running, but something isn’t acting quite right? I’ve compiled this short list of questions that I’ve seen asked many times before:

How do I adjust line-height in sIFR?

Flash doesn’t understand the concept of line-height. Instead, it uses a custom property called leading. To adjust the line-height in sIFR, do this in your sifr-config file:

// leading must be a number (decimals allowed); no units needed
css: '.sIFR-root { color:#5a3b00; font-size:25px; leading: -3; }',

How do I style links in sIFR? My cursor doesn’t work.

A common problem with sIFR-replaced links is that your cursor doesn’t appear as the friendly hand pointer, but as a text selector. This is because you haven’t replaced the link, but the text inside the link. Read here for how to fix this.

That’s it!

If you have suggestions for improving this tutorial, or if you get stuck, feel free to leave a comment. You can also post a question at Stack Overflow where Mark Wubben (lead sIFR developer) is great at answering questions.

When viewing the latest post, next_post_link() displays nothing; when viewing the earliest post, previous_post_link() displays nothing. This can result in some less than friendly navigation.

In this post, I’ll show you how to use a built-in WordPress function and PHP conditionals to improve your WordPress page navigation.

The problem

Here is an example of next_post_link() and previous_post_link() at work on our blog’s old theme:

When viewing a post that is neither the newest nor the oldest, the post navigation links display as expected.

The trouble with these functions comes when you get to the first or last post. In the case of the first, you’ll have something like this:

When viewing the oldest post, the "previous post" link disappears, leaving an ugly hole.

And when viewing the last post, you’ll have something like this:

Similarly, when viewing the newest post, the "next post" link disappears.

To the rescue: get_adjacent_post

We’re going to use the obscure WordPress function get_adjacent_post() to check if… (shockingly) …there is an adjacent post. If there isn’t, we output whatever HTML markup we like to take the place of the gaping hole we’re trying to fill. If there is an adjacent post, we output it as normal.

The function retrieves a link to the adjacent post (either next or previous) and takes the following form…

get_adjacent_post([bool $in_same_cat, string $excluded_categories, bool $previous])

…and has these parameters:

• $in_same_cat : Whether the link should be in the same category
• $excluded_categories : A comma-separated list of excluded category IDs
• $previous : Whether to retrieve the previous post

The solution, with sample markup

The code block below contains the markup you should add to your single.php template file. Place it where you’d like your navigation to appear, then adjust the parameters and output to suit your needs.

<span id="prev">
   <?php previous_post_link('%link', '&laquo; Previous'); ?>
   <?php if(!get_adjacent_post(false, '', true)) { echo '<span>&laquo;Previous</span>'; } // if there are no older articles ?>
</span>
<span id="next">
   <?php next_post_link('%link', 'Next &raquo;'); ?>
   <?php if(!get_adjacent_post(false, '', false)) { echo '<span>Next &raquo;</span>'; } // if there are no newer articles ?>
</span>

I then added this line to my CSS file:

#prev span, #next span { color:#ccc; } /* lighter than the normal anchor text */

And here is the final result:

The final result, showing user-friendly language at both ends.

In the example above, I grayed out the inactive links. If you have more room, you might get creative by replacing the text with something like “Sorry, there aren’t any newer posts!”

Since then, I’ve found a much cooler and more practical way of editing content inline: by using a modal box. The result is the same: authorized users can update certain content blocks without control panel access and without any knowledge of HTML.

In fact, I think this method is far more robust, flexible, and user friendly than the AJAX one I shared with you a while back.

Let’s get started.

What is a modal box?

If you already know what a modal box is and why you would use it with ExpressionEngine, feel free to skip ahead to the implementation.

A modal box is a JavaScript driven dialogue box that “pops over” a page’s content. It is not a separate popup window, so it won’t be blocked by a user’s browser. Perhaps most importantly, a modal box requires the user to interact with it before the user can do anything else on the page.

A simple modal box

Why use a modal box for inline editing?

Usability. A modal box does not require the user to leave the current page, which means a user can interact with the dialogue (or series of dialogues) while still seeing the same page in the background.

For ExpressionEngine users in particular, not having to leave the page you want to edit is a big bonus, since finding a particular weblog entry in the control panel can be time consuming.

Can I see a demonstration?

Here is the end result of this tutorial. Feel free to make some changes – these are posting to an actual EE database so you can see how this method works.

You can also go to Wildbit’s Modal Box page and check out the demos.

Getting a modal box to work with ExpressionEngine

The goal for this tutorial is to implement a modal box that allows us to edit the content of an ExpressionEngine weblog entry inline; that is, without control panel access.

Step 1: Create a new weblog, custom fields, and template group

To be as comprehensive as possible, I’ll assume that you’re starting with a fresh EE install. If you already have weblogs set up, skip to the next step.

Create a new weblog (in a flash of brilliance, I named mine “ModalBox Test” and gave it a short name of modalbox_test).

Create a new custom field group (or use the default one). Make sure it has at least one text input field type and one textarea field type. I set the formatting for my fields to “none,” but you don’t have to.

Use the short names above if you plan to follow this tutorial to a T.

Assign your field group to your modalbox_test weblog.

Create a new template group. I called mine modalbox_test, the same as the weblog.

Step 2: Grab the ModalBox files

Visit Wildbit’s site and download the latest version of ModalBox (I’m using 1.6.0 for this tutorial).

Extract the zip file on your computer, then upload the modalbox1.6.0 folder to your web server. For this tutorial, I renamed my modalbox1.6.0 folder to modalbox and uploaded it to my system/scripts folder (this folder does not exist by default, so you will have to create it).

For the visually inclined.

The system folder is EE’s default system folder. You may have renamed it to something else.

Step 3: Link the ModalBox files to your template

I’ve prepared the following code block that you can use in your new template. If you’re using my custom field names from Step #1, you don’t need to change anything. Otherwise, be sure to replace my custom field names with your own.

Copy and paste the following code into your modalbox_test/index template (the calls to the ModalBox files are in red boldface):

<!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>Inline Editing with Modal Boxes</title>
    <link rel="stylesheet" type="text/css" href="{stylesheet=weblog/stylesheet}" />

    <!-- Modalbox files -->
    <script type="text/javascript" src="{scripts}/modalbox/lib/prototype.js"></script>
    <script type="text/javascript" src="{scripts}/modalbox/lib/scriptaculous.js?load=effects"></script>
    <script type="text/javascript" src="{scripts}/modalbox/modalbox.js"></script>
    <link rel="stylesheet" type="text/css" href="{scripts}/modalbox/modalbox.css" media="screen" />
    <!--// Modalbox files -->
</head>
<body>

<h1>An example of inline editing with ExpressionEngine and Modal Boxes</h1>

<ul>
    {exp:weblog:entries disable="categories|member_data|pagination|trackbacks" weblog="modalbox_test"}
        <li>
            <h2>{title}</h2>
            <p><strong>{modalbox_input}</strong></p>
            <p>{modalbox_textarea}</p>
        </li>
    {/exp:weblog:entries}
</ul>

</body>
</html>

Notice the {scripts} variable. That is a global variable I set up in EE that contains the path to my scripts folder (e.g., http://www.yoursite.com/system/scripts).

Step 4. Add an “Edit” link

Before you go any further, add some test entries, then preview your template to make sure everything is hooked up correctly.

Once that’s done, add the following line of code to your template. Place it where you’d like the “Edit” link to appear (I placed mine right below the <h2> tags in the sample code).

{if logged_in}<a onclick="Modalbox.show($('modalbox-content-{entry_id}'), {title: this.title, width: 800}); return false;" title="Edit this weblog entry" href="#">Edit</a>{/if}

This line of code tells the ModalBox script to load a DIV with an ID of modalbox-content-XX (where XX is the entry’s ID) into a ModalBox that is 800 pixels wide with a heading of “Edit weblog entry.”

Step 5. Create the DIV

In the previous step, we told ModalBox to find and display a DIV with a particular ID. This DIV will contain a SAEF (stand alone edit form), which allows us to easily and safely post our changes to the EE database.

Grab the SAEF code here and paste it wherever you like in your main template, so long as it is within the {exp:weblog:entries} tags.

The only thing you’ll need to change in the SAEF are the custom field ID numbers associated with each of your custom fields.

What?

When you created custom fields for your weblog, ExpressionEngine assigned each of them a unique ID number. We need to know what these numbers are in order to pull the correct information from the database.

To find these numbers, go to Admin › Weblog Administration › Custom Weblog Fields, then click “Add/Edit Custom Fields” next to the field group you created for this tutorial. Mouse over each of your custom fields and note the number that appears in the bottom left of your browser:

How to find a field ID for each of your custom fields

Here are my field IDs:

• modalbox_input: 73
• modalbox_textarea: 74

In your SAEF, find any references to these field IDs. They will look like field_id_XX, where XX is the field ID. For example, I would change my SAEF to look like this (my changes are in red):

<label for="amount">Modalbox Input</label>
<input type="text" name="field_id_73" id="amount" value="{modalbox_input}" />
<input type="hidden" name="field_ft_73" value="none" />

<label for="details">Modalbox Textarea</label>
<textarea name="field_id_74" id="details">{modalbox_textarea}</textarea>
<input type="hidden" name="field_ft_74" value="none" />

The field_ft_XX lines control the formatting for a particular field. You can leave them set to “none” to remove all HTML formatting.

Step 6. Test your ModalBox

Save and preview your template, then click an “Edit” link to call the ModalBox. If you’ve followed along closely, you’ll see a form populated with your weblog entry’s content.

The results of our hard work

Make some changes and click “Save” and you should be sent to the location specified in the “return” parameter of your SAEF. If this is the same page you just came from, you should see your changes.

Step 7. Add a success message

If you make a change and get dumped back on a page without any visual cues that something changed, you (or your client) may not have a clue what just happened.

That’s why I suggest adding a success message.

First, alter the return parameter in your SAEF to include the following:

return="modalbox_test/index/?updated=true"

You can set “updated” to be anything you like; it’s just a variable name.

Next, in the page you are returning to (modalbox_test/index), add the following lines of PHP:

<?php
    if(stristr($_SERVER['REQUEST_URI'], 'updated=true')) { $updated = 1; }

    if(isset($updated)) {
        echo "<div>Your weblog entry was successfully updated.</div>";
    }
?>

This snippet checks the URL for the segment we just added; if it finds it, then it displays a success message.

Step 8. Add a dropdown menu

In my last tutorial on inline editing, I didn’t touch the subject of dropdowns, since trying to get them to work with that script was impossible.

Luckily, we can use the SAEF with a bit of PHP to get what we need. Add the following where you’d like your dropdown to appear in the SAEF, being sure to replace the field IDs as needed:

<label for="dropdown">Dropdown List</label>
<select name="field_id_XX">
    {exp:query sql="SELECT field_list_items FROM exp_weblog_fields WHERE field_id = 'XX' "}
        <?php
            $items ="{field_list_items}";
            $items = explode("\n", $items);
            $howmany = count($items);
            $i = 0; do {
            $item_id = $items[$i];
        ?>
        <option value="<?=$item_id?>"><?=$item_id?></option>
        <?php
            $i++; } while ($i < $howmany);
        ?>
    {/exp:query}
</select>

This bit of code will loop through all of your manually entered dropdown items, then display them.

Step 9. Enjoy!

Feel free to share your own experiences, or to suggest ways to improve the code I’ve presented here. Have a question? Got stuck and need help? Let me know!

Postscript: Streamlining your implementation

I was fortunate enough to receive some feedback from Markus Stolpmann, a fellow EE user, on how to improve the modalbox implementation. The steps above are fine if you don’t mind including hidden divs in your code – but what if this isn’t your cup of tea?

It’s far easier to maintain your code if you include the SAEF in a separate template.

To begin, create a new template group (something like modalboxes works well). This new group will hold all of the content shown in your modal boxes. Our company intranet, for example, has templates like:

• modalboxes/add_prospect
• modalboxes/add_invoice
• modalboxes/edit_prospect
• modalboxes/edit_invoice

Each of these templates contains a SAEF with fields specific to the task (i.e., I won’t have an “invoice number” input box in my edit_prospect template). Here is an example of what my modalboxes/edit_prospect template looks like:

{exp:weblog:entry_form weblog="prospects" return="prospects/prospect_added"}
    <ul>
        <li>
            <label for="title">Prospect Name<em>*</em></label>
            <input type="text" name="title" id="title" value="{title}" maxlength="100" onkeyup="liveUrlTitle();" />
        </li>
        <li>
            <label for="email">Email</label>
            <input type="text" name="field_id_4" id="email" />
        </li>
        ...
        <li>
            <input type="submit" name="submit" value="Edit prospect" />&nbsp;or <a href="#" title="Close window" onclick="Modalbox.hide()">Cancel and close window</a>
            <input type="hidden" name="status" value="Prospect" />
            <input type="hidden" name="url_title" value="{url_title}" maxlength="75" />
            <input type="hidden" name="entry_date" value="<?php echo date("Y-m-d h:i"); ?>" />
            <input type="hidden" name="allow_comments" value="y" {allow_comments} />
        </li>
    </ul>
{/exp:weblog:entry_form}

Go ahead and remove the divs we created in step 5, transferring them to your new template group. Then find your “edit” link (step 4) and replace it with the following:

<a onclick="Modalbox.show('{path=modalboxes/edit_prospect}{entry_id}', {title: this.title, width: 800}); return false;" title="{title} &ndash; Edit details" href="#">

This line of code passes each weblog entry’s ID to the “modalboxes” template group, where it’s picked up automatically and used to populate your SAEF.

You can now enjoy modalboxes without cluttering your main templates with hidden divs. Enjoy!

In this post, I’ll show you how you can use AJAX to edit your ExpressionEngine content on the front end, without a page refresh, and with a simple click of the mouse.

NOTE: I recently wrote about an improved method for inline editing with EE using modal boxes. Read the tutorial here.

The Problem

Making changes to front end content can be time consuming and confusing. Even if your templates are set to display WordPress-style “edit” links next to each weblog entry, you have to use the control panel (CP) to make changes. Many end users don’t feel comfortable using the CP, and many times you just want to make a quick change without leaving the front end.

The good news is that with a bit of AJAX, we can bypass the CP altogether, greatly simplifying the editing process.

The Solution

I took my inspiration from an old post on inline editing at 24 ways. I’ve modified the code to work with ExpressionEngine, and will show you how you can get it to work with your own EE site.

Step 1: Create a new EE weblog and template

Create a new weblog and connect it to a custom field group with at least one textarea field (make sure the formatting is set to “none”). Enter a few sample entries, and then create a new template.

Enter the following HTML in your template, substituting your weblog name for ajax-test and your custom field name for {body}:

<!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>Edit-in-Place with Ajax</title>
    <link rel="stylesheet" type="text/css" href="{stylesheet=home/stylesheet}" />
</head>
<body>

<h1>Editing Inline with ExpressionEngine and AJAX</h1>

{if logged_in}
    {exp:weblog:entries disable="categories|member_data|pagination|trackbacks" weblog="ajax-test"}
        <h2>{title}</h2>
        <p>{body}</p>
    {/exp:weblog:entries}
{/if}

{if logged_out}<p>You must be logged in to view this page!</p>{/if}
</body>
</html>

I recommend previewing your template to ensure the entries are displaying properly.

Step 2: Grab the Prototype JavaScript library

The script we’ll be using requires Prototype. Get the latest version of Prototype here, upload it to your server, and add the following line to your template (inside the <head> tags):

<script src="http://path-to-your-scripts-folder/prototype.js" type="text/javascript"></script>

Step 3: Grab the Script

Here’s where all the magic happens. Grab the script here and save it as editinplace.js (don’t upload it just yet). Be sure to place a call to the script in your template by adding this line:

<script src="http://path-to-your-scripts-folder/editinplace.js" type="text/javascript"></script>

I recommend leaving the script open in another window while you follow along here.

Step 4: Get familiar with the script

Let’s take a closer look at editinplace.js. The first line ensures the script won’t run until the page is fully loaded. The init() function defines which element ID we want to be editable – in this case, editTitle.

The makeEditable() function does three things:

1. On mouseclick, call the edit() function, which hides the editable text and displays a textarea and two buttons (“Save” and “Cancel”)
2. On mouseover, add a CSS class to the editable area (this allows us to highlight it on hover)
3. On mouseout, remove the CSS class from the editable area

Notice that the showAsEditable() function is creating and removing a CSS class called editable. You can rename this to whatever you want, but be sure to add a declaration to your stylesheet.

The declaration I’m using on the demo page is:

.editable { background:#ffffd3; cursor:pointer; }

If a user clicks “Cancel,” the cleanUp() function is called; it clears the textarea and buttons and unhides the original text.

If a user clicks “Save,” the saveChanges() function is called; it posts the changes, displays a “Saving…” message, and returns the updated text.

Step 5: Grab the PHP

The script you just copied works in tandem with a small PHP script, which takes your changes and echoes them to the screen. Paste the script below into a new file:

<?php
    $id = $_POST['id'];
    $content = $_POST['content'];
    echo htmlspecialchars($content);
?>

Save this file as edit.php and upload it to your server. Update editinplace.js (line 53) to point to your PHP script, then upload this file too.

Step 6: Put the script to work

Now that we know what the scripts are doing, let’s put them to work. Editinplace.js is looking for an element with an ID of editTitle, but your template doesn’t currently have that. Let’s add it in.

Change the <h2> tag in your template to this:

<h2 id="editTitle">{title}</h2>

Save your template and preview it. Move your mouse over your first heading. Assuming you copied my CSS rules from above, you should see a highlighted box surround your heading, and your cursor should change to a pointer. Click the heading, edit the text, and click “Save” or “Cancel.”

If you try to edit your other headings, you’ll notice nothing’s happening.

Why is this? Remember that an ID is unique to a page, so if you have duplicate IDs, you’ll get strange results. In this case, only the first element of a given ID will be editable.

For most ExpressionEngine applications, you’ll be looping through a weblog several times, so this approach won’t work.

Step 7: Making multiple items on the same page editable

First, change the init() function in editinplace.js to this:

function init() {
    var max = 50;
    for (var i = 1; i <= max; i++) {
        makeEditable('editTitle_' + i);
    }
}

Then, in your template, modify your <h2> tag like so:

<h2 id="editTitle_{count}">{title}</h2>

Refresh your template and you should be able to make changes to all of your headings.

Step 8: Posting changes to your ExpressionEngine database

Up to this point, we’ve only been echoing changes back to the screen. Now it’s time to make those changes permanent by posting them to a database.

The bulk of the work will come in edit.php, though before we start making changes to that file, we need to add some things to editinplace.js.

Update your saveChanges() function to look like this (changes are in bold):

function saveChanges(obj) {
    var new_content = escape($F(obj.id+'_edit'));

    obj.preUpdate = obj.innerHTML
    obj.innerHTML = "Saving…";
    cleanUp(obj, true);

    var success = function(t){editComplete(t, obj);}
    var failure = function(t){editFailed(t, obj);}

    var url = 'http://path-to-your-scripts-folder/edit.php';
    var pars = 'id=' + obj.id + '&content=' + new_content + '&pre=' + obj.preUpdate;
    var myAjax = new Ajax.Request(url, {method:'post',
    postBody:pars, onSuccess:success, onFailure:failure});
}

If you copy and paste from above, don’t forget to update the path to your PHP file.

Next, update edit.php to look like this:

<?php
    $id = $_POST['id'];
    $content = $_POST['content'];
    $pre = $_POST['pre'];
    echo htmlspecialchars($content);

    require_once("path-to-your/include.inc.php");

    $sql = mysql_query("UPDATE exp_weblog_titles SET title = '$content' WHERE title = '$pre'");

    if(!$sql) {
        echo "<p class='error'>Unable to update the title!</p>";
    }
?>

You’ll need to create an include file that contains the connection information for your database (grab a sample include file here).

Update the path to your include file, enter your database connection information, save all three files, upload them, and refresh your rendered template. Make some changes to the titles. Refresh the page again, and your changes should remain.

Congratulations – you’ve just made a direct change to your EE database with AJAX!

Going a step further – editing more than just titles

You probably noticed in the demo that the excerpt for each post was also editable. Here’s how you do it:

Step 9: Create another editable element

First, you’ll need to tell the script that you want to make another set of IDs editable. Modify the init() function in editinplace.js to look like this:

function init() {
    var max = 50;
    for (var i = 1; i <= max; i++) {
        makeEditable('editTitle_' + i);
        makeEditable('editBody_' + i);
    }
}

Next, modify your template by adding the new ID:

<p id="editBody_{count}">{body}</p>

Finally, to post any changes to your paragraphs to the database, you’ll need to modify edit.php:

<?php
    $id = $_POST['id'];
    $content = $_POST['content'];
    $pre = $_POST['pre'];
    echo htmlspecialchars($content);

    require_once("path-to-your/include.inc.php");

    if(stristr($id, 'Title') == true) {
        $sql = mysql_query("UPDATE exp_weblog_titles SET title = '$content' WHERE title = '$pre'");
    } elseif(stristr($id, 'Body') == true) {
        $sql = mysql_query("UPDATE exp_weblog_data SET field_id_65 = '$content' WHERE field_id_65 = '$pre'");
    }
?>

Since the PHP script is handling requests for both editTitle and editBody, we need to use the stristr() function to determine which ID is being passed in.

Be sure that the field ID matches your custom field! In the example above, it is 65, but yours is likely different.

You can find your field ID by going into the CP, clicking “Admin,” selecting “Custom Weblog Fields,” and hovering your mouse over the field name on the left. The field ID will appear at the very end of the URL string at the bottom left of your browser.

Step 10: Provide a textarea for paragraphs and a text input for titles

You probably don’t want to be editing large hunks of text in a tiny input box. To get a textarea to show up when you click on a paragraph (while keeping a text input for your titles), modify the edit() function in editinplace.js:

function edit(obj) {
    Element.hide(obj);

    if(obj.id.search(/Title/) != -1) {
        // show an input box if we're editing a header
        var textbox ='<div class="edit-input" id="' + obj.id + '_editor"><input name="' + obj.id + '" type="text" id="' + obj.id + '_edit" value="' + obj.innerHTML + '" />';
    } else {
        // else show a textarea
        var textbox ='<div class="edit-area" id="' + obj.id + '_editor"><textarea name="' + obj.id + '" id="' + obj.id + '_edit">' + obj.innerHTML + '"</textarea>';
    }

    var button = '<input type="button" value="SAVE" id="' + obj.id + '_save"/> OR <input type="button" value="CANCEL" id="' + obj.id + '_cancel"/></div>';

    new Insertion.After(obj, textbox+button);

    Event.observe(obj.id+'_save', 'click', function(){saveChanges(obj)}, false);
    Event.observe(obj.id+'_cancel', 'click', function(){cleanUp(obj)}, false);
}

Step 11: Limiting edits to certain member groups

Before you decide to go crazy with inline editing, remember that, without the proper checks, anyone who visits your site can make changes to your content.

For starters, you should wrap your editable areas in a {if logged_in} conditional. Once that’s done, you should also consider only allowing certain member groups to edit content inline. Here’s a quick fix:

<h2{if member_group == 1} id="editTitle_{count}"{/if}>{title}</h2>

These conditionals allow you to specify who can edit which areas. You could, for example, allow members to edit your body text, but only allow admins to edit your titles.

Limitations

While working through this script, I came up against a few roadblocks:

• When making more than one element (e.g., headers and paragraphs) editable, you must have an equal number of each. In other words, if there are 3 headers on the page that you want to edit, you can’t have more than 3 paragraph blocks that are editable. Paragraphs beyond the 3rd won’t be clickable.
• You have to pre-define a max number of editable fields (in my example, this is 50).
• Inline editing doesn’t work well with headings that are also anchors

Conclusion

This is my first attempt at getting inline editing to work with ExpressionEngine. I don’t profess to be a code guru, so it is my hope that a little bit of discussion can help improve the code here and make life easier for developers and end users everywhere.

I welcome your feedback, frustrations, and success stories. Good luck!

Having worked with it for some time now, I’ve had a chance to work with a number of great extensions, which I’d like to share with you here. To fill out my list, I went through dozens of extensions I had not used, testing and then hand-picking my favorites.

Here they are, in no particular order:

1. Edit Tab AJAX (download)

Edit Tab AJAX takes advantage of the jQuery for the Control Panel extension (bundled with the latest versions of EE).

You’ll notice it at work on the “Edit” screen. Out-of-the-box EE requires you to first select a search criteria from one of the dropdown menus and then click “Search.” With the Edit Tab extension enabled, all you have to do is select an option from the dropdown menu and the results are loaded below, without a page refresh.

Look ma, no refresh!

This might not seem like a big deal, but cutting out that extra page refresh on every search can save a bundle of time. The only downside: if you edit an entry, then click “back,” you’ll lose your initial search results.

2. Playa (download)

One glaring limitation of EE’s custom fields is that you’re limited to a “one-to-one” comparison when relating entries.

For example, let’s say you have a “Featured Products” weblog, and you’d like to associate multiple products with a single “Featured Products” entry. Natively, you can’t — you’d have to create three separate weblog entries.

Enter Playa. Playa allows for a “one-to-many” comparison, so you can associate as many items as you want with a single weblog entry.

Using Playa to associate a single weblog entry with several related entries

3. Redirect After Login (download)

This extension allows you to show or hide the default (read: ugly) login and logout screens, and to redirect your users to URLs of your choice after login and logout. This can come in very handy if you use EE to manage non-admin user accounts.

With this extension, you can easily redirect a user to his or her profile page after login.

The settings screen for the Redirect After Login extension

4. MD Character Count (download)

I came across this extension while looking for a way to show one of our clients how much space was left in a given field. This extension (one of my favorites) allows you to limit the number of characters in any of your custom fields (input or text area, of course). You can even control the message that appears below each field.

MD Character Count lets you specify different counts, count types, and messages for every custom field (text input or textarea) across all of your weblogs.

One nice feature is that you can specify a “hard” count (i.e., you absolutely can’t go over the specified number of characters) or a “soft” count (i.e., you can go over the specified limit, but you’ll get a visual cue that you’ve done so):

The character limit and characters remaining will appear below each field you specify

If you specify a"soft" count type, you'll get a visual cue when you go over the limit

The only downside is that this extension doesn’t work with WYSIWYG fields.

5. Gypsy (download)

Gypsy eliminates the need to create custom field groups, and instead allows you to assign custom fields directly to whichever weblogs you choose.

You can elect whether or not to make a custom field a "Gypsy" field

It’s incredibly useful for those times you need to reuse custom fields. If you have just one custom field that is different between two weblogs, regular EE requires you to create two field groups and duplicate most of the custom fields for the second group.

With Gypsy, you only need to worry about the fields, not the groups.

6. Live Look (download)

If you’ve ever wondered why EE includes a “Preview” feature, know that you were not alone. Live Look enables accurate, live previews of your weblog entries from within the control panel.

I once was blind...but now I see

This extension is particularly valuable for clients, who appreciate seeing what their entries will actually look like before they go live.

7. LG Data Matrix (download)

[[UPDATE 5 May 09: Brandon Kelly recently released an updated version of LG Data Matrix called FF Matrix. Unlike Data Matrix (which restricts you to certain field types), FF Matrix allows you to create custom field types. You can also easily convert your Data Matrix fields to FF Matrix fields.]]

This extension is a real life-saver, because it addresses a major shortcoming of EE: if you want to enter varying amounts of information for a custom field, you have to do one of two things:

1. Create more custom fields
2. Create a new weblog and set up a relationship

Let’s say you want to enter multiple tasks for a particular project. Normally, you’d set up a custom field named tasks and assign it to a weblog named projects. Then, you’d set the custom field to be a textarea, and enter all of your tasks in a big chunk.

But what if you want to associate more information with each task, like the date the task is due or to whom the task is assigned? If you’re like me, you hate “chunking” everything inside a textarea. It’s harder to format and rearrange data within a textarea, and it’s harder to read.

It would be nice if you could add and remove tasks without creating separate custom fields or an entirely separate “tasks” weblog.

That’s where LG Data Matrix comes in. With this extension, I can create a single “tasks” custom field, then create what are essentially sub-fields on the fly, as I need them.

This extension will change how you work with EE custom fields. Note the icons for adding, removing, and rearranging your sub-fields

8. Cloner (download)

Cloner is a neat extension that can come in handy if you ever need to duplicate an entry.

Cloner lets you specify a suffix to differentiate the cloned entry from the original

You can clone entries one-at-a-time from the "Edit" screen

9. File (download)

Anyone who has used EE knows that the built-in file upload functionality isn’t very user friendly. Mark Huot created File to make it easier to upload files using EE’s control panel.

File allows you to designate a custom field as a “File” type, which replaces the standard text input with a more user-friendly “Browse” button:

My custom field after selecting two images and clicking "Quick Save." I have enabled multiple uploads and thumbnails via Admin › Weblog Admin › File Upload Prefs

It would be nice if there were an upload button, since the extension requires you to quick save or submit before the files are uploaded. Otherwise, it’s stellar.

10. MD Add Sitename (download)

I wanted to include Masuga Design’s Live Search extension here, but couldn’t get the latest version to work with my install. The screenshots and description alone had me sold.

This little extension is nonetheless very useful, especially for those developers who work with more than one EE site at a time. Once enabled, you will see the name of your site in the top left. Manipulating the font face, size, weight, color, and padding is a snap. You can also customize the site name if you don’t like the default.

Once enabled, your site's name will appear in the top left

Granted, the site name will be included in the forthcoming EE 2.0 release, but for the time being this is a good addition to your extensions arsenal.

Are there other EE extensions that you know and love? Feel free to share!