I don’t really want to check my email. Four weeks have passed and the idea of processing my messages feels really foreign.

It feels strange loading up Gmail without doing a specific search to find a particular message.

I just checked and it’s actually been 5 weeks since I last saw the inside of my inbox. Oops.

I suppose I should check my messages today or soon 6 weeks will have passed without email (is that such a bad thing?).

Let’s do this.

Post Workout

I just finished processing nearly 400 messages and I’m exhausted. I didn’t like it at all.

Checking my email didn’t feel smooth or easy. Instead, it felt like something very unnatural.

Perhaps 4 weeks is too long to let email go unchecked, or perhaps 4 weeks is just long enough to stop caring about email. I’m all for that.

I can just barely hear a little voice in my ear telling me that I shouldn’t be giving email the time of day even if just once a month. It’s saying that I should let the email pile up and do whatever it wants to my inbox as long as I don’t have to touch it ever again. I can just cherry pick the messages I want from now on.

Sounds good to me.

At the same time, a more reasonable, even-tempered, and organized voice is screaming, pleading, and waving its hands frantically in the air to stop me from even entertaining such a notion.

“Once you go down that road,” it says, “you can never come back.”

You decide you want to get your inbox in order one day down the road? You’ll be in for a world of pain trying to clear the weeds and make the inbox fit for use once again.

“Far better to go back to processing messages every 3 weeks, ” the voice quite reasonably assures me. After all, that yielded the fastest message processing time in months, and it was easy.

If it’s easy, it’s not hard right?

Okay, tiny reasonable voice, you win. I’ll go back to checking my messages once every 3 weeks…for now.

But I still like that dropping-email-forever idea, so you’ll have to be very convincing in 3 weeks.

Today’s Stats

• Checked email: 1 time
• Time: 14:59:23
• Total messages: 379
  • Inbox: 61
  • Bulk: 65
  • Important: 0
  • Action: 53
  • To Read: 53
• Management: 36
  • Incorrect Smart Label: 0
  • Unsubscribe: 33
  • Update filtering: 2
  • Spam: 1
• Time per Message
  • Inbox: 06:42 (9.1 messages/minute)
  • Bulk: 07:08 (9.1 messages/minute)
  • Management (filters, etc.): 11:15 (3.2 messages/minute)
  • Total: 25:05
  • Average: 15.1 messages/minute

The post 30 Days of Email Domination: Workout appeared first on Archetyped.

Direct to your dashboard

This release marks the first time SLB 2.0 will be accessible directly via WordPress’ admin dashboard. SLB is used on a huge variety of WordPress websites so this will open up testing to many more users. It may also expose some issues with various setups and configurations, which is exactly what we need right now before the final version is released.

While quite stable for the hundreds of brave testers that have been enjoying beta versions of SLB 2.0 for several months via GitHub, installing release candidates is not for the faint of heart. As with any prerelease version of any software, it is highly recommended that you test SLB 2.0 Release Candidate 2 on a staging server prior to updating your production site. As an added precaution, SLB even provides a beta notice on the plugin listings page so that no user is caught unaware.

Simple Lightbox Beta Notice

Optimizations

As previously mentioned, this release was completely focused on optimizations.

JavaScript loaded in footer

SLB’s JavaScript code that controls the lightbox functionality is now loaded in the document’s footer instead of the header. This will help pages to load faster.

Props to SLB user scruffy1 for nudging me to move JavaScript loading to the footer. The truth is that I thought this was already implemented in a previous release, but it never made it in. Now it is, and it is good.

A More Flexible Viewport

SLB 2.0RC1 unlocked the viewport so that, in addition to being fully responsive in mobile browsers, users can still pinch and zoom in on the lightbox if they want to get a closer look. RC2 adds even greater flexibility by supporting non-conflicting settings that a responsive theme may be implementing. The result is increased compatibility with your responsive WordPress theme and an all-around smoother lightbox experience.

Ready for Translations

Now that SLB’s UI is locked down for v2.0, the time was right to generate a new POT file for localizing SLB. If you would like to provide a translation, simply fork SLB on GitHub and submit a pull request with your translation file.

Check out WordPress’ official documentation to learn more about WordPress internationalization.

2.0 Final: Coming Soon

It’s totally cool if you’re not comfortable with installing a beta version or even a release candidate on your site. You’ll just have to hold off from experiencing SLB 2.0 goodness for just a little bit longer while our brave testers kick the tires on these release candidates.

If you are feeling brave though, install SLB 2.0RC, and send your feedback!

The post SLB 2.0: Release Candidate 2 appeared first on Archetyped.

Update: Simple Lightbox 2.0 Release Candidate 2 has been released!

Thanks to feedback from our brave testers, Simple Lightbox 2.0 is even closer to an official release with its latest update to Release Candidate status.

Release Candidate?

For the uninitiated, a release candidate is a version that is considered ready for official release. All features are finished and there are no known bugs. As there are many users who depend on Simple Lightbox to work without issues, release candidates are vitally important to make sure the kinks are worked out before releasing a new version to the masses.

That being said, this release candidate is the first version that may be made available to users via WordPress’ admin dashboard. This will open up testing to many more users and may expose some issues with various setups and configurations, but that’s exactly what we need at this point. My only hope is that users read and understand the beta notice before updating SLB on their site.

Simple Lightbox Beta Notice

Optimizations

First off, SLB 2.0RC1 includes some notable optimizations.

Component API file paths

File paths set when registering various components for SLB such as Template Tags, Content Handlers, and Themes now follow the convention set by WordPress’ own file loading functions like wp_enqueue_script().

When the component APIs were introduced in SLB 2.0 beta 7, file paths were expected to be relative to WordPress’ plugins directory. This effectively meant that only plugins could create component as files had exist in the plugins directory. To make things more flexible, file paths defined in all component APIs now require a full URI, just like WordPress’ built-in file loading functions (wp_register_script(), wp_enqueue_script(), wp_enqueue_style(), etc.).

Custom components can now be added by plugins and themes. No favoritism here.

Label text updated for internationalization

Providing SLB in each user’s native language is very important. To that end, I a (long) walk through SLB’s entire codebase to check for any text labels (e.g. UI text) that did not yet support internationalization. The next update will include a file for contributors to translate all of SLB’s text into any language (even Klingon, if that’s your thing).

Fixes

Of course, no update to SLB would be complete without the carcasses of squashed bugs left in it’s wake and 2.0RC1 delivers.

Unlocking the Viewport

In order to display properly on mobile devices, SLB modifies the browser’s viewport property while a lightbox is displayed. This allows the lightbox to fill these small screens, making it easier to view the lightbox’s content without distraction. However, prior to 2.0RC1, the viewport settings and associated CSS were a bit too aggressive, and while they properly filled the screen with content, they also restricted zooming in to get a closer look at the content in the lightbox.

The viewport settings and CSS have been updated in 2.0RC1 to be more flexible. Now, while the lightbox still fills the screen, users are able to zoom in on the content. SLB user zephyr88 was the first to report the issue, so this bug fix shall henceforth be referred to as Zooming Zephyr in honor of their contribution.

Group Navigation

How often do you do this: Open a group of images in SLB, navigate through a few photos, and close it. Then, open up a different group of images on the same page and navigate through those images.

It sounds complicated, but it’s really quite common. Strangely, SLB was having a bit of problem navigating through a 2nd group of images, but only if you had previously viewed another group of images first.

This issue took a bit of time to track down because it was affecting such low-level behavior (i.e. navigating between grouped images). In the end, the issue was caused by object references leaking into a JavaScript object’s prototype– yeah, that old one. Thankfully the fix was simple and SLB user larryjmoore caught the bug and reported it in time for this update. To commemorate his contribution, the fix to this group navigation bug is named Larry the Navigator.

Release Candidate 2?

Whether there will be additional release candidates after this one strongly depends on user feedback and bug reports. If you find a bug, please report it so that it can be attended to.

I’m very excited about SLB 2.0 and I want everyone to be able to use all the new features, so let’s squash some bugs and get this thing released!

The post SLB 2.0: Release Candidate 1 appeared first on Archetyped.

Processing 3 week’s worth of messages in 10 minutes or less seemed highly unlikely. I had 67% more messages to process this time than last time (2 week’s worth of messages) and I only just made it under 10 minutes (09:34) then.

Basically, I had no chance.

Inbox

Interestingly, though I was processing 3 week’s worth of messages, today’s message processing rate (MPR) in the inbox was pretty close to the inbox MPR when processing 1 or 2 week’s worth of messages. This may indicate that the same type of messages are in the inbox each time, with the rest of the messages being properly routed to the appropriate bucket by filters.

I’ll need to look into whether there are any additional types of messages I can automatically filter out of the inbox to improve the MPR without affecting my efficiency in other buckets.

Bulk

I am happy to see that the average amount of bulk messages appears to be decreasing each week. Today there were 49 bulk messages, which breaks down to about 16 bulk messages per week, which is an improvement over the previous average of 19.5 bulk messages per week.

Unfortunately, processing bulk messages took a bit longer this week with an MPR of 13.8/minute (compared to the previous MPR of 19.3/minute). There were more bulk messages that I actually wanted to read this week, so this likely contributed to a slower MPR.

Management

Management went pretty quickly, with the fastest MPR since late-January.

While I still wish there were a bulk unsubscribe feature, using the Message Sneak Peek Labs feature in Gmail makes it pretty painless to find the unsubscribe link in messages without having to open each message individually.

Message Sneak Peek in Gmail Labs

Now I just go down the list of messages I want to unsubscribe from, right-clicking each one to pop open a quick preview, and click on the unsubscribe link at the bottom of the message.

Thankfully, most email senders are pretty responsible about providing a quick and easy way to unsubscribe from mailing lists without having to jump through a bunch of hoops like logging in and updating preferences directly (though I did have to do that for a couple messages today).

For the stone-age senders that still require you to send them an email with “Remove” in the subject line, I just mark their messages as Spam and let Gmail handle it from there.

Close

In the end, I spent 11:49 processing messages today. Close, but not quite under 10 minutes. I’m not beating myself up too much though because it’s not that bad for 3 week’s worth of email. Better still, my average MPR shot up 36% over the average MPR from processing 2 week’s worth of email, which tells me I’m on the right track.

Plans

I could stick to checking email every 3 weeks to see if my results are consistent, but I think I’ll move on to checking email once every 4 weeks. 4 is a nice round number and I can see if message processing is further improved by adding an additional week’s worth of messages.

Today’s Stats

• Time: 09:57
• Total messages: 273
  • Inbox: 51
  • Bulk: 49
  • Important: 2
  • Action: 42
  • To Read: 54
• Management: 10
  • Incorrect Smart Label: 0
  • Unsubscribe: 7
  • Update filtering: 1
  • Spam: 2
• Time per Message
  • Inbox: 05:16 (9.7 messages/minute)
  • Bulk: 03:33 (13.8 messages/minute)
  • Management (filters, etc.): 03:00 (3.3 messages/minute)
  • Total: 11:49
  • Average: 23.1 messages/minute

The post 30 Days of Email Domination: Three Weeks appeared first on Archetyped.

I heard you’re having problems using Simple Lightbox (SLB), the incredibly simple lightbox for WordPress. Have no fear, I made this rapid fire guide just for you.

You’re probably overthinking it

SLB strives to live up to its name– it’s incredibly simple to use. If things seem hard, it’s most likely because you’re used to the endless hoops of settings many plugins make you jump through just to start using them. With SLB, you really can just activate it on your site and it works.

Bottom line: Don’t overthink it.

What’s a lightbox?

Good question, this is a lightbox.

If you weren’t sure what to do just now, see the next section.

What’s a link?

This may be the most complex concept to grasp in order to use SLB. Thankfully, it’s very simple. On a web page, a link is something you can click on to make something happen. Navigating to another page or displaying images in a lightbox are made possible by clicking on links. Remember what you just clicked on in the previous section? That was a link.

SLB’s functionality hinges on links because there needs to be something on the page for users to click in order to display the lightbox. Specifically, SLB works with links to media such as images. If you have a link to a PNG, JPEG, GIF image file in a post, then SLB will load it in a lightbox rather than force the user to load a completely new page just for the image.

How do I create an image link?

Most users want to insert a small version of an image (i.e. a thumbnail) and have SLB display a lightbox of the full-size image when it is clicked on.

If this already sounds complicated to you, rest assured that it is very simple to do in WordPress. In fact, you’ll be an expert in it in less than 5 minutes.

First, read through WordPress’ official documentation on inserting images into posts and pages. It’s just a few steps, I’ll wait.

Next…well, that’s it! If you can insert an image into a post in WordPress then you know everything you need to insert an image link.

The key is the Image Link section in the aforementioned documentation. You need to make sure that this option is set to either Attachment Page or Media File before you insert the image into your post. This will wrap the inserted thumbnail image with a link that loads the full-size version of the image when it is clicked. Thanks to SLB, the full-size image will be displayed in a lightbox rather than loading an entirely new page.

Getting Help

Simple Lightbox should be…simple. If you’re having a problem with SLB, think you’ve found a bug, or even have a feature you’d like to request, please report it on SLB’s official issue tracker.

Noob no longer

Congratulations, you now know everything you need to use Simple Lightbox. You’ve graduated from noob to user.

The post Simple Lightbox for Noobs appeared first on Archetyped.

Nope.

I can’t say I had any difficulty with the wait at all. In fact, I seriously considered just letting it ride and steer clear of email for another whole week. The only reason I processed my messages today was because I needed to check for bills and bank statements.

Ruthless

Being ruthless about auto-blocking unwanted messages held additional significance today when I set up a filter to block messages from a family member who sends links to articles to everyone in the family. We all get emails from someone like this, but I still felt bad about it. However, since I’m not going to read those articles, these messages were just noise and had to go.

At first I thought, “it’s not so bad, I can just delete these messages as they come.” This confirmed once and for all that auto-blocking was my only option– never manually do anything that can be automated.

Two Better than One?

I was quite curious how long it would take to process 2 weeks worth of messages today. Would the increased message volume lead to faster processing? Would I end up with even more messages to filter? In any case, keeping message processing under 10 minutes did not seem likely, but I remained my goal nonetheless.

Thankfully, total message processing required less than 10 minutes with a bit of time to spare. Additionally, today’s average message processing rate is the highest since January, so that’s nice. All in all, I’d say that the 2 week experiment was a success.

On to three.

Today’s Stats

• Checked email: 1 time
• Time: 14:10
• Total messages: 163
  • Inbox: 23
  • Bulk: 39
  • Important: 0
• Management: 9
  • Incorrect Smart Label: 1
  • Unsubscribe: 4
  • Update filtering: 2
  • Spam: 2
• Time per Message
  • Inbox: 03:45 (9.9 messages/minute)
  • Bulk: 02:01 (19.3 messages/minute)
  • Management (filters, etc.): 03:48
  • Total: 09:34
  • Average: 17.0 messages/minute

The post 30 Days of Email Domination: On to Three appeared first on Archetyped.

I don’t miss it in the least.

Checking my messages has been a regular Saturday morning activity for the past 5 months, so I was curious about how I would feel when Saturday came rolling by without a visit to the inbox. Surprisingly, when I remembered that I wouldn’t be checking my email until next week, all I felt was relief. The thought passed and so did any urge to see how many unread messages I had.

Two weeks without email should be easy.

While Smartlabels have made managing messages a breeze, forwarding filters have virtually liberated me from email altogether. I no longer wonder whether there’s an important message waiting for me– when a message that I deem to be important arrives, I am notified immediately.

And that’s the problem.

Don’t get me wrong, I love my forwarding filters. Nonetheless, these instant message notifications– even if they are for messages that I want– are distractions. No, it’s worse– notifications are mind control.

Even if I’m completely focused on something else, when that little bell rings, my hand is lifting my phone out of my pocket to check the message before I even realize it. If I don’t check the message, like this morning when I woke up and saw that I had new messages, then I’m burning with curiosity until I do (I forced myself to wait for a few hours).

By Appointment Only

So what are you to do when your forwarding filters are deciding when you are notified about messages? Well, you ask if has an appointment of course!

1. Be Exclusive

First, I have completely disabled Gmail sync on my Android phone. This means zero notifications for new messages– no one gets in.

2. Set up Office Hours

Using the flexible Llama app, I set up an automated event that uses Synker to sync with Gmail once a day. Now email invades my mind on my schedule.

Finally, I’m Cheating

While my phone is now protected from rogue email notifications, my tablet is not. That’s right, I’ll still be getting instant notifications on my tablet, but there are two good(ish) reasons for this:

First, turning off sync 99% of the time is pretty aggressive, so continuing to receive notifications on my tablet is a “safe” way to test this on my phone while still having to instant notifications in case I did not account for all potential issues (note: I did not).

Second, the tablet is out of sight for most of the day, generally only coming out after dinner for some reading. As a result, even if the tablet is getting instant notifications, I generally will not be seeing them.

I’ll be testing this setup for the next week and report back.

The post 30 Days of Email Domination: Mind Control appeared first on Archetyped.

git checkout -b entry-cpt

Exciting, right? For everyone else, I have decided that entries will be a custom post type.

Why?

In the end, the decision wasn’t that hard. There are a few reasons why creating series entries as custom post types is ideal:

Organization is priority #1

The whole point of a series plugin is to organize posts. Letting organization take a back seat to other factors is simply not a good idea.

As a custom post type with strong connections to a series, entries will be well-organized by default.

Better Compromises

Each option had their risks and compromises. In the end, I can sleep better with the compromises of this option and I’m confident that most (if not all) of the issues can be handled with minimal hackery.

I Need to Use It

I’m sharing the development of this plugin because I want as many people as possible to benefit from it. Once it’s ready to go, I want as many people as possible benefit from the plugin itself as well.

However, I readily admit that I decided to create this plugin because I want it. While I would love for everyone else to use it as well, I must also accept that this plugin won’t fit certain users’ needs. The plugin needs to fit my needs because that’s the only way to guarantee its continued development.

New Territory

I’m jumping into highly untested waters from this point out. This is going to be fun.

The post Building a WordPress Series Plugin: Decision appeared first on Archetyped.

Option 1: Entries are Posts

The Rundown

Currently, entries are standard posts. Ultimately, options would be used allow the user to select which post types can be part of a series.

URI Structure

• Series: site.com/series/series-name/
• Entry: site.com/post-name/ (based on the site’s permalink settings)

Entry Management

• Existing management page for the entry’s post type
• Custom UI for listing/managing entries of a series

Good News

Flexibility

Flexibility is the star quarterback when any post type can be a series entry. Entries can be easily selected from existing and new content alike.

Series content could be as varied as the custom post types that are defined on your site. An image gallery here, a podcast there, and finish it off with a normal post! Anything is possible!

Bad News

Of course, there are some downsides to using any old post type as series entries.

Organization

Organization definitely suffers in this option. For example, our series about “Awesome Things” may have a URI such as:

site.com/series/awesome-things/

However, the URI of each entry in this series will be completely unrelated. For example, the URI for the “Kittens” entry would be:

site.com/kittens/

There’s no connection between the URI for a series and the URIs of its entries.

This is just one example of an organizational issue I refer to as Weak Links. In addition to URIs, an entry’s slug, taxonomies (e.g. tags, categories, etc.), etc. have no connection to the series it is part of. In fact, the only connection entries have to a series is a simple metadata value indicating the entry’s series.

Of course, there are ways to work around this. For example, we can prefix entry slugs with the series’ slug (manually or automatically). It’ll do, but it’s not ideal.

Simply wrangling all of a series’ entries could be an issue as well. Each post type in WordPress has it’s own admin page, so entries for a single series could be strewn about in multiple admin sections. Though this plugin will have its own UI for managing a series’ entries, the fact that an entry is accessible in multiple places in the admin creates a real management issue.

Metadata

Since any post type can be an entry in a series, there is also no good way to implement fields for entry-specific metadata on the post editor, making it difficult to identify specific entries within the context of a series. It would be pretty straightforward to display entry-specific fields once a post has been added to a series, but that would create an inconsistency between when a post is first assigned to a series (no entry-specific fields) and after that post is saved (entry-specific fields displayed).

Option 2: Entries are a Custom Post Type

The Rundown

Entries are fully-fledged custom post types in this scenario, just like the series that they belong to.

URI Structure

• Series: site.com/series/series-name/
• Entry: series-uri/entry-name (e.g. site.com/series/series-name/entry-name)

Entry Management

• Entries are explicit children of a Series (set using post_parent)
• Entries are managed via Series editor/management page
  • No specific menu item for general entry management
  • Series must first be selected to view its entries
  • Example: Series editor has “Add Entry” and “View Entries” buttons

Good News

Organized

Organization is vastly improved in this option.

URI structures are logical and hackable. Our “Kittens” entry in the “Awesome Things” series the following URI:

site.com/series/awesome-things/kittens/

Removing the kittens/ segment from the URI will bring us up one level to the series’ main page:

site.com/series/awesome-things/

When a user looks at the URI of a series or an entry, they will know exactly where they are in the context of a series.

In addition, this option creates the strongest possible link between a series and its entries using WordPress’ post_parent data. A post can have only one post parent, so there is zero confusion about what series an entry belongs to.

Simple

The workflow for creating entries for a series is clear and straightforward. Instead of creating a post and assigning it a series from the post editor (thus making it a series), an entry is created for a series. In this case, the chicken (series) always comes before the egg (entry).

This workflow also isolates series and entry management from other administration tasks. There is no way for entries to be modified (e.g. deleted, edited, etc.) via actions taken in other pages.

Basically, a structured workflow keeps things simple. Too many options and configuration makes things overly complex when the ultimate goal is simply to create content.

Metadata

As entries are a custom post type, they can have all the fields for entry-specific metadata we want. It would be dead simple to valuable data to an entry in the context of the series that it belongs to (e.g. milestones, final entries, etc.).

In addition, as all entries are explicit children of a series, we can let an entry inherit the series’ metadata (taxonomies, etc.) dynamically. This means you don’t have to type the same tags for each entry (only the tags that are unique to that entry).

Bad News

Flexibility

Though we gain a lot of ground in terms of organization and simplicity, we also lose ground in terms of flexibility.

For one, we can no longer add any type of post to a series. Entries can only be the custom post type created specifically for this purpose. This means that a series cannot be a grab bag of different types of content, but must fit within the constraints of what this custom post type allows.

One thing that I’ll be looking into is whether custom post types can take advantage of post formats. This would at least provide some additional variability in the type of content you can add to a series.

Obviously, there will be a way to convert existing posts to entries so that previously-created content can be integrated into series. This is no small task however, as there are several factors to account for (e.g. redirection from the entry’s old URI), so this functionality may be added in a later update.

As always, there are workarounds to allow other custom post types to be used as series entries, but as they all circumvent WordPress’ default behavior, it may be more of a hassle than it’s worth.

Visibility

Finally, as custom post types, series and entries would not show up in standard post queries (home, feeds, etc.) by default.

Depending on how you look at it, this actually might be a good thing since it means that you can keep series content separate from the rest of the site’s content if desired.

In any case, it is a fairly simple matter to integrate custom post types into default post queries, so this will likely be made available as a user option.

Decisions

As you can see, there are good and bad things about each option. Nonetheless, there are always tradeoffs with any decision, so I’m making the decision on which option to choose today. I’d be glad to hear any thoughts you may have as well.

I’m going to go for a ride. Maybe some fresh air will make things clearer.

The post Building a WordPress Series Plugin: Risky Business appeared first on Archetyped.

Beta 7 is a turning point for SLB in multiple ways.

Git Out

SLB has recently been migrated over to Git, which I’m very happy about. Among other things, Git facilitates a workflow that allow easy experimentation and fast iteration. Working on new features is far more controlled and manageable as a result.

SLB’s entire Git repository has also been published on GitHub. GitHub makes it easy to collaborate on projects using things like forking and pull requests. I initially published SLB’s Master branch to give users easy access to new releases. Later, I bit the bullet and also published SLB’s Development branch. It’s a little uncomfortable putting my raw code out there for you to see, but it’s ideal for anyone who wants to test the bleeding edge or wants to get involved in development.

All of this was actually possible since Beta 5; the big difference starting with Beta 7 is that I’ve optimized my workflow so that I can prepare releases far more easily. For example, Beta 7 has been released, but it’s not done. There are several new features planned for this phase, but I did not want to wait until they were all done before you had access to them. As a result, Beta 7 is being released in multiple stages. Once a new feature is done, it’s heading out into the big world for all to test it. Young features are impatient– they don’t want to wait for their brother and sister features to be ready.

What this means for you: More frequent updates. (Why didn’t you just say that? Geez.)

Content Handlers

One of the major features of SLB 2.0 is support for multiple content types. Why should images have a monopoly on lightboxes? What about videos, forms, and even tweets?

SLB 2.0 was built from the ground up to support multiple content types, and Beta 7 provides an API for developers to add support for any type of content quickly and easily.

What this means for you: Any type of content can be displayed in a lightbox. (Didn’t I just say that? Really…)

Even SLB’s default content types (e.g. images) use the new Content Handler API:

$handlers->add('image', array(
    'match'         => 'match_image',
    'client_script' => 'handler.image.js'
));

Match

The match property specifies the callback function used to determine if a link matches this content type. The callback does not have to be anything fancy; for example, here’s the callback to match image links:

/**
 * Matches image URIs
 * @param string $uri URI to match
 * @return bool TRUE if URI is image
 */
public function match_image($uri) {
    return ( $this->util->has_file_extension($uri, array('jpg', 'jpeg', 'jpe', 'jfif', 'jif', 'gif', 'png')) ) ? true : false;
}

Client Script

The client_script property specifies a JavaScript file to load in the browser for client-side functionality. This controls things such as how the content is rendered in the lightbox.

The file path provided in client_script is relative to WordPress’ plugins directory.

The client script code needs to return an object which is added to the content handler. Here’s the client script for images:

(function($) {
return {
    render: function(item) {
        var dfr = $.Deferred();
        //Create image object
        var img = new Image();
        var type = this;
        //Set load event
        var handler = function(e) {
            //Save Data
            item.set_data(this);
            //Set attributes
            var dim = {'width': this.width, 'height': this.height};
            item.set_attribute('dimensions', dim);
            //Build output
            var out = $('<img />', {'src': item.get_uri()});
            //Resolve deferred
            dfr.resolve(out);
        };

        //Attach event handler
        if ( img.addEventListener ) {
            img.addEventListener('load', handler, false);
        } else if ( img.attachEvent ) {
            img.attachEvent('onload', handler);
        } else {
            handler(img);
        }
        //Load image
        img.src = item.get_uri();
        //Return promise
        return dfr.promise();
    }
}
})(jQuery)

Register

All that’s left is to register the new content type at the appropriate time:

/**
 * Add custom content handler(s)
 * @param object $handlers Content Handlers
 */
public function my_custom_content_handler($handlers) {
    $handlers->add('handler-id', array (
        'match'         => 'match_callback',
        'client_script' => 'path-to-handler/handler.handler-id.js'
    ));
}

//Hook into content handler initialization
add_action('slb_content_handlers_init', 'my_custom_content_handler');

That’s all there is to it! When links are processed on the server, the registered content handlers are cycled through until a match is found and assigned to the link. To make things as fast as possible, only the content handlers that have been matched to a link will be loaded into the browser.

Priorities

Content handlers can also be prioritized so that a handler can be evaluated before other handlers. For example, if you wanted to create a custom handler for Flickr images, then you would want links to be matched against this handler before the standard image content handler.

Setting a content handler’s priority is easy and follows the example of WordPress’ own add_action()/add_filter() functions. That is, by default, all handlers have a priority of 10. If a handler should be evaluated earlier, use a lower number (e.g. 1-9). Conversely, if a handler should be evaluated later, use a higher number (e.g. 11+). All content handlers with the same priority will be evaluated in the order that they were registered.

Basically, content handlers are added like so:

$handlers->add($id, $properties, [$priority]);

Here’s an example of registering a content handler with a high priority:

/**
 * Register content handler for Flickr images
 * @param object $handlers Content Handlers
 */
public function register_flickr_handler($handlers) {
    $args = array (
        'match'         => 'match_flickr',
        'client_script' => 'path-to-handler/handler.flickr.js'
    );
    $handlers->add('flickr', $args, 5);
}

//Hook into content handler initialization
add_action('slb_content_handlers_init', 'register_flickr_handler');

The Content Handler API is quite robust and new handlers can easily be added to SLB!

Template Tags

Template tags also get a shiny new API in this update. Adding your own template tags is now easier than ever.

$template_tags->add('tag-name', array(
    'client_script' => 'path-to-file/tag.tag-name.js'
));

Client Script

Like content handlers, template tags have a client_script property that specifies the JavaScript file that will be loaded in the browser to handle a template tag’s client-side functionality. This controls how a template tag is rendered in the browser.

The file path provided in client_script is relative to WordPress’ plugins directory.

The code in this file returns an object which is added to the template tag. Here’s the client script for the {{item}} template tag:

(function($) {
return {
    render: function(item, tag) {
        var dfr = $.Deferred();
        var m = 'get_' + tag.get_prop();
        var ret = ( this.util.is_method(item, m) ) ? item[m]() : item.get_attribute(tag.get_prop(), '');
        if ( this.util.is_promise(ret) ) {
            ret.done(function(output) {
                dfr.resolve(output);
            });
        } else {
            dfr.resolve(ret);
        }
        return dfr.promise();
    }
}
})(jQuery);

Register

Once the client script is ready, all that’s left is to register the new content type at the appropriate time:

/**
 * Add custom template tag(s)
 * @param obj $tags Template tags collection
 */
public function my_custom_template_tags($tags) {
    $tags->add('mytag', array(
        'client_script' => 'path-to-file/tag.mytag.js'
    ));
}

//Add hook to register custom template tags
add_action('slb_template_tags_init', 'my_custom_template_tags');

If that seemed really simple, that’s because it is! In-depth documentation on how to develop custom template tags is forthcoming, but the focus for this release was getting the API in order. Thankfully, the work done the content handler API made this pretty simple to do and much of the code is shared between these APIs.

Themes

The Theme API has also been updated to align with the other component APIs in this release.

$themes->add('theme-id', array (
    'name'          => 'Theme Name',
    'parent'        => 'parent-theme',
    'layout'        => 'path-to-file/layout.html',
    'client_script' => 'path-to-file/client.js',
    'client_style'  => 'path-to-file/style.css',
));

Name

The name property defines the theme’s display name. The name is displayed in the theme selection list.

Parent

Themes can optionally have a parent that they inherit the properties of. This makes customizing existing themes incredibly simple. For example, if you want to update the CSS of SLB’s default theme (ID: slb_default), you would simply add a new theme, but only define the client_style parameter:

$themes->add('my-child-theme', array (
    'name'          => 'My Child Theme',
    'parent'        => 'slb_default',
    'client_style'  => 'path-to-file/my-style.css',
));

Layout

The layout is a file that contains the HTML for the theme’s lightbox. The layout contains standard HTML and template tags that control how an item’s data is displayed when viewed in the lightbox.

Client Script

Like the other components, themes have a client_script property that specifies the JavaScript file that will be loaded in the browser to handle a theme’s client-side functionality. This controls a theme’s capabilities such as animations, etc.

The file path provided in client_script is relative to WordPress’ plugins directory.

Client Style

Finally, the client_style property specifies a CSS file for the theme.

Just like the client_script property (and all other file paths in these APIs), the file path provided in client_style is relative to WordPress’ plugins directory.

Register

Theme’s are registered just like other components:

/**
 * Add custom theme(s)
 * @param obj $themes Themes collection
 */
function my_custom_theme($themes) {
    $themes->add('theme-id', array (
        'name'          => 'Theme Name',
        'parent'        => 'parent-theme',
        'layout'        => 'path-to-file/layout.html',
        'client_script' => 'path-to-file/client.js',
        'client_style'  => 'path-to-file/style.css',
    ));
}

//Add hook to register custom theme
add_action('slb_themes_init', 'my_custom_theme');

Simple!

Get the Beta

Want to get access to the next generation of Simple Lightbox and be part of its progress? Get the beta now and leave feedback!

Next Steps

SLB 2.0 Beta 7 was a big update. Simple Lightbox 2.0 is now feature complete and from here we’re going to move straight into release candidates.

The post SLB 2.0: Beta 7 appeared first on Archetyped.