Search    Register    Log In   

By on Nov 29, 2018 at 11:07 AM

When you upload a video to WSN and then play it on the listing details page, it plays through a javascript player interface called Flowplayer. Flowplayer is not actually included with the files of WSN, though. Instead, the javascript and CSS is referenced directly from flowplayer.org into your site. Partly this is because WSN is huge enough already, but mostly it's because Flowplayer is licensed under the GPLv3 and it's unclear what the legal implications would be if I distributed it (and I don't have money for a lawyer to find out). When picking WSN components, I normally choose MIT, BSD or LGPL licensed software because I know those licenses don't add any obligations for me to other code which I ship along side it, they only impact their own redistribution rights.

So anyway, normally it's no problem having flowplayer load from flowplayer.org instead of locally. But yesterday someone was having a problem with it because he was trying to play videos on a localhost installation on a computer that has no internet connection. In order to make it possible to use flowplayer without internet, I've added do-it-yourself support for a locally hosted version of flowplayer. All you need to do is save http://releases.flowplayer.org/6.0.3/skin/functional.css to jquery/flowplayerskin.css and save http://releases.flowplayer.org/6.0.3/flowplayer.min.js to jquery/flowplayer.min.js and then WSN will automatically use those local files instead of the flowplayer.org versions. This can also protect you in the event that flowplayer.org goes down, of course.

In other news, I've added openroute geocoding. Lots of redundant geocoding options now. We'll need openroute eventually for Open Street Map driving directions too. Since OpenCage provides a handy way to detect when the 2500 requests have been used, I'll make WSN automatically switch to openroute when OpenCage requires have been exhausted. Essentially you'll get 5000 geocodes per day now through the automatic combination of the tw...

Read Full Blog Entry

By on Nov 27, 2018 at 12:58 PM

Here's something everybody can use. Grab a free copy of the latest WSN Links 10.3.15, use the new bookmarks importer tool at Admin -> Links -> Add Links, and viola: you've got your personal favorite web directory with all the searching and sorting features you could want. You can let WSN automatically prune dead links or convert them to wayback machine versions during import. Link descriptions (meta description), tags (meta keywords) and associated RSS feeds can be imported automatically. The category structure, of course, will mirror the structure of your bookmarks folders.

I've tested this mostly on Chrome bookmarks, but verified Firefox works too at least for simple cases. Not sure about other browsers. There may be people with more complex bookmark structures than me who will need to report bugs, but I've got several levels of folders with 482 links importing nicely.

This could be a good way to share your bookmarks with your friends too, even enable the social tools to let them comment.

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

<< January 2019 >>

Recent Comments