Transparency Report – March 2020

This is the 12th monthly report for Print My Blog WordPress plugin.

What Happened in This Month

Overview of What’s New

• Put Post’s Title in Single-Post PDF Filenames
• Avada Lazy-Loading Compatibility
• Fixed Overly-Eager Javascript Loading
• Fixed PHP 5.2 and 5.3 Fatal Errors
• Conveying Vision for Print My Blog Pro

The Details

Put Post’s Title in Single-Post PDF Filenames

User JSin remarked that PDFs created using the Print Buttons all had the same filename (the site’s title), which was annoying for folks who created PDFs from individual posts, and sometimes meant they would accidentally overwrite them.

Version 2.3.5 addressed that by adding the current post’s name onto the filename (by adding it to the HTML page’s title attribute, if you want to know).

Avada Lazy-Loading Compatibility

GitHub user uwefunk reported a few issues using Avada and Print My Blog. We worked through a few small issues (like the print button not looking clickable in his theme, and being left-aligned instead of centered), but the biggest issue I managed to fix (in 2.3.3) was lazy-loading.

Avada, like many other themes and plugins, avoids actually loading images until you scroll down the page and they come into view. That can be annoying with Print My Blog because that’s sometimes a lot of scrolling. Or, the images might not appear at all because they need some Javascript to trigger loading them and that doesn’t get executed on the Print Page.

The fix ended up simply being I forced loading the images myself: I just looked for the HTML that says where the image will be fetched from, and get force the images to fetch it as soon as the print-page is ready (for the technically inclined, I just looked for all the img tags with an attribute called data-orig-src and stuffed into into the src attribute, then the browser takes care of loading the image.)

Fixed Overly-Eager Javascript Loading

Last month I remarked how Print My Blog’s Gutenberg block Javascript was unnecessarily getting loaded everywhere. I had a quickfix that prevented it from doing anything, but this month, in version 2.3.6, I managed to actually prevent it from being loaded at all. It might only save y’all a few kilobytes, but it feels good to be thrifty.

Fixed PHP 5.2 and 5.3 Fatal Errors

My friend Jason Liversidge also pointed out to me that he had an error using Print My Blog on an older site he owned using PHP 5.2. It turned out Print My Blog gave a fatal error (and so wouldn’t activate) on sites running PHP 5.2 and 5.3.

I didn’t realize that earlier because I’ve had difficulty setting up a local site that uses those older versions of PHP (which is part of why I made Print My Blog in the first place: because it gets hard to read old data using new software, and sometimes getting just the right blend of old software is also difficult.)

Anyways, I managed to fix the problem, so now users of PHP 5.2 and 5.3 are nicely told Print my Blog’s minimum PHP version is 5.4, instead of getting a rude fatal error.

The fix was this: in order for your code to work with older versions of PHP, your new-style code needs to not not execute, but it needs to not even be parsed. E.g., this code snippet only executes the new-style code if you’re on PHP 5.4 or higher…

if(version_compare(PHP_VERSION, '5.4.0, '>')){
    $new_style_class = \My\Great\PHP54Style\Class();
}

…BUT, it will still have a fatal error when being interpreted by PHP 5.3 or lower. Why? Because even though PHP doesn’t execute that new-style code, it still parses it. And that’s where PHP 5.3 parses that, it says “woah! I don’t understand that! It must be wrong.” and has a fatal error.

So, I just made sure my plugin’s main file was completely 5.2-compatible. And if it detected PHP 5.4+, it would then include the other files that needed PHP 5.4; otherwise, it wouldn’t load them.

Vision for Print My Blog Pro

I made two posts this month that describe a bit of my vision for Print My Blog Pro: Why Print My Blog? and Why Am I Making a Pro Version of Print My Blog?. The gist is this: let you write documents (print books, eBooks, research papers, essays, menus, etc) and blog posts at the same time, in WordPress, and stop messing around with copy-and-pasting between other programs and WordPress.

So far I haven’t really gotten any feedback on that vision. I’m not sure if it’s obvious, or obtuse. So feedback either way would be helpful.

Thinking Out Loud

Lull in Growth

It appears from the active install growth for March that progress nearly stopped. That coincided with a bout of Hand, Foot, and Mouth Disease running through our house (thankfully I had it the worst, but I didn’t have much energy for improving Print My Blog), followed by the sudden societal breakdown from Coronavirus (and I’ve been really busy trying to get my wife’s online school adapted to 100% distance learning.)

So really, I think I can see the cause: I wasn’t as focused on marketing and improving Print My Blog in March and much of February, too. There have been quite a few features requested lately which I haven’t been able to add because I’m trying to get the Pro version off the ground.

Although, progress was actually still pretty steady: according to my calculations, there were about 120 new active installs in March, putting it about on track with the average growth for about the last year (it looks like less because it’s smaller compared to current user base.)

Discovered HTTrack

While trying to help out my e-friend Don McLean get a usable copy of his blog (he hasn’t been super satisfied with Print My Blog’s layout, and isn’t in much of position to be testing out the Pro version which is only in the experimental stages) he asked if there were a simple way to just download his website onto a CD. So, I did some research.

I found an open-source, free program called HTTrack that will crawl a website, download all its pages, download its images and videos and basically everything, and update all the links to point to the locally downloaded files, thus making a local, static website that’s 100% self-contained (meaning if the real website goes down, or you’re offline, your local copy will totally still work.)

I think HTTrack won’t work too well if your website has dynamic content (like content that loads later using JavaScript, or lazy-loading images like I mentioned earlier.) It also might not work too well with future browsers, as they’re continually changing. But the simpler the website the more likely it is to work well.

For people planning on shutting down their website, I think running HTTrack, in addition to Print My Blog or something similar, is a good idea.

Cashing Out from Open Collective

Last month I mentioned how Open Collective wouldn’t let me cash out any of the donations unless I filled out a tax form, and my accountant couldn’t figure it out. Well, I figured out a workaround: just don’t bill for as much. Open Collective requires more tax information if I recorded more than $600 in expenses, and as you can see in my Business Stats, I’ve recorded thousands in expenses… but donations through Open Collective only summed to a bit over $100. So I cancelled most of the expenses I had recorded, so the amount equaled the donations (much less than the $600 threshold), which removed Open Collective’s requirement for additional tax information, and was then able to cash it out from Open Collective.😀

So that was good. But I’m still discontinuing use of Open Collective. A $600 limit for the year is a bit low considering the opportunity cost. For now, donations are still accepted via PayPal (thanks Don for the $50 Canadian this month), until I get Print My Blog Pro setup with Freemius.

Cry for Comments

I’m not sure how many folks read all the way to the end. If you did, please add a comment with your favourite emoji (or a useful comment would be accepted too). Thanks!