Jump to content

krisj

Members
  • Posts

    82
  • Joined

  • Last visited

Posts posted by krisj

  1. 2 hours ago, Martijn Geerts said:

    To be fair I haven't test this field with together with a matrix field on the page or within a matrix field. 

    Is the Issue in the Admin, or in the front-end, doesn't it return anything or something else?

    Can you tell me more about your specific issue ?

    Ah, sorry, I was very succinct.

    The problem was in the back end when used within repeater matrix and default value was not provided. When I sorted that I think it wasn't giving me the functionality I was after anyway so I ended up just nesting another repeater matrix within the main one.

    I will try again later and report back with some more detail if I can.

    • Like 1
  2. OK found it - /wire/templates-admin/scripts/inputfields.js

    line 1015

    It is already in the core! The way you enable it is by having $config->debug = true;

    of course it would be nice to have it optionally on when debug is off too as I find it very useful.

    https://github.com/rolandtoth/AdminOnSteroids uses its variation too but to enable just this little thing thats already part of the core AOS is a bit of an overkill to say the least..

    • Like 1
  3. 12 hours ago, Outcydaz said:

    @krisj I've tried this solution and the colorpicker still does not work in a repeater or repeater matrix. Is there something else i'm misssing?

    what errors are you getting in the JS console? I don't have time to look into it but that was what made it work for me. Probably not initialising the jQuery stuff in the right place...

  4. On 7/20/2016 at 11:35 AM, hheyne said:

    Hi Teppo, I have the same problem as Joss. I use version 2.7.2 of ProcessWire. When I don't use the modul pw sends mails. If I use swiftmailer from the api it works. But when I try to send a testmail it says 0 receipients and it sends nothing. Any hints?

    Edit:
    I tried just Wire Mail SMTP. With that modul everything seems to work as expected. I'm using uberspace.de as hosting provider.

    In my experience Wire Mail SMTP works better too. And here is an observation in general:

    If you are sending emails via PHP, I would highly recommend using SMTP methods where possible as every single email provider is cracking down on spammers to the point where messages that are not sent using a real MTA (real SMTP server) are having much harder time to comply. There are hundreds of parameters that are tested against and if you email does not conform to the ever growing technical specification (not just the message and envelope itself but also the path with all IPs involved) it simply goes into junk or lately even worse - gets rejected or sent to dev>null

    What would be wise here from the email module developers side would be to actually build some sort of a queue mechanism where connection timeouts/rejections are caught and the admin can be either notified via a 3rd party messaging or at least logged/saved for a redelivery option later on. For example if issue gets resolved with some IP blacklist situation or whatnot.

    Cloud based delivery solutions (eg Mandrill etc.) are starting to look more appealing..

    my 2c

    • Like 1
  5. In case someone stumbles upon this here is a solution to a IFRAME embedded PW based site with Internet Explorer as user client.

    In a true style of the most hated browser ever it will potentially throw you a curb ball when dealing with authentication, form submission etc. It is to do with IE security enforcements and session cookies. So you might want to try this in addition to CSRF and sessionFingerprint settings:

    in your .php add

    header('P3P: CP="NOI ADM DEV COM NAV OUR STP"');

    or your markup add:

    <meta http-equiv="P3P" content='CP="NOI ADM DEV PSAi COM NAV OUR OTR STP IND DEM"' />

    if you care about the details just Google it.

    Long story short IE seems to be the only browser that enforces an old, largely defunct standard that never took off.

    enjoy!

    • Like 1
  6. 2 hours ago, Beluga said:

    Note that I don't use that solution anymore, but pwFoo's simpler solution.

    probably makes sense in your case. I still need the user welcome email functionality provided by the EmailNewUser module. e.g. it uses the same template for api and manually created users as well as "resend" functionality which is handy.

    and only takes 1 short line of code to make it work with the FrontendUser.

     

  7. On 7/20/2015 at 4:28 PM, Beluga said:

    Thanks! Setting autoload to true actually didn't work, but it is simply enough for me to put this in my register.php:

    
    $modules->get('EmailAdminNewUser');

    Now I will get admin emails for users that have registered!

    Thanks for this @Beluga I had to use 

    $modules->get('EmailNewUser');

    in my register.php instead. But it works with the FrontendUser now. Very useful module @adrian!

    • Like 3
  8. 11 minutes ago, cstevensjr said:

    @krisj, You may want to post this information in the support forum for that Module.

     

     

    Thank you for the suggestion @cstevensjr :P 

    1 hour ago, krisj said:

    so theEmail New User does not want to work with FronendUser registration... even though the "send automatic email" is turned on... head scratch in progress....

    so here is the solution from that thread (

    )

    except it needs to be:

    $modules->get('EmailNewUser');

    problem solved....

  9. 5 hours ago, mr-fan said:

    Is this module an option?

     

    yes this would work as a final welcome message indeed.

    There are however scenarios (we have a project right now that keeps changing goalpost as they are realising the data structure is different than they originally thought) where there might be other tokens/IDs needed as a means to identify the invitee before they are allowed to register. Sometimes without email. Say manually distributed invite.

  10. 19 hours ago, pwFoo said:

    I created the pre register validation module because I don't like unused / bot created accounts ;)

    Email address based invite needs an database to save the token generated to the email address. So it's more complex. Sometime an invited user don't want to use the invited email address. So... just send an invite token which allows the user to register an account?

     

    the pre-register works really nicely I have to say, keeps the user table clean.

    Regards to the invite system  - it could be any other identification info really. There are many scenarios where an organisation could be send say 10 x different "Keys/tokens" to distribute to their own users, that would be a "single use" key/token to register an account for example.

    I wonder if you would track this in a separate table or just use an extra field in PW User?

    sounds like a fu module using hooks no?

  11. 56 minutes ago, loukote said:

    Krisj,

    Do you have their email addresses? If so, could you enter random passwords and tell them to click the "Forgot password" button?

    (that's how I approached it recently, no issues reported)

     

     

    I thought about hacking something based on forgot pass functionality. But I need to manage the messaging etc. Nice idea though.

  12. pwFoo, how would you handle a scenario where the registration process has to check for a scenario where:

    • only existing users can register
    • they still have to verify the email they are entering via email-token-submit process
    • they still have to pick a password

    so essentially we would have all the "potential/invited" users already in the PW entered as generic usernames with specific emails and then using the frontenduser module to just "activate" these accounts. An invite only system basically..

    look forward to any ideas.

    many thanks

  13. In case someone is wondering about the PW 3.0.22 new password field functionality ( InputfieldPasswordComplexify ) compatibility, this is what you will need in the <head>...

    <link type="text/css" href="/wire/templates-admin/styles/font-awesome/css/font-awesome.min.css?v=17j" rel="stylesheet">
    <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldPassword/complexify/jquery.complexify.min.js"></script>
    <script type="text/javascript" src="/wire/modules/Inputfield/InputfieldPassword/complexify/jquery.complexify.banlist.js"></script>
    <script type="text/javascript" src="/wire/modules/Jquery/JqueryCore/xregexp.js?v=1466417387"></script>
    <script src="/wire/modules/Inputfield/InputfieldPassword/InputfieldPassword.min.js?v=101-1466417387"></script>

     

    • Like 6
  14. Very chuffed that it only took a minute to figure out... so here you are a way to quickly change the appearance (by adding your own class programmatically) of the register submit button:

    $fu->form->fhSubmitBtn->attr('class', 'first-class-name another-cool-class another-amazing-thing-the-button-does green-button massive-button');
    

    do you have a quick overview of what form elements are available as built in by the way? Not that I don't like codegazeing...

    • Like 1
  15. On another note, how about a slightly deeper refactoring and adding something like a stepped form option...

    some examples:

    http://thecodeplayer.com/walkthrough/jquery-multi-step-form-with-progress-bar

    http://www.jquery-steps.com/Examples

    It would be nice to keep it decoupled from the markup as much as possible of course...

    I think it would not take too much work but would be nice..

    e.g. simple example like this:

    1 - enter name & email

    2 - instruction to check email, click on the link/copy token

    3 - greetings/congratulations/more instructions screen

    It is already possible but you could add a bit more support if you have time

×
×
  • Create New...