4elements, web design and consultancy

  1. Using Let’s Encrypt SSL With Your WordPress Project

    What's Let's Encrypt?

    For years, purchasing, renewing, installing and managing SSL certificates overwhelmed me with expense and complexity. Now, Let's Encrypt makes it fairly simple and free.

    Let’s Encrypt is an emerging, free, automated, and open certificate authority brought to you by a California public benefit corporation called the Internet Security Research Group—it also has nonprofit status.

    Its goal is to make HTTPS become the default Internet browser protocol to ensure greater privacy and security on the web. Mozilla and the Electronic Frontier Foundation are two of its platinum sponsors:

    Whats Lets Encrypt Platinum sponsors

    Let's Encrypt entered public beta in December, so I can now easily guide you through exploring its services.

    In this tutorial, I'll walk you through installing Let's Encrypt on a few of my websites, including my WordPress consulting website, http://lookahead.io, soon to be https://.

    Before we get started, please remember, I do try to participate in the discussions below. If you have a question or topic suggestion, please post a comment below or contact me on Twitter @reifman.

    Let's Encrypt Feature Summary

    Let’s Encrypt runs on Python working with Apache to automate certificate registration and renewal, simplifying the process of activating HTTPS capability for any website, including WordPress.

    Here are the key benefits that Let's Encrypt delivers:

    • Free: Anyone with a domain name can register a trusted certificate without cost.
    • Automatic: An Apache web server can easily acquire a certificate, securely configure it, and automatically manage renewal.
    • Secure: Let’s Encrypt will advance TLS security best practices, both as a Certificate Authority and by helping sites maintain secure servers.
    • Transparent: All certificate transactions are publicly recorded and available for inspection.
    • Open: The automatic issuance and renewal protocol will be published as an open standard.
    • Cooperative: Let’s Encrypt is a community effort to benefit everyone.

    Installing SSL With Let's Encrypt

    Let's begin by updating my server, Apache Ubuntu.

    If you don't have Git installed on your server, it's best to have it to install Let's Encrypt:

    Once installed, clone the Let's Encrypt software into the Apache opt sub-directory for third-party applications:

    First I experimented with installing Let's Encrypt on my Fever news reader application, not WordPress. I host it at http://fever.lookahead.io:

    The Setup Wizard

    To begin, you'll be asked for your email address:

    Lets Encrypt Installation Email Request

    Then shown the Terms of Service:

    Lets Encrypt Installation Terms of Service

    Let's Encrypt gives you the option of offering HTTPS as a secondary option or directing all traffic to HTTPS:

    Lets Encrypt Select HTTPS mode

    You're done in minutes:

    Lets Encrypt Congratulations

    You'll also be shown some notes on certificate expiration and renewal:

    Installing on WordPress

    To install Let's Encrypt SSL on my WordPress consulting site, it was just as easy. There was just one minor difference. I asked Let's Encrypt to support the www sub-domain as well:

    You can go visit it now, either HTTP or HTTPS, you'll end up here, https://lookahead.io:

    Lets Encrypt Lookahead Consulting

    SSL Reports

    You can go to sites like Qualys SSL Labs to get a site report on your SSL capability:


    Lets Encrypt SSL Qualys Labs

    Here's the authentication page:

    Lets Encrypt SSL Qualys Labs Authentication

    Certificate Auto-Renewal

    Auto-renewal is pretty simple too. First, we grab the renew script and give it execution privileges:

    Lets Encrypt Set up auto renewals

    Then run the script for each domain:

    And you can set up a cron job to run regularly:

    Add this line:


    I did run into a few quirks that I thought I'd share. When I installed SSL for my old Community Starter open-source project (both root domain and www), Let's Encrypted gave this error:

    I had set up a wildcard alias in my conf file:

    This change fixed it, adding an alias for www holdouts:

    Then the home page embedded Vimeo video failed:

    Lets Encrypt Vimeo Not Working with HTTPS

    I just had to change the iframe to the Vimeo player to use HTTPS:

    Problem solved:

    Lets Encrypt Vimeo Working with HTTPS

    In Closing

    I'm very impressed with the community goal Let's Encrypt has delivered on with quality and ease. Web publishers everywhere will benefit from simple, free SSL. Thank you EFF, Mozilla, and Let's Encrypt!

    Lets Encrypt Donate

    You can donate to either Let's Encrypt or EFF to support this work:

    You can learn more technical detail about their software here. Let's Encrypt also has a well-structured community forum:

    Lets Encrypt Community Forum

    What's Next?

    Let's Encrypt is actively working on finishing its first public release:

    We have more work to do before we’re comfortable dropping the beta label entirely, particularly on the client experience. Automation is a cornerstone of our strategy, and we need to make sure that the client works smoothly and reliably on a wide range of platforms.

    To keep up with the latest code, just update your git tree occasionally:

    My primary WordPress site runs with Varnish 3.x currently. This doesn't work out of the box with Let's Encrypt. I will probably spend some time soon tracking down a solution for that.

    In the meantime, if you're looking for other utilities to help you build out your growing set of tools for WordPress or for code to study and become more well-versed in WordPress, don't forget to see what we have available in Envato Market.

    If you have questions, please post them below. Or you can contact me on Twitter @reifman. Please check out my Envato Tuts+ instructor page to see other tutorials I've written, such as Cloning WordPress in Linux (in 90 seconds).

    Related Links


    Leave a comment › Posted in: Daily

    1. How to Rewrite Custom URLs in OpenCart

      In the course of this tutorial, we'll go through the details of custom SEO-friendly URLs. It's an important aspect you should look at while developing custom modules, and it affects the overall search engine rankings as well.

      We'll use the latest version of OpenCart, so make sure that you've installed that to follow the code.

      What We Are Going to Do—in a Nutshell

      Here's a summary of the steps we'll need to take to achieve custom URLs in OpenCart:

      • First, we will need to understand how it works in the core.
      • We'll go through the changes required in the core files.
      • We'll take a quick look at the SQL queries to insert our custom URL mappings.
      • We'll cover how to use built-in rewrite functions.

      So, that's the quick glance of what's coming up next. Let's move on to the first topic.

      The URL Mappings in a Database

      First of all, it's important to understand how SEO URLs work in the core of OpenCart.

      Go ahead and explore the entries in the "url_alias" MySQL table using phpMyAdmin or something similar. You'll see mappings like this.

      There are two important columns to note here. The first one is the query column which stores the actual path, and the other is keyword, which stores the SEO alias for that URL.

      As you can see, there are mappings for different entities like product, category, information, and manufacturer. Whenever any entity is saved in the back-end of OpenCart, an associated entry is added to this table.

      In the front-end, whenever the user accesses the URL, OpenCart finds the related mapping from the "url_alias" table. In this way, the actual entity is mapped to the SEO-friendly URL.

      Go ahead and open the file catalog/controller/common/seo_url.php, and let's explore the following snippet from the index method.

      As you can see, we are fetching the associated entry from the "url_alias" table. After that, the query parameter is parsed and an associated internal path is returned.

      So, this is the way it works in the core. Unfortunately, the setup only works for core URLs—for custom URLs we need to alter the core code. That's the recipe of our next section.

      The Core File Changes

      Go ahead and open the file catalog/controller/common/seo_url.php, and replace the rewrite method with the following one.

      The rewrite method is used to convert an internal URL into an SEO-friendly URL. But it does this only for internal URLs. Hence, we need to add custom code to make it work for our custom modules as well. In our code changes, we have provided the last else case which loads the mapping for our custom module. We have not added our custom mapping yet, so let's do it in our next section.

      Although we have modified the core file directly, it's just for the sake of simplicity. You should use OCMOD to alter the core file without actually modifying it.

      Add MySQL Entries

      In this section, we will add an SEO URL mapping for our custom module. Again, it's a plain SQL for example purposes—you can achieve that using module install scripts.

      Go ahead and run it in your OpenCart database.

      In the next and final section, we will see how to use the helper function to produce SEO-friendly links.

      How It Works

      Go ahead and create a new file catalog/controller/custom/custom.php with the following contents.

      Now, in the front-end, open the URL http://www.yourstore.com/index.php?route=custom/custom.

      Yeah, it's a plain white screen just with one link, and that is what we intended. The important thing to note here is the URL of that link— it's now SEO-friendly! Click on that and it will load the same page, as we have added the mapping for that in the "url_alias" table.

      So, that's the whole concept demonstrated in a simple way. You could extend it and make a model to insert SEO-friendly links for your custom module.


      Today, we have discussed an important topic in OpenCart—custom SEO-friendly URLs. We took a very simple approach to explain it, and I hope that it was useful for you.

      If you're looking for additional OpenCart tools, utilities, extensions, and so on that you can leverage in your own projects or for your own education, don't forget to see what we have available in the marketplace.

      Feel free to post your queries and suggestions using the feed below.


      Leave a comment › Posted in: Daily

    1. Drupal 8: Properly Injecting Dependencies Using DI

      As I am sure you know by now, dependency injection (DI) and the Symfony service container are important new development features of Drupal 8. However, even though they are starting to be better understood in the Drupal development community, there is still some lack of clarity about how exactly to inject services into Drupal 8 classes.

      Many examples talk about services, but most cover only the static way of loading them:

      This is understandable as the proper injection approach is more verbose, and if you know it already, rather boilerplate. However, the static approach in real life should only be used in two cases:

      • in the .module file (outside of a class context)
      • those rare occasions within a class context where the class is being loaded without service container awareness

      Other than that, injecting services is the best practice as it ensures decoupled code and eases testing.

      In Drupal 8 there are some specificities about dependency injection that you will not be able to understand solely from a pure Symfony approach. So in this article we are going to look at some examples of proper constructor injection in Drupal 8. To this end, but also to cover all the basics, we will look at three types of examples, in order of complexity:

      • injecting services into another of your own services
      • injecting services into non-service classes
      • injecting services into plugin classes

      Going forward, the assumption is that you know already what DI is, what purpose it serves and how the service container supports it. If not, I recommend checking out this article first.


      Injecting services into your own service is very easy. Since you are the one defining the service, all you have to do is pass it as an argument to the service you want to inject. Imagine the following service definitions:

      Here we define two services where the second one takes the first one as a constructor argument. So all we have to do now in the AnotherDemoService class is store it as a local variable:

      And that is pretty much it. It's also important to mention that this approach is exactly the same as in Symfony, so no change here.

      Non-Service Classes

      Now let's take a look at classes that we often interact with but that are not our own services. To understand how this injection takes place, you need to understand how the classes are resolved and how they are instantiated. But we will see that in practice soon.


      Controller classes are mostly used for mapping routing paths to business logic. They are supposed to stay thin and delegate heavier business logic to services. Many extend the ControllerBase class and get some helper methods to retrieve common services from the container. However, these are returned statically.

      When a controller object is being created (ControllerResolver::createController), the ClassResolver is used to get an instance of the controller class definition. The resolver is container aware and returns an instance of the controller if the container already has it. Conversely, it instantiates a new one and returns that.

      And here is where our injection takes place: if the class being resolved implements the ContainerAwareInterface, the instantiation takes place by using the static create() method on that class which receives the entire container. And our ControllerBase class also implements the ContainerAwareInterface.

      So let's take a look at an example controller which properly injects services using this approach (instead of requesting them statically):

      The EntityListController class doesn't do anything for our purposes here, so just imagine that BlockListController directly extends the ControllerBase class, which in turn implements the ContainerInjectionInterface.

      As we said, when this controller is instantiated, the static create() method is called. Its purpose is to instantiate this class and pass whatever parameters it wants to the class constructor. And since the container is passed to create(), it can choose which services to request and pass along to the constructor.

      Then, the constructor simply has to receive the services and store them locally. Do keep in mind that it's bad practice to inject the entire container into your class, and you should always limit the services you inject to the ones you need. And if you need too many, you are likely doing something wrong.

      We used this controller example to go a bit deeper into the Drupal dependency injection approach and understand how constructor injection works. There are also setter injection possibilities by making classes container aware, but we won't cover that here. Let's instead look at other examples of classes you may interact with and in which you should inject services.


      Forms are another great example of classes where you need to inject services. Usually you either extend the FormBase or ConfigFormBase classes which already implement the ContainerInjectionInterface. In this case, if you override the create() and constructor methods, you can inject whatever you want. If you don't want to extend these classes, all you have to do is implement this interface yourself and follow the same steps we saw above with the controller.

      As an example, let's take a look at the SiteInformationForm which extends the ConfigFormBase and see how it injects services on top of the config.factory its parent needs:

      As before, the create() method is used for the instantiation, which passes to the constructor the service required by the parent class as well as some extra ones it needs on top.

      And this is pretty much how the basic constructor injection works in Drupal 8. It's available in almost all class contexts, save for a few in which the instantiation part was not yet solved in this manner (e.g. FieldType plugins). Additionally, there is an important subsystem which has some differences but is crucially important to understand: plugins.


      The plugin system is a very important Drupal 8 component that powers a lot of functionality. So let's see how dependency injection works with plugin classes.

      The most important difference in how injection is handled with plugins is the interface plugin classes need to implement: ContainerFactoryPluginInterface. The reason is that plugins are not resolved but are managed by a plugin manager. So when this manager needs to instantiate one of its plugins, it will do so using a factory. And usually, this factory is the ContainerFactory (or a similar variation of it).

      So if we look at ContainerFactory::createInstance(), we see that aside from the container being passed to the usual create() method, the $configuration, $plugin_id, and $plugin_definition variables are passed as well (which are the three basic parameters each plugin comes with).

      So let's see two examples of such plugins that inject services. First, the core UserLoginBlock plugin (@Block):

      As you can see, it implements the ContainerFactoryPluginInterface and the create() method receives those three extra parameters. These are then passed in the right order to the class constructor, and from the container a service is requested and passed as well. This is the most basic, yet commonly used, example of injecting services into plugin classes.

      Another interesting example is the FileWidget plugin (@FieldWidget):

      As you can see, the create() method receives the same parameters, but the class constructor expects extra ones that are specific to this plugin type. This is not a problem. They can usually be found inside the $configuration array of that particular plugin and passed from there.

      So these are the main differences when it comes to injecting services into plugin classes. There's a different interface to implement and some extra parameters in the create() method.


      As we've seen in this article, there are a number of ways we can get our hands on services in Drupal 8. Sometimes we have to statically request them. However, most of the time we shouldn't. And we've seen some typical examples of when and how we should inject them into our classes instead. We've also seen the two main interfaces the classes need to implement in order to be instantiated with the container and be ready for injection, as well as the difference between them.

      If you are working in a class context and you are unsure of how to inject services, start looking at other classes of that type. If they are plugins, check if any of the parents implement the ContainerFactoryPluginInterface. If not, do it yourself for your class and make sure the constructor receives what it expects. Also check out the plugin manager class responsible and see what factory it uses.

      In other cases, such as with TypedData classes like the FieldType, take a look at other examples in core. If you see others using statically loaded services, it's most likely not yet ready for injection so you'll have to do the same. But keep an eye out, because this might change in the future.


      Leave a comment › Posted in: Daily

    1. 20 Useful WordPress WooCommerce Plugins Available on CodeCanyon

      WooCommerce is a free plugin that transforms WordPress into a powerful eCommerce solution.

      This WordPress eCommerce plugin now powers over 37% of all online stores and offers a wide variety of plugins that extend and customize WooCommerce in many different ways.

      Here are 20 useful WordPress WooCommerce plugins available on Envato Market that are worth your consideration:

      1. Fancy Product Designer - WooCommerce Plugin

      There are many product printing services on the web whereby users upload images, add text, and create their own unique t-shirt, mug, or just about any other product that can be printed on.

      With WooCommerce and the Fancy Product Designer - WooCommerce Plugin, you can do the same thing and build your own custom eCommerce storefront.

      Fancy Product Designer - WooCommerce Plugin

      This is one of the best online solutions for custom printing businesses:

      • customers can create text layers or upload images—even images from social media accounts
      • customers can color individual layers or choose those set by the store owner
      • smart pricing based on layers, layer types, product types, etc.
      • sell just about any type of product
      • and much, much more!

      This HTML5 WordPress WooCommerce plugin works with many themes and is easy to translate.

      You can't get much fancier than the Fancy Product Designer - WooCommerce Plugin.

      2. WooCommerce Dynamic Pricing & Discounts

      This WordPress WooCommerce plugin is a must have for anyone interested in offering discount pricing.

      The WooCommerce Dynamic Pricing & Discounts plugin lets you determine pricing rules and cart discounts with ease.

      WooCommerce Dynamic Pricing  Discounts

      Whether you're selling shippable or digital products, you'll find everything you need:

      • provide quantity discounts, special offers, percentage discounts and more
      • create an almost unlimited number of discount pricing types
      • conditional cart discounts
      • customer loyalty pricing
      • and much more

      Start boosting your sales and increasing customer loyalty with the WooCommerce Dynamic Pricing & Discounts.

      3. Table Rate Shipping for WooCommerce

      For wholesalers and retailers shipping products, you know how complicated shipping can be. Multiply the number of different products with the number of shipping destinations and you'll quickly realize how crazy it can get.

      With the Table Rate Shipping for WooCommerce WordPress plugin, however, you can set up a system that will help you charge less for shipping and sell more product.

      Table Rate Shipping for WooCommerce

      This WordPress WooCommerce plugin is one of the best-selling WooCommerce extensions for good reason:

      • set up zones based on country, state, or postal codes
      • base rates on price, quantity, weight or dimensions
      • generate one or multiple shipping cost options
      • supports volumetric shipping
      • and much more

      The fact that this plugin is also WPML compatible and has a tax inclusion option makes this a stellar choice.

      Need to ship? Table Rate Shipping for WooCommerce delivers.

      4. WooCommerce Extra Product Options

      WooCommerce Extra Product Options is a great solution for eCommerce stores that need to offer extra product options.

      WooCommerce Extra Product Options

      This WordPress WooCommerce plugin offers:

      • check-boxes, radio buttons, select boxes, textareas, input boxes, upload, date, range picker, and color picker
      • the ability to replace check-boxes, radio buttons, and select boxes with images
      • hide or show prices
      • form fields builder
      • and more

      WooCommerce Extra Product Options is a solid and simple way to bring extra product options to your WooCommerce-powered storefront.

      5. WooCommerce Product Filter

      If you're selling many products using WooCommerce, you're going to need a good way for customers to search, sort, and find what they're looking for.

      A product not found is a sale lost.

      The WooCommerce Product Filter is one of the best solutions for searching, sorting, and filtering products.

      WooCommerce Product Filter

      This WordPress WooCommerce plugin is impressive:

      • filter using taxonomies, price, range, and in-stock filters
      • unlimited filters and easy integration
      • widget filters and filter layouts
      • impressive design options
      • and much more

      My favorite feature has to be the filter analytics. Track your customer search behavior to improve your storefront or develop new products.

      The WooCommerce Product Filter is one of the best product search filters you'll find.

      6. WooCommerce Advanced Shipping

      Here's another nice option for those shipping products.

      The WooCommerce Advanced Shipping plugin is very advanced, but also easy to use.

      WooCommerce Advanced Shipping

      Features include:

      • customize with cart, user, and product based conditions
      • volume based pricing and table shipping
      • create unlimited shipping methods
      • set up worldwide shipping zones
      • and more

      WooCommerce Advanced Shipping also includes conditional logic.

      7. WooCommerce PDF Invoice

      Providing a PDF invoice with your eCommerce sales is not only a nice service to the customer, but adds a really professional touch.

      The WooCommerce PDF Invoice WordPress plugin is the perfect WooCommerce add-on to do that.

      WooCommerce PDF Invoice

      It's hard to consider any other option with these features:

      • supports custom check-fields and multiple custom content blocks
      • offers regular and proforma invoices
      • complies with accounting standards
      • excellent design layout and style
      • automatic invoicing
      • and much, much more

      It's feature rich and well designed, and you'd be hard pressed to find anything better.

      WooCommerce PDF Invoice is made by professionals, and it shows.

      8. WooChimp - WooCommerce MailChimp Integration

      Automatically build your customer email list by connecting WooCommerce and MailChimp with WooChimp - WooCommerce MailChimp Integration.

      It's pretty nifty.

      WooChimp - WooCommerce MailChimp Integration

      You'll find just about every option you could ever want in a WooCommerce MailChimp integration WordPress plugin.

      • subscribe customers automatically and sign up on checkout
      • includes widget and shortcode support
      • campaign-to-order tracking
      • Ecommerc360 support
      • and much, much more

      Leveraging the power of MailChimp with your WooCommerce storefront extends your reach and marketing in a powerful way.

      And you'll “go bananas” over the great support, documentation, and clean code the WooChimp - WooCommerce MailChimp Integration plugin offers.

      9. WooCommerce Advanced Bulk Edit

      If you want to do bulk editing (or export to a CSV file) of your WooCommerce products, you need to take a look at WooCommerce Advanced Bulk Edit.

      WooCommerce Advanced Bulk Edit

      Some of the features include:

      • bulk edit, add, and remove attributes
      • create, duplicate, and delete products
      • many ways to filter products
      • supports 40+ fields
      • and more

      WooCommerce Advanced Bulk Edit is simple, straightforward, and gets the job done.

      10. Subscriptio - WooCommerce Subscriptions

      Subscriptio - WooCommerce Subscriptions gives you everything you need to give your WordPress WooCommerce website the ability to sell and manage subscriptions.

      Subscriptio - WooCommerce Subscriptions

      This feature-rich solution is all you'll need:

      • options for cancellation warnings, suspended subscriptions, and more
      • PayPal and Stripe payment gateways are built in
      • recurring payments with any billing cycle
      • set up free trials or set-up fees
      • and much, much more

      For magazine subscriptions, online memberships, e-learning packages, etc... there's hardly a better WordPress WooCommerce plugin solution.

      Subscriptio - WooCommerce Subscriptions is solid.

      11. WooCommerce Customer Relationship Manager

      This is a cool WordPress WooCommerce plugin.

      WooCommerce Customer Relationship Manager extends your eCommerce site to a CRM (Customer Relationship Management) solution.

      WooCommerce Customer Relationship Manager

      Track all your customer interactions:

      • create new customers and place orders by taking orders over the phone
      • easily search and filter through your customers
      • send emails individually or bulk
      • assign customer status
      • log calls and emails
      • and much, much more

      This plugin makes it possible to sell products and services online, over the phone, or even face-to-face, making it a solution for both online and brick-and-mortar businesses.

      The WooCommerce Customer Relationship Manager plugin is impressive and unique.

      12. Wordpress Meta Data & Taxonomies Filter

      The WordPress Meta Data & Taxonomies Filter WooCommerce plugin gives you the ability to query multiple taxonomies and meta fields at the same time.

      Wordpress Meta Data  Taxonomies Filter

      Features also include:

      • create new meta fields with checkboxes, drop-downs, range-sliders, and more
      • includes widgets and shortcodes
      • AJAX searching support
      • and more

      If you need a simple and flexible search for your WordPress WooCommerce store, take a look at the WordPress Meta Data & Taxonomies Filter plugin.

      13. WooCommerce Currency Switcher

      If your customers are international or even if you're selling to one other country, you're going to need the WooCommerce Currency Switcher.

      This is a great way for users to change the currency being used and for the price to be converted in real time.

      WooCommerce Currency Switcher

      You'll find just the right features:

      • rate conversion using Yahoo, Google Appspot Aggregators, or manually
      • display currency switcher via widget or shortcode
      • five UI currency switcher options
      • GeoLocation by IP
      • and much more

      The WooCommerce Currency Switcher is simple, powerful, and well designed.

      14. WooThumbs - Awesome Product Imagery

      Stop using static images for your products.

      Start using WooThumbs - Awesome Product Imagery!

      WooThumbs - Awesome Product Imagery

      Build a better customer experience:

      • create image carousels and sliders
      • supports touch gestures
      • add product videos
      • zoom images
      • and more

      Don't rely on just your theme to make your products look good; give your images a boost with sliders, zoom, videos, and so on.

      WooThumbs - Awesome Product Imagery looks awesome.

      15. WooCommerce Products Designer

      Here's another “web to print” solution.

      The WooCommerce Products Designer gives customers the ability to create and upload their own designs to be custom printed.

      WooCcommerce Products Designer

      Some of the features include:

      • create starter designs for your customers
      • upload images from social networks
      • users can save designs for later
      • provide clipart libraries
      • custom pricing rules
      • upload controls
      • and much, much more

      The feature set is impressive and the UI is highly configurable.

      WooCommerce Products Designer is an excellent web to print solution.

      16. Social Coupon for WordPress

      Give your customers discount coupons for sharing pages via social media.

      Social Coupon for WordPress makes it easy to integrate into your WordPress WooCommerce store.

      Social Coupon for WordPress

      This plugin includes everything you'll need:

      • supports Facebook Like, Facebook Share, Google+, Twitter tweets, Twitter follows, and LinkedIn shares
      • display sharer on any page or widget area with shortcodes
      • set custom URLs or current page
      • full HTTPS support
      • and much more

      Hook directly into the WooComerce coupon system for easy discount management.

      Social Coupon for WordPress is a great way to increase shares and sales.

      17. SUMO Reward Points - WooCommerce Reward System

      Build your own loyalty reward program using the SUMO Reward Points - WooCommerce Reward System.

      This is a unique and powerful WooCommerce WordPress plugin to help increase customer engagement.

      SUMO Reward Points - WooCommerce Reward System

      Reward customers for:

      • social media shares
      • product purchases
      • writing reviews
      • signing up
      • referrals

      You can then offer points at a product, category, or global level. Points can have set expiration dates and much, much more.

      There are many different ways to configure SUMO Reward Points - WooCommerce Reward System.

      18. WooCommerce Recover Abandoned Cart

      Stop losing sales from abandoned carts and start recovering them with the WooCommerce Recover Abandoned Cart plugin.

      Send an email—and even follow-up emails—to recover abandoned carts.

      WooCommerce Recover Abandoned Cart
      "Recover Abandoned Cart monitors carts that are abandoned by Members and Guests to capture Abandoned Carts. It automatically sends mails using the mail templates at specified times to Recover the Abandoned Carts."

      Create and customize your email follow-ups. Add coupons, and schedule how many, how often, and when emails are sent.

      Using the WooCommerce Recover Abandoned Cart plugin is a great way to follow up and salvage sales that are otherwise already lost.

      19. WooCommerce Quick Export Plugin

      Exporting your sales and customer data into a CSV file can be very useful. Use it for bookkeeping, creating charts and graphs, sorting data, and importing into other systems.

      WooCommerce Quick Export Plugin makes the CSV export process easy.

      WooCommerce Quick Export Plugin

      Features include:

      • export based on time range
      • export customer data
      • export select fields
      • and more

      WooCommerce Quick Export Plugin is a great way to export your WooCommerce database fields to CSV.

      20. WooCommerce Bulk Edit Variable Products & Prices

      The WooCommerce Bulk Edit Variable Products & Prices plugin makes it super easy to make bulk edits.

      WooCommerce Bulk Edit Variable Products  Prices
      “You can edit as many products as you want in just one step and edit fields such as SKU, Stock, Regular Price, Sale Price, Weight, Height, etc. You can even increase or decrease all prices in a category by a set percentage % or dollar value $ for quick sales or product price increases/decreases all in one step.”

      Make big changes quickly and easily with WooCommerce Bulk Edit Variable Products & Prices and its easy-to-use Admin interface.


      While this covers a lot of the basics of extending WooCommerce, it just barely scratches the surface of what's available on Envato Market and around the web.

      If you're interested in extending WordPress WooCommerce yourself, consider an Envato Tuts+ tutorial, a course on developing a WooCommerce theme, or downloading the WooCommerce Cookbook eBook.

      What's your favorite or most useful WordPress WooCommerce plugin?


      Leave a comment › Posted in: Daily

    1. What’s the Difference Between Java and JavaScript?

      For those who are just getting started with programming, be it server-side or client-side, it's inevitable that you're going to come across the programming languages Java and JavaScript.

      If you've any experience programming in one or the other, then you know they aren't the same, and you probably know the difference between the two. But if you're just getting started, this can be confusing for some reasons, the first being how the languages are named.

      Though they share the name "Java" in their name, they share very few attributes and characteristics. In this article, we're going to take a look at some of the key differences in the languages by examining some of the high-level attributes each language offers.

      Ultimately, we're seeking to help those of you who are brand new to programming and aren't sure which language you'd like to learn (or learn first!). In this article, we're going to take a look at some of the key differences that exist in the languages and where each is applicable an attempt to arm you with the information necessary to help you take the next step in your career.

      Java and JavaScript

      Perhaps the best point to make when starting off in distinguishing these two languages is to draw the comparison like this:

      Java is to JavaScript as ham is to hamster.

      Unfortunately, I can't claim this analogy as my own. Instead, it's coined by Jeremy Keith, but it makes an excellent point: About the only thing the languages have in common is that they share the name "Java" in their name. 

      One similarity is that the languages are what we call "C-style" languages in that their syntaxes are like those of C. That is, they both have functions, parentheses, brackets, and semicolons.

      Other than that, though, there's very little similarity. Throughout the rest of this article, we're going to look at each language at a very high level to give you an idea as to what each language offers and the features of each. 

      Once done, you should be able to see a difference in the two languages and, although they are named similarly and have some similar syntax, that's about the only thing they have in common.

      So let's get started.

      What Is Java?

      We've covered Java in other tutorials on this site and will continue to do so as the language continues to grow over time. 

      Java was conceived under the idea of "write once, run anywhere", meaning that you could write a program on a computer and then deploy it to any device that had the Java runtime.

      But wait: What's the Java runtime? 

      First, it's important to understand that Java is a compiled language, though it's not compiled to binary, executable code. Instead, it's compiled to bytecode.

      Java bytecode is the instruction set of the Java virtual machine. Each bytecode is composed by one, or in some cases two bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters.

      Sounds less than exciting, doesn't it? That's okay! As developers, we aren't responsible for writing the bytecode. Instead, the Java compiler compiles our code to bytecode.

      This bytecode is executed on top of the runtime, which runs in the context of another operating system. This operating system may run on a cell phone, it may run on another computer, it may run on Windows, OS X, Linux, or any other system on which it's compatible. You can read all about it on this page.

      It sounds neat, right? The thing is, it's not without its challenges. It seems far easier than it is, and this is something that more advanced Java developers tackle. It's outside the scope of this article. Instead, we're going to focus on attributes of the language so that we can compare and contrast it with JavaScript.

      But first, let's look at some of the faculties we have to work in Java. It's important to note that we work at a much higher level. For example, we get to work with the following constructors:

      • Classes are the foundation of any object-oriented based language. They allow us to define what characteristics and behaviors an object will exhibit once it has been instantiated.
      • Functions are the parts of classes that allow objects to do something. A class that represents a File may allow us to read the contents of what it contains.
      • Properties, or attributes, are what describe a class. A File, for example, may have permissions such as the ability to read or write to a file system. It may also have a path representing where it resides on the file system.
      • Inheritance is when one class can inherit certain properties from another class. This means that it receives all of the functions and properties from a parent class, and it can add its unique functionality.

      If you've never written code before, some of this may sound like jargon. Understandably so! We have some resources that are available to help teach you what you need to know:

      But before jumping too far into making a decision about what you want to learn, let's take a look at JavaScript, as well.

      What Is JavaScript?

      I've covered JavaScript in much more detail in a previous article that you can read here, but I'll be covering the high points, as previously mentioned, in this article. For a much deeper dive, take a look at what's provided above.

      JavaScript, at its core, is a dynamic language that's untyped, and it's interpreted. This means:

      • We, as developers, can easily extend certain aspects of the language by adding our code to pre-existing objects such as the object String.
      • The untyped nature of the language means that we can declare strings, booleans, and numbers (versus integers, floats, and decimals) without having to state explicitly their type as we do in Java (and other languages).
      • The language is interpreted, meaning that it's not compiled into an executable. Instead, it's interpreted by a web browser or another piece of software on your computer that translates your instructions into machine code.

      If you're confused by any of this, don't worry! We've all been there:

      • Defining variables?
      • Implementing functions?
      • Creating objects?
      • Setting up conditional statements?
      • And much more.

      It's a lot. I know. But the nice thing is that we have plenty of resources to get you up to speed with JavaScript. And once you learn the nuances of the language, it becomes easier and easier to work within its confines.

      Remember, all of the "I'm not sure what I'm doing" is natural, and it's part of the learning curve. If you've never seen any programming related to JavaScript, then I highly recommend checking out a couple of the following courses:

      Once you get more familiar with the language, it's also important to use proper tools for developing your applications. This includes using tools such as a debugger (which most modern browsers include). This is out of scope for this particular article, though.

      A Note About Object-Orientation

      Another important distinction to make is that JavaScript and Java are both considered object-oriented languages but for different reasons.

      Java allows us to create instances of objects from classes that we create. Conversely, everything in JavaScript is an object. That means there are no classes. And because everything is an object, everything has methods and properties we can use. 

      In Java, when you create an instance of a class, you have access to the methods and properties that you expose through the class definition. If you have public properties, public functions, and so on, then the developer can use them.

      In JavaScript, when you create a variable, an object, or even a function, you have the ability to call functions that exist not only on that object but on objects from which the given object derives its properties. This has to do with the prototypal inheritance nature of JavaScript, which you can read more about in this article.

      Which One Should I Choose?

      As you can see from the content above, the two languages—though both inspired by C regarding their syntax—are very different. Each also serves a different purpose.

      Though you can write JavaScript on the server with technologies like Node.js, they aren't the same type of applications that are built with Java. Additionally, though you can write server-side applications with Java, they aren't the same type of applications that you typically write with JavaScript.

      Instead, it's often helpful to think about JavaScript being a language that's best suited for client-side development, for applications that will run in a web browser, or for single-page applications. And it's best to think of Java as a programming language that's best used for writing server-side or desktop applications that can be run on a variety of different operating systems and devices.


      Apparently, each of these languages offers their unique sets of advantages and disadvantages. Honestly, I think that much of what drives us to choose one language over the other has to do with what we want to do in terms of building solutions for ourselves and others.

      If you wish to work on the web, then JavaScript is likely your best choice. If on the other hand, you want to write desktop applications, then Java isn't a bad choice.

      For those who are interested, it's worth noting that JavaScript has become one of the de-facto languages of working on the web. It’s not without it’s learning curves, and there are plenty of frameworks and libraries to keep you busy, as well. If you’re looking for additional resources to study or to use in your work, check out what we have available in the Envato marketplace.

      I spend the majority of my time working with WordPress and building solutions on top of it; however, I'm also a fan of JavaScript and blog about it from time to time. If you're interested in other courses and tutorials I've written for Envato, please check out my profile page. Furthermore, you can read more articles about WordPress and JavaScript development on my blog. Feel free to follow me on Twitter as well at @tommcfarlin.

      With that said, please leave any and all feedback in the comment feed below.


      Leave a comment › Posted in: Daily

    1. How to Use Pantheon to Set Up and Maintain a Production-Safe WordPress Site

      Today, WordPress powers 25% of all of the world's websites, so it's safe to say that what started as blogging software has grown into something much bigger than its humble origins, and is ready to be used on production-level sites from news portals to complete web applications.

      With this level of professionalism, new needs arise.

      On a personal blog read by friends and family, a broken plugin update won't cause much more than slight annoyance—most likely, your readers won't even see the mistake. When you work in front of hundreds of thousands of visitors, however, such an error will be noticed immediately, and you won't get away with it that easily.

      "It worked on my computer" might be true, but it won't make the frustrated customer any happier.

      That's why, as you build a professional WordPress site for a bigger audience, you'll need a hosting setup that helps you make sure your updates are safe and never break the live environment.

      A Dev-Test-Live Setup Comes to the Rescue

      So, how do you make sure your server won't break when you push a new update live, be it a new version of your theme or an update to one or more of your plugins?

      By testing in an environment identical to the live server before pushing your changes live.

      Pantheon Architecture

      The setup starts with a development server that you use for your everyday work on the product: developer testing, presenting early changes to clients, and so on. This server might run on your computer or a server in the cloud.

      When you are happy with how things are looking on the development server, in this setup, you won't rush to push your code live. Instead, you commit your changes into version control and deploy them to a test server.

      Because the test environment runs server software identical to the software on the live server—except for the fact that the new code hasn't been updated to the live server yet—you can use it to spot any issues that might arise on the server but not on your development environment. To make testing even more realistic and spot errors caused by data entered by your customers, you can also populate the test database with real data from your live server.

      On the test server, you make sure that everything works as it should by testing the site manually or by running automated tests, or a combination of the two. And only then, when the tests complete successfully, push the changes live. With confidence, knowing that the changes won't break your site.

      How Pantheon Can Help You

      While the Dev-Test-Live approach is well known among software companies building services online, it has traditionally been limited to developers and businesses with the resources to run and manage multiple servers on their own—and to keep them in sync with the same server software and data.

      That means paying for many servers, but also a lot of maintenance work.

      On Pantheon, this approach comes built in with the service.

      Pantheon is a scalable, fast WordPress and Drupal hosting service that not only makes it possible for you to test your code on a test server before pushing it live but pretty much forces you to follow the best practice procedure in all of your deployments.

      In this tutorial, you will learn how to set up a WordPress site on Pantheon and develop and maintain it securely using the Dev-Test-Live architecture and version control.

      Let's get started!

      1. Setting Up Your WordPress Site on Pantheon

      Now that you know what we'll be building (and why), it's time to get started.

      One of the great things about Pantheon is its pricing model: you only pay once your site goes live, so you can try everything and even demonstrate your website to friends and customers before having to pay for your account.

      First, head over to the Pantheon website and create your free account.

      If your work consists of creating websites for a bunch of customers, or you have a team of developers working with you, you can sign up as an agency. Agencies have the same pricing structure but also get some extra features such as Multidev, which allows you to fork a site into multiple development environments to ease collaboration and to build and demonstrate new features without having to update the primary environment.

      If you are not sure which type of account is right for you, just go with the default one. You can always convert your account to an agency account later.

      Step 1: Create a New WordPress Site

      Once signed in, you'll see the following view:

      Welcome to Pantheon

      Click on Create New Site to start building your first WordPress site on Pantheon.

      Name Your Pantheon site

      On this screen, choose a name for your site on Pantheon: the name is used in your Pantheon admin, and for generating your environments' URLs. You cannot change this name later, so it's good to give it some thought, but don't worry—it doesn't have to be the same as your WordPress site's final name.

      The names are global across Pantheon, so selecting something very generic can lead to an error. In that case, try something else.

      Site Name already in use

      After selecting the name, click Create Site.

      Next, you will be asked to choose the start state for your new site. You can either start a new website from scratch or import an existing Drupal or WordPress site:

      Configure Your Site

      Choose Start from Scratch.

      Below the selection, you'll see a list of different starting packages or upstreams, as they are called on Pantheon.

      These default upstreams are maintained by Pantheon so that when a new update becomes available to one that you are using (WordPress, in our case), you can easily update them to your site through the Pantheon Dashboard.

      Install WordPress

      As we're creating a WordPress site, click on Install WordPress.

      The installation begins. And after a little while, it's ready.

      Your site is ready

      Click on the Visit your Pantheon Dashboard button.

      Step 2: Complete the Setup and Visit Your Site

      Now, you have a brand new WordPress installation running on a Pantheon development server and can access and control it through the Pantheon Dashboard.

      Your new WordPress site on the Pantheon dashboard

      On the top of the screen, you'll see three tabs for the different server environments: Dev, Test, and Live. Under each tab, you'll then find a similar menu structure for maintaining that server and deploying code and data between environments:

      • Code: Shows the commit log of the underlying Git repository. On the Dev environment, as we'll soon see, this can also be used for committing code to version control.
      • Status: Information about the environment's status such as database usage, cron jobs, required WordPress plugin updates, and caching.
      • Database / Files: Tools for exporting, importing, and cloning databases and uploaded files.
      • Errors: PHP Errors logged on the selected environment.
      • Domains / HTTPS: Tools for setting up a custom domain and an SSL certificate for the environment. This feature is only available for paying customers.
      • Backups: Tools for backing up the environment's database. Paying customers can also set up automatic backups.
      • Security: An option for password-protecting the environment so that outsiders will not be able to see what you are working on before it goes live.

      Click on the Site Admin button on the top-left part of the screen. That will lead you through your regular WordPress setup flow:

      Begin your WordPress setup

      You can also click the Visit Development Site button to view the site.

      The new WordPress site running the Twenty Sixteen theme

      Step 3: Create the Test Environment

      Now that your development environment is up and running, let's take a look at the other two environments.

      As we saw above, on the Pantheon dashboard, you'll find the tabs for the three server environments: Dev, Test, and Live.

      Environment Switching Tabs

      Each of the tabs represents one of the server environments running your site. Dev is the development environment for testing as you work on the site, and maybe demonstrating an early version of the site to customers. Live is the version of the site that is up and running, and being used by actual users.

      In between the two is Test, the environment that keeps your live site relatively secure from your mistakes. Before you can push anything live on Pantheon, it will always have to go through a Test environment, so that you get one last chance to check that everything works correctly before sending your code into the wild.  

      As we just created the new WordPress site, it still only exists in the development environment.

      Let's create a test environment for it.

      Click on the Test tab.

      First time seeing the Test tab

      As this is your first time on the Test tab, you'll see some information about how the Test environment works.

      Click on Create Test Environment to clone your Dev environment for testing. At this stage, both the code and data from Dev are cloned as no live environment exists yet. In future updates, as well soon see, however, only code moves from Dev to Test. That's because the idea is that on the test server, you'll check your code against data copied from the live environment.

      Test environment created

      The test environment is now ready.

      Click on Visit Test Site to check that the test site looks just the same as the site running on your Dev environment. You can also click Site Admin to sign in to your WordPress dashboard. Use the same admin credentials you defined for WordPress on the Dev server.

      You have created a very basic WordPress installation with a development and testing environment and are ready to start customizing it.

      2. Installing Plugins and Configuring Your WordPress Site

      Now that you have a WordPress installation running in the cloud, you probably want to do something more with it. At the very least, you'll install a few plugins and maybe a theme, and customize the site to match your liking. In a more complex setup, you'll write your own plugins and maybe create a custom theme to make your site your own.

      That's where we get to the heart of working with a Dev-Test-Live setup.

      The setup on Pantheon is based on version control: Pantheon keeps your entire WordPress installation, except for file uploads, which are handled using a special file system, in a Git repository. This way, when you deploy your changes to the next environment, everything always stays in sync and you never lose your changes.

      That also means that the only way to make updates to the Test and Live environments is through version control. You cannot install plugins or themes on the Live server the way you probably are used to when working with WordPress. After all, that would break the idea of testing the setup before pushing it live.

      So, how do you install and update plugins and themes on your WordPress site?

      Step 1: Enable the SFTP Connection Mode

      You can access your site's Dev environment on Pantheon in two ways: using Git or directly over SFTP.

      While using Git is useful for some more advanced use cases (we'll take a look at it later in the tutorial), part of the beauty of the Pantheon setup is that by using SFTP, you can use the Dev environment as your development server. This way, it is possible even to skip having a development server running on your computer at all.

      The choice isn't permanent: you can switch between the modes depending on what works best for the task at hand.

      So, for now, make sure your Dev environment is using the SFTP connection mode:

      Choose the SFTP connection mode

      In the SFTP mode, you make your changes to the WordPress installation's codebase directly on the server, and then, when everything looks good, commit your changes to Git using the tools on the Pantheon dashboard.

      This way, you can use the Dev site as you would use any WordPress site and customize the site using the WordPress dashboard just as you would on a single server setup.

      Let's try it in action.

      Step 2: Install a Plugin

      In the WordPress admin dashboard, select Plugins > Add New. Then, select a plugin you'd like to install. As an example, I installed JetPack by WordPress.com:

      Plugin installed

      Now, activate the plugin and check that it runs as expected on your Dev server.

      When you are happy with the plugin, return to your Pantheon Dashboard. There, you'll see that the system has noticed your changes and shows them as changes ready to be pushed to version control.

      Changes ready to be committed

      Click on the text field that says Add a commit message to enter your commit message and to see some more details about the changes that are about to go into version control.

      Files with the most changes

      Check the changes, add a descriptive commit message, and click Commit to commit the changes.

      Once the commit has finished, the changes are available to be deployed to the Test server. To do this, click on the Test tab.

      There, you'll see the following notification.

      1 commit is ready to deploy

      It's the commit you just made on your Dev environment, now ready to be deployed to Test.

      Type a descriptive log message and click on Deploy Code from Development to Test Environment.

      Then, visit your Test site's WordPress Dashboard to check the changes.

      On the Plugins page, you'll see that the plugin has been installed, but it isn't active yet.

      The Jetpack plugin is now available

      That's because on Pantheon, while code gets updated from Dev up towards the live server, database changes, including information about the active plugins, flow the other way, from Live towards Dev.

      Because plugins often run some code at activation, for plugins, this is not bad. You just need to remember to activate your plugins after the deployment has completed and you're ready to go. In my next Pantheon tutorial, I will show how you can automate this using Pantheon's command-line tool.

      However, while this approach works for plugins, there are other data, such as plugin and theme settings, that form an important part of the site's setup that you probably don't want to configure manually after the deployment.

      Let's look at how you can pass them from one environment to the next.

      Step 3: Deploy Site Options Through Version Control

      As we remember, code—or files in version control—flows up from the development environment towards the live server. So, to move settings in a similar way, the most natural approach is to store them in version control.

      To do this, we will use a free WordPress plugin that does just that.

      The plugin, WP-CFM, reads options from the WordPress options tables and stores them in a text file, which can then be committed to version control (remember, the entire WordPress installation—except the uploads directory—is stored in version control and read in the other environments).

      Let's do this next.

      Follow the instructions from Step 2 above to install the WP-CFM plugin in the Dev environment and to deploy it to Test. Then, activate the plugin on both environments.

      Now that the plugin is active in both environments, we can use it to push WordPress options from Dev to Test. If you like, you can modify some WordPress settings at this point so you'll see how the changes get applied on the Test server (the site's name, for example, is a pretty visible change).

      In your Dev server's WordPress dashboard, click on Settings > WP-CFM.


      Click Add Bundle to create a new settings bundle for version control. Bundles are collections of setting that can be saved and pushed independently of each other.

      Select options to include in the bundle

      Next, you are asked to select the options you'd like to include in the bundle. If you want to keep some options different from one environment to the next, you can uncheck them in the list.

      In the example above, I chose everything in WP Options, except the list of active plugins (because I want to be able to run the plugin activation scripts on every environment), but you can pick whatever feels logical to your site setup.

      When you are happy with the list of options, click Save Changes.

      Once you have saved the bundle, you'll see new buttons for it:

      Buttons for using the bundle

      Click on the Diff button to see the differences between your Dev database and the contents of the options file exported by WP-CFM.

      As WP-CFM hasn't created an export file yet, the diff will show everything as added:

      WP-CFM Diff Viewer

      Close the Diff popup, and click Push to store the data from the database to the export file.

      Now, when you go back to your Pantheon dashboard's Dev tab, you'll see that WP-CFM has created a JSON file (wp-content/config/site_options.json) ready to be committed to version control:

      1 changed file ready to be committed

      Commit the changes and deploy them to the Test environment.

      Then, on the Test server's WordPress dashboard, navigate to Settings > WP-CFM.

      WP-CFM on Test

      First, you'll notice that the Site Options bundle is now available also in this environment.

      However, because of the limitations set to the Test and Live environments, you'll also notice that the options bundle only works in one direction: wp-content/config is not writable on the Test environment. This is great because it will help us keep the export file clean.

      Click on the Pull button to read the contents of the configuration file and apply them in your WP Options table. In the confirmation popup that asks "Import file settings to DB?", answer OK.

      Now, if you made some changes to your WordPress options before doing the Push on the Dev server, you should see those changes also applied to the Test site.

      Step 4: Bring Real Data From Live or Test to Dev

      At some point in your site's lifecycle, you might want to take the actual data from your Live server to Dev. It could be to test a bug against real data, or just to see how things look with real user-generated content instead of some test data created by you, the developer.

      On the Dev environment, click on Database / Files in the menu on the left.

      Clone Database and Files

      Here, you can choose the environment from which to clone the data (test / live) and whether you want to clone just the database or also any file uploads made in that environment.

      You also have the option to update any URLs in the database to match the Dev environment's URL structure.

      Notice that the cloning will replace everything in your Dev environment's database, so if you have any custom changes that you'd like to bring back after the cloning, use WP-CFM to push them into a text file before doing the cloning.

      This functionality is most useful for pulling data from Live and Test to Dev, but you can also use it to clone the Dev database to Test (and even Live). It can be useful for example if you create your initial site content (pages and maybe blog posts) on the Dev environment and want to push it to test at once before creating the Live environment.

      3. Working With Your Site's Codebase

      We have now looked at the basic WordPress management tasks such as installing new plugins and pushing configuration changes between environments.

      Updating plugins and installing themes can be done in the same way, following the same instructions. So, if you do all of your site's management using pre-existing themes and plugins, this is pretty much what you need to know about the basics of Pantheon to make great use of it.

      Often, however, you'll also want to change the code yourself, be it by writing a plugin or by modifying and customizing a theme.

      To demonstrate how you can do this, let's create a simple child theme for the current default theme, Twenty Sixteen, and push it all the way to the Test site.

      Step 1: Use SFTP to Connect to Your Pantheon Dev Server

      Still continuing with the approach of using the Pantheon Dev environment as your development server, let's use your favorite FTP client to upload our code modifications to the Dev server.

      This is easy, and we've all probably done this at some time or another on other servers on the internet.

      To connect to the Pantheon server, first, on the Pantheon Dashboard, click on the STFP Connection Info button to open a popup with information on how to connect to your development server.

      SFTP Connection Instructions

      Copy the Host and Username information to your FTP client and use your Pantheon Dashboard password to connect to the server. Make sure to use the Port specified in the connection instructions.

      Once connected to the server, you'll find your WordPress site's entire codebase in the directory ~/code.

      Your WordPress installation is found under code

      Once connected, you can use your FTP client to replace any files or upload new ones, and see the changes applied immediately on your Dev server's WordPress site.

      Many FTP clients, code editors, and PHP IDEs (such as PHPStorm and Eclipse) allow you to sync your code changes directly with a remote server using SFTP. By using those tools, you can make the development even quicker with the extra step of uploading your changes for testing happening automatically in the background.

      Notice that your Dev server's SFTP URL can change from time to time, so if you find yourself unable to connect, just check the current connection credentials from the Dashboard and try again.

      Step 2: Create and Upload Your Child Theme

      As an example of this approach, let's create a simple child theme for the default theme, Twenty Sixteen. As this is just for demonstration purposes, we'll keep the theme super simple with nothing but a style.css file that changes the site's background color to red and a functions.php file for enqueueing the stylesheet.

      On your computer, create a directory called twentysixteen-child, and inside it, a text file named style.css.

      Inside style.css add the following content:

      Then, create a functions.php file with the following contents:

      Next, upload the directory along with its contents to your Dev server's directory ~/code/wp-content/themes/.

      The directory has now been uploaded

      Now, when you visit the Appearance > Themes screen on your Dev server's WordPress admin, you'll see that the new theme is now available for use.

      Go ahead and activate it!

      Activate the Twenty Sixteen Child theme

      Now, when you visit your Dev site, you'll notice that its background has turned red, just as we defined in the Child theme's CSS file.

      Step 3: Commit Your Changes and Deploy the Child Theme to Test

      You have now uploaded a new child theme to your Dev server. Next, to make sure you don't lose your changes, and to be able to deploy it to the Test server, you'll need to commit your changes to version control.

      When developing your site directly on the Dev environment using SFTP, it's critical to remember that before you commit the changes to Git on your Pantheon Dashboard, they are not stored in version control. So, to make sure you won't lose any of your important changes, don't forget to commit often—even when you are not yet ready to push your changes to Test.

      On the Dev environment's Dashboard tab, you'll notice that you have some uncommitted changes ready to be committed.

      3 changed files ready to be committed

      Type in a commit message and click Commit.

      In the screenshot above, you'll also notice that there are changes in the site_options.json file created by WP-CFM. That's because I pushed the information about activating the theme to that configuration file. This way, the new theme will get activated almost automatically. While this isn't necessary in this simple example case, it's a good practice to adopt considering the future and any more complex theme setups you may be building.

      Once you have committed the changes, deploy them to Test using the steps explained earlier when we deployed our plugin installations. Then, if you pushed the site options bundle using WP-CFM, use the plugin to pull the changes to the test site's database.

      Now, when you visit the Test environment's Appearance > Themes page, you should see the new theme as the active theme.

      Twenty Sixteen Child as the active theme

      Step 4: Working With Git

      If you want to have clearer control over the codebase and prefer to do your development and developer testing on your local machine, you can push your code to the Dev server using the Git version control yourself instead of first uploading the changes to the server over FTP.

      To do this, again on the Dev server's Code tab, switch the Connection Mode from SFTP to Git.

      Switch the Connection Mode from SFTP to Git

      If you have any uncommitted changes on the Dev server when you switch to Git mode, you'll see a popup asking you to confirm that you want to do the switch and lose the changes.

      Are you sure

      If you want to keep the changes, close the notification and commit before continuing with switching the mode. If you don't need the changes, type DELETE in the text field and click on the big red button.

      Git authentication on Pantheon is done using an SSH key, so before continuing further, you need to generate a key and add it to your account. You can use the same SSH key for all of your Pantheon sites, so you'll only need to do this once.

      Add an SSH Key

      With your SSH key in place, you can start working on your WordPress installation using Git.

      Click on the Git Connection Info button on the Dev environment to reveal the exact git clone command to use to pull your site's Git repository to your local machine.

      Git Connection Instructions

      Run the git clone command on the command line, in a directory where you want to store the code on your computer. If you prefer using a graphical user interface, that's alright too: you can go ahead and use your favorite Git client.

      Once you have cloned the Git repository, you'll see that the directory contains your entire WordPress installation.

      Git directory structure

      To test working with Git, make a small modification to the child theme we created in the previous steps.

      Modify the child theme's style.css, changing the background color to green instead of red. Then, commit the change to git.

      In the project directory, on the command line, type the following commands:

      Once the push command has completed, visit the Pantheon Dashboard.

      There, you'll find your change listed in the commit log, and when you visit the site, you'll see that the background has turned green.

      Commit Log shows the latest change

      So, the change you made is now present on the Dev server but also ready to be deployed to the Test environment.

      In a way, you can use this method to either bypass the Dev server entirely (running the development on your local machine and using Pantheon for just the Test and Live environments) or as a different way for uploading code to your development server.

      It's all up to you and your preferences, as is the choice between SFTP and Git itself.

      From here on, the rest of the workflow—deploying your changes to Test, and finally to Live—is the same as when working in the SFTP mode.

      What's Next?

      You now know how set up and run a WordPress site securely using a Dev-Test-Live setup on Pantheon. This will get you a long way in doing updates without worrying about breaking the live server. 

      But while this is already an excellent setup, we can improve it—and your workflow—by automating some of the tasks, and adding an automated testing phase to the process. We'll dive into those in my next tutorial.

      Until then, keep experimenting with your new Pantheon site!


      Leave a comment › Posted in: Daily

    1. How Dispatching Works in OpenCart

      As a programmer, it’s important that you understand the flow of the system you’re working with—not just for the sake of being able to alter something when needed, but also because it’ll give you a confidence boost while doing so.

      Today, we’ll pick OpenCart and dissect it to understand the basics of the dispatching process. We’ll start with what the dispatching process is all about, and as we move on we’ll explore code slices from the different sections of the framework.

      I’ll pick up the latest version of OpenCart for this article, but more or less the flow is similar in the earlier versions.

      Dispatching in a Nutshell

      In any web-based application, the dispatching process is used to find the mapping between the incoming request URL and the corresponding module in the framework. Of course, the implementation varies from framework to framework, but the underlying concept remains the same. So here are some of the responsibilities of the dispatcher:

      • Grab the appropriate parameters from the Request Object.
      • Find the corresponding module and action to be called.
      • If the corresponding module and action are found, the dispatching process ends.
      • If no module is found for the given Request, the default action is set and the dispatching process ends.

      Let’s try to understand this using a simple example in OpenCart. To create a new user from the front-end, one needs to register with the site using http://www.youropencartstore.com/index.php?route=account/register. Let’s summarize the steps taken by OpenCart to render the requested page.

      • First, it checks the presence of the “route” query string variable, otherwise it’ll set the “common/home” as a default “route” of the page.
      • In our case, it’s present, so it’ll set up the required variables and trigger the dispatch process.
      • At the beginning of the dispatch process, it’ll run some of the “preAction” actions which are used to perform common tasks. We’ll discuss the “preAction” stuff in the later part of this article.
      • Finally, it’ll check whether there’s a controller file available for the current “route” variable, and if there’s one it’ll be called to fetch the response.
      • If there’s no controller file available for the requested “route” variable, it’ll execute the “error/not_found” action, which shows the “page not found” message to the user.

      So that’s a top-level view of how OpenCart goes through the requested URL and returns the response. In the next section, we’ll go deeper and see how exactly it does so.

      Go Through the Flow

      Go ahead and open the index.php file in the document root of OpenCart. There is a lot happening in that file, but don’t get overwhelmed, as most of it is just the setup of objects used throughout the framework.

      Let’s straight away pull in the snippet of our interest from that file.

      As with most other frameworks, OpenCart also relies on the front-controller pattern so that there’s a common entry point for all the requests in the application.

      First, we’re creating an instance of the front controller and assigning it to the $controller variable. Immediately next to that, we’re calling the addPreAction method to add a couple of actions.

      Now, that brings another topic on the table: what is a “preAction”? In simple terms, a preAction is an action which will be executed before the requested action on any page. For example, when the user clicks on any page, you want to check whether the site is in maintenance mode or not before the actual response is returned. In that case, you could use a preAction so that user will be redirected to the maintenance page if it’s on.

      Also, we’re adding common/seo_url as a preAction as well, since in the case of an SEO-enabled site we want to fetch the corresponding route variables before actual dispatching starts.

      Let’s move on to the next important snippet.

      It checks the presence of the “route” query string variable, and if it’s there we’ll create an instance of the Action class by passing the current “route” value as a constructor argument. If it’s not present, we’ll do the same with the home page route URI—common/home.

      With our $action variable set with the proper value, let’s move on to the next snippet.

      Finally, we’re calling the dispatch method of the front controller class. Go ahead and open system/engine/front.php and find the following snippet.

      This is the method where all the magic happens! First, it executes all the “preActions” as discussed earlier. Further, in the while loop it’ll try to execute our current $action, passed as an argument of the execute method.

      Let’s follow the definition of the execute method in the same file.

      On the very first line, the execute method of the Action class is called. Don’t confuse it with the execute method of the Front controller class. Open the file system/engine/action.php and here it is.

      The important thing to note here is that the Action class already sets up the required variables in the constructor itself when the action object is instantiated in index.php. It sets up the file, class and method properties, which will be used in the execute method. To keep things less complicated, we’ll only discuss the execute method, although I would recommend that you go through the constructor of the Action class.

      Back to our execute method of the Action class, it checks the presence of the file ($this->file) associated with the current route. If everything is fine, it includes that file and calls the corresponding method ($this->method) of that controller class using the call_user_func function and returns the response.

      If the associated file is not available, it’ll return false. Now, let’s get back to the snippet from the execute method of the Front controller class. Be patient, we’re almost there!

      Once the execute method of the Action class completes the process, it returns the result and it’s assigned to the $result variable. Now, there are three different possibilities with the value stored in $result. Let’s examine each one.

      If everything went fine, we’ll have HTML output in the $result variable, so the $action variable is set to false and the process ends. It’s the last else case.

      Recall that we returned false if the corresponding controller file was not found in the execute method of the Action class. In that case, the $action variable will be set to $this->error (error/not_found Action), and “page not found” will be shown to the user.

      And finally, if we find that the $result is an object itself, we’ll set it to the $action variable. Yes, that’s weird: why on earth would the controller method return another Action object, when it’s supposed to return the HTML output for requested page? But that’s just one of the ways the controller redirects users to some other URL.

      Let’s quickly open the catalog/controller/common/maintenance.php file and see it in action. In the index method, it returns the Action object if certain conditions are true.

      So, as you can see, it returns the Action object to redirect the user to the common/maintenance/info URL. Of course, there’s a code in the dispatch method of the front controller class to handle this behavior. Recall the snippet from that method—I promise it’s the last snippet of this tutorial.

      So it’s a while loop, and it runs until it finds the $action variable set to false! More specifically, it’ll end the loop when we have useful output for our user.

      So that’s the end of the journey. I hope that it was not as complicated as it seemed to be at first glance.


      Today, we’ve gone through an important aspect of the OpenCart framework—the dispatching process. We understood the basics of dispatching and went through the complete flow to understand how it works.

      If you're looking for additional OpenCart tools, utilities, extensions, and so on that you can leverage in your own projects or for your own education, don't forget to see what we have available in the marketplace.

      For any queries, don’t hesitate to leave your comments. Also, Twitter is another option for contacting me, and I respond quickly.


      Leave a comment › Posted in: Daily

    1. Create a Find and Replace Plugin in jQuery

      If you have ever used jQuery, there is a pretty good chance that you also have used at least one of its countless plugins. Just think about something useful that you would like to do in jQuery, and I am almost certain that a plugin exists to do exactly that.

      Sometimes, when a plugin does not exist, you might have to create one all by yourself. It is not as hard as it sounds. In this tutorial, I will go over some general rules that you need to follow when creating plugins, and later we will create our own find and replace plugin.

      The Basics

      There are a few things that you need to be aware of when developing plugins. In this section, I will cover all of them one by one. Consider the following code snippet:

      First, you might have noticed that I am using this instead of $(this) in our plugin. This is because $.fn makes functionName part of the same jQuery object as the .addClass() method.

      Let me explain to make it clearer. Using $.fn always returns a jQuery object which contains all the methods that you use in jQuery. If you ever create your own methods, they will be part of this object as well. Since your function is now part of the jQuery object, you can use this in place of $(this).

      Second, you should try to make your plugin chainable. This is one of the many important features of jQuery that developers use all the time. To make a method chainable, it should return the original jQuery object. This can be achieved by just appending return as I did in the code above.

      Finally, you should protect the $ alias and make sure that using your plugin with other JavaScript code does not result in any conflict. All you need to do to make sure that this does not happen is just wrap the function in an immediately invoked function expression just like the code above.

      Creating the Plugin

      With the basics out of our way, we can focus on our main task, i.e., creating the plugin. We begin with a primitive version, where we will just replace the original text with some predefined text. Here is the code to do it:

      I am using regex to replace all the occurrences of Lorem Ipsum with Replacement. To be honest, in its current form, our plugin is totally useless. The users should at least have the option to find a piece of text and then replace it with some other text of their choice.

      At this point, the ability to accept various options comes to our rescue. We will provide users with three options: some text to find, some text to replace, and the ability to set the background color of the replaced text. You can also use this opportunity to set default values for various parameters, in case the users knowingly or unknowingly did not set the value themselves. Here is the code to do it:

      I have set findText to null. For replaceText, an empty string makes most sense because if a user did not set a replace value, maybe he or she just wanted it to be empty. The most appropriate value for backgroundColor would be the background color of the webpage, which in most cases is white. You can also put some checks in place to notify users if they forgot to provide the values.

      In order to use these values, we will have to change our original plugin code as well. Our plugin code should now be:

      The text that needs to be found can be accessed using setting.findText. This is stored in a variable for later use. I am using the RegExp constructor to create a regular expression object. This can be used to dynamically replace regular expressions.

      Using the global modifier makes sure that all the occurrences of StringToFind are replaced. I have enclosed the replacing text in a span element with inline styling. Finally, I update the HTML of the element that called our findReplace function.

      This demo shows our plugin in action.

      Making Improvements

      Our nice little plugin works perfectly. You can make it even more awesome with a few modifications. We have already provided the option to change the background color of the replaced elements.

      However, if users decide to change the font size, add some padding or make some other changes, they can't. It is also impractical to provide all these options. What we are going to do instead is give the users the ability to add a class of their choice to the replaced elements. This way they can make changes in the CSS themselves, and our plugin will be lightweight as well.

      All you have to do is change the backgroundColor option in our earlier version to customClass in the corresponding places.

      Some users of your plugin might be interested in calling a callback function after the plugin has done its work. This is fairly easy to achieve. You just need to add a completeCallback option to get the callback function from users. Then the code below will take care of the rest:

      In the code snippet above, the .isFunction method checks if the user has actually passed a function before we execute it. To call custom functions, you need to call the function in the following manner:

      Here is a screenshot of the plugin in action:

      I am posting the complete code of our plugin to make sure there is not any mix-up:

      Our final demo.

      Final Thoughts

      Creating a plugin in jQuery is not hard at all. You just have to follow a few basic rules and you are good to go.

      If you're interested in some other plugins we have available as well as what they can do for you in any of your existing projects, then please check out the jQuery work we have in the marketplace.

      One thing that I would recommend is to make the plugin as flexible as possible and keep its size as small as possible. No one is going to use a 15k plugin which only finds and replaces text.

      Finally, I hope you liked this tutorial, and if you have any questions regarding the tutorial, let me know in the comments.


      Leave a comment › Posted in: Daily

  • Page 1 of 94 pages  1 2 3 >  Last ›
  • Browse the Blog