A friendly challenge to all WordCamp Cape Town 2016 Workshop Speakers

It’s Sunday morning 11 September and I am still coming off of the high that is WordCamp.

However, one thing makes me sad. Due to constraints the day 1 workshops were not filmed. While I do understand the logistics of this and why it was not possible, I gets me thinking that it would be amazing if there was some way to still capture this information for those who attended, or better yet, those who could not make it.

And then it hit me. We live in a digital age. There is nothing stopping each and every workshop speaker from taking an hour of our their day, recording their own session and uploading it to YouTube.

So, if you were a workshop speaker on day 1 of WordCamp, I challenge you to redo your workshop in the comfort of your home or office, record it and share it with the world. If your workshop¬†was fairly seamless ( we’re looking at you Konstantin ūüėČ ) then it will be really easy. If, like me, there were things you could improve to help fit it into 1 hour, then make those changes and record your session.

I’m letting Steve and Danielle off the hook, I’m not sure they could record their talk and recreate the magic without an actual audience. ūüėČ

I also already know Chris Muller is off the hook, as his team filmed his talk for him. So Chris, you are first up, upload the video, share it and inspire the rest of the community to record theirs.

You can expect mine by the end of the week!

WCCT

UPDATE 2 : Here is the recording of my talk from the day

UPDATE 1: Just for fun I’ve uploaded a preparation recording of my talk, recorded in my car during the drive to day 2 of WordCamp. There are some minor errors in the recording as well as some background noises. Also some parts of the talk changed on the day, but the general gist is the same.

Listen on SoundCloud.

Slides from my Day 2 lightning talk at WordCamp Cape Town 2016

 

WordCamp Cape Town – Day 1

So day one of Word Camp Cape Town is over. It was quite a whirlwind of a day, but I thoroughly enjoyed every moment of it.

My WordCamp experience actually started on Wednesday night, at the VIP dinner. Here I got to meet and chat with a bunch of folk from the local WordPress community who I had only ever ‘met’ online. It’s quite a thing to already have a relationship with someone and then only meet them in person for the first time (I wonder if this is how new Automattic employees feel at their first company meetup?)¬†The vibe was great and I had some amazing discussions¬†with some awesome people.

Today kicked off (after the obligatory 1 hour 20 minute drive from the outskirts of town) with my ‘Extending WordPress’ workshop. It went pretty well, there are some things I could have done better and some things that I nailed, but all in all I had good feedback. It’s always great hearing that people finally understood a specific concept because of your talk and one or two people mentioned that to me, which was amazing.

After that I sat in on Seagyn’s advanced talk on Continuous Integration, Unit Testing and Integration testing. I got to play with Travis-CI and I am excited to start implementing this knowledge into my development work flow

After lunch I decided to stay on the advanced developer track and thoroughly enjoyed Konstantin Obenland’s Settings API workshop. Being able to watch an expert at work is an amazing thing, and Konstantin ‘live coded’ his Settings API example with only one bug (which he fixed in record time) causing him a few moments of quiet contemplation. And I do really mean moments, in the time that it would have taken me to figure out the problem, he’d already figured out the problem and the solution. Amazing stuff.

The day ended with a really fun and interesting talk from Steve and Danielle. I really enjoyed the way that made the entire workshop interactive and interesting. I would have easily listened to a workshop on how to increase your site speed, but they presented it in such a way that they actually made me excited to just go and learn how to do it myself. Well done guys.

Other things that stood our where how many of the local Divi community were present, where ever we ran into each other the obvious topic of conversation was Divi 3.0. I even had the chance to speak to some non Divi users and discuss the theme and its merits with them. I am definitely looking forward to meeting all the Divi Users that are at WordCamp tomorrow at our unofficial Divi Meetup.

All in all day one was pretty special. What inspired me the most was ¬†how full the three different tracks were, I’m looking forward to seeing and interacting with everyone in the single regular sessions track tomorrow

 

Adding the cart button to your Divi shop pages.

As is always the case with these code snippets, this one comes from a question by a user in the Divi Theme Users group on Facebook.

Leif Ottosson asked about the ‘Add to Cart’ button on the Divi/WooCommerce shop page. When adding the Divi Shop Module to a page via the Page Builder, the list of products on that page does not include an ‘Add to Cart’ button. The idea being that the user should first view the product before adding it to their cart.

Sometimes, however, it may be quicker or better (from a UX  perspective) to allow your user to add to their cart, straight from the product list page.

This can be achieved by using the following PHP code snipped, either in the functions.php file of your child theme, or in a plugin.


// register add to cart action
function dac_add_cart_button () {
    add_action( 'woocommerce_after_shop_loop_item_title', 'woocommerce_template_loop_add_to_cart', 10 );
}
add_action( 'after_setup_theme', 'dac_add_cart_button' );

Replace the ‘dac’ prefix with any prefix of your own and you should now see the ‘Add to Cart’ button underneath the products on any page where you have used the Shop module.

Making child themes part of your business development best practice.

In part one of this series on child themes, I discussed the hows and whys of child themes. Hopefully you understand what they are and why you should use them. In part two I want to discuss the various ways you can access or create child themes as well as show you some cool things you can do with a child theme.

A quick note to the reader, this article is aimed at Divi designers and developers. If you don’t use Divi most of this article will still be relevant, but some of it¬†will be very Divi specific. Also, before we continue, I would like to point out that I wrote a supplementary article to part one discussing the basics of a WordPress theme. If you don’t know how a WordPress theme works I recommend you read that article first before continuing with this one.

Everybody caught up? Right, let’s crack on then shall we…

There are three ways you can get a child theme, buy one off the shelf (from any of the Divi related marketplaces), roll your own using a number of child theme makers available, or create one yourself from scratch (DIY). Lets look at all three options.

Off the shelf

Off the shelf child themes are great. You get a pre built child theme customised¬†with¬†the developer’s choice of style and functionality included. What is quite unique about most Divi child themes is that you also get demo content included with the theme.¬†The ease at which child theme developers can create demo content using the Divi builder and the recently upgraded portability system means you literally get a fully functioning website out of the box. All you need to do is update the content, replace images and tweak some styles here and there and your site is ready to fly. If you¬†want to get a website up and running quickly, these off the shelf child themes are just what you need.

Roll your own

What I like to call a ‘roll your own’ child theme is one that you create using one of the online child theme creators. There are a few options available out there, just Google ‘divi child theme’. These are a pretty cool intermediary step. What the child theme creator does is ask you to input a few fields and it will generate a child theme archive for you to download. This child theme has the most basic of functionality (mostly just rewriting the Elegant Themes footer credits) but it is a great way to see the basic inner workings of a child theme and learn to build your own from there.

Do it yourself.

Otherwise known as ‘developing a child theme’. This is how the pros do it. Don’t get me wrong I have nothing against either off the shelf or roll your own child themes, but if you really want to understand not only child themes but WordPress themes and/or theme development, then you should really be developing your own. Not only does it give you a skill that is sought after, but it will open up a whole new avenue of WordPress and Divi customisation, giving you endless scope to create unique websites for your clients.

Now, as this series of articles is focusing on how to do it yourself, lets learn how to create a child theme.

The very basics.

All of what I am describing here you can read about in the WordPress documentation on child themes. In short, a child theme simply inherits the layout, styling and functionality of the parent theme but gives you the ability to override any of this layout, styling or functionality. A child theme only needs two things to be considered a child theme:

  • a directory (or folder) to contain the child theme files
  • a style.css file

The name of the directory is irrelevant. WordPress recommends naming it after the parent theme (eg ‘Divi-child’) but this is not required. Mostly developers¬†prefer to name it after the site its being used on or give it a descriptive name based on it’s content. It honestly doesn’t matter. What does matter is what is inside your style.css file.

The header of the style.css contains the most important part of the child theme, the parent theme registration. This is placed inside CSS comments at the top of the style.css file.

/*
 Theme Name:   Divi Child
 Theme URI:    http://example.com/divi-child/
 Description:  Divi Child Theme
 Author:       John Doe
 Author URI:   http://example.com
 Template:     Divi
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:  http://www.gnu.org/licenses/gpl-2.0.html
 Tags:         light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
 Text Domain:  divi-child
*/

Now the only really important part of this is the Template field. To ensure that this is registered as a Divi child theme you need to set Template to Divi. The rest of the fields are not important for a child theme to function, but it’s a good idea to at least give your theme a Theme Name and Version.¬†If you are developing themes for client sites or to sell, its also useful to include the Author URI, as a link back to your site. Finally, while it is not a requirement to do so for the theme to work, because your child theme extends WordPress, which is licensed under the GPL, you should also include the License and License URI, as your child theme will also fall under the GPL.

You can literally start copying template files from your parent them (in this case Divi) to your child theme and edit them to achieve the effect you require. Some of the common things you can do is:

  1. Copy the footer.php file to edit the footer credits (probably the question that is asked the most by new Divi builders)
  2. Copy the archive.php file to change how the default blog archive is displayed.
  3. Copy the /includes/social_icons.php file to add additional social media icons to your header or footer.
  4. Copy the 404.php to create a custom 404 page for your site.

Quite honestly the sky’s the limit. Any file that is ‘auto included’ in the Divi theme¬†can be overridden by copying it to your child theme and making the changes you require. You can also use the Template Hierarchy to create other files in your child theme to change how Divi renders certain views, for example creating a category.php file to enable how your category pages are rendered.

Working with style.

So obviously seeing as you have a style.css in your child theme, you’re going to want to also use it to add custom CSS to¬†the site you are working on. As mentioned in part one, this is a quicker way to add custom CSS to your child theme and in my opinion easier to manage and tweak. For this to happen you’re going to need to add a functions.php file to your child theme. By adding this file you can queue up the parent and child style sheets, as well as use it to add any custom PHP functionality to your child theme, and therefore your site.

A good methodology is to simply always create a functions.php in your child theme with the following PHP.

<?php
function my_theme_enqueue_styles() {
    $parent_style = 'divi-style'; // This is the 'parent-style'.
    wp_enqueue_style( $parent_style, get_template_directory_uri() . '/style.css' );
    wp_enqueue_style( 'divi-child-style', get_stylesheet_directory_uri() . '/style.css', array( $parent_style ) );
}
add_action( 'wp_enqueue_scripts', 'my_theme_enqueue_styles' );
?>

What this does is the following

  1. Registers a function called ‘my_theme_enqueue_styles’, to be fired¬†when the WordPress ‘wp_enqueue_scripts’ action is¬†fired.
  2. Enqueues the parent theme style sheet (in this case the style.css from the Divi theme)
  3. Enqueues the child theme style sheet (in this case the style.css from your child theme) and makes it dependant on the parent style

It’s important to note that the parent theme style needs to be¬†loaded as well as the child theme style, and in which order, so that the child theme styles override the parent theme styles, should they be applied to the same HTML¬†elements.

Once that is done you can do ahead and start adding custom CSS to your child theme style.css. As I’ve said before this is the recommended way to make large CSS changes to your Divi site.

Fully functioning.

But what else can be done with the functions.php file? Well this file really acts like a plugin file for your child theme. So you can add pretty much any custom functionality to your child theme in this file. Some examples include:

  1. Creating a function that will allow you to edit the contents of your footer credits from the WordPress Customizer
  2. Pre populating your new Divi site with common Divi settings
  3. Adding custom widgets
  4. Adding custom functionality to your Divi site, like custom modules or layouts.
  5. Customising the WP admin area

The sky is the limit really.

Active stations

Once you have created your child theme you will need to install it within WordPress. This is done by uploading an archive (zip) of the child theme directory via the Appearance -> Themes menu in your WP admin area (just like you would any other theme) and activating it.

A simple example.

I thought I would round of this article with a simple example of (more or less) all the things I’ve discussed above.¬†I’ve created a simple child theme that registers two additional customiser settings for editing the Divi Footer credits. It also contains some custom CSS for the footer, just to show how custom CSS is implemented. You can download it from the GitHub repository.

For the next article in this series I will dive into each of the functions of the example child theme as well as add some more cool Divi specific things that can be done. I’ll also look at some of the comment WordPress specific things you need to know about, like actions hooks and filters.

 

 

Please, copy my ideas!

An open letter to all Divi plugin developers:

Please, copy my ideas!

I am, first and foremost, an open source developer. That means I believe that if you have a piece of software, either purchased or obtained freely via open source repositories, you should be allowed to ‘study, change, and distribute the software to anyone and for any purpose‘ (definition of open source software from Wikipedia). Secondary to that, I am a problem solver. I get great satisfaction when I can solve someone’s problem, specifically if it is with a piece of software I develop.

With that in mind, if I develop a plugin for Divi and you are developing/planning to develop a plugin for Divi that does the same thing or think you can do it better, please don’t stop.¬†Build it, ship it, make it happen.

One of two things will occur.

  1. Your plugin will be superior to mine
  2. Your plugin will be just a copy of mine, with little to no added benefit.

Let’s consider both options

If your plugin is superior to mine,¬†I will (silently, or maybe even publicly) congratulate you. If we ever end up discussing it, I’ll probably even share my original source code with you, if it helps you improve yours. In fact I’ve done this before with the developer of the Image Intense plugin. Image Intense does so much more than my little Image Overlay plugin every will. When I recently ended up in a discussion with the developer (over a totally separate post I shared and he found use for), he mentioned¬†his soon to be released plugin with me. I shared my source code with him on the spot, should he ever find any use for it. Don’t believe me? Ask him yourself.

If your plugin is just a copy of mine,¬†I’ll simply shrug it off and move on with my life. I’m actively working on new plugin ideas every week (literally, I was working on one this week and another plugin idea came to me, via a conversation with a previous client, which I started on the prototype for) so if you make something that copies anything I do, I’ll take it as a compliment. After all, they do say that “Imitation is the sincerest form of flattery.”

There are some things that I do find reprehensible.

I personally feel that if you are a developer/designer/site builder and you are using a piece of software for a client project that requires payment to obtain, you should at least pay for that plugin. I’ve seen sites where premium plugins and themes are listed free to download, citing the GPL is the legal reason why they can do this. Legally they are not wrong, nor ethically, as the GPL allows for this (see my definition of open source above). But I do feel that if you are selling your services as an expert, but part of your expertise is using a specific plugin to achieve a desired result, you should at least buy that plugin for your arsenal of tools. Having said that, because it’s¬†GPL, there’s not really much anyone¬†can do¬†about it. You’re allowed to, so if you have no issues with doing it, then so be it.

I also do not agree with the concept of just copying and re-branding someone else’s code as your own. So if you buy any of my plugins, or obtain a copy of them via some other means, copy all the code verbatim but give it a new name to sell on your website (and I find out) I will call you on it. However, again because it’s¬†GPL, there’s not really much I can (or will) do¬†about it.

Competition is a healthy, natural part of being in business. As far as I am concerned, competition breads innovation. So please, compete with me, show me what you can do and I’ll show you what I can do. If you can do it better than me, great. My motto is not to be better than anyone else, but just to be better than the person I was yesterday.

At the end of the day the people who really win are our customers. And isn’t that the reason we got into building products in the first place, to solve our customers problems?

 

The definitive guide to calculating your billable rate

Recently on the WordPress South Africa Slack channel, a member asked the following question:

‚ÄúCan we talk pricing? How do you figure out how much to charge for WordPress Development? What factors influence your pricing?‚ÄĚ

A bunch of other freelancers (including myself) piped in and gave our opinions, but it was Nathan Jeffery’s post that really nailed it. (The figures below are quoted for South African currency/costs, but you can adjust it to your specific situation).

“Whether you charge a fixed rate or hourly the important thing to do is figure out your costs and from there work out your billable rate.

For example:

Monthly costs

  • Rent: 7,000.00
  • Adsl/Fibre/3G: 2,000.00
  • Electricity: 1,500.00
  • Food: 3,000.00
  • Hardware (50k depreciated over 3 years): ¬Ī1,400.00
  • Accounts and Auditing (10k per year split over 12 months): ¬Ī900.00

This makes your target income 15,800.00. Add a buffer of 20% for rainy day and savings, giving you 18,960.00 per month as a target

Potential billable hours

Next we need to determine how many hours can actually be worked in a month (on average).

If we assume you’re willing to work 10 hours per day and 6 days per week, that gives us 60 hours a week (240 hours per month) to work with.

Let’s assume that 60% of your time will be spent doing promotions, looking for opportunities, quoting, doing admin etc. This means you’ve only got 96 hours available in the month to work on paid work which is 4.8 hours of productive time per day, which is pretty reasonable.

Calculate your hourly rate

Based on these values we can work out an initial hourly rate.

Target (18,960.00) divided by potential billable hours (96) = 197.50 per hour, let’s round this up to 200.00.

This means if you’re booked 100% of your billable time, you could survive by charging 200.00 per hour.

The reality of the matter is that it’s unlikely you will be booked 100% of the time, at least not in the beginning, so you need to factor that into your survival costing.

Let’s assume you’ll be working 50% of the time which means you’ll need to charge twice as much per hour, therefore 400.00.

When working out your fixed cost quotes, you can/should use at least 400.00 per hour as your base rate to calculate what you should be charging.

You should also factor in time you need to allocate towards things like:

  • Having a holiday and paying for it (if that is your thing)
  • Learning and continued self development (the more you can do and the quicker you can do it, the more you can charge per hour)
  • Time off sick (it sucks but it is a reality so you need to budget for it)
  • Reserve for tax etc, if you’re invoicing in your own name you’ll be taxed as an individual and probably need to register for provisional tax. You need to make sure you keep enough money aside to pay your taxes when it’s required, don’t want to get in trouble with the taxman

This model can obviously be tweaked but should give you some idea as to what you’ll need to consider.‚ÄĚ

Nathan was also kind enough to share a Generic Freelancer Costing Template that can be used to calculate your billable rate.

I can honestly say that is the best guide I’ve ever seen for calculating your billable rate. Instead of focusing on what your competitors are charging and merely going lower, are you billing according to your costs vs available work hours?

You can read about Nathan on his website or follow him on Twitter.

The Basics of a WordPress Theme

In the first part of my article on child themes¬†I explained a little about¬†the history of WordPress themes and child themes, what they are and why you should use them. After sharing the post in a couple of online groups I am a part of, I received a fairly good positive response to the topic and my thoughts on it. One thing that also stood out from some of the comments was that a lot of Divi users don’t necessarily know how a WordPress theme works in the first place.

Everything I am writing about is (pretty much) included in the WordPress Theme Handbook,¬†specifically the articles on the Template Files, Template¬†Hierarchy and Child Themes. If you can afford the time to read through the handbook I highly recommend it. However it can sometimes be a little technical, so it’s often easier to get a ‘primer’ on the topic, to give you the relevant information you need in a manageable size. So, based on the responses to my first article I’ve chosen to first¬†write this article¬†to explain a little about how WordPress themes work.

Understanding the basics

To be able to understand¬†child themes, first we need to understand WordPress themes. This means we need to talk a little about the Template Files¬†and the¬†Template¬†Hierarchy. I’m not going to go into too much detail, but in short it’s the way in which WordPress looks for and loads the various template files in your theme to render content.

Template Files

Any WordPress theme has a base set of template files that is uses to render content for different sections of your WordPress site. If you take a look at the files inside a ‘standard’ WordPress themes (like those found on WordPress.org) you will see that, at their base level, all themes are made up of of two things, a style sheet and a bunch of php files, also known as templates. Theses templates¬†include, but are not limited to, files¬†like the header.php, footer.php, archive.php, single.php page.php and sidebar.php. Each of these templates¬†performs a different type of task within your WordPress theme.¬†The templates themselves are also divided into different template types, depending on what they do.

Template partials are template files that will be included inside another template file. For example the header and footer template files are partials. They will be included (and reused) inside other template files to render specific sections of a page, in this case the header and the footer of the site.

Examples:

  • header.php – contains all code to render the¬†header
  • footer.php – contains all code to render¬†the footer
  • sidebar.php – contains all code to render the sidebar

The common WordPress template files are the templates that will render the specific content of your site they related to. They can be very specific (rendering a specific category of posts, or a specific page) or very generic (for example the index.php file which will be used whenever a specific template file doesnt exist for the content being rendered)

Examples

  • page.php – contains the code to render a page
  • archive.php – contains the code to render any blog post archive (or list)
  • single.php – contains the code to render any individual post

If you read up in the Template Files section of the theme developer handbook you can learn what each one does.

Template Hierarchy.

The next thing to understand is the template hierarchy. This is the way in which WordPress will look for a series of template files to render the specific piece of¬†content. If the first template in the list doesn’t exist it will keep going down the list until it finds a template it can use. The easiest way to explain this is to take a look at a WordPress blog.

On a standard WordPress blog, you usually have a ‘list view’ (list of blog items, a thumbnail image, an excerpt and some form of link to the full article) and then an ‘article¬†view’ (the actual article itself, including any content for that article). So, that means that you would need at least two templates, one to render the list view and one to render the article view. This means that the WordPress engine will look for a template for each view and use it to render the content. For the list view, WordPress will look for a ‘archive.php’ file in your template folder to render the list view and a ‘single.php’ file in your template folder for the article view.
So your archive.php would contain some HTML to display the list view as well as a WordPress Loop to render the list of blog posts, and the single.php would contain HTML specific to the article view, as well as some PHP to get the relevant article content for display.

Now, if you are a theme developer you are probably swearing at me right now, and that’s fine. That last¬†statement is not 100% correct but I am simplifying it a bit, bear with me.

So great, there is a template for list views and a template for article views, what now? Well, lets say that you want to have links to a list of blog posts per category and you want a different display for each category list view.¬†Whenever a user views blogs under a certain category you want to include a description of that category above the list view. Well you could do this in two ways. Either you would add some code to your archive.php to check if the user is browsing a list of blog posts per category and show that description or you can use the category specific templates in the template hierarchy and create a different template per category. For example, if you had a category with the slug ‘products’ and you created a template in your theme called¬†category-products.php, whenever the user browses to the products blog category, WordPress would use that template file to render the products category blog items. This is useful because it means you don’t have to add extra processing to your archive.php template file and you can just service products category specific content to the user, just by adding a template file.

The other important thing to understand is that for each level of WordPress, from pages to posts, categories to tags, there is a hierarchy in place as to what gets loaded. So for example, when WordPress renders a list of blog posts, it first looks for a category specific template (either by slug or by id) then a general category template, then the archive template and then finally the index template. So in our products category example above (lets say the product category id was 5) WordPress would look for the following template files, in this order, to use to render the list:

  • category-products.php
  • category-5.php
  • category.php
  • archive.php
  • index.php

That’s 6 levels of template hierarchy that you could use to render things differently for different points of just your blog!

The same goes for blog posts, you have the following set of templates at your disposal when developing a theme. Lets say I was rendering a page with the slug (or name) ‘my-page’ which has an id of 7. WordPress would look for the following templates, in this order, to render the page content:

  • a custom template file ‚Äď (The page template assigned to the page in WP admin).
  • page-my-page.php
  • page-7.php
  • page.php
  • singular.php
  • index.php

Each template is the fallback to the previous template, with index.php being the final template for pretty much all sections of a WordPress site. You can probably see now why any theme developers reading this article were a little annoyed at my oversimplification of the theme hierarchy earlier ;-).

To get a better understanding of the different levels of template types available to you, as well the order in which WordPress loads them, I highly suggest you read Hierarchy in Detail section of the Theme developers handbook.

So what does this mean in terms of Divi. Well the base of the Divi theme is a small subset of the template partials and common template files. Divi doesnt have (for example) category based templates or even an archive template in its template file list. Because Divi has modules which render the blog lists and pages. Divi tends to use the templates towards the end of the hierarchy (single.php page.php and index.php) to render all content, because the modules are handling all the grunt work. However we need to have an understanding of what these template files do and how they can be ‘overridden’ using the hierarchy to be able to build our child theme.

A peek inside the Atlantic Wave workshop

It’s not every day that I get really excited about a plugin I am working on.¬†Don’t get me wrong, every plugin I develop is exciting, but more so from a ‘solving a puzzle’ or ‘fulfilling someone else’s requirement’ point of view. Granted, this is the reason I got into plugin development and it is a great feeling to know that people out there are using my plugins to make their lives easier.

What I’m talking about is the excitement I get about the fact that I am busy developing a plugin that not only will make others lives easier but also the fact that I¬†it has scope to become so much more than the current sum of its parts. It’s one of the first plugins I’ve written that¬†has the potential for so much more than what I am aware of and I am more excited about the future feature requests I’m going to get from the Divi community than anything else.

Allow me to introduce you then, to Atlantic Wave’s Elegant Forms plugin.

Building on the base of the Divi theme Contact Form module, with Elegant Forms I hope to fill a gap that, up to now, has required to the installation of other third party plugins like Gravity Forms or Contact Form 7. By baking Elegant Forms right into the Divi Page Builder I hope to bring the same extended functionality to your Divi site builder experience.

I’m about halfway through development of version 1 and I’m already planning the features to be added to future versions. I’ve included some ‘sneak peek’ screenshots of some of the functionality below.¬†If this excites you as much as it does me, comment below and let me know what you think. I’d also love to hear your requests for features to be added to this plugin.

As an added bonus, if you comment with your thoughts or a feature request below, when the plugin releases I’ll randomly select a winner from the comments to receive a 100% discount coupon on Elegant Marketplace, effectively giving you a free copy of the plugin at launch.