Project Guidelines is a set of best practices for JavaScript projects.
There are a lot of PHPUnit posts on our site already (just check the tag), but it's been a while since we've actually introduced people to it, and the tool has evolved significantly since then.
This article aims to re-introduce the tool in a modern way, to a modern audience, in a modern PHP environment - if you're unfamiliar with PHPUnit or testing, this post is for you.
Here we assume you're familiar with object oriented PHP and are using PHP version 7 and above. To get an environment up and running which has PHP 7 pre-installed, and to be able to follow instructions in this post to the letter without getting tripped up, we suggest you use Homestead Improved. Note also that some command line usage will be expected, but you will be guided through it all. Don't be afraid of it - it's a tool more powerful than you can imagine.
If you're wondering why we're recommending everyone use a Vagrant box, I go in depth about this in Jump Start PHP Environment, but this introduction of Vagrant will explain things adequately as well.
Test Driven Development is the idea that you write code in such a way that you first write another bit of code the sole purpose of which is making sure that the originally intended code works, even if it's not written yet.
Checking if something is indeed what we expect it to be is called asserting in TDD-land. Remember this term.
For example, an assertion that 2+2=4 is correct. But if we assert that 2+3=4, the testing framework (like PHPUnit) will mark this assertion as false. This is called a "failed test". We tested is 2+3 is 4, and failed. Obviously, in your application you won't be testing for sums of scalar values - instead, there'll be variables which the language will replace with real values at run-time and assert that, but you get the idea.
PHPUnit is a collection of utilities (PHP classes and executable files) which makes not only writing tests easy (writing tests often entails writing more code than the application actually has - but it's worth it), but also allows you to see the output of the testing process in a nice graph which lets you know about code quality (e.g. maybe there's too many IFs in a class - that's marked as bad quality because changing one condition often requires rewriting as many tests as there are IFs), code coverage (how much of a given class or function has been covered by tests, and how much remains untested), and more.
In order not to bore you with too much text (too late?), let's actually put it to use and learn from examples.
The code we end up with at the end of this tutorial can be downloaded from Github.
To drive the examples home, we'll build a simple command line package which lets users turn a JSON file into a PHP file. That PHP file will contain the JSON data as an associative PHP array. This is just a personal use case of mine - I use Diffbot a lot and the output there can be enormous - too large to manually inspect, so easier processing with PHP can come in very handy.
Henceforth, it is assumed that you are running a fully PHP 7 capable environment with Composer installed, and can follow along. If you've booted up Homestead Improved, please SSH into it now with vagrant ssh, and let's begin.
First, we'll go into the folder where our projects live. In the case of Homestead Improved, that's Code.
cd Code
Then, we'll create a new project based on PDS-Skeleton and install PHPUnit inside it with Composer.
git clone http://ift.tt/2gQr2Hf converter
cd converter
composer require phpunit/phpunit --dev
Notice that we used the --dev flag to only install PHPUnit as a dev dependency - meaning it's not needed in production, keeping our deployed project lightweight. Notice also that the fact that we started with PDS-Skeleton means our tests folder is already created for us, with two demo files which we'll be deleting.
Next, we need a front controller for our app - the file all requests are routed through. In converter/public, create index.php with the following contents:
<?php
echo "Hello world";
You should be familiar with all the above contents. With our "Hello World" contents in place, let's make sure we can access this from the browser.
If you're using Homestead Improved, I hope you followed instructions and set up a virtual host or are accessing the app via the virtual machine's IP.
Let's delete the extra files now. Either do it manually, or run the following:
rm bin/* src/* docs/* tests/*
You may be wondering why we need the front controller with Hello World. We won't be using it in this tutorial, but later on as we test our app as humans, it'll come in handy. Regardless, it won't be part of the final package we deploy.
We need a PHPUnit configuration file which tells PHPUnit where to find the tests, which preparation steps to take before testing, and how to test. In the root of the project, create the file phpunit.xml with the following content:
<phpunit bootstrap="tests/autoload.php">
<testsuites>
<testsuite name="converter">
<directory suffix="Test.php">tests</directory>
</testsuite>
</testsuites>
</phpunit>
phpunit.xml
A project can have several test suites, depending on context. For example, everything user-account-related could be grouped into a suite called "users", and this could have its own rules or a different folder for testing that functionality. In our case, the project is very small so a single suite is more than enough, targeting the tests directory. We defined the suffix argument - this means PHPUnit will only run those files that end with Test.php. Useful when we want some other files among tests as well, but don't want them to be run except when we call them from within actual Test files.
You can read about other such arguments here.
The bootstrap value tells PHPUnit which PHP file to load before testing. This is useful when configuring autoloading or project-wide testing variables, even a testing database, etc - all things that you don't want or need when in production mode. Let's create tests/autoload.php:
<?php
require_once __DIR__.'/../vendor/autoload.php';
tests/autoload.php
In this case, we're just loading Composer's default autoloader because PDS-Skeleton already has the Tests namespace configured for us in composer.json. If we replace template values in that file with our own, we end up with a composer.json that looks like this:
{
"name": "sitepoint/jsonconverter",
"type": "standard",
"description": "A converter from JSON files to PHP array files.",
"homepage": "http://ift.tt/2gQr2Hf",
"license": "MIT",
"autoload": {
"psr-4": {
"SitePoint\\": "src/SitePoint"
}
},
"autoload-dev": {
"psr-4": {
"SitePoint\\": "tests/SitePoint"
}
},
"bin": ["bin/converter"],
"require-dev": {
"phpunit/phpunit": "^6.2"
}
}
After this, we run composer du (short for dump-autoload) to refresh the autoloading scripts.
composer du
Remember, TDD is the art of making errors first, and then making changes to the code that gets them to stop being errors, not the other way around. With that in mind, let's create our first test.
<?php
namespace SitePoint\Converter;
use PHPUnit\Framework\TestCase;
class ConverterTest extends TestCase {
public function testHello() {
$this->assertEquals('Hello', 'Hell' . 'o');
}
}
tests/SitePoint/Converter/ConverterTest.php
It's best if the tests follow the same structure we expect our project to have. With that in mind, we give them the same namespaces and same directory tree layouts. Thus, our ConverterTest.php file is in tests, subfolder SitePoint, subfolder Converter.
The file we're extending is the most basic version of the Test class that PHPUnit offers. In most cases, it'll be enough. When not, it's perfectly fine to extend it further and then build on that. Remember - tests don't have to follow the rules of good software design, so deep inheritance and code repetition are fine - as long as they test what needs to be tested!
This example "test case" asserts that the string Hello is equal to the concatenation of Hell and o. If we run this suite with php vendor/bin/phpunit now, we'll get a positive result.
PHPUnit runs every method starting with
testin aTestfile unless told otherwise. This is why we didn't have to be explicit when running the test suite - it's all automatic.
Our current test is neither useful nor realistic, though. We used it merely to check if our setup works. Let's write a proper one now. Rewrite the ConverterTest.php file like so:
Continue reading %Re-Introducing PHPUnit – Getting Started with TDD in PHP%
Web components are a set of standards for creating custom, reusable HTML elements. Polymer is an open-source JavaScript library for building web applications using web components. Created by those clever folks at Google, it provides a number of additional features over vanilla web components and when used with a polyfill, supports the latest version of all major browsers.
In this tutorial I'm going to show you how easy it is to make use of web components and Polymer in WordPress. I'm going to start by showing you how to integrate Polymer into your WordPress install, then I'm going to demonstrate how to add a working Google Maps component to your site's side bar. This might be useful for any site (e.g. that of a restaurant) which needs to provide visitors with directions to their premises.
After reading, you'll be able to employ this technique on a site of your own. And you'll not be limited to a Google Map widget, you'll be able to choose from the wide range of pre-made components, or even write your own.
As ever, all of the code for this tutorial is available in a GitHub repository.
As native support for web components is growing ever better, you might be forgiven for asking if Polymer is still relevant. The short answer to that question is Yes!
Polymer does make use of a variety of web component polyfills—which will hopefully one day full by the wayside—but it is a lot more than that. Polymer is a wrapper around the web components API that allows us to develop and implement new components at a much greater speed than we would otherwise be able. It offers various additional features over vanilla web components, such as one-way and two-way data binding, computed properties and gesture events. It comes with a very polished CLI which can be used for such tasks as scaffolding out a project, running tests, or running a local server, and it can make use of a wide range of pre-built elements, such as the much loved material design elements library.
In short, Polymer is still very relevant. It is a powerful framework, which is used in production by large companies such as USA Today, Coca Cola and Electronic Arts.
Before we start, we need to setup our environment that is going to be running WordPress. For this tutorial, I'll be using the ScotchBox Vagrant VM, equipped with some pre-installed tools to kickstart your WordPress installation.
If you have WordPress installed already, or would prefer to use a different method, you can skip this bit. If you need a bit of help with the setup, but don't want to go the vagrant route described below, try Googling "install WordPress locally" and looking for an up-to-date tutorial.
We start of by making sure that Git, Vagrant and Virtual Box are installed on our system. We can then clone the GitHub repo with ScotchBox's pre-populated Vagrantfile.
git clone http://ift.tt/1xiiR9O sitepoint-wp-polymer
Now we are ready to run vagrant up. After our machine has booted, we have to remove the default /public/index.php static file and install WordPress.
cd sitepoint-wp-polymer/public
rm index.php
git clone http://ift.tt/1BFfzSc .
Now we have to make a duplicate of the wp-config-sample.php file. Name it wp-config.php.
cp wp-config-sample.php wp-config.php
and edit the following values:
// wp-config.php
// ...
define('DB_NAME', 'scotchbox');
define('DB_USER', 'root');
define('DB_PASSWORD', 'root');
// ...
Now you are ready to fire up your browser and visit http://192.168.33.10. You will be prompted to enter the admin account credentials and site title. Feel free to fill these out as you see fit.
So we've got WordPress set up, now we need a theme. Out of the box, this will be the Twenty Seventeen theme, but this is pretty generic and includes much more than you normally need. A good alternative here, is to use the SitePoint WordPress base theme.
This theme was created in response to the question "What would the perfect WordPress base theme look like?". Its features include:
The SitePoint WordPress base theme is a great starting point for new projects. It's mobile friendly, easy to use and 100% free. To follow along with the rest of tis tutorial, head over to the theme's homepage and download it now.
And while you're there, you might like to check out the suite of paid themes SitePoint offers, too. These are all built on top of the base theme and include an ecommerce theme, restaurant theme, portfolio theme, business theme and construction theme.
After downloading SitePoint WordPress base theme, unzip it and copy/paste to thewp-content/themes folder. Then create a new folder called sitepoint-base-child, in wp-content/themes. In that directory create a style.css file and a functions.php file.
cd wp-content/themes/
mkdir sitepoint-base-child
cd sitepoint-base-child
touch functions.php style.css
Open up style.css and copy this into it:
/*
Theme Name: SitePoint Base Child
Author: Almir B.
Author URI: http://ift.tt/28X308Z
Template: sitepoint-base
Version: 1.0.0
Text Domain: ab-sitepoint-base
*/
And into functions.php:
<?php
//functions.php
add_action( 'wp_enqueue_scripts', 'sp_theme_enqueue_styles' );
function sp_theme_enqueue_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
This will enqueue the base CSS from the parent theme.
We just created a child theme, whose role is to implement functionalities on top of the base theme without having to modify the base files. All of the customisations go into this child theme.
One last step is to go to the admin dashboard, then to Appearance > Themes from the main side menu, and click Activate under, Sitepoint Base Child theme.
Now that's done, we have to install Polymer with bower. Make sure you are in the public/wp-content/themes/sitepoint-base-child folder, and then run:
bower init
You can answer with default answer to every question. Next we need to install the dependencies:
bower install --save Polymer/polymer#^2.0.0 PolymerElements/paper-input#2.0-preview
This will install Polymer and the paper-input component, so that we can have a fancy material designed input component out of the box. It is important to use the #2.0-preview tag for the paper input and also for the Google Map element later, as it will not work with the latest version of Polymer (version 2.0) otherwise.
In order to user Polymer, we have to include it using an HTML import, and we will also include the polyfill for web components, so as to support older browsers.
Head to the functions.php file in the child theme, and add an enqueue to the existing enqueue function.
<?php
//functions.php
add_action( 'wp_enqueue_scripts', 'sp_theme_enqueue_styles' );
function sp_theme_enqueue_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
wp_enqueue_script( 'polymer', get_stylesheet_directory_uri() . '/bower_components/webcomponentsjs/webcomponents-lite.js' );
}
WordPress does not have an enqueue function for enqueueing HTML imports, but we can hook into the wp_head hook which outputs into the <head> element of the page.
<?php
//functions.php
add_action( 'wp_enqueue_scripts', 'sp_theme_enqueue_styles' );
function sp_theme_enqueue_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
wp_enqueue_style( 'polymer', get_stylesheet_directory_uri() . '/bower_components/webcomponentsjs/webcomponents-lite.min.js' );
}
add_action( 'wp_head', 'include_polymer_elements' );
function include_polymer_elements() {
?>
<link rel="import"
href="<?php echo get_stylesheet_directory_uri() ?>/bower_components/polymer/polymer.html">
<link rel="import"
href="<?php echo get_stylesheet_directory_uri() ?>/bower_components/paper-input/paper-input.html">
<?php
}
That's all we needed to start using Polymer elements in WordPress. Now let's create a WordPress widget so we can take this out for a test ride.
In order to create a new widget, we will create a new child class from the WP_Widget class and then register it with the widgets_init hook.
Create a new folder in your child theme, name it lib, and add it a file named sitepoint-map-widget.php.
mkdir lib
cd lib
touch sitepoint-map-widget.php
Copy the following into that file:
<?php
// lib/sitepoint-map-widget.php
class SitepointMapWidget extends WP_Widget {
function __construct() {
// Instantiate the parent object
parent::__construct( false, 'Google Paper Input' );
}
function widget( $args, $instance ) {
echo '<paper-input raised always-float-label label="Floating label"></paper-input>';
}
}
All we did here is create a new child class of WP_Widet and called the parent constructor in order to give the widget a custom name. Additionally, the widget function is the one that does the actual output. For now, we will simply output a <paper-input> element, which is an element from the paper-input-elements collection.
Last but not least, we need to include this new PHP file at the top of our functions.php file:
<?php
// functions.php
require_once( 'lib/sitepoint-map-widget.php' );
// ...
and then register a widget at the end of the file:
<?php
// functions.php
// ...
add_action( 'widgets_init', 'sp_register_widgets' );
function sp_register_widgets() {
register_widget( 'SitepointMapWidget' );
}
Now we can go into the admin dashboard of WordPress. From the main menu, go into Appearance > Widgets, and there you should see a widget named Google Paper Input on the left.
Drag and drop it into the Main Sidebar section to the right, above the rest of the default widgets from the SitePoint Base theme.
Now you can visit the homepage, and on the right side right above the search box, you will see a material design input with a label.
And thus we have concluded Polymer's Hello, World! example. We've covered a lot of ground already—installing Polymer, integrating it with WordPress and including a sample widget, all in just a few lines of code—but in the next section we will take this further and implement our Google Map component.
Continue reading %Using Polymer in WordPress: Build a Custom Google Maps Component%
Dirty Forms is a jQuery plugin to help prevent users from losing data when editing forms.
Dirty Forms will alert a user when they attempt to leave a page without submitting a form they have entered data into.
Build any site design without coding! You can have a fully equipped website up and running within just a few minutes.
A health and beauty blog offering helpful tips from the pharmacists and beauty experts at New York City’s world famous C.O. Bigelow – The Oldest Apothecary in America. Since 1838.
Luminis is a minimal, responsive photography WordPress theme perfect for wedding photographers, travel photos, fashion photos, portraits, photo studio, photography agency, designers, artists, bloggers to showcase their portfolio.
NETFOX is a company providing goods and services for retail and wholesale customers in the E-Commerce market.
The future is back – new Website out now including WebVR, Chatbot, WebGL – you name it!
Design agency focused on solving user experience and interface challenges for large and small enterprises.
).
Do you want to reach more customers and prospects using Facebook Messenger? Have you tried Messenger ads? Messenger ads display inside the Messenger app on the home tab, increasing the likelihood people will interact with your business. In this article, you’ll discover how to set up a Messenger ad. What Are Messenger Home Ads? Unlike [...]
This post How to Set Up Facebook Messenger Ads first appeared on .
- Your Guide to the Social Media Jungle
Twig is a template engine for PHP. But isn't PHP itself a template engine?
Yes and no!
Even though PHP started as a template engine, it didn't evolve like one, and while we can still use it as one please tell me which version of "Hello world" you prefer:
<?php echo "<p> Hello " . $name . "</p>"; ?>
or
<p> Hello </p>
PHP is a verbose language, and that verbosity is amplified when trying to output HTML content.
Modern template systems will take away some of that verbosity and still add a fair share of functionality on top. Things like security and debug features are mainstays in modern template engines.
Today, we're focusing on Twig.
Twig is a template engine created by Sensio labs, the company behind Blackfire and Symfony. Let's take a look at its main strengths and how can we use it in our projects.
There are two ways of installing Twig. We can use the tar ball available on their website, or we can use Composer, just like we always do and recommend.
composer require twig/twig
We're assuming you're running an environment with PHP set up and Composer globally installed. Your best bet is using Homestead Improved - it'll let you get started in 5 minutes on the exact same machine we're using, so we're all on the same page. If you'd like to learn more about PHP Environments, we have an excellent premium book about that available for purchase here.
Before we go any further, there's something we need to clarify first.
As a template engine, Twig operates both on the front and on the back end of a project. Because of that, we can look at Twig in two different ways: Twig for template designers and Twig for developers.
On one side, we prepare all data we need. On the other side, we render all that data.
To exemplify the basic usage of Twig, let's create a simple project. First of all, we need to bootstrap Twig. Let's create a bootstrap.php file with the following content:
<?php
// Load our autoloader
require_once __DIR__.'/vendor/autoload.php';
// Specify our Twig templates location
$loader = new Twig_Loader_Filesystem(__DIR__.'/templates');
// Instantiate our Twig
$twig = new Twig_Environment($loader);
Twig uses a central object called Environment. Instances of this class are used to store the configuration, extensions, and to load templates from the file system or other locations.
With our Twig instance bootstrapped, we can go on and create an index.php file where we will load some data and pass it to a Twig template.
<?php
require_once __DIR__.'/bootstrap.php';
// Create a product list
$products = [
[
'name' => 'Notebook',
'description' => 'Core i7',
'value' => 800.00,
'date_register' => '2017-06-22',
],
[
'name' => 'Mouse',
'description' => 'Razer',
'value' => 125.00,
'date_register' => '2017-10-25',
],
[
'name' => 'Keyboard',
'description' => 'Mechanical Keyboard',
'value' => 250.00,
'date_register' => '2017-06-23',
],
];
// Render our view
echo $twig->render('index.html', ['products' => $products] );
This is a simple example; we are creating an array of products that we can use in our template. Then, we use the render() method which accepts a template name (this is a file inside the template folder that we defined earlier) and the data that we want to pass to the template.
To complete our example, let's go inside our /templates folder and create an index.html file. First, let's take a look at the template itself.
<!DOCTYPE html>
<html lang="pt-BR">
<head>
<meta charset="UTF-8">
<title>Twig Example</title>
</head>
<body>
<table border="1" style="width: 80%;">
<thead>
<tr>
<td>Product</td>
<td>Description</td>
<td>Value</td>
<td>Date</td>
</tr>
</thead>
<tbody>
</tbody>
</table>
</body>
</html>
Opening index.php in the browser (by visiting localhost or homestead.app, depending on how you've set up your hosts and server) should produce the following screen now:
But let's go back and take a closer look at our template code.
Continue reading %Twig – the Most Popular Stand-Alone PHP Template Engine%
SheetJS js-xlsx is a parser and writer for various spreadsheet formats. Pure-JS cleanroom implementation from official specifications, related documents, and test files. This is the community version.
