By Paul on Feb 10, 2019 at 6:08 PM

10.4.2 brings some improvements to WSN's link checkers, especially the dead link checker. It now records and displays the time a listing was last found to be down, along with the number of times it has been dead. Should make it easier for you to see whether a link is definitely beyond hope or just experiencing some temporary downtime. There's a new "re-check" option so you can re-check selected links (re-check works for dead, reciprocal and content checks alike).

Also fixed some errors that were displaying when checking a site that has a bad SSL certificate. The bad certificates cause web browsers to advise people not to view the site and generally indicate an abandoned site, so I'm having it count them as dead.

Several other fixes also included. All the fixes will be backported to 10.3, some of them to 10.2.

Still running into some troubles with the new page speed tools on lesser-used internal pages. Hopefully I'll find all of those issues soon, meanwhile it's best to turn off the page speed options if your site is having problems.

By Paul on Jan 31, 2019 at 8:18 AM

I decided to start the 10.4 series today. Continuing the recent development strategy, 10.4.0 is identical to 10.3.36 and they will begin to diverge with 10.4.1. This means we can finally stablize 10.3 so that no new bugs are introduced to it from now on. If you've been running 10.3 with automatic updates turned off, this would be a good time to turn the updates on as they're safer now. If you've been running 10.2 or earier, this is the time to upgrade.

The 15 of you who purchased access to the 10.3 series have been granted free access to the 10.4 series and should have gotten an email to that effect by now. Everyone else remains on 10.2, which is now the legacy series. I'll send an email to those people soon, with a summary of 10.3's advancements.

To those still running 10.1 or earlier, please upgrade to at least 10.2 ASAP because your site will become very buggy and potentially more difficult to upgrade as soon as your web host updates your PHP version to 7.1+ -- which will be soon, since older versions of PHP are being retired and will no longer get security updates.

Currently, the WSN versioning scheme looks a lot like Apple's Mac OS X versioning. In the future, I may switch over to a simpler scheme like Chrome and Firefox where each series is a new major number like 11, 12, etc.

By Paul on Jan 30, 2019 at 1:45 PM

Time to revisit the color-coded map pins option.

First, I thought it'd be a good idea to make google maps use the same marker image as Open Street Map. That way you can customize it (marker.png in your theme images), and more importantly it removes the dependance on google's long-depreciated charts API which was being used to generate the google maps pin images dynamically before -- that API could go dark any day.

The tricky part was to maintain support for the colored map pins option without having to create 10 new images for different colored pins which would be a pain for you to customize. To achieve this for google, I ended up using some tricky CSS. Basically I have it append a color number to the image with marker.png?color=2. Then the CSS img[src="https://www.quietplease.org/attractions/templates/images_blog/marker.png?color=2"] { filter: hue-rotate(60deg); } alters the color of just the ones with ?color=2.

I was hoping this would make it easy to port the colored pins option to OSM. No such luck, somehow the CSS trick doesn't work with OSM. Seems as if the markers aren't actually img tags in the DOM for OSM. Who knows what they are? Chrome's element inspector should know and it says it's an <image> tag with a weird xlink:href attribute containing the url. But image[xlink:href="https://www.quietplease.org/attractions/templates/images_blog/marker.png?color=3"] { filter: hue-rotate(120deg); } didn't work. A search result suggested escaping the colon, but that didn't work either. Even using the image tag's id didn't help, so there must be something mysteriously keeping it from acting as part of the page DOM.

Eventually, after reading novel upon novel of documentation, I realized the only way to get this done before I die of old age is to use something much like the google chart image-generating API. Rather than use the depreciated one, I've built a new one into WSN that uses your marker.png and applies color changes via gd/imagemagick in a s...

Read Full Blog Entry

By Paul on Jan 29, 2019 at 3:56 AM

Today's release has two major sets of new features. First, there's a suite of page speed tools on a new page speed settings page. Most of these tools were discussed in the last blog entry. I've been able to boost one of my WSN installations a 97/100 speed ranking on the google mobile site speed test with these page speed tools, with no significant adverse effects. Of course, they make it a pain to edit things so they ship off by default and should only be enabled when your site goes live and you're no longer changing it regularly.

There's also a new file browser tool. This is similar to cpanel's file manager, but simpler. It allows you to do some basic file editing / deleting / uploading without FTP. While it does make things easier for a hacker who has access to your admin account, a hacker who has access to your admin account already essentially controls your server -- so be sure to use a strong password, limit the admin permissions of other admins you can't be sure will use strong passwords to only areas they need, and consider IP restrictions.

I've also fixed an issue with some old version upgrades that was causing youtube embeds to have mixed content errors on https sites (this wasn't affecting most https sites, just those who originally installed certain old versions). Also noticed recently that the BB codes and smilies links in the comment message composition help were being blocked by chrome's popup blocker, so I changed them to open in full new pages... which also has the advantage of working on mobile, though it's not pretty.

Finally, I discovered that when WSN tries to download a remote web page (for whatever purpose) it was failing on gzip-compressed pages in some circumstances. I changed the curl code to handle gzip compression to fix this.

By Paul on Jan 23, 2019 at 2:20 AM

WSN has some page speed tools -- html minification, javascript minification, css minification -- but these tools are limited. While they combine many files into one, they don't combine every possible css/js file into one. While they handle most of the styles/scripts on most pages, they don't automatically handle every obscure page. And if you've added custom scripts/styles to your website that you found around the internet or wrote yourself, WSN doesn't make any attempt to combine or compress those.

Thus I've been working on a more complete and generalized page speed tool -- although it'll probably be more complex to operate and more prone to failing on unusual unforseen situations. This tool will be able to work in other scripts like wordpress or any php script with slight adjustment. A hook passes it the final output of the page, which it then parses to extract all stylesheet and javascript files. It builds minified caches of each css/js file at a rate of one file per page load, via an 1x1 transparent PNG image worker thread inserted in the page -- grabbing each interpreted URL (normalized for relative urls etc) via cURL/fopen. Once all of the page's css resources have been cached, it then combines them into a single cache file. Same for javascript. Then it replaces the first stylesheet reference in the page with the combined style cache, and the first javascript reference in the page with the combined javascript cache. All other style/javascript inclusions are removed from the page. Then the page HTML is minified for output.

In the process of building this, I discovered that WSN's modifyendoutput plugin doesn't actually modify the very end output -- instead, it modifies just before conditionals processing. Applying HTML minification there would break WSN conditionals, so I've added a new pluggable function modifyultimateoutput that processes at the very end.

Anyway, this page speed script is proving a lot more complex than it initially looked but I think I'm w...

Read Full Blog Entry