Austin Web Development & Database Consulting

If you’re a Google Chrome user you may have encountered a bug where the browser window gets stuck in full screen mode.  In such cases, hitting F-11, or clicking the Exit Full Screen link does nothing.

After searching for fixes, many of which were ineffective, the only fix I found to work was deleting my user preference directory.  If you’re a Linux user, here’s how:

First, go to the google-chrome directory in your home path:

 cd ~/.config/google-chrome

Next, verify you have a Default directory.  Rename it as a backup resource, just in case you need it.

 mv Default/ Default_backup/

Then restart Chrome.  You should see that a new Default directory is created.  You should also notice Chrome starts normally and is no longer stuck in full screen.  The only drawback here is that your preferences are trashed, but most will find that more than acceptable since Chrome is now usable again.

Several months back we made the decision to merge TimePanel’s blog into our company’s blog here at solutionfactor.net.  Fortunately it was a breeze thanks to native support within WordPress to do so. Here’s how we did it; hopefully this saves readers some time if they’re looking to do something similar.

Step 1:  Backups

Backups are always a good idea, especially in cases like this where data will go through changes that you may want to revert, either due to unexpected error, or just b/c you change your mind at some point.

You can backup both site’s files easily using cp to copy files to a backup directory:

sudo cp -r blog_1_directory/ blog_1_backup/
sudo cp -r blog_2_directory/ blog_2_backup/

 … and for the databases, a vanilla mysqldump handles the job:

sudo mysqldump -u -p blog_1_database > blog_1_database.sql
sudo mysqldump -u -p blog_2_database > blog_2_database.sql

Step 2:  Export The Source Blog

Next up is exporting the source blog.  By source blog, I mean the blog you’re exporting data from.  By contrast, I’ll refer to the target blog (later) as the blog you want to import data into.

Log into the source blog and go to Tools > Export. From there, select to export All content (it’s probably selected by default), then click Download Export File.

WordPress Export Blog Page

Step 3:  Import Into The Target Blog

With the source data exported, next up is to import the data into the target blog.  To do so, log into the target blog and go to Settings > Import.

From there, you’ll see an option to install an import tool; select the WordPress tool at the bottom of the list.

Once installed, run it.   You’ll see an option to create a new author for the imported posts, or assign to an existing author. In our case, we chose the latter, but choose the option that best suits you.

And that should be it.  Once the import tool completes, you should see all your blog posts on the new blog.

Step 4:  301 Redirects

If you’re planning on removing the old blog posts once they’ve been imported into the target site, you’ll want to add 301 redirects to inform search engines the content has moved.  Otherwise, the old content will produce 404 errors once it’s gone, which can lead to SEO penalties.

Fortunately it’s an easy change to make.  You can add the following redirect to your vhost or .htaccess file:

redirect 301 [old blog url] [new blog url]

In our case, that translated to the following:

redirect 301 /blog http://solutionfactor.net/blog/

Just a heads up that if you’re submitting data via FormData with XHR2, you’ll need to ensure the proper Content-type header is set, otherwise request data won’t be sent properly. In my case, an incorrect Content-type header resulted in only sending FormData’s first attribute with the request.

Here’s some detail.

This was the form in question; Signal’s login form code, note the email and password fields:

Login form markup

Straightforward enough. But here’s what an XHR2 request looked like in Chrome’s Dev Tools:

XHR2 request, only sending the form’s first element value.

Note that only the email value is being sent. Something is off.

Turns out the Content-type request header was set incorrectly. As shown above, it was set to application-x-www-form-urlencoded. Obviously that Content-type is incorrect given that we’re no longer sending request data via an encoded url, but rather as form data.

I had left the incorrect urlencoded header value in by acccident, but after removing it, all values from the login form are now sent as expected:

XHR2 after Content-type request header fix.

Hope this saves someone some time.

Since we had a client ask about the effort involved to setup automated testing in their product, and because I mentioned it before in a LAMP Best Practices post, we thought it’d be a great idea to share how easy it is to get PHPUnit going in a new project.

Prerequistes

Our unit testing framework of choice is PHPUnit.  So before we get started, we’ll need to get that installed.  At Solution Factor we all develop on Linux Mint, so installing it from the repo is simple (note: the following commands only apply to Debian based distributions).

To install PHPUnit, run:
[code lang=”bash”]sudo pear install phpunit/PHPUnit[/code]

Next, a CodeCoverage library may be needed; unfortunately it’s left out of some PHPUnit packages.  To install it, we just ran the following:

sudo pear channel-discover pear.symfony-project.com
sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover components.ez.no
sudo pear install phpunit/PHP_CodeCoverage

With that, our PHPUnit install is complete. Now we’re ready to start adding PHPUnit to our project.

Directory And File Setup

To get PHPUnit setup, we started by creating a tests directory.  This can be created anywhere in a project, so long as it’s outside the document root (for security purposes).   The tests directory will house everything test related, and within it we created 3 things:

1. a phpunit.xml file – the config file for phpunit
2. classes/baseTest.php – will house a simple test to confirm PHPUnit is working
3. bootstrap.php – to allow PHPUnit to bootstrap into our project

Here’s what the basic file and directory setup looks like in my dev environment:

PHPUnit file structure

PHPUnit File Modifications

With the file and directory structure setup, it’s time to inform PHPUnit about our test suite, and provide it with tests to run.

First up is the phpunit.xml file.   This is PHPUnit’s config file and tells it where tests and any bootstrap files are. Here’s the content we added, note the Bootstrap and test suite settings:

<!--?xml version="1.0" encoding="UTF-8"?-->

./

Next we added a simple test case to classes/baseTest.php file.  The test isn’t meaningful, it only serves as a way to confirm PHPUnit is running properly.  Here’s the file content:

<?php

class BaseTest extends PHPUnit_Framework_TestCase
{
    public function testBase()
    {
        $this->assertTrue(true);
        $this->assertEquals(1, 1);
    }
}

And that completes the setup. To confirm PHPUnit runs fine, cd to the tests directory and run phpunit.  We initially got a bunch of HTML output, and you may too, but at the very bottom PHPUnit did give the following confirmation:  OK (1 test, 2 assertions).

So if you see that, phpunit is working.

The Bootstrap File, And Getting Rid Of HTML Output

We didn’t mention the Bootstrap file much, but we did just mention some unneeded HTML output.  Both are related.

The Bootstrap file for PHPUnit serves a similar purpose as it would for other frameworks (i.e. most common MVC frameworks):  it helps PHPUnit initialize and load any config or libraries needed to run tests properly.  For example, you should aim to provide PHPUnit with the same config parameters that your app has, for things like database connections, path information, etc. An example of how we utilized a bootstrap.php file with teh Kohana framework can be found here: PHPUnit into Kohana.

Fortunately in our case little was needed in bootstrap.php. All we added was one line of code to load the config file for the app we’re testing:

<?php
require('../app/config/config.php');
?>

With that, PHPUnit then had access to the same config parameters our app does. Without loading the app’s config in bootstrap.php, we’d have to redefine the same config values somehow for PHPUnit; the bootstrap.php file allows you to avoid having to do that in a redundant way.

For your app, expect that bootstrap.php will serve a similar purpose, but obviously will contain different code than what we added.

Conclusion

We believe every LAMP project should integrate automated testing. As shown here, it’s easy to get that started. Once setup, reaping the benefits of automated testing is only a matter of adding tests as the code base progresses. And, once matured, the test suite is a great way to gain confidence that new features, bug fixes, or other changes are stable as they move upstream to production.

Keeping our products fast will always be one of our primary goals.  We love fast apps, and keep a lookout for ways to make them even faster.  That goes for initial load times as well as usage while inside the app.

Unfortunately JavaScript heavy apps fight against that goal.  For example, as additional features make their way into TimePanel, the amount of JavaScript we have to send across the network increases.  Caching helps, but has its own limits.  For example, the first time a user logs into TimePanel, they’re served the app’s CSS and JavaScript due to a cold cache.  Additionally, anytime we deploy updates, TimePanel’s CSS and JavaScript version numbers are bumped, forcing new versions to be loaded when a user logs in.  Those are two scenarios where caching doesn’t help and load times are increased.

Normally those kinds of circumstances may not be that bad, but since TimePanel’s JavaScript contain the entire app, its size introduces extra load time that users have to sit through.  That JavaScripts lock the browser’s UI thread until they’re downloaded and parsed compounds the matter.

Due to those problems, and how much we value speed, we sought out a way to minimize load times.  Enter HTML 5’s async script attribute coupled with a simple preloading technique.

JavaScript, HTML 5 Async, and Preloading

To give a brief background, there’s one main reason why JavaScripts, and their size, are problematic.  They block the browser’s UI thread, meaning that until a JavaScript is downloaded and parsed, nothing else happens in the browser.  That means a user could see nothing happening for some moment of time, perhaps even seconds, if a given JavaScript is big enough, or network latency is high enough.  This is why it’s always a good idea to keep JavaScript small, and if possible, serve them from a fast CDN (a CDN will typically provide better geolocation, speeding up file delivery to the user).

Another way to combat that is to leverage HTML 5’s async script attribute, and preloading.

HTML 5 introduced the async script attribute to mitigate the negative affects we just described related to JavaScript files.  With the async script attribute, developers have a way to declare that a script be loaded asynchronously so as to not block UI rendering or subsequent file downloads.  This provides a huge step forward toward maintaining a fast user experience while JavaScript files download to the user’s browser.

Additionally, preloading scripts is another way to achieve that.  By selectively inserting script tags in a non-interfering way before they’re needed, a user can transparently download and parse a JavaScript file, or other asset, behind the scenes.  This doesn’t speed up file loading per se, rather it off loads it in a way that’s transparent for the user.  This provides a perceived speed increase, and is exactly the kind of change we just deployed to help TimePanel load faster.

The Changes, and Before/After Results

The opportunity we saw was to load TimePanel’s CSS and JavaScript on the login page.  Since we didn’t want to just move the script load time from post-login to pre-login, we added the async script attribute to the CSS and JavaScript script tags.

Edit:  Thanks to Silvenga for correcting my use of the async attribute for CSS.  He correctly noted that async attributes only apply to script nodes, not link nodes.  I’ve since edited my post above to strike-through CSS references, and updated the following screen shot.

Async attribute added to JavaScript file.

That keeps the login page rendering practically unaffected.  The JavaScript file downloads asynchronously while the user views the login page, or while entering their credentials.  Then, after the user logs in those files are reloaded, but this time via browser cache, resulting in a decrease in TimePanel’s load time, post-login.

Again, the download times of TimePanel’s JS using async on the login page isn’t faster than if it were downloaded otherwise.  But, since we’re doing it behind the scenes while the user is logging in it increases perceived performance of the app after login by being able to serve TimePanel’s JS from the browser cache instead of over the network.

And the results are noticeable.  Before and after results, taken from Chrome’s network waterfall, show the onload time went from 926ms to 646ms, a decrease of 283ms!

Before async and preloading – 926ms onload.

After async and preloading – 646ms onload.

Conclusion

Speed is important, and HTML 5 and other modern techniques offer opportunities to speed up modern applications, despite growing feature sets and file sizes.

If JavaScript, or other performance-sensitive assets, are getting in the way of load times, consider applying the async script attribute to keep the user’s browser UI from locking up.  Also consider preloading scripts when possible to have scripts loaded and at the ready by the time user’s need them, without making the script’s download and parse time noticeable to the user.