Web Programmer and Developer are very much familiar with the local development environment URL “localhost”. But seeing the same URL sometimes made us boring and wish to have a custom URL. Many of you may have the desire that instead of “localhost”, it could be something else! Right?

Let’s figure out the new URL first, we may name it development.rs. Don’t confused with rs. It’s mean RangpurSource, my company name. So, we’re going to set our new custom local development environment URL to development.rs from localhost.

Before begin, note that I’m working with the WAMP, so all the “www” will be replaced with “htdocs” if you’re using XAMPP.

So, Let’s BEGINS –

Step 1

Go to C:\wamp\bin\apache\Apache2.2.17\conf\ and open httpd.conf file and change #Include conf/extra/httpd-vhosts.conf to Include conf/extra/httpd-vhosts.conf. Just uncomment the line so that it can include the virtual hosts file.

Step 2

Go to C:\wamp\bin\apache\Apache2.2.17\conf\extra and open httpd-vhosts.conf file and add the following code

Step 3

You maybe got an error called access denied or file cannot be edited and save, this is because of windows file security. Just edit the file as an administrator mode and you’ll be getting what you’ve expected.

Today, I’m going to write about the process of activating/enabling an additional language and the process of adding a completely new language that is not present in the plugin system.

Let’s BEGINS…

Activating/enabling additional language

Like before, go to Settings > Languages then select the Languages tab

In this page, you could the list of languages in the right side that is auto integrated (aka: configured already).

Now you just need to click on the Enable link to activate the desired language into your website. I activated the Italiano language.

So, you can now visit your page or post editor and see, the new language is come to there.

Essentially, if you need any other settings in that language, go into the Edit link. But I will be talking on that matter in the other article in this series.

Adding new language in Q-Translate:

You may be wondering that there is no such language in your country flag or your own. Yes, I myself wondering that much because I’m from Bangladesh and by default Bangla (Bengali) was not configure there as other were. So, here I’m going add the language and showing you the process of how could you add your own language also.

Let’s getting in…

Similarly as before, go to in the Languages tab, here you’ll be finding a section called Add language at the left hand side.

The first step is to add the language code, this code is the main fact for integration of the new language. Don’t worry, the language code is given in the ISO Language Code’s website. The URL is – https://www.w3.org/WAI/ER/IG/ert/iso639.htm#2letter Here you can find all the ISO standard code for languages for all countries. So, I need ISO code for language “Bengali”, I just find the text “Bengali” and here it is –

Now add the country flags from the Flag dropdown. Mine is bd.png

You shall find your flag also. But if you don’t find the flag, don’t worry go to your WordPress installation directory then go to plugins > qtranslate-x > flags directory and copy paste your flag in a .png format with a size of width = 18px and height = 12px. Then come to the Languages tab again and refresh the window, you shall now find your flag in the dropdown.

And then click on the Add Language button.

The Languages tab will be redirected to this current page and you can now see the newly added language is present at the bottom of the other languages.

Click on the Enable link to enable the new language that is added just a few moments ago.

Now go to the page/post editor and see the বাংলা (Bengali) as an additional language in the editor.

Yeah! We’re now DONE.

I hope, you enjoyed the article and able to configure your desired language without having any problem. But if you faced any problem, as before, please do comment in the below comment section and I’ll definitely help you configuring your problem.

Despite being having many other translators, I like Q-Translate for it easy to use and flexible feature, and yes it’s completely free rather than other. Here, I’m going to start a series of posts that would let you know everything about Q-Translate plugin system – installation, configuration and integration with any theme that supports Multilingual / Translation.

Let’s dive into the first lesson…

Download and install the plugin as it does like many other plugins. After activating the plugin, you must find these notifications – starter guide and survey. Just ignore them clicking the dismissal buttons like the screenshot below –

Now go to Settings > Languages.

Now you would see the two default languages English and Deutsch in the General tab.

The most important settings in the General tab is URL Modification Mode but ignore it now, I will discuss this in the other article for sure.

Now go to the Advance tab, here you could find Post Types, now choose the option you want to show your translation option there. By default, all options are selected. But if you want, you could unselect any of one/two you need. Here I’m selection only Posts, Pages. Remember that, if you have any other custom post types, you could find them here also.

So, you can now visit your pages, posts editor and see the settings for your desired language is come like the screenshot below –

Language switcher button for your desired languages will be there, so you can add/enable more languages to see more language buttons here and I’ll be sharing the way you can add another language to the next article.

Let me know if you faced any problem installing that plugin so that I could assist you.

And if this article helps you settings up the plugin, please let’s share your thought so that I can get encouragement for writing more helpful article. 🙂

In WordPress, there are plenty of things we still don’t know. One of them is creating “multiple headers and footers” files and fetch their data.

Sounds new to you? Maybe!

Before I’m going to clear the thing, I assume you have a solid understanding of WordPress template system with header.php, footer.php and get_header(), get_footer() templates tags. Without knowing these, you’d not understand what I’m talking here.

Now, let’s describe the matter.

Every WordPress developer (theme developer actually) have to work on a lot of things in header and footer files to make the theme perfect. One of the main benefits of creating multiple headers and footers file is, the design looks unique for each page or a certain page you’d like to select in.

Suppose, your theme has a header (header.php) and a footer (footer.php) file –

header.php has 3 columns, containing a logo, menus, and social icons. footer.php has 2 columns, containing various links, text and subscription form for all the pages in your website. Now you want, except homepage, all other pages will have a design like so –

In the header, 2 columns with having only logo and social icon. And in the footer, 1 column with having copyright text.

So, you’ve to style a different header/footer file for your custom header/footer that will be added on the other pages except for home page as I said. You designed and named the new header/footer file to header-column-2.php or footer-full-width.php

Now, how could you call them to your theme? That, where you found WordPress’s beauty! 🙂

Just calling the normal get_header(); will fetch the data from header.php file. But if you call the get_header() with passing an argument like: get_header(‘column-2’); or for footer, get_footer(‘full-width’);. That will fetch the data from your custom made header (header-column-2.php) or footer (footer-full-width.php) file.

The thing to remember that, you must keep the prefix “header-“ and “footer-” before your custom header and footer file, and when you call them, call them without “header-“ or “footer-”. Otherwise, it won’t work!

So, if you’ve a file named new-style.php for header, name it to header-new-style.php and call it like get_header(‘new-style’);. So that, WordPress will automatically understand you’re asking data from the header-new-style.php file.

As mobile and tablet devices come closer to achieving final world domination, web design and technology is in a race to accommodate the ever-growing number of screen sizes. However, devising tools to meet the challenges of this phenomenon brings a whole new set of problems, with one of the latest buzzwords to emerge being “responsive web”. This is the challenge of making the web work on most, if not all, devices without degrading the user’s experience. Instead of designing content to fit desktop or laptops, information has to be available for mobile phones, tablets or any surface connected to the web. However, this responsive web design evolution has proven to be a difficult and sometimes painful one.

While it can be almost trivial to accommodate textual information, the tricky part comes when we put into consideration content like responsive images, infographics, videos, an so forth, which were once designed with only desktops in mind. This not only brings up the question of displaying the content correctly, but also how the content itself is consumed using different devices. Users on smart phones are different to users on desktops. Things like data plans and processing speed have to be considered as well. Google has started to highlight mobile-friendly sites on its search results, with some speculating that it will lead to a substantial pagerank boost to such sites. Earlier solutions addressed this by deploying mobile-only subdomains (and redirects) but this increased complexity and fell out of fashion quickly. (Not every site has the ability to afford this route.)

On the Quest for Responsive Web Images

Responsive web design images simply must scale to fit common devices in the modern age

At this point, developers and designers have to ensure their website load is optimized to meet the users who are on mobile sites. Over 20% of web traffic is now mobile users, and the number is still rising. With images taking among the largest shares of page content data, it becomes a priority to reduce this load. Several attempts have been made to simplify responsive design image resizing, including, both server-side and front-end solutions. To discuss these responsive image solutions, we need to first understand the current image linking shortcomings.

The tag has only the source attribute linking directly to the image itself. It has no way of determining the correct type of image needed without any add-ons.

Can’t we just have all the image sizes included in the HTML, and use CSS rules to display:none for all but the correct image? That is the most logical solution in a perfect logical world. This way the browser can ignore all the images not displayed and, in theory, not download them. However, browsers are optimized beyond common logic. To make the page render fast enough, the browser pre-fetches linked content before even the necessary stylesheets and JavaScript files are fully loaded. Instead of ignoring the large images intended for desktops, we end up having downloaded all images and resulting in an even larger page load. The CSS-only technique only works for images intended as background images because these can be set within the stylesheet (using media queries).

So, what’s a website to do?

Back-End Responsive Image Scaling Solutions

A back-end solution can be perfect for handling image size in a responsive web design situation.

Barring mobile-only sites/sub-domains, we are left with sniffing user-agent (UA) and using it to serve the correctly sized images back to the user. However, any developer can attest how unreliable this solution can be. New UA strings keep popping up all the time, making it strenuous to maintain and update a comprehensive list. And of course, this doesn’t even take into account the unreliability of easily-spoofed UA strings in the first place.

Adaptive Images

However, some server-side solutions are worthy of consideration. Adaptive Images is a great solution for those preferring a back-end responsive image fix. It does not require any special markup but instead uses a small JavaScript file and does most of the heavy work in its back-end file. It uses a PHP and nginx configured server. It also does not rely on any UA sniffing but instead checks for the screen width. Adaptive Images works great for scaling down images, but it’s also handy for when large images need art direction, i.e. image reduction by techniques such as cropping and rotation – not merely scaling.

Sencha Touch

Sencha Touch is another back-end responsive design image solution, although it is better to refer to it as a third-party solution. Sencha Touch will resize the image accordingly by sniffing the UA. Below is a basic example of how the service works:

There is also an option to specify the image sizes, in case we do not want Sencha to resize the image automatically.

At the end of the day, server-side (and third party) solutions require resources to process the request before sending the correct image back. This takes precious time and in turn slows down the request-response trip. A better solution might be if the device itself determined which resources to request directly, and the server responding accordingly.

Front-End Solutions

Front-end responsive design image scaling solutions can be a great option to optimize website loads.

In recent times, there have been great improvements on the browser side to address responsive images.

The <picture> element has been introduced and approved in the HTML5 specification by the W3C. It is currently not widely available on all browsers but it will not be long before it is natively available. Until then, we rely on JavaScript polyfills for the element. Polyfills are also a great solution for legacy browsers lacking the element.

There is also the case of the srcset attribute that is available for several webKit based browsers for the element. This can used without any JavaScript and is a great solution if non-webKit browsers are to be ignored. It is a useful stop-gap for the odd case where other solutions fall short, but should not be considered a comprehensive solution.

Picturefill

Picturefill is a polyfill library for the element. It is one of the most popular libraries among the front-end solutions to responsive image sizing and scaling issues. There are two versions; Picturefill v1 mimics the element using span while Picturefill v2 uses the element among the browsers that already offer it and provides a polyfill for legacy ones (for example, for IE >= IE9). It has some limitations and work arounds, most notably for Android 2.3 – which incidentally is an example of where the img srcset attribute comes to the rescue. Below is a sample markup for using Picturefill v2:

XHTML

1

2

3

4

5

<picture>

<source srcset="/images/kitty_large.jpg"media="(min-width: 768px)">

<source srcset="/images/kitty_medium.jpg"media="(max-width: 767px)">

<img srcset="/images/kitty_small.jpg"alt="My Kitty Cat">

</picture>

To improve performance on users with limited data plans, Picturefill can be combined with lazy loading. However, the library could offer wider browser support and address the odd cases rather than relying on patches.

Imager.js

Imager.js is a library created by BBC News team to accomplish responsive images with a different approach to the one used by Picturefill. While Picturefill attempts to bring the element to unsupported browsers, Imager.js focuses on downloading only the appropriate images while also keeping an eye out for network speeds. It also incorporates lazy loading without relying on third-party libraries. It works by using placeholder elements and replacing them with elements. The sample code below exhibits this behavior:

Browser support is much better than that of Picturefill at the expense of being a more pragmatic solution than a forward thinking one.

Source Shuffling

Source Shuffling approaches the responsive image problem from a slightly different angle than the rest of front-end libraries. It resembles something out of the “mobile first” school of thought, whereby it serves the smallest resolution possible by default. Upon detecting that a device has a larger screen, it swaps the image source for a larger image. It feels like more of a hack and less of a full fledged library. This is a great solution for chiefly mobile sites but means double resource downloading for desktops and/or tablets is unavoidable.

Some other notable JavaScript libraries are:

HiSRC – A jQuery plugin for responsive images. Dependency on jQuery might be an issue.

Mobify.js – A more general library for responsive content, including images, stylesheets and even JavaScript. It ‘captures’ the DOM before resource loading. Mobify is a powerful comprehensive library, but may be overkill if the goal is just responsive images.

Summary

At the end of the day, it is up to the developer to decide which responsive web design image approach suits the user base. This means data collection and testing will give a better idea of the approach to take.

To wrap up, the list of questions below can be helpful to consider before deciding the appropriate responsive image solution.

Are legacy browsers an issue? If not, consider using a more modern approach (e.g: Picturefill, srcset attribute)

Is the response time critical? If not, go for a third-party or back-end solution.

Are the solutions supposed to be in-house? Third-party solutions will obviously be ruled out.

Are there lots of images already on a site that is trying to transition to responsive images? Are there concerns about validation or semantic tags (or rather non-semantic tags)? This will require a back-end solution to route the image requests to something like Adaptive Images.

Is art direction a problem (specifically for large images with a lot of information)? A library like Picturefill will be a better solution for such a scenario. Also, any of the back-end solutions will work as well.

Is there a concern about lack of JavaScript? Any of the front-end solutions will be out of the question, which leaves the back-end or third-party options that rely on UA sniffing.

Is there a priority for mobile response times over desktop response times? A library like Source Shuffling may be more appropriate.

Is there a need to provide responsive behavior to every aspect of the site, not just images? Mobify.js might work better.

Has the perfect world been achieved? Use CSS-only display:none approach!