Webmastersite.net

Search    Register    Log In   


By on Nov 24, 2018 at 7:19 AM

Turns out Geocodio only supports USA and Canada, and for some reason they don't bother to mention that anywhere prominent. So I had to quickly do more research and found that OpenCage appears the best worldwide geocoding option, with a permissive TOS. OpenCage's data is "interpolated" rather than "rooftop" level accuracy, meaning the pin should be close enough to see your destination but not necessarily exactly precise, so Geocodio is better for USA/Canada addresses. I've set up WSN so that (if all the API keys have been entered) it uses Geocodio on addresses that contain "United States" or "Canada" but uses OpenCage for all other countries. If you still want to use the google maps geocoder even though it breaks the TOS, WSN will fall back to that if you have no other API keys entered.

Today's project is for WSN Links. As you've no doubt noticed, link rot is a big problem these days -- websites are coming and going all the time, and reorganizing their URLs without leaving redirects too. WSN's dead link checker and content checker help you catch these, but just having to delete stuff all the time isn't ideal. Thus, I'm adding an option to convert the listings found dead into archive.org wayback machine links. The wayback machine, as you probably know, keeps an incomplete but extensive archive of historical webpages.

Now, there's a couple ways to do that. One way is to just request the latest archived version of the URL -- simple. But what if the website has changed or might eventually change into a spammy page full of viagra links? Archive.org would happily archive the spammy page and serve it up. So I think it's better to instead request a version of the page from a specific time in the past when we know the site was good. The date on which the link was submitted to your site makes the most sense to me. So, when you tell WSN to convert a link to the wayback machine version, it will automatically request the version from the date of the link submission. Archive.org...

Read Full Blog Entry


By on Nov 21, 2018 at 10:48 AM

Discovered today that thumbshots.com died on November 10th. Obituary at www.thumbshots.com/Support/...3/EntryID/47/Default.aspxa
Odd spammy text at the bottom of the page makes it look like they've either gone insane or been hacked too.

Some of you have been using thumbshots.com thumbshots in WSN. It used to be the default, but for the past few years pagepeeker has been the default with thumbshots.com available via the thumbshotskey tweak. With today's WSN releases, I've retired the thumbshotskey tweak and switched all sites to pagepeeker.


By on Nov 20, 2018 at 9:51 PM (Edited Nov 20, 2018 at 9:54 PM)

Structured data markup is basically another way of helping search engines understand your site. It describes pages in terms of objects or concepts and how they relate to each other. For a news article for example, it tells what the headline is, the description, the images, and the author details.

A couple years ago, I spent a lot of time marking up the WSN templates with schema.org structured data markup. It made a bit of a mess out of the HTML and was easy to end up with an incomplete version of, but it conveyed the basic info. As soon as that was done, of course, everybody changed their minds and decided that's no good and everybody should use a different markup method. At this point, JSON-LD seems to be the winner. Unlike the old method, JSON-LD lives in the header of the page and isn't mixed into the content semantically.

A few months back I added a Structured Data Schema template to WSN Links in order to enable JSON-LD. Basically what this needed to be was a subtemplate that gets auto-included in the <head> section and uses conditionals to decide what JSON to show. At that time, I added some markup for the contact form page... and left a space for the details page but didn't fill it in.

The listing details page is of course the most useful place for structured data markup. It's also very hard for me to fill out on your behalf when I can't know what exactly you're doing with an installation. Nonetheless, I've come back to that today for a try.

So far, I've set up an article schema for WSN KB article details pages. In the course of doing this, I discovered a few things. First, the schema is really insistint about wanting images -- it won't validate and is considered invalid markup if you don't provide it with both an article image and a publisher website logo. For article images I've added {LINKSTRUCTUREDIMAGELIST} to provide a list of thumbnail URLs if there are any images attached to the article... and an utterly pointless small transparent PNG...

Read Full Blog Entry


By on Nov 19, 2018 at 10:48 PM

A few months ago, Google Maps drastically lowered their free use allowance. The vast majority of us are, alas, still in no danger of having any websites popular enough to hit the limit. For a customer who was hitting the limit, I added a "click to load map" option in WSN to reduce their number of maps impressions. That, of course, is a far from ideal solution. What we really need is an alterative mapping service.

I thought about Bing, but they have limits of their own and may put a tighter squeeze on people at any time. So I settled on investigating Open Street Map, under the theory that OSM being non-commercial should mean we can count on it being scalable and not trying to charge people. Quickly I discovered that OSM isn't so much a mapping service as a toolkit which can be used to start making a mapping service. To do anything but a simple static tile gets complex quickly and people turn to third party tools to help implement OSM.

For the basic task of putting markers on a map with info windows, I've found Open Layers is pretty good. A few more idiosyncracies than Google Maps, but close enough. Driving directions seem to require another third party service, unfortunately. Nor do I have an overlapping marker spiderifier type of tool for OSM. Nor do the min/max zoom tweaks or lots of other things work at the moment with OSM. Nor does it support multiple maps on a page yet, nor ajax progressive marker loading, nor location dragging on submit/edit which has proved a particular pain. It'll be a long slog to get close to feature parity with google maps, but at least the basics are working.

This brought me to another look at geocoding services. OpenLayers, alas, does not include their own geocoder. Considering Google Maps has a rather low geocoding limit that one can quickly hit by regenerating a decent sized directory, finding a good geocoder is definitely a top priority. The problem I'm running into with every one I look at is the same: their terms of service. Map...

Read Full Blog Entry


By on Nov 18, 2018 at 2:34 AM

In WSN 10.2, I spent a lot of time on WordPress integration. Perfected the theme integration, and made a WordPress plugin for each WSN script that installs and integrates and manages it and provides access to the WSN admin from WordPress. While starting work on 10.3, I realized WSN was actually integrating more fully with WordPress than with other WSNs. Time to fix that.

The first step was to take the previously hacky template integration and turn it into something standard and reliable. Instead of editing the integration file for template integration, you're now asked how much you'd like to integrate at the time of integration in the admin. Most templates including wrapper will be the best option for most, but I've retained the option to not integrate the wrapper for those who find conditionals confusing, and to not integrate anything but the style or not even the style for those with special needs.

This brought me to the issue of making sure people don't get confused when editing integrated templates. I added warning text which explains that changes will be applied to multiple scripts and describes how to use conditionals to distinguish the scripts. To achieve that, it was necessary to make host scripts aware of scripts integrating with them (which they previously were not). This seemed a good time to also make client scripts aware of their siblings and make a convenient admin menu for switching between all the tied-togeather scripts.

Once that was done, I added a script installer menu option. The installer makes it easy to add another script without having to enter any database info, it just puts it in the same database as the current script with an automatically-calculated table prefix. It then integrates members and themes for you. It always installs the free version so if you have licenses of other scripts you'll need to enter those logins after the install. I'm pondering the next steps for the installer, which may include copying tweaks or a subset of set...

Read Full Blog Entry

<< March 2019 >>
SunMonTueWedThuFriSat
12
3456789
10111213141516
17181920212223
24252627282930
31

Recent Comments