In Web Apps

532 Views November 2, 2015 Be first to comment

[vc_row][vc_column width=”2/3″][cq_vc_flipbox frontfullimage=”2461″ backtitle=”VISIT THIS PROJECT” backcontent=”(opens a new tab/window)” backcontentcolor=”#ffffff” backbutton=”CLICK HERE” backbuttonbg=”#bd0000″ backbuttonhoverbg=”#ff1919″ flipdirection=”rightleft” cardstyle=”customized” backbg=”#000000″ isshadow=”cq-noshadow” avatarsize=”” elementwidth=”100%” elementheight=”393px” elementmargin=”5px 0 0 0″ backbuttonlink=”||target:%20_blank” link=”||target:%20_blank”][/vc_column][vc_column width=”1/3″][vc_column_text]Project Title:

Purpose: Entertainment News Blog

Technologies: WordPress, PHP, HTML5, CSS3, Javascript, Photoshop[/vc_column_text][cq_vc_cqbutton buttonlabel=”OPEN PROJECT” icon=”hand-o-up” iconposition=”left” buttoncolor=”#ffffff” buttonbackground=”#bd0000″ link=”||target:%20_blank” extra_class=”btn-project”][/vc_column][/vc_row]

Continue Reading

by admin


In Web Apps

Purple Haze Liqueur

451 Views October 31, 2015 Be first to comment

[vc_row][vc_column width=”2/3″][cq_vc_flipbox frontfullimage=”2467″ backtitle=”VISIT THIS PROJECT” backcontent=”(opens a new tab/window)” backcontentcolor=”#ffffff” backbutton=”CLICK HERE” backbuttonbg=”#bd0000″ backbuttonhoverbg=”#ff1919″ flipdirection=”rightleft” cardstyle=”customized” backbg=”#000000″ isshadow=”cq-noshadow” avatarsize=”” elementwidth=”100%” elementheight=”393px” elementmargin=”5px 0 0 0″ backbuttonlink=”||target:%20_blank” link=”||target:%20_blank”][/vc_column][vc_column width=”1/3″][vc_column_text]Project Title: Purple Haze Liqueur

Purpose: Informational website to introduce a new Liqueur called “Purple Haze”.

Technologies: WordPress, PHP, HTML5, CSS3, Javascript, Photoshop[/vc_column_text][cq_vc_cqbutton buttonlabel=”OPEN PROJECT” icon=”hand-o-up” iconposition=”left” buttoncolor=”#ffffff” buttonbackground=”#bd0000″ link=”||target:%20_blank” extra_class=”btn-project”][/vc_column][/vc_row]

Continue Reading

by admin


In Web Apps

502 Views October 31, 2015 Be first to comment

[vc_row][vc_column width=”2/3″][cq_vc_flipbox frontfullimage=”2463″ backtitle=”VISIT THIS PROJECT” backcontent=”(opens a new tab/window)” backcontentcolor=”#ffffff” backbutton=”CLICK HERE” backbuttonbg=”#bd0000″ backbuttonhoverbg=”#ff1919″ flipdirection=”rightleft” cardstyle=”customized” backbg=”#000000″ isshadow=”cq-noshadow” avatarsize=”” elementwidth=”100%” elementheight=”393px” elementmargin=”5px 0 0 0″ backbuttonlink=”||target:%20_blank” link=”||target:%20_blank”][/vc_column][vc_column width=”1/3″][vc_column_text]Project Title:

Purpose: Ecommerce website to sell male endurance spray.

Technologies: WordPress, WooCommerce, PHP, HTML5, CSS3, Javascript

[/vc_column_text][cq_vc_cqbutton buttonlabel=”OPEN PROJECT” icon=”hand-o-up” iconposition=”left” buttoncolor=”#ffffff” buttonbackground=”#bd0000″ link=”||target:%20_blank” extra_class=”btn-project”][/vc_column][/vc_row]

Continue Reading

by admin


In Modded News

Fix the WordPress Top Admin Bar

394 Views August 16, 2015 Be first to comment

Does your site header get overtaken by the WordPress Top Admin bar??? It’s annoying and if you don’t know what you’re doing, you can really mess things up trying to fix it. So here’s the right way to deal with it, and it only takes a moment to do…


Open up the header.php file and just before the < /head > tag add this (modify it to suit your code):

I hope this helps some poor soul out there.


Continue Reading

by admin


In Coding, From the Web, Grids, Layouts, Preprocessors

Smarter Grids With Sass And Susy

355 Views July 20, 2015 Be first to comment


If you’re a designer, you’ll know that grids are your friends. More often than not, they’re the vital architecture that holds a beautiful design together; they create rhythm, structure your page, lead the eye, and prevent the whole thing collapsing in a sloppy mess.

Smarter Grids With Sass And Susy

I’m a firm advocate for designing with the browser: prototyping with HTML and CSS has many clear advantages over static Photoshop comps, which have less value for the responsive web. Unfortunately, HTML, CSS and grids aren’t natural bedfellows: the progression of web standards over the years has been lacking in this area, meaning we have to grapple with floats (which were never designed to be used this way) and clearfixes — not ideal when you want to spend less time debugging layout and more time crafting experiences.

The post Smarter Grids With Sass And Susy appeared first on Smashing Magazine.

Continue Reading

by admin


In From the Web

Remix CodePen Challenge: Winners Announced!

320 Views July 20, 2015 Be first to comment

One month ago we set you a challenge: to remix an HTML and CSS profile card on CodePen as creatively as possible. A massive 154 of you took part–and today we’re very happy to announce the three prizewinners!

How we Selected the Winners

The judges panel comprised an Editor (me), a Designer, a Project Manager, a UX Specialist, an SEO Pro and a Front-end Developer from the team at Envato. Together we whittled down the collection by examining each pen’s creativity, execution, personality, originality and UX. It was a difficult process, but the three which received the most votes are listed below! 

Drumroll please..

Third Place: Yegor Borisenco

Great bit of Sass and animation, with plenty of personality!

Yegor wins:

  • $50 PayPal Prize
  • 1-year CodePen Pro Account
  • 3-month subscription to Tuts+
  • Envato Studio 20% discount voucher

Second Place: David Jones

Hit Rerun (bottom right of the pen) to fully appreciate what David’s done..

David wins:

  • $100 PayPal prize
  • 1-year CodePen Pro Account
  • 3-month subscription to Tuts+
  • $50 Envato Studio voucher

First Place: Dion Pramadhan

Our judges couldn’t help but be charmed by this one, well done Dion!

Dion wins:

  • $200 PayPal Prize
  • CodePen Tee Shirt and Swag Bag
  • 1-year CodePen Pro Account
  • 1-year subscription to Tuts+
  • $150 Envato Studio voucher
  • A “Won a Contest“ badge on Envato Market

Great Job Everyone!

A well-deserved congratulations to our winners! We’ll be in touch shortly with details on how to get hold of the goodies.

Thank you to everyone who took part–selecting the best from these entries (don’t forget the check out the collection to see what you were all up against) was no easy task. Thanks to the judges team for lending us their expertise. Lastly, thanks must go to PayPal and the guys at CodePen for stumping up superb prizes. If you didn’t win, better luck next time, we hope to see you in another challenge!

Continue Reading

by admin


In From the Web

Getting Started With the Instagram API: Media Endpoints

462 Views July 20, 2015 Be first to comment

Final product image
What You’ll Be Creating

This is part two of a series on the Instagram API. In this tutorial, I’ll guide you through using Instagram’s Media Endpoints, which allow you to search for popular images from a specific time and place. 

You can download code for each episode by using the GitHub repository link in the sidebar. You may also be interested in my two-part Tuts+ series, Locating Potential Crime Scene Witnesses With Social Media APIs

The code for these tutorials is written in PHP using the Yii Framework. You can learn more about Yii in Introduction to the Yii Framework (Tuts+) and in the Programming With Yii2 Series (Tuts+). You can also easily adapt the code segments for your own PHP application.

I do participate in the discussions. If you have a question or topic suggestion, please post a comment below. You can also reach me on Twitter @reifman or email me directly.

Let’s begin by registering as a developer with Instagram.

Getting Started

To get started, visit the Instagram API page for developers and click Register Your Application:

Instagram Hello Developers

You’ll need to sign up for a developer account:

Instagram Developer Signup

Then you can register a new application to receive your Client ID:

Instagram New Client Registration

On the Manage Clients dashboard, you’ll see your Client ID and Client Secret, so make note of these:

Instagram Manage Clients

Using the Media Endpoints

As web service APIs go, the Instagram API is robust, and in my experience works very well. Instagram offers a handful of API endpoints:

Instagram API Documentation Overview and Endpoints

For this tutorial, we’ll focus on the Media endpoints:

Instagram API Media Endpoints

With Media endpoints, you can retrieve information about an Instagram photo or video by referencing its ID or the shortcode from its URL, e.g. 0EyZ53Ja9X from It also provides geosearch capabilities to find media posted from a specific time and place as we did in Locating Potential Crime Scene Witnesses With Social Media APIs. And finally, it allows you to retrieve popular, trending Instagram posts.

The API Console

To help you get started and debug, Instagram has an API console powered by Apigee:

Instagram API Console powered by Apigee

You can try out queries against the Media endpoints using the API console. Here’s an example result for media/popular:

Obviously, you can see how useful this is for working with media from the popular mobile photography service.

Let’s move on to installing our sample codebase and configuring it to work with your Instagram client application.

Installing the Codebase

For this series, I’m going to continue to build on the Eyewitness codebase from Locating Potential Crime Scene Witnesses With Social Media APIs. You can clone the GitHub repository located in the sidebar to run our sample code.

You’ll need to configure your local Apache configuration. I use MAMP, so it looks something like this:

You need to create a database locally. I use PHPMyAdmin to create one graphically:

Create your Eyewitness database

Then I create an initialization file in /var/secure/eyew.ini with my database credentials and Instagram IDs and keys. I described this process recently in another Tuts+ tutorial: Protecting Your Keys From GitHub.

My ini file looks like this:

Update your Composer and its vendor libraries:

Then initialize our database. The first migration installs user tables for our Yii2-User by developer Dmeroff extension, and the second creates our app-specific tables:

Again, you can learn more about setting up a Yii Framework application in my Programming With Yii2 series for Tuts+.

Here’s the MySQL schema for our Instagram image table—we call it the Gram table. We’ll use it to store geosearch results.

The Home Page

I’ve renamed the sample application “Instapi”, short for Instagram API.

Here’s a look at what you should see when you visit the site in your browser:

Instagram API Sample Code Home Page

Performing Media Searches

To implement media searches in our Instapi application, I’m using Galen Grover’s Instagram PHP package.

Search Popular Images

First, let’s implement a search for media/popular. We’ll query the API and display the results in a table.

I’ve created an action called popular in GramController.php:

It calls searchPopular() in the Gram.php model:

In /views/gram/popular.php, we set up an HTML table structure:

and include the _item.php partial view to display individual media results:

Here are the results of Instagram media popular queries. Go ahead and refresh the page in your app. It’s fun to see what comes up next.

Instagram Media Popular Results Table

Look Up Information About an Image or Video

I’ve linked the Instagram media ID in the first column to a controller action that calls the media endpoint which gets us more information:

Here’s the lookup function in the Instagram model:

Here’s a screenshot of the data dumped to the screen:

Instagram API Media Information Dumped to Screen

Obviously, you could use and store this information however you would like.

Search for Media From a Time and Place

Now, let’s search for images from a specific time and place. For this example, I’ll review our Eyewitness example.

Our codebase allows you to define a moment as a place and time. It consists of a friendly descriptor, a location (latitude and longitude), a start time and a duration (in minutes). For my first example, I’m looking for Instagram users who were present at Macklemore’s video shooting on the evening of Wednesday, July 24, 2013 at Seattle’s landmark Dick’s Drive In.

Using Google Maps, I can get the GPS latitude and longitude for Dick’s. It’s 47.6195 -122.321. 

Dicks Drive In Broadway Seattle GPS in Google Maps

From the article, I learned that the production shut down at 1 am. I’m going to choose a start time of 10 pm and a duration of 3 hours.

Create a Moment

Instagram accepts start times in GMT so I’ve hardcoded an eight-hour time change adjustment from my timezone (PST). You may need to change this in the code.

To search Instagram, just click on the camera icon below:

The Moments Index Grid

The actual search is fairly straightforward: $instagram->searchMedia( $this->latitude, $this->longitude,$params ); 

The results are stored in the Gram table, which we can then browse:

Here’s the first page of results from my search. You can see the crowds and Macklemore’s Cadillac limo driving up.

Macklemore Search Results

Then on page three, an Instagram user named Joshua Lewis has a shot of Macklemore exiting the Cadillac: 

More Macklemore Search Results

Here’s Macklemore:

Macklemore Arrives on Instagram

This example clearly shows the power that the Instagram search API provides. In just a few moments, we found a variety of eyewitnesses to an event from the summer of 2013.

What’s Next?

I hope you’ve enjoyed learning about the Instagram API thus far. In the next episode, we’ll explore OAuth authentication so that we can query areas of the Instagram service that require user authorization.

In the meantime, please feel free to post your questions and comments below. You can also reach me on Twitter @reifman or email me directly. You can also browse my Tuts+ instructor page to see other tutorials I’ve written. 

Related Links

The preview image is modified from a result that came up in our API search. 

Continue Reading

by admin


In From the Web

The Beginners Guide to WooCommerce: Shipping Settings Part 2

328 Views July 19, 2015 Be first to comment

In our previous article we discussed how a store owner can configure the settings in the Shipping Options section. WooCommerce offers multiple shipping methods which you can implement to deliver items/products to your customers. Today I will be taking up every method separately in detail, explaining how you can configure the settings for these shipping methods.

WooCommerce Shipping Options menu

As a reminder, WooCommerce offers five different types of shipping methods. Each is listed on a separate sub-page in the Shipping Settings tab. They are:

  1. Flat Rate
  2. Free Shipping
  3. International Delivery
  4. Local Delivery
  5. Local Pickup

Flat Rate

We will start this article with the settings of shipping through the flat rate shipping option.


Enable or Disable shipping method

By now I am sure you know what the option for Enable/Disable means. You may enable this option if you want to offer shipping at a flat rate to your customers. 

Method Title

Method title

The field for Method Title will decide what text will be displayed to your customers if you are offering flat rate shipping. Once again WooCommerce has set a default value of Flat Rate at the time of plugin installation, but a store owner can set it to any custom value.

Cart showing Flat Rate Shipping Method text

The figure above shows that if we change this field to Flat Rate Shipping Method and save the changes then the same title will appear on the front-end.


Availability All allowed countries

You can limit the destinations where you will offer shipping at a flat rate. The option of Availability is a dropdown menu from which you can allow flat rate shipping to All allowed countries or to some Specific Countries. If you select some Specific Countries then you’ll have to choose the specific countries from another dropdown which appears next to this option.

Tax Status

Tax Status dropdown menu

An online store owner has the choice of applying taxes to the various shipping methods or not. You can add the cost of taxes like Value Added Tax (VAT) or the Sales Tax if you set the Tax Status option as Taxable. Otherwise you may select None and the shipping cost will not include any such tax.

Additional Rates

Additional Rates

In WooCommerce, if you are willing to implement some additional taxes other than the standard flat rates then you can use the function of Additional Rates. WooCommerce guides its users about how to fill the details in this setting. You will notice in the above figure that some attributes are displayed which are filled according to a particular format, i.e.

Option Name | Additional Cost [+-Percents%] | Per Cost Type (order, class or item)

Let’s see what these attributes denote:

  • Option Name: Here you will enter the names of shipping methods other than the flat rate, e.g. Express Shipping, Airmail Shipping, etc.
  • Additional Cost: This is the additional amount which will be applied on every product other than the base flat rate.
  • Per Cost Type: The attribute of Per Cost Type may apply to every class, order or item and will decide how this cost will be applied. 

Now I will explain how these Additional Rates can be set at the front-end with the help of an example.

Additional Rates

In the above figure I have added an additional price of 10.0 and 5.0 for the newly defined shipping rates of Express Shipping and Airmail Shipping, which will be applicable on every order. So, considering the fact that I have fixed £7.00 for shipping with flat rate, now the total charge for Express Shipping becomes £17.00 (10.0+7.0=17.00) and the Airmail Shipping becomes £12.00 (7.0+5.0=12.00). 

Shopping cart showing different shipping totals depending on shipping method

A customer who chooses shipping with flat rate will be charged £42.00 (35.0+7.0=42.00) whereas a person opting for the additional rate of Express Shipping will be charged £52.00 (35.0+17.0=52.00) for the same order. The difference in total cost was observed due to the selection of different shipping methods. (See above fig.)   

Additional Costs

Towards the end of this section we see some configurations that will control and manage various additional costs that will apply apart from the fixed flat rate. These settings include:

  • Costs Added…
  • Costs
  • Minimum Handling Fee

Costs Added

Costs Added dropdown menu

The settings in this field will decide how and on what basis the additional costs other than flat rate will apply. Here we see three different options. These costs may be applied:

  • per order: applicable on the entire order
  • per item: applicable on every single item
  • per class: applicable on the entire shipping class for a particular order


Costs options

The section for Costs is displayed in the form of a table where you can actually enter the cost of additional rates which will be applied per order, item or class. In this table you can see different columns. You can click the Add Cost button to add new fields in this table and click Delete selected costs to remove any field. You can find the following attributes in the table:

  • Shipping Class: This field defines various shipping classes of items that are added to the cart.
  • Cost: Here you will enter the applied cost, which will not include the tax rate.
  • Handling Fee: This is another kind of additional amount that will be added to your final product price. Here you will enter the data either in the form of numbers (e.g. 5.5) or in percentages (e.g. 4%).
  • Any class: If a user is defining the cost for a product’s shipping class then this field will apply.
Costs section showing additional amounts for cost and handling fee

For example, let’s fill the fields with the data shown in the above figure, where I have fixed Shipping Class=Any class; Cost=5; Handling Fee=2.5.

When I save these changes, the cart page will display new prices. So, when a customer selects flat rate shipping, the total price for the product is £49.50.

How £49.50?

Attributes Price (£)
Price of the product 35.00
Flat shipping rate 7.00
Additional cost 5.00
Handling fee  2.50
Total 49.50
Front end view showing the new rates as above

In the same manner you can calculate the total cost if a customer selects the option of Express Shipping Method or any other.

Minimum Handling Fee

Minimum Handling Fee

The last field for setting which you will see in this section is for the Minimum Handling Fee, which is the minimum amount which will always be charged to customers. If you do not want to apply this fee, then you may leave this field empty.

In the end, click the Save Changes button.

This setting completes the configuration of flat rate shipping. In the next article I will explain the rest of the settings for the remaining shipping methods. 

Continue Reading

by admin


In From the Web

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

764 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

304 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