pwFoo

Because of needed redesign and rework most of the code will be changed / optimized Test today was with PW 2.5.18 dev and PHP 5.5.21.

It's fine if Fredi works for you FormHelper and FrontendContentManager need some work to be compatible with the latest dev, but at the moment I have some other projects.

Hello JoZ3, sorry for the delay... I installed both (FormHelper and FrontendContentManager) via PW backend Navigate to Admin -> Modules -> New Fill in FormHelper (second time FrontendContentManager) as ModuleClassName Click Download and Install No errors during install the current module versions. Could You try it again?

At the moment I try to build universal and extendable login / register modules. First builds here. https://processwire.com/talk/topic/8001-frontenduserlogin/ https://processwire.com/talk/topic/8013-module-frontenduserregister/ But need feedback and maybe help to get it ready and useable ForgotPassword (core module) and PersistLogin (manual mode) are integrated as plugins (sub modules).

Register module with plugin feature. Form is unstyled at the moment, but register a user works. Honeypot plugin is at the moment a visible additional form field (should be hidden by css or js), but should give you an idea about the planned plugin structure. https://bitbucket.org/pwFoo/frontenduserregister/src/bb750e24afe356d36bc1d2bb064ccd925fd92e9e/FrontendUserRegister/?at=master Because most methods are hookable module is extendable with plugins like email (pre register?) verification, additional form fields, ...

Login module should work, but the form is unstyled. A plugin is a module with attach / detach during install / uninstall to the parent module. Demo plugins (minimal tested!) are persistLogin module integration (manual mode, remember me checkbox) ProcessForgotPassword (core module) integration https://bitbucket.org/pwFoo/frontenduserlogin/src/be5b84b78d24060872d0ae96f2e7631f50028099/FrontendUserLogin/?at=master

Some modules missing parameters to make sense or useable in the frontend. Instead of hacks or additional hooks to do changes it should be realized with some more parameters during module load in the frontend. But maybe a improved documentation should do it. Form api is great. I use it everywhere I working with PW forms!!! There are some helpful and great topics here (special thanks to Soma ).

Hi Ryan, would be great get core modules (inputfields, form api, ...) documented and also usable in the frontend (so far it's possible and make sense ).

Attach / detach plugins to a parent module works fine, but parent module uninstall will blocked by the plugins (because "requires parent module"). Is there a way to uninstall all plugins during parent uninstall instead of block the uninstall process? Attached plugin modulesFrontendUserRegisterPluginHoneypot Uninstall (Disabled) Can't uninstall module - Module is required by other modules that must be removed first Uninstall (Disabled)You must first uninstall other modules - FrontendUserRegisterPluginHoneypot

Ok... after a little more searching that should be the solution... https://processwire.com/talk/topic/648-storing-module-config-using-api/?p=5241

I try to build module plugins / children. Child modules should be load during parent / main module init. Load the modules is easy, but how could a attach a child module to the parent? 1) How to modify the parent module? 2) Because only installed plugins / children loaded during parent init, attach / detach during child un-/install should be fine. Search for a simple in module solution. No autoload needed. Parent module should load a saved list of children to work with.

FrontendUserLogin 0.3 released (dev / unstable) Updated initial post. Tests and feedback welcome! FormHelper dependency is removed should work with Persistent login for users (mode: automatically) out of the box simple error handling (login failed, LoginThrottle, missing required value) Strings translatable by using $this->_() code optimized and some hookable methods removed (use PW Session methods instead!) Session::login Session::authenticate Session::logout Session::redirect hookable methods to modify form fields and form process / validation. Also to extend module with plugins / addons. FrontendUserLogin::processForm FrontendUserLogin::buildLoginForm ToDo Change password field type to password (at the moment isn't supported by PW?!) Remove (optional) field labels (seems not working after field is added to the form object?!) maybe a default style and optional add custom css / js code Change integration of Persistent login for users via plugin module (add Remember me checkbox and trigger PersistLogin manual mode) Forgot Password core module integration?

Do you try to edit or create a page with FCM? I'll take a look. Maybe I'll release a fix to make it useable until I rewrite it...

You shouldn't use FrontendContentManager (FCM) because it's unstable and after some changes at PW dev FormHelper amd FCM won't work as expected in future releases. At the moment I remove the FormHelper dependency for FrontendUserLogin and FrontendUserRegister modules because of the native support for form fields as array data. Maybe I'm rewrite / redesign FormHelp to simplify form process and file handling, but have to think about first. After current work is done, I'll start a new try to build a FCM module. If you need a module to frontend edit pages you should try Fredi for example.

FCM has to be rewritten and isn't ready to use! Do NOT use FCM module yet!

Hi JoZ3, could You provide your code which uses FormHelper and your PW version?

Maybe not working if field is already added to the form?

Module will be updated soon... - remove FormHelper dependency - planned (optional) features email activation and honeypot to reduce spam registrations

Nice module. I'll try it soon I build an inline edit module with Tokeninput with free tagging and ajax data source, but I build it for frontend use and not a Inputfield.

Have you added an element with ID "PageIDIndicator"? If you remove / rename it upload should work without modifications. Take a look at the if condition.

Thanks, Soma. I'll try it. With a edit form (existing page) Inputfields ckeditor and image / file works fine. I'll prefered to use those Inputfields also to create a new page So you recommend not to use the (designed for backend) Inputfields?

With older PW version some month before it works fine with a "fake page" public function fakePage($tpl) { $fakePage = new Page(); $fakePage->template = $tpl; return $fakePage; } and getInputfields() elseif($src instanceof Template) { $fields = $this->fakePage($src)->getInputfields(); } $src is a template object (function param). Tested it with latest dev some days before and now it works no more. I'll check my code and test it again, but it looks like a PW dev change. Is there another / better way to work with "template based forms" (no existing page, because page will be created after form sent / processed).

A simple module to exend view / edit permissions via reference current page -> group -> user current Page -> user It works with 4 additional fields refAccessGroup_view refAccessGroup_edit refAccessUser_view refAccessUser_edit Selector to check permissions is generated because fields optional. Field exists at current template is checked by a has() call and permissions verified by count() calls. Here is the combined view / edit permission check function public function checkRefAccess($refPage, $userId, $permission = 'view') { // Has page group based reference access field? if ($fieldGroupExists = $refPage->has("{$this->fieldGroupRef}_{$permission}")) { $selector[] = "{$this->fieldGroupRef}_{$permission}.{$this->fieldUserRef}_{$permission}"; $selectorCount[] = "{$this->fieldGroupRef}_{$permission}.count<1"; } // Has page user based reference access field? if ($fieldUserExists = $refPage->has("{$this->fieldUserRef}_{$permission}")) { $selector[] = "{$this->fieldUserRef}_{$permission}"; $selectorCount[] = "{$this->fieldUserRef}_{$permission}.count<1"; } if (!$fieldGroupExists && !$fieldUserExists) return false; // Build selector with existing field(s) $selectorCount = implode(',', $selectorCount); $selector = implode('|', $selector); // view access to public and unrestricted content? if ($permission == 'view' && $this->publicAccess && $this->pages->count("id={$refPage->id}, {$selectorCount}")) { return true; } // view | edit access allowed by group | user reference? elseif ($this->pages->count("id={$refPage->id}, {$selector}={$userId}")) { return true; } else { return false; } } Maybe looks confusing, but seems to work *g* 1) check viewable && default public && group / user count < 1 (NO users or groups set!) -> public page without restrictions 2) user get permission to view | edit by a group or user reference -> user is member of a allowed group or directly referenced as user Link to bitbucket branch https://bitbucket.org/pwFoo/accessbyreference/src/c806dc3c7cec154f84b7f31fb81767603a4009b7/AccessByReference/AccessByReference.module?at=pwFoo

I look how to redirect guests to a login on permission denied instead of 404 page. Is redirectLogin removed from the template admin? Seen it in the past, but isn't available in my PW dev install. I'll test it via api, but would like to know if I miss something because I haven't found it in the admin backend.

Is it possible to skip it to get form uploads via template file / image inputfield working? I know I could create and add an image upload field, but it would be great to generate an form based on the template fields without hardcoded parts. It works fine in "older" versions of PW (stable or earlier dev).