Tag Archives: known

Posted on
by

A number of folk have been starting to see some more spam comments appearing in their logged out comments section, posted by bots.

I’ve already written an Akismet plugin, which has helped with some of it, and Known core has also been extended with some countermeasures. However, I have wanted to see if I could do some more.

When I was wearing one of my other hats the other day, I had the opportunity to play with the new Recaptcha 3 code, and I thought I’d bring it to Known.

Recaptcha 3 takes a new approach to detecting bots. Rather than getting a popup and getting you to click on pictures (which is very very annoying, and hard for those with accessibility issues), Recaptcha 3 does some arcane magicks behind the scenes to determine who’s bot or not, and then gives you a score indicating the likelihood that you’re dealing with a human. 1.0 for high likelihood of a meat sack, 0.0 for a bot, and then any value in between.

Much like with spam detectors like Spam Assassin, you can then set your own threshold values and do this on a page by page basis.

Crucially, you’re never going to get a popup. Thank the Gods.

Anyway, I’ve built this out as a plugin. Out of the box, you’ll get protection for login, registration, and public comments, but you can extend it to protect your own custom forms without too much trouble.

Have a play!

» Visit the project on Github...

Posted on
by

In my mind, one of the important milestones in our long march towards Known 1.0, was to allow allow Known settings and admin pages to have their own template.

It was not uncommon for themes or plugins to get a little broken, and in some cases this caused Known’s admin page to break. A bad time all round.

So, a recent patch makes it so that these special pages can now have their own templates, which will make Known framework sites much more robust.

As a side effect of this, I’ve introduced a mechanism in the template system for code to specify a different page shell for a url hierarchy. So, for example, by using \Idno\Core\Idno::site()->template()->addUrlShellOverride('/foo/', 'foo-shell') you can specify that anything under ‘/foo/’ would use shell ‘foo-shell’, automatically.

More tweaks to come, I’m sure, but so far it looks like this…

Posted on
by

The recent move to Composer for Known (and eventually Known plugins) has given me the opportunity to improve the experience for plugin developers.

Previously, generating a .pot file for languages would require a script in Known’s central language directory. This meant all sorts of “relative path” hijinks in your Gruntfile.js, and was generally bad.

So, I’ve taken this opportunity to package up the script into its own project that can be installed via composer as a development dependency into your plugin project.

How to use

  1. Create your CoolProject, and add your translation string hooks, and load them as described here.
  2. In your project, add known-language-tools as a dependency using composer require mapkyca/known-language-tools --dev
  3. In the project directory you’ll find a Sample.package.json file. Copy this to your project root as package.json and edit accordingly. Note your project name should be the name of your project.
  4. In the project directory, you’ll find a Sample.Gruntfile.js. Again, copy this into your project root.
  5. Create a languages directory
  6. Run the grunt task, grunt build-lang (if grunt isn’t found, npm install --only=dev first.

Hope this is useful to you!

» Visit the project on Github...