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

There are some more lines like the changed one. So is it the same line or another?

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 bernhard
      @Sergio asked about the pdf creation process in the showcase thread about my 360° feedback/survey tool and so I went ahead and set my little pdf helper module to public:
       
      Download & Docs: https://gitlab.com/baumrock/RockPdf
       
      You can combine it easily with RockReplacer: 
       
    • By Soma
      LogMaintenance
      A simple ProcessWire module to give some maintenance control over log files. I found myself often having lots of log files for different things that can grow more or less quickly to a size where they can be difficult to maintain. The built in Logger of PW does a good job of giving you the possibility to delete or prune logs. But it has to be done manually and sometimes a log grows into millions of lines, which makes it often impossible to even prune it as it's too large.
      LogMaintenance uses LazyCron to run the maintenance task and there's several settings you can setup on a global or per log basis.
      Archive: will create zip files for each log file in logs/archive/ folder and add the log each time the maintenance is run to a subfolder containing the datetime.
      Lines: keeps logs to a certain number of lines 
      Days: keeps the log to a certain number of days
      Bytes: keeps the log to a certain amount of bytes
      Each setting is checked from top down, the first setting to contain something is used. So if you check the "Archive" option, all other settings are ignored and logs are archived everytime the LazyCron is executed. If you want to keep your logs to a certain amount of bytes just leave all other settings to 0 or blank.
      Per Log Settings
      There's a textarea that you can use to setup a config for a specific log file one per line. All the logs you define here ignore the global settings above. The syntax for the settings is:
      logname:[archive]:[lines]:[days]:[bytes] 
      errors:1:0:0:0 // would archive the errors log messages:0:10000:0:0 // will prune the errors log to 10000 lines  
      The module can be found on github for you to check out. It's still fresh and I'm currently testing.
      https://github.com/somatonic/LogMaintenance
    • By teppo
      Fieldtype Page IDs is a third party Fieldtype that, simply put, stores Page references as integers (Page IDs).
      This fieldtype was built as a quick and dirty workaround for Page Reference fields' inability handle self-references due to circular reference issues. A project I've been working on for a while now includes a combination of RepeaterMatrix content blocks and tagging/categorization system that would've resulted in a lot of duplicate pages (and plenty of unnecessary manual work for content editors) had I used built-in Page Reference fields, and thus a new Fieldtype felt like the most sensible approach.
      Fieldtype Page IDs was designed to be loosely compatible with Page References in order to make conversions between the two feasible, but it is quite limited feature wise:
      largely due to the fact that stored values are actually just integers with no connection to Pages whatsoever some advanced selectors and related features are not supported, and page values can't be directly accessed configuration settings are limited to the bare essentials (selector string and Inputfield class) only a handful of Inputfields (AsmSelect, Checkboxes, Text) are (currently) supported Anyway, in case you need to store Page IDs (and Page IDs only) and are happy with the limitations mentioned above, feel free to give this Fieldtype a try. It has been working fine for me in one particular project, but hasn't been tested that much, so please tread carefully – and let me know if you run into any issues.
      GitHub repository: https://github.com/teppokoivula/FieldtypePageIDs
      Modules directory: https://modules.processwire.com/modules/fieldtype-page-ids/
    • By daniels
      This is a lightweight alternative to other newsletter & newsletter-subscription modules.
      You can find the Module in the Modules directory and on Github
      It can subscribe, update, unsubscribe & delete a user in a list in Mailchimp with MailChimp API 3.0. It does not provide any forms or validation, so you can feel free to use your own. To protect your users, it does not save any user data in logs or sends them to an admin.
      This module fits your needs if you...
      ...use Mailchimp as your newsletter / email-automation tool ...want to let users subscribe to your newsletter on your website ...want to use your own form, validation and messages (with or without the wire forms) ...don't want any personal user data saved in any way in your ProcessWire environment (cf. EU data regulation terms) ...like to subscribe, update, unsubscribe or delete users to/from different lists ...like the Mailchimp UI for creating / sending / reviewing email campaigns *I have only tested it with PHP 7.x so far, so use on owners risk
      EDIT:
      I've updated the module to 0.0.4. I removed the instructions from this forum, so I don't have to maintain it on multiple places. Just checkout the readme on github 🙂
      If you have questions or like to contribute, just post a reply or create an issue or pr on github. 
    • By bernhard
      WHY?
      This module was built to fill the gap between simple $pages->find() operations and complex SQL queries.
      The problem with $pages->find() is that it loads all pages into memory and that can be a problem when querying multiple thousands of pages. Even $pages->findMany() loads all pages into memory and therefore is a lot slower than regular SQL.
      The problem with SQL on the other hand is, that the queries are quite complex to build. All fields are separate tables, some repeatable fields use multiple rows for their content that belong to only one single page, you always need to check for the page status (which is not necessary on regular find() operations and therefore nobody is used to that).
      In short: It is far too much work to efficiently and easily get an array of data based on PW pages and fields and I need that a lot for my RockGrid module to build all kinds of tabular data.

      Basic Usage

       
      Docs & Download
      https://modules.processwire.com/modules/rock-finder/
      https://gitlab.com/baumrock/RockFinder/tree/master
       
      Changelog
      180528, v1.0.4 add custom select statement option 180516 change sql query method, bump version to 1.0.0 180515 multilang bugfix 180513 beta release <180513 preview/discussion took place here: https://processwire.com/talk/topic/18983-rocksqlfinder-highly-efficient-and-flexible-sql-finder-module/