Simple Tips for Developing Plugins and Themes Against WordPress Trunk

Posted on March 29, 2018 by Mario

If you often develop plugins or themes for WordPress, you may have heard about one of the strategies that are often recommended, which is doing so against trunk of WordPress. This practice often works best to any web developers or someone who is looking for ways to improve their development practices. Not to mention how easy you can view the source code on the web at any time, since WordPress is open source software.

Besides, you can also work with it easily as you can download it to your local computer. Therefore, in this article we would like to describe how to work with the current snapshot of code with WordPress and why it may be beneficial to use this codebase when working on projects of others. So, if you are curious to know how to develop plugins and themes against WordPress trunk, you can continue reading the article below.

Developing Against WordPress Trunk

We recommend you to have Subversion or a Subversion client installed before getting started. By having a package manager like Homebrew to handle software and a command-line client, you can easily enter this in your terminal:

$ brew install subversion

If you are looking to use a front-end, you can also use something like Versions or Cornerstone. Below are the steps that you have to follow:

Download the Latest Code

Download the latest snapshot of the WordPress codebase by using this command:

$ svn co https://core.svn.wordpress.org/trunk/ .

However, if you’re using a front-end then you might need to use the following URL in your client of choice to browse the repository:

https://core.svn.wordpress.org/trunk

Then, you can download the contents of the trunk directory to your computer and prepare to install it on your computer.

Or you can use your front-end of choice:

In order to do this, you have to make sure that a database is prepared and then walk through the standard installation procedure.

Setup Debug Mode

After all is installed, you can set your WordPress into debug mode, so you are able to see information in the debug logs as well as in your browser.

To do this, you can open wp-config.php and change the line that reads:

define( ‘WP_DEBUG’, false );

To read:

define( ‘WP_DEBUG’, true );

define( ‘WP_DEBUG_LOG’, true );

define( ‘WP_DEBUG_DISPLAY’, false );

@ini_set( ‘display_errors’, 0 );

define( ‘SCRIPT_DEBUG’, true );

At this point, you will see information printed out to the screen every time you’re working with code and every time you have information written to debug.log which you can also view in your preferred text editor or console.

Work with the Proper Directories

After all of your WordPress is set, you’re ready to work on your project, note on whether or not you’re working plugins or themes. Furthermore, in general, you’ll find each in wp-content/plugins or wp-content/themes.

For instance, if you’re working on a plugin then you’re going to keep your plugin in the plugins’ directory. You can see on the screenshot above that you may need to use Scheduled Post Shortcut against trunk.

A Word about Stable Versions

So, whenever you are working with a plugin or a theme that runs against a stable version of WordPress, remember the choices you have to make:

Work against the stable version of the code that’s available at WordPress.org.
Work against the snapshot of code in trunk.

If you happen to use the former, then your code is going to work with the latest stable version. However, if you choose to work with the latter, then you will need to work with the upcoming version of WordPress in order to make it work. However, remember that things can change between what’s in trunk and what’s ultimately released. Therefore, if you prefer to work with trunk, you may need to keep testing your work against the code until the core team tags trunk as a stable version.

4 Brilliant Image Optimisation Tips

Posted on March 22, 2018 by Mario

A fast loading website is what everyone is looking for; no one loves to wait even for a little more seconds to have their site loaded. Therefore, many web developers and web designers think about how to make faster loading websites. This situation can be obtained through many ways; one of them is to focus on image optimisation. With a good image optimisation, many believe that a site can load faster.

So, whether you’re building full-size e-commerce websites or simply learning a few tips about it, you have to make sure your images load faster.

Be Selective and Preload Critical Images

First, you need to take a look at your site, then identify if there is any critical image asset. In most cases, logo or hero images are usually the critical image assets where the preload resource hint comes in. Preload is actually a way of hinting to the client that an asset should be retrieved before the browser parser would otherwise discover it. Therefore, you can use it for almost everything, but most of all, it works amazing for preloading critical imagery. The example below will show you how to use it in the HTML <head> element on order to preload a hero banner image:

Furthermore, you can also use preload in an HTTP header:

Below, we present two screenshot rolls of the same page loading in Chrome. You can see the different result between the two, since one scenario uses preload to load a hero banner image, while the other doesn’t.

From the example above, with preload the banner image appears in the browser window half a second faster, since a quick one liner gives the browser a head start.

Different from optimising JPEGs or PNGs, SVGs are comprised of text, specifically XML markup which means that typical optimisations you would apply to text-based assets can and should also be applied to SVGs. Beyond that, to tamp down the size of SVGs, you can use an optimiser, such as SVGO. However, if you are not only using vector artwork, but also creating it, you can automatically simplify your artwork to reduce the amount of anchor points in paths via the Simplify dialog window.

If you are using Illustrator CC, you can find this dialog’s menu by going to Object>Path>Simplify. By reducing Curve Precision, it is possible to remove extra path points in your artwork. If you want to remove extra path points in your artwork, you can reduce the Curve Precision, then optionally adjusting Angle Threshold. For example, if you reduce the Curve Precision of as little as 6%, you will remove 54 path points. Therefore, whenever you want to improve the appearance of your artwork, you can use judiciously.

Please remember that this tool will run aggressively, so at first, you might need to lower Curve Precision too much and once you are carefully crafted, artwork will devolve into a blob. You’ll read the rewards, as long as you strike the right balance.

Convert Animate GIFs to Video

Everyone loves a good animated GIF, since they can convey almost any sentiment using that. However, in terms of loading, they can really make your loading run so slow. Therefore, image optimisers such as gifsicle can help you shave off excess kilobytes by converting those GIFs into videos and embed them in the HTML5 <video> tag. The ffmpeg command line utility is well suited for this task:

The example of the commands above takes a source GIF (animated.gif) as input in the –I argument, and output videos with a variable bitrate maximum of 512 Kbps. In a test, a 989 Kb animated GIF is able to reduce to a 155Kb MP4, a 109Kb OGV, and an 85Kb WebM. This makes all video files comparable in quality to the source GIF. Therefore, since the ubiquity of <video> tag support in browsers, you can use these three video formats, as follows:

If you want to try the command above, remember to order your <source> tags, so that the most optimal format is specified, and the least optimal is specified last. Therefore, you will start with WebM videos first, but check the output file size of each video and go with whatever is smallest first and end with whatever is largest. So, wait no more to install the FFmpeg if you don’t have one.

Lazy Load with Intersection Observer

Most of us may have done lazy loading images, but many lazy loading scripts use CPU-intensive scroll event handlers. Such methods can contribute to sluggish interactions on a page. In fact, older hardware with less processing power is even more prone to the ill effects of this type of code. Even though execution throttling does help, it’s still messy and rather inefficient workaround for determining when elements are in the viewport.

Fortunately, with Intersection Observer API, you can have a simpler and far more efficient way to determine when elements are in the viewport. Below is the example of some basic lazy loading image markup:

<img class=”lazy” data-src=”/images/lazy-loaded-image.jpg” src=”/images/placeholder.jpg” alt=”I’m lazy.” width=”320″ height=”240″>

Here, we would like to load a placeholder image in the src attribute, and then store the URL for the image we want to lazily load in the data-src attribute. The <img> element a class of lazy for easy access with querySelectorAll is given to top it all off.. Then, we can simply use this code:

document.addEventListener(“DOMContentLoaded”, function(){
if(“IntersectionObserver” in window && “IntersectionObserverEntry” in window && “intersectionRatio” in window.IntersectionObserverEntry.prototype){
elements = document.querySelectorAll(“img.lazy”);

var imageObserver = new IntersectionObserver(function(entries, observer){
entries.forEach(function(entry){
if(entry.isIntersecting){
entry.target.setAttribute(“src”, entry.target.getAttribute(“data-src”));
entry.target.classList.remove(“lazy”);
imageObserver.unobserve(entry.target);
}
});
});

elements.forEach(function(image){
imageObserver.observe(image);
});
}
});

Here, we bind code to the document object’s DOMContentLoaded event in which this code will find out if Intersection Observer is supported by the current browser. We can grab all img elements with a class of lazy with querySelectorAll and then attach observers to them.

The observer contains reference to the elements we’re observing (entries) and the observer itself (observer). This code hinges on each observer entry’s is intersecting value. The observed element is intersecting returns 0, when the element is out of the viewport. It will return a value greater than 0, as the element enters the viewport. Then, we can swap the content of the image’s data-src attribute into the src attribute, and remove its lazy class. You can remove the observer with the observer’s unobserved method.

By using this method, you are choosing a much more easier method than mucking around with scroll handlers. So, hopefully, the methods above can be the best alternatives for you to optimise your images. Good Luck!

The 8 Biggest SEO Misconceptions of Hreflang Implementation

Posted on March 15, 2018 by Mario

There are a number of excellent tips on how to effectively geo-target sites, but there is one of the best methods is to use the hreflang element. Unfortunately, there is still so much confusion around, which caused some serious errors on many sites. In fact, more than half of them had some sort of problem with the code implantation, and it must be due to lack of understanding of hreflang fundamentals.

Therefore, in this article, we would like to give you the 8 misconceptions that often mislead many web developers and SEO services agency. So, if you are working in those fields, you’d better read the following points, and hopefully, after reading the points below, you can understand the right concept for understanding and applying the hreflang in your SEO strategy.

Misconception 1: You only Need Hreflang on the Home Page of the Site

Some people prefer to put hreflang tags in a few sites on their home pages. Unfortunately, Google’s sample code only displays the home page version of a URL which makes some interpreting only needed on the home pages. Many SEO professionals said that Google was smart enough to figure it out. All you need to do is just give them the template and they will understand.

However, Google cannot understand the client’s wants, that’s why in most cases, it will show the incorrect page in the local market. Therefore, you need to add the hreflang element to any and all pages that have an alternative version included in an xml site map and not just home pages.

Misconception 2: You only Need Hreflang on Dot-Com Domains

Some developer teams are arguing if it is possible to develop a solution to map pages across different top-level domain. They think that once they use ccTLDs like .co.uk, the search engine would understand what country they are targeting. This is why you need to do a test to make sure that it is understood and that no other local sites are ranking in the market. Also, it is strongly recommended for you to use the hreflang element for any page that has an alternative, no matter what domain it is on. Besides, enterprise hreflang XML tools can map the URLs regardless of what domain they are on. Furthermore, you can also host the XML sitemaps for all of the different sites in the same location which makes maintaining them much easier.

Misconception 3: You can only use the X-Default on the Home Page with a Country Selector

Another opinion came from a few SEO pros that said the x-default could only be used when you have a home page that has a country selector which can only be used on this page. This statement is almost right, but actually, there are two specific applications of the x-default. For instance, sites like FedEx or Ikea present a splash page with a language and/or country selector asking the visitor to choose which location and/or language version of the site they want to visit. Since this page does not target any specific language or country, the x-default would tell search engines to present this page in any market that does not have the assigned page. The wrong part is when the SEO pros state on how to handle older and large multinationals, especially those in the United States, a place which the main dot-com site is often used as both their global site and their U.S. site. So, in this situation, you should also use the x-default.

Misconception 4: Regional Sites Cannot Use Hreflang Element

People usually use regional sites to target multiple countries in a region using a single language site. The most common of these regions are APAC for Asia Pacific countries, LatAM for South and Central American country regions, or MENA covering Arabic speaking Middle East countries and North Africa.

You can also use the hreflang on a regional site in some ways. The first method is by setting the regional site to a common language which is most commonly done with an Arabic language site.

Another way is to tag the same page for multiple countries. Usually, sites do this when they already have a designated language site, multiple local sites in the same language, and want this version to be visible in specific markets rather than the x-default or language version.

In this approach, every language market will list the element that you are targeting.

Misconception 5: To Save Lines of Code Add Multiple Codes to the Hreflang=Syntax

Some people think that the application can cut down on the number of XML sitemap entries by adding multiple countries and language codes to the syntax.

The fact is this is not working, since you must create a separate URL element for each URL and Google has been very clear about this.

Misconception 6: You Should Set Your Rel=Canonical to the Global Site

This is totally wrong as doing so will remove your local language pages almost as fast as blocking them with a robots.txt entry. In fact, this might be one of the biggest mistakes that many companies make, related to hreflang other than incorrect country and language codes. Most make this suggestion in the context of removing duplicate content. The hreflang element essentially does this for you.

Therefore, the right answer is to point to the local language page it is on and never point to any other page unless you want the page to be blocked. This makes no need for hreflang tag to be on the page. For example:

Misconception 7: You can combine Hreflang and Canonical Tags

This mistake is probably the most common one that often happens. In many cases, developers often try to combine the canonical and self-referencing hreflang element into a single tag.

In this case, it was the page for Ireland English.

Therefore, as a solution, you need to make sure that the rel=canonical must be its one entity as must the hreflang element for the page. For that reason, you cannot combine them under any conditions and the correct entry should be like this.

Misconception 8: The Rel=Canonical Can Serve as the Self-Referencing Entry

The source to support this concept is still hard to find, but it is completely incorrect. Below is an example of this mistake when referencing the Argentina Spanish page.

As stated before that it is incorrect; therefore, you must use hreflang element for the self-referencing element. In fact, if the hreflang tags are on the local pages, they should look like this:

Conclusion

We have to admit that hreflang is one of the most complex technical issues SEO pros must deal with. Unfortunately, there are lots of incorrect interpretations that you can find anywhere. So, take a moment before you tackle your hreflang implementation to think about what problems you are trying to solve and be careful whether these changes can cause new problems or not.

OnlineMagz

The best website magazine

Responsive Business Theme

Month: March 2018

Simple Tips for Developing Plugins and Themes Against WordPress Trunk

4 Brilliant Image Optimisation Tips

The 8 Biggest SEO Misconceptions of Hreflang Implementation