Yii 1, PHP 7.1, yii-pdf and Mpdf

Mpdf 6.x only supports PHP versions up to 7.0. If you’re upgrading your local machine, or hosting environment to PHP 7.1 or beyond (you should be) then you’ll need to upgrade your Mpdf install to something more recent than 6. That requires a few changes.

Now just to make things complex here, the latest version of Mpdf happens to be version 7.1. From here on I’ll try and prefix any version numbers with either PHP or Mpdf.

Mpdf 7 and greater is composer install only. You could still download and copy the files into place, but I highly recommend using composer to manage your vendor packages in Yii (and Yii 2). It will save you hours and hours over time.

Mpdf 7 has updated it’s class name to be Mpdf with a capital M, and changed it’s construct method to accept a config array instead of separate parameters. Small but significant updates we’ll have to deal with.

If you’re already using composer, then you’ll have a composer.json file in the root of your codebase, and in there you should have a line which starts “mpdf/mpdf”.

That line will probably end something like “^6.0” or “^6.4”

Assuming it’s less than “7.x.x” we’re going to update with composer.

Back up your codebase. I shouldn’t have to mention it, but do it, honest.

Run composer require mpdf/mpdf “^7.0”

That line will install the latest version, Mpdf 7.1, allow anything newer to be installed if you update in the future, and change your composer.json file (and likely your composer.lock file too) to include the newer information.

So we have the latest code, but we need to update Yii to use it.

yii-pdf wraps mpdf and makes it available via Yii->app()->ePdf->mpdf()

The yii-pdf config to get it functioning with Mpdf 7+ will look something like this:

'ePdf' => [
	'class' => 'application.extensions.yii-pdf.EYiiPdf',
	'params' => [
		'mpdf' => [
			'librarySourcePath' => 'vendor.mpdf.mpdf.src.*',
			'constants' => [
				'_MPDF_TEMP_PATH' => Yii::getPathOfAlias('application.runtime'),
			],
			'class'=>'\Mpdf\Mpdf',
			'defaultParams' => [
				'mode' => '',		//  This parameter specifies the mode of the new document.
				'format' => 'A4',	// format A4, A5, ...
			],
		],
	],
],

Note the librarySourcePath and class values. You can add your existing defaultParams and anything else which was in your preferences previously.

The last part is to update all places where you call the mpdf library. Previously it would have looks something like:

$mpdf = Yii::app()->ePdf->mpdf('UTF-8', '', 0, '', 15, 15, 15, 15, 8, 8);

We now convert the config to be an array of values:

$mpdf = Yii::app()->ePdf->mpdf(['UTF-8', '', 0, '', 15, 15, 15, 15, 8, 8]);

And that should be it. Update using composer, update your config, update all locations you instantiate mpdf. Then check your pdf generating code is still functioning.

Security of WHM backups to an AWS S3 bucket

When you give your Web Hosting Manager (WHM) the ability to send a copy of your backup to Amazon’s AWS S3 service, you have to hand it a Key and Secret that give it that permission.

The worst option is to hand over a Secret and Key related to your own log in.

The best is to:

Create a policy which
- Only gives access to a single bucket
- Only allows the least access required for the task
- Only allows connections from trusted IP addresses
Create a Group to connect the policy to
Create a user (for the WHM) to connect to the group

For validation of connection to S3 WHM currently requires the ability to write objects, list all objects in a bucket, delete objects. Now for some this is frustratingly more than you want to hand over. In theory WHM could make do with just the ability to write to the bucket, but at the moment we have to make all those abilities available.

Luckily, the fact we’re also limiting by IP and then Secret and Key—which WHM encrypts when you submit them—should make it highly unlikely anybody else will be able to abuse the ability to delete objects.

Here is the example policy that I have in place. Feel free to copy, personalise and use:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "WHMBackupAccess",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ],
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "YOUR_SERVER_IP/32"
                }
            }
        }    
    ]
}

If you’re in need of help putting this all together, let me know and I might expand this post to include how to do the setup inside WHM and the AWS console.

.htaccess redirects based on date and time

A useful trick for implementing maintenance windows and redirects without having to use a php or similar script is to check date and time in .htaccess files or use it to build a redirect url.

Date and time values in .htaccess come in the form %{TIME_XXXX} where XXXX is the type of date or time you want.

So if you want to redirect a generic url to one which contains today’s date, you might use:
RewriteRule ^posts/today$ /posts/%{TIME_YEAR}-%{TIME_MON}-%{TIME_DAY}

That would result in /posts/today being redirected to something like /posts/2015-08-27

If you wanted redirect a page after a date (and time) is passed you could use something like the following, where if the date and time is passed 9am on 27th August 2015 the redirect will happen. We use a simple number comparison of turning the date into an integer and then comparing it.
RewriteCond %{TIME_YEAR}%{TIME_MON}%{TIME_DAY}%{TIME_HOUR} >2015082709 RewriteRule ^$ /destination/url.html [R=301,L]

The following would only redirect until a specific time (10.22am on 27th August 2015)
RewriteCond %{TIME_YEAR}%{TIME_MON}%{TIME_DAY}%{TIME_HOUR}%{TIME_MIN} <201508271022 RewriteRule ^$ /destination/url.html [R=301,L]

The following would only redirect between two specific dates (20th July 2015 and 27th August 2015)
RewriteCond %{TIME_YEAR}%{TIME_MON}%{TIME_DAY} <20150828 RewriteCond %{TIME_YEAR}%{TIME_MON}%{TIME_DAY} >20150719 RewriteRule ^$ /destination/url.html [R=301,L]

The options you have for %{TIME_XXXX} values are:
TIME_YEAR // current four-digit year TIME_MON // current month TIME_DAY // current day of month TIME_HOUR // current hour (24 hour clock) of day TIME_MIN // current minute of hour TIME_SEC // current second of minute TIME_WDAY // current week-day TIME // a formatted string representing the date and time down to seconds. e.g. 20150827112234

MySQL roughly random string generation for inserting or updating rows

Ever wanted to inject hashes into new or existing rows of a MySQL database?

Two slightly different methods, but the same result…

Insert

The code below allows you to generate a different hash for each row you’re inserting. You can tweak to choose the string’s length. No unique checks are done.

INSERT INTO table_name (
column_name
) VALUES (
    (SUBSTRING(MD5(RAND()) FROM 1 FOR 20))
)

Update columns and values to suit your needs

Update

The code below allows you to generate a different string for each row affected by the update and choose the random string’s length from 1 to 32 character.

I’m aware it’s not the most random of generators but for url hashes etc, it works well. Be sure to then check for duplicates, which are possible!

Change 20 to a length between 1 and 32 that suits your needs.

Update the WHERE condition to suit your needs

UPDATE table_name
SET column_name = (
    SELECT substring(MD5(RAND()), -20)
)
WHERE condition_column = 1;

Chrome browser masking PHP errors

I thought I was going mad for a while, but it turns out that sometimes spotting php error messages which come back from the server to the Google Chrome browser can be really tough.

If the error is inside an html element or attribute of an html element you’re going to struggle to see it in Google Chrome…

<a href="<?= $Model->fakeFunction(); ?>">link</a>

If $Model doesn’t have a method called fakeFunction then php will spit a “Fatal error: Call to a member function” error. The page that is displayed in Chrome won’t show you the error and viewing the source will also hide it from you.

Even the elements tab in Chrome Developer Tools won’t show it.

There only way I’ve been able to find the error content is to look at the network tab in Chrome and view the raw response of the document back from the server.

A few hours lost on this one!