Anyone who has watched the preview videos or checked out the 3.0 betas will know that a lot has changed in this new code base. There’s a ton of new functionality for both free and PRO users alike. We have invested some serious ducats into making this next generation a product we are proud of. We believe the new features, and our commitment to support is a good value for the price you’re paying. We’re committed to developing, and enhancing the Events Calendar suite of products for the long haul, and that means our we need to be around to do so.

The new pricing structure includes a 20% increase, and is as follows:

• Personal licenses will cost $60 for Events Calendar PRO, Community Events, WooTickets, Eventbrite Tickets & the forthcoming soon-to-be-named Filters plugin, and $25 for Facebook Events.
• Business licenses will cost $120 for Events Calendar PRO, Community Events, WooTickets, Eventbrite Tickets & the forthcoming soon-to-be-named Filters plugin, and $40 for Facebook Events.
• Developer licenses will cost $300 for Events Calendar PRO, Community Events, WooTickets, Eventbrite Tickets & the forthcoming soon-to-be-named Filters plugin, and $70 for Facebook Events.

Do you have more questions about why we’re raising prices? We’re pretty open about how we do things around here. Feel free to reach out.  We’d love to hear your feedback.

In our talk this morning, Jessica walked through the changes she’s made and what you can expect from them. This is the first under-the-hood preview we’ve given so far and it should shed some light on what you can expect. Check out the video (less than 5 minutes long!) after the jump.

Pretty cool, right? Let’s review, using list view as our example to keep continuity with the video…

What’s changing and how the file is broken up

In the old list view, everything was in one file. It started with a wrapper, led into the header and the loop from there. The event single item was a big chunk of code within the list and repeated for every item in the event list; it would generate the same HTML for every event in the list. Underneath, it had the next/previous navigation and the iCal link. The big takeaway here should be that everything was all in one file.

In the 3.0 release, list view is still in the same location: plugin folder –> views –> list.php. But if you go into events –> views, you’ll see a list.php (the file that gets included first for list view — essentially the parent view file). Inside it, little pieces are called to handle each part of the view: for example, a template part for the tribe bar. We’ve included a new function: tribe_get_template_part. That is really similar to WordPress’ get_template_part function, and it looks in all the correct locations for tri.be templates. You’ll see includes like (‘modules/bar’), etc. The loop is also now in a separate file.

As an example: if you just wanted to add a div that wraps around the whole list, your approach will change in 3.0. Previously you would have been forced to copy the entire list file and make your changes there. But now you can merely copy this new file and leave the loop content alone, as it’s now included separately.

How to do an override

Overrides, then, have changed as well. You only have to override the piece you want to change — not the whole thing. Let’s say we want to override the list view so the next/previous links that appear before the loop were gone. To do this an override in the 3.0 codebase you’ll follow these steps:

1. Create a new “tribe-events” folder in your theme directory.
2. In that “tribe-events” folder, make a new folder called “list”.
3. Inside the “list” folder, make a file called “nav.php”.
4. Copy the contents of “nav.php” from the original “views” folder to your new file of the same name. (Note that we’re not copying the whole list.php file, as was the case previously).
5. Delete the nav-centric code from this file and replace it with something simple; for example, a basic line of text saying “There is no nav.”
6. Save the file, and refresh the frontend. Your navigation links will be replaced by that text we added.

Note that the rest of the template is untouched, and still pulling from the original plugin files. So when updates are released people will not need to update the entire list.php; they can keep using the version we’ve released and if they made modifications to the nav or any other small overrides, that’s all they’ll have to be responsible for maintaining.

One last point to keep in mind: in the old version, there was a lot of logic in the templates. This could be confusing for themers or other laymen, and made it a bit tough to scan as well. But for 3.0 we’ve moved a lot of that logic to template tags. So all you’ll have to do is throw out one template tag that does all this logic for you. Ultimately this means the templates themselves are also cleaner/simpler.

If you’re curious about anything else related to the templating structure, or if this raised questions in your mind that need an answer, let us know in the comments below.

You’ve probably seen Shane’s blog post from the end of April containing the PollDaddy survey. (If you haven’t replied yet, what better time than now?). But we’ve also got a batch of conversations scheduled next week in place of May’s usability test, which should help paint an even better picture.

Earlier this week I sent an email to three distinct groups of users:

• The last 100 people to purchase a plugin
• 100 users whose licenses expired over the past couple months who have not renewed
• 50 or so users who have bought 4 or more licenses

The goal was simple: we wanted to schedule about a dozen 20-minute sessions throughout the morning of May 17, talking to a cross-section of these three groups to see what we could find out. This wasn’t intended a science experiment or a case study; it’s a casual conversation. But even pitching it as such  – and with the offer of a free license/upgrade to sweeten the deal — we wondered how much response we’d get. Our estimate was maybe 5% but not much higher than that.

Surprisingly, we got one hell of a response. All 12 of the slots were booked within far less than 24 hours, and I’m still four days later turning away people who are replying with interest. Even more surprising, we had just as many expired users reply as we did recent buyers.

We’re excited about what this means for the quality of our conversations next week, and even more excited about where the results of these conversations will take us. We’re going to let the flow naturally but do have a script we’ll stick to if things go off course, which includes questions like:

• What role does events play in the stuff you’re working on?
• What do you look at when deciding on a calendar?
• Do you pick this for your clients? Or do the clients pick it with you?
• Do you crack the hood? What are your expectations when doing so? How do you use documentation? Did you? What were you expecting to see that you didn’t?
• How did we make you more profitable? Did we? Is there other stuff we could build that you could sell? Are there features you’d pay extra for?
• How much do you care about features/aesthetics vs core quality?
• What frustrates you on a daily basis? Developers, is there anything we could have done to make your job easier?

If you were one of the folks who volunteered your time — even if you were turned away because the slots were booked — we thank you.

Any other companies out there tried these types of sessions? If so, was it worth your while in the long term? This is our first attempt and we’re in many ways making it up as we go along. Would definitely be interested in hearing feedback in the comments from others who’ve done the same.

I. Week View (April 1, 2013)

II. Map View (April 2, 2013)

III. Photo View (April 4, 2013)

IV. List, Calendar & Day Views (April 8, 2013)

V. Updated “General” Settings tab (April 11, 2013)

Part I

Part II

VI. Other Settings tabs (April 15, 2013)

Part I

Part II

VII. The “Filters” Panel add-on (April 16, 2013)

If there are any features or pages you’d like to see demoed, please let me know via email or in the comments below. I’ll continue adding to this list as we continue to publish previews between now and the 3.0 launch. Thanks for watching!

The code will be finished. Features will be all in place and any bugs that we’re hitting for 3.0 will already be addressed. This will truly be the last act before we release finished products to the masses, and we’d love for YOU to be involved. While we probably won’t get 1000 translations, the more we can secure for launch, the more countries we’ll be able to serve with this new batch of releases.

We’re also offering a free developer license to whoever provides us with the most obscure translation! We reserve the right to make final judgment on what defines “obscure,” but if you send us something we’ve never seen before or a language not widely used, you’ll definitely be entered into this contest.

Please let us know if you’d be interested in providing translations for any of the following products. Languages that have already been spoken for are listed below each plugin, but you’re welcome to volunteer as a backup in case our primary contact bails.

• The Events Calendar 3.0 / Events Calendar PRO 3.0 (must be done together)
  • German (de_DE) from Thomas Lipp
  • Swedish (sv_SE) from Ben Andersen
  • Dutch (nl_NL) from Nico
  • Danish (da_DK) from Martin Hover
  • Brazilian Portuguese (pt_BR) from Diego Meneghetti
  • European Portuguese (pt_PT) from Antonio Pratas
  • Norwegian (nb_NO) from Eyolf Steffensen
  • Italian (it_IT) from Piercarlo Romeo
  • Czech (cs_CZ) from Martin Kristan
  • Spanish (es_ES) from Rene Ramos Avendaño
  • French (fr_FR) from Frederic-xavier Dubois
  • Polish (pl_PL) from Marek Kosina
  • Greek (el) from Panos Efstratiou
  • Arabic (ar) from Mamdouh Samy
  • Catalan (ca) from Barbara Partegas
  • Romanian (r0_RO) from Arian
  • Turkish (tr) from Evren Ugurbas
  • Hebrew (he_IL) from Dan Stramer
  • Bosnian (bs_BA) from Marko Manojlović
  • Croatian (hr) from Marko Manojlović
  • Serbian (sr_RS) from Marko Manojlović
  • Ukrainian (uk) from Alexey Fedorov
  • Persian (fa_IR) from Ardi Madadi
  • Japanese (ja) from Toru Miki
  • Albanian (sq) from Martin Lerch
• Community Events 1.0.6
  • Sri Lankan Tamil (ta_LK) from Andrew Jebaraj
  • Sri Lankan Sinhala (si_LK) from Andrew Jebaraj
  • German (de_DE) from Jan
  • Portuguese (pt_PT) from Luiza Libardi
    
  • French (fr_FR) from Jeremie Leroy
• Eventbrite Tickets 1.0.6
  • German (de_DE) from Jan
• WooTickets 2.0
  • Danish (da_DK) from Tue Jensen
  • Turkish (tr) from Ardi Madadi
  • Persian (fa_IR) from Ardi Madadi
  • German (de_DE) from Jan
• Facebook Events 1.0.6
  • Swedish (sv_SE) from Anders Eriksson
  • German (de_DE) from Jan
• Filters Panel 1.0
  • German (de_DE) from Jan
  • French (fr_FR) from Jeremie Leroy

Remember that we’ll grant you a free license for the plugin you translated in exchange for completed .po/.mo files. If you want to translate multiple plugins, you’re welcome to claim multiple licenses. We’ve got a few volunteers lined up already so if you’ve already emailed, no need to do so again. But if you haven’t yet reached out and would be interested in doing so, please shoot us a note no later than May 17.

Like Thomas Kinkade and Pablo Picasso before him, success in art is defined by crafting an approach that best connects with your patrons. The most beautiful thing about art, though? When you start with a blank slate, you can take it in any direction you want. And the same goes for support.

He managed to reference Thomas Kinkade. How can you not love that?

Check it out: Customer Service as Art

If you happen to be having a good day and want to share your story, we’d super duper appreciate it. We’ll also be giving away a free license to a randomly chosen reply.

The focus of the test has also changed a bit. While it was previously planned as half theming/half renewals & upgrades, we’re instead using all the sessions on the 25th to focus on renewals & upgrades exclusively.

While we (for obvious reasons) cannot give you the upgrade itself for free, anyone who participates will be offered a free personal license for any add-on of their choosing. Each slot will be 45 minutes and the sessions are set to run as follows:

• 9-9:45 am PT
• 10-10:45 am PT
• 11-11:45 am PT
• 12-12:45 pm PT

Let us know if you’re interested, and if so which slot would be best for your schedule.

The filters panel, as you’ll see over the next 9 minutes, allows additional filtering options beyond what’s available in the events bar. Your frontend users will be able to narrow down by venue, organizer, category and a whole slew of other options using a sidebar panel that matches the design of the overall calendar. Live AJAX filtering means those changes take effect immediately when the selection is made.

Check out the video — where we review both the frontend experience and backend filter-centric settings — after the jump.

Let’s recap. In terms of filtering options available to site admins right off the bat, you’ve got:

• Event Category
• Cost ($)
• Tags
• Venues
• Organizers
• Day
• Time
• Distance

Those, coupled with the options in the event bar (which do interact with the filters panel) should give your users plenty of options. As users enable a given filter, those will take effect on the frontend immediately — assuming the live AJAX is enabled. If it isn’t, they’ll be prompted to hit a “Submit” button…which certainly isn’t the end of the world.

A few things you should keep in mind:

• Organizers and venues list your 5 most-used of each. This means that as you use certain venues/organizers with increased or decreased frequency, that change will be reflected on the frontend panel immediately.
• The distance filter will not appear — even if it’s been enabled — until a geographic location has been entered into the “Location” field in the events bar.
• Filtering selections also modify the URL, which means you can pre-define filters before you send someone a link to the site. Have a friend coming to town who only likes live music? Filter to just show the live music category, on the days of the week she’ll be in town, then send her the link for perusal. She won’t have to apply those filters since your auto-generated URL took care of that.

Don’t want a given filtering choice available on the frontend? Want them appearing in a different order, with labels that you’ve personally added? Both are easily configured under Events –> Settings — > Filters. You can also change the category dropdown from a multiselect to a dropdown (or vice versa) on this page.

We’re really excited to get this plugin out there. As I mentioned in the video, it should ship alongside the 3.0 release and WILL be a separate add-on. If you haven’t checked the 3.0 preview page yet, what better time than now?

Today, we’re continuing down that path and reviewing the remaining settings tabs: specifically, “Display,” “Default Content” and “Additional Fields”. I’d aimed to make this into one, 5 minute video…but no matter how fast I spoke that didn’t work. So this preview — available after the jump — is actually a two-parter.

Part 1

Part 2

So, what’d we learn? To recap…

“Display” impacts all-things related to the frontend template you’ve selected. This is where you’ll decide the stylesheet settings you want to use — anywhere from a basic skeleton stylesheet (which would require you to add your own styles for it to look good) to our Tribe Events styles, which are designed and styled enough that they could probably work for most sites directly out-of-the box. You can also select your page template here, using either of the options pre-bundled with the plugin or those associated with your theme, and can enable/disable frontend views available to your users. Lastly, you can set a default events view here (what your users see when they visit /events on the frontend) and can add HTML before/after the calendar itself.

“Default Content” is a site administrator’s way of pre-populating the venue and organizer fields for anyone who creates a new event. The options you select here will appear already selected in the dropdown for anyone who goes to create an event; they can change it to another existing venue/organizer or add their own, if they want to. You can also set content here that will automatically populate any new Venue created under Events –> Venues on the backend. If you use the same venue/organizer/location a lot, this could save you or the people entering your events a lot of time.

“Additional Fields” are custom event attributes that appear alongside the rest of your prominent event metadata — date, time, venue, organizer — above the description on the frontend. Got a weekly event that uses a different DJ each week? Add a “DJ” field and write the fellow’s name so your users can decide if this is the show for them. Whatever attributes you make available will be accessible by anyone creating an event; if you don’t want them used, you’ll need to Remove them entirely. It’s worth noting these additional fields existed in 2.x and are being carried over to 3.0 with one major change: we’ve added a URL field as well, so you don’t have to add HTML to include links now.

“Licenses” and “Help” are more administrative than anything. Enter your license keys on the “Licenses” tab (remember the plugin works 100% without a license, you just don’t get support or updates); and come to “Help” when you’re struggling or need a buddy.

That’s it for the settings tabs! We’ll be back to reviewing the frontend in the next session. If you haven’t checked out our main 3.0 preview page…well, what better time than now?