Search    Register    Log In   

By 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 script...

Read Full Blog Entry

By 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 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 with...

Read Full Blog Entry

By on Jan 17, 2019 at 3:57 AM

A month or so ago, I made a change to how the children of categories with special rewrite URLs set work. Previously, the children didn't take into account their parent's special URL -- since then, the children have automatically used their parent's special URL in calculating their ancestry path part of the URL. For example, if a category named "One, Two" has the special URL https://site.com/onetwo/ then a child URL is now https://site.com/onetwo/child/ whereas previously it would've becoming a numeric category URL due to the special character (comma) in the parent category name.

Turns out this had an unwanted effect in a certain situation. Someone was giving some of their top level categories special URLs of the form something.html, which resulted in subcategories being somethinghtml/child/, but they wanted the subcategories to be something/child/. To work around this, I just put in an exemption so that special URLs that contain .html are not considered by their children.

The major new feature in today's release is the zoom level constraints options on the maps settings page. Most of these options were previously available as tweaks, but the tweaks were incomplete and failed to explain the meanings of the zoom level numbers. You can restrict the range the auto-calculated starting zoom value will fall within, and you can also restrict the range the user can manually zoom to. Also elevated the coloredpins tweak to a setting. And elsewhere on the maps settings page, added some javascript to automatically hide options not available to OSM when using OSM instead of Google Maps.... btw it should be easy enough to make the zoom constraints and colored pins work with OSM if anyone lets me know that they're using OSM and would like those options.

In other news, I've finally redesigned the offers system to be fully mobile-friendly on the submit/edit page. This will not overwrite your current offers input html, only applies to new installs. I need to start thinking of a way t...

Read Full Blog Entry

By on Jan 09, 2019 at 11:07 PM

10.3.31 contains a few more speed improvements, less drastic. It also fixes three little bugs:

When using the horizontal admin menu with a non-bootstrap front end theme, the menus weren't working because it wasn't including the bootstrap javascript. Important fix since it left people unable to navigate their admin after they install a new theme or change menu type in certain ways.

In the guided start, the settings page suddenly shrunk to a smaller size halfway down. Fixed the missing closing tag that was causing that.

In the listing bit, the conditional that checks whether the viewer has permission to email the listing was mistakenly <IF {THISHASPERMISSION[canemail]}>. I've corrected that to <IF {THISMEMBERHASPERMISSION[canemail]}>. Now the email link only appears in appropriate contexts, and this fix also speeds pages a bit because it removes the unparsed template variable. I discovered this problem when I was working on optimizing settingsreplacements and saw it was trying to process {THISHASPERMISSION as a potential setting. I've made this fix apply automatically to modified templates, since it's simple enough to do so, so you won't need to edit your customized listing bits.
<< January 2019 >>

Recent Comments