4elements, Amsterdam, Holland

  1. The Beginners Guide to WooCommerce: Order Reports - Part 3

    The first tab of reports in WooCommerce is for the "Orders" which an online store owner receives during a particular duration of time. This section is further divided into four sub-sections which provides a store owner with more and well refined filtered results. Of these four, I discussed the first two sub-sections (i.e. Sales by date & Sales by product) in my last two articles. So today, I will explain the details and functioning of the third part of Order reports which is Sales by category

    Sales by category

    As the name explains its meaning Sales by category will display all the order reports w.r.t categories which are a part of your online store. You can see the reports for the entire category as a whole. If I talk in terms of a much detailed view, Sales by date and Sales by product allow online store owners to study their store performance much deeply as compared to Sales by category

    However, if you want to get a quick overview of your store's performance then this option serves best for this purpose. Just in a glance you can closely observe the total earnings, loss & profit which is generated from the sales.

    Sales by category

    To access to this part of the plugin go to via WooCommerce > Reports > Orders > Sales by category.

    Sales by category layout

    You will find a layout similar to one which I discussed in case of Sales by date and Sales by product. Which means that various filters which display results for reports with different time spans are available in the first row. These filters are based upon Year, Last Month, This Month, Last 7 days and a Custom date. Towards the end of this first row is a button for Export CSV which allows the online store owners to download any of the reports in .csv file format.

    There again exists a column below the first row to the left. Here is where you can select a category. Enter the name select the category and its reports will be displayed.


    In this search bar you can add single or multiple categories or subcategories. A button called Show to display the reports. To make things simpler and consume less time next to the Show button are the options for All & None, which allow you to add or remove all the categories from the Search bar in a single click. 

    All categories in sales by category

    Let's me explain this scenario by considering that I clicked All and the Search bar displayed all the categories I had in my online store. In my case, the store offered mainly 7 different categories & subcategories i.e. Clothing, Hoodies, T-shirts, Music, Albums, Singles & Posters. You can remove any of these entries simply by clicking the cross.

    sales by category report

    To view the order reports click Show. As a default, the time filter is set to Last 7 Days so the first set of reports will be displayed for this time period.

    sales by category report last 7 days

    The layout and format of the reports is also the same with a column displaying all the details being individually stacked up. However, the contents are different. Now, there are no graphs, points or lines instead online store owners will view reports of his categories in the form of bar charts. 

    Likewise, the entries in the column lists the amount generated by each category or sub-category individually. Last but not the least, in case you hover your mouse over any of these rows, it will turn that section in purple on the bar chart. 

    The above figure shows that the rightmost bar appears purple which indicates that the mouse is positioned on the last row i.e. sales in Posters category. In the previous figure this bar was originally red in color. 

    Based on these facts I am adding the reports for other time filters as well.

    This Month

    sales by category report this month

    I am taking January 2015 as the reference month so the above figure shows report for This Month. All the previous explanation applies in this case as well.

    Last Month

    sales by category report last month

    Sales by category order reports for the Last Month will correspond to the results for December 2014.


    sales by category report yearly

    Last but not the least is the yearly report of sales by category. All the results are beautifully displayed in vibrant colors making it quite easy for online store owners to monitor his store's performance in a single glance. 


    This is it for today, l hope to have made things pretty clear by now. In the next article I will discuss the last part of order reports. If you have any queries regarding today's post you may ask in the comments.



    Leave a comment › Posted in: Daily

    1. How to Monitor Docker-Based Applications Using New Relic


      Docker is one of the fastest-growing new technologies at the moment. A solution for deploying software and building scalable web service architectures, it allows you to split your application's architecture into containers with specific roles and responsibilities. Using Docker, you also get to specify the application's dependencies on the operating-system level, bringing us the closest we've ever been to Java's original promise: "Write once, run anywhere".

      On the downside, encapsulating your code inside a set of containers can lead to a lack of visibility: the containers become black boxes and leave the developer with little or no visibility into their inner workings.

      To fix this, New Relic took up the task and made its server-side monitoring tools (Servers and APM) support Docker. In June 2015, the Docker support became available for all New Relic customers. 

      In the post announcing the Docker support, Andrew Marshall from New Relic writes:

      "You can now drill down from the application (which is really what you care about) to the individual Docker container, and then to the physical server. No more blind spots!"

      By monitoring your Docker-based application using New Relic's tool set, you can now analyze the application as a whole and then, when you find issues in your application, look up the containers where the problems occur and fix the issues inside them. 

      Also, by monitoring the application at the Docker level, you will get valuable information about your setup: are you using your containers wisely, and does the division of resources between containers work as it should? 

      In This Tutorial

      In this tutorial, I will show you how to get started with monitoring a simple Docker-based application using New Relic's tools.

      You will learn:

      • how to set up New Relic monitoring on a web server running a set of Docker containers to gather information about the overall Docker environment
      • how to set up New Relic monitoring for a PHP application running inside one or more Docker containers to monitor the state of the application as well as the individual Docker container

      To achieve this, we will create a simple prototype for a hosted WordPress solution: three WordPress sites each running in a Docker container and a MySQL container shared between them. 

      With the setup in place, we will then enable New Relic monitoring and go through the monitoring tools' views and explore the data you'll find in them.


      While I hope you will learn something about using Docker by reading this tutorial, it's not meant to be a tutorial about Docker as much as it is about using New Relic's monitoring tools together with your Docker-based applications. 

      That's why, to get the most out of the tutorial, you should be at least somewhat familiar with Docker. Also, a basic understanding of the Linux command line is expected. 

      Set Up the Docker Containers

      In short, Docker is a tool for packaging your application's components and their dependencies into well-documented, self-contained units that can be deployed quickly and reliably into different environments—be it a development machine or a cluster of production servers.

      These building blocks are called containers—a concept close to a virtual machine, but not quite. Whereas a virtual machine runs its own operating system, containers all run on the same host operating system but each have their own dependencies and libraries. Containers can also be linked to each other to allow them to share, for example, their resources. 

      To learn more about Docker, the best place to start is the tool's online documentation. It is well written and will guide you by the hand. 

      Then, once you feel comfortable about trying Docker in action, let's get started with our setup!

      What Will We Build?

      Before we get started with implementing our Docker and New Relic setup, here's an image showing an overview of the basic architecture that we're going to build in this tutorial:

      A simple WordPress stack build on Docker containers and reporting to New Relic

      As I mentioned in the introduction, this is a simplified hosted WordPress service: In three containers (an arbitrary number), we'll run a WordPress installation in each. The WordPress containers are all linked to a container running MySQL. All of this will run on one server—which in the example will be hosted on Amazon Web Services, but can be any server capable of running Docker and New Relic's monitoring tools.

      The server and the containers running inside it will be monitored by New Relic's APM (Application Performance Monitoring) and Servers tools.

      I designed this setup mostly for demonstration purposes, but it is actually modeled after something I'm building in my own project: just by adding an admin tool, a proper DNS configuration, and an Nginx reverse proxy—all of these running in their own Docker containers—the setup can be built into a fully functional hosted WordPress service. This, however, is outside the scope of this tutorial, so let's get back to running some WordPress containers.

      Step 1: Start a New EC2 Machine

      I like to use Amazon Web Services when I need a web server for experiments like this: the servers are cheap to start, and you only pay for the time you use them (just remember to stop them when you're done!).

      However, there's nothing Amazon-specific about using Docker with New Relic, so if you prefer some other virtual server provider or have a server of your own on which you can install Docker and the New Relic monitoring tools, these are all good options. 

      In that case, you can skip this step and move straight to installing Docker on the server machine (Step 2).

      In my earlier tutorial, Get Started With Monitoring Your Web Application Using New Relic Alerts, I included detailed, step-by-step instructions for starting a machine in the Amazon cloud. Follow those instructions, in the tutorial's Step 1, but don't install PHP or start Apache just yet as this time, because Apache and PHP will go inside the Docker containers.

      If you're already familiar with AWS and just want a quick reminder of which options to choose when starting the machine, this short list will guide you through the process:

      1. Sign in to the AWS console, creating an account if you don't have one yet.
      2. In the main menu, choose EC2. You'll notice that Amazon has recently launched a new service for running Docker containers in the cloud (EC2 Container Service), but this time, we'll want to manage Docker ourselves.
      3. Select Launch Instance to launch a new machine. Go with the Quick Start option and pick the default, 64-bit Amazon Linux server. For testing, a t2.micro machine size is just fine.
      4. On the security group page, open the HTTP port and make SSH available only from your IP by selecting the My IP option.
      5. Click Review and Launch to start the server. When you're asked to create a key pair, create one (name it for example docker_test) and download it.

      After a minute or so, you'll notice that your machine is up. 

      Right click on its name and choose the Connect option. Copy the machine's IP address from the popup and use it to connect to the machine using SSH (place the IP address where it says INSERT_IP_HERE in the commands below):

      Step 2: Install Docker on the Server

      Now that you have started a server and you are connected to it over SSH, it's time to install the Docker engine.

      The instructions in this step are for the Amazon Linux server we created in Step 1. If you are using a different operating system, see the Docker documentation for installation instructions specific to your environment.

      Start by installing the docker package:

      The -y option makes yum automatically answer yes to any questions about the installation. It makes things quicker, but if you want to play safe, feel free to leave it out.

      Once the Docker package has been installed, start it as a service:

      Now, you'll find Docker running for the rest of this server's runtime (or until you stop it yourself).

      To test the installation, you can use the docker ps command which lists the running Docker containers:

      At this time, the list is still empty, as we haven't yet started any containers:

      The Docker process list shows no running containers

      Finally, add the default user to the docker group so you can control Docker without having to prefix all your Docker commands with sudo. It's just four extra letters, but makes a big difference when you have to write it often! 

      To apply the change to your connection, close the ssh connection and connect again. 

      Now, you're all set to start some Docker containers.

      Step 3: Start the Docker Containers

      If you search for WordPress and Docker (or MySQL and Docker), you'll notice that there are many different Docker images to choose from. In your own application, it's a good idea to go through the most popular ones and see which works best for you—or if you should actually write one from scratch. 

      In this tutorial, I decided to go with official images: the MySQL image provided by MySQL, and Docker's official WordPress image.

      First, start a container using the MySQL imagemysql/mysql-server:5.5

      The command downloads the package and its dependencies and then starts your MySQL container, naming it db. The name is important as we'll use it to link our WordPress containers to the database. 

      If you like, use docker ps to check that the new container is running. For some more information about the startup, you may check the container's log file with docker logs db. You should see something like this as the last few lines of the output:

      Next, start a WordPress container using Docker's WordPress image, wordpress:latest (using the latest tag, you'll always get the most up-to-date Apache-based version). 

      In the command above, you'll notice that we link the container to the MySQL image above (--link db:mysql) and pass the name of the database to use as an environment variable (-e WORDPRESS_DB_NAME="wordpress_1"). This container listens to the standard HTTP port 80

      The root user's database password is shared automatically when we link the db container.

      Once the image has been loaded and the container is running, visit the machine's URL to check that the container is working as it should. When working on AWS, use the Public IP from Step 1.

      Visiting the site youll find WordPress running

      Finish the WordPress installation if you like—it only takes a minute or two. 

      You have now started the first of the three WordPress containers. Before we add the rest, let's set up New Relic monitoring for the current setup.

      Install New Relic Server Monitoring With Docker Support

      New Relic's Docker support is divided into two parts: 

      • In the Servers part, you'll find overall information about Docker: things like how many containers of different types are running, or how much of the resources they are using on each of your servers. 
      • In the APM part, you can access the Docker containers as parts of your web applications, monitoring them together as well as individually on the application level.

      Let's begin with the Servers part. 

      Step 1: Install the New Relic Server Monitor

      As New Relic runs as an online service, to use the New Relic monitoring tools, you'll first need an active New Relic account. You can start with a 14-day free trial or use the free version—all of the functionality presented in this tutorial is available in the free version. 

      If you don't have a New Relic account yet, start by signing up.

      Once signed up, select Servers from the top menu to access the server monitoring tool.

      The New Relic menu bar

      If you are already using New Relic Servers, you'll see a list of your servers monitored with New Relic. Click on the Add more button for setup instructions.

      If you just signed up, you'll be sent straight to the Get started with New Relic Servers page. 

      On this page, you'll find instructions specific to the different environments. Pick the one that matches your server. For the Amazon Linux setup used in this tutorial, we'll go with the Red Hat or CentOS option.

      Get started with New Relic Servers

      Scroll down, and finish the installation according to the instructions matching your server environment.

      In the case of Amazon Linux, start by adding the New Relic yum repository. Notice that this needs to be done as root, so we'll use sudo.

      Next, with the yum repository added, use it to install the Server Monitor package:

      Again, the -y parameter makes yum answer yes to every prompt. If you want to be more careful, feel free to go without it and accept the prompts manually.

      To complete the installation, configure the monitoring agent and set your license key. You'll find a version of the command with your license key in place on the Get started with New Relic Servers page. Remember to prefix the command with sudo.

      Before starting the monitoring daemon, we'll divert a bit from the setup instructions on the New Relic Servers page and make a few additional configurations for Docker monitoring.

      Step 2: Apply Docker Specific Configuration

      First, to allow New Relic to collect data about your Docker setup, add the newrelic user to the Docker group on your server:

      Then, restart Docker. 

      Notice that to do the restart gracefully and to make sure nothing breaks in your containers, it's a good idea to stop all running containers first.

      Once the restart is complete, we're all set and you can start the server monitoring daemon.

      The setup for the New Relic server daemon is now complete. Start the Docker containers again, and you'll soon see information about your server in the tool's dashboard. 

      Let's take a look at what you can find there.

      What You'll Find Inside New Relic Servers

      Inside New Relic, click on the Servers menu item to reload the list of servers. If all went well, you should now see your server listed:

      The server listing now shows our new server

      Click on the machine's name to see more information about it. If no data is shown yet, give the tool some time and try again.

      The first thing you'll see is the overview page.


      On the overview page, everything looks pretty much the same as it would on a New Relic Servers overview page when monitoring a regular server without Docker. 

      The New Relic Servers overview page

      There is the CPU usage, the server's load average, the amount of physical memory used, some information about Disk I/O and network usage. As we just started the server and there are no users visiting the site, most of these figures are still low.

      If you look at the list of processes on the bottom right, you'll notice that Docker is indeed running on this server:

      The list of processes show Docker running on the server

      The Docker Images View

      The overall view is important when thinking about the server's health as a whole, but now, what we are really interested in is what we can learn about the Docker setup. For this, the more interesting part of Servers is the Docker menu. 

      Click on the Docker menu item on the left. 

      The Docker Images view on New Relic Servers

      The Docker screen shows the percentage of the server resources your Docker containers are using, grouped by their images. 

      In this case, for example, you'll see the two images, wordpress:latest and mysql/mysql-server:5.5, that we used to start our two containers in the previous steps. There isn't much activity on the server, but we can see that WordPress is using more of the CPU, and both use about the same amount of memory. 

      You can use the drop-down on the top left corner to sort the list by either CPU or Memory.

      Later, as your application matures, the findings from this page will tell you more about your setup and what you should do with it. 

      For example, if you notice that MySQL is using a lot of the system's memory and processing power, it might be a good time to consider moving it to its own dedicated server. Or maybe you'll notice that there are more WordPress containers running on the server than what really fits and decide to split them into two...

      A Closer Look at One Docker Image

      If you want to learn more about a specific image, click on its name on the list on the left. This will open a view that shows information about just the containers using this image. 

      A closer look at the WordPress image

      The screen shows you the CPU and memory usage from containers using this image and the number of containers over time. 

      To see how adding more containers affects the view, add a couple more WordPress containers. We'll use the same docker run command from earlier, with a few small changes:

      • The new containers will be named wordpress-2 and wordpress-3 respectively.
      • The new containers will use databases wordpress_2 and wordpress_3.
      • The new containers will listen to different ports, 8000 and 8001 instead of 80.

      Here are the two run commands with the changes from the list above in place:

      On Amazon, to make the new WordPress sites accessible, you'll still need to edit your EC2 instance's Security Group settings to allow incoming traffic from ports 8000 and 8001. Use the Custom TCP Rule option and select Anywhere as traffic source.

      Now, visit the two new WordPress sites, clicking on some of their menu items. 

      Then come back to New Relic Servers to see how the data on the Docker page changed.

      The first, and most visible change is the number of containers running. Instead of one, there are now three:

      The Containers graph show the change in the number of running containers

      CPU and memory usage is still low—although the use of memory shows growth:

      CPU and memoery usage after adding two more WordPress containers

      Adding Support for New Relic APM in Your Docker Containers

      So far, we have looked at the Docker containers from the outside, through their resource usage, and how they look when explored from the server running them. 

      But even though this Servers view to Docker does provide useful overall information about your server and what's running inside it, the true power of New Relic lies in its application-first approach: by monitoring the application level, you can gain more detailed information about what is happening on your server and what to do about it.

      Normally, when running the PHP code directly on your web server, you'd simply install the APM monitoring agent. For an example of this, you can look at the right there on the server on which you're running the application (as we did in the New Relic Alerts tutorial I mentioned earlier). 

      Now, things are a bit different: We have split the architecture into separate pieces—"micro services"—each running in their own containers, and so the host server itself isn't running Apache or PHP. That's why, if you were to install the APM agent directly on the host server, you wouldn't see any activity whatsoever.

      The monitoring needs to go inside the containers.

      Step 1: Create Your Own Version of the WordPress Image

      One of the great things about Docker is the way it lets you build upon existing images, using them as a base and making them your own without having to change the original image or write a new one from scratch.

      We will modify the WordPress image we used earlier in the tutorial by enabling New Relic monitoring inside it. 

      You can download the source file for the Docker image from the linked GitHub repository, or you can create it yourself by following the instructions in this tutorial. When working with this example, it's probably easiest to do it right there on your server.

      Start by creating a directory for the new image definition, for example in ec2-user's home directory. 

      Then, in that directory, add a new text file, naming it Dockerfile. This is the file that will contain the definition of what goes into your Docker image.

      Inside the file, add the following code. We'll go through the contents line by line right after the snippet.

      Now, let's go through the file and see what it does.

      Line 1: The file starts by specifying the Docker image that our image should be built on. I picked a specific version of the wordpress image so that if we build this image again after a while, it will not have changed in between. 4.3.1-apache is the latest version at the time of writing.

      Lines 3–5: Include a script for initializing the New Relic monitor. The script will be run at container startup so that we can use it to define the application's name and license key separately for every container. 

      We'll look at the contents of this file in the next step.

      Lines 7–8: If you look closely at the code defining the base WordPress image, you'll notice that the script, apache-entrypoint.sh, defined to run as its ENTRYPOINT ends with a line that executes the command passed in the CMD option (by default, this is apache2-foreground). 

      The line looks like this:

      As I didn't want to replace the original "entrypoint" script but needed to have it finish by calling the new run.sh script we just mentioned above, I decided to edit the ENTRYPOINT file at compile time: the sed command (on line 8) replaces the exec line from above with an exec command that executes run.sh instead.

      Lines 10–11: This is probably not something you'll want in a production setup. However, for testing it's very handy to include a simple PHP file that we can use to check if New Relic was set up correctly. 

      Make sure to also create a file named test.php with the following content:

      Lines 13–20: This is the part where we install the New Relic monitoring package into the image.

      If you look at the installation instructions on New Relic's Get Started with New Relic page (the first page you'll see when you choose the APM option after signing in), you'll notice that the commands on these lines are closely following the installation instructions for the Debian environment. This is because the default WordPress image is based on an image that uses Debian.

      First, the script installs wget and uses it to download the New Relic key and add it to APT. 

      Next, the script adds the New Relic repository to APT.

      And then, finally, on lines 19 and 20, it installs the newrelic-php5 package from that repository.

      Lines 22–25: The New Relic installation instructions on the Get started with New Relic page continue with finalizing the installation and putting the license key in place. 

      As the license key and application name are quite container-specific information, we can't include this final step in the image. Its place is only at startup, in our run.sh script. 

      To prepare for this, the script defines three environment variables:

      • NR_INSTALL_SILENT: This variable, if present (and set to any value) will cause the New Relic installation script to skip all user prompts and use defaults instead.
      • NR_INSTALL_KEY: This one specifies the license key. As we don't want to hard-code a license key in the image definition, it's set to **ChangeMe** for now. This variable is also read automatically by the install script.
      • NR_APP_NAME: This is a variable I added myself, which will be used in the run.sh script to edit the New Relic daemon's configuration to use the container's actual application name instead of the default ("PHP Application").

      Step 2: Create the Custom Startup Script

      With the Dockerfile ready, we still need to implement the startup script, run.sh, mentioned above. The script will finish the New Relic setup and only then start the server, now with New Relic monitoring in place. 

      Create the file and add the following code into it:

      Now, let's go through the code line by line.

      Line 1: Specify that the script should be run with the bash interpreter.

      Line 2: Specify that the script should exit if an error occurs.

      Lines 4–5: Run the New Relic installation script. Notice that we don't need to pass in any parameters as the configuration is done using environment variables. NR_INSTALL_SILENT was already specified in the Dockerfile and NR_INSTALL_KEY should be passed in with the docker run command.

      Lines 7–8: As the installation script doesn't have an environment variable for specifying the name of the application, we'll have to edit the configuration manually—or actually, programmatically—in this script. 

      In the configuration file, the application name is specified as:

      The sed command on line 8 looks for this string and replaces it with a version that includes the name defined in NR_APP_NAME.

      Line 10: Finally, to complete the startup, call apache2-foreground to run Apache in the foreground and keep the container running. As you remember from earlier, this was originally done at the end of the entrypoint script.

      Now, all the pieces for augmenting the WordPress image with New Relic monitoring are in place. We can now build the image and give it a try.

      Step 3: Compile and Run the New Image

      In the directory where you placed the files created during the past two steps, enter the command: 

      This creates a new image, named tutsplus/wordpress-newrelic with the tag 4.3.1-apache, and adds it to your local Docker image repository.

      Once the build completes, it's time to see if everything is working properly.

      First, stop and remove your existing WordPress containers:

      Then, run new ones, starting with just one and adding more once you've checked that everything is running smoothly.

      The command is mostly the same as what we saw earlier when starting the default WordPress image, with the following changes: 

      -e NR_INSTALL_KEY="YOUR KEY HERE": This is where you specify the New Relic license key that should be used in the install script. You can find yours by going to APM's Get started with New Relic page and choosing the PHP option.

      On this page, right before the installation instructions, there's a red button that says Reveal License Key. Click on it and then replace YOUR KEY HERE with the key shown.

      Get your license key

      -e NR_APP_NAME="wordpress-cloud": This part of the command sets the environment variable used for specifying the application's name. This name is used to group the data inside APM. 

      The "correct" value for a container's name depends on your setup and how you want to monitor it. If all of your containers are running pieces of the same application, it will make sense to use the same name for them and collect them all in the same view in the monitoring tool. On the other hand, if the containers are clearly separate, distinct names are the way to go. In this example, I decided to use the same name, wordpress-cloud, for all three containers.

      Check the New Relic documentation for a more detailed discussion on naming your applications.

      tutsplus/wordpress-newrelic:4.3.1-apache: At the end of the command, you'll notice that we now use the newly created image instead of wordpress:latest.

      Once you've run the command and your server has started, visit the WordPress test page to verify that the server is running and New Relic is included. You may also want to check the value of newrelic.appname

      The PHP test page showing New Relic configuration

      Then, you can again go to the main page to find WordPress running OK. You now have a Docker container running WordPress and reporting its state to New Relic APM. 

      Add the remaining two containers, wordpress-2 and wordpress-3, and then let's take a look at the data we'll find in APM.

      What You'll Find Inside New Relic APM

      Now that you have set up the monitoring for each of your Docker containers, let's take a look at the information we can find about them in APM.

      As we added all three WordPress containers with the same name, when you now open the APM page, you'll find just that one application, wordpress-cloud. When you place your mouse pointer on top of the application's name, you'll see a popup saying "Php application running on 3 hosts (3 instances)."

      APM showing our Docker based application

      Click on the name to access the analytics data for this application and its containers.


      The first view you'll see in APM is Overview. This page shows a summary of the performance of all of the containers in this application: how long requests made to the application take on average, the application's Apdex score, its throughput, and a list of the application's slowest transactions .

      Overview of the wordpress-cloud application

      At the bottom of the screen, you'll find a summary of the structure of the application: what servers it's running on, and the containers in use inside them. 

      In a more complex, real-life application, you might see multiple servers as well as multiple containers. Now, you'll find our three WordPress containers. As we didn't install New Relic to the database image, we can't see it on this list.

      Filtering Data by Container

      Similar to the overview page, by default, the rest of the screens in APM will show you a summary of the entire application's performance in the various metrics presented in them. 

      However, if you want to drill down to a specific container, you can at any time use the drop-down menu at the top of the screen to choose the one you are interested in:

      Dropdown menu to choose a specific container

      If you are not sure what the different server codes on this list mean, you can use the docker ps command to find the mapping between these Docker IDs and your containers.

      Finding and Fixing PHP Errors in Docker Containers

      APM is not only useful for tracking the performance of your web-based application. It is also a great help in noticing when something goes wrong in your application and locating the issues. 

      To test this in a Docker-based environment, I created a simple WordPress plugin, intentionally placing a couple of errors in the code, and installed it on one of the containers. Then, after browsing the site for a while, this is what I saw on the Errors page in APM:

      The Errors page shows the applications errors

      Looking at the picture, you'll quickly see that the error rate in your application is on the rise.

      Below the graph, you'll find a list showing the recent errors: a syntax error that has occurred three times and a division by zero, taking place at various places in the code. Both need to be addressed, but for now, let's look at the first one.

      Clicking on the error message will bring you to a page that shows more information about the error:

      More information about the error

      Looking at this screen, you'll see that the error is occurring on one of the Docker containers, 402c389c0661, which just happens to be the ID of wordpress-3, the container on which I installed the broken plugin.

      Now that we have found the container on which the error happens, we can use the stack trace to fix the problem and update a working version of the plugin to the affected container. Issue solved. 


      You have now implemented a simple Docker-based web server setup and enabled New Relic monitoring on it. You have also seen how you can use the monitoring tools to gain better visibility into the Docker-based application.

      However, we have only scratched the surface of what you can do with the New Relic monitoring tools, so if you are not yet a New Relic user, take a look at the Docker Monitoring page at New Relic, and get started.



      Leave a comment › Posted in: Daily

    1. WP_Query Arguments: Date

      In this series on WP_Query, you've been learning how to use the WP_Query class to create custom queries in your theme files or plugins.

      This part of the series will take you through the arguments you can use to create both simple and complex date queries, to output posts published on, before, after or between given dates.

      I'll show you what parameters are available to you and how to use them to write your queries. But first, a reminder of how arguments work in WP_Query.

      A Recap on How Arguments Work in WP_Query

      Before we start, let's have a quick recap on how arguments work in WP_Query. When you code WP_Query in your themes or plugins, you need to include four main elements:

      • the arguments for the query, using parameters which will be covered in this tutorial
      • the query itself
      • the loop
      • finishing off: closing if and while tags and resetting post data

      In practice this will look something like the following:

      The arguments are what tells WordPress what data to fetch from the database and it's those that I'll cover here. So all we're focusing on here is the first part of the code:

      As you can see, the arguments are contained in an array. You'll learn how to code them as you work through this tutorial.

      Coding Your Arguments

      There is a specific way to code the arguments in the array, which is as follows:

      You must enclose the parameters and their values in single quotation marks, use => between them, and separate them with a comma. If you get this wrong, WordPress may not add all of your arguments to the query or you may get a white screen.

      Date Parameters

      You can also use parameters to query for posts with a publish date on a given date. You can be as specific as you like with dates, using years and months for example to retrieve a number of posts.

      You can write a simple set of arguments or you can use date_query to create nested arrays and run more complex queries. Let's start with the simpler arguments.

      Simple Date Arguments

      The parameters you can use to query by date are:

      • year (int): Four-digit year (e.g. 2015).
      • monthnum (int): Month number (from 1 to 12).
      • w (int): Week of the year (from 0 to 53). The mode is dependent on the "start_of_week" option which you can edit in your Settings page in the admin.
      • day (int): Day of the month (from 1 to 31).
      • hour (int): Hour (from 0 to 23).
      • minute (int): Minute (from 0 to 60).
      • second (int): Second (0 to 60).
      • m (int): YearMonth (e.g. 201502).

      So imagine you're running an events site that uses the publish date for each event to denote the event start date. To want to display all events, past and future, happening in 2015, here are the arguments you'd need:

      Note that I've used future and publish for the post status, as posts scheduled for a future date aren't queried by default.

      Or if you wanted to automatically display events happening this year, and not update your query every year, you could first get the current year and then pass that in your query arguments:

      Complex Date Arguments

      To use multiple date parameters to create more complex queries, you use the date_query parameter. This gives you access to more parameters:

      • year (int): Four-digit year (e.g. 2015).
      • month (int): Month number (from 1 to 12).
      • week (int): Week of the year (from 0 to 53).
      • day (int): Day of the month (from 1 to 31).
      • hour (int): Hour (from 0 to 23).
      • minute (int): Minute (from 0 to 59).
      • second (int): Second (0 to 59).
      • after (string/array): Date to retrieve posts after. 
      • before (string/array): Date to retrieve posts before. 
      • inclusive (boolean): For after/before, whether exact value should be matched or not.
      • compare (string): An operator you use to compare data in the database to your arguments. Possible values are '=', '!=', '>', '>=', '<', '<=', 'LIKE', 'NOT LIKE', 'IN', 'NOT IN', 'BETWEEN', 'NOT BETWEEN', 'EXISTS', and 'NOT EXISTS'.
      • column (string): Database column to query against: the default is 'post_date'.
      • relation (string): OR or AND, how the sub-arrays should be compared. The default is AND.

      The date_query parameter is formatted like this:

      You can also create multiple arrays and define how they will be compared using the relation parameter. The below example will return queries that match the arguments in both arrays:

      While the code below will fetch posts that match the arguments in either array (or both):

      Let's illustrate this with an example. Let's say you're working on a college website and want to display posts from this academic year. The academic year runs from 1 September 2014 to 31 August 2015, so you'd need to find posts in the relevant months and years:

      Note that the month parameter takes a string for its arguments, not an array.

      The before and after Parameters

      An alternative to the example above is to define the dates before and/or after which you want to display posts, using the before and after parameters. These take three arguments:

      • year (string): Accepts any four-digit year: empty by default.
      • month (string): The month of the year (1 to 12). The default is 12.
      • day (string): The day of the month (1 to 31). The default is the last day of the month.

      You can also use a string for the date, as long as it's compatible with the php strtotime format.

      So returning to my example of displaying posts for this academic year, I have two more options. Firstly, I could use a nested array with the year and month parameters:

      There are a couple of things to note here:

      • I've used 'relation' => 'AND' because the posts need to have been published after my start date and before my end date.
      • For each of the nested arrays, I've used 'inclusive' => true to ensure that WordPress fetches posts published during September 2014 and August 2015.

      I could also write this query using a string for the dates:

      Note that because of the way date strings work, it's more reliable to use exclusive dates. This is because if you use a date string, this will be converted to 00:00 on that date. So to make it work, either use the time in your string as well, or do as I've done and use the day before the date you want to show posts from (and after the date you want to show posts until).

      Something else you can do with date parameters is display posts published today. Going back to my events site, let's say I want to display a big banner on my home page on the day when an event is happening. I can write a query for this and then output details of the event if one is found. Here are the arguments:

      Using the date() function returns the current date—I've used this three times to ensure I get the correct day, month and year. Note that I've also included the post_status argument to ensure that an event happening later today is included.


      Sometimes you don't just want to query all the published posts. By using the WP_Query class you can create much more specific queries to output posts by date, including the posts you published on a given date, before a date, after a date or between a pair of dates.

      The date_query arguments combine with other parameters such as post_status, which is covered in more detail elsewhere in this series.



      Leave a comment › Posted in: Daily

    1. The Genius of Template Strings in ES6

      ES6 is the future of JavaScript and it is already here. It is a finished specification, and it brings a lot of features a language requires to stay competitive with the needs of the web of now. Not everything in ES6 is for you, and in this little series of posts I will show features that are very handy and already usable.

      If you look at JavaScript code I’ve written, you will find that I always use single quotes to define strings instead of double quotes. JavaScript is OK with either—the following two examples do exactly the same thing:

      The reason why I prefer single quotes is that, first of all, it makes it easier to assemble HTML strings with properly quoted attributes that way:

      The only time you need to escape now is when you use a single quote in your HTML, which should be a very rare occasion. The only thing I can think of is inline JavaScript or CSS, which means you are very likely to do something shady or desperate to your markup. Even in your texts, you are probably better off to not use a single quote but the typographically more pleasing ‘.

      Aside: Of course, HTML is forgiving enough to omit the quotes or to use single quotes around an attribute, but I prefer to create readable markup for humans rather than relying on the forgiveness of a parser. We made the HTML5 parser forgiving because people wrote terrible markup in the past, not as an excuse to keep doing so.

      I’ve suffered enough in the DHTML days of document.write, creating a document inside a frameset in a new popup window and other abominations, to not want to use the escape character ever again. At times, we needed triple ones, and that was even before we had colour coding in our editors. It was a mess.

      Expression Substitution in Strings?

      Another reason why I prefer single quotes is that I wrote a lot of PHP in my time for very large web sites where performance mattered a lot. In PHP, there is a difference between single and double quotes. Single-quoted strings don’t have any substitution in them, whereas double-quoted ones do. That meant back in the days of PHP 3 and 4 that using single quotes was much faster, as the parser didn’t have to go through the string to substitute values. Here is an example of what that means:

      JavaScript didn’t have this substitution, which is why we had to concatenate strings to achieve the same result. This is pretty unwieldy, as you need to jump in and out of quotes all the time.

      Multi-Line Mess

      This gets really messy with longer and more complex strings and especially when we assemble a lot of HTML. And most likely you will sooner or later end up with your linting tool complaining about trailing whitespace after a + at the end of a line. This is based on the issue that JavaScript has no multi-line strings:

      Client-Side Templating Solutions

      In order to work around the mess that is string handling and concatenation in JavaScript, we did what we always do—we wrote a library. There are many HTML templating libraries, with Mustache.js probably having been the seminal one. All of these follow their own, non-standardized syntax and work in that frame of mind. It’s a bit like saying that you write your content in Markdown and then realizing that there are many different ideas of what “Markdown” means.

      Enter Template Strings

      With the advent of ES6 and its standardization, we can rejoice as JavaScript now has a new kid on the block when it comes to handling strings: Template Strings. The support of template strings in current browsers is encouraging: Chrome 44+, Firefox 38+, Microsoft Edge and WebKit are all on board. Safari, sadly enough, is not, but it’ll get there.

      The genius of template strings is that it uses a new string delimiter, which isn’t in use either in HTML nor in normal texts: the backtick (`).

      Using this one we now have string expression substitution in JavaScript:

      The ${} construct can take any JavaScript expression that returns a value. You can, for example, do calculations, or access properties of an object:

      That last example also shows you that multi-line strings are not an issue at all any longer.

      Tagged Templates

      Another thing you can do with template strings is prepend them with a tag, which is the name of a function that is called and gets the string as a parameter. For example, you could encode the resulting string for URLs without having to resort to the horridly named encodeURIComponent all the time.

      This works, but relies on implicit array-to-string coercion. The parameter sent to the function is not a string, but an array of strings and values. If used the way I show here, it gets converted to a string for convenience, but the correct way is to access the array members directly.

      Retrieving Strings and Values From a Template String

      Inside the tag function you can not only get the full string but also its parts.

      There is also an array of the raw strings provided to you, which means that you get all the characters in the string, including control characters. Say, for example, you add a line break with \n. You will get the double whitespace in the string, but the \n characters in the raw strings:


      Template strings are one of those nifty little wins in ES6 that can be used right now. If you have to support older browsers, you can of course transpile your ES6 to ES5; you can do a feature test for template string support using a library like featuretests.io or with the following code:

      Here are some more articles on template strings:

      More Hands-On With JavaScript

      This article is part of the web development series from Microsoft tech evangelists on practical JavaScript learning, open-source projects, and interoperability best practices, including Microsoft Edge browser and the new EdgeHTML rendering engine

      We encourage you to test across browsers and devices including Microsoft Edge—the default browser for Windows 10—with free tools on dev.modern.IE:

      In-depth tech learning on Microsoft Edge and the Web Platform from our engineers and evangelists:

      More free cross-platform tools and resources for the Web Platform:



      Leave a comment › Posted in: Daily

    1. Set Up Scheduled Tasks in Magento

      Cron is an important utility which allows you to execute scripts at certain regular intervals. It has become an important aspect for web­-based applications as well. There are lots of ways in which cron is useful to websites, from sending regular newsletter mails to synchronizing the database with third-party systems. You can also use cron to clean up the back­-end storage to improve the overall performance of an application.

      Magento supports cron in the core itself, as it does with several other utilities! It allows you to set up scheduled tasks in the module, so that they can run at regular intervals. Magento runs all the cron tasks using the "cron.sh" and "cron.php" files located in the root of the site. So you'll need to make sure that you've set up the system-level cron to run the "cron.sh" file at regular intervals, which eventually triggers the Magento cron system. And finally, Magento gathers all the cron jobs located in the modules, and runs them if needed in that particular cron run.

      Although Magento has already provided lots of cron jobs in the core modules itself, you can create a custom cron task in your module as well. And creating a custom module is exactly what we'll be talking about in the upcoming sections.

      A Glance at the File Setup

      We'll create a simple custom module named "Customcron". Here's the list of files required for the desired setup:

      • app/etc/modules/Envato_All.xml: It's a file which is used to enable our custom module.
      • app/code/local/Envato/Customcron/etc/config.xml: It's a module configuration file in which we'll declare the custom cron job.
      • app/code/local/Envato/Customcron/Model/Customcron.php: It's a model file in which we'll define the cron job logic.

      Custom Module: Set Up the Files and Folders

      First, we need to create a module enabler file. Create a file "app/etc/modules/Envato_All.xml" and paste the following contents in that file. We've used "Envato" as our module namespace and "Customcron" as our module name. It'll enable our "Customcron" module by default.

      Next, we need to create a module configuration file. Create "app/code/local/Envato/Customcron/etc/config.xml" and paste the following contents in that file.

      The "config.xml" file looks fairly simple—it declares the version number and model classes as per the Magento conventions. However, the important tag for us is <crontab>, which is used to declare all the jobs. It's one of the "event observers" which is used by Magento to gather all the cron jobs in the modules.

      Further, under the <jobs> tag, we've declared our custom crontab job using the <custom_cron_task> tag. It's a sort of unique identifier for the cron job. Although in the above file we've only created a single task, you can set up multiple cron jobs under the <jobs> tag. Next, under <custom_cron_task> we've defined <schedule> and <run> tags.

      The <schedule> tag defines cron intervals inside the <cron_expr> tag at which the job will run regularly. In our case, the custom cron task will run every five minutes. But wait, what will it do every five minutes? That's exactly what the <run> tag stands for! It declares the "Model method" which will be called by Magento during the custom cron job run.

      Next, we'll create a model "Cronjob.php" file. Create "app/code/local/Envato/Customcron/Model/Customcron.php" with the following contents.

      So as we declared earlier, we've defined the "customcrontask" model method. In this method, we're simply sending an email using the Magento email class utility. But more importantly, this method will be called regularly, at every cron job run, of course every five minutes.

      And finally, you should make sure that you've created a cronjob entry in your system. For Linux, you simply need to add the following line to your crontab file.

      You just need to replace "/path/to/magento/site" with the actual path of the Magento installation. And for Windows, you can do the same by using scheduled tasks. However, in Windows, you need to use the "/path/to/magento/site/cron.php" file, as "cron.sh" is not supported.

      So it's really straightforward to plug your custom cron jobs into the Magento cron system! That's it for today, and I hope you've learned something useful in Magento. Share your thoughts using the feed below!



      Leave a comment › Posted in: Daily

  • Page 1 of 103 pages  1 2 3 >  Last ›
  • Browse the Blog