FlorianA

Hi,

I'd like to add a checkbox ("Notify users about changes") to the user profile editor and, after user has saved his profile and checked this box, send some e-mail notifications about his changes. I'm using a mechanism like that successfully for other pages by using hooks on ProcessPageEdit::buildFormContent and Pages::saved, this also works when editing any "user" page as admin, but it doesn't work when editing the user page via the "Profile" menu item. Is there any hook that can achieve that for profile editing? I've tried ProcessProfile::execute, but I couldn't find a way to get the form's raw data from there.

Sounds logical. And it works with Page Auto Complete. Thank you, @taotoo 👍

Hi all,

on my site, I use one template with a field of type Page/AsmSelect (a single-page template used for site settings). When I try to edit the page of this template, loading of the page editor is extremely slow - I can't do it on the productive server, since the 30-second execution time limit of my provider exceeds.

After removing the Page/AsmSelect field from the template, it works without problems, but as soon as I add it again, the editor becomes slow again - even if the field's value doesn't contain any page references.

Is this a known issue? Should I do anything different? Any help will be appreciated!

Florian

Thanks for your replies.

I've already tried to create the page in advance and redirect the user to the edit URL. The drawback is that the page needs to get a dummy title that has to be overwritten by the user.

@Studio Lambelet, your hook does work, but is it also possible to retrieve the template of the parent page? This would be important for me in order to get a context sensitive message.

Maybe I'll try a third solution with two links in the frontend:

• "Quick upload": User can specify a page title and file to be uploaded in a small form. Page will created without showing backend.
• "Advanced upload": Regular call of the "new page" workflow which allows to specify more than one file and some more fields.

Hi all,

I'd like to have a link in my front-end to add a new page (urls('admin')."page/add/?parent_id=$parentId"). I can't use front-end editing since I'd like to use the drag-and-drop area for uploading files. On the other hand, the back-end workflow with its two steps, defining title and url, then entering the rest, might be a bit confusing for end users. Therefore I'd like to display a kind of help message on the "New Page" page. What is the easiest way to do this? Is there a corresponding hook (couldn't find one)?

14 hours ago, Laikmosh said:

im not getting why are you trying to reference a page on itself, any data that you might get in the reference already exists in the page itself, this is like calling yourself on the phone, could you explain what are you trying to achieve with this?

The field is called "user_visible_by" and says that only users with one of the referenced roles are allowed to see users with the current role. In most cases, users should be allowed to see users with their own roles, but not always, so it is necessary to define if users with a certain role are visible by users with the same role. As a stopgap, I could add a separate checkbox for this, but this won't be so elegant ...

Hi all,

I have defined a Page Reference field for the "role" template with the referenced template being "role", too. Now, when I try to select such a role reference for a certain role page, the currently edited role won't be shown in the selection list. Isn't it possible to define a page reference which refers to the current page itself?

Florian

On 7/3/2021 at 6:02 PM, adrian said:

I'll fix the documentation in a minute, but you you please try the above to confirm it's working for you.

Yes, it works with "roles", thanks. I must have done something wrong with my previous test ...

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 ...

OK, thanks for the link. So I'll use the $_POST variable.

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?

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

On 5/8/2020 at 1:06 PM, horst said:

Summary: When you start a new site and the default not should be english:

...

@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.

On 5/6/2020 at 11:28 AM, horst said:

@FlorianA maybe there is / was a misunderstanding? (I haven't read the thread, only the last posts)

You are able to do:

• sites only in german,
• sites with german as default language, and (multiple) other language(s) added

in ProcessWire with a snip, -- IF you start a new site right with the desired default language. Then your users only have to fill in the german fields, (and only optional other language(s)). 

@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 ?

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.

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) ...

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.

On 8/30/2019 at 6:05 PM, bernhard said:

PPS: I think even this should work:

$wire->addHookAfter('Pages::saved(template=xyz,notify=1)', function($event) {
  $page = $event->arguments(0);

  // send email
  
  // reset checkbox
  $page->setAndSave('notify', 0);
});

 

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?

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.

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.

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:

1. Anyhow add a hook on rendering the form and insert a checkbox at the appropriate place.
2. 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.

On 8/4/2019 at 8:44 PM, FlorianA said:

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.

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) : '';
}

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.

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?

14 hours ago, teppo said:

Actually the API provides access to the hashed password.

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:

Quote

* Additional notes regarding the $user->pass property: 
* Note that when getting, this returns a hashed version of the password, so it is not typically useful to get this property. 
* However, it is useful to set this property if you want to change the password. When you change a password, it is assumed 
* to be the non-hashed/non-encrypted version. ProcessWire will hash it automatically when the user is saved.

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.