Module Dice Captcha

[rot]

I released a simple module:
 
Processwire Dice Captcha Module
 


This is a very simple captcha module. For more extensive information please read the REAMDE on github.
 
If you want you can change the jpg files and adapt the size setting in the module accordingly. This should also increase security as if you use more complex images they will be harder to recognize. You can als change the number of dices asked for.
 
Usage:

<?php
//Init Module
$dice = $modules->get("FormDiceCaptcha");

//On submit check if the validation is correct
if($input->post->submit) {
    //validate - the value is stored in the session
    if(!$dice->validate($input->post->captcha))
      echo "<p class='error'>".__("Please check that you have completed all fields")."</p>";
    else
      echo "Success!";
}

?>

<form method="post" action="./">
  <!--Show captcha -->
  <img src="$dice->captcha()"/>
  How much is the sum of the dices?
  <!--ask for sum -->
  <input type="text" name="captcha" value="$form[captcha]"/>
  <input type="submit" name="submit" value="submit">
</form>

Github:
https://github.com/romanseidl/FormDiceCaptcha
 
Changelog

• 0.1.1 Changed the directory structure to conform with Processwire standards and renamed the module classname to FormDiceCapture to conform naming conventions. Also the github project had to be renamed.
  In case you have version 0.1.0 installed you will have to change the calls to $modules->get('DiceCaptcha') to $modules->get('FormDiceCaptcha') after updating to 0.1.1.
   

Edited April 18, 2015 by Nico Knoll
Added the "module" tag and removed it from title.

[rot]

I added a config interface for the num_dices and the image size. Beyond I added a version number to the module info.

[adrian]

I see that you just upped the version number in the modules directory for this module, as well as your TextformatterImageLinkInterceptor module, both to 0.1

The problem is that in Github, they are both still showing: 'version' => 1 which translates to 0.0.1

This is causing problems for PW sites when you click "Check for Updates" or you use the ProcessWire Upgrades module because they both say there is an update (because they pull from the modules directory), but then they get the files from Github which are still versioned as 0.0.1

The best option is to set the version in the file on github and then run the "Edit this Module" option in the modules directory and just submit to have it grab the new version number directly from the file - this way they will always be in sync and will prevent any issues.

Thanks!

[rot]

Oh. Sorry.

Thanks for the info.

What version should I set in the files to correspond to 0.1? 10? Or 0.1?

[adrian]

What version should I set in the files to correspond to 0.1? 10? Or 0.1? 

10

1 = 0.0.1

10 = 0.1

100 = 1

111 = 1.1.1

[Mike Rockett]

This is actually quite interesting. I've been wanting to know why we can use numbers instead of strings. Is there any benefit to this?

[adrian]

I honestly don't know why it is the convention and I don't really like it, but maybe there is a good reason.

I am pretty sure you can use strings just fine and I think it would encourage easier use semantic version numbers.

One thing to be careful of is things like: 1.1.1 as that won't work as a number, although it should work as a string. 1.1 does work as a number though. At least that is my experience: https://github.com/NicoKnoll/MigratorWordpress/commit/50be6896ffae67dc467a62164fa8cd968462237b

EDIT: Maybe using integers just makes it easier to compare version numbers - whether there is a newer version available? Although I am sure we can still do this and have more flexibility. Maybe they should be in three parts, like the PW core: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ProcessWire.php#L34

[Mike Rockett]

One thing to be careful of is things like: 1.1.1 as that won't work as a number, although it should work as a string. 1.1 does work as a number though. At least that is my experience: https://github.com/NicoKnoll/MigratorWordpress/commit/50be6896ffae67dc467a62164fa8cd968462237b

Just had a look at that commit, and I see that the 1.3.1 wasn't enclosed in quotes, which is why it never worked. 

With Jumplinks, PW seems not to have had any issues with me using strings instead of numbers/floats.

Sorry - misread your post. Just woke up from a little nap.

From my viewpoint, it's just a semantics thing - though I could very well be wrong.

[rot]

Anyway I just updated the git files to 'version' => 10. Hope that solves the issue.

One more question: I have the zip file pointing to a file that contains two subdirectories (s. https://github.com/romanseidl/dice-captcha/archive/master.zip) as the module is in a subdirectory.

Is this a good thing to have?

[horst]

No, this is not as good as it could be. The format of the folder should be in a descriptive name where the first part should be a category where sufficient: Markup or Inputfield or Process etc. folllowed by the rest of the name.

The complete name has to be InCamelCase, only containing a-z A-Z, maybe 0-9 is allowed too, but I'm not sure about it.

Your modules root folder should have this name and in it there has to be at least one module file, the main file if you like to call it that way. Its name is the same like the folder (InCamelCase) with the file extension .module - The module file must have a class definition with also exact that name.

All other you can handle as you like, with subfolders or not, etc.

[rot]

Thanks for the reply. Unfortunately I did not really completely understand it.

First there ist this CamelCase naming. The module directory and the "main" module should have that CategoryCamelCase.module name. Like ProcessMakeCoffee.module. I think I understood that one but I could not think of a good category for the DiceCapture. Maybe "Form" or something like that?

On github the default zip file packs all file into a directory called like the "repository-name".

So if you would

• set up a repository called "make-coffee"
• and then create a directory called "ProcessMakeCoffee"
• and put ProcessMakeCoffee.module into it

The zip layout would be as follows:

make-coffee

          ^-ProcessMakeCoffee

                            ^-ProcessMakeCoffee.module

Is this a good layout? Or should I rather:

• set up a repository called "ProcessMakeCoffee"
• and put ProcessMakeCoffee.module into it

The zip layout would be as follows:

ProcessMakeCoffee

                ^-ProcessMakeCoffee.module

Maybe one can also create zip files from subdirectories on github. No idea about that. Else the repository name would have match.

Should I rather use the first or the second project layout?

[kongondo]

Naming Conventions:
Have a look at these:
https://processwire.com/talk/topic/2394-how-to-present-your-module/
http://processwire.com/api/modules/
 

For modules that aren't based on these existing types, you don't need to consider naming conventions.

 
 That is what Horst meant by:
 

The format of the folder should be in a descriptive name where the first part should be a category where sufficient: Markup or Inputfield or Process etc. folllowed by the rest of the name.

 
  Note though that the class name still has to be...ClassName..., i.e. just the way you've named yours..
 
 Directory structure...
 

ProcessMakeCoffee
                ^-ProcessMakeCoffee.module

 
....should be fine. PW will automatically create a directory named after the module class (ProcessMakeCoffee) when that module is installed if you've submitted it to the modules' directory. Otherwise, the normal instruction is for your users to create the directory if manually installing the module....Have a look at the GitHub project pages of some of the modules in the modules' directory..e..g.
 
https://github.com/ryancramerdesign/FieldtypeEvents
https://github.com/somatonic/MarkupSimpleNavigation

https://github.com/horst-n/WireMailSmtp

Edited April 16, 2015 by kongondo

[teppo]

EDIT: Maybe using integers just makes it easier to compare version numbers - whether there is a newer version available?

Sorry, a bit OT, but this is exactly why PHP has version_compare(). Either way, three digits can't properly represent version numbers (1.11.1, etc.) so that's not a very good convention to have, whether or not it makes some things slightly easier

[rot]

So i would like to rename the Module to "FormDiceCapture" and rename the github repository.

Is this OK to do? I assume hardly anybody has installed the modlue yet but it might break their update path?

One can NOT create zip files of subdirectories. So the correct proces is to:

• set up a repository called "ProcessMakeCoffee"
• and put ProcessMakeCoffee.module into it

[kongondo]

So i would like to rename the Module to "FormDiceCapture" and rename the github repository.

Is this OK to do? I assume hardly anybody has installed the modlue yet but it might break their update path?

I suppose you can, given that the module is still in Alpha. You would then make an announcement here (and especially in your first post). I would also recommend you polish up the readme a bit ....just a little bit about what the module does (I know we 'all' know about captcha...but nice touch to say what your module does all the same). Thanks!

[rot]

I changed the directory structure to conform with Processwire standards and renamed the module classname to FormDiceCapture to conform naming conventions. The version number has been increased to 0.1.1.

In case you have the module installed you will have to change the calls to $modules->get('DiceCaptcha') to $modules->get('FormDiceCaptcha').

Sorry for any inconvenience caused by that. I though I might rather change that now than later when there is more users.

[hellomoto]

This is compatible with PW 3.

Is there any reason you would not use it in production? I tried hCaptcha but that's more laborous for users.