9seeds

Building Custom WordPress Solutions | Plugin Development

 

News

End of Life for Event Ticketing

Posted on

It started with a question. I asked Justin, “Are you still excited about working on Event Ticketing?” He didn’t even have to answer. When it took him more than 2 seconds to answer, I knew he was looking for the right way to let me down easy.

We spent the next 30 minutes talking about it, trying to rationalize keeping the plugin around. But ultimately, I explained it like this: “At the moment, the Event Ticketing plugin is a mediocre product. Since you are the person doing 90% of the development, if you aren’t excited about the project, there is no way we will ever make the plugin anything other than mediocre.”

And with that, be both knew what we had to do.

Today we are announcing the End of Life of both:

– WP Event Ticketing (version 1.3.3)
– Event Ticketing for WP (version 2.0.1)

We did not make this decision lightly. It’s actually been on my mind for the past couple months. But after an increase in support requests starting coming in and the realization that it could be weeks or even months before we could get a couple key issues fixed, the writing was on the wall and I knew it was time to pull the plug.

If you’re a developer and you would like to pick up where we left off and get Event Ticketing ready for prime time, the code can be found on github.

Genesis Simple Headers

And while we’re killing of plugins, he have also decided to remove Genesis Simple Headers from the WordPress repo.

This plugin was something I wrote quickly to serve a very narrow purpose. I released it thinking “hey, maybe this will be useful for a couple people.” Then it was downloaded more than 30,000 times. Yikes!

We finally decided to remove it thanks to two key factors;
a) StudioPress started adding the header functionality to the bulk of their new themes
b) With the release of Genesis 2.0, it would take a sizable amount of work to make GSH compatible

With less themes needing our plugin, spending the time to fix the plugin’s issues just seems silly. So by having the plugin available in the repo, we’re causing frustration for new users.

What about current users?

If you’re currently using one of the plugins above without issue, our decision to stop development will not affect you immediately. Your current plugin will not automatically cease to function. However, as WordPress continues to release new versions, there is no guarantee that the plugin will continue to function and you may need to seek an alternative solution.

Pretty PHP Date Ranges

Posted on

Pretty PHP Date Ranges

Last week I needed to come up with a way to display a pretty date range based on a starting and ending date in PHP. It’s simple enough use PHP’s date function to convert a unix timestamp into a pretty date format, but PHP doesn’t have a built in function to format date ranges.

The goal was to take two unix time stamps and output a range that looks like this:

January 25 – 26th, 2014

This sounds and is simple until you take into account that sometimes it crosses months and needs to look like this:

January 25 – February 2nd, 2014

or could cross years like this:

December 25th, 2013 – January 3rd, 2014

So here is the code to build those prettified date ranges:


 * @since 1.0
 */

function jb_verbose_date_range($start_date = '',$end_date = '') {

    $date_range = '';

    // If only one date, or dates are the same set to FULL verbose date
    if ( empty($start_date) || empty($end_date) || ( date('FjY',$start_date) == date('FjY',$end_date) ) ) { // FjY == accounts for same day, different time
        $start_date_pretty = date( 'F jS, Y', $start_date );
        $end_date_pretty = date( 'F jS, Y', $end_date );
    } else {
         // Setup basic dates
        $start_date_pretty = date( 'F j', $start_date );
        $end_date_pretty = date( 'jS, Y', $end_date );
        // If years differ add suffix and year to start_date
        if ( date('Y',$start_date) != date('Y',$end_date) ) {
            $start_date_pretty .= date( 'S, Y', $start_date );
        }

        // If months differ add suffix and year to end_date
        if ( date('F',$start_date) != date('F',$end_date) ) {
            $end_date_pretty = date( 'F ', $end_date) . $end_date_pretty;
        }
    }

    // build date_range return string
    if( ! empty( $start_date ) ) {
          $date_range .= $start_date_pretty;
    }

    // check if there is an end date and append if not identical
    if( ! empty( $end_date ) ) {
        if( $end_date_pretty != $start_date_pretty ) {
              $date_range .= ' - ' . $end_date_pretty;
          }
     }
    return $date_range;
}

Also available on GitHub/Gist here.

To actually use that in WordPress you’d just add something like this in your template file where you wanted to output the date, here based on two custom field values.

';
     echo jb_verbose_date_range( $start_date , $end_date );
     echo '';
}

Sticky Footer for Genesis

Posted on

glue-bottleWe had a client request that their site’s footer be fixed to the bottom of the browser window for “short pages” or pages with little content. A good example of how to accomplish this with HTML and CSS is available at: http://css-tricks.com/snippets/css/sticky-footer/. If you’re using the Genesis framework for WordPress however, a couple more steps are required to get the sticky footer working.

For this example, we’re using the Genesis sample theme, but it should work for any theme available from StudioPress with minor CSS adjustments to .site-footer height and .page-wrap margin-bottom.

You’ll only need to work with two files: functions.php and style.css. The code for each section is listed below. Note that this solution will likely not work in IE8 or Opera, where a javascript solution may be needed (see Ryan Fait’s sticky footer example for an alternative method that is not Genesis-specific).

Your mileage may vary. Feel free to leave your modifications and suggestions in the comments.

Sticky footer for genesis screenshot

Functions.php

//* Sticky Footer Functions
add_action( 'genesis_before_header', 'stickyfoot_wrap_begin');
function stickyfoot_wrap_begin() {
	echo '
';
}

add_action( 'genesis_before_footer', 'stickyfoot_wrap_end');
function stickyfoot_wrap_end() {
	echo '
';
}

style.css

html, body {
	height: 100%;
}

.site-container {
	height: 100%;
}

.page-wrap {
	min-height: 100%;
	/* equal to footer height */
	margin-bottom: -90px; 

}

.site-inner {
	min-height: 100%;
	/* equal to footer height */
	margin-bottom: -90px; 
}

.site-footer, .site-inner:after {
	/* .site-footer and .site-inner:after must be same height as .site-inner */
	height: 90px; 

}

.site-footer {
	background: orange;
	/* Use this for testing */
}

Developing WordPress Locally – Part 3

Posted on

This is the 3rd post in a 3 part series. You can find the first two posts here and here.

The previous two posts talked about getting set up to work on your WordPress website on your local machine, allowing you to build your site offline. In this final post in the series, I’m going to show you how to launch your new site live to the world.

Tools

My development is being done on a Mac, and my tools reflect that. If you’re developing on Windows, you’ll need to find alternate tools, but that shouldn’t be an issue.

Before we dive in

Since the process is a bit different for sites that are brand new Vs a site that already exists and you’re simply doing updates, I’ll go ahead and walk through both processes.

If you are not using DesktopServer, but are using something like MAMP for your local hosting, option 1 won’t apply to you, but, you should be able to use option 2 just fine.

I’ll also note that I am assuming you already have a hosting account and that you know how to install WordPress on it. Since most hosting companies these days have a one-click install for WordPress, that shouldn’t be a big deal. But if your host doesn’t offer one-click install, check out this article about installing WordPress.

And finally, since this is only an example walk through, I am not actually launching a site to a live domain. So in any screenshots where you see example.9seeds.com, that’s the location that is acting as our LIVE website URL.

Option 1: Brand New Website

Alright, you finally built your website and now it’s time to launch it. Let’s begin.

Step 1: Install DesktopServer plugin

Log in to your live site, which at this point should just be a default WordPress install. Go to the plugins page and install the DesktopServer plugin. Once it’s installed, activate the plugin.
ds-plugin

Step 2: DesktopServer

From the DesktopServer menu, select “Export, import or share a website” and click next. On the next screen, choose “Export or deploy a WordPress website.” and click next. On the 3rd screen select the “From Website” (your local dev install) and “Export as” (your live domain name) and then click the “Direct deploy to an existing server.” radio button. When you do, a pop-up will come up asking for your WordPress user credentials for your live site. Fill those in and hit submit. You will get a 4th page with options on what you want to do next. I leave things as they are with the top two options checked. Click next and then DesktopServer will get to work.

IMPORTANT: This is going to delete any WordPress data you have on your live site and replace it with everything you have on your local site. Fair warning!

Depending on the size of your site, this can take a while, so be patient.
ds-exportds-export-2ds-datads-launch

Step 3: Save Permalinks

Once DesktopServer says it’s done, the final step in the process is to log in to the live WordPress site and go to Settings -> Permalinks and click the save button. This needs to be done so that WordPress will generate the .htaccess file for you so your permalinks will work.

Remember, your username and password to access the site will be the same as it is to access your local development site.
permalinks

That’s it. Your new site is ready to go!

Option 2: Updating an existing site

In this version, we’re going to assume your site is already live, but you’ve now made some changes and you want to push those up to your live server.

Step 1: Transmit

First up, we need to upload any new themes, plugins or images that we’ve created locally. I do this by connecting to my live server with Transmit and highlight wp-content folder on both local and live. I then click the Sync button.
tr-sync1

On the next screen, you’ll want to make sure that the arrow (1) is pointing from your local server to the dev server. The proper folders (2) have been selected. Simulate the sync (3) is selected. Click the Syncronize button and Transmit will compare the local and live folders and report back what has changed. The great part about the sync tool, instead of having to upload all 1500+ files, it’s only going to upload the 107 files that are changed. This is a big time saver.
trans-sync-2tr-changed

Step 2: WP Migrate DB Pro

When using WP Migrate DB Pro, it’s important to remember that this step is going to wipe out your existing database. So, if you have a ton of traffic and comments and don’t want to lose those by pulling a copy of your local database up to your live database, you may want to instead simply open two browsers and copy/paste from the local to the live any changes you’ve made. BUT, if you are fine with making your live database match your local database, then this is the process for you.

On the live site, go to Tools -> Migrate DB Pro. On the Settings tab, check the box for ‘Accept push requests’ and then copy the connection info to the clipboard.
migrate-live

On the local site, go to Tolls -> Migrate DB Pro. On the Migrate tab, select the “Push” radio button and paste in the connection info from the clipboard. Then click Migrate DB.
migrate-local

You are done! Your live site should now match your local site.

I hope you’ve enjoyed this series on Developing WordPress Locally. If you have any questions or comments or just want to share your own process, please leave a note in the comments!

Want More?

– Read Part 1 of this series
– Read Part 2 of this series
– Sign up for our newsletter

Developing WordPress Locally – Part 2

Posted on

In Part 1 of this series I shared the process I go through to set up a local WordPress workspace for developing client websites when we are starting from scratch. In this post I will show you how I set up a workspace for clients who already have an existing website.

While I am explaining this as a process for working on a client’s website, this is also a great way to run a development version of your own website. It will allow you to try out plugins and themes using your real data so you can see exactly how it will work BEFORE you push it live.

Since many of the tools and steps I am going to use are the same as they are in Part 1 of this post series, I may gloss over details that are covered more in-depth in the previous post.

Tools

As I said before, I am developing on a Mac. Many of the tools I use are Mac specific. If you are on a PC, the concepts will be the same, but you may need to find a comparable tool.

Here’s the list of tools I’ll be using:

Before you get started

By now you should have already collected the FTP information and WordPress admin login credentials for the site you’re working on. If not, do that now. I’ll also mention that having a BitBucket account isn’t a requirement for what I’m going to show you here, but it is part of MY process, so I’m leaving it in, but you can skip that part if you’d like. OK, I think we’re set. Let’s do this!

Aaaaand Go

Just like I said in the previous post, I’m going to break up the process in to a number of ‘steps.’ Each time there’s a new step, that simply means we are changing applications. In my head, this makes the most sense for breaking up this post in to digestible segments.

Step 1: Desktop Server

First thing we’re going to do is set up a copy of WordPress to work on locally. In DesktopServer, start by choosing the ‘Create a new development environment’ radio button. On the next screen you will enter a site name and in the Blueprint dropdown choose the latest version of WordPress and click continue. After the install is complete, click Done and you’ll see the congratulations screen with a link to your new local WordPress install. Click the link to finish the WordPress install in the browser.
Create Siteds-new-siteds-congrats

Note: DesktopServer lets you create your own ‘Blueprints.’ These are folders that contain the default WordPress install and you can add your own default themes and plugins. As an example, I have the latest version of Genesis in the theme folder and I have a handful of plugins I use for development in the plugins folder. This is a nice time saver when setting up a dev environment.

Step 1.5

You may have noticed in my screenshot, my Desktop Server Blueprint is out of date. Because I installed an older version of WordPress, and some of my plugins are out of date, my next step is to log in to my new local WordPress install and update WordPress core and all plugins directly from the WordPress admin area. Just because we are working locally, there’s no need for us to jump through any crazy hoops to update WordPress. I love that about Desktop Server.

Step 2: Transmit

In Transmit, I create a new connection profile and fill in the details for my client’s website. I then connect to the server and I download everything from their wp-content/themes/ folder and wp-content/plugins/ folder. I store these in the matching folders inside our newly created website on our local machine.
transmit-createtransmit-folders

Note: If the site I am working on doesn’t have a huge amount of files in the uploads folder, I will go ahead and download that now as well. But, if it does have a large number of files, I will instead use the Uploads By Proxy plugin, which I will explain in a later step.

Step 3: WP Migrate DB Pro

If there is one plugin that saves me the most amount of time, it has to be WP Migrate DB Pro. We are going to use the plugin to mirror our live site on our local install.

Start by installing the WP Migrate DB Pro plugin on both your live site and your local installation.

On the live website, in the WordPress dashboard, go to Tools -> Migrate DB Pro. Click the Settings tab at the top. On the resulting screen click the “Accept pull requests allow this database to be exported and download” checkbox. Then, highlight and copy the information in the ‘Connection Info’ box.
migrate-live

On the local website, in the WordPress dashboard, go to Tools -> Migrate DB Pro. On the Migrate tab, click the ‘Pull’ radio button and paste in the connection info you copied a second ago. You do not need to click the ‘connect’ button. After a second you should see a screen that looks similar to this:
migrate-local

Click the ‘Migrate DB’ button at the bottom and the plugin will start pulling a copy of the live database and using it to replace your local database. It will also update all the website URL references and path references based on what it auto-detected. You can see that in the screenshot just above. When it’s done, you’ll see a confirmation message like this one:
migrate-done

47 seconds. Done and done.

Important Note: Your local database and your live database are the same. This means that the username and password that you set up locally in Step 1 above will no longer work. You need to log in using a username/password that existed on the live website.

At this point, we’re done touching the live website. All further steps in this process are done on your local WordPress installation.

Step 4: Uploads by Proxy

If you downloaded the /wp-content/uploads/ folder in step 2, you can skip ahead to Step 5.

When a client has a large number of files in their uploads folder, rather than spending time waiting for them all to download and taking up space on my hard drive, the Uploads by Proxy plugin comes to the rescue. Install the plugin and activate it.

Open Sublime Text 2 and open your wp-config.php file located in the root folder of your WordPress install. Add the following two lines to your wp-config file, just about where it suggests you stop editing.
define(‘WP_SITEURL’, ‘http://ignitevegas.com’);
define(‘UBP_SITEURL’, ‘http://ignitevegas.com’);
Like this:
sublime-ubp

Now our local site is displaying images directly from the live site. Here’s a before and after:
ubp-beforeubp-after

OK, one final warning about Uploads by Proxy. If you are planning to do development on your local computer from a location where you won’t have an internet connection, then using Uploads by Proxy is a bad idea! Go back and download the uploads folder instead.

Technically speaking, you are ready to start working on your site. However, before I get started I like to create a BitBucket repo and store a copy of the site files as they are now before I do any work. It’s always nice to have a rollback point in case something goes horribly horribly wrong. That being said…

Step 5: Tower

Before I create my local repo, I save a copy of this file in to the root folder of my local WordPress install and rename it to .gitignore (It has to be named exactly like that. See the explanation in the first post if needed.

From the Tower dashboard, click the “Create Local Repository” link. In the pop-up, click Browse to select the root folder for your local WordPress install. Give it a proper title and click OK.
tower-localrepo

Once the repo is created, double click it and you should see something similar to this:
tower-new-repo

I then do an initial commit of the .gitignore file and the wp-content folder. I do this by clicking the ‘Stage all’ button, clicking ‘commit’ and in the pop-up I type in ‘initial install’
tower-initial-commit

Step 6: BitBucket

In my bitbucket.org account, I create a new BitBucket repo. Like this:
bitbucket-create

Once the repo is created I select the Clone button and switch the second dropdown to SSH. In the screenshot below you’ll see that in the highlighted area it says ‘git clone git@bitbucket…’. We don’t actually need the ‘git clone’ portion. We want to copy everything after that. In this example, that’s going to look like this: [email protected]:9seeds/ignite-vegas.git Once we have that copied to the clipboard, we’re done with bitbucket.
bb-clone

Step 7: Tower

Now I’m going to add BitBucket as a ‘remote’ so that I can store a copy of the code in a central location for myself and my team to access later on. I do this by right-clicking on ‘Remotes’ and in the pop-up, I fill type in ‘BitBucket’ as the name of the remote and then paste in the info I copied in the previous step. I select Private Key from the dropdown and click OK.
tower-remote

The last step is to drag the ‘master’ branch on to the ‘BitBucket’ Remote. This will do an initial push of our local repository up to BitBucket. In the pop-up window, make sure to have the ‘Track this new remote branch’ checked and then hit OK.
tower-track

Alright, NOW you are really done. Now it’s time to open up your editor and get to work.

Sign up for the 9seeds.com newsletter to make sure you catch next week’s final post in the series where I’ll cover how we take the work we’ve done locally and push it to the live server.

Want More?

– Read Part 1 of this series
– Read Part 3 of this series
– Sign up for our newsletter