In From the Web

Build a Custom WordPress User Flow — Part 3: Password Reset

4 Views July 18, 2015 Be first to comment

In the first two tutorials in this series, we have built custom pages for logging in and registering a new user. Now, there is only one part in the login flow left to explore and replace: what happens if a user forgets his or her password and wants to reset it.

In this tutorial, we will tackle that last step and complete the Personalize Login plugin we’ve been building throughout the series. 

The password reset functionality in WordPress follows what has become more or less the standard approach on today’s web sites: 

  1. A user initiates the reset by entering his or her user name or email address and requesting a password reset.
  2. A temporary password reset token is created and stored in the user data. A link containing this token is sent to the user’s email address.
  3. The user clicks on the link.
  4. On the password reset page, the token is verified and if it matches the user’s data, she gets to pick a new password.

Just like login and new user registration, this functionality is handled through wp-login.php — and so, the overall idea of how we’ll customize this flow will by now be mostly familiar from previous tutorials. 

If you haven’t read the first two tutorials yet, it’s best to start from Part 1 and go through the series in order. You can follow the tutorial while writing the code yourself or download the full source code from the linked Github repository.

Now, let’s get started by replacing the first screen in the flow.

Initiate the Password Reset

A password reset begins when a user arrives at your login page but doesn’t remember which password he or she used for this site. 

For this, we placed a Forgot your password? link at the bottom of the Sign In form in the first part of the series. By default, on WordPress powered sites, this link points to wp-login.php?action=lostpassword, a page that looks like this:

WordPress Forgot Your Password screen

To replace this page with a custom one, we will create a function to redirect the user to our custom page and hook that function to a WordPress action.

In this case, we have two options to choose from: we can use the action lost_password, which is called right before the page is rendered, or the action we have been using in previous tutorials: login_form_{action}, this time, login_form_lostpassword.

We could go both ways, but to limit the amount of unnecessary code being executed, let’s choose the latter option.

But first, let’s create the new page.

Step 1: Create a Page for Initiating Password Reset

As you remember, in Part 1, we created a function for creating WordPress pages at plugin activation, using the plugin_activated callback function.

In this function, add the new page’s definition at the end of the $page_definitions array. In the password reset flow, we’ll also need a second page for choosing the new password. So, to save time, let’s also add this second page now.

Here’s the entire array for clarity (with the two last page definitions added):

The plugin activation callback is only called when the plugin is explicitly activated, so to create these new pages, you’ll have to deactivate the plugin and then activate it again.

Now, with the pages created, we can redirect the user to member-password-lost instead of wp-login?action=lostpassword

Step 2: Redirect the User to the Custom Page

As I mentioned above, we’ll use the action login_form_{action}, or login_form_lostpassword to cut in before wp-login.php gets a chance to render the default version of the “Lost your password?” screen.

In the plugin’s constructor, add the following line:

Then, create the function redirect_to_custom_lostpassword

This function will check for the request method: for now, we’ll only act on requests sent using the GET method as those are the ones meant for displaying the screen. We’ll take a look at what happens at POST in a little while.

The function is actually the same as the one we used for redirecting the user to our custom registration page in the previous tutorial, with just the redirect replaced with the page slug of the new page we created above (a good place for some refactoring in the future, maybe?).

Now, if you click on Forgot your password? on the login page, you’ll be redirected to a custom Forgot Your Password page. Now, let’s create a shortcode to add the form for initiating the password reset.

Step 3: Create a Shortcode for Password Reset Form

When creating the page for initiating the password reset, we added the shortcode, [custom-lost-password-form] to its body. Now, to replace the shortcode with a form, let’s create a shortcode handler.

In the plugin’s constructor, add the following line:

Then, create the function for rendering the form:

By now, most of this function is already familiar to you: First we parse the shortcode parameters (show_title is used to decide whether a title should be rendered before the form for initiating the password reset). Then, if the user isn’t logged in, the function renders a template containing the form for initiating the password reset.

Let’s add that template now. In the templates directory, create a new file, naming it password_lost_form.php. Then, add the following code to that template:

The template begins by showing a title if the show_title attribute is set to true (lines 2-4).

This is followed by some instructions on lines 6-13 and the the actual form. As you’ll see on line 15, the form will be posted to the URL returned by the WordPress function  wp_lostpassword_url, the same URL that we saw above when we redirected the user to our custom page.

This form contains just one text field, user_login (line 18). In this field, the default password reset functionality in WordPress accepts either the user’s user name or email. As we are using email as the user name, they are both the same, and so we’ll ask for just the email in the field’s label (line 17).

With this template added, when you go click on the Lost your password? link on the login page, you’ll see a page that looks like this (If using the current WordPress default theme, Twenty Fifteen)

Custom Forgot Your Password screen

Step 4: Handle the Form Submit

Now that we have created the form, it’s time to look at what happens when the user submits it.

In order for us to do proper error handling without resorting to hacks, we’ll need to code some of the functionality ourselves — using helper functions from wp-login.php as much as possible, naturally. 

To do this, we’ll add a new function to handle the POST requests in thelogin_form_lostpassword action. 

This function will use the retrieve_password function defined in wp-login.php to look up the user and initiate the password update procedure. Then, depending on whether there were errors or not, the function redirects the user to the correct page: in case of errors, back to the Lost Your Password page and when successful, to the login page.

In the constructor, add the following line: 

Then, create the function:

The function begins by checking the request method (on line 5). As we’re interested in the case when the password lost form is submitted, this function only jumps in when it finds a POST request. The GET requests are already handled by the function redirect_to_custom_lostpassword we created earlier.

Then, on line 6, we call the WordPress function retrieve_password. The function’s name is a bit misleading: the function doesn’t really retrieve the password but instead checks the data from the form and then prepares the user’s account for password reset by creating the password reset token and emailing it to the user.

If there are errors (line 7), we redirect the user back to the page member-password-lost, with the error codes passed as a request parameter (lines 8-10, with the actual redirect done on line 17). 

If all goes well, the user is redirected to the login page with the request parameter checkemail set (lines 12-14) so that we can show a message to the user.

Now, if you submit the form, everything should work alright. But to make the user experience complete, we’ll need to go back to the shortcodes rendering the password lost and login forms and show the errors and success notifications.

Let’s start from the positive, and add the success message. 

In the shortcode function, render_login_form, add the following lines somewhere before the get_template_html call:

In the form template, add a message, using the attribute from above:

Now, after successfully initiating a password reset the Sign In form should look like this:

Password reset instructions shown on Sign In page

To display errors, we’ll go back to the lost password form. 

First, in the shortcode handler, render_password_lost_form, right before rendering the template, add the following lines to go through the error codes and collect matching error messages in the array $attributes['errors']:

Then, in the template, we’ll render the errors:

Finally, add the error messages to our function get_error_messages:

Next, to complete the first step in the password reset flow, let’s take a look at how we can customize the email that is sent to the user.

Step 5: Customize the Password Reset Email

As we saw earlier, when the request for resetting a password is sent, in the function retrieve_password, WordPress sends an email message containing quick instructions on what to do and a link that can be used to finish the password reset.

The message is short and to the point. It does what it’s supposed to do, but you might want to customize it to give it a personal touch and maybe make it a little more descriptive.

The default text is hard coded in wp-login.php, but before sending the message, WordPress gives plugin developers a chance to replace it using two filters.

First, to replace the message body, you can use the filter retrieve_password_message. Let’s do that now.

In the plugin’s constructor, add the following line:

Then, create the function, replace_retrieve_password_message:

The function receives four parameters: 

  • $message is the default version of the message to be sent to the user. We’ll ignore this parameter and create our own text from scratch.
  • $key is the token used to verify the user’s password reset request. It needs to be included in the password reset link.
  • $user_login is the user’s user name (in our case, email address), also needed in the password reset link.
  • $user_data contains some data about the user. We’ll ignore this for now, but you can explore it further in your own customization if you like.

Most of the function is just creating a message as a series of strings concatenations. The  URL for completing the password reset is created on line 18.

For a more complete customization, one idea would be to add a settings field for editing the content of the password retrieval message and use that instead of coding the message inside the function this way.

If you like, you can use the filter retrieve_password_title to replace the email message title the same way. The filter function takes one parameter, the default title to be sent to the user, and should return the new title. 

Still one other way to further customize the is to replace the entire message and send an HTML message instead, for example using the method I explained in an earlier tutorial about using Mandrill to send email messages from WordPress. In this case, I would use the Mandrill API to send the message in the filter function above and return false so that WordPress wouldn’t try sending the email again.

You have now completed the first step in the password reset procedure: the user can ask to reset the password and the process is initiated by WordPress. 

Next, we’ll look at what happens when the user clicks on the link in the password reset email.

Do the Password Reset

As we saw above, after initiating a password reset, the user is redirected back to the login page, with instructions to check his or her email. 

In that email, there is a link back to wp-login.php with the parameters login and key for identifying the user and verifying the password reset request. When the user clicks on the link, WordPress verifies the user and the key for validity, and then if all is good, lets the user set a new password.

The functionality works well, and we’ll use parts of it, calling existing helper functions in wp-login.php, but again, because of how the actions and filters are organized in the password reset code, we’ll have to rewrite some of the code to be able to complete the customization.

Step 1: Redirect the User to a Custom Page

First, we’ll start by redirecting the user to our own reset password page (which we created at the beginning of this tutorial). 

By now, this is probably familiar to you: In the same way we did in the login and register actions as well as the first page in the password reset flow, we’ll use the action login_form_{action} to divert the password reset action to our own custom functions before WordPress gets to do anything. 

There are two wp-login.php actions that are used for the same functionality, rp and resetpass, so we’ll need to redirect them both to the same function, redirect_to_custom_password_reset.

In the plugin’s constructor, add the following lines:

Then, create the function:

The function starts by checking that this is a GET request. POST requests sent to this same URL will be handled below. 

Then, on line 8, we call the WordPress function check_password_reset_key to verify that the parameters passed with the password reset link are valid. If there was an error, we redirect the user back to the login page, with the error code as a request parameter (lines 9-16). We’ll add the code for displaying the error soon.

If the parameters were successfully validated and the user is allowed to update his or her password, the function continues by redirecting the user to our custom (still empty) password reset page, member-password-reset

On lines 19-20, we add the parameters key and login to the redirect URL so that they’ll be available for another check when the user tries to set a new password on the next screen. The default version of the WordPress password reset uses a cookie for this, but for the tutorial’s sake, I decided to go with request parameters to keep the code easier to follow.

Next, let’s create a custom version of the password reset form.

Step 2: Show the Password Reset Form

The password reset form shown to the user after clicking on the link received in the email, by default looks like this:

WordPress Reset Password screen

It’s a simple form with two fields, pass1 and pass2, one for entering the password and the other to retype it to check that there were no typos.

To create our custom version of this form, we’ll use a shortcode. 

First, add the following line in the plugin’s constructor:

Then, create the function for rendering the form:

The core of this function starts on line 17, where we check that the user identification parameters login and key are present. If not, the password reset link isn’t valid, and we just render an error message (line 34).

If the check is OK, the two variables are added to the $attributes array to make them available to the form template (lines 18-19). 

Then, on lines 21-30, we already prepare for errors that can occur when the form is submitted, using the same error passing method from earlier forms in the tutorial.

Finally, on line 32, the function reads the template and returns it to WordPress for rendering. 

Let’s create the template next. In the templates directory, create a new file and name it password_reset_form.php. Add the following content:

The form begins with an optional title, displayed if the shortcode attribute show_title is set to true (lines 2-4). 

The actual form follows right after the title. Notice that the form will be posted to wp-login.php?action=resetpass (line 6), the same URL used in the link in the password reset email, except that the email link used a short version, rp, instead of resetpass.

At the beginning of the form (lines 7-8), we set up two hidden fields rp_key and rp_login to pass the key and login parameters to the form handler that will use them to validate the password change request.

On lines 10-16, the template will print out errors if there are any. This code is exactly the same as in the previous shortcode template earlier in this tutorial.

The two fields are printed out on lines 18-25, followed by some instructions for choosing a good password and the button for submitting the form.

Here’s what the form should look like now:

Custom Reset Password screen

Step 3: Handle the Reset Password Action

When the user submits the form by clicking on the Reset Password button, its contents are sent to wp-login.php?action=resetpass, the same URL we used above to redirect the user to our custom password reset page. 

Naturally, as we created the form ourselves, we could just as well use a different URL. However, by keeping this default URL and using the login_form_resetpass (and login_form_rp, just to be sure) action to replace the default functionality, we can make sure no one ends up accidentally calling the default version of the password reset.

To do this, once again, add two lines to the constructor:

Then, create the function:

The function begins by checking the request method, which should be POSTGET requests have already been handled by the redirect function above. 

Then, it collects the key and login parameters from the form data and uses them to verify the password reset link on line 9, using the WordPress function check_password_reset_key (the same function we used already in the redirect function).

On lines 10-18, we again check for possible errors in the password reset key check, redirecting the user to the page for Lost Your Password? page for rendering the errors. 

Then, if the reset key is valid, we can focus on the form. 

First, the function checks that the two passwords match (lines 21-31), and then that they are not empty (lines 33-43). In both cases, the user is redirected back to our password reset page, with the key and login parameters included in the URL to let the user retry the password update.

Finally, if all checks are successful (feel free to add more checks if you like), the function resets the password using the function reset_password (on line 46) and redirects the user to the login page with a parameter password=changed appended to the URL to show a notification. 

The password is now updated successfully, and all that’s left is to show the success notification and to add error messages.

First, let’s add the notification. In the shortcode function render_login_form, add the following check:

Then, add the actual message to the template, login_form.php, right before rendering the form:

As we already added support for rendering the error messages above, all that’s left is adding the descriptive error messages to our function get_error_message

Add the following lines right before the default branch in the construct:


That’s it! The password reset functionality is ready, and so, we have finished customizing the WordPress login experience from registering a new user to logging in and resetting a lost password.

I hope the series has given you enough tools so that you feel well equipped for further customizations — for example by adding a new step to the password reset flow — and a better understanding on what happens inside wp-login.php.

Now, go and customize some more!

Continue Reading

by admin


In From the Web

Apple Tightens Security With App Transport Security

1 Views July 17, 2015 Be first to comment

The importance of and attention for security on the web has increased substantially over the past few years. During this year’s WWDC, Apple has made it clear that it plans to lead by example by improving security of its operating systems through a new feature, App Transport Security.

Of course, the security of a platform is only as strong as the security of its components and that includes third party applications. In other words, Apple expects developers to adopt App Transport Security in their applications.

In this article, I will explain what App Transport Security entails, how it will affect your applications, and how you can update your applications to stick to Apple’s guidelines and recommendations.

What Is App Transport Security?

App Transport Security, or ATS for short, is a new feature of iOS 9 and OS X El Capitan. While Apple didn’t mention watchOS, we can assume App Transport Security also applies to watchOS 2. App Transport Security aims to improve the security of Apple’s operating systems and any applications running on these operating systems.

Network requests that are made over HTTP transmit data as cleartext. It goes without saying that this poses a significant security risk. Apple stresses that every developer should strive to keep the data of their customers safe and secure, even if that data doesn’t seem important or sensitive.

App Transport Security actively encourages security by imposing a number of security best practices, the most important being the requirement that network requests need to be sent over a secure connection. With App Transport Security enabled, network requests are automatically made over HTTPS instead of HTTP.

There are a number of other requirements to further improve security. For example, App Transport Security requires TLS (Transport Layer Security) 1.2 or higher. While you may be unfamiliar with TLS, I’m sure you’ve heard of SSL (Secure Sockets Layer). TLS is the successor of SSL and is a collection of cryptographic protocols to enforce security over network connections.

Apple recently published a public, prerelease technote about App Transport Security to give developers the opportunity to plan for App Transport Security. The document outlines what App Transport Security expects from your applications and the web services it interacts with.


Wait a second. My application uses a CDN (Content Delivery Network) that I don’t have control over and it doesn’t support HTTPS. Don’t worry. Apple has your back covered. With regards to App Transport Security, an application falls into one of four categories. Let’s go over each category to see how it impacts an application.


If your application only interfaces with servers that support HTTPS, then you’re in luck. You’re application won’t have to make any changes. However, note that App Transport Security requires TLS 1.2 and it expects the domain to use ciphers that support forward secrecy. The certificate also needs to meet the requirements imposed by ATS. It’s therefore important to double-check that the servers your application communicates with comply with the requirements of ATS.

Mix & Match

It is possible that your application talks to servers that don’t meet the ATS requirements. In that case, you need to tell the operating system which domains are involved and specify in your application’s Info.plist what requirements aren’t met.

This means that App Transport Security is enforced for every endpoint your application talks to with the exception of the ones specified in your application’s Info.plist. You can configure the exceptions using a number of predefined keys. In the following Info.plist, we define three exceptions.

The first exception we define tells ATS that communication with this subdomain overrides the requirement to use HTTPS. Note that this exception only applies to the subdomain specified in the exception. It’s important to understand that the NSExceptionAllowsInsecureHTTPLoads key doesn’t only relate to the use of HTTPS. The exception specifies that, for that domain, every requirement of App Transport Security is overridden.

It’s possible that your application talks to a server that serves its data over HTTPS, but isn’t using TLS 1.2 or higher. In that case, you define an exception that specifies the minimum TLS version that should be used. This is a better and safer option than completely overriding App Transport Security for that particular domain.

The NSIncludesSubdomains key tells App Transport Security that the exception applies to every subdomain of the specified domain. The exception further defines that the domain can use ciphers that don’t support forward secrecy (NSExceptionRequiresForwardSecrecy) by expanding the list of accepted ciphers. For more information about forward secrecy, I recommend reading Apple’s technote on the topic.

Opt Out

If you’re building a web browser, then you have a slightly bigger problem. Because you don’t know which web pages your users are going to visit, you cannot possibly tell whether those web pages are served over HTTPS and meet the ATS requirements. In that case, there is no other option but to opt out of App Transport Security altogether.

It’s important that you explicitly opt out of App Transport Security. Remember that App Transport Security is enforced by default. In your application’s Info.plist, you add a dictionary for the key NSAppTransportSecurity. The dictionary should include one key, NSAllowsArbitraryLoads, and its value should be set to YES. This is what your application’s Info.plist file should look like if you opt out of App Transport Security.

Opt Out With Exceptions

There is a fourth option in which your application opts out of App Transport Security, but defines a number of exceptions. This is useful if your application fetches data from a range of servers you don’t control, but also talks to an API you maintain. In that case, you specify in your application’s Info.plist that arbitrary loads are allowed, but you also define one or more exceptions for which App Transport Security is enabled. This is what the Info.plist could look like.


Apple has emphasized that applications automatically opt in to App Transport Security if they are built against iOS 9 or OS X El Capitan. This means that you won’t have to make any changes to your applications as long as you build them against iOS 8 or OS X Yosemite.

Based on previous releases of iOS and OS X, however, we have learned that Apple requires developers to build their applications against the latest SDK fairly soon after their official release. In other words, even though you won’t have to comply with App Transport Security when iOS 9 and OS X El Capitan are released later this year, it is very likely that Apple will require developers to build against the latest SDK in the first or second quarter of 2016. I therefore recommend that you investigate how App Transport Security will impact your applications sooner rather than later.


I hope this article has made it clear that App Transport Security is not something your applications can adopt some day. It’s similar to Apple’s requirement for 64-bit support not too long ago. Unless your applications only talk to servers over HTTPS that comply with the ATS requirements, you need to invest some time to investigate how App Transport Security will impact your applications. Apple’s technote about App Transport Security can help you with this.

Continue Reading

by admin


In From the Web

Easy Digital Downloads: Email Settings, Part 2

5 Views July 17, 2015 Be first to comment

In my previous article, I discussed the configuration of the first few options which you find inside the tab of Emails Settings. Let’s look at the remaining options of this tab in today’s article. 

Emails Settings

As I have discussed earlier, emails in Easy Digital Downloads are managed and handled in an organized way. Digital store owners and customers can both be notified simultaneously via emails about any activity.  

Easy Digital Downloads Emails Settings

Email settings in EDD can be accessed via Download > Settings > Emails. I have already explained the working and functions of options like Email Template, Logo, From Name and From Email. So, let’s get started with the next option, which is for the Purchase Email Subject.

Purchase Email Subject

Easy Digital Downloads Emails Settings

Purchase Email Subject is a text field from where you set the subject of your purchase emails. Whenever any customer buys a product, he or she will be addressed with this subject in the email. For example, I have set Purchase Receipt as its value.

Easy Digital Downloads Emails Settings

The above image shows an email for a new purchase which bears the subject Purchase Receipt. However, you can change it as well.

Purchase Receipt

Easy Digital Downloads Emails Settings

The next option in the Emails settings allow you to configure and manage the contents of the Purchase Receipt. Whenever an email is sent in EDD, its contents follow a particular format. Hence, the email’s body is controlled from this option. 

The above figure shows the basic format which starts with addressing the customer by name, followed by a thank you note and finally the site name and the list of downloadable products which the customer has purchased along with their links. These attributes are added via short-codes like {name}, {download_list}, etc.

The interface has a WordPress text editor and some formatting options where you can add media files as well.

Easy Digital Downloads Emails Settings

Right below the text window is a list of short-codes which can be added to your purchase email. Whichever short-code you choose, its functionality will be included.

Let’s explain it with the help of an example.

Easy Digital Downloads Emails Settings

The above figure shows the option of Purchase Receipt where I have added some additional short-codes from the list above. Adding these will mean I am adding some extra details in the email. I have replaced {name} with {fullname} and have added codes for {payment_method}, {receipt_link} and {date}.

Now when customers purchase any product, the format of the email will be much more detailed than before.

Easy Digital Downloads Emails Settings

You can compare the above figure with the previous figures for emails.

New Sale Notifications

So far I have explained the options relevant to Purchase emails, which are sent to the customers upon any purchase. Next is a portion of New Sale Notifications where I will discuss the options for Sale emails. These emails will notify the digital store owner (you) about any new sale.

Sale Notification Subject

Easy Digital Downloads Emails Settings

Fill out this field to set the email subject of your sale emails. A default value is already set, but you can change it to some custom value as well.

Easy Digital Downloads Emails Settings

The above figure shows the result for the Sale Notification Subject.

Sale Notification

Easy Digital Downloads Emails Settings

The next option is the Sale Notification and its purpose and function is similar to the Purchase Receipt. The only difference is that this option will define the structure of the new sale emails. The layout is the same and you can once again find a list of various short-codes to include additional details.

Sale Notification Emails

Easy Digital Downloads Emails Settings

In the next field you will specify all those mailing ID(s) where you want to receive sale emails.

Disable Admin Notifications

Easy Digital Downloads Emails Settings

The last option is a checkbox for Disable Admin Notifications. If you do not wish to be notified about any new sale then enable this option. Otherwise leave this disabled. 

Once you are done with all the settings in this tab simply click Save Changes.


This ends the settings of the Emails tab. Try these out and let me know if you face any difficulty. In the next article I will discuss the next tab of Settings which is for various Styles in EDD.

Continue Reading

by admin


In From the Web

Understand Overriding in Magento: Models

5 Views July 17, 2015 Be first to comment

In this series, we’re exploring overriding features available in the Magento eCommerce system. In the previous article, we discussed how to override core block files using a custom module. Today, I’ll extend it and demonstrate how you can override core model files using an XML-based configuration file.

Why Overriding Models?

In Magento, models play an important role as they implement most of the business logic of the core features. There are times when you need to change the flow or business logic in models to implement your custom features. 

It’s tempting to go ahead and change the core files directly, which seems an easy and straightforward solution. Having said that, it’s a bad practice, as it makes upgrading Magento really difficult. The more core files you modify directly, the more difficult it becomes for you to keep track of your changes and apply them during every version upgrade!

In this tutorial, we’ll make a custom module to understand how model overriding works in Magento. In this custom module, we’ll see how to override a category model class of the core “Catalog” module. Overriding works by setting up certain XML tags as per the conventions of Magento.

I assume that you’re familiar with the basic module creation process in Magento. If not, here’s a good article explaining the basics of custom module creation. Let’s jump right in to the course of this tutorial!

A Glance at the Setup

Here’s the list of files required for the desired setup:

  • app/etc/modules/Envato_All.xml: It’s a file used to enable our custom module.
  • app/code/local/Envato/Catalog/etc/config.xml: It’s a module configuration file in which we’ll set up model class overriding using certain tags as per the Magento conventions.
  • app/code/local/Envato/Catalog/Model/Category.php: It’s a model class of our custom module which will override the base model class.

Creating Files and Folders: Custom Module

First, we need to create a module enabler file. Create a file “app/etc/modules/Envato_All.xml” and paste the following contents in that file. We’ve used Envato as our module namespace and Catalog as our module name. It’ll enable our “Catalog” module by default.

Next, we need to create a module configuration file. Create “app/code/local/Envato/Catalog/etc/config.xml” and paste the following contents in that file.

First, we’ve defined a module version number using the <version> tag. After that, the <catalog> and <rewrite> tags are used to inform the Magento overriding system that we’re going to override a “model” of the “Catalog” core module.

Next, the <category> tag is used to define a model identity which will be overridden by the Envato_Catalog_Model_Category class. It’s mapped to a model file “Category.php” under the “Model” directory of the Catalog module. An important thing to notice here is that we’re following a directory structure similar to the core module. Although that’s not strictly necessary, it’s better than using a different directory structure, because it helps to maintain readability.

Finally, the only remaining thing is to define a model class Envato_Catalog_Model_Category. Let’s create a model file “app/code/local/Envato/Catalog/Model/Category.php” and paste the following contents in that file.

We’ve defined an Envato_Catalog_Model_Category class which extends the core Mage_Catalog_Model_Category model class of the “Catalog” module. Thus, you can override every method of the base class and create new methods if necessary.

In the above example, the getProductCollection method is overridden so it’ll be called instead of the method defined in the core model class! You can modify the model code as per your requirements. 

When you override any methods in models, you should make sure that the data type of the return value of that method matches with the data type of the base class method. Since model methods are called from several core modules, we should make sure that it doesn’t break other features!

Although this is a very basic example, it serves the purpose of overriding the core model, and you can extend it as per your custom requirements.


In this tutorial, we learned how to override core model files in Magento using a custom module. In the next and last part of this overriding series, we’ll see how to override core controller files. Don’t hesitate to leave your comments below!

Continue Reading

by admin


In Case Studies, Frameworks, From the Web, General, Process, Product Strategy, UX, Workflow

Product Design Unification Case Study, Part 2: “Burger-Driven” Framework

6 Views July 17, 2015 Be first to comment


In the first part of the case study about Mail.Ru Group product design unification, I described our first approach — a mobile web framework. Aside from creating a unified visual style and interaction principles for a dozen services, we’ve also transformed our design process from the classic “prototype → design mock-up → HTML → implementation” approach for every screen, to a modern and more efficient framework-based approach.

Product Design Unification Case Study, Part 2:

In this second part I’ll show how we have improved the same technology to embody larger versions of these products and made our “Bootstrap on steroids” more powerful. In the spring of 2012, our business unit acquired 11 content-based projects: Auto, Events Guide, Health, Horoscopes, Kids, Lady, Moto, News, Sports, TV, and Weather. Many of them are very successful in their market niche in Russia; however, they each have their own history, often with outsourced designs that led to inconsistencies.

The post Product Design Unification Case Study, Part 2: “Burger-Driven” Framework appeared first on Smashing Magazine.

Continue Reading

by admin


In From the Web

How to Debug JavaScript Remotely With Vorlon.js

2 Views July 16, 2015 Be first to comment

Recently at //BUILD/ 2015 we announced Vorlon.js—an open source,
extensible, platform-agnostic tool for remotely debugging and testing your
JavaScript. I had the opportunity to create Vorlon.js with the help of some
talented engineers and tech evangelists at Microsoft (the same guys that
brought you Babylon.js).

Vorlon.js is powered by Node.js,
Socket.IO, and late-night coffee. I would like to share with you why we made
it and how to incorporate it into your own testing workflow, as well as sharing some
more details on the art of building a JavaScript library like it.

Vorlonjs logo

Why Vorlon.js?

Vorlon.js helps you
remotely load, inspect, test and debug JavaScript code running on any device
with a web browser. Whether it is a game console, mobile device, or even an IoT-
connected refrigerator, you can remotely connect up to 50 devices and execute
JavaScript in each or all of them. 

The idea here is that dev teams can also
debug together—each person can write code, and the results are visible to all.
We had a simple motto in this project: No native code, no dependency
to a specific browser, only JavaScript, HTML and CSS running on the
devices of your choice.

Vorlon.js itself is a
small web server you can run from your local machine, or install on a server
for your team to access, that serves the Vorlon.js dashboard (your command
center) and communicates with the remote devices. 

Installing the Vorlon.js
client in your web site or app is as easy as adding a single script tag. It’s
also extensible, so devs can write plug-ins that add features to both the
client and the dashboard, such as feature detection, logging, and
exception tracking.

So why the name? There
are actually two reasons. The first one is because I am just crazy about Babylon 5 (the TV show). Based on
this, the second reason is because the Vorlons are one of the wisest
and most ancient races in the universe and thus, they are helpful as diplomats
between younger races. Their helpfulness is what inspired us: for web devs,
it’s still just too hard to write JavaScript that works reliably in the various
devices and browsers. Vorlon.js seeks to make it just a little easier.

You Mentioned
Vorlon.js Has Plug-ins?

Vorlon.js has been
designed so that you can extend the dashboard and client application easily by
writing or installing additional plugins. You can resize or add extra panes to
the dashboard which can communicate bidirectionally with the client
application. There are three plug-ins to begin with:


Logging: The console tab will stream console messages from the client to the
dashboard that you can use for debugging. Anything logged with console.log(), console.warn()
or console.error() will appear in the dashboard. Like the F12 Dev Tool
DOM explorer, you can see the DOM tree, select a node (which will be
highlighted on the device, and update or add new CSS properties).

You can also interact with the remote webpage by typing code into the input.
Code entered will be evaluated in the context of the page.

Console page

DOM Explorer

DOM inspector shows you the DOM of the remote webpage. You can inspect the DOM,
clicking on nodes to highlight them in the host webpage, and if you select
one you can also view and modify its CSS properties.

DOM Explorer page


Modernizr tab will show you the supported browser features as reported by Modernizr. You can use this to
determine what features are actually available. This might be particularly
useful on unusual mobile devices, or things like games consoles.

Modernizr tab showing CSS features detection

How Do I Use It?

From your node command
line, just execute this:

Now you have a server
running on your localhost on port 1337. To get access to the dashboard, just navigate to https://localhost:1337/dashboard/SESSIONID, where SESSIONID is the
id for the current dashboard session. This can be any string you want.

You have then to add a
single reference in your client project:

Please note that SESSIONID can be omitted and in this case, it will be
automatically replaced by “default”. 

And that’s it! Now your client will send debug information to your dashboard
seamlessly. Let’s now have a look at an example using a real site. 

Debugging Using Vorlon.js

Let’s use for our example. First,
I have to launch my server (using node start.js inside the /server folder).
Then, I just have to add this line to my client site:

Because I am not defining
a SESSIONID, I can just go to https://localhost:1337/dashboard. The
dashboard looks like this:

Vorlonjs dashboard

Sidenote: The browser shown above
is Microsoft Edge (formerly known as Project Spartan), Microsoft’s new
browser for Windows 10. You can also test your web apps for it remotely on your
Mac, iOS, Android, or Windows device @ Or try Vorlon.js too.

Back to it: I can see console messages for instance, which is useful when I
debug Babylon.js on mobile devices (like iOS, Android or Windows Phone). I can click on any node on the DOM Explorer to get info about CSS properties:

DOM Explorer info about CSS properties

 On the client side, the
selected node is highlighted with a red border:

client side showing the selected node highlighted with a red border

Moreover, I can switch to the Modernizr tab to see the capabilities of my specific device:

Modernizr tab showing the capabilities of my specific device

On the left side, you can
see the list of currently connected clients and you can use the Identify a
button to display a number on every connected device.

A Little More on
How We Built Vorlon.js

From the very beginning,
we wanted to be sure that Vorlon.js remains as mobile-first and platform-agnostic
as possible. So we decided to use open source tech that worked across the
broader number of environments.

Our dev environment was
Visual Studio Community which you can get for free now. We used the Node.js tools for Visual Studio and

for the back-end. Our front-end was JavaScript and TypeScript. If you’re not
familiar with TypeScript, you can learn why we’ve built Babylon.js with it in this blog post. Recently Angular 2 has been built with
. But you don’t have to know it to use Vorlon.js.

Here’s a global schema of
how it works:

Vorlonjs architecture diagram

 Here are the parts we built it with:

  • A Node.js server is
    hosting a dashboard page (served using Express) and a service.
  • The
    service is using Socket.IO to
    establish a direct connection with both the dashboard and the various
  • Devices
    have to reference a simple Vorlon.js page served by the server. It
    contains all the plugins’ client code which interacts with the client device
    and communicates with the dashboard through the server.
  • Every
    plug-in is split in two parts:
    • the
      client side, used to capture information and to interact with the device
    • the
      dashboard side, used to generate a command panel for the plugin inside
      the dashboard

For instance, the console
plugin works this way:

  • The client
    side generates a hook on top of console.log(), console.warn() or console.error(). This hook is used to send the parameters of these
    functions to the dashboard. It can also receive orders from the dashboard
    side that it will evaluate.
  • The
    dashboard side gathers these parameters and displays them on the dashboard.

The result is simply a
remote console:

Remote console

You can get an even
better understanding of Vorlon.js extensibility, including how to build your own
plug-ins, at the Vorlon.js website.

What’s Next?

Vorlon.js is built on the
idea of extensibility. We encourage you to contribute! And we’re already thinking about how we might integrate Vorlon.js into browser dev tools as well as Web
Audio debugging.

If you want to try it,
you are just one click away: And
the more technical docs are on our GitHub.

More Hands-On With

It might surprise you a bit, but Microsoft
has a bunch of free learning on many open source JavaScript topics, and we’re on
a mission to create a lot more with Microsoft Edge. Check out my own:

Or our team’s learning series:

And some free tools: Visual Studio Community, Azure Trial, and cross-browser testing tools for Mac, Linux, or

This article is part of the web dev tech
series from Microsoft. We’re excited to share
and the new EdgeHTML
rendering engine
with you. Get free virtual machines or test remotely on
your Mac, iOS, Android, or Windows device @

Continue Reading

by admin


In From the Web

Toolbox of the Smart WordPress Developer: Kirki

4 Views July 16, 2015 Be first to comment

Welcome to the second part of the “Toolbox of the Smart WordPress Developer” series! In this part, we’re going to go through Kirki, a great Customizer toolkit for WordPress theme developers.

Let’s begin!

A Word on the Customizer

WordPress version 3.4 introduced a new API called the Theme Customization API and the “Theme Customizer” screen. (In version 4.1, the word “Theme” was dropped since it’s not exclusively a “theme customizer”.) It allows us to add customization options in the Appearance > Customize menu, with an opportunity to change theme settings simultaneously while previewing the website.

It didn’t create much hype at first, but the community adopted it over time, and we gradually got more and more excited about this handy API. Over two years after its release, the Customizer API has evolved into a wonderful utility that even lets us publish posts and customize the login screen.

It’s not an overstatement to say that Customizer is one of the most valuable APIs of WordPress because of its ability to completely change users’ experience.

If you want to learn more on this subject, check out our series on the Customizer, written by Lee Pham.

Enter Kirki: Easy Development for the Customizer Screen

Kirki is a great tool to improve the experience of a theme’s users. It focuses solely on theme customization and extends the default Customizer controls with toggles, range inputs and images as radio buttons.

Once you get to know how it works, building a theme customization screen will be easier than ever.

A Call to Action: Kirki is translation-ready and needs your help to translate this open-source project into different languages. I’m going to handle the Turkish translation, and it would be great if you could help translate Kirki into your language. If you want to contribute, contact Aristeides Stathopoulos, author of Kirki, for details.

Embedding Kirki in Your Theme and Configuring It

Bundling your theme with Kirki is very easy, actually. You just need to download the latest version from GitHub, extract the contents into a folder in your theme, and include the main plugin file (by using the include_once() function) in your theme’s functions.php file.

Here’s an example:

Piece of cake, isn’t it? Below that, you can create a configuration to avoid conflicts with other themes or plugins that use Kirki as well:


Using Kirki in Your Theme

Now we’ve learned about how to embed and configure Kirki in our themes, it’s time to see some examples of how to build our theme customization page.

Let’s start with the basics. Here’s the code of a basic installation with some panels and sections but without any control fields:

Now, let’s see about the control fields Kirki provides.

Control Field Types of Kirki

After creating your panels and sections, you can fill in the sections with “control fields”. Here’s the code to add a field inside a section:

As I said before, Kirki extends the default control fields list with new ones. For the sake of writing a more “complete” tutorial, I will include the core control fields as well as Kirki’s additional control fields.

  1. text allows you to add a simple text input.
  2. textarea allows you to add a textarea.
  3. editor allows you to add a WYSIWYG editor.
  4. radio allows you to add radio buttons.
  5. checkbox allows you to add checkboxes.
  6. color and color-alpha (supports transparency) allow you to select a color with a nice color picker.
  7. background allows you to add a complete CSS background customizer.
  8. palette allows you to add a color palette.
  9. select allows you to add a dropdown menu.
  10. select2 allows you to add a “better” selection menu, different from the default <option> HTML element.
  11. select2-multiple allows you to add a selection menu with multiple choices. (Wild guess: This might be merged with the select2 field in the future.)
  12. dropdown-pages allows you to add a dropdown menu listing the pages in the database.
  13. upload allows you to add the native uploader.
  14. image allows you to add the native image selector/uploader.
  15. radio-image allows you to add images acting as radio buttons.
  16. radio-buttonset allows you to add a button set acting as radio buttons.
  17. number allows you to add an HTML5 number input.
  18. slider allows you to add an HTML5 range slider.
  19. multicheck allows you to add a list with multiple checkbox inputs.
  20. switch allows you to add a “switch” button that acts like a checkbox, but prettier.
  21. toggle allows you to add a “toggle” button that also acts like a checkbox.
  22. sortable allows you to add a sortable list of checkbox controls.
  23. custom allows you to add a custom control field, which is basically any valid HTML code fragment.

Styling Kirki

Kirki has some pretty cool settings for you to make a customized Customizer for your theme. You can display a logo above the control fields, set a different color scheme for the Customizer and so on.

  • logo_image: Specifies the logo image URL.
  • description: Specifies a description text that will be displayed upon clicking the logo.
  • color_active: Specifies the “active” color for menu items, help buttons and such.
  • color_light: Specifies the “secondary” color for disabled and inactive controls.
  • color_select: Specifies the “selected” color for, well, selected stuff.
  • color_accent: Specifies the “accent” color that’s used on slider controls and image selects.
  • color_back: Specifies the background color for the Customizer.
  • url_path: Specifies the URL path for Kirki, used for loading CSS files in its /assets/ folder.
  • stylesheet_id: The stylesheet ID to set as the handle in CSS enqueueing processes.

To set these style options, you will need to use the kirki/config filter. Here’s an example of how to configure Kirki:

Getting the Values

You have to use the values in your theme that Kirki stores, right? Here’s how:

Simple as that. Of course, you still can use the core get_option() and get_theme_mod() functions.

Wrapping Up for Today

Tools like this make WordPress even more user-friendly and easy to develop, don’t you think? As I said in the series introduction, the power of WordPress comes from its community, and tools like this are the key to community growth. Kirki offers more than I wrote in this tutorial, and Ari (the author) promises that he will continue developing Kirki for, in his words, as long as it takes.

What do you think about Kirki? Shoot your thoughts in the Comments section below. And if you liked the article, don’t forget to share it with your friends!

See you in the next part where we’ll be covering the GenerateWP website!

Continue Reading

by admin


In From the Web

The Tuts+ Guide to Template Tags: Sixth Batch

3 Views July 16, 2015 Be first to comment

In the sixth part of the series, we went through the fifth batch of WordPress template tags. In this seventh part, we’re going to go through the sixth batch of the almost 200 template tags. Throughout the tutorial, we’ll see template tags about authors and attachments.

Getting the URL of the Author’s Post Archives: get_author_posts_url()

This template tag returns a link to an author’s post archives.


This template tag accepts two parameters:

  • $author_ID (required—integer):
    The ID of the author.
    (Default: Current author)
  • $author_nicename (optional—string):
    The “nice name” of the author. (A “nice name” is the sanitized version of “username” which can be used in URLs and such.)
    (Default: Empty)


Displaying a Link to the Author’s Post Archives: the_author_posts_link()

This template tag outputs a link to the author’s post archives.


This template tag doesn’t accept any parameters.


Getting & Displaying the Author’s Website Link: get_the_author_link() & the_author_link()

These template tags return or echo a link to the author’s website.


These template tags don’t accept any parameters.


Getting & Displaying the Author’s Meta Data: get_the_author_meta() & the_author_meta()

These template tags fetch and display the meta data of an author.


Both template tags accept two parameters:

  • $field (required—string):
    The field to fetch (‘login’, ‘nicename’, ’email’, ‘url’, ‘registered’, or ‘status’).
    (Default: Empty)
  • $user_ID (optional—integer):
    The ID of the user.
    (Default: Global $authordata)


Getting & Displaying the Post Count of the Author: get_the_author_posts() & the_author_posts()

These template tags count how many posts an author has written, and returns or displays the result.


These template tags don’t accept any parameters.


Getting & Displaying the List of Authors: wp_list_authors()

This template tag returns or displays a list of authors writing on your website.


This template tag accepts only one parameter:

  • $args (optional—array):
    An array of the following arguments:

    • 'orderby' (string): How to order the links. Accepts ‘user_nicename’, ‘user_email’, ‘user_url’, ‘user_registered’, ‘name’, ‘display_name’, ‘post_count’, ‘ID’, ‘meta_value’, and ‘user_login’.
      (Default: ‘name’)
    • 'order' (string): Whether to order items in ascending (‘ASC’) or descending (‘DESC’) order.
      (Default: ‘ASC’)
    • 'number' (integer): Number of authors to retrieve.
      (Default: NULL which means no limit)
    • 'option_count' (boolean): Whether to display post count next to author names or not.
      (Default: FALSE)
    • 'exclude_admin' (boolean): Whether to exclude the ‘admin’ (not all Administrators, just the one with the ‘admin’ username) from the list.
      (Default: TRUE)
    • 'show_fullname' (boolean): Whether to show first and last names (TRUE) or “display names” (FALSE).
      (Default: FALSE)
    • 'hide_empty' (boolean): Hide authors with no posts or not.
      (Default: TRUE)
    • 'echo' (boolean): Whether to echo the output (TRUE) or return it (FALSE).
      (Default: TRUE)
    • 'feed' (string): If set to any non-blank value, author feed links will appear next to author links. The value will be the anchor text of the links.
      (Default: Empty)
    • 'feed_type' (string): Type of feed (‘rss’, ‘rss2’, ‘atom’ or ‘rdf’).
      (Default: Empty)
    • 'feed_image' (string): Image path to override anchor text and show an image instead.
      (Default: Empty)
    • 'style' (string): Style to display authors—’list’ to generate an unordered list or ‘none’ to generate a list of links separated with commas.
      (Default: ‘list’)
    • 'html' (boolean): Whether to generate HTML or plain text.
      (Default: TRUE)
    • 'include' (string): Comma-separated list of IDs to include.
      (Default: Empty)
    • 'exclude' (string): Comma-separated list of IDs to exclude.
      (Default: Empty)


Getting & Displaying an HTML Dropdown of Users: wp_dropdown_users()

This template tag returns or echoes a dropdown menu (<select>) of users.


This template tag accepts only one parameter:

  • $args (optional—array):
    An array of the following arguments:

    • 'show_option_all' (string): Text to display as the dropdown default.
      (Default: Empty)
    • 'show_option_none' (string): Text to display as the dropdown default when no users were found.
      (Default: Empty)
    • 'option_none_value' (integer or string): Value to use for ‘show_option_none’ when no users were found.
      (Default: -1)
    • 'hide_if_only_one_author' (string): Whether to hide the dropdown if there’s only one author.
      (Default: Empty)
    • 'orderby' (string): Which column to use for ordering users.
      (Default: ‘display_name’)
    • 'order' (string): Which direction to order users.
      (Default: ‘ASC’)
    • 'include' (array or string): An array or a comma-separated list of user IDs to show (and exclude the rest).
      (Default: Empty)
    • 'exclude' (array or string): An array or a comma-separated list of user IDs to exclude from the list.
      (Default: Empty)
    • 'multi' (boolean or integer): Whether to skip the ID of the SELECT element. (Useful if you’re going to display more than one users dropdown.)
      (Default: 0)
    • 'show' (string): What to show as list item names.
      (Default: ‘display_name’)
    • 'echo' (boolean or integer): Whether to display or retrieve content.
      (Default: 1)
    • 'selected' (integer): The user ID to be selected by default.
      (Default: 0)
    • 'include_selected' (boolean): Whether to always include the selected user ID in the dropdown..
      (Default: FALSE)
    • 'name' (string): The NAME attribute value for the SELECT element.
      (Default: ‘user’)
    • 'id' (string): The ID for the SELECT element.
      (Default: Empty)
    • 'class' (string): CSS class for the SELECT element.
      (Default: Empty)
    • 'blog_id' (optional; integer): ID of the blog to retrieve users.
      (Default: Current blog)
    • 'who' (string): Which type of users to query (Accepts ‘authors’ or an empty string).
      (Default: Emtpy)


Getting & Displaying the Featured Image of the Post: get_the_post_thumbnail() & the_post_thumbnail()

Well, the title explains it all.


get_the_post_thumbnail() accepts three parameters:

  • $post_ID (optional—integer):
    The ID of the post.
    (Default: Current post)
  • $size (optional—string):
    Size of the image.
    (Default: ‘post-thumbnail’)
  • $attr (optional—string or array):
    An array of the following attributes:

    • ‘src’: The image source
    • ‘class’: The CSS class (or classes, separated with spaces)
    • ‘alt’: The alt text

And the_post_thumbnail() accepts two parameters:

  • $size (optional—string):
    Size of the image.
    (Default: ‘post-thumbnail’)
  • $attr (optional—string or array):
    An array of the following attributes:

    • ‘src’: The image source
    • ‘class’: The CSS class (or classes, separated with spaces)
    • ‘alt’: The alt text


Getting & Displaying the Permalink of an Attachment Page: wp_get_attachment_link() & the_attachment_link()

These template tags return or display the permalink of the attachment, so it can be opened in another page.


wp_get_attachment_link() accepts five parameters:

  • $post_ID (optional—integer or object):
    The ID of the post.
    (Default: Current post)
  • $size (optional —string):
    Size of the image.
    (Default: ‘thumbnail’)
  • $permalink (optional—boolean):
    Whether to include permalink or not.
    (Default: FALSE)
  • $icon (optional—boolean):
    Whether to include icon.
    (Default: FALSE)
  • $text (optional—string or boolean):
    Text to display for the link.
    (Default: FALSE)

And the_attachment_link() accepts four parameters:

  • $post_ID (optional—integer or object):
    The ID of the post.
    (Default: Current post)
  • $fullsize (optional—boolean):
    Whether to use full sized image or not.
    (Default: FALSE)
  • $deprecated (deprecated—boolean):
    This parameter is deprecated and you should just pass it as TRUE or FALSE (doesn’t matter which).
  • $permalink (optional—boolean):
    Whether to include permalink or not.
    (Default: FALSE)


Getting the ID of the Post’s Featured Image: get_post_thumbnail_id()

This template tag gets the ID of a post’s featured image.


This template tag accepts only one parameter:

  • $post_ID (optional—integer):
    The post’s ID to retrieve the thumbnail ID from.
    (Default: Current post)


Getting the Attachment Image: wp_get_attachment_image()

This template tag returns a given attachment image’s HTML code (<img />).


This template tag accepts four parameters:

  • $attachment_ID (optional—integer):
    The ID of the attachment.
    (Default: Current attachment)
  • $size (optional—string):
    The image size.
    (Default: ‘thumbnail’)
  • $icon (optional—boolean):
    Whether to include icon or not.
    (Default: FALSE)
  • $attr (optional—string or array):
    An array of the following attributes:

    • ‘src’: The image source
    • ‘class’: The CSS class (or classes, separated with spaces)
    • ‘alt’: The alt text


Getting the Attachment Image URL: wp_get_attachment_image_src()

This template tag returns the URL of an attachment image of your choice.


This template tag accepts three parameters:

  • $attachment_ID (optional—integer):
    The ID of the attachment.
    (Default: Current attachment)
  • $size (optional—string):
    The image size.
    (Default: ‘thumbnail’)
  • $icon (optional—boolean):
    Whether to include icon or not.
    (Default: FALSE)


Getting the Attachment Image Meta Data: wp_get_attachment_metadata()

This template tag returns the meta data of a given attachment.


This template tag accepts two parameters:

  • $attachment_ID (optional—integer):
    The ID of the attachment.
    (Default: 0)
  • $unfiltered (optional—boolean):
    If this is set to TRUE, the wp_get_attachment_metadata filter will not be run.
    (Default: FALSE)


Getting the Next Image of the Same Post: next_image_link()

This template tag returns the “next image” link for image attachment pages.


This template tag accepts two parameters:

  • $size (optional—string):
    Size of the image.
    (Default: ‘thumbnail’)
  • $text (optional—string or boolean):
    Text to display for the link.
    (Default: FALSE)


Getting the Previous Image of the Same Post: previous_image_link()

This template tag returns the “previous image” link for image attachment pages.


This template tag accepts two parameters:

  • $size (optional—string):
    Size of the image.
    (Default: ‘thumbnail’)
  • $text (optional—string or boolean):
    Text to display for the link.
    (Default: FALSE)



Hope you liked this sixth batch of template tags. There are two more batches to go, so stay tuned for more template tags!

If you have any questions, comments or corrections, you can share your thoughts with us in the Comments section. And if you liked the article, don’t forget to share it with your friends!

Continue Reading

by admin


In From the Web

Free Course: Crawl the Web With Python

3 Views July 15, 2015 Be first to comment

Recently we’ve started producing short, free courses aimed at those of you with limited time and a limited budget. The idea is that in a set of short videos, clocking in at around an hour of total viewing time, you can learn some useful new skills, without paying a penny.

In our latest free course, Crawl the Web With Python, you’ll learn the basics of building a simple web crawler and scraper using Python.

Python web crawler
What You’ll Be Creating

What You’ll Learn

In a recent business venture, Tuts+ instructor Derek Jensen found it necessary to collect bulk data from different online sources in order to centralize it and make it easier for people to find and to make sense of. 

None of those sites had exposed public APIs, so he decided to try his hand at a little web crawling and scraping to obtain this metadata. After searching around for a while, he found that many people when faced with the same issue have turned to Python. 

In this course he shares some of his findings and shows you how you can go about creating your own basic web crawler and scraper. 

Watch the Introduction

Take the Course

To take this free course, simply go to the course page and follow the steps to create a free account. If you already have an account, just log in and you’ll be able to get started right away.

Continue Reading

by admin


In From the Web

Beyond the Basics With Framer

Be first to view July 15, 2015 Be first to comment


In my previous tutorial about Framer, you learned how to use layers, states, and events to create simple mock-ups for your iOS and Android apps. Framer has a lot more to offer though. In this tutorial, I am going to focus on a few more advanced features of the framework that allow you to add more complex interactions and effects to your mock-ups.

1. Nesting Layers

Because a layer can be embedded inside another layer, you can create complex layer hierarchies with Framer. An embedded layer is called a sublayer and the layer that it is embedded in is called its superlayer. The following code snippet shows you how to embed a layer within another layer using the superLayer property.

You can make use of layer hierarchies to simulate multiple screens in your mock-ups. Let me show you how to do this with the help of an example. Consider a mock-up that has two screens, a login screen and a welcome screen.

The login screen contains input fields for the username and password, and a submit button. The welcome screen contains an image and a few lines of text.

To create such a mock-up, you could consider the login and welcome screens as superlayers and the user interface elements they contain as sublayers. Let’s start by creating the superlayers first.

As you can see, loginScreen and welcomeScreen are blank Layer objects for now. Let’s add some sublayers to the loginScreen layer.

In the same way, let’s now add some sublayers to the welcomeScreen layer.

At this point, if you try to view your prototype in a browser, it will look a bit messy. Both superlayers (loginScreen and welcomeScreen) are visible at the same time.

To hide a layer, you set its visible property to false. Here’s how you keep the welcomeScreen layer hidden when the mock-up starts:

To change the view from the login screen to the welcome screen, you can simply hide the loginScreen layer and turn on the visibility of the welcomeScreen layer. The following code snippet shows you how to do so inside the click handler of submitButton:

Go back to the browser and refresh the page to see your mock-up making more sense now. Remember that the browser you’re using to view the mock-up should be WebKit-based, such as Chrome or Safari.

Instant transition

If you don’t like the instant switch, you can animate the transition by using the animate function to animate, for example, the opacity of the layers.

This is what the transition looks like now:

Fade-out and fade-in transition

2. Using Layer Effects

Framer allows you to apply a variety of image effects, such as gaussian blur, hue rotation, brightness/contrast adjustment, color inversion, sepia tone addition, and more, to your Layer objects.

The following code snippet shows you how to use the blur effect to create a blurred background:

This is what the result looks like:

Blurred background

The rest of the effects are used in a similar manner. For example, to reduce the contrast of the bg layer, you need to modify the contrast property:

3. Creating Scrollable Layers

To make a layer scrollable, you need to embed it in the content layer of a ScrollComponent object. Creating a ScrollComponent is similar to creating a Layer object:

The following code block shows you how to embed a Layer object within the content of scroll1:

Here’s what a ScrollComponent looks like in action:


Note that scrolling is possible only if the dimensions of the layer are larger than the dimensions of the ScrollComponent it is embedded in.

4. Displaying Paginated Data

Sometimes, instead of continuous scrolling, you might want to present your data as a set of pages. For example, you might want to create an interface where a user swipes through a set of images. This can be done using a PageComponent. The PageComponent class is derived from the ScrollComponent class and has an identical constructor.

To add a Layer to a PageComponent, you need to use the addPage function. The following code shows you how to create a PageComponent and add a few image layers to it:

The result looks like this:

Paginated scrolling

5. Managing Animations

You already know that you can use the animate function to animate the properties of a Layer object. However, calling animate starts the animation immediately. If you want to have control over when an animation starts or stops, you can use Animation objects instead.

Here’s how you create an Animation object:

You can then use the intuitively named start, stop, and reverse functions to manage the animation. For example, to start the animation invoke the start function:

You can also add event handlers to Animation objects, using the on function. This feature can be used to create chained animations. For example, here’s a code snippet that reverses animation1 when the animation ends:

The animation would look like this:

Managed animation

6. Changing Device Orientation

All the examples I showed you till now rendered the mobile device in portrait orientation. If you want to use the landscape orientation, you need to assign the value 90 to the orientation property of the DeviceComponent.

In the browser, the device will now look like this:

Landscape orientation

To animate the change in orientation, you use the setOrientation method, passing in true as its second parameter.


In this tutorial, you learned how to make use of Framer’s more advanced features, such as nested or embedded layers, layer effects, scrolling containers, and animation events. With a little bit of creativity and effort, you can now create stunning prototypes using the Framer framework. Here are some beautiful mock-ups to inspire you.

Refer to Framer’s Documentation to learn more about this powerful prototyping framework.

Continue Reading

by admin