Search    Register    Log In   

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.

By on Sep 13, 2016 at 8:15 AM (Edited Sep 13, 2016 at 8:19 AM)

I've just released 10.0.19. Besides a bunch of minor fixes, an update to the bxslider component and the auctions system and cache mentioned in recent previous blogs, the rest of the changes relate to the saved listings system.

In the past, there've been two parallel saved listings systems -- one in the database for members and one in browser localstorage for guests. 10.0.19 unifies that by importing the guest localstorage data to the database, and sending a cookie to the browser to act as a unique identifier for that guest's database entries. This means it's now possible to show how many guests have saved a particular listing, as well as how many members. This unification process also made it easier for me to bring a guest's saved listings with them when they become a member, which wasn't happening before but is now (automatically).

A major under the hood structural change to saved listings is that they've been moved to their own separate table now instead of being tracked in the listing savedby field. The only way this will affect most of you is that you can now create toplists of saved listings in the toplist generator by selecing the savedlinks table. If by some chance you created a toplist with a custom SQL filter based on the savedby field, it will no longer work until you convert it -- fortunately I think it's unlikely that anyone has done so since the format of the field wasn't documented. The underlying reason for the change was to enable manual drag and drop ordering of saved listings, which isn't enabled by default but is available with the new manualsortsaved tweak. If not using manualsortsaved, the old sorting selector still works.

Another change is that saved listings collections can now be shared publically between your members. When the new "public saved listings" switch is turned on, each member's profile page shows a link to view that member's saved listings. If comments are switched on, members can also discuss each other's saved listing collect...

Read Full Blog Entry

<< January 2019 >>

Recent Comments