Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by FlorianA

  1. Yes, it works with "roles", thanks. I must have done something wrong with my previous test ...
  2. It seems that the "allowed_roles" option does not work for the $page->protect() method. Neither does it show any effect when I try it, nor I could find the string "allowed_roles" in the module's source code. What I've found in source code was an option called "roles", but that doesn't work either ...
  3. OK, thanks for the link. So I'll use the $_POST variable.
  4. Hi all, could it be that input()->post does not cope with multi-dimensional arrays from POST data? Example data (pasted from Firefox network analysis): { "add[91896][]": [ "30227", "30312" ], "add[89364][]": "30430", "nr[91896][30227]": "a", "nr[91896][30312]": "b", "nr[89364][30430]": "c", "nr[91896][30332]": "", ... } My code: print "===add=== "; print_r($_POST['add']); print "===nr=== "; print_r($_POST['nr']); print "===add=== "; print_r(input()->post('add')); print "===nr=== "; print_r(input()->post('nr')); Result: ===add=== Array ( [91896] => Array ( [0] => 30227 [1] => 30312 ) [89364] => Array ( [0] => 30430 ) ) ===nr=== Array ( [91896] => Array ( [30227] => a [30312] => b [30332] => [30389] => [30364] => [30432] => [30208] => [30403] => ) [89364] => Array ( [30430] => c [30332] => [30350] => [30389] => [30384] => [30432] => [30403] => ) ) ===add=== Array ( ) ===nr=== Array ( ) Any ideas what could be wrong?
  5. Am I right to say that your example $start = date('z'); $end = $start + 7; $sevendays = $pages->find("mydatefield.day_of_year>=$start, mydatefield.day_of_year<$end"); doesn't work, if $start is within the last week of December? It won't find pages for January, since day_of_year starts with 1 again. My SQL solution for this would be something like select * from my_table where (DAYOFYEAR(my_date)+366 - DAYOFYEAR(CURDATE())) % 366 < 7 Is there an equivalent PW query solution for this? Thanks, Florian
  6. @horst, thank you very much for your post! Things could be so easy with a good tutorial ๐Ÿ™‚ I think I'll try it this way. However, I've already put a lot of work into my site, but it isn't productive yet, so I think it isn't too late for a clean re-start with new fields and pages.
  7. @horst, that sounds really promising, unfortunatley I don't have a clue how to do this. I've just installed a new site from the ZIP file (master 3.0.148) with the "Multilanguage" site profile, but I couldn't see a possibility to prevent the default language from being English. I couldn't find any documentation about it either. I'll greatly appreciate any hints how to do the snip ๐Ÿ˜‰
  8. Just noticed that I'm still not finished ๐Ÿ˜ญ The field labels and descriptions are still in the wrong language. This cannot be fixed by simple SQL since these values are JSON-encoded in the data column of the fields table ๐Ÿคฎ Maybe I'll try to write a PHP script with a mixture of PW API and raw SQL calls because I'm not familiar enough with PW internals for a cleaner solution. Maybe I already could be finished with the PW port of my site, but this default language issue wastes lots of lots of time ... on the other hand, it seems to be a blocker for me forcing my users to fill in all (English) default language fields if the site's text is by 95% in German.
  9. After some tedious experiments, I finally managed to switch my site's default language from English to German both in frontend and backend. I am reliefed but not satisfied because it was a terrible hack: Starting with @mscore's SQL script, I added a condition to make sure that field texts are only swapped if a translation exists SET s1.data = s1.data123, s1.data123 = s2.data WHERE s1.pages_id = s2.pages_id AND s1.data1019 != ''; Especially important for backend field without translation, otherwise the backend text will get broken. Then, I added some lines in order to update the option names for FieldtypeOptions: UPDATE fieldtype_options s1, fieldtype_options s2 SET s1.title = s1.title123, s1.title123 = s2.title, s1.value = s1.value123, s1.value123 = s2.value WHERE s1.fields_id = s2.fields_id and s1.option_id = s2.option_id; The following statements are necessary for keeping the correct translation files for both languages (let 124 be the page id of the default language): update field_language_files set pages_id = 123 where pages_id = 124; update field_language_files_site set pages_id = 123 where pages_id = 124; Unfortunately, since translation files are stored in the assets, it is also necessary to swap the corresponding asset directory names: files/123 to files/124. The final step is changing the title of the new non-default language ("deutsch" to "english") and the language names respective. I can't understand why there's still no out-of-the-box solution for this use-case, which is IMHO not so unusual. I also would prefer a PW API solution like @gebeer's one, but I couldnt' find out how to iterate over really all stuff I need (including backend) ...
  10. 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.
  11. 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?
  12. 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.
  13. 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.
  14. 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.
  15. 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) : ''; }
  16. 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.
  17. 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?
  18. 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.
  19. 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 ๐Ÿ˜‰
  20. 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?
  21. 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!
  22. It does work with dev version 3.0.93 Thanks a lot for your assistance, @adrian
  23. 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.
  24. 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
  25. For one role I've tried these four cases, none of them filtered out any user with role "foo": !roles=foo roles!=foo !roles.name=foo roles.name!=foo
  • Create New...