• 1,346 Craft licenses have been issued.
  
• 19 updates have been released including 94 bug fixes, 87 improvements, and 33 new features.
  
• 205 packages have been purchased by extremely intelligent, charismatic, and hard working people.
  
• 376 package trials have been started by equally gifted people that might have some commitment issues to work through.
  
• 568 awesome members in our very helpful Google+ community!
  
• 1,365 tweeple are following @craftcms on Twitter.
• 2,007 one-click auto-updates have been successfully served. Turns out that people like to stay up-to-date if you make it easy enough.
  
• 7 engaging community chats and events.
• 9 - The impressive percentage of visitors to our site from Germany. The Germans... they love Craft.

We just released Craft 0.9.2218 which separates the date and time inputs, gives time selection its own menu (using jquery.timepicker), and it even displays the dates and times based on the date/time formats defined by the user’s preferred locale. So people in the US are going to get dates displayed as MM/DD/YYYY, while people in the UK will get DD/MM/YYYY.

Date fields also got a new “Show time” setting, so now you get to choose whether your Date field is just for a date, or for a specific date and time.

We’ve also beefed up Craft’s Timezone setting to include all known timezones rather than just the ones that have unique abbreviations, and there are a few bug fixes in there as well. So fire up those auto-updaters!

Time support

That’s right – you can finally set the time of day within entry Post/Expiration Date fields, as well as within your Date fields. We’re even displaying the time in the proper 12 or 24-hour format depending on your preferred locale.

Dates and times are displayed in the site’s timezone (set in Settings > General), but continue to be stored in UTC.

Rich Text improvements

The Rich Text fieldtype got a lot of love in this update. We dropped the Min Height setting in favor of full-blown custom Redactor config support. Now you can place .json files in craft/config/redactor/, and they will be available config options when editing your Rich Text fields. We’ve even started bundling two configs with Craft for you – Simple and Standard.

Next up, while we wait for Redactor 9.0 with its promised HTML output improvements, we figured we’d give Rich Text fields a new “Clean up HTML?” setting. If it’s checked (and it’s checked by default), Craft will remove all <span> tags, empty tags, and most style attributes from the submitted HTML.

And finally, we’ve written a new Page Break plugin for Redactor, which is included in the new “Standard” config. It adds a new button to your Redactor fields labelled “Insert Page Break”. When you click it, Craft adds a marker to your content at the insertion point. There are three template functions available to you for getting all individual pages in an array, getting a specific page, and getting the total number of pages. The final code example on that page is exactly how we’re doing the “Read more” links on pixelandtonic.com/blog.

Here are links to the release notes:

• Matrix 2.5.4
• Wygwam 2.7.1
• Playa 4.4.2
• Assets 2.1.1

We’ve also taken this opportunity to drop the ee1/ folders from Matrix and Wygwam. At this point we haven’t touched the EE1 files for quite some time, and the latest versions we’ve released are pretty stable so we don’t expect to be doing much more maintenance on them going forward.

If you have a need for an EE1 version of Matrix, Wygwam, or Playa, you can request it by emailing us at support@pixelandtonic.com.

Oh, and one more thing…

Field Pack 2

One of our favorite features in EE 2.6 is the ability for each add-on package to provide multiple fieldtypes. That enabled us to revisit the old Dive Bar fieldtypes, and package them all up into a single add-on, which we’re calling Field Pack 2.

We’ve made a few EE 2.6 compatibility updates to Field Pack’s bundled fieldtypes as well, so be sure to grab it if you’re running any of the old Dive Bar fieldtypes.

We’ve taken time to ensure the upgrade process from the Dive Bar fieldtypes goes smoothly as well. When you install a Field Pack 2 fieldtype, it will check if its Dive Bar counterpart was installed. If it was, it’ll handle the field conversions and fieldtype uninstallation for you. All you have to do is delete the old files.

We’ve been working on Craft for 2 1/2 years now, and throughout that time, we’ve kept up the pace on maintaining and supporting all of our add-ons. We’ve even written a major update to Assets, which in and of itself was the most challenging thing we’ve ever done with ExpressionEngine.

EE 2.6 is about to come out. While we’re not thrilled about one particular new feature, there are some cool things in the release that we’re very excited about, and have already taken advantage of in one of our add-ons. (More on that soon!)

Times have changed, and so the time has come to to rethink this site’s purpose. There are things it should be focussing on that it wasn’t, and things it shouldn’t be focussing on anymore that it was.

Devoted to devot:ee

Back when the site launched, devot:ee was in its infancy, and its add-on store was merely a twinkle in Ryan Masuga’s eye. Now that site is a vital resource for the EE community, and with its user reviews, favorites, store, and now lists, it’s a much better place to find out about, share, and purchase our add-ons than this site could ever be. So rather than try to compete with that, we have decided to let devot:ee handle the dedicated add-on overview pages and purchasing exclusively. The EE add-ons section of this site is now an elegant menu of our add-ons, with links to devot:ee.

If you’ve purchased any add-on licenses on pixelandtonic.com in the past, all of those licenses have already been transferred to your devot:ee account. If you don’t have one, or there’s an email mismatch between your devot:ee and former P&T accounts, you’ll receive an email with instructions to reclaim your licenses.

Static add-on docs

As of today, all of our add-on documentation is available as good ol’ Apache-served HTML files at docs.pixelandtonic.com. We’ve been meaning to do this for a while now – this way they can remain available even when we need to take our site down for maintenance.

New pages

We’ve added two new pages to the site: Craft and About Us. The Craft page features a gorgeous photo taken by the super-talented Ashley Baxter, and About Us has illustrations and quick bios for each of us.

Built with Craft

If there’s any wonder, yes the new pixelandtonic.com was built with Craft. We like it!

If you’re interested in hearing about the more technical aspects of Craft, it’s definitely worth a read!

Some changes were required to Better Workflow to make this possible, so you’ll need to grab the just-released BWF 1.6 as well. Many thanks to Electric Putty for working with us to make this happen!

Playa 4.4 also includes security and performance improvements, making this a highly recommended update for all Playa users, even if you aren’t using BWF. View the release notes for a full list of changes.

If you’ve been thinking about using either of those platforms for file storage or as a CDN, you now have a great way to connect your favorite CMS to them!

Assets also got lots of handy new template tags, enabling you to do things like output a complete folder/file tree based on your Assets sources. Check the release notes for a full list of new features.

Here’s what one person had to say about it:

lots of useful info gleaned chatting with the @craftcms folks - lovely looking product backed up by a really nice team. HipChat a nice tool!

— Al Power (@alpower) March 29, 2013

We have decided to make Craft Chats a regular thing. Friday at 1:30 PST worked out really well for us, so we’re going to stick with that for now.

The URL is going to change week-to-week, so make sure you’re following @craftcms on Twitter to get notified.

Talk tomorrow!

30-day Free Package Trials

A number of people have requested a way to try out Craft’s five extended feature packages. While we did make it possible to give them a spin via our On the Rocks demo site, that was just a stopgap solution. Now with the latest Craft release, there’s a new “Try” button right next to each package’s “Buy” button, which will start your 30-day free trial. No credit card is necessary – the package is immediately installed, and you have 30 days to decide whether you want to buy the package or uninstall it.

Table Fieldtype

One of the most popular feature requests we’ve received is for Matrix. While that’s definitely on the roadmap, our plans for Matrix are pretty ambitious and it will probably end up being a commercial plugin. There are plenty of use cases for a simple table field without all the bells and whistles however, so we created a new “Matrix Light”-esque fieldtype, called Table.

With Table, you can set up multiple columns, and for each one choose a Heading, Handle, Width, and Type (Single-line Text, Multi-line Text, or Number). The columns and the rows are sortable with drag-n-drop, and you can loop through the rows in your templates using a simple for-loop.

Date Fieldtype

We’ve also added a new Date fieldtype, which summons a standard jQuery Datepicker. Dates are stored as MySQL DATETIME columns, so you can set it to dates before January 1, 1970 without issue.

Introducing the Forecast Page

Unrelated to this new Craft release (but awesome nonetheless), we just launched a new Forecast page on buildwithcraft.com. It pulls in our “Craft 1.0” to-do list on Basecamp daily, so you can get a sense of what’s in store for Craft as we work toward 1.0. Check it out!

• 606 Craft licenses have been issued.
• 3 Craft updates have been released, with a total of 12 improvements, 12 bug fixes, and 5 new features.
• 267 one-click updates have been issued.
• 296 people have joined Craft’s Google+ community.
• 2 community-orchestrated events have taken place.

In today’s release, we added a pretty awesome new feature: On Demand Asset Transforms. It’s easier to show you this feature than explain it, so we created a video of the feature in action:

So, lots going on. We’re having a ton of fun with this, and we hope you are too!

If you have’t been paying attention, Craft is a beautiful, robust, extremely powerful, ridiculously flexible CMS which we’ve been diligently working away on, mostly in secret up until a few months ago.

Yes, we renamed it. (Previously we called it Blocks.) There was some legal influence in the decision, but ultimately it came down to the fact that we built something very different than we set out to build. “Blocks” was the name of a lightweight little CMS that sounded like a fun 6 month project back in 2011. Those six months passed, another six months passed, and then another before we realized what we had done – built a real, full-featured CMS that we had completely fallen in love with.

It wasn’t until a few weeks ago, as we started figuring out how to market the thing, that we realized that “Blocks” didn’t really make sense anymore. We knew our target market, and we knew who wasn’t in our target market, and decided that we needed a name that helped identify that. The CMS is for people who like to take their time and do things right. It’s for those of us who truly approach our work with the utmost skillfulness and craft. We craftsmen actually like writing every last HTML tag by hand, and we wouldn’t touch an off-the-shelf theme with a ten-foot stick.

If you can identify with that, I highly recommend that you give Craft a shot. Today marks its first day in Public Beta, and it has really shaped up to be something great. We’re totally thrilled to have made it this far, and we can’t wait to see what you do with it!

We will be posting more about Craft in the coming weeks – we have plenty of stories to tell! – but if we make this post any longer we’re going to lose half of you, so we’ll keep it short and sweet. Go download Craft!

Without further ado, here are the winning photos, in the order they were submitted:

Darcy O’Neil

Derek Hogue

Adam Kragt

Paulo Elias

Chad Clark

Seamus Holman

Lea Alcantara

Luca Di Bella

Brendan Underwood

Wim Bezemer

Ian Pitts

Matt Gossman

Gomi Child

Erwin Heiser

Simon Cox

Congratulations, guys! We’ll be contacting each of you shortly to find out where we should send your Assets 2 license.

By far, the most popular request we received was for Amazon S3 support. There was just one little problem: the Assets codebase was very much married to EE. To simply lump S3 support onto it would have been freakishly hacky – a maintainability nightmare. If we were going to do it with any sort of elegance, we’d have to rewrite it from scratch.

Blocks was already well underway by the time Assets launched, and it was looking more and more like it would be a real thing. Of course, it too would need a good file manager. With that in mind we decided to go ahead and start rewriting Assets, with a new architecture that refactored all of the EE upload directory-specifc code into its own “connector class”. That approach would enable us to add new connectors with relative ease, like one for Blocks, and one for S3.

Now, a year and a half later, we finally get to show you what has shaped up to be a very awesome Assets 2.0 release.

What’s new?

Amazon S3

In case it wasn’t obvious, yes, Assets 2 can connect to S3. You can hook it up to as many S3 buckets from as many AWS accounts as you want. They’ll show up right alongside the rest of your EE upload directories, and you can drag files and folders around between them all, just like you could in Assets 1. It’s really quite magical.

File Indexing

To speed things up, and prevent excessive S3 requests, Assets now stores a record of all of your files and folders in the database. There’s a new “Update Indexes” tab in Assets’ module where you can tell Assets which EE upload directories and/or Amazon S3 buckets to reindex (similar to EE’s “Synchronize” feature). We’ve also added a “Refresh” button to Assets’ file manager, which will quickly reindex whichever folder you’re currently viewing.

Conflict Resolution

When you upload a file with the same name as an existing file, Assets now lets you chose how to proceed. You can rename the new file, replace the original file, or cancel the upload. We didn’t stop at file uploads: you’re given similar choices any time you perform any action which would result in two files or folders with the same name living in the same directory.

Lossless File Replacement

You can now replace existing files while preserving the original file’s metadata and entry associations. Simply upload a new file with the same name as the original. When you’re asked how you want to handle the naming conflict, choose to replace the original file, and presto: new file, same old metadata.

New Module Tags

We’ve given Assets two of its own module tags: {exp:assets:files} and {exp:assets:folders}. You can use them to access your files and folders directly from your templates, rather than going through an Assets field.

Simple File Uploading for SafeCracker

If you have a SafeCacker form and would like users to be able to upload a file to your Assets field with a simple HTML file input, now you can.

Redesigned from the Ground Up

What major P&T add-on update would be complete without a new UI? We pulled all the stops on this one: Assets 2 has been completely redesigned from the ground up. It’s really quite something, and we think it sets a new bar for how beautiful EE2’s control panel can be. The whole thing is Retina-ready (including image thumbnails!), so if you’ve got a Retina MacBook Pro, you’re in for a treat.

Available Now!

Assets 2 is available now for $99. And it’s a free upgrade for all Assets 1 licenses. We’re really excited to get this out there. It’s a pretty amazing update, and we think you’re going to love it.

We kicked off a private beta in mid-November, and it has been going great. You couldn’t ask for better beta testers. They’ve really been putting Blocks through its paces: they’ve been reporting bugs, sharing ideas, and building plugins (not to mention building websites).

There’s a Google Group dedicated to the beta where literally hundreds of discussions have taken place. It’s been invaluable to us as we shape Blocks. Our beta testers have provided direction for things as simple as how to access the CP (looking for an “/admin/” URL segment rather than requiring a separate admin.php file), to much broader subjects like content localization.

So to all of our beta testers: Thanks for your help! Blocks will be better for it.

If you weren’t invited to the beta, don’t worry – you’ll get your chance to play soon enough. We’re just wrapping up a couple big under-the-hood changes, and then we’ll open the beta up to the public. At that point Blocks will be 99% feature complete for 1.0, and it’ll just be a matter of building out blockscms.com.

…“just”.

Anyway, we’re thrilled with the progress we’ve made in the past couple months, and the passion and excitement of this new little Blocks community is truly inspiring. This is fun!

For years, we’ve been dreaming of a place where customers can get support for EE and their add-ons, all under one roof. And thanks to the the initiative and drive of the awesome EE community, that dream is becoming a reality.

You’re probably familiar with the developer Q&A site, Stack Overflow – it’s at the top of most Google searches for anything related to web development. The guys who created Stack Overflow have also created a whole network of domain-specific Q&A sites, called Stack Exchange. And now there’s a new Stack Exchange site dedicated to ExpressionEngine: expressionengine.stackexchange.com.

There have already been a number of questions posted involving P&T’s add-ons, so a couple weeks ago we started subscribing to our products’ tags and helping out where we can. And as of today, we’re making EE Stack Exchange our primary support site.

To ease the transition, we’ve built a whole new Support page, with a centralized search that brings in results from EE Stack Exchange as well as our old Get Satisfaction site. We’ll continue monitoring Get Satisfaction, but in two weeks we’re planning on putting the site in an archived state.

Thanks to all of you who have made the EE Stack Exchange a reality. Your hard work has really paid off!

“bring it”

OK!

If you haven’t had the pleasure of meeting her, you’re in for a treat! Lisa is kind, fun loving, and eager to help.  We’re placing her at the helm of community outreach, where she’ll do what she does best: help people succeed, and cultivate a community of passionate, web-loving individuals.

Lisa’s first day will be Monday, November 12, but that hasn’t stopped her from spending her down time playing with Blocks (see what we did there?).

Here’s what she had to say:

“I am excited to join Pixel & Tonic in building an exciting, engaging, and innovative community. Cheers to a bright future; let us journey together to new adventures, my friends!

You can catch Lisa on Twitter @lisajill, and she blogs at lisajill.net.

Welcome to the team, Lisa!

Ironically, the question we expected to hear the most, hasn’t been asked even once: Why bother? Perhaps that’s because the answer is obvious: This is what Pixel & Tonic was created to do.

What’s special about it?

Blocks gets its name from its biggest feature: Content Blocks. It’s our name for “fields”. We realize that every site is different, and has different content requirements. So out of the box, we supply only the bare minimum of content-y fields – titles for entries, first and last names for users, etc. Beyond that, the choice is yours. Sections, pages, users, and assets all get their own “content block sets”, where you can define exactly which content blocks you want to be associated with them. From a development perspective, we’ve made it extremely easy to add content block support to entities in the system, so plugins will be able to take advantage of them as well, with very little effort.

Beyond content blocks, the entire system is filled with goodies that will make you smile: Internationalization support, entry drafts and versioning, multi-group assignment for users, one-click updating (for the system and for plugins), and extremely powerful templating, to name a few. Oh, and did we mention that it’s P&T-designed?

If you’re a fan of our add-ons, it’s safe to say you’re going to love Blocks.

Who’s it for?

Blocks was built for web designers and developers who like to code every last HTML node by hand. It’s for web agencies that strive to make their clients happy by delivering the best solution possible. And it’s for site owners, who just want a simple tool to keep their website updated with fresh content, without going up a steep learning curve.

What types of sites can be built with Blocks?

It’s hard to answer this question without sounding a little crazy, but here goes. Whether you want to build a small brochure site, a multi-section news site, or anything in between, we want Blocks to be the best CMS option you’ve got, from both cost and feature perspectives.

To accomplish that, Blocks has been divided into 6 parts: the core, and five strategic packages, each providing features geared at different types of sites. When you go to purchase Blocks, you can pick and choose which packages you want included, based on your site’s requirements. As your site grows in scope, so can the CMS.

So what are they? Publish Pro ($100) adds multiple section support, entry drafts and versioning; Users ($100) adds user management, groups and permissions; Language ($100) adds internationalization support; Cloud ($50) adds Amazon S3 and other cloud-based file management support; and Rebrand ($50) adds the ability to brand the system for your agency or client. Oh, and if you’re building a simple website with no use for any of those packages, we’re going to give you Core…(drum roll please!)… for free.

Just how extensible is it?

It should go without saying that we’re big fans of plugins here at Pixel & Tonic. So rest assured, Blocks has been written from the ground up with extensibility in mind. The app has a comprehensive service layer providing APIs that handle absolutely all the business logic, and plugins can tap into those APIs in the exact same way that the core components do. Plugins can even offer their own APIs, enabling cross-compatibility with other plugins. They can have their own controllers, front-end resources, templates… the list goes on. So yeah… Blocks is pretty darn extensible. And if you just want to write a plugin that adds a new block type or widget to the system, it’s as easy to do as it should be.

When will it be available?

We’re gearing up for a private beta as quickly as possible. The initial focus will be finalizing our plugin APIs, so plugin developers will get access first. Once we’re ready, we’ll start to let more people in, and keep scaling it until we’re ready to launch 1.0. To stay in the loop, you can either follow @blockscms on Twitter, or signup for the newsletter on blockscms.com.

What does this mean for our EE add-ons?

In a word: Nothing. ExpressionEngine is a great tool and we’re honored to be a part of its community. We’ve had two years to figure out how to balance working on Blocks and EE add-ons side by side, and we’ve made it work. We’ll continue to maintain and support our existing add-ons, and even write new ones when we feel so compelled.

So there you have it! Hopefully this answered most of the big questions floating around, but if you’re still curious about something, feel free to email us or ask on Twitter. We’re extremely excited about Blocks, and we hope you are too.

We’ve got a big add-on update coming out soon, and we need your help! Before we can launch, we need lots and lots of pictures of adult beverages.

Go out tonight and order your favorite cocktail/vino/beer, snap a photo of it, and send it to ontherocks@pixelandtonic.com. If we end up using your photo on our website, we’ll add a free add-on license to your account!

There’s no limit to the number of photos you can send us, or to the number of licenses we’ll give you. You have until 11:59pm PST next Friday (October 12) to send us your photos.

Drink up!

The not-so-fine print: Please don’t send us any photos that you didn’t take yourself. By sending us photos, you grant Pixel & Tonic free license to use them for promotional purposes for the rest of time. (You still own them though!) Pixel & Tonic is not responsible for any harm done to yourself, anyone else, or your camera, as a result of drinking alcoholic beverages. Please drink responsibly.

Finally about a month ago we decided it was time to get serious. So we opened up a new job posting, and spent two solid weeks emailing, IMing, and video chatting with a slew of candidates.

We’re excited to announce that we’ve found our guy!

His name is Andris Šev-something-or-other, he lives in a small village called Latvia, and his favorite whiskey is Laphroaig.

Today was his first day, and he hit the ground running. He updated Matrix Multi-Upload to support image manipulation preferences and the exp_files table, so it’s no longer necessary to sync your upload directories after uploading files.

You can catch Andris on Twitter (@piparvecis), so make sure to give him a big #eecms welcome!

To make sense of the name, first let’s do a quick refresher on Playa’s terminology:

Say you had two channels, Ingredients and Drinks. You want to store which ingredients go in each drink, so you put a Playa field on the Drinks channel called “Ingredients”. You create a new Drinks entry, called “Gin & Tonic”, and within the Ingredients field, you select “Gin” and “Tonic Water”.

In that example, the “Gin & Tonic” entry becomes the parent of the “Gin” and “Tonic Water” entries. Likewise, the “Gin” and “Tonic Water” entries become the children of the “Gin & Tonic” entry, as well as siblings of each other.

Now you create a new entry, “Vodka Tonic”. Its ingredients are “Vodka” and “Tonic Water”. Same story here – “Vodka Tonic” becomes a parent, “Vodka” and “Tonic Water” become children, and siblings of each other. But as of Playa 4.3, one additional relationship is formed: Since both “Gin & Tonic” and “Vodka Tonic” share the child “Tonic Water”, they become co-parents of each other.

One last Drink entry to add: “Pixel & Tonic”. This one’s ingredients include “Red Bull”, “Gin”, “Bitters”, and “Tonic Water”. With this entry in place, two new co-parent relationships are formed: P&T-to-G&T (via “Gin” and “Tonic Water”), and P&T-to-VT (via “Tonic Water”). This case illustrates another feature of co-parent relationships: When you show an entry’s co-parents in the templates, they will be ordered by the number of common children between the entries.

That makes for a useful way to use Playa to show similar entries. Take this template, for example. Pretend it’s the Drinks’ single entry page template, located at drinks/index.

{exp:channel:entries channel="drinks"}
  <h1>{title}</h1>
  {description}

  <h3>Ingredients</h3>
  <ul>
    {ingredients}
      <li>{title}</li>
    {/ingredients}
  </ul>

  <h3>Similar Drinks</h3>
  <ul>
    {exp:playa:coparents field="ingredients"}
      <li><a href="{path=drinks/{url_title}">{title}</a></li>
    {/exp:playa:coparents}
  </ul>
{/exp:channel:entries}

If you were viewing the single entry page for “Gin & Tonic,” both “Pixel & Tonic” and “Vodka Tonic” would show up under Similar Drinks. “Pixel & Tonic” would come first, since they share two of the same ingredients.

There are three new tags for getting at co-parent relationships: {exp:playa:coparents} (shown above), {exp:playa:total_coparents}, and {exp:playa:coparent_ids}. Read all about them in Playa’s Template Tags and Parameters page in the docs.

We’re looking forward to what you’ll accomplish with this!

These were the last two stragglers, so as of today, we can say that Pixel & Tonic offers Low Variables compatibility across the board!

This has been, by far, the most popular feature request for Matrix, so this should be great news for many of you.

In related news, you can now buy Assets, Matrix, and Playa from EngineHosting while you’re signing up for a new hosting account. They’ll even install them for you!

Well, the results are in, and we’re happy to announce that our very own Assets has been voted 2011’s Module of the Year!

Beyond that, Matrix Multi-Upload is a runner-up for Accessory of the Year, and Pixel & Tonic is a runner-up for Developer of the Year.

So, a big Thank You to all of you who voted for us! And congrats to the other winners! It’s been a great year for EE add-ons.

We’re looking for someone who:

• is proficient at PHP
• is reasonably competent at HTML/CSS/JS
• has experience developing a CodeIgniter application and/or ExpressionEngine add-on (EE 1 or 2)
• has experience using Playa, Matrix, or Assets
• has strong communication skills and a desire to help others succeed

Assets is composed of two parts: a module and a fieldtype. The module hosts a full-blown file manager, unlike anything you’ve ever seen on the web. Two different view modes, file name searching, subfolder support, folder/file drag-n-dropping, the list goes on. We set out to make this thing as easy to use for standard CRUD operations as your desktop OS’s file windows, and I think we’ve achieved just that.

The fieldtype enables you to associate files with your individual entries, or Matrix cells. You can choose to allow multiple file selections, or just one. You can also restrict it to specific EE upload directories if you want. And the selected files can either be displayed as thumbnails or in a list view.

Double-clicking on a file, either in the module or an Assets field, reveals a little modal window where you can edit the file’s metadata, including Title, Date, Caption, Author, and more. Changes you make here are global, so you don’t have to keep entering the same stuff over and over again. And all of that metadata, as well as other basic info about your files, are readily available for your templates, via Assets’ powerful template tags.

We’ve made it easy to convert File fields over to Assets fields – simply edit the field, and change its Field Type to Assets, and Assets will update your existing entries for you. And if you’re using Wygwam, we’ve even updated that to support Assets’ file browser for file selection. So you can finally have a consistent file browsing experience throughout your Publish page.

Assets is available now for just $55, so go check it out! We think you’ll agree that Assets is file management done right.

Up until now, we’ve always included the stock release of CKEditor, never modifying it beyond our custom skin. When a request came along that fell into CKEditor’s turf, we’d just shrug and apologize that it’s not something we have control over.

But here’s the thing: Unlike the other CKEditor implementations for ExpressionEngine, Wygwam is actually an OEM-licensed application for CKEditor (and CKFinder). Which is why we’re allowed to distribute it as part of the add-on, rather than requiring you to download and install it separately. With that, we’re also free to modify it to our liking. So it’s never been a legal matter that we haven’t touched CKEditor; just that we haven’t taken the time to get to know it.

With Wygwam 2.2, we’ve finally rolled up our sleeves and started digging around in the internals of CKEditor, tweaking things here and there. So that Pages and Structure integration, that Relationship field in the Link dialog – those were changes we were able to make right in CKEditor’s core code. No external hacks required.

And those are just the beginning! We’ve already got a list going of changes we’d like to make, and are analyzing the best ways to go about them.

Of course, we’d love to hear your thoughts as well. Do you have any special features you wish Wygwam had? Let us know!

The update packs some new UI goodness (as always), plus a ton of big under-the-hood changes that make Playa more powerful than ever!

Translucent UI

Playa now sports the same translucent UI styling that we pioneered with Matrix 2, making your Playa fields look stunning regardless of which Control Panel theme you’re using.

Autocomplete for Single-Selects

We’ve written a new single-select UI with autocomplete, for the times you only want to allow one selection. This is especially useful if you’ve got hundreds or thousands of entries to choose from – no more scrolling through a list of entries a mile long!

New Database Table

We know this isn’t quite as sexy as the UI stuff, but it’s a very huge part of this update. Playa has outgrown EE’s native exp_relationships table, and has moved into its own exp_playa_relationships. This has enabled us to significantly simplify parts of the code, while making Playa more powerful at the same time.

Playa Converters

We’ve made it much easier to convert Relationship fields and even relationships created by Solspace’s Related Entries module over to Playa.

Seriously Powerful Templating

We’ve added tons of new templating tags, and even enhanced the ones that were already there. With Playa 4, you’re free to do what you want.

Dropping EE1 Compatibility

Now that ExpressionEngine 2 has been out for over a year, we decided it’s time to stop worrying about EE1. So starting with Playa 4, all major new Pixel & Tonic releases are going to be for EE2 only. We do realize that some people still need to use EE1 though, so for the time being we’re bundling the latest release of Playa 3 in with the download.

EECI2010, The Netherlands

On the second night of this year’s European EECI conference, we’re sponsoring the “P&T PartEE”. And we’ll be there to enjoy it too, so make sure to say hi!

ExpressionEngine Camp, Denver, CO

Live in the US? You should check out ExpressionEngine Camp, which looks like it’ll be a promising event in late October. The best part? The venue has a bar!

Naturally, we’ll see to it that both events are serving pixel and tonics :)

So today, we take the wraps off of a new section here on P&T.com: the Dive Bar.

We’ve got four new add-ons on tap for you downloading pleasure, and more on the way. They’re all free, so check them out!

So we’ve been hard at work figuring out just what a Pixel & Tonic is made of. It’s been a true labor of love, and today, we’re excited to share our findings with you!

The big challenge was deciding what a “pixel” is, when referring to drinks.

Well, what is a pixel made up of? Red, Green, and Blue lights.

RGB.

So we set out to find three things, beginning with R, G, and B, that would go well together, along with tonic water, and look handsome when garnished with a lemon.

After some trial and error, we came up with Red Bull, Gin, and Bitters.

RGB.

Without further ado, here’s the official recipe. Enjoy!

Ingredients

• 2 parts Gin
• 1 part Red Bull
• 1 part Tonic Water
• a dash of Bitters

Mixing Instructions

Build over ice in a highball glass. Stir and garnish with a lemon wedge.

“We” means *we*

On Monday, May 3, Brad Bell joined Pixel & Tonic, officially making this a two-man operation. Brad and I worked at a web agency together a couple years ago, where we built a gaming portal for a well-known tech company. We’re not ready to talk about what he’s working on yet, suffice to say that we’re trying something new, and we think it’s going to be awesome.

New digs

It didn’t take long to realize that working from home isn’t for me. So shortly before Brad started, I signed a lease for an office in downtown Willow Glen, a vibrant little town in San Jose.

Here’s a pic of the office. Click to view a couple others on Flickr.

New storefront

On Wednesday, May 12, Devot:ee announced the opening of their Add-on Store. So the best place to discover EE add-ons is now the best place to buy them, too. To show our support, Matrix, Wygwam, and Playa were all available for sale from day one. So now you can buy your favorite P&T add-ons right alongside BucketList, CartThrob, Low Variables, and whatever else you need for your upcoming EE project, all with one purchase. Plus, 20% of your purchase will go to Devot:ee, so it’s a great way to show your support for the site.

Along with the Add-on Store, Devot:ee also dropped its “Devot:ed” paid memberships. Now, anyone can rate and review add-ons for free! *Cough*

So, a big congrats to Ryan and Jacob for their game-changing work!

New drink

This past week we’ve been hard at work defining just what a “Pixel & Tonic” is. Yesterday, we found it, and it’s delicious! Read about it here.

Workshop at EECI2010

I’ll be giving a workshop at EECI2010 in a little over a week. The subject will be ‘creating engaging experiences’. Here’s the synopsis:

User experience matters, whether you’re designing a website or developing an add-on. Will yours be engaging, downright annoying, or just plain forgettable? It’s up to you! Learn what works (and what doesn’t) from a connoisseur of interaction design in this two-hour workshop.

The conference is almost sold out. If you hurry, you can buy one of the view remaining tickets here. And for those who can’t come, they’re also making a DVD of the conference, which will only cost $99.

Thanks for tuning in!

Matrix 2 is a complete rewrite of what was formerly called FF Matrix. We’ve added some great new features along the way:

New UI

As if you didn’t see this coming :) Matrix 2 sports a new translucent skin that looks great on both ExpressionEngine 1 and all of the ExpressionEngine 2 themes.

File Celltype for ExpressionEngine 2

Thanks to EE2’s new File Manager, adding a File celltype to Matrix was too easy to pass up. Plus, we realize how essential file upload celltypes have become to many of Matrix’s uses.

New Column Settings

You can now give each of your columns their own instructions for authors, set their widths, and decide whether data entered into that column should be used as search keywords or not.

Its Own Database Table

Rather than jumbling all of your data into a giant serialized array and storing it in your exp_weblog_data table, Matrix 2 actually saves its data in a new exp_matrix_data table, which leads to better reliability and performance.

Free Upgrade

If you’ve already purchased an FF Matrix Site License, upgrading to Matrix 2 is completely free. And new licenses are just $55.

Hope you like it!

Here are the big new features:

EE2 Compatibility

Playa 3 works seamlessly in the ExpressionEngine 2 Public Beta, making it our second EE2 offering.

New UI

We’ve redesigned and reengineered Playa’s Drop Panes UI from the ground up, simplifying its appearance and making it a ton of fun to use!

Huge Performance Improvements

Performance was a major focus for this release. You can now use Playa on large-scale sites with thousands of entries without worrying about slow Control Panel load times.

Best part? If you already own a Playa site license, Playa 3 is a free upgrade! So what are you waiting for? Go grab a copy!

The three big winners are:

• Grand Prize: Marcus Neto
• Second Prize: Liam Crean
• Third Prize: Mason Kessinger

50 Playa, Wygwam, and FF Matrix licenses have also been shipped out – check your email to see if you’ve won!

So Congrats to all of the winners! And we look forward to seeing Marcus at EECI2010!

Finally, thanks again to EllisLab and EngineHosting for your generous contributions to the Giveaways!

November, 2008. Four months since I had moved out and taken a new job. And I was under the impression that my stint with ExpressionEngine was over. I had only developed a couple websites with EE at my previous job. One of them required I build Playa, and when the site was done I released it for free as a token of thanks for all of the other free add-ons people had released. I had no intention of actively supporting or maintaining it – especially since I wasn’t even using EE at the new job.

But then I joined Twitter. ExpressionEngine users followed me, and I followed them back. I started seeing mentions of Playa here and there, and realized that people were actually using it. But they weren’t all nice things – many were having issues. I wouldn’t stand for that, so I started releasing updates. And with that, finding a way to manage releases.

At first, I turned to LG Data Matrix. Each time I released an update, I’d create a new row in an LGDM field – saving only the Version and Release Date in text fields, and the Release Notes in a textarea. A separate MH File field held the latest file.

But I wanted the dates to be stored as actual timestamps – something I could reformat within my templates (for, say, a Changelog feed). And I wanted a checkbox cell to define which rows would show up on my add-on overview pages (in a “Recent Changes” section). So I hacked those cell-types into LG Data Matrix myself. (Later, Leevi was kind enough to include my changes in his 1.1 update.)

Working on LG Data Matrix got me thinking: How cool would it be if the add-on came with an API that made it easy for anyone to create cell-types? Wait… how awesome would it be if there were an API that made entire field-types easy to create? And, once that was established, I could clone LG Data Matrix with that API, and then it could load these field-types itself, so they’d double as cell-types!

A couple months later, FieldFrame and FF Matrix were born. And not long after that, nGen File Field.

Which brings us back to managing releases. With FF Matrix and nGen File, I could now store each individual release’s ZIP file right alongside the rest of its metadata:

Going Commercial

April, 2009. I released Playa 2, a notable update that brought the add-on far beyond its original scope. So I decided that it was time to start charging.

For payment processing, I did what I think most add-on developers have done to date: take the Simple Commerce module, and hack the hell out of it.

The two big changes were:

1. Don’t require a user to be logged-in to make a purchase. (I didn’t have any sort of member accounts, and wasn’t interested in dealing with that just so people could buy things.)
2. Upon completion of a purchase, generate a license key. Store it alongside the other purchase data in exp_simple_commerce_purchases, and make it an available variable for my Customer Email Template.

When a customer completed a purchase, they would receive their License email, which included a Download URL. The URL was essentially a script that searched the purchases table for the license key it was passed, and if a record was found, served up the latest File for the associated product.

Though the system worked (for the most part, anyway), I was never happy with it. I didn’t like how disconnected everything was – release metadata and files being stored in a Matrix field; purchases being handled by a separate, hacked module; and file downloading by its own one-off script. I like to keep things contained, and this was anything but.

Enter Juniper

Pixel & Tonic gave me a clean slate. I could do anything I wanted. So I spent some time identifying what I disliked about the old system, what type of features I’d like to see, and what would be the most straightforward solution for myself and my customers.

Here’s a summary of what I came up with:

• Since items for purchase are typically associated with entries, so their commerce setup should take place right within a tab on the publish page.
• This tab should hold two things: the item’s price, and release matrix. The release matrix should record the Version, Release Date, Release Notes, and File for each release.
• Since license generation is tied to purchases, the module should handle the commerce.
• Since file downloading is conditional upon either the item being free or the member having paid for it, the module should handle that as well.

Essentially, take each of the components of the old system, and combine them into one module that’s specifically tailored to my own needs (selling software).

The end result is Juniper. Here’s what the publish tab looks like:

For the Releases matrix, I took the opportunity to try a couple new things that might make their way into the next major release of FF Matrix. The most noticeable being that previously-saved content is initially presented in a non-editable state. If you do want to edit a cell, simply clicking on it will swap its static state with an editable field. Hitting the ESC key while that input has focus will revert the cell back. This drastically cuts down the visual clutter of the matrix, and also makes it easier to identify which cells have unsaved changes.

Templating with Juniper

I spent a lot of time on the templating end of the module, which helped me keep my site’s templates straightforward.

With the help of an additional field, for_sale, those Download / Buy Now buttons at the top of each of my add-on pages were as simple as:

{if for_sale == "y"}
    <a href="{exp:juniper:add_to_cart_url entry_id='{entry_id}' return='store/cart'}">Buy Now</a>
{if:else}
    <a href="{exp:juniper:download_url entry_id='{entry_id}'}">Download</a>
{/if}

{exp:juniper:add_to_cart_url} adds the item associated with the passed-in {entry_id} to the user’s cart (an array stored in the session), and optionally redirects the browser to a specified template. In this case, users are redirected to store/cart, whose template looks a bit like this:

{exp:juniper:cart_form checkout="store/checkout"}
    {if no_items}<p>Your cart is empty.</p>{/if}

    <table class="cart">
        <thead><tr>
            <th scope="col">Product</th>
            <th scope="col">Quantity</th>
            <th scope="col">Price</th>
            <th scope="col">Total</th>
        </tr></thead>
        <tbody>
            {items}
                <tr>
                    <th scope="col"><a href="{path={url_title}}">{title}</a></th>
                    <td><input type="text" name="quantity[{item_id}]" size="2" value="{quantity}" /></td>
                    <td>${price}</td>
                    <td>${total}</td>
                </tr>
            {/items}
            <tr>
                <td colspan="3"></td>
                <td><strong>Grand Total:</strong> ${grand_total}</td>
            </tr>
        </tbody>
    </table>

    <input class="button" type="submit" name="update" value="Update Cart" />
    <input class="button submit" type="submit" name="checkout" value="Checkout" />

{/exp:juniper:cart_form}

The {items} tag pair loops through each unique item in the user’s cart. Both Submit buttons will update the user’s cart with the new item quantities, and then either reload the current template, or redirect to the template specified in {exp:juniper:cart_form}’s checkout= parameter, depending on which Submit button the user pressed.

The other two Juniper-related templates, store/checkout and members/index, look much like you’d expect, so we’ll skip those.

Much to be done

I launched with many of Juniper’s to-do list items unchecked, and have been adding them as I have time. This past week has seen the addition of PayPal integration, some fancy charts behind the scenes, and even public module actions for generating a LG Addon Updater version.xml file and NSM Addon Updater releases.rss files. Purchase management isn’t quite finished yet, which is why I’m running a little late on those Launch Giveaways, and there are quite a few other nice-to-have’s in the pipeline.

But I couldn’t be happier with what I accomplished in this module, especially considering all of the other things I’ve been juggling these last couple months. I feel very confident about Juniper as my new release management/purchasing/downloading platform, and the initial reaction to its checkout experience has been quite positive.

Release

It’s very likely that Juniper will be released in some fashion this year. Given that it’s a very targeted product, how I go about it – the price, the availability, the support model, etc. – are still up in the air. But it’s no secret that I think more EE add-on developers should start charging for their work, and I’m happy to help make that a reality. If it’s something you’re interested in, let me know in the comments.

This concludes Making P&T, our series on the design and development of what is now Pixel & Tonic. If you have any other subjects you’d like to hear about on Blog & Tonic, feel free to share in the comments. But for now, we’re going to get back to doing what we do best: developing add-ons.

When I decided to migrate my FieldFrame documentation from the GitHub wiki to brandon-kelly.com, I was spoiled by a variety of approaches to choose from. I could have simply created a “FieldFrame Docs” weblog, and created a contents tree with your standard {exp:weblog:entries} tag, or done something a bit more interesting using Structure.

But as I’m always looking to bend my own products in strange new ways, what I came up with was quite absurd.

I started by creating that FieldFrame Docs weblog and giving each page its own entry. For the contents tree, I made a new FF Matrix field within my EE Add-ons field group, and gave it two cells: Page (a Playa select related to the Docs weblog), and Alternate Heading (a text field). I wanted to be able to organize my pages into groups, so a row with an Alt Heading set would appear as a heading, and the others would be linked titles. I also created a new FF Matrix celltype, “FFM Hierarchy”, and used that to establish a hierarchy within the tree.

It might look decent, but in practice it’s been a pain in the ass to maintain. Every time I wanted to add a new page, I’d first create the new page’s entry, then go to FieldFrame’s entry, add a new row to the Docs matrix and relate it to the page. If that page was to be placed anywhere but at the end, the hierarchy would tend to get screwed up, and require readjustment. Oh, and when I gave Playa its own Docs section, I had to relate the Playa cell to its weblog as well as FieldFrame Docs, so if I wasn’t careful I could accidentally relate FieldFrame to a Playa Docs page, and vise-versa.

But the worst part was the templates. There was the site/_docs template (routed from site/index and site/_apps), which displayed the current page’s contents:

{exp:weblog:entries dynamic="off" weblog="docs_{segment_1}"
       url_title="{segment_3}{if segment_3 == ''}docs_{segment_1}{/if}"
       limit="1" ... }

{embed="site/_docs_tree" url_title="{url_title}" title="{title}"}
   <div class="col first wide body">
       {exp:textile}{docs_body}{/exp:textile}
   </div>
{/exp:weblog:entries}

And the subsequently-embedded site/_docs_tree was responsible for building the actual contents tree, as well as embedding the site header and footer:

{exp:weblog:entries dynamic="off" weblog="ee" url_title="{segment_1}"
       limit="1" ... }

{embed="site/_header" ... }

<ul class="subnav"> ... </ul>

<h1>{embed:title}</h1>

<div class="col last callout">
   <h3>{title} Documentation</h3>

   <ul>
       {docs_tree}
           <li>
               {if page}
                   {page}<a{if url_title == "{embed:url_title}"} class="active"{/if} href="/{segment_1}/{segment_2}{if url_title != weblog_short_name}/{url_title}{/if}">
                       {title}
                   </a>{/page}
               {if:else}
                   <h4>{heading}</h4>
               {/if}
               {if subpages}
                   <ul>
                       {subpages}
                   </ul>
               {/if}
           </li>
       {/docs_tree}
   </ul>
</div>

{/exp:weblog:entries}

It was a mess.

The Docs Module

Thankfully I decided to use EE2 on pixelandtonic.com, where such an abomination isn’t yet possible, while I wait for… myself… to port FF Matrix over. So this time around, I took the cleanest possible approach: I wrote a new module!

Thanks to EE2’s new module tab API, each of my EE Add-on entries have their own “Docs” tab on the publish page, where I can manage all documentation for that entry, including the hierarchy:

And since my module’s tag pair doesn’t conflict with {exp:weblog:entries}, I can now fit the entire Docs page in a single primary template, ee/docs:

{exp:channel:entries channel="ee" url_title="{segment_3}" ...}
<em>{exp:docs:page entry_id="{entry_id}" url_title="{segment_4}"}</em>
{embed="site/-header" title="{title} - Docs - {docs_page_title}" ...}
{embed="ee/-header" title="{title}" ...}

<div class="content">
    <div class="grid23 clearafter">
        <div class="left">
            {if segment_4}<h1>{docs_page_title}</h1>{/if}
            <em>{docs_page_contents}</em>
        </div>
        <nav class="right">
            <em>{exp:docs:tree entry_id="{entry_id}" base_url="{site_url}{url_title}/docs" selected="{docs_page_url_title}"}</em>
        </nav>
    </div>
</div>

{embed="site/-footer"}
<strong>{/exp:docs:page}</strong>
{/exp:channel:entries}

In its current state, the module is pretty simple – pages are stored in their own table, and are only given the four fields shown above (Parent, Title, URL Title, and Contents). Page order is defined by drag-n-dropping the pages within the contents tree on the right. The module has two tags, one for outputting the entire tree in an unordered list (not currently customizable), and one for outputting a single page’s contents.

It’s a good starting point, but there are areas for improvement. Once I’m done porting Playa and Matrix to EE2, I’d like to go back and add HTML archive exporting (for on-the-fly downloadable docs) and maybe even release branching.

Release?

Whether or not I release Docs publicly is up in the air. I’ll do it if there’s sufficient demand; otherwise it’ll remain private. So if you think you could use this, sound off in the comments! Include your use case for extra P&T Points (worth about 1/2 a Schrute Buck in today’s economy).

And that’s it for today; thanks for tuning in! This series will continue tomorrow with a look into how I’m managing releases and processing payments, so make sure you’re following @pixelandtonic or subscribed to our RSS feed to be notified about that.

One of the great, horrifying things about ExpressionEngine is that your website’s structure is completely up to you. EE makes no assumptions whatsoever, which makes it a fantastic tool for everything from simple blogs to full-blown portals like iLounge. And the best part is that, should you decide to scale your website into something bigger, you can do it without starting from scratch. Your content is already sitting in non-assuming weblogs / channels / sections / buckets, ready to be presented in any variety of new ways.

This was essentially the story with my previous site. It began as a simple Movable Type-based blog, whose content was a mix of blog posts, portfolio entries, and a couple downloadable goods. Once I started releasing ExpressionEngine add-ons, I attempted to restructure things a bit by applying categories to entries. But it didn’t take long before the site started showing its seams, so in December of 2008 I decided to do the right thing, and migrate to EE.

The migration was simple enough – I used the Movable Type Import Utility to get the content into EE, and then I distributed my entries into separate weblogs: Sites, EE Add-ons, Mint Pepper, Mac Apps, and Posts. I came up with a basic design that only consisted of a homepage and a single entry page, and called it a day. Since then, I’ve revamped the homepage to focus solely on EE add-ons (only giving other content a small home in the global footer), revamped the blog, introduced documentation sections for FieldFrame and Playa, created the Playa in Action page and Fieldtype Showcase, and made a few other iterative enhancements.

URL Routing

While that site is a testament to ExpressionEngine’s malleability, I’ve never been very happy with its structural implementation. A prime example of that is how I’m handling URL routing. I wanted all product URLs to begin at the first URL segment, e.g., http://brandon-kelly.com/playa, rather than http://brandon-kelly.com/ee/playa. I accomplished that using segment conditionals:

{if segment_1 == ""}
   {embed="site/_home"}
{if:else}
   {embed="site/_apps"}
{/if}

In this case, if the site/index template gets called (and thus, the request hasn’t already been routed to an existing template group, like “blog”), I’m assuming that either the homepage or a product of some sort should be displayed.

While this approach works, it’s not ideal, since things like template caching go out the window, not to mention the performance hit from loading and parsing an additional template. So when I set out to make pixelandtonic.com, I decided to try something new.

I started with a simple and straightforward template structure. The “site” group is for the homepage and globally-embedded templates, like the site header and footer. Then there’s an “ee” group for ExpressionEngine add-ons, which includes the templates “index”, “releasenotes”, and “docs”. The ee/index template checks {segment_2} for the add-on’s URL Title, and the other two check {segment_3}.

When you visit an EE add-on’s section on pixelandtonic.com, the first step in URL routing takes place not in a template, but in the site’s .htaccess file:

RewriteRule ^index.php/(playa|wygwam|fieldframe|ffmatrix)(/[^\/]+)?(/.+)?$ /index.php/ee$2/$1/$3 [NC,L]

This little redirect (coupled with a standard index.php redirect) will take an incoming URI like /playa, and turn it into /index.php/ee/playa behind the scenes. Sub-pages like /playa/releasenotes become /index.php/ee/releasenotes/playa. Now, the first template EE loads is also the last (well, besides the site header and footer embeds). No template segment conditionals required!

My only caveat is that it will require manually adding new URL Titles to the regular expression as I introduce new products, but that’s certainly an acceptable tradeoff.

Trailing Slashes

While on the subject of .htaccess redirects, there’s another little tidbit probably worth sharing: how I’m handling trailing slashes in the URI. While EE doesn’t know the difference between URIs like /playa versus /playa/, web analytics apps and search engines may consider these separate web pages. If you’re developing a static website, this isn’t a big deal, because if you attempt to go to the former URI (sans trailing slash), Apache will automatically redirect the client to the latter (with trailing slash).

But for a web application like EE, where everything in the URI after “index.php” is handled by the application rather than Apache, this redirection is left up to you. Just like the decision to use or not use a “www” subdomain, it doesn’t matter whether you choose to force a trailing slash or vise-versa; it just matters that you force one or the other.

I decided to force URIs without trailing slashes, if only because they look a little cleaner, and in this 140-char world, every character counts. Here’s the rewrite rule I’m using to do it:

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 [R=301,L]

If you decide to force URIs with trailing slashes instead, simply change that last line to:

RewriteRule ^(.+[^/])$ /$1/ [R=301,L]

For this redirect to be applied, it must first pass a couple conditions that make sure that this isn’t a POST request, and the URI does not map to an existing file or directory. (They’re the same conditions I’m using for index.php redirection.) The rule must be placed before your index.php rule, since by that point, your request has already been redirected to an existing file (index.php).

SSL

Being that I’m handling payments now, SSL was crucial. But I only wanted it on certain pages (anything in members/, and store/checkout). So after getting my SSL certificate up and running, I set a new redirect in place to force SSL on these pages:

RewriteCond %{ENV:SECURE_REDIRECT} !=on
RewriteRule ^(members|store/checkout) https://%{HTTP_HOST}%{REQUEST_URI} [NC,R=301,L]

Note that %{ENV:SECURE_REDIRECT} is a custom environment variable set by EngineHosting. Due to the way their servers are set up, the normal %{HTTPS} variable doesn’t reflect the actual SSL status of the request. If you’re not on EngineHosting, use %{HTTPS} instead.

Then there was the problem of forcing forms living on SSL pages to also post to SSL pages. (Since most forms on P&T are generated from EE modules which just use the Site URL as the form action’s prefix, this wasn’t as simple as remembering to type “https://”.) For that I wrote a simple plugin that converts all instances of “http://” into “https://”:

function https()
{
	$tagdata = $this->EE->TMPL->tagdata;
	return str_replace('http://', 'https://', $tagdata);
}

Wrapping module form tags with {exp:pt:https} and {/exp:pt:https} then did the trick.

So that covers the initial HTML response, but not the in-page elements (CSS, JS, images). And unfortunately, some browsers make a big fuss when HTML is transferred over SSL, but not the in-page elements.

To force all elements to load over the same protocol the HTML was being sent in, I opened up index.php, and added a couple new global variables:

$assign_to_config['site_url'] = 'http://'.$_SERVER['HTTP_HOST'].'/';
$assign_to_config['global_vars']['site_ssl_url'] = str_replace('http://', 'https://', $assign_to_config['site_url']);
$assign_to_config['global_vars']['site_proto_url'] = ($_SERVER['HTTPS'] == 'on' ? $assign_to_config['global_vars']['site_ssl_url'] : $assign_to_config['site_url']);

Now, {site_url} is being defined right in index.php, {site_ssl_url} will always be the same as {site_url} except with an https:// prefix, and {site_proto_url} is either set to the {site_url} or {site_ssl_url}, depending on whether or not the current request is coming over SSL.

From there, it was just a matter of plugging these new tags in where appropriate. Links to members/* (which would be redirected to https:// anyway) are now created using {site_ssl_url}:

<li><a id="sitenav-signin" href="{site_ssl_url}members/signin">Sign In</a></li>
<li><a id="sitenav-register" href="{site_ssl_url}members/register">Register</a></li>

And page resources are pulled in using {site_proto_url}:

<link rel="stylesheet" type="text/css" href="{site_proto_url}global/styles/pt.css" />

The end result is that pages which don’t require SSL don’t get SSL; links going to pages that should be served with SSL have appropriate href attributes; pages that should be on SSL are forced to be served over SSL as well as their resources, and forms living on those pages will submit over SSL. All bases covered.

And that’s it for today; thanks for tuning in! This series will continue tomorrow with a look into how I’m handling product documentation, so make sure you’re following @pixelandtonic or subscribed to our RSS feed to be notified about that.

The Name

Several people have asked me how I came up with the name. I’d love to tell you that it just came to me – that it’s a way of saying “We work hard and we play hard” or some BS.

Truth is, it’s the result of spending days on GoDaddy, hunting for that one halfway-decent, available domain name. At one point I almost settled on “EngineApparel”, but the initial reaction from a few friends was less than validating. Finally the idea of “something-and-tonic” came to me while driving to work one morning. PixelAndTonic.com was my first choice, and when it turned out to be available, I swear I could hear angels singing.

The Logo

I got in touch with Rob Morris, the mastermind behind those Playa 2 ads, pleading for help with the logo. And despite my jumbled, self-contradicting attempt to describe what I wanted, I think we can all agree that what he gave me is perfect:

The Design

The only problem with a great logo is designing a site that does it justice. And unfortunately, Rob didn’t have the bandwidth. I got in touch with one of my favorite agencies, who were happy to help, but unfortunately it became apparent that my timeline and their availability weren’t matching up. So I decided to give it a go myself.

I started with an add-on overview page, since the lot of those tend to get the most traffic. My first take ended up looking pretty decent:

But then I moved onto the homepage, where I found this design to be stubbornly immalleable. I couldn’t for the life of me find a way to mold it for another layout. So I decided to pull the plug on it, and start over.

This time, I started by listing out the types of elements needed on a few different types of pages: the homepage, an add-on overview page, an add-on documentation page, etc. I then made a few rough sketches of those pages, and got to work on the homepage. A few false starts later, I came up with something not far off from the final design:

My goal for the homepage was simple: to get the message across that although Pixel & Tonic may be new, the guy behind it, and the add-ons, are not. Originally I was planning on accomplishing that by including a blurb about myself on the homepage, leveraging my own name’s recognition and reputation. But amidst the design process I realized that it would be far more effective to instead feature a few notable quotes from respected people in the community, and list a bunch of recognizable logos of agencies who are using my add-ons. I think the end result gets the job done very well.

Against all odds, I’m happy to say that I’m indeed proud with the design of this site. Although I do love designing interfaces, designing a full website from scratch – that big, empty canvas – scares the hell out of me. I’m glad I faced my fear, but I’m not exactly about to go looking for more web design gigs anytime soon.

HTML5, CSS3, IE Zero

This is the first time I’ve gone all-out with HTML5 on a website. Not talking about those arrogant frontmen <video> and <audio>, but rather <header>, <footer>, <section>, <nav>, <hgroup>, <article>, <figure>, and <aside> – the real musicians.

Overall it’s been nice, mainly because it makes the markup that much easier to follow while working on it. There’s less thought involved in reading and comprehending a </article> than something like </div><!--/.article-->. If you’re thinking about seeing what all the fuss is about for yourself, HTML5 Doctor’s Glossary proved an invaluable resource for discovering the new toys, and learning how to use them the way God intended.

There’s also a healthy mix of CSS3 on the site, mainly in the form of border radii, box shadows (outer and inset, for those of you that take the FF 3-6 to work), and background gradients. There’s even a CSS mask on the homepage, creating that fade-out effect when an add-on hero image nears the edges of the container (Chrome 5 and Webkit nightlies only).

So what about IE? Well, thanks to the fact that I’m targeting other web developers, I can say with 97.3% certainty that you’re not using it. Which is awesome, because that gave me a practical reason not to worry about it (besides just not caring). I did scope out the damages a couple days before launching, and it wasn’t pretty. Not even remotely usable. I’ll probably deal with that in some form eventually, but it’s most certainly not going to be full support.

That’s it for today; thanks for tuning in! This series will continue tomorrow with a look into how the site is structured, so make sure you’re following @pixelandtonic or subscribed to our RSS feed to be notified about that.

So one week from today (March 2), we’ll be handing out over $5,000-worth in prizes!

 To enter, all you have to do is join our Mailing List. Just enter your email address to the little form found at the bottom of every page. 

So what are these prizes, exactly? Here’s the breakdown:

Grand Prize

• EECI2010 SF Full Conference Ticket ($525 value)
• ExpressionEngine 2 Commercial license ($299.95 value)
• 12-month EngineHosting S-2 package ($240 value)
• Playa license ($75 value)
• Wygwam license ($35 value)
• FF Matrix license ($35 value)

Second Prize

• ExpressionEngine 2 Non-Commercial license ($149.95 value)
• 12-month EngineHosting S-2 package
• Playa license
• Wygwam license
• FF Matrix license

Third Prize

• ExpressionEngine 2 Freelancer license ($99.95 value)
• 12-month EngineHosting S-2 package
• Wygwam license
• FF Matrix license

50 More Lucky Winners

• 20 Wygwam licenses
• 20 FF Matrix licenses
• 10 Playa licenses

Many thanks to EllisLab for donating the EE2 licenses, and EngineHosting for donating the hosting packages!

Initially the development of the two went hand-in-hand, so it made sense to continue packaging them together, even if it meant dealing with their colliding perceptions. But now that EE2 includes an API that roughly mimics FieldFrame’s, and the two products have begun taking lifecycles of their own, the time has come for them to part ways.

While FieldFrame remains free, FF Matrix now costs $35. That will fund its continued support and development as I work on version 2, which will be a free upgrade when released.

We’ve packed several big new features into this release:

EE2 Compatibility

That’s right! Wygwam 2 is officially our first EE2-compatible add-on. And we’re using EE2’s new fieldtype API, so FieldFrame isn’t required. Granted, FF Matrix is not yet available for EE2, so that feature isn’t either. But beyond that, the EE1 and EE2 versions stack up feature-for-feature.

A New Look

We went back to the drawing board for Wygwam’s custom CKEditor skin, and came up with something that does a better job of blending into your ExpressionEngine control panel, allowing you to focus on That Which Matters Most – your content.

Easy Conversions

Already have a weblog full of entries? We’ve implemented XHTML, Auto <br>, and Textile conversion, so text fields that began their life with something less than full-blown HTML content can be easily changed to Wygwam fields without manually updating all previously-saved content.

Streamlined Field Settings

Wygwam 1.0 raised the bar for text field settings. It provided a simple interface for creating custom toolbar configurations - a process that traditionally can be somewhat tedious, even to developers.

Now with Wygwam 2, we’ve provided an interface for virtually all of CKEditor’s config settings. That means you no longer have to bother fiddling with CKEditor’s config.js file to further customize your editing experience.

Good to Your Wallet

So what does all of this cost? Well, if you’ve already purchased a license for Wygwam 1.x, Wygwam 2 is a free upgrade! Consider it a big thank you for giving Wygwam a chance, even though so many free alternatives are available. We hope you’ve found it to be worth the cost of admission. And if you’re purchasing a new license, it’ll cost just $35.

Buy Wygwam now!

P&T is the embodiment of my decision to go solo. It’s the platform for my future internet endeavors. And its office looks awfully similar to my bedroom.

So: why? I had a pretty good thing going with the Brandon Kelly brand after all.

But it had reached its limits on a couple fronts.

One is simple: I want to expand. Not just in that I want to do this full time. I mean grow the business. Employ other people, and find new ways to better service the EE/web communities. This would have been awkward to do under my own name.

The other is not so obvious, but important nonetheless: I believe my add-on sales suffered to a degree by an inherent lack of confidence in their future support and development. Because, who’s to say I won’t decide to abandon EE in favor of iPad development a year from now? Or, God forbid, I’m involved in some tragic event? Fact is, people are unreliable. And Brandon Kelly is a person (so far as you know).

Creating this company is my way of saying that you needn’t worry. These add-ons are here to stay. Sure I’m still just one guy, but that’s going to change soon. (In anticipation, you’ll notice we’re already practicing talking as a plural entity.)

So it’s all about scaling up. I want to see how far I can run – and how big I can make this.

The launch is composed of a few parts:

1. This website – I’ve moved my most popular add-ons over to this new domain. That includes their marketing copy, purchase processes, release notes, and documentation. I’ve also introduced member accounts, where you can keep track of all your licenses.
2. Blog & Tonic – Going forward, all P&T-related announcements and other tidbits will be posted here.
3. @pixelandtonic – The official P&T Twitter account.
4. Wygwam 2 – We managed to pack even more features into our premiere text editor for ExpressionEngine, not the least of which is EE2 compatibility!
5. FF Matrix Going It Alone – It’s time.
6. Making P&T – A series of blog posts that will show off some of the inner-workings of this site, starting tomorrow.
7. Launch Giveaways – We’ve got a few things to give away in celebration of the launch. Subscribe to our mailing list for a chance to win something!
8. Minor updates to FF Matrix, Playa, and FieldFrame.

Been busy. But color me optimistic – the future is very bright!

Thank You!

Pixel & Tonic simply wouldn’t have been possible if not for your humbling loyalty and support over the last couple years. So give yourself a big pat on the back – you’ve earned it!

Last October, I had the pleasure of attending (and speaking at) EECI2009 in Leiden, Netherlands. Every aspect of the conference was top-notch. So when EECI2010 was announced (and that it would be in my own backyard, no less), I didn’t think twice about throwing some money at it.

If last year’s success is any indication, this conference is going to be magical. Don’t miss it!