geek

5 ways for Creating Better, Faster and More Optimized WordPress Websites

Posted on by Mario

Creating better faster and more optimized wordpress websites

There are always new updates in WordPress, so that every developer should learn the latest optimization practices.  But, mostly seasoned developers focus on what they are good at. Then, neglect or don’t have time to learn the latest optimization practices. If you happen to be one among those kinds of web developers, you need to read the following tips. This article can help you create better, faster and more optimized WordPress sites.

  1. Switching Hosts Isn’t Always a Quick Fix

If you think that switching hosts will automatically fix certain problems, you may need to reconsider your opinion. In fact, you still experience some code issues or compatibility problems with specific plugins even though you have changed your host. A managed host will provide as much assistance as they can, but won’t debug an issue with a bad plugin or code for you. Therefore, you need a WordPress developer to dig into it and make a determination as to what the issue is. In fact, to solve these problems, many hosts provide third-party partners and developers.

  1. Don’t Try Editing Your Code

To avoid WordPress sites go down, you need to make sure that no one is editing a PHP file directly from the appearance editor in the dashboard. But, how? You can use the following code in your wp-config.php file, removing the edit_themes, edit_plugins, and edit_files capabilities for all users. This method will prevent users to hack away at the code and break the site.

define(‘DISALLOW_FILE_EDIT’, true);

Take this process one step further to update themes or install plugins and remove the functionality for clients to update. Place the following code in your wp-config.php file to restrict these capabilities.

define(‘DISALLOW_FILE_MODS’, true);

  1. Don’t Cut Corners on Your Themes and Plugins

WordPress might be the foundation of your site, but the themes and plugins are also important elements. Therefore, you need to choose your plugins carefully. Do a little research and look for its ratings and reviews beforehand.

Recent research even shows that nearly 50% of the plugins in the repository haven’t been updated in over 2 years. This makes these themes and plugins are easy to get infected with malware. Another thing to be on the lookout for is a bundled plugin that should be updated. This surely will cause a huge problem for WordPress users who buy things via online marketplace. On the other hand, this method will open a wide chance for hackers and site owners are extremely vulnerable.

  1. Watch Your Admin AJAX Calls

Inspect any plugins that may utilize AJAX, for instance, the WordPress Heartbeat API uses /wp-admin/admin-ajax.php to run AJAX calls from the web-browser. Mostly these kind of files occurs during  traffic spikes, CPU load, and can bring your site to a crawl.

If you find there are 3rd party plugins that utilize admin-ajax.php, make sure that everything runs in the correct way. Besides, you can figure out what plugins might be causing it by looking at the HTTP POST request action and quickly determine, based on its name. However, AJAX does load after the page loads.  So, this is not always a bad thing to see this in a speed test.

  1. Ensure PHP 7/HHVM Compatibility Before Jumping on Board

Nothing can beat PHP7 and HHVM when it comes to boosting WordPress performance. But, before you are tempted to use these programs, you need to make sure that your site is compatible with the program. This means before you are upgrading from PHP 5.6 to 7, you need to test all functionalities of your WordPress site in a staging environment or locally to ensure there aren’t any compatibility issues.

Best Practices for API Error Handling

Posted on by Mario

Best-Practices-for-API-Error-Handling

As a web developer, we all don’t want to see Error codes in an API response, neither do you. When it happens to you, it can mean one of two things — there was something wrong in your request or your handling that the API simply couldn’t parse the passed data, or the API itself has so many problems. In either situation, traffic comes to a sudden end, and we start trying to discover the cause and solution for that.

Although being unpleasant, errors, whether in code form or simple error response, are incredibly useful. Error codes are probably the most useful diagnostic element in the API space.

Today, we’re going to discuss about the importance and the usefulness of error responses and handling approaches. There are some common error code classifications the average user will encounter, as well as some examples of these codes in action that you need to know.

The Value of Error Codes
As explained above, error codes are surprisingly, but incredibly useful. Error codes in the response stage of an API are essential in communicating failure from a developer to a user. This stage is a direct communication between client and API. It’s considered as the most important step towards informing the user of a failure, as well as boosting the error resolution process.

An error comes randomly and sometimes it’s beyond our knowledge. That’s why error responses are the only constant, consistent communication that we, as the user, can rely on when an error has occurred. Error codes can both clarify the situation, as well as communicate the intended functionality.

For example, an error code such as “401 Unauthorized – Please Pass Token.” You understand the point of failure in that response, especially that the user is unauthorized. However, you also figure out the intended functionality, which means that the API requires a token, and that token must be passed as part of the request in order to obtain authorization.

With a simple error code and resolution explanation, you have already identified the cause of the error, as well as the intended functionality and method to fix that error. It is very useful, especially for the amount of data that is actually returned.

HTTP Status Codes
Before we deeply discuss about error codes and what makes a code good, we need to sort out the HTTP Status Codes format. These codes are the most frequent status codes that the average user will encounter, not only in terms of APIs but also in terms of general internet usage. Although there are other protocols and have their own system of codes, the HTTP Status Codes dominate API communication, and vendor-specific codes tend to be derived from these ranges.

  • 1XX – Informational

The 1XX range has two basic functionalities. First, in the transfer of information concerning the protocol state of the connected devices — for example, 101 Switching Protocols is a status code noting that the client has requested a protocol change from the server, and that the request has been approved. The 1XX range also elucidates the state of the initial request. For example, 100 Continue, notes that a server has received request headers from a client, and that the server is waiting for the request body.

  • 2XX – Success

The 2XX range notes a range of successes in communication, and combines several responses into specific codes. The first three status codes excellently determine this range, like 200 OK means that a GET or POST request was successful, 201 Created indicates that a request has been brought to completion and a new resource has been created for the client, and 202 Accepted shows that the request has been accepted, and that processing has begun.

  • 3XX – Redirection

The 3XX range is all about the status of the resource or endpoint. When this kind of status code is sent, it confirms that the server is still accepting communication, but that the contacted point is not the accurate point of entry into the system. 301 Moved Permanently denotes that the client request did reach the correct system, but this request and all future requests should be managed by a different URI. This is very convenient both in subdomains and in moving a resource from one server to another.

  • 4XX – Client Error

The 4XX series of error codes is probably the most well-known because of the famous 404 Not Found status, which is a prominent marker for URLs and URIs that are formed in the wrong way. However, other more useful status codes for APIs are in this range.

414 URI Too Long is a common status code, indicating that the data pushed through in a GET request is too long, and should be changed into a POST request. Another common code is 429 Too many Requests, which is used for rate limiting to note a client is attempting too many requests simultaneously that their traffic is being rejected.

  • 5XX – Server Error

The 5XX range is reserved for error codes notably related to the server functionality. Whereas the 4XX range is the client’s responsibility (meaning that it is a client failure), the 5XX range explicitly notes failures with the server. Error codes such as 502 Bad Gateway, which marks the upstream server, has failed and that the current server is a gateway, further reveal server functionality as a method of showing where failure is transpiring.

Making a Good Error Code
With a strongly-built comprehension of HTTP Status Codes, we can start analyzing what actually makes for a good error code, and what makes for a bad error code. Quality error codes not only convey what went wrong, but also why it went wrong.

Excessively obscure error codes are very inconvenient. Imagine that you are trying to make a GET request to an API that manages digital music inventory. You’ve submitted your request to an API that usually accepts your traffic, you’ve passed the correct authorization and authentication credentials, and you think the server is ready to respond.

You send your data, and receive this kind of error code: 400 Bad Request. Without additional data and without more information, what does this mean? It’s in the 4XX range, so you know the problem was on the client side, but it doesn’t explain and solve anything, other than “bad request.”

This explains that a “helpful” error code is not as helpful as it should be. We could easily make that same response helpful and clear with less effort. Good error codes must pass three essential criteria in order to be functional, such as:

  • An HTTP Status Code, so that the source and realm of the problem can be confirmed with ease;
  • An Internal Reference IDfor documentation-specific notation of errors. In some cases, this can substitute the HTTP Status Code, as long as the internal reference sheet inserts the HTTP Status Code scheme or similar reference material.
  • Human readable messagesthat conclude the context, cause, and solution for the existing error.

From this discussion, we can conclude that error codes are useful if inserted with messages conveying what goes wrong and why it goes wrong, topped off with the human readable messages emphasizing the solution that we can take and do to handle it. That way, we can effortlessly handle it when future errors occur spontaneously.

3 JavaScript Libraries to Look Up for in 2017

Posted on by Mario

3-javascript-libraries-to-look-up-for-in-2017

For some web developers, JavaScript’s ecosystem can be fatigue. Especially this year where there is a lot of tooling and configuring is required. So, to make your work easier, we submit a list of 3 generic libraries/frameworks for front-end development.

Vue.js

If you haven’t put any attention on Vue.js before, now you have to keep your eyes on. It is a tiny JavaScript framework which seems to primarily focus on views and give you only a handful of tools to regulate data for those views. Moreover, Vue.js is also good for a change as it doesn’t get stuffed with programming design pattern and limitations.

There are two types of Vue.js. A stand-alone version that includes the template compiler and the runtime version that doesn’t. You can see its simplicity, through an example of a component that shows a message and brings interactivity to a button to reverse the message.

<div id="app">
  <p>{{ message }}</p>
  <button v-on:click="reverseMessage">Reverse Message</button>
</div>

import Vue from 'vue'

new Vue({
  el: '#app',
  data: {
    message: 'Hello World!',
  },
  methods: {
    reverseMessage: function () {
      const reversedMessage = this.message
        .split('')
        .reverse()
        .join('');

      this.message = reversedMessage;
    },
  },
});

Don’t you worry about the existence of other plugins, as you still can find them on Vue.js. In fact, several guides are available to use there. This framework will be suitable for you, especially if you wish to have productive fast. It also scales well as the project grows.

Svelte

Svelte must be the latest JavaScript Libraries as it has been released in mid-November 2016. At some point, it may looks similar to Vue.js, but leaves a smaller footprint. “Traditional” frameworks need runtime code to define and execute modules; keeps state, update the views and do whatever frameworks do. Moreover, with Svelte you can dissolve into clean JavaScript code as of you didn’t use a framework at all. The big advantages that you can get is that its file size.

Svelte has plugins so you can compile the source code using Webpack, Browserify, Rollup or Gulp.

You can use the below example of creating the Vue.js example with Svelte as a comparison:

<p>{{ message }}</p>
<button on:click="reverseMessage()">Reverse Message</button>

<script>
export default {
  data () {
    return {
      message: 'Hello World!',
    }
  },
  methods: {
    reverseMessage () {
      const reversedMessage = this.get('message')
          .split('')
          .reverse()
          .join('');

      this.set({
        message: reversedMessage,
      });
    }
  }
};
</script>

The very same module created with Vue.js produces a 7kb bundle. Svelte produces a 2kb file.

In terms of performance, Svelte competes with Inferno. This makes Svelte becomes a good choice if you care about your application’s footprint. At the time of writing, Svelte either doesn’t have its plugin system documented, or doesn’t have one at all. The TODO indicates that Svelte will support plugins and might have an API to hook into the framework.

The compatibility of the compiled code depends on your build workflow stack, so it’s hard to say what its default compatibility is. Technically you should be able to achieve pre-ES% support by including ES5 shims.

To conditionally load and invoke modules, Conditioner.js is one of the good choices. The difference from other module loaders is that conditioner.js allows you define conditions under which to load and/or show a module. This results in reducing loading time and saving bandwidth.

However, you better already have functional components in place that are enhanced with a given JavaScript module. How those modules are defined is entirely up to you. You could even make it load modules from your favorite framework.

To get started, you can install it via npm: npm install conditioner-js.

The demo is unlike previous ones to better illustrate Conditioner.js’ features. Imagine we wish to show the time remaining to an event. A module is shown like this:

import moment from 'moment';

export default class RelativeTime {
  /**
   * Enhance given element to show relative time.
   * @param {HTMLElement} element - The element to enhance.
   */
  constructor(element) {
    this.startTime = moment(element.datetime);

    // Update every second
    setInterval(() => this.update(), 1000);
    this.update();
  }

  /**
   * Update displayed relative time.
   */
  update() {
    element.innerHTML = this.startDate.toNow();
  }
}

It is so simple to initialize the module:

<time datetime="2017-01-01" data-module="ui/RelativeTime">2017</time>

Conditioner will then load the ui/RelativeTime module at this location in the DOM. Note the content is already present and in an acceptable format and the module only enhances that.

If you want a module to initialize only when it’s visible to a user, you can do so with conditions:

<!-- Show RelativeTime only if it is visible to the user -->
<time datetime="2017-01-01" data-module="ui/RelativeTime" data-conditions="element:{visible}">2017</time>
<!-- Keep showing RelativeTime after it was visible to the user -->
<time datetime="2017-01-01" data-module="ui/RelativeTime" data-conditions="element:{was visible}">2017</time>

Conditioner.js has quite an extensive list of monitors, which you use to define conditions. Don’t fret! You only have to include those you need, preventing the inclusion of unnecessary code.

You can also pass along options as a JSON string or a slightly more readable JSON variant.

<!-- JSON variant -->
<div data-module="ui/RelativeTime" data-options='unit:"seconds"'>...</div>
<!-- Or good old JSON -->
<div data-module="ui/RelativeTime" data-options='{"unit":"seconds"}'>...</div>