netcarver

Thanks for posting this diogo!

Actually, you can control the parent-child relationship, restricting children (or parents) to a certain type (or types) of template. If you edit a template you'll see a tab called "Family" (in the English version) and that's where you can setup restrictions on the relationships.

There is always the IRC channel #processwire over on freenode.net as a possible place to ask and (depending on who is in at the time) get some of your questions answered.

An alternative (and relatively cheap) hardware based token generator.

Ok, so all the PINs are already known . What's interesting in this article on a 3.4 million PIN number leak is the patterns users use to make remembering just 4 digits easy.

I am already sans-beard

Yep. Everyone in the IRC channel has to have a clean-shaven gravatar

That's good to know Ryan, thanks for testing it. I wasn't aware of the installs property, must have missed that from my reading of the wiki. I separated it in case anyone else wanted to develop modules that use the PPP one-time-pad system (though I don't have any further plans to right now) and also because the code in CryptoPPP is mainly comprised of parts of existing PHP implementations of the PPP system and I wanted to able to credit those folks in the module's information. My contributions are mainly within the 2-factor authentication module. I plan on doing that once there has been some additional testing and I've worked out the two problems I have with it at present (see the Known Problems part of the opening post.)

Thanks to Soma for helping me with module questions via the #processwire IRC channel.

I've been working on an experimental module set that adds 2-factor authentication to ProcessWire with the help of Steve Gibson's PPP one-time-pad system. This is split into two modules; a CryptoPPP library that implements the otp system and a 2-factor authentication module that uses it to add 2-factor authentication to ProcessWire. The 2-factor module adds an additional "Login Token" field to the login page into which the authenticating user will need to enter the next unused token from their one-time-pad. Pages from their pad can either be printed out in advance in a credit-card sized format (with codes being crossed out as they are used as shown here) or the required token can be sent to their registered email address so they don't need to print anything out. This second option requires a good email address be present in the user's account in order for them to be sent the token. Email Delivery To set up email delivery go to the 2-factor module's config page and choose "token delivery via email" and save the settings. Next, make sure that every user who will use the system has a valid email address set up in their account. Upon the first failed user login attempt, the required token will be emailed to the user’s email address and they should then be able to log in. Printing Pages From The Pad If you prefer to print the tokens in a handy credit-card sized format then… Go to your profile screen Expand the “PPP Initialisation Vector” field Hit the “Show Token Cards” button to open a new browser window with the next 3 useful cards Use your browser’s print option to print these out Trim them to size and store ...but make sure you print these out before you enable 2-factor authentication on your account. If you cross out your used codes, you will always know which code to use when logging back in -- and if you forget, the first login attempt will fail and the token field will then prompt you with the location of the correct code to use. Why would I ever want to use 2-factor authentication? If your site is only for you or for people you know use good passwords then you probably never will need a 2-factor authentication system. But it has been shown that many users use passwords that are, well, rubbish not very good and having a second factor can be useful in mitigating poor passwords. As the second factor in this system comes out of a one-time-pad system (meaning it will not be reused) then having the user's password leaked or guessed should not compromise their account nor will having someone spy out the token they are using to log-in as tokens are not re-used (well, not for a very long time.) Known Problems You need to hit the save button after you install the 2-factor module to get it to remember the initial settings. (I guess I'm not setting the defaults correctly at present but pressing the button will allow you to move forward for now) Uninstall of the 2-factor module leads to a lot of warnings. Attachments

<irrelevant><off_topic> I think CAPTCHA's are actually misnamed. It means "Completely Automated Public Turing test to tell Computers and Humans Apart" but a Turing test is, AFAIK, a test applied by a human to tell humans and computers apart. In CAPTCHA's its done by a computer. </off_topic></irrelevant>

I think you have to apply the disabled attribute just prior to rendering in the GUI, so a module doing this in its init()... $this->addHookBefore('Inputfield::render', $this, 'myHook' ); And then having this... protected function myHook(HookEvent $event) { if( 'FieldNameYouWantDisabled'' === $event->object->name ) $event->object->attr( 'disabled', 'disabled' ); } ...should be enough.

Just stumbled on something unexpected, if not problematic, in the admin interface. I was looking at the guest user page accessed via the Admin > Access > Users > guest route and I hit the save button *without* making a single edit. Interestingly, I got the following messages about the result of that save... [tick] Change: roles [tick] Saved Page: /processwire/access/users/guest/ [cross] The guest role is required ...which isn't exactly what I'd have expected having made no changes. I've checked with others in the chatroom and they are seeing the same thing. This seems similar to something that I found the other day regarding PW not 'keeping' the checked status of submitted checkboxes if they have the 'disabled' attribute set. As it looks like the roles checkboxes are all disabled for the guest user that might be why it's picking up a change.

Forgot to mention that DS is (effectively) a Textpattern alias for DIRECTORY_SEPARATOR.

Ryan, looks like you have some hard-coded assumptions of unix path separators in the codebase that might better be swapped for the DS constant. Take a look at _copyFiles() in PagefilesManager.php for one example (there might be more)... protected function _copyFiles($fromPath, $toPath) { if(!is_dir($toPath)) return 0; $numCopied = 0; $fromPath = rtrim($fromPath, '/') . '/'; $toPath = rtrim($toPath, '/') . '/'; foreach(new DirectoryIterator($fromPath) as $file) { if($file->isDot()) continue; if($file->isDir()) { $newPath = $toPath . $file->getFilename() . '/'; $this->_createPath($newPath); $numCopied += $this->_copyFiles($file->getPathname(), $newPath); continue; } if($file->isFile()) { if(copy($file->getPathname(), $toPath . $file->getFilename())) $numCopied++; } } return $numCopied; Where you are doing trims + replaces with forward slashes (unix-specific) rather than the OS-neutral DS. Check out this post of mine from waaaayyyy back in my Textpattern days for more background. I'm not suggesting this is the exact source of the problem being reported in this thread but I think it does represent a code portability issue for PW.

@renobird Looks like it is now.

.htaccess issue perhaps?

The IRC channel does seem to be busier than usual today - it's nice to see so many newcomers in there.

Welcome to 2012

Hi Tim and welcome to PW. Just posting this in case you hadn't spotted that there is a ProcessWire IRC channel from your lurking in the forum.

Amazing work Ryan - as usual!

Not sure about the duplicate warning but for the latin1 to utf-8 import then one option might be to use a DB management tool to copy the source table and then change every text-based field / text-based index (if you need to maintain/import them too) over to utf-8 prior to attempting the import.

Hi jukooz, please see this post for more information. In theory: great idea. In practice: could be more difficult than expected, not necessarily due to PDO (which does allow good connectivity between backend DBs) but perhaps due to the little differences in the dialects of SQL that they all use which could be sources of incompatibility. This needs careful investigation as, AFAIK, ProcessWire's selectors can generate some pretty complex SQL.

ROFL! I was hoping that was a ProcessWire logo on the garment.

'lead' => 'leading' 'iron' => 'ironing' ?