pwFoo

FrontendUser: login, logout and register users / members

Recommended Posts

FrontendUser
 
The FrontendUser module provides a frontend login, logout and user registration functionality.

 
Features

See module documentation for details.

  • login with error handling and value sanitizing
  • Plugin: ProcessForgotPassword core module integration
  • Plugin: LoginPersist module integration
     
  • user registration with username and email address already in use check
  • email adress pre-register validation (email verification)
     
  • Extendable with additional fields and by PW hooks
  • forms generated by PW form api
     
  • Custom style / script 
     

Requirements

Usage

Repository

ToDo / Issues

I hope it will be helpful to the community and I would be glad to get feedback or suggestions for improvement!

  • Like 8

Share this post


Link to post
Share on other sites

Hi pwFoo. I've tried to install first FormHelper on a clean local installation with Mamp Pro (PW 2.5.29, PHP 5.6.2). FormHelper.module was installed properly, but the FormHelperExtra.module gives me the following error: "Unable to install module 'FormHelperExtra': Can't save page 0: /fhstorage/: It has no parent assigned".

post-192-0-54688400-1430739618_thumb.png

Share this post


Link to post
Share on other sites

Hello jacmaes,

fhstorage is a hidden admin page to handle file uploads to not existing pages (during frontend page creation for example). It should be added and removed during FormHelperExtra module un-/install. I'll take a look at it later.

But FormHelperExtra isn't needed! Just install FormHelper and FrontendUser modules and it should work.

Share this post


Link to post
Share on other sites

Thanks. I realize that FormHelperExtra was not needed, so I went ahead and successfully installed everything else. The login and registration process work fine in my test environment, and it's pretty easy and quick to implement. Great job. 

Now I'd like to go one step further, and allow users to edit their profiles (after adding fields to the user template like "first name", "last name" and "birthdate" for example). I believe that FormHelper should help out with this, but how should I proceed? Could you add a simple example to the module docs? 

Share this post


Link to post
Share on other sites

I should be easy to extend the register form with additional fields (like done with the login and register plugins examples).

A FrontendUserProfile is planned and should be easy to build with the FormHelper module (and also without, but I like it ;) It simplify some tasks like sanitize values or form processing). Maybe ProcessProfile core module could do the job...

I take a look and maybe add a simple example, but that should be moved to the FormHelper topic.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks pwFoo. You're right, it's easy to extend and there are plenty of snippets in the forum to get anyone started quickly.

Share this post


Link to post
Share on other sites

Here is the source code of the LoginPersist integration.

        $persist = $this->modules->get('InputfieldCheckboxes');
        $persist->name = 'persist';
        $persist->attr('id+name', 'persist');
        $persist->skipLabel = 4;
        $persist->addoption('persist', $this->_('Remember me?'));
        $persist->addHookAfter('Session::login', function($event) use (&$persist) {
            if (isset($persist->value[0]) && $persist->value[0] === 'persist') {
                $this->modules->get('LoginPersist')->persist();
            }
        });

The examples hook into existing form fields.

Add own fields (example "$myField") or change order

$fu->login(array('username', 'password', 'persist', 'forgot', $myField));

See basic usage

Share this post


Link to post
Share on other sites

Updated FU version 0.8.2 replaced hard coded verification email with simple html / plain templates to send an html email with wiremail. Has to be improved / changed in the future, but I don't know how I'll implement it (module configuration, template, ...) to keep it flexible and simple.

  • Like 1

Share this post


Link to post
Share on other sites

I have some problems with the email template / config. Subject and text should be configurable, but I won't write a template parser to replace tokens like 

{{token}}
{{url}}
...

or something similar. 

Write the text to the template isn't a good way and also not translatable.

So how should / could it be done a nice way?

  1. Set text block in module configuration to be shown before the token / link?
  2. Move the complex email verification plugin to a separated module file with own config section?
  3. Use a page for email subject / text to be translatable like other fields?
  4. ...

I try to build a universal usable login / register module, so suggestions and feedback is welcome! ;)

Share this post


Link to post
Share on other sites

Version 0.8.3

  • moved email validation to sub-module FrontendUserRegisterEmailValidation
  • Added FrontendUserRegisterEmailValidation module configuration (email subject and text)
  • Removed plain email template (now generated by php based on the html one)
  • simple example html email template

Share this post


Link to post
Share on other sites

Hi again ;-)

thanks for the tips regarding php 5.3 workaround - that did the trick!

Another (minor) issue I encountered is that the generated email will still append the "normal" _main.php template file, which results in a doubled html / body code and may confuse some mail clients. By changing the line

//$mail->body($emailContentPlain)->bodyHTML($emailContentHtml);
$mail->body($emailContentPlain);

in FrontendUserRegisterEmailValidation.module the regex will strip out the _main.php tags as well, which for me right now works as a workaround, but of course I am wondering where I'd be able to undo the automatic appending of the _main.php … my guess is, that

$emailContentHtml = wire('page')->render($this->fu->getFile('validationEmail.php', 'templates'), $vars);

is the right place to look, but I've yet to find the correct setting for $vars. :-)

cheers;
Tom

Share this post


Link to post
Share on other sites

Hi Tom,

I think the email template isn't loaded! 

Again a PHP 5.3 workaround is needed ;)

I have an idea how to fix it and make the module compatible to PHP 5.3. I'll update it soon!

  • Like 1

Share this post


Link to post
Share on other sites

hi,

sorry for being unclear, the email template is loaded, i.e. the infos and content etc are in the email. it's only that after that, the _main.php is included, as well, which in my case will add additional (and content-less) html,body,etc markup to the already existing html,body,etc markup in the mail's source code. :-) Changes to the email template are reflected in the mail sent. It's only the additional markup that I'm wondering about.
 

Share this post


Link to post
Share on other sites

ok. Maybe a prepand / append to template problem? Could you check the config file?

I load a custom template from module folder. Maybe I need another way to load it to prevent the template append / prepand...

Updated module to 0.8.4 / email validation plugin to 0.0.2. 

  • module instance / object is now available via wire('fu') to simplify plugin hooks and...
  • add PHP 5.3 compatibility :)

Minimum tested at the moment! Could you test it and post the results here?

  • Like 1

Share this post


Link to post
Share on other sites

Hi,
wow, this is fast. :-) and on a sunday, too! <3
I merged your latest master with my local changes, keeping your 5.3 compat changes.
Works fine :biggrin:
1000thx

Share this post


Link to post
Share on other sites

Thanks for feedback. 

Is the template append problems also fixed with the new version?

Because that was also a anonymous function / php 5.3 problem.

Have to verified that the FrontendUserRegisterEmailValidation module configuration is working? It's used as email subject ($this->subject) an prepanded email text ($this->content). Works fine with php 5.5, but haven't tested it with php 5.3.

I merged your latest master with my local changes, keeping your 5.3 compat changes.

Could you tell me that you have changed? Customization should be possible without hack / modify the module. Just with PW hooks, custom plugins and additional fields ;)

Share this post


Link to post
Share on other sites

Hi,

well, basically I added a function to send another mail after sucessful registration, and bypassed the need to login after the user has entered his/her desired password in the second step.

I can send you a pull request of my dev-branch if you like, but rather wouldn't have this public for now since we hard-coded some email adresses and client-related stuff into the code… may I mail you a zip or invite you to our bitbucket team so you can see the fork?
(it's all a bit rushed right now b/c it needs to work tomorrow morning (launch) :-D )

Share this post


Link to post
Share on other sites

The hole email verification (hide password field, add verification code field, process additional fields and send the email) is based on hooks without a FU module modification. ;)

Additional email and auto login should be done by an additional hook ;)

Maybe I can take a look in the evening, but don't know yet...

FrontendUser module should work fine, but keep in mind it's alpha at the moment and needs testing!

Share this post


Link to post
Share on other sites

the template append is still there.

here's a excerpt from the mail source code if the

$mail->body($emailContentPlain)->bodyHTML($emailContentHtml);

is used, if I change this to

$mail->body($emailContentPlain);

the mail is ok (due to the regex stripping I guess).

--==Multipart_Boundary_x737b845286a9a5899d535817f4d80ca2x
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<html>
    <body>
        <p>Thank you, (snip snap) .... </p>
        <!-- empty line and comment only lines works as a linebreak with plain emails -->
        
        <p>User: Testtest<br />
        Email: test@test.te</p>

        <p>Code: 2b7d110cb29be35bbac13d506e02f7de</p>

        <p>Link: (domain)/registration/?registerToken=2b7d110cb29be35bbac13d506e02f7de</p>
    </body>
</html>
<!DOCTYPE html>
<html lang="de">
<head>
    <meta charset="utf-8" />
    <title></title>
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <script type="text/javascript" src="/site/templates/js/modernizr-custom.js"></script>

    <link rel="stylesheet" type="text/css" href="/site/templates/css/styles.css">

</head>
<body id="pid-1032" class="pid-1032 p-registration t-user_registration">
<div class="page">
            <main class="page-main">
        <!-- main content -->
            </main>
    <footer class="page-footer">
        <div class="container">
                    </div>
    </footer>
</div>
<script type="text/javascript" src="/site/templates/js/jquery.min.js"></script>
<script type="text/javascript" src="/site/templates/js/scripts.js"></script>

</body>
</html>

--==Multipart_Boundary_x737b845286a9a5899d535817f4d80ca2x--

The hole email verification (hide password field, add verification code field, process additional fields and send the email) is based on hooks without a FU module modification. ;)

Additional email and auto login should be done by an additional hook ;)

Maybe I can take a look in the evening, but don't know yet...

FrontendUser module should work fine, but keep in mind it's alpha at the moment and needs testing!

yes, and thank you for the alpha reminder ;-)
I need to learn the hook things better, and then I'll keep my fingers out of the module's code, promised! :-)

ah, and of course I don't expect you to tackle my problems here (just realised that the above may be read as "uh it's urgent, please have a look") but this is not how it was meant; I mentioned it only as an explanation why I hacked in your module's code :-))

Share this post


Link to post
Share on other sites

No problem. If you send me the additional code and I have the time I could rewrite it to a hook.

I would like to see the module used by the community and extended by hooks / plugins to keep the module core simple, clean and reusable ;)

Custom plugins could be added to my git repo / wiki to share with other PW users.

I'm also interested in feedback if you use it inside a project. Just to see how it could be improved.

  • Like 1

Share this post


Link to post
Share on other sites

Version 0.8.5

  • Add some more comments to FrontendUserRegisterEmailValidation module
  • FrontendUser::auth() is now hookable (to build a auto login after sucessful user registration)
  • Add usage shorthand to call login / register with one method call by set a second param ($redirect)
    // load module
    $fu = $modules->get('FrontendUser');
    
    // login
    echo $fu->login(null, $redirectDestination);   // with default fields
    //echo $fu->login(array('username', 'password', 'persist', 'forgot'), $redirectDestination);
    
    // load module
    $fu = $modules->get('FrontendUser');
    
    // registration
    echo $fu->register(null, $redirectDestination);  // with default fields
    //echo $fu->register(array('username', 'email', 'emailValidation', 'password'), $redirectDestination);
    

The compatibility to PHP 5.3 seems to work fine, but isn't fully tested. Because Processwire 2.5 / 2.6 requires PHP 5.3+ I would't increase the requirements to PHP 5.4 ;)

  • Like 2

Share this post


Link to post
Share on other sites

I'm testing the latest version, but:

Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8r DAV/2 PHP/5.4.10

Compile Error: Can't use method return value in write context (line 63 of /Volumes/Docs/MAMP/htdocs/pwire_test05/site/modules/FrontendUser/FrontendUser/FrontendUserRegisterEmailValidation.module) 

Share this post


Link to post
Share on other sites

Hello Macrura,

line 63 of FrontendUserRegisterEmailValidation.module:

        if (empty(wire('session')->get('registerStep'))) {

Seems to be PHP < 5.5 related...

Note:

Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)). Instead, use trim($name) == false.

 To be compatible with PHP 5.3 and 5.4 I have to check the usage of empty() in combination with wire() and replace such calls... I'll take a look later.

You could test this:

//        if (empty(wire('session')->get('registerStep'))) {
        $session = wire('session');
        if (empty($session->get('registerStep'))) {

Share this post


Link to post
Share on other sites

that didn't solve it...

Compile Error: Can't use method return value in write context

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By netcarver
      Part 1 of a 2 part Module & Service Reveal.
      I'm currently working on a new module: ModuleReleaseNotes that was inspired by the work I originally did on making Ryan's ProcessWireUpgrades module "release" aware. In the end, I decided to ditch the approach I was originally taking and instead work on a module that hooked in to the UpgradeConfirmation dialog and the module edit page.
      Aims
      My aims for this module are as follows...
      Make discovery of a module's changes prior to an upgrade a trivial task. Make breaking changes very obvious. Make reading of a module's support documentation post-install a trivial task. Make module authors start to think about how they can improve the change discovery process for their modules. Make sure the display of information from the module support files/commit messages doesn't introduce a vulnerability. Looking at these in turn...
      Making discovery of a module's changes prior to upgrade a trivial task.
      This is done by adding a "What's changed section" to the upgrade confirmation dialog.  This section takes a best-effort approach to showing what's changed between the installed version and the updated version that's available via the module repository.
      At present, it is only able to talk to github-hosted repositories in order to ask them for the release notes, the changelog file (if present) and a list of commits between the git tag that matches the installed version and the tag matching the latest version.
      It will display the Release Notes (if the author is using the feature), else it will display the commits between the tags (if tagging is used by the module author) else it will show the changelog file (if present) else it will show the latest N commits on the master branch (N, of course, being configurable to your liking.)
      An example of the Github Release Notes pulled in for you, taken from Mike Rockett's TextformatterTypographer Module...

      An example of a tag-to-tag commit list from the same module...

      An example of a changelog - formatted to show just the changes (formatting styles will change)...

      Finally, an example of a fallback list of commits - sorry Adrian ...

       
      Making breaking changes obvious.
      This is currently done by searching for a set of configurable search strings. Later versions may be able to support breaking change detection via use of Semantic Versioning - but this may require some way of signalling the use of this versioning standard on a module-by-module basis.
      For now, then, you can customise the default set of change markers. Here I have added my own alias to the list of breaking change markers and the changes section of the changelog is styled accordingly (these will be improved)...

       
      Make reading of a module's support documentation, post-install, a trivial task.
      This is done by making some of the support files (like the README, CHANGELOG and LICENSE files) readable from the module's information/settings screen. There is an option to control the initial open/closed state of this section...

      Here is Tracy's README file from within the module settings page... 

       
      Make module authors start to think about how they can improve the change discovery process for their modules.
      There are notes in each of the sections displayed on the upgrade confirmation page that help authors use each of the features...

       
      Make sure display of external information doesn't introduce a vulnerability.
      This is an ongoing concern, and is the thing that is most likely to delay or prevent this module's release lead to this module's withdrawl should a vulnerability be found. Currently, output is formatted either via Markdown + HTML Purifier (if it was originally a Markdown file) or via htmlspecialchars() if it has come from a plaintext file.
      If you discover a vulnerability, please get in contact with me via the forum PM system.
       
      Ongoing...
      For now, I've concentrated on integration with GitHub, as most people use that platform to host their code. I know a few people are hosting their repositories with BitBucket (PWFoo comes to mind) and some with GitLab (Mike Rockett?) and I would eventually like to have adaptor implementations for these providers (and perhaps GitKraken) - but for now, GitHub rules and the other hosts are unsupported.
       
      Links
      Github: ModuleReleaseNotes
      PW Module Repository: Here
    • By FrancisChung
      Hi,
      I was wondering if anyone knew what this did? 

      If so, do you know what modules it actually impacts? Is there another log that lists the action it took?

      I'm having some weird problems with PHP duplicate declaration per link below, since this module was run.
       
       
    • By tpr
      AdminOnSteroids
      Various admin tweaks to enhance ProcessWire admin.
      http://modules.processwire.com/modules/admin-on-steroids/
      https://github.com/rolandtoth/AdminOnSteroids

    • By Macrura
      Field Descriptions Extended
      This module enables you to extend field descriptions by dividing short descriptions with a longer text that is revealed in a toggle.
      Github: https://github.com/outflux3/FieldDescriptionsExtended
      Extending your field descriptions using the standard field's description field.
      Once this module is installed, it will automatically search your description field for the presence of 5 dashes (-----).
      Any content above the 5 dashes will be visible and the content below the dashes will be hidden. A 'More...' link will appear at the end of the short description which when clicked will reveal the rest of the description.
      Using Simple Markdown Editor with the description field
      If you have Simple Markdown Editor (InputfieldSimpleMDE) installed, you can enable the field description to have that editor.
      *When using Simple MDE, you can use the button (Insert Horizontal Line) instead of typing 5 dashes. More about SimpleMDE.
      Extending your field descriptions using content from a ProcessWire Page for the field description.
      You may use the content from a ProcessWire page as a field description. This would allow you to easily insert images, links, and use hanna codes.
      To use page content for your field descriptions, please follow these instructions:
      Install Select Fields module (FieldtypeFields) http://modules.processwire.com/modules/fieldtype-fields/ Create a new field using this field type, e.g. field_select. Add the field to any template you will be using for your field descriptions. Setup your help pages (for example under a settings branch) where you will store the field description content,using the template containing the Field Select. Add content to a page and select the field where that content should show. To show a short text before the link to the longer content, separate them with 5 dashes Be sure to update your settings on this page, first enable page content descriptions,then specify the name of the Select Fields field, template to search, and content field. If you create a field description using this method, please note that the description field must be blank for contexts where you want the page content to appear.
      You can freely use template context for field descriptions, but the Page Content method is not context sensitive and will display under all contexts where the description is blank.
      ----
      original post:
      This is a new module, hope to release soon, which allows extended field descriptions, in currently 2 ways.
      The main feature of the module is that you can have a short description and then a 'more...' link which drops down a longer block of text.
      This is achieved by separating the intro/visible text and the rest with 5 dashes.

      Example setup:

      the 2nd way is if you are using AdminThemeUiKit, you can show extended field instructions in a panel. The content of the panel is edited on a regular PW page. This use case would probably not be that common, but if you had a field that required some extended instructions for how to use, this could be useful; Also, since this allows you to target information and instructions down at the field level, it could reduce the amount of documentation needed on a global level, since it is a lot more context targeted.