Webmastersite.net

Search    Register    Log In   


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. Mapbox...

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 settin...

Read Full Blog Entry


By on Nov 17, 2018 at 6:32 AM

Thought I'd revive this blog to go into more detail about developments in the WSN 10.3 series so far. Let's start with an entry about the bootstrap-related developments, which have been numerous.

To free things up a bit from the non-bootstrap legacy, WSN now has two different base styles. When using a legacy (non-bootstrap) theme, the schemas/base.css gets called in as before -- but for bootstrap themes, WSN now calls schemas/bootstrapbase.css instead. I've been trimming some legacy cruft out of bootstrapbase.css and trying to let as much of bootstrap's own rules take precedence as possible. This has resulted in some visual mistakes in a few releases, like certain tables not being aligned to top that needed to be because I simplified too much. Hopefully I've caught all of those situations now.

The bootstrap user-editable stylesheet (templates/styles/default.css or templates/styles/bootstrap.css) has changed too. In 10.2 and before, it used an @import rule to pull in bootswatch themes or the generic bootstrap from a CDN. This was problematic if you're sometimes working offline with a localhost installation, and also addde another DNS lookup to a another server that can sometimes slow things down, and increased the chances of downtime since both your server and the theme CDN server had to be working for your site to work right. So what I decided to do was have WSN download and cache the bootswatch themes and display them from the local copy. In order to accomplish that, I had to removed the @import from the style and move the bootstrap loading to the backend code.

You now choose your bootswatch theme or specify a custom bootstrap theme source at Admin -> Themes -> Theme Settings. Instead of displaying the theme from the remote source, WSN downloads and caches a copy of whichever bootswatch theme you select and then displays it from the local copy.
The dark bootswatch styles proved difficult as they normally rely on appending a bunch of rules to the user styl...

Read Full Blog Entry


By on May 27, 2017 at 10:24 AM

Lots of advancements in WSN's mapping functionality lately, as of 10.1.11 Beta 4.

First, the issue of not having all possible pins on the category or search map at once is at last solved. By setting Admin -> Settings -> General -> Map Pins Loading Strategy to "all", WSN will progressively load all applicable pins that are within the current viewport -- and when the viewport changes by drag/zoom, it loads anything needed for the new viewport. It's generally a quick process but there's a loading indicator bar to make it clear when it completes.

Second, I set about making it possible to dynamically filter the map by listing type by checking or unchecking a checkbox for each type. To use this, simply insert {FUNC_ADDFILTERPINSHTML} where you want the checkboxes displayed.

Third, in conjunction with the above I thought it'd be nice to visually distinguish pins of each listing type in different colors. This is now possible by setting the coloredpins tweak. Up to 7 colors are automatically assigned, and a colored pin is displayed by the checkbox to act as a visual key.


By on Apr 19, 2017 at 10:39 PM (Edited Apr 19, 2017 at 10:46 PM)

Adding a couple of new tweaks today: changeswitches and changesettings. These allow you to change the value of any switch or setting using your tweaks.php file, instead of using the admin panel. My personal use case is for my development site where I want to do my testing with reCAPTCHA and alertify turned off, but not actually configure the site that way because my release tools make the development copy's configuration be the default configuration. I'd imagine you might want to use it to create special tweaks files you can upload to a site to put it into a testing configuration, or something like that.

Here's how it works. Open tweaks.php in a text editor. Then add lines like this before the ?>:

$changesettings['stopspam'] = 'bait';
$changeswitches['alertify'] = 0;

Note that switches must always be 0 (turned off) or 1 (turned on). You can add as many settings or switches as you like.

In order to avoid accidentally saving the changed state in the admin, these changes are applied only on front-end pages -- not in the admin panel.


By on Mar 26, 2017 at 6:50 PM

As of WSN 10.1.7, reCAPTCHA will be enabled by default using shared keys with no domain restrictions. This will provide a better out of the box spam-prevention experience on new installations, avoiding the accessibility issues of WSN's internally-generated CAPTCHA.

You may still wish to replace the shared keys with your own keys in order to have control over the challenge level (more human-friendly or more secure against machines).

I've also added a line to the privacy policy page when reCAPTCHA is enabled which explains that it uses cookies and shares data with google, fulfilling EU privacy disclosure law.


By on Nov 15, 2016 at 11:17 AM

Normally, WSN's CAPTCHA option is sufficient to stop spammers from submitting to your site. It can be a bit annoying to the submitter, though, and hard to read at times. It can also be defeated by the more advanced or specifically-targeted bots.

Now you have another option: google's reCAPTCHA. reCAPTCHA has several advantages. First, it can be "solved" with just a click in most cases thus saving the submitter time and effort. Second, when it suspects the user of being a bot, it presents them with problems that are impossible for current AI systems -- such as choosing which of a series of pictures contain a certain thing. Third, the complexity is configurable so you can decide whether to make things easier or more secure.

The drawback of reCAPTCHA is that you have to sign up for keys for each domain name to use it. When you select it from the spam prevention menu at Admin -> Settings -> General, two boxes will immediately appear prompting you for the site key and secret key and there'll be a link above the boxes telling you where to register to get the keys.

reCAPTCHA is available in WSN versions 10.0.32 Beta 3 and later.


By on Sep 24, 2016 at 11:02 AM

It just got a lot easier to do a one state directory. By that I mean a directory where the category structure is all counties of a particular US state, or cities by county... not a directory of businesses in Yevgeny Zamyatin's dystopian One State.

For a while, we've had options in the auto setup to choose a category structure of counties by state or cities by county by state. That works well for a national directory, but in many cases people just want a directory for a particular state. Removing the undesired states was no simple matter, and then since having a single superflous top level category is undesirable you'd want to make all the subcategories into top level categories. With WSN 10.0.22 Beta 3 and the latest version of autosetup.php, all the required queries have been automated. All you do is select "Counties of single state" or "Cities by county of single state" under "Pre-Load Data" during setup, and then select your desired state from the dropdown that appears. As an additional convenience, either of these selections will also automatically trim your countries list at Admin -> Settings -> Localization to just "United States" and states list to just your selected state, so that submitters don't have a chance to mess up the address.

A further improvement I have in mind for the future is to create a "cities as autocategories" switch which will remove the category selection process from submitting listings, and instead automatically choose a category based on the city/state provided as the listings address. This of course would require that all listings have an address. It would also need to automatically create new subcategories for city names that don't yet have categories, and would have to wait until after validation to do so in order to prevent spammy category names.


By on Sep 17, 2016 at 6:58 AM

The blog theme, similar to what you see on this blog (though a little better because I haven't updated the version here for a bit), is now available in the Add Themes page in WSN Knowedge Base 10.0.20. It's mostly bootstrap, with several templates a bit of language customized for blog use. If there's anything you like to see added to it, let me know.
<< April 2019 >>
SunMonTueWedThuFriSat
123456
78910111213
14151617181920
21222324252627
282930

Recent Comments