4elements, Amsterdam, Holland

  1. Try New Relic and Get 75% Off a Tuts+ Subscription

    Do you want to get actionable, real-time insights from the billions of metrics your software is producing? Do you also want to get 75% off a Tuts+ yearly subscription?

    If so, you're in luck. Until 31 March, New Relic is offering you the opportunity to deploy for free, and get a 75% discount on a one-year subscription to Tuts+ at the same time.

    We're confident about recommending New Relic, because we use their products ourselves here at Envato (our parent company). Watch this video for an example of how we use New Relic Insights:

    To find out more about how New Relic works and get started with using it, follow these simple steps. There's a Tuts+ tutorial to help you with each one:

    1. The Basics in 30 Minutes

    It's simple to deploy New Relic and get started with basic monitoring. In this tutorial, you'll learn how to set up a simple Rails app and hook up New Relic to start monitoring its performance.

    New Relic welcome page

    2. Learn How to Monitor WordPress Performance

    You can use New Relic's free server monitoring to see what's happening within your WordPress installation and your PHP stack. In our tutorial you'll learn how to use New Relic to evaluate WordPress performance in three key ways:

    1. Monitoring MySQL performance. Poorly written themes or plugins can definitely negatively affect site performance. And, as your site grows, this could get worse.
    2. Apdex gives you a quantitative measurement of the usability experiences of your site based on response time.
    3. Monitoring the performance of third party plugins and APIs. WordPress offers a powerful array of plugins and services to add to your blog, but some can kill performance. New Relic can help you identify problem areas.
    New Relic dashboard in WordPress

    3. Set Up Front-End Monitoring

    Learn how to use New Relic Browser to monitor full page life cycle data—well beyond the initial page load. For each end user page load, New Relic captures:

    • Time spent in the front end (browser)
    • Code and events executed in the browser (JavaScript, Ajax, and end-user interactions)
    • Time spent in the back end (network and web app)
    • Geographic origin
    • Browser type and version, and operating system

    You can view the data globally across all users and see it sliced and diced by webpage, browser, user session, and location.

    New Relic Browser Real Time Application Monitoring

    4. Go Mobile

    If you're interested in mobile development, you'll want to integrate New Relic in an iOS application. Our tutorial will show you how easy it is to set up New Relic, and what it can do for your iOS application in terms of performance and making sure your users get the best possible experience using your product.

    New Relic Mobile Monitoring

    If you're more interested in Android development, you can also have a look at Using New Relic to Monitor Your Android App.

    5. Use New Relic to Monitor Your Servers

    In Using New Relic to Monitor Your Servers, we look at how to use New Relic to monitor your infrastructure (i.e. your production server) and why you'd want to.

    New Relic Server Dashboard

    We've got even more New Relic tutorials for you in this series. If you're interested in trying it out, deploy for free before 31 March 2015 and get 75% off a Tuts+ yearly subscription. 

     

    0 Comments

    Leave a comment › Posted in: Daily

    1. When You’re Hacked in WordPress: Dealing With a Hacked WordPress Site

      One of the worst things that can happen to your website just happened: It's been hacked. Somebody broke into your computer and got passwords, or your passwords were weak, or somebody exploited a security vulnerability caused by WordPress or your hosting provider, or something else happened that let a hacker hack your website...

      What do we do now? It's not the time to feel sorry for yourself, it's time to take action and bring back your website. Let's go!

      How Do WordPress Websites Get Hacked?

      It's a good question, and it's got more than one answer, but none of those answers is "because WordPress isn't safe". 

      Believe me when I say this: WordPress is one of the most secure platforms on the internet. You can't expect 100% security from any system (even your brain isn't 100% secure—scientists are now able to read or even overwrite thoughts on your brain!). So nobody can talk about total protection, but be sure that WordPress is a lot safer than regular platforms. Why? Because it has a huge developer community that can patch zero-day vulnerabilities on day zero. But, again, you shouldn't even trust yourself when it comes to safety and security.

      So, let's answer the question: Why do WordPress websites get hacked? As I said, there is more than one answer:

      Because of a security flaw on your server: You probably know that WordPress isn't the only software that runs on your server to generate your web pages. Your server has an operating system which runs important software like PHP, MySQL, a hosting control panel like cPanel, and anything that's necessary to allow software like WordPress to be run. Even the tiniest security flaw in this system can allow a hacker to bring down your website.

      Because of a security flaw on your computer or mobile device: Remember the times when you could connect to a computer with Windows XP through a port and without any intervention, even evading those awful "firewalls"? It's not as horrible as it's used to be, but that doesn't mean that your computer, smartphone or tablet is completely safe—again, nothing is 100% safe. More and more viruses and trojans come out every day, targeting iOS, Android, Windows, Linux, OS X and every other operating system. Not only operating systems, but also regular software can cause security problems as well. It doesn't stop there either: You can even reveal your passwords to hackers through unencrypted Wi-Fi connections. Seriously, an evil mind has many options to get to your passwords.

      Because of a security flaw on you: You know what I learned in over 15 years? You can take every single precaution on your systems, but if you don't have common sense, you will fail on security. It seems the easiest, but it's actually the hardest thing to do if you want better security: You have to be careful.

      Or because of a security flaw on WordPress: Yeah, there's that, too. It happens, a zero-day vulnerability in the core of WordPress could emerge tomorrow and some 15-year-old script kiddie could go on a "hacking spree" and your website could get hacked.

      What to Do When You're Hacked

      So, what happens when what's done is done? It's time to act to get your website back, of course!

      Shut It Down NOW!

      Yes, before everything, take down your website immediately. It's going to be a minor inconvenience if your visitors can't reach your website, but it's going to be a disappointment if your visitors see that your website is hacked. If WordPress is still running, take your website into maintenance mode. If the damage is bigger, just shut down the website and sort things out via your server's control panel.

      Contact Your Hosting Provider for Details

      If you don't know much about server management, ask your hosting provider about this attack: What really happened? What was the main cause—was it WordPress, or was it a PHP flaw that was exploited? If you find out that it's your theme or one of the plugins you installed, delete the file(s) with the vulnerability before anything else.

      And save the log files, in case you're going to take legal action.

      Review the Latest Backups, and Restore the Healthiest

      In times like this, you understand the importance of backing up your files and databases. If you have backups, review them and restore the healthiest one. It's a good idea to restore the last backup, but if you're not sure when the attack took place, you might need to download a bunch of backups and look inside each of them.

      Find Out What Caused It and Take Action

      When my website got hacked for the first time, my hosting provider told me that it was a plugin file that allowed the hacker to run a "shell script" in my server. Luckily, the hacker was merciful and didn't delete anything on my server (though even if he did, I had backups)—he just put an index.html file in the root folder.

      As you can guess, I immediately got rid of the plugin and contacted its author to inform him about the situation. If you find out that it was a theme or plugin vulnerability, you should contact the person who made it and tell them that it caused a hacker attack. If it was a core vulnerability and it's unknown to the community, make sure we (the community) know about this. If you can patch the vulnerability, that's another good thing.

      Fix and Double-Check Everything and Go Live Again

      If you don't panic when things like this happen, it will be a lot easier to overcome and fix everything.

      • Take a deep breath.
      • Shut down the server.
      • Review the backups.
      • Restore the latest healthy backup.
      • Get information (and logs) from the server admin.
      • Fix what caused the problem and eliminate the vulnerability.
      • Double-check to make sure everything is all right.
      • Go live again.

      Incidents like these teach us to be more careful, so don't read the situation just in a bad way. What's done is done. You (hopefully) succeeded in making things right, and you're ready to move on with more wisdom.

      Wrapping Up

      It's an unpleasant experience, I know. But things like this happen all the time, and trying to avoid thinking about it is the worst thing to do. You shouldn't refrain from thinking about the worst case scenario, and you shouldn't refrain from taking precautions.

      What did you do when your website got hacked? Tell us what you experienced or what you think in the comments section below. And if you liked the article, don't forget to share it with your friends!

      Stay tuned for the next part of this series!

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. Creating a Web App From Scratch Using AngularJS and Firebase: Part 2

      In the first part of this series, we saw how to get started with creating an application using AngularJS and Firebase. We created our Sign In page and implemented the sign-in functionality with Firebase as the back end.

      In this tutorial, we'll take this series to the next level. We'll create and set up the sign-up page and see how to do form validations in AngularJS. 

      Getting Started

      Let's start by cloning the first part of the tutorial from GitHub.

      Once the code is fetched, navigate to the project directory and install the required dependencies.

      Once all dependencies are installed, start the server.

      Point your browser to http://localhost:8000/app/#/home and you should have the app running.

      Creating a Sign-Up Screen

      We'll start by creating a page for the guest users to sign up. Navigate to AngularJS_Firebase_Part1/app and create a folder called register. Inside the register folder, create register.html and register.js files. Here is how register.html looks: 

      As seen in the above HTML code, we have used Bootstrap for our HTML design.

      Inside register.js, we'll declare the routes for the application to access the register view. $routeProvider has a method called when, which we'll use to create a route for our register view. When defining a new route, we'll set a templateUrl which would be rendered in the index.html. Along with that, we'll also set a controllerfor the newly created $scope of the register view. A controller is a logic which controls a particular view. Here's how it should look:

      Now open up app.js and include the register module myApp.register in the app.

      To display the sign-up page, we need to include register.js inside the main HTML template file of the app. Open up index.html and include the following:

      Restart the server and point your browser to http://localhost:8000/app/index.html#/register and you should see the sign-up screen:

      Sign-up screen for AngularJS  Firebase App

      Next, let's make the sign-up screen link to the sign-in screen. In home.html and register.html there is a sign up and sign in href respectively. We'll set both the href sources so that they are accessible from both the pages.

      In home.html:

      In the register.html:

      Form Validation in AngularJS

      When a user enters his or her email address and password on the registration screen, we need to validate a few things. First, the email id entered should have a valid email id format, and secondly the password entered should have a minimum length. 

      AngularJS provides FormController, which keeps track of every element inside a form. From the AngularJS docs:

      FormController keeps track of all its controls and nested forms as well as the state of them, such as being valid/invalid or dirty/pristine.

      FormController has a few properties like $pristine, $dirty, $invalid, $valid, etc. We'll see what these properties are, and we will be using some of these properties to implement form validation for our registration page.

      First, we need to modify our form HTML to add validation messages. In register.html modify the form HTML as shown.

      Save the changes, restart the server, and refresh the register page. You should see a page like this:

      AngularJS  Firebase App register page

      Now, as we can see in the above screen, the validation messages are visible. We need to show them only when the email and password are not valid.

      AngularJS provides a directive called ngShow to show HTML based on a certain expression. (An AngularJS directive is an extended HTML attribute provided by AngularJS to enhance the elements' capabilities.) So, we'll use ngShow to show the validation message when the input email has invalid data. But how do we know if the input email is invalid? Well, remember the FormController properties that we discussed earlier. FormController has a property called $invalid which is True if a control is invalid. regForm.email.$invalid would be true if the email entered is not a valid one. So we'll use $invalid and ngShow to show the validation message. Modify the email message span as shown below:

      Save the changes, restart the server, and browse to the registration page. You'll see that the validation message for email id doesn't show any longer. Now, try to enter some data into the input email and the error message will pop up. Try entering a valid email address and the validation message will be gone. But the message for the password minimum length still shows up, initially. Let's fix it up.

      AngularJS provides another directive called ng-minlength to set the minimum length for any input control. We'll use that to set the minimum length for the password field and then use ngShow to show/hide the validation message. Modify the password field to include the ng-minlength directive as shown:

      Next modify the validation message span for the password field as shown:

      So, if the minimum length of the password field is not as per the minimum length set in the password input field, then regForm.password.$error.minlength will be set to "true" and the validation message will be shown.

      Save all the changes, restart the server, and browse to the registration page. Try entering a value for password, and the validation message will show up until the password length is 8.

      Now, in order to highlight the invalid input elements, we can use some styles. Using an AngularJS directive called ngClass we can dynamically highlight the faulty input elements using the $invalid property. So add the ngClass directive to the parent div of the email and password elements. 

      Save the changes, restart the server, and try browsing to the registration page. Now, on invalid entries, the validation messages show up as below:

      Validation messages showing on registration page

      Now, as you can see in the above screen, on validation errors the Register button is enabled. Let's make it disabled unless the email and password entered are valid. AngularJS provides a directive called ngDisabled which helps to disable elements based on an expression. If email and password are validated then the user.email and user.password models will be set. So, we'll use these two objects to enable/disable the register button using ngDisabled. Modify the register button HTML as shown:

      As you can see, ng-disabled will be true if user.email or user.password is not false, which will be the case only when the data is invalid.

      Save all the changes, restart the server, and refresh the registration page. As you'll notice, the Register button is disabled and it will remain so, until a valid email address and password are entered.

      Registration screen with Register button disabled

      Validating Sign-In Screen

      Implementing validation on the sign-in screen is quite similar to the way we did it for the sign-up screen. I would suggest that you implement validation yourself for the sign-in screen as an exercise. In case you get stuck, have a look at the modified HTML code for the sign in form in home.html as shown below:

      Wrapping It Up

      In this part of the tutorial, we created the sign-up page and set up the routes for it. We also saw how to implement validations using AngularJS for the sign-up page.

      In the next part, we'll focus on implementing the sign-up functionality and a few other features. Source code from the above tutorial is available on GitHub.

      Do let us know your thoughts in the comments below!

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. WordPressium: Creating a Medium-like Experience

      Final product image
      What You'll Be Creating

      If you've visited articles on Medium, you know its clean, readable lines. The articles load fast and read easily on phones, tablets and desktops. Here's a sample from one of my Medium articles, Shining Light on Internet Rage:

      Mediums Clean Readable Lines - Shining Light on Internet Rage

      In this tutorial, I'll guide you through selecting themes and plugins to turn your WordPress site into a Medium-like experience. We'll focus on functionality as well. I'll walk you through plugins that show reading time, and how you can let the user select text and comment inline or share it to Twitter.

      Here's an example of Medium's presentation of expected reading times:

      Medium Reading Time

      Here's an example of Medium's select and comment and share feature:

      Medium Select and Comment or Tweet

      Here's an example of inline comments in another of my Medium articles:

      Medium Inline Comments

      Starting From Scratch

      If you'd like to build an entirely new site, you can follow my visual guide to WordPress installation here. You may also be interested in the Ghost open source blogging platform which I profiled earlier this year on Tuts+. For this example, I'm actually going to migrate the Ghost site I built in the earlier piece to a Medium-like WordPress experience.

      Here's what my earlier Ghost home page turned out to look like using a Medium-like theme called Ghostium:

      Breakupsio Site Using Ghost - Previous Tuts Tutorial

      If you want to adapt your existing site, just follow along as we explore Medium-like themes and plugins.

      Themes That Resemble Medium

      For this tutorial, I'm going to install the Readme "Readable WordPress Theme" available at Theme Forest, a Tuts+ network company, for $48 (it was my choice, not Tuts+).

      Purchase Readme at ThemeForest

      If you're willing to pay for a theme, you might also want to check out these three:

      There's also a variety of great free Medium-inspired WordPress themes. Here are a few excellent roundups:

      Of these, you might begin by checking out Fastr by Kanishk Kunal. He hosts a demo here. Here's a screenshot of Fastr:

      Fastr - a free open source WordPress theme like Mediumcom

      If you find a free theme that you like, please post your experience in the comment thread below for other readers to benefit from.

      Installing and Configuring Readme

      You can purchase the Readme theme at ThemeForest, and then download the WordPress .zip archive from the site.

      Visit your WordPress dashboard, and click Appearance > Themes > Add New > Upload.

      Upload the Readme theme to your WordPress site

      As with any WordPress theme, there's a lot of site-specific configuration and theme-specific user interface to work with. As these go, Readme is relatively clean. It has a simple tabbed dialog for most settings:

      Readme Theme Options Tabbed Dialog

      It also offers a variety of nice layouts, like its Masonry option:

      Readme Masonry Layout

      You can check out how I configured my finished site at breakups.io. This is my cover layout:

      Breakupsio home page with readme theme

      Here's a story page:

      Breakupsio story page with readme theme

      I like the way it turned out. If I had more content, I might have opted for the Masonry layout.

      Medium-Like Plugins

      Now, let's jump into Medium-like plugins: Select Text and Share, Reading Time, and Inline Comments.

      Select Text and Share

      The free Selection Sharer plugin by Hans van Gent lets you add text selection and email and Twitter sharing to your site. It's easy to install and worked perfectly for me out of the box.

      WordPress Plugin Selection Sharer

      Here's what it looks like on my site when you select text and share it. You can also give it a try:

      Selection Sharer live at Breakupsio

      I was impressed with how well this worked without any configuration. An alternative is the free Quotable plugin which offers select and tweet.

      I do worry a bit about the discoverability of this feature, but any time someone goes to copy text, they'll discover it.

      Reading Time

      As you can see from the images above, the Readme theme provides built-in reading time. However, there are plugin options if you choose another theme.

      The free Reading Time plugin displays time to read and a progress bar in the post.

      WordPress Plugin Reading Time

      There are also some open Jquery libraries that do the same thing if you'd like to integrate your own. e.g. Michael Lynch's Reading Time.

      Inline Comments

      Sorry to disappoint, but it turns out that you can't easily do everything Medium does. Inline comments are difficult to recreate, as they rely on a lot of theme support. WP Tavern explored this topic more fully. They settled on the free Inline Comments plugin. But neither of the solutions they looked at provided a great user experience. 

      In the end, I chose to remain with my favorite, the free Disqus plugin, though it doesn't offer inline capability at this time.

      Suggested Reads

      Now, let's take a step beyond Medium and add something cool that The New York Times does well: a suggested next read plugin. The free UpPrev plugin displays a flyover promo to the previous, next or random post on your site:

      WordPress Plugin upPrev

      Since personal blogs often have a high bounce rate, e.g. readers click away after reading one article, upPrev can help keep people on the site. Even though I use widgets for recent and popular items, I like the concept of using an animated flyover to promote a specific piece.

      UpPrev has a simple plugin settings dialog and worked easily for me:

      UpPrev Plugin Appearance Settings

      You can choose how upPrev selects content to present, for example, previous, random or related, with the Yet Another Related Posts (YARPP) plugin:

      UpPrev Plugin Content Settings

      Here's what it looks like as you scroll down to the bottom of a page on breakups.io:

      UpPrev Flyover on Breakupsio Story Page

      In Closing

      I hope you've enjoyed this post. Medium and WordPress are both exciting platforms and it's great when we can take things we like from one and implement them in another. It's also interesting when you find things such as inline comments that are still hard to do in WordPress. Medium does a lot well and the WordPress team has its work cut out for it.

      Please feel free to post corrections, questions or comments below. I try to participate in the discussions. I'd be especially interested in your experience with themes and/or alternate plugins. You can also reach me on Twitter @reifman or email me directly. If you enjoyed this tutorial, please visit my instructor page to see my collections of other tutorials.

      Related Links

       

      0 Comments

      Leave a comment › Posted in: Daily

    1. Create a License Controlled Plugin and Theme Update System, Part 3: Doing the Update

      In the first two tutorials in the series, we have built a WordPress plugin for managing software licenses. In part 1, we built the administration tools needed for adding products and licenses, and in part 2, we created an API that plugins and themes can use to access the license and product information. 

      Now, it's time to tie it all together and make a WordPress theme and a WordPress plugin use the license server to check for updates. To do this, we will create a class that can be dropped into any WordPress plugin or theme's codebase to make the theme or plugin use a WordPress site running our WP License Manager plugin to check for updates. 

      In this tutorial, you will learn about the following topics: 

      • How to hook into the WordPress theme update system.
      • How to hook into the WordPress plugin update system (yes, the two are separate—but similar—and need to be addressed one by one).
      • How to call an external API from WordPress.

      The functionality we will create in this tutorial requires us to dig deeper into how WordPress works under its hood, which makes this tutorial a bit more advanced than the first two in the series. However, we will go through every step thoroughly, so if you have been following the tutorial this far, there should be no problem finishing this one.

      Just like in the previous parts, you can follow the tutorial writing your own code as we go, or download the final class and use it as a reference.

      Let's get started.

      1. Setting Up the Testing Environment

      To build the license manager client class and to test it, you need a testing environment with the following components:

      • A WordPress server running the WP License Manager plugin created in parts 1 and 2 of the tutorial series. We'll call it the license server.
      • A WordPress server for running the plugin and theme to be updated. We'll call it the test server.
      • A theme for testing the update system.
      • A plugin for testing the update system.

      You can use one of your existing themes and plugins for testing, or create a placeholder with no real content or functionality other than the updates, following the instructions below.

      Step 1: Create a WordPress Theme for Testing

      In wp-content/themes, create a new directory called hello-world-theme (for example).

      In that directory, add a style.css file with the standard theme heading. This is needed for WordPress to find the theme. 

      Add an index.php file. It can be empty, or you can use the following placeholder HTML:

      For testing the license manager client class, we still need a functions.php file. This is where you'll initialize the class we will create in this tutorial—for now, you can leave the file empty.

      With this minimum setup, WordPress will accept the theme without errors. Activate it now.

      Once you have decided on the theme to use, add a product to represent it on the license server. Call the new product "Hello World Theme" and set its version number to something higher than the 0.1 we defined in the theme header above. 

      Mark down the "post slug" part of the product's permalink (hello-world-theme) as it will be used as the product's ID when talking to the license manager API. 

      Step 2: Create a WordPress Plugin for Testing

      Creating an empty test plugin is even faster than creating a test theme. All you need is a PHP file with a bare-bones plugin header. 

      In wp-content/plugins, create a directory called hello-world-plugin and inside it, a file, hello-world.php, with the following content:

      The plugin is now ready so go ahead and activate it.

      Just like you did for the theme, create a product for this plugin on the license manager server. Call the product "Hello World Plugin"—this should give you the id (slug) hello-world-plugin—and set its version number to something higher than the 0.1 defined in the plugin header.

      Now that you have set up your testing environment and have a plugin and a theme ready for testing, it's time to get started with the license manager client class itself. 

      2. Setting Up the License Manager Client Class

      Let's start creating the License Manager Client class by building the common functionality that is shared by both themes and plugins. As we need to test the code in some context, we'll start with the theme and add plugin specific stuff once the theme updates are working.

      Step 1: Create the License Manager Client Class and Initialize It

      In your theme directory (hello-world-theme), add a new class called Wp_License_Manager_Client (using the file name class-wp-license-manager-client.php). This class will hold all the code related to checking the licenses and handling the theme's updates.

      As this class file is meant to be included in any number of WordPress themes and plugins, surround it with a class_exists check. This way, if there are many installed plugins and themes that use this class, they won't break the system by trying to create the class many times.

      Let's continue with some initialization before moving to actual functionality.

      First, add some variables that will be initialized in the class's constructor. The code comments explain the variables, and I will mention them again when we use them in the code.

      Then, add a constructor for setting these instance variables:

      To better understand what these parameters are used for, and to link the class to your theme, open your theme's functions.php file and create an instance of the Wp_License_Manager_Client class:

      Let's go through the code line by line:

      Line 2: Include the license manager class we are about to create.

      Line 4: The license manager client is only needed in admin screens, so in order to not create unnecessary objects, check for whether the user is viewing one of WordPress's admin screens or not.

      Lines 5–9: Create the Wp_License_Manager_Client instance using the following parameter values:

      • hello-world-theme: The slug (id) of the product (theme) on the license server.
      • Hello World Theme: The name of the theme. It will be used for settings screens and other situations where we need to refer to the product by its name.
      • hello-world-text: The text domain your theme uses for localization. Using the same text domain for the license management screens makes it easier for localizers to translate the entire theme at once.
      • http://<URL_TO_LICENSE_SERVER>/api/license-manager/v1: This is the URL to the API we created in the previous part of the tutorial series. Replace URL_TO_LICENSE_SERVER with the URL to the WordPress site on which you installed the WP License Manager plugin.

      The remaining two parameters in the constructor are only needed when the class is used with a plugin, so we'll leave them to their default values for now and come back to them later in the tutorial when we move to plugin updates.

      Step 2: Create a Settings Screen for Entering the License Key

      The first thing a user needs to be able to use the license manager API is a valid license key—and a way to enter it into the theme. 

      For this, we will now create a new options screen. 

      As we have already created a number of similar screens in parts 1 and 2 of the tutorial series, I will go through the code only briefly.

      Notice that every piece of functionality that goes into the license manager client class should be activated by attaching one of the class's functions to a WordPress action or filter. This way, everything stays clean and easy to manage. To keep things as simple as possible for the theme developer who will be using this class, I have put all the initialization in the class's constructor.

      Add the settings screen related hooks to the constructor, right below the initialization code we added in the previous step:

      Then, create the two functions mentioned, add_license_settings_page and add_license_settings_fields. Notice how we use the $product_name and $text_domain variables from the constructor when defining the title for the settings page.

      Both functions created above define a number of callbacks for rendering the settings page and the settings fields. Add the callback functions:

      To minimize the risk of a typo when typing the settings field's name, I have created a helper function, get_settings_field_name, that is used throughout the code snippets above. Another helper function, get_settings_page_slug, is used for defining the path to the settings screen.

      Add those two function at the end of the class to make the code run without errors:

      The functions use the $product_id passed in the constructor to create the settings field and the settings page slug. This way, every theme or plugin using the class will get their own settings and there will be no conflicts.

      The settings page is now ready and looks like this:

      License settings screen

      Step 3: Add a Reminder For the User

      It's easy for a user to miss a setting like this and end up wondering why the theme isn't getting updates. That's why it's a good idea to create a reminder that will be shown in the admin, until the user configures the theme and enters the license key.

      It's time for another WordPress action. The admin_notices action is used for all WordPress notifications and errors, therefore fitting our purposes perfectly.

      In the constructor, right below the two actions we added earlier, add:

      Then, add the function, show_admin_notices:

      The function first checks if the options have been set. If the options item doesn't exist or any of the two required fields are empty, it shows the notice and a link to the theme's license settings page where the user can complete the setup. The class, update-nag, defines the look of the notification.

      Here's what the "nag" looks like, appearing at the top of the admin dashboard:

      Reminder for updating the license settings

      Now, to make the nag go away, let's put in the license information. 

      First, visit the license server's WordPress admin area and create a new license for the test theme (Hello World Theme). After you have clicked on Add License, you will see the list of licenses. 

      Copy the license key that was generated by the license manager plugin. Then, go back to your test site and configure the theme's license settings by entering your email address and the license key copied from the license manager server.

      Your nag is gone and your theme settings are in place for testing the functionality we will create next.

      3. Communicating With the License Manager API

      With the basic framework in place, let's look at communicating with our license manager API.

      Step 1: Add Functions for Calling the API

      First, add a function for calling the License Manager API. The function takes two parameters: the API method or action to call on the license manager server, and an array with parameters for the action:

      Line 13: Create the URL to call, using the base URL passed as a constructor parameter ($api_endpoint), and the action passed in as a parameter ($method).

      Line 16: Use the PHP function http_build_query to create a URL encoded parameter string and append it to the GET request.

      Line 19: Use WordPress's built-in HTTP function wp_remote_get to send a GET request to the URL generated on the previous lines.

      Lines 20–22: Do some basic error handling to see if an error occurred. We'll add the is_api_error function next.

      Lines 24–25: Read the response and parse it from a JSON encoded string to an array containing the data received from the license server. 

      Line 27: Return the response.

      Next, add the error checking function. The handling is very rough and doesn't go into any detail about what went wrong—just enough to know if there was an error or not:

      Step 2: Add Functions for Retrieving License and Update Information

      Now that we have created the function for talking with the API, we can use it to call the license server to get some information about the current theme or plugin.

      Add the following function for calling the info action:

      Line 8: Retrieve the license manager client's options.

      Lines 9–12: Verify that the license key and email options have been set. If we don't have them, calling the API will be a waste of time—we already know that the request will fail.

      Lines 14–21: Call the license manager API's info action with the following parameters:

      • p: The product ID defined in the Wp_License_Manager_Client constructor.
      • e: The license owner's email address, read from settings.
      • l: The license key, read from settings.

      Line 23: Return the license data. The data will include the following fields:

      • name: The name of the product (theme or plugin).
      • description: A description of the product.
      • version: Current version available on the server.
      • package_url: The download URL for the product. This is a URL to the get API action on the license manager server.
      • last_updated: When the product has been updated.
      • description_url: A URL to a page that can be used for showing more information about the product.
      • tested: The highest WordPress version on which the product has been tested (needed only for plugins).
      • banner_low: Low resolution (regular) version of the product banner image (only needed for plugins).
      • banner_high: High resolution (retina) version of the product banner image (only needed for plugins).

      Next, let's use the function to check if there is an update waiting to be downloaded. Add the following function:

      Line 8: Request product information using the get_license_info function you just created.

      Lines 9–11: If an error occurred while making the API call, return false. It would also be a good idea to show the error to the user—to keep things simple, I left that functionality out for now.

      Line 13: Use PHP's version_compare to see if the version number received from the server is higher than the local version number.

      Line 14: If an update is available, return the license data. By returning the data right away, we save ourselves the need to make an extra API call to get the data again.

      To complete this function, we still need to implement the function for retrieving the local version number, used on line 13. Plugin and theme data are accessed a little differently, so the function will have separate implementations for both:

      Line 2: Get the current theme's data.

      Line 3: Read the current version and return it.

      Line 5: Plugin data is read using a different function, get_plugin_data, that uses the plugin's main file name as the identifier. We will set the variable, $this->plugin_file, later when integrating to our test plugin.

      Line 6: Return the plugin's version number.

      Add the function is_theme for checking for the type of the product inside which we are operating:

      We have now created the functions needed for connecting to the license server and checking if there is a newer version available. Next, it's time for the really interesting part: tying this to the WordPress update functionality.

      4. How WordPress Checks for Updates

      The framework for building our theme and plugin update system is in place. It's time to start digging deeper into the WordPress update functionality. 

      At the admin_init action (and a number of other, more specific, actions), if enough time has passed since the last update check, WordPress compares its plugins and themes against the versions hosted in the WordPress.org Plugin and Theme directories to see if new versions have been released. 

      After the check, WordPress stores the results into a site transient: update_themes for themes and update_plugins for plugins.

      Then, when you visit the Updates page (or the Themes and Plugins pages), WordPress checks these transients to see and mark themes and plugins that have updates available.

      When you look at the code for this functionality (which you can find in wp-includes/update.php) you can see that it has been designed to work with the official directories and nothing else: there are no hooks for specifying the server to check against or for sniffing the requests before they are sent. 

      But that hasn't stopped plugin and theme developers from using their own license servers—and it's not going to stop us either.

      The solution lies in the way the results of the update check are saved. I mentioned above that the results of the update lookup are stored in a transient. And right at the beginning of the WordPress function set_site_transient, we find:

      This filter gives us access to the contents of the plugin and theme update data before it is saved, just in time to add our own data to it!

      5. Hooking Into WordPress Theme Updates

      Let's begin implementing our own update checking code, starting from themes.

      Step 1: Create a Filter to Hook Into the Theme Update Check 

      As we saw above, when WordPress has finished checking for theme updates from the WordPress.org theme directory, it stores the information about themes in need of an update in a transient called update_themes

      To check for our own updates and add the data into the transient before it is saved, we will hook a function of our own to the filter, pre_set_site_transient_update_themes. In this function, we will call the license server to check for this theme's updates, and then, if there is an update available, add the information in the transient.

      First, add the filter at the end of Wp_License_Manager_Client's constructor:

      Then, create the function, check_for_update:

      Lines 10–13$transient->checked is an array with all currently installed themes and their version numbers (theme stylesheet as key and version as value). If you were to check updates for multiple themes at once, you could use this array to collect the data and send it all to your license server. In this simple version, however, we just verify that the array isn't empty and move on.

      Lines 15–16: Check if there is an update available for this product (theme) on our license server, using the is_update_available function we created earlier. The function returns the product information if the version on the license server is higher than the installed one and false if there are no updates available.

      Line 18: Check if this is a theme or a plugin. At this point, we'll only focus on the theme updates, so I have left the else branch empty for now.

      Lines 20–21: Find the theme's "slug" to use it as a key for marking the current theme in need of update.

      Lines 23–27: Insert the information related to the theme update into the transient's $response array, using the theme's slug as key. 

      • new_version: Theme version on server.
      • package: The URL for downloading the theme package. As WordPress needs to be able to download the theme directly from this URL, we created the license manager to return a fully formed URL in the license information, including the user's email address and license key.
      • url: A URL for a page to show information about the theme. This parameter is used when clicking for more information on the Themes page.

      Line 33: Return the transient so that WordPress can save it—with our theme update information appended to it.

      And that's it! You have now built a complete update system for your self-hosted WordPress themes. Let's test the functionality and then move on to updating plugins.

      Step 2: Test the Theme Update

      Before moving on to updating plugins, let's test the functionality to see the update in action. 

      Updating the theme you are using for testing will overwrite the theme, so as the first thing, create a new zip file using its files. Then upload the zip file to Amazon S3 as we did in part 2 of the tutorial series.

      Next, log in to your license server and edit the Hello World Theme's product information, making sure it uses the zip file you just uploaded to Amazon S3 and that the product's version number is higher than the one of the theme installed locally.

      Edit product information

      Save the changes and head back to the test server to test the update.

      On the test server, click on Dashboard > Updates. WordPress will now perform the API calls to check if there are themes in need of an update. If nothing happens, it could be that the previous check has just taken place and WordPress is still waiting for the time limit in between version checks to pass. In that case, wait for a minute and click on Check Again to force the check.

      Now, you should see your theme in the list of themes that can be updated.

      Hello World Theme is in need of an update

      Next, try doing the update. If all goes well — as it should — you will see the following output. By default, the details are not show unless there is an error, so you'll have to click on Show Details to see what happened in the update.

      Notice how the theme is not downloaded from WordPress.org but rather your own license manager server.

      Theme update

      6. Hooking to WordPress Plugin Updates

      With the theme updates done and tested, we are almost finished with the tutorial. A big part of the code that will be needed for updating plugins is already in place. But there are some differences and additions needed, so let's get to work and add support for plugins to our license manager client class.

      Step 1: Include the Client Class in Your Plugin

      Copy the file class-wp-license-manager-client.php over to your test plugin's source folder. Then, in a suitable place in the plugin, place the following initialization code. 

      If you are using the empty test plugin, just drop it into the main plugin file, right below the plugin header. Remember to replace <URL_TO_LICENSE_SERVER> with your own server URL.

      Most of the parameters are the same as when initializing the class for use with a theme—with different, product specific values (e.g. hello-world-plugin instead of hello-world-theme).

      The last two parameters were not used when creating a theme, so let's take a look at them: 

      • $type (with value plugin) tells the Wp_License_Manager_Client instance to use the plugin specific functionality.
      • $plugin_file (last parameter) is used for retrieving the plugin's identifier for requesting plugin data such as its current version. When this initialization is done in the plugin's main class, we can use __FILE__.

      Step 2: Check for Plugin Updates

      Earlier in this tutorial, we hooked our Wp_License_Manager_Client class to look for changes in the update_themes transient by placing an add_filter row at the end of the constructor. Plugin updates will be handled similarly, only using the transient update_plugins instead of update_themes.

      So, right after the existing filter, add the plugin specific code (lines 1–3 were already present in the constructor, so I'm including them here to show where the new code should go):

      As you notice from the code above, the new filter uses the same function as the one we added for themes, check_for_update.

      Earlier, when we created the check_for_update function, we left one else branch empty, waiting to be filled with the code for handling plugin updates. Now, let's add content to that section. Here's the entire function with the plugin-related code added starting from line 27:

      Looking at the code, it's good to notice that while the function is the same, now we're handling a different transient, update_plugins rather than update_themes. One way this shows is that while the data in update_themes is stored as an array, update_plugins uses an object (line 30)!

      The calls to our License Manager API are the same as when using a theme, but the data stored to the transient is a little different—based on what WordPress expects to find in the transient.

      With this code in place, you can already test for updates in the same way we did with the theme (create a zip file, upload it to S3, edit product properties). Make sure the plugin's version number on the license server is higher than the installed one, and navigate to the test server's Updates page. An update for the Hello World Plugin should appear:

      update for the Hello World Plugin appears

      When you update the plugin, you will see that it is downloaded from your own server just like the theme. 

      But we are not quite done yet: If you look at the plugin information in the screen shot above, you'll notice that "Compatibility with WordPress 4.0.1" says "Unknown". Also, if you click on View version 0.2 details, an error message is shown.

      Let's fix this.

      Step 3: Provide Plugin Information

      To collect the information it shows about plugins, WordPress uses a function called plugins_api. By default, the function calls the WordPress.org API, just like the version checks. However, unlike the version check, this function contains three powerful filters: plugins_api_args for editing the parameters sent to the API, plugins_api for overriding the default API requests, and plugins_api_result for editing the results received from the API.

      We will use plugins_api as it gives us the greatest level of control over the functionality: when WordPress initiates a Plugins API call to get information about the current plugin, our function will jump in and handle the request using the license server instead of WordPress.org. The rest of the requests will be left for WordPress to process.

      First, add the filter in the Wp_License_Manager_Client constructor's plugin specific else branch:

      Then, add the function:

      Line 16: Check the requested Plugin API action. We are currently only interested in plugin_information, so if WordPress asks for something else, we just return false and let the request go all the way to WordPress.org.

      Line 19: Check if the request is about the current plugin. If yes, we'll take the request and handle it. If not, return false so we don't break other plugins' Plugins API requests.

      Line 20: Call our license server to retrieve the information for the current product.

      Lines 22–48: Collect all the plugin data we got from the info request. Now, we are finally using all of the fields returned by the API.

      Line 50: Return the result object.

      To test this functionality, edit the Hello World Plugin product on your license server and add values to all of the product settings fields. In addition to the settings defined earlier, enter the following, setting the values to anything you like—we are just testing...

      • Tested with WordPress version: The highest WordPress version you have tested the plugin on.
      • Requires WordPress version: The minimum WordPress version required to run your plugin.
      • Last Updated: The date of the last update to this plugin, in YYYY-MM-DD format.
      • Banner low and Banner high: These fields define the normal (low) and retina (high) versions of the banner shown on top of the plugin information screen. Insert URLs to images of the following sizes: 772x250 for low and 1544x500 for high.

      Save the product and head back to the test site's Updates page. Now, you will see that there the WordPress version compatibility field is no longer Unknown, and when you click on View version 0.2 details, you will see this popup:

      Hello World Plugin popup

      Conclusion

      We have now created a fully functional, license controlled WordPress plugin and theme update system. It's still rather basic, but can already be used for passing updates to your organization's internal users or your premium plugin and theme customers.

      Hopefully, you have also learned something new about working with WordPress plugins and themes and can use the knowledge in creating your own projects.

       

      0 Comments

      Leave a comment › Posted in: Daily

  • Page 3 of 51 pages  < 1 2 3 4 5 >  Last ›
  • Browse the Blog

    Syndicate

    Most recent entries

    governing-bruise