code

Simple Methods of Adding SSL to Your WordPress Website

Posted on by Mario

SSL WORDPRESS

People choose SSL mostly because it provides more secure information and gives more benefits, especially from a user’s perspective, as any information they share with your site via a form, shopping cart, etc. is encrypted – it is safe from the third party. However, few web developers that know the very same principles also apply to site administrators.

In fact, running the WordPress admin in https also brings huge benefit, since you can secure all the sensitive information you input daily inside of WordPress. All of this information needs protection; therefore, it is essential for every WordPress website out there to renew the certificate in every three months.

If you are in a tight budget, you can opt on the market for low-cost certificates that do the job nicely in most cases. Remember that ecommerce sites might be better off with higher level certificates that offer features like identity validation which allows customer to know you better.

This makes us have no reason for not giving a little time and money to understand and apply an SSL certificate. So, if you are committed to integrating SSL with a WordPress installation, now it’s time to discover the ways.

HTTPS Your WordPress

Before, we setup WordPress to utilize an HTTPS connection; you have to make sure that you already have an SSL certificate installed on your server. Actually, it is quite simple to setup WordPress to utilize an https connection, as follows:

  • Back up the site
  • Change the Site URL
  • Ensure all internal links and attachments use https
  • Run the WordPress admin in https
  • Automatically forward http requests to https

Change the Site URL

First, navigate over to settings > General inside the WordPress administration area since you’ll want to change the WordPress Address (URL) and Site Address (URL) from ‘http://www.yourdomain.com’ to ‘https://www.yourdomain.com’. Scroll down to the bottom and save the changes when you’re done and then, WordPress will automatically log you out. If you want to log back, you can use the newly-secured URL.

Make Sure All Internal Links/Attachments Use HTTPS

Even though you change the URL, image or attachment URL throughout WordPress, it will not suddenly switch your website into HTTPS. In order to discover ways to change the URL site, you can conduct a search and replace area of your database. One thing for sure, you need to back up your site to prevent anything from going wrong.

Nowadays, you can find many searches and replace plugins available for WordPress, but you can give a try to Velvet Blues Update URLs, as it can be an effective solution. Furthermore, this plugin only touches the areas of the database that need changes, so you will not mistakenly change the right thing. In fact, you can update URLs to get started once you’ve installed and activated the plugin, head over to tools > Update URLs to get started.

Don’t worry as using plugin is as simple as adding the old and new URLs for your site. All you need to do is make sure that all the settings look are correct then click “Update URLs Now” when you’re ready and let the plugin take care of the rest. You’ll see a report on the screen that says how many URLs are changed and where the plugin found them, once the URLs have been replaced.

Run the WordPress Admin in HTTPS

In order to ensure that there will be HTTPS in the WordPress back end, you should grab the latest version of your site’s wp-config.php file and add the following line just above “/* That’s all, stop editing! Happy blogging. */”:


Now, you can save and upload the file to your server.

Automatically Forward http Requests to Https

The last step is to make sure that you only use https URLs for your site. First, you need to download the latest copy of your site’s .htaccess file and add the following just underneath the line “RewriteEngine On”:

Then save and upload the file to your server. You can try and enter an http URL for your site in a browser to test it. If you do it right, it should automatically forward you to the https version. Bear in mind that every server has been set up differently, so you should find other ways to make this work. Feel free to contact your web host for suggestions.

Troubleshooting a ‘Broken’ Lock

Discover if there are any broken padlock icons in your browser’s address bar and/or mixed content warnings. If you find any, then something is trying to load in from an http address. Usually, it is caused by a script or other outside resource being called from your site’s theme or CSS. As a solution, you can refresh the page and see if that clears up the issue.

If the problem is still going on, you can visit “Why No Padlock?” and input your URL that you want to analyze. The site will scan and analyze it for you.

Conclusion

Keeping user’s information private is an important thing, especially if you are doing a business in digital world. By seeing the green padlock in your site’s address, users will think that your business takes their personal information seriously. This will surely increase their trust and interest to buy something from you or even fill out a simple contact form.

Json-api-normalizer: Why JSON API and Redux Work Best When Used Together

Posted on by Mario

As a web developer, we have to manage the data needed for every application we work on. There are problems when doing so, such as:

  1. Fetch data from the back end.
  2. Store it somewhere locally in the front-end application.
  3. Retrieve the data from the local store and format it as needed by the specific view or screen.

In this article, we are going to discuss about the data usage from JSON, the JSON API and GraphQL back ends, and from that, we can learn the practical way on how to manage front-end application data. As for the real use, let’s imagine that we have carried out a survey that asks the same questions of many users. After each user has given their answers, other users can comment on them if wanted to. Our web app will perform a request to the back end, store the gathered data in the local store and render the content on the page. In order to make it stay simple, we will leave out the answer-creation flow.

Redux Best Practices

What makes Redux the best is that it is changeable no matter what kind of API you consume. It doesn’t matter whether you change your API from JSON to JSON API or even GraphQL and back during development, as long as you keep your data model, so it will not affect the implementation of your state management. Below is the explanation on the best practice using Redux:

  1. Keep Data Flat in the Redux Store

First, here’s the data model:

 

 

Based on the picture above, we have a question data object that might have many post objects. It is possible that each post might have many comment objects. Each post and comment has respectively one author.

Let’s say we have a back end that returns a specific JSON response. It is possible that it would have a carefully nested structure. If you store your data in the same way you do in the store, you will face many problems after that, like, for instance, you might store the same object many times like this:

{

  “text”: “My Post”,

  “author”: {

    “name”: “Yury”,

    “avatar”: “avatar1.png”

  },

  “comments”: [

    {

      “text”: “Awesome Comment”,

      “author”: {

            “name”: “Yury”,

        “avatar”: “avatar1.png”

      }

    }

  ]

}

In the example above, it indicates that we store the same Author object in several places, which is bad, because not only does it need more memory but it also has negative side effects. You would have to pass the whole state and update all instances of the same object especially if somebody changed the user’s avatar in the back end.

To prevent something like that from happening, we can store the data in a flattened structure. This way, each object would be stored only once and would be easily accessible.

{

  “post”: [{

    “id”: 1,

    “text”: “My Post”,

    “author”: { “id”: 1 },

    “comments”: [ { “id”: 1 } ]

  }],

  “comment”: [{

    “id”: 1,

    “text”: “Awesome Comment”

  }],

  “author”: [{

    “name”: “Yury”,

    “avatar”: “avatar1.png”,

    “id”: 1

  }]

 }

  1. Store Collections as Maps Whenever Possible

After we have the data in a good flat structure, we can gradually accumulate the received data, in order for us to reuse it as a cache, to improve performance or for offline use. However, if we combine new data in the existing storage, we have to select only relevant data objects for the specific view. We can store the structure of each JSON document separately to find out which data objects were provided in a specific request to gain this. There is a list of data object IDs that we can use to gather the data from the storage.

Let’s say there is a list of friends of two different users, Alice and Bob. We will then perform two requests to gather the list and review the contents of our storage consequently. Let’s suppose that from the start the storage is empty.

/ALICE/FRIENDS RESPONSE

Here’s the User data object with an ID of 1 and a name, Mike, like this:

{

  “data”: [{

    “type”: “User”,

    “id”: “1”,

    “attributes”: {

      “name”: “Mike”

    }

  }]

}

/BOB/FRIENDS RESPONSE

This is another request that would return a User with the ID of 2 and Kevin as the name:

{

  “data”: [{

    “type”: “User”,

    “id”: “2”,

    “attributes”: {

      “name”: “Kevin”

    }

  }]

}

STORAGE STATE

This is what our storage state would look like:

{

  “users”: [

    {

      “id”: “1”,

      “name”: “Mike”

    },

    {

        “id”: “2”,

        “name”: “Kevin”

    }

  ]

}

STORAGE STATE WITH META DATA

In order to find out or distinguish which data objects in storage are relevant, we have to keep the structure of the JSON API document. With that focus, we can change it into this:

{

  “users”: [

    {

      “id”: “1”,

      “name”: “Mike”

    },

    {

        “id”: “2”,

        “name”: “Kevin”

    }

  ],

  “meta”: {

      “/alice/friends”: [

        {

          “type”: “User”,

          “id”: “1”

        }

      ],

      “/bob/friends”: [

        {

          “type”: “User”,

          “id”: “2”

        }

      ]

  }

}

With this, we can now read the meta data and gather all mentioned data objects. Now here’s the recap of the operations’ complexities:

As can be seen from the picture above, maps certainly works better than arrays because all operations have O(1) as the complexity instead of O(n). If we use a map instead of an array for the User data object, it would be like this:

STORAGE STATE REVISED

{

  “users”: {

      “1”: {

        “name”: “Mike”

      },

      “2”: {

        “name”: “Kevin”

      }

  },

  “meta”: {

      “/alice/friends”: [

        {

          “type”: “User”,

          “id”: “1”

        }

      ],

      “/bob/friends”: [

        {

          “type”: “User”,

           “id”: “2”

        }

      ]

  }

}

Now with this simple method, we can find a specific user by ID almost instantly.

Processing the Data and JSON API

There are many solutions to convert JSON documents to a Redux-friendly form. However, while there is no significant change within the application’s lifecycle, it will cause a failure if things are too dynamic, even though normalizing the function with the provision of a JSON document works great if your data model is known in advance.

Using GraphQL might be possible and interesting as well; however, if our APIs are being consumed by many third parties, we can’t adopt it.

JSON API and Redux

Redux and the JSON API work best together. The data provided by the JSON API in a flat structure by definition conforms nicely with Redux best practices. The data is typified in order to be naturally saved in Redux’s storage in a map with the format type → map of objects.

There are things to consider, though. First, it should be noted that storing the types of data objects “data” and “included” as two separate entitles in the Redux store can violate Redux best practices, as the same data objects would be stored more than once.

To solve these problems, we can use the main features of json-api-normalizer, such as:

  • Merge data and included fields, normalizing the data.
  • Collections are converted into maps in a form of a id=> object.
  • The response’s original structure is stored in a special meta

First, in order to solve problems with redundant structures and circular dependencies, the introduction of the distinction of data and included data objects in the JSON API specification is needed. Second, there is a constant update on data in Redux, although gradually, that can help with the performance improvement.

 Now that you know why JSON API works best with Redux, it can be concluded that this approach can assist us in prototyping a lot faster and flexible with changes to the data model. If you are in doubt whether using Redux with JSON API or not, this article will help you find the solution and reason why you shouldn’t doubt this method.

Myths and Realities of Replaced elements in HTML

Posted on by Mario

Replaced Elements in HTML Myths and Realities - YWF (2)

According to official specs, replaced elements are content outside the scope of the CSS formatting model, such as an image, embedded document, or applet. For instance, the content of the HTML IMG element is often replaced by the image that its src attribute designates. Besides, replaced elements often have intrinsic dimensions, such as an intrinsic width, an intrinsic height, and an intrinsic height specified in absolute units. Now, you may have a general description of what a replaced element is, but as a web developer, you have to look deeper about replaced elements.

Replaced Elements in the Real World
To discuss in a full description about the replaced elements, we need to go to a different resource, namely the Rendering section of the HTML Living Standard document. But, when you look deeper, the specs can be confusing. This is because some HTML elements operate as replaced elements all the time, while other do it only in specific circumstances.

Embedded Content
Embedded content is the first category of replaced elements. Embedded content means any element that imports another resource into the document, or content from another vocabulary that is inserted into the document. While these external resources have the intrinsic dimensions that match the requirements of the definition.

Embed, iframe, and video are the main elements in this category. Since they always import external content into your document, these elements are always treated as replaced elements. There are more elements that a bit more complicated that fall into this category only in special circumstances, such as:

  • applet – Treated as a replaced element when it represents a plugin, otherwise it’s treated as an ordinary element.
  • audio – Treated as a replaced element only when it is “exposing a user interface element”. Will render about one line high, as wide as is necessary to expose the user agent’s user interface features.
  • object – Treated as a replaced element when it represents an image, plugin, or nested browsing context (similar to an iframe).
  • canvas – Treated as a replaced element when it represents embedded content. That is, it contains the element’s bitmap, if any, or else a transparent black bitmap with the same intrinsic dimensions as the element.

Images
Images are others elements that treated as a replaced element with the intrinsic dimensions of the image. This category also includes the input elements with a type=”image” attribute.

When the image is not rendered on the page, things get a bit more complicated for several reasons. The <input type=”image”> will be displayed as a normal button.

Default Size of Replaced Elements
We can understand this elements by these three basic rules:

  • if the object has explicit width, height and ratio values, use them;
  • if the object only has ratio, use auto for both width and height while maintaining the said ratio;
  • if none of these dimensions are available:
    – use width: 300px; height: 150px when the viewport is larger than 300px
    – use “auto” for both width and height and a ratio of 2:1 when the viewport is smaller than 300px;

What About the Other Types of Form Controls?
There are many misconceptions about other types of form controls are replaced elements too. After all, these elements are also rendered with a default width and height. In fact, most people consider intrinsic dimensions actually comes from the following line:

Each kind of form control is also described in the widgets section, which describes the look and feel of the control. Another reason why form control looks different from one browser to the next and from one OS to another:

The elements defined in this section can be rendered in a variety of manners, within the guidelines provided below. User agents are encouraged to set the ‘appearance’ CSS property appropriately to achieve platform-native appearances for widgets, and are expected to implement any relevant animations,etc, that are appropriate for the platform.

Conclusion
It is easy to get confused about replaced elements and form controls. But, they are different categories of HTML elements, with <input type=”image”> being the only form control that is a replaced element.