Jump to content

FlorianA

Members
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

11 Good

About FlorianA

  • Rank
    Jr. Member
  • Birthday November 8

Profile Information

  • Gender
    Male
  • Location
    Northern Germany

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've just tried the ForgotPassword module and I wonder why the password reset process can't be smoother for the user. Especially I don't understand why there must be this "verification code" that has to be transfered manually to the password reset form. Why couldn't it be integrated directly into the URL? It shouldn't make any difference as to security since both URL and verification code are transfered through the same channel (e-mail) anyway. I'm planning to migrate my current non-PW site to PW, and since I don't have my user's clear-text passwords, I can't migrate them, too. That means I'll have to force all my users through the password reset procedure, and I really wouldn't like to make this more tedious than necessary. Another feature request: I'd like to confirm the additional field values in the first step (before sending the e-mail) rather than in the last one. I think this would not only improve user experience, but it would also allow to use e-mail rather than user name for identification even if there are duplicate e-mail adresses, since you could use the confirm value field for disambiguation.
  2. Yes, it works indeed 🙂 But I wonder if it's really necessary to reset the 'notify' flag, as it does not belong to the page template but has just been injected into the form by the buildFormContent hook above. I'm lucky enough still finding the field in the Pages::saved hook, but it isn't saved with the page, is it?
  3. I'm just considering, if I should rather hook Pages::saved than ProcessPageEdit::processInput. The advantage is that I can get information about which fields have changed. So I can send the e-mail notification only if some important fields have changed. It seems that I can still access the "notify" value of my checkbox - it is contained by the "changes" parameter exactly if it differs from the default.
  4. Thanks @Robin S for this really nice piece of code. Works out of the box 🙂 One more question: When exactly the ProcessPageEdit::processInput hook is being triggered? I want to be sure that users are notified only after page data really has been saved.
  5. Hi, I would like to extend the (backend) edit form for some pages: Above the "Save" button there should be an additional checkbox "Notify users about changes". If this checkbox is checked, an e-mail notification about the page's changes should be sent to other users. My plans for implementation are the following: Anyhow add a hook on rendering the form and insert a checkbox at the appropriate place. Hook the saving of the form, check the state of the checkbox and send the e-mail, if wanted. However, I'm struggling with the details. Which method should be hooked for step 1? InputFieldForm::render? How can I get the current form data? How can I extend it? Is there already a module which does all this stuff for me? (Not really sending the e-mail but all the hooking stuff, that's a pattern I would like to reuse form something else later.) Thanks in advance for any help.
  6. OK, I've found it out myself now. The trick is to make the field accessible by API. Then you can simply write something like: function getRestrictedProperty($page, $fieldname, $user) { $field = $page->getFields()->get($fieldname); if ($field == null) return ''; return $field->viewable($page, $user) ? $page->get($fieldname) : ''; }
  7. I think a debugger won't help me. I'd just like to retrieve a page property although the corresponding field is not visible by the current user - because it would be visible by another user who has just been "authenticated" by a token.
  8. By the way, what is the easiest way in PW to show a page the same way another user would see it, if he was logged in (including properties only visible by the other user)? Can I use checkAccess=0 in a $page->get() query or something else?
  9. Hi all, thank you for your answers. In the meantime, I also found out how to access the hashed password, though unfortunately the documentation is hidden very well in a comment of the User class source: I still think, using the password hash is a better solution for my calendar than generating a random token: There is no need to implement any storage logic. As soon as the user changes the password, the token will be invalidated automatically. I won't do a force login from the token but only will grant the user's access to some restricted fields in the calendar data. As the security level of this data is not too high, this simple solution should be enough.
  10. Hi, I would like to provide an ICS calendar URL for registered users. However, it should be possible to load this URL without the need to login before, since this would be difficult for many calendar apps. That's why I would like to generate an individual URL for each user which contains a kind of authentication token. An implementation could look like this: The token is an MD5 hash of the user name, his encrypted password and maybe something else. Both user name and token are added to the URL as GET params. When calling the template, a token is calculated from user name parameter and compared to the token parameter. If both are identical, the user will be handled as authenticated. What's the easiest way to implement somethin like this in PW? The exact solution above seems not to be possible, as AFAIK the API doesn't provide access to the encrypted password. But I'm sure there's any existing solution for this in PW or any module 😉
  11. I still found a weird bug after having changed the default language by SQL: The "Language Support - Tabs" module doesn't work correctly any more. It does show the tabs, but on each tab the fields for both languages are shown, too. Does anybody have a clue why this could be?
  12. Thanks a lot for this solution @mscore! I've just switched successfully my default language from English to German by this. The only remaining step seemed to be moving "German" to the first position of "Languages" in the page tree, then I also get the "German" tab at first position when editing a text. I really can't understand why this is no PW default feature yet -- this feature was essential for finishing my site migration to PW, and my fear of wrecking my content by a dirty workaround delayed my project probably by several months!
  13. It does work with dev version 3.0.93 Thanks a lot for your assistance, @adrian
  14. That's a valuable hint. Up to now my concept was to restrict permissions not only for the "hide_year_of_birth" field but also for other more "private" user fields like street or phone numbers. That's why I didn't want to handle this one field by a global permission. But my plans break down anyway if the restricted fields aren't editable any more even for the user's own profile. So I have to look for another solution ... I think it will be something like a "view_extended_user_data" permission which applies not only to the year of birth but also to some other fields.
  15. Tracy Console? ... <google> ... Tracy Debugger ... Wow! What a wonderful tool! I should have discoverd that earlier. I think it would deserve a place on https://processwire.com/docs/tutorials/ Anyway, my problem persists even when trying the command above. My PW version is 3.0.61
×
×
  • Create New...