4elements, Amsterdam, Holland

  1. A Walkthrough on Conditional Tags in WordPress: Introduction

    One of the most important strengths of WordPress is the extensibility of the core. With plugins and themes, WordPress users have been able to mold their websites for almost a decade. (WordPress was first released in 2003, but plugins were introduced in 2004 and themes were introduced in 2005.) And to create such a solid infrastructure, WordPress includes lots of handy sub-systems (functions, classes or whole APIs). One of them is "Conditional Tags", which allow our code to function differently in particular situations.

    In this series, we're going to learn about these Conditional Tags. We're going to start off with the definition and the importance of Conditional Tags in this post. And in the next parts, we're going to go through Conditional Tags with a description and some examples.

    Let's begin!

    What Are Conditional Tags?

    In the Codex, Conditional Tags are described like this:

    The Conditional Tags can be used in your Template files to change what content is displayed and how that content is displayed on a particular page depending on what conditions that page matches.

    You get the idea: In order to make your code use and/or alter the content, you use Conditional Tags and tell your code the type, state and place of the content. Imagine your code and WordPress having a conversation:

    • Your Code: Hey man, I need some help.
    • WordPress: Sure, I'm all ears. What do you need?
    • Your Code: I'm going to wrap these post titles with some DIVs, but I need to know if these are on a category archive page. Are these on a category archive page?
    • WordPress: TRUE
    • Your Code: Um... What?
    • WordPress: I mean yes.
    • Your Code: That's great, thank you!
    • WordPress: Bye!

    So, in short, Conditional Tags are boolean statements that steer your code to understand where it is, when used inside an if/else statement. They only return TRUE or FALSE, and your code only needs these two boolean values.

    How to Use Conditional Tags

    While Conditional Tags are a pretty important part of WordPress development, it's amazingly simple to use them. Since they only return TRUE or FALSE, you can use them inside if statements without any hassle. (Actually, there are three exceptional Conditional Tags that return FALSE or a value, and we'll get to them in the next parts, but you can use them in if statements, too.)

    Let's have a quick example of how a Conditional Tag works:

    Get it? We used the Conditional Tag for the if statement and we told WordPress that if it's the homepage, this piece of code will echo a—somewhat dull—welcome text. It's really not that big of a deal.

    Let's have another example, with some "cleaner" code:

    See what we did? We created a variable and defined the Conditional Tag in it; so we were able to use the variable for the if statement. Piece of cake!

    Example Scenarios for Using Conditional Tags

    Believe me when I say there's an infinite number of cases for using Conditional Tags. Off the top of my head, I can give you five scenarios in which you can make use of Conditional Tags:

    1. Imagine that you're developing a social sharing plugin for WordPress and you want to give your users to option to show and hide the widget under posts and pages. With a combination of is_single(), is_page() and is_singular(), you can create a function that checks the user's plugin settings and, say, hides the widget on pages but shows them under each post.
    2. Let's say that you're developing a theme for a small company. You're working on the "News" page (the "blog" part of the theme) and you designed a slick post listing with thumbnails... but you know that they will forget or choose to not use a thumbnail for some posts. That's where has_post_thumbnail() comes in handy: Use it and your theme will check if the post does not have a thumbnail and display a default image.
    3. Suppose you're creating an add-on plugin for a popular WordPress plugin. You need to detect that the main plugin is installed and being used because your plugin may cause problems if a novice user installs it without using the main plugin. The solution is simple: Using is_plugin_active(), you can disable your plugin's functionality, and using is_plugin_inactive(), you can display a warning in the admin area.
    4. You created a theme for another client and they want to upload images, PDF documents and ZIP archives to their posts—but they also want to display all images under each post. Simply using the Conditional Tag wp_attachment_is_image() will let you pick over the images and show them under the posts.
    5. Say you're making a plugin for multi-author blogs and you want to detect if the user's website has more than one author. The Conditional Tag is_multi_author() gives you the answer.


    As you can see, Conditional Tags are one of the easiest features of WordPress to use, but also one of the most important parts of theme and plugin development.

    The aim of this series is to introduce Conditional Tags and we're just getting started. In the next five articles, we're going to go through 65 different Conditional Tags with descriptions, cases of use, and examples for some of them.

    See you in the next part!



    Leave a comment › Posted in: Daily

    1. New Course: EmberJS Framework Basics

      Our new EmberJS Framework Basics course covers everything you need to know to get started building web apps in Ember. 

      Tuts+ instructor Rem Zolotykh will give you an overview of all the major parts of Ember and how they work together. Then you'll learn the details of how apps are implemented in Ember, with a focus on routes, controllers, resources, templates, data handling, and all the other most important Ember technologies. Every lesson concludes with a small assignment for practicing the skills you’ve just learned.

      You can take our new course straight away by subscribing to Tuts+. For just $15 a month, you get access to this course and hundreds of others, with new ones added every week.



      Leave a comment › Posted in: Daily

    1. Moving WordPress: Moving a Site Out of a Multisite Network

      Sometimes a site has been created in a WordPress Multisite network but needs to be moved to its own single site installation. There are a few scenarios where this might happen including:

      • The site has grown too large to be contained in the network.
      • The site needs its own IP address.
      • The site owner is moving providers or taking over complete management of the site themselves.

      In some instances you might find that you can move the site out of Multisite by using a plugin or a combination of plugins, but if this doesn't work you'll need to move the relevant database tables. Moving a site out of a Multisite Network in this way is a tricky process as it involves isolating the database tables in the Multisite database that relate to that specific site. However it's not impossible.

      What You'll Need

      To follow this tutorial, you'll need:

      • An installation of WordPress Multisite with a subsite that you want to move to its own WordPress installation.
      • A second location which you want to move your site to.
      • For manual moves, you will need an FTP client, a code editor, and access to phpMyAdmin.

      Note: You can't move the main site out of a Multisite network, because the network won't work without it. If you do need to move the contents of the main site elsewhere, I would recommend creating a duplicate and then replacing the contents of the original site with a dummy site. You won't be able to move the domain name, though, as all of the other sites in your network are using it too.

      Using a Plugin to Migrate a Site Out of Multisite

      If your site doesn't have a lot of configuration set up via plugin, theme or site settings screens, you may be able to successfully move it using the WordPress Importer plugin. If the site has widgets, you can copy their settings across using the Widget Settings Importer/Exporter plugin.

      However, if you've added a lot of bespoke configuration using settings or options screens or the theme customizer, none of these will be copied across. In this case you'll need to do a manual move.

      For full details of how to use these plugins to move your site, see my earlier tutorial on using plugins to move a WordPress site. The process is exactly the same for moving a site from a Multisite network to its own WordPress installation.

      Migrating a Site out of Multisite Manually

      The site you're moving out of Multisite will have three components that you need to copy from the Multisite network:

      • theme and plugin files—you might copy these across or reinstall them in the new site
      • uploads—you'll find these in the site's subdirectory in wp‑content/uploads/sites
      • database tables—you don't need all of the database tables but just the ones relating to this site

      Note: If your Multisite network was created prior to WordPress 3.5, you won't have a sites folder. Instead you'll have a blogs.dir folder in wp-content with all of the upload files for the subsites. This will have a numbered folder for the site you're migrating, which you copy instead. I'll cover this in more detail below.

      Do You Really Need to Move the Site?

      Before you start, think about the reasons you're migrating the site. Could it be purely to have a new domain name? If this is the case, then the free domain mapping plugin will let you give individual sites their own domain, and visitors will never see the domain of your Multisite network.

      But if this isn't the only reason, then read on!

      Backing Up First

      Before you do anything like this, it's a good idea to back up your Multisite installation. Use your preferred backup plugin, or a combination of FTP and phpMyAdmin if you prefer to work manually.

      You'll use this backup to copy the relevant files to your new site, and it also gives you some peace of mind in case you have any problems.

      Finding the ID of Your Site in the Multisite Network

      Each site in a Multisite network has its own unique numerical ID. This is used to identify its folder in the wp-content/uploads/sites directory (or wp-content/blogs.dir if your Multisite network is older—see above), and also to identify the database tables for that site.

      Find this by going to Network Admin > Sites and then selecting the Edit option for the site you're working with. The URL WordPress takes you to will give you the site's ID. The URL should be in the form http://mynetwork.com/wp-admin/network/site-info.php?id=XX

      XX is the ID of your site, and will be the name of the folder containing its files, as well as the prefix for its database table names.

      Exporting the Site's Tables From the Network

      As you're only moving one child site and not the whole installation, you won't need the contents of your entire database.

      In PhpMyAdmin, click on the Export tab. Then find the tables relating to the site you're exporting. They will begin with wp_XX_, where XX is the ID of your site. An example is shown below.

      Database tables selected ready for export

      Select all of the tables relating to your child site and then export them.

      Note: WordPress Multisite stores all data relating to users of the network in the wp_users and wp_usermeta tables: it doesn't create separate ones for each site. If you have a lot of users on your site which you want to copy across from the network, then you might want to export those tables as well, import them to the new site and edit users in the admin screens to remove any that are not relevant to the new site. However, if your site just has one or two users, it's easier to recreate them on the new site. For more information on Multisite and database tables, see this tutorial on the WordPress database and Multisite.

      Editing the Database Tables

      Make a copy of the sql file that's been downloaded to your machine and give it a name that tells you what it is (for example by adding copy to its name). Open it in a code editor.

      Editing Links

      Change all instances of the site's domain in the Multisite network to its new single site domain. For example if your site was at http://network.com/mysite, change it to to http://mysite.com. If your network uses subdomains, you'll need to change all instances of http://mysite.network.com. If you do this I'd advise also running a check for the subdirectory version just in case. Save your file.

      Note: If your site had a domain mapped to it which isn't the domain you're moving it to, you'll need to replace that with the new domain too. Tread very carefully here, and keep backups!

      Editing Table References

      The database tables in your new single site installation won't have prefixes for the site ID, so you'll need to remove these. In your sql file, replace all instances of wp_XX_ with wp_, where XX is your site ID.

      Now save the sql file.

      Installing WordPress and Creating a Database in the New Location

      In phpMyAdmin, create a new database in the location for your new site and install WordPress in the normal way.

      Uploading Files to the New Site

      Identify the plugins used by the child site and either install them in your new WordPress site via the Plugins screen or upload them from the backup you took of your old site.

      Do the same for any themes your site is using—copy them from your backup to the wp-content/themes directory of your new standalone WordPress installation, or just reinstall them.

      Copy the uploads from your old site to the new one:

      • If the network was created after WordPress 3.5, it will have a sites folder in wp-content/uploads. Find the subfolder with your site's ID and upload its contents to the wp-content/uploads folder in your new site.
      • If the network is an older one and has a blogs.dir folder, that will also contain a folder with your site's ID. That will then have a subfolder called files. Copy the contents of the files folder to the wp-content/uploads folder in your new site.

      Note: you may need to delete any folders WordPress has created in your new uploads folder to avoid any clashes.

      Once you've done all this, activate any themes and plugins.

      Importing Tables to the New Database

      Now that you've installed your themes and plugins, you need to import the database tables.

      Dropping the Existing Tables

      Before you upload the tables from your old site, you'll need to delete the duplicate ones which WordPress has added to your new site.

      In phpMyAdmin, drop the following tables from your database:

      • wp_commentmeta
      • wp_comments
      • wp_links
      • wp_options
      • wp_postmeta
      • wp_posts
      • wp_terms
      • wp_term_relationships
      • wp_term_taxonomy

      The screenshot shows my database with just those tables selected:

      database tables selected ready to be dropped

      Select them, click on the With selected: dropdown box, and select Drop. When prompted, click Go.

      Note: Don't delete the wp_usermeta or wp_users tables, unless you've chosen to copy these across from the network as well (see above).

      Uploading the Database Tables

      Next upload the database you've edited:

      • Click the Import tab.
      • Click the Choose file button.
      • Select the sql file you've edited and click Choose or OK.
      • Click the Go button.
      • After a while (depending on the size of your database), you will see a message telling you the upload has successfully finished.

      Final Steps

      Clear your browser's cache. This avoids any problems you may have if the browser has cached content from the old site.

      Now log in to the WordPress admin for the remote site. If you moved the user tables across, your login details will be the same as for your old site, but if you didn't, these will be whatever you specified when you installed WordPress in the new location.

      Visit the Permalinks screen and turn pretty permalinks back on.

      Check that all your links are working ok and that widgets and plugins are behaving as they should. If not, you can either step back through the process, using your backups where you need to, or simply set up the plugins and widgets from within your new site.

      Removing the Site From Your Multisite Network

      Once you are completely happy that everything's working as it should, remove the site from your Multisite installation. I'd recommend leaving this a week or so in case you spot anything that hasn't moved across. In the meantime, you can configure the old site's domain to map to the new one, either by using a plugin or in CPanel.

      Phew! It was a long and slightly complicated process, but you've done it. 


      Migrating a site out of WordPress Multisite and into its own installation isn't something you can do quickly or without being very thorough, but it is possible and I've done it a few times. If you follow the steps above and make sure you have backups in case of any problems, then you should find it works smoothly for you.



      Leave a comment › Posted in: Daily

    1. Introduction to Lumen

      Lumen is a brand spanking new PHP micro-framework developed by the author of the Laravel framework, Taylor Otwell. Don't stress, though—Lumen is not meant to replace Laravel. In fact, the idea behind Lumen is that it complements your existing or future Laravel applications.

      Taylor Otwell developed Lumen with some very specific purposes in mind, namely, microservices and APIs. Just briefly, a microservice is a smaller, decoupled process that communicates with a larger application, e.g. our Laravel application.

      In this article I want to go over what's different in Lumen, when we should use Lumen, and how we can use Lumen. I'll also explain how we can take our Lumen application and easily migrate it to a full-stack Laravel application. There won't be a whole lot of code, as Lumen is much the same as Laravel. Let's get started.

      So What's New?

      This will most likely be the first question that many of you will be asking. In reality, not a whole lot is actually "new" with Lumen aside from the glue. Lumen still utilizes most of the Illuminate components that make up the Laravel framework (there are only a couple missing). Think of it as a slimmed down Laravel installation. 

      Its goal is to maximize performance, and to get this increase in performance, several things have been changed. The most important of these are the following:

      1. Less configuration. Much of Lumen comes pre-configured. In fact, you'll find that there's no config directory in a Lumen install. Instead, you'll utilize the .env files to configure most of your application.
      2. Different router. This is probably the biggest difference and the reason why it can be as fast as it is. Lumen doesn't utilize the Symfony router like its big brother Laravel. Instead, Lumen uses FastRoute, a lightweight routing implementation developed by Nikita Popov.

      There are a few trade-offs here. FastRoute is a very fast implementation, but it's not as feature-packed as the Symfony router. If you want to use sub-domain routing then you'll have to stick with a Laravel install which uses the Symfony router. 

      The other trade-off worth mentioning is that for finer control over configuration of certain components you'll need to modify configuration files within the vendor/laravel/lumen-framework directory. The majority of the configuration can be done through the .env files, but some lesser configured things aren't directly configurable.

      Should I Switch to Lumen Right Now?

      The answer here will depend, but probably not. If you're developing or have developed an application on Laravel (4 or 5), then you probably won't need to switch to Lumen right this very minute. While Lumen is capable of developing a full-blown web application, it is better suited to the smaller, decoupled services and APIs.

      So When Can I Use It?

      I can't tell you when you can and can't use a framework that's available to you. I will, however, make some recommendations on when you might consider using Lumen for a part of your next project.

      Let's say you're building a large web shop application. So you go ahead and install Laravel and get to work on a monolithic application. Now, there's nothing wrong with this approach, and you may find it works fine for you. If so, carry on. If you find you're becoming overwhelmed with the complexity, or things seem to be getting a little out of hand, then you may want to split it up into some smaller, more manageable pieces.

      You would use Lumen to create separate applications for each decoupled service. For our shop we might split off the billing, e-mail notifications, shipping, and tracking to separate applications. Each of these applications would be a self-contained Lumen install and each application would only do a specific task. 

      To enable our main application to communicate with our decoupled services, we'd make use of queues and a service like Amazon SQS. We can use queues to easily queue up jobs, and each service would listen for its particular jobs and process them as they're queued. The benefit to this approach is that each service can be scaled and deployed independently of one another. 

      You could also use Lumen to build an API which could also be consumed by your main application with the help of an HTTP client such as Guzzle. This decoupling allows you to scale and optimize the business side of your application without interfering with the rest.

      Okay, How Do I Use It?

      By now you should have a good idea as to whether or not using Lumen is the right step for you. Installing Lumen is as easy as installing Laravel: a simple composer create-project command, or you can install the lumen command to create new projects. We'll just use Composer to grab a fresh install.

      Composer will pull down all the dependencies. You can use Artisan to quickly serve up the application to take a look, or you can set up a Virtual Host or Homestead site. Either way, once you hit the path to your Lumen installation you'll see the shiny splash page informing you that Lumen is good to go.

      Configuration is all done in the .env files, so you'll either want to rename the .env.example file or copy its contents into a new file.

      The remaining bootstrapping that you'll want to be aware of is in the bootstrap/app.php file. If you're using the .env configuration mentioned above then you'll want to uncomment Dotenv::load(__DIR__.'/../');. Scrolling through this file you'll see several commented lines that you may want to uncomment. There's the loading of facades, Eloquent, some middlewares, and the registration of other service providers.

      You've now got yourself a freshly installed and configured copy of Lumen ready to build something amazing.

      But Wait, I Need Laravel Now!

      You might be building your Lumen application and everything is going absolutely fine, until one fateful day when you realise you need something that only the full-stack Laravel framework offers. Don't stress, though, as it's an extremely painless upgrade. Here are the steps to follow:

      1. Install a fresh copy of Laravel 5.
      2. Copy across your app directory. Be aware that you may need some things from the L5 app directory, such as the providers.
      3. Copy across your configuration to the appropriate file in the config directory.
      4. Copy across any custom bootstrapping.
      5. Fix some routes. Because Lumen uses FastRoute, you'll probably need to tweak some of your routes so that they're compatible with the Symfony router.

      That should be the bulk of what you need to copy in order to migrate your Lumen application to Laravel. Of course, this works both ways, so you can easily migrate a Laravel application to Lumen if you realize you don't need everything the full-stack framework offers.


      To wrap this up, I just want to point out that I'm advocating the use of Lumen primarily for decoupled services and APIs, which is its intended use. That's not to say you can't build an entire application on Lumen, because you can. If you choose to do it, that's fine. There aren't any rules carved in a stone tablet telling you what you can and can't use for your projects. At the end of the day the decision is left up to you. Weigh your options, plan your project, decide what you'll need, consult your team, and then make your final decision.



      Leave a comment › Posted in: Daily

    1. Using Page Templates in Your WordPress Theme

      How many pages did you create in your last WordPress project? If you're using WordPress as a content management system and not for blogging or any other reason, it's very possible that pages are the most used post type in that project. Why? Because pages are the most basic and most useful post type in WordPress.

      There are five default post types that come with WordPress out of the box: posts, pages, attachments, revisions, and navigational menus. Arguably, pages have the most importance among these built-in post types. It's extremely common for a corporate website to consist of many pages, and you can see tens, maybe hundreds of different pages in a website like that.

      Although pages are very important for WordPress as a content management system, it's easy to make a very boring website, with pages identical to others. That's where "page templates" come into play: Page templates are probably the most effective way to spice up your pages' designs.

      What Are Page Templates?

      In essence, page templates let you customize the look and feel of your pages. You can't serve them as a plugin, but you can use them in your themes—or child themes. By creating and placing them in your theme's folder, you'll be able to use different layouts for your pages automatically or optionally, depending on the type of page template.

      Yes, there are different types of page templates. There are three kinds, in fact:

      1. The default page template, which is the page.php file of your theme
      2. Specialized page templates, which are literally specialized for specific pages
      3. Custom page templates, which are the ones that we all think of when we see the words "page template"

      The default page template, page.php, is the file that overrides index.php in order to change the design of your pages. If you want to design a new layout for a specific page (for example, the page with the "about" slug), you can use specialized page templates which override both page.php and index.php. And if you want to create a new page design to use in any page you want, you can use custom page templates which override specialized page templates, page.php and index.php.

      I don't think it's necessary to look into the page.php file any further, so let's move on to specialized page templates.

      Specialized Page Templates

      Specialized page templates are the ones that can be set for a single page and force it to use a layout, instead of leaving it to the user's decision. It's a good way to set page templates for specific pages when designing a website for a client (or yourself), but it's not as useful as custom page templates.

      There are two very easy ways to create specialized page templates: by using the page's ID or its slug. Simply naming your template file with the ID or slug of the page, like page-9.php or page-about.php, forces WordPress to use that template to show the page. (Slugs have more priority than IDs in specialized page templates, so page-about.php will override page-9.php if they're both intended for the same page.)

      If you're making a theme for the public, you shouldn't use specialized page templates unless you have a very specific reason to do so.

      Custom Page Templates

      As I said before, custom page templates are the kind of page templates that everyone thinks of when "page templates" are mentioned, because of their ease of use and consequent popularity.

      Creating custom page templates is also very easy. You just put the following piece of PHP comment at the beginning of the template file and WordPress takes care of the rest:

      That's it! Now in the editing screen of each page, you can select this custom page template instead of the default page template.

      If you're going to make and release a theme, keep in mind that custom page templates are one of the best ways to enrich a theme, and you're practically expected to create a couple of them.

      Useful Tips and Tricks

      Creating a specialized or custom page template: This one's a no-brainer—if you want to create a specialized or custom page template, just duplicate the page.php file, rename it with a name of your choice, and edit the file as you like.

      Organizing page templates in a subfolder: Here's a fun fact: You can store your custom page template files in a subfolder, instead of dumping them all to the root folder of your theme. (This does not apply to specialized page templates.) Just keep in mind that a child theme also needs to have the same subfolder if it intends to override the custom page templates in the parent theme.

      If you don't want (or need) to have a subfolder, you should at least name your custom page template files with a prefix (like page-template-***.php) to increase their visibility among other theme files.

      Using custom templates in other post types: Sadly, the liberty of using custom templates isn't possible for post types other than Pages. You can set a generic page template for your Portfolio post type by creating a specialized template file called single-portfolio.php but you can't set different custom templates for each portfolio item. In order to achieve it, I found an old (and possibly abandoned) plugin called Custom Post Type Page Template. It still works nicely in WordPress 4.0, so you might want to give it a shot if you really need this kind of functionality.

      Naming your custom page templates right: If you're developing a theme to release it, you should think from the perspective of all users, not just you. Naming custom page templates is just one example: If you want people to use your theme without any hassle, you should pick your custom page template names carefully. You might understand what "1/1" means, but you must name it to "Full Width Page" to prevent any confusion. Your users might even just skip using custom page templates altogether if they don't understand what they're about.

      Final Words

      Compared to other features, page templates have a a very simple logic, and yet they show us the richness of WordPress (in terms of design) more than any other WordPress feature. I personally love them, and looking at the variety of custom page templates in the most popular free and commercial WordPress themes, I can say that the community loves them as well.

      What do you think about page templates? Do you have any different ideas, opinions, or things I missed in this tutorial? Tell us what you think in the comments section. And if you liked the article, don't forget to share it with your friends!



      Leave a comment › Posted in: Daily

  • Page 3 of 64 pages  < 1 2 3 4 5 >  Last ›
  • Browse the Blog