Using Jetpack Blocks without a connection to WordPress.com

Recently I wanted to use a Jetpack block for the WordPress Gutenberg editor, specifically the Slideshow Block, which I think is very slim and elegant compared to other Slideshow blocks on the WordPress.org plugin directory.

The one thing I didn’t want to do, though, is to connect my site to WordPress.com. For the most part because I didn’t intend to use any of the functionality that requires the WordPress.com connection.

The difficulty in this: normally, you can’t actually use Jetpack until you connect the site to your WordPress.com account. This behavior is in place so you can enjoy a friction-less experience after the connection is established (i.e. you can activate any of its features whether or not it needs the connection).

In my case, the connection is not needed for using the Slideshow block since it works with the local media library.

So, I present not a hack but an official way to use Jetpack without a WordPress.com connection: it’s called Offline Mode.

You activate it by adding a constant or filter to your wp-config.php, for example:

define( 'JETPACK_DEV_DEBUG', true );

While it is intended for local installs and actually development, it is useful if you just want to use a single feature of Jetpack that doesn’t require the connection.

Many people say that Jetpack is slow because it’s so big. It is indeed huge from a file size and feature perspective, but also it’s very optimized, so that it will only load the PHP or JS code it needs. The other files lay dormant in your file system and don’t contribute to the loading or rendering time of your site.

SSL Certificate Expiry Warning Script

With the increasing trend of SSL on the web, where Google values SSL sites higher and you can have your site be added to the HSTS preload list (the browser will first try HTTPS before trying HTTP), it is a good idea to start using SSL yourself.

The downside: you need to get a certificate through a (pre-trusted by the browser) CA, or certificate authority. This usually costs money, though there are some services that give you a certificate for free. The free certificates only last for one year or less, this means you need to request and install a new certificate frequently, especially when you have multiple domains.

Now it can happen to anyone, even Microsoft (Windows Azure Service Disruption from Expired Certificate), that you forget to renew (and update) your certificate in time.

There is a nice service called certalert.me (interestingly enough not over HTTPS) that will send you an e-mail when a certificate is due to be updated. But as with any web service, unfortunately you can never be sure how long it’s going to live.

So, I have created a script that I run through a cronjob every day that will send me a notification e-mail several times in advance (1 day and 2 7 14 30 60 days ahead), so that you are not dependent on a third party to get notified about expiries. As it is supposed to be with cronjobs, there is no output when there is nothing to report (thus no e-mail).

Here is the script (download warn_about_certificate_expiry.sh):


#!/bin/sh 

CertExpiries=$(mktemp)
for i in /etc/certificates/*.pem; do
	echo $(basename $i): $(openssl x509 -in $i -inform PEM -text -noout -enddate | grep "Not After" | tail -1 | awk '{print $4, $5, $7}') >> $CertExpiries
done

Date=$(date -ud "+1 day" | awk '{print $2, $3, $6}')
Expiries=$(grep "$Date" $CertExpiries)
if [ $? -eq 0 ]; then 
	echo These Certificates expire TOMORROW!
	echo $Expiries
	echo
fi
for i in 2 7 14 30 60; do
	Date=$(date -ud "+$i day" | awk '{print $2, $3, $6}')
	Expiries=$(grep "$Date" $CertExpiries)
	if [ $? -eq 0 ]; then 
		echo These Certificates expire in $i days:
		echo $Expiries
		echo
	fi
done
rm $CertExpiries;