gebeer

Have you tried doing a var_dump("hello"); instead of the echo? Depending on your template setup sometimes things that you echo are hidden under some elements and do not show.

@tpr not that I'm aware of. There is nothing special going on after login. User stays on the login page and gets presented with a logout button. In the meantime I made a fresh 2.7.2 stable install, added the custom user template/parent and role just as on the problem-site. I copied over the login logic to the new test install and can login fine. So the problem must be somewhere within other code on that site. I spent hours on debugging and can't seem to find the reason. In Xdebug panel I see that the site hangs for a while at line 61 of wire/core/Fieldgroup.php and then throws the fatal error. My Xdebug call stack is then filled with 10000 lines. Would it help if I made a pastebin with the xdebug call stack, could anyone see from that where the problem lies? EDIT: my member user template has about 20 fields. I tried removing all but the required ones. But the error still persisted. So it is not related to the user fields either. EDIT2: Into the clean install of PW 2.7.2 I imported all fields/templates from the affected site. Created a testuser with the custom member template and can login fine. Something seems screwed with the site that has the problem. Before wasting more hours on debugging the problematic install, I will rather import the content to the new blank install that now has all fields/templates that I need.

I catch the login throttle messages and pass them to a session variable which is displayed on the login page: // login user try { $u = $session->login($username, $pass); } catch(Exception $e) { $session->logout(); // without this line the user will be logged in although the exception is thrown $session->login_error = $e->getMessage(); $session->redirect($pages->get('/login/')->url); } Strange thing is that without the $session->logout(), my login page will show the error message that is thrown by the login throttle but still login the user. Is this intended behaviour?

Hello, my site has users from different timezones logging in to the backend. I have a "timezone" field for each user where I store their timezone string. Now I need to show dates in the backend in the user's timezone. I know I can set timezone for php date calculations with: date_default_timezone_set("Europe/Berlin") for example. In config.php I have $config->timezone = 'America/Phoenix'; as a general setting for that site. Now when a user logs on I want to set the timezone for his session to date_default_timezone_set($user->timezone). Where would be the best place to set this?

Yeah, I never had to raise it above 200 before. When xdebugging the login template it seems like it is going in loops. Makes my head spin. Meanwhile I found that even with the $session->redirect part commented out I get the error (see my EDIT in the OP) while reloading the login page. Then it ppoints to /wire/core/Fieldgroup.php on line 61. EDIT: Now I commented everything out in the login template. When I load the page while the user is still logged in, I get the error again.

Hello, I have a site with users that have a custom user template setup on PW 2.7.2 stable. Custom user template is "member" and role for those users also "member". The site has a frontend dashboard where users can edit their profile, events etc. I can login with this user type to the backend fine and the permission settings are all working. When I login to the frontend, I get this error: "Fatal error: Maximum function nesting level of '10000' reached, aborting! in .../wire/core/Wire.php on line 333"; I already raised the xdebug.max_nesting_level from 1000 to 10000. When I set it to 100000, the server disconnects. I can see that the user gets logged in with $session->login($uname, $pass) before the error is thrown. EDIT: When I reload the login page after the error shows with the now logged in user, I get this error: "Fatal error: Maximum function nesting level of '10000' reached, aborting! in /var/www/utgpw/wire/core/Fieldgroup.php on line 61" But a $session->redirect($dashboard->url) seems to cause the error. If I logon with a test user that has role "member" but the regular user template, I don't get the error and get redirected to the dashboard fine. All the code in my dashboard template is working. Actually, the whole login and dashboard logic for the frontend is copied from another site where it has been working fine for over a year now. So I guess the problem is related to how the custom user templates are handled in the core. My setup for the custom user template has also proven to work without issues in 2 other sites. I have spent hours on debugging already and now I'm lost. Any ideas that point to the cause of this would be much appreciated.

@clsource great resources, thank you @BernhardB thanks for spotting this. I amended my post.

I wrote up a detailed tutorial on how to use this: https://processwire.com/talk/topic/11806-tutorial-building-a-simple-rest-api-in-processwire/

In this tutorial I will cover how to use clsource's REST Helper classes to create a RESTful API endpoint within a PW-powered site and how to connect to it from the outside world with a REST client. This is a quite lengthy tutorial. If you follow all along and make it through to the end, you should get both, a working REST API with ProcessWire and hopefully some more basic understanding how these APIs work. As always with PW, there are many ways you could do this. My way of implementing it and the code examples are loosely based on a real world project that I am working on. Also, this is the first tutorial I am writing, so please bear with me if my instructions and examples are not that clear to understand. And please let me know if something is missing or could be made more clear. The steps covered: create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed at) copy and save the REST Helper classes to your site create a template file and write some logic to receive and process data through our endpoint and send data back to the REST client test the whole setup with a Browser REST Client Addon I will not go into fundamentals and technical details on how RESTful APis are supposed to work. I assume that you have already read up on that and have a basic understanding of the principles behind that technology. Some helpful resources to brush up your knowledge: https://en.wikipedia.org/wiki/Representational_state_transfer http://www.restapitutorial.com/lessons/whatisrest.html The complete pages.php template is attached to this post for copy/paste. Lets get started. 1. create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed) First we need to create some templates and pages in the PW backend to make our REST API accessible from the outside world through an URL (API endpoint). In my example this URL will be: https://mysite.dev/api/pages/ Note the "https" part. While this is not mandatory, I strongly recommend having your API endpoint use the https protocol, for security reasons. Further down in step 3 we will use this URL to create new pages / update and get data of existing pages. Go to your PW test site admin and: create 2 new templates: one is called "api", the other one "pages". For a start, they both have only a title field assigned. Just create the templates. We will create the corresponding files later, when we need them. enable "allow URL segments" for the "pages" template. We will need this later to access data sent by the requests from the client. in the Files tab of the "pages" template check "Disable automatic append of file: _main.php" create a new page under the home page with title, name and template "api" and set it to hidden create a child page for the "api" page with title, name and template "pages" The pagetree should look somewhat like this: Ok, now we're all set up for creating our API endpoint. If you browse to https://mysite.dev/api/pages/ you will most likely get a 404 error or will be redirected to your home page as we do not have a template file yet for the "pages" template. We will add that later in step 3. 2. copy and save the REST Helper classes to your site I have the REST Helper class sitting in site/templates/inc/Rest.php and include it from there. You could save it in any other location within your site/templates folder. I forked clsource's original code to add basic HTTP authentication support. Click here to open my raw gist, copy the contents and save them to /site/templates/inc/Rest.php In the next step we will include this file to make the classes "Rest" and "Request" available to our template file. 3. create a template file and write some logic to receive and process data through our endpoint and send data back to the client This will be the longest and most complex part of the tutorial. But I will try to present it in small, easy to follow chunks. Since we access our API at https://mysite.dev/api/pages/, we need to create a template file called "pages.php" for our "pages" template and save it to /site/templates/pages.php. Go ahead and create this file (if you're lazy, copy the attached file). Now right at the top of pages.php, we start with <?php require_once "./inc/Rest.php"; to include the REST Helper classes. Next, we initialize some variables that we will keep using later on // set vars with the default output $statuscode = 200; $response = []; $header = Rest\Header::mimeType('json'); 3.1 retrieve data with a GET request Now that we have the basics set up, we will next create the code for handling the easiest request type, a GET request. With the GET request we will ask the API to return data for an existing page. To let the API know which page it should return data for, we need to send the page id along with our request. I am attaching the page id as an url segment to the API endpoint. So the URL that the client will use to retrieve data for a page will look like: https://mysite.dev/api/pages/1234 where 1234 is the unique page id. Add following code to pages.php // if we have an urlsegment and it is a numeric string we get data from or update an existing page: handle GET and PUT requests if($input->urlSegment1 && is_numeric($input->urlSegment1)) { $pageId = $input->urlSegment1; // GET request: get data from existing page if(Rest\Request::is('get')) { // get the page for given Id $p = $pages->get($pageId); if($p->id) { $pdata = ["id" => $pageId]; // array for storing page data with added page id $p->of(false); // set output formatting to false before retrieving page data // loop through the page fields and add their names and values to $pdata array foreach($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen) continue; $value = $p->get($field->name); $pdata[$field->name] = $field->type->sleepValue($p, $field, $value); } $response = $pdata; } else { //page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } else { // no url segment: handle POST requests } // render the response and body http_response_code($statuscode); header($header); echo json_encode($response); Lets brake this down: First we check for a numeric url segment which is our $pageId. Then the Rest Request class comes into play and checks what type of request is coming in from the client. For the GET request, we want to return all data that is stored for a page plus the page id. This is all good old PW API code. I am using the $pdata array to store all page data. Then I am handing this array over to the $response variable. This will be used further down to render the JSON response body. If the page does not exist, I am setting an error message for the $response and a status code 404 so the client will know what went wrong. The else statement will later hold our POST request handling. The last 3 lines of code are setting the header and status code for the response and print out the response body that is sent back to the client. You can now browse to https://mysite.dev/api/pages/1 where you should see a JSON string with field names and values of your home page. If you enter a page id which does not exist you should see a JSON string with the error message. Lets move on to updating pages through a PUT request 3.2 update pages with a PUT request Since our API needs to know the id of the page we want to update, we again need to append an id to our endpoint url. In this example we will update the title and name of our homepage. So the request url will be: https://mysite.dev/api/pages/1. For the GET request above, anyone can connect to our API to retrieve page data. For the PUT request this is not a good idea. Thus we will add basic authentication so that only authorized clients can make updates. I use basic HTTP authentication with username and password. In combination with the https protocol this should be fairly safe. To set this up, we need an API key for the password and a username of our choosing. We add the API key in the PW backend: add a new text field "key" and assign it to the "api" template. edit the "api" page, enter your key and save. (I am using 123456 as key for this tutorial) Now add following code right after the if(Rest\Request::is('get')) {...} statement: // PUT request: update data of existing page if(Rest\Request::is('put')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // get the page for given Id $p = $pages->get($pageId); if($p->id) { $p->of(false); $p->title = $sanitizer->text($params["title"]); $p->name = $sanitizer->pageName($params["name"]); $p->save(); $response["success"] = "Page updated successfully"; } else { // page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } Breakdown: We check if the request from the client is a put request. All data that was sent by the client is available through the $params array. The $params array also includes $params["uname"] and $params["upass"] which hold our API user and key. We set API key and user and check if they match with the values that were sent by the client. If they don't match we store an error message to the response body and set the appropriate status code. If authentication went through ok, we get the page via PW API and update the values that were sent in the request body by the client. Then we put out a success message in the response body. If the page does not exist, we send the appropriate response message and status code, just like in the GET request example above. Now you might wonder how the client sends API user/key and new data for updating title and name. This is covered further down in step 4. If you want to test the PUT request right now, head down there and follow the instructions. If not, continue reading on how to setup a POST request for creating new pages. 3.2 create new pages with a POST request Final part of the coding part is creating new pages through our API. For this to work we need to implement a POST request that sends all the data that we need for page creation. We will do this at our endpoint: https://mysite.dev/api/pages/ Paste following code within the else statement that has the comment "// no url segment: handle POST requests": // POST request: create new page if(Rest\Request::is('post')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // create the new page $p = new Page(); $p->template = $sanitizer->text($params["template"]); $p->parent = $pages->get($sanitizer->text($params["parent"])); $p->name = $sanitizer->pageName($params["name"]); $p->title = $sanitizer->text($params["title"]); $p->save(); if($p->id) { $response["success"] = "Page created successfully"; $response["url"] = "https://mysite.dev/api/pages/{$p->id}"; } else { // page does not exist $response["error"] = "Something went wrong"; $statuscode = 404; // just as a dummy. Real error code depends on the type of error. } } } You already know what most of this code is doing (checking authorisation etc.). Here's what is new: We create a page through the PW API and assign it a template, a parent and basic content that was sent by the client. We check if the page has been saved and update our response body array with a success message and the URL that this page will be accessible at through the API for future requests. The client can store this URL for making GET or PUT requests to this page. If you're still reading, you have made it through the hard part of this tutorial. Congratulations. Having our code for reading, updating and creating pages, we now need a way to test the whole scenario. Read on to find out how this can be done. 4. test the whole setup with a Browser REST Client Addon The link in the heading will take you to a place from which you can install the very useful RESTClient addon to your favorite browser. I am using it with Firefox which is still the dev browser of my choice. Open a RESTClient session by clicking the little red square icon in the browsers addon bar. The UI is pretty straightforward and intuitive to use. 4.1 test the GET request Choose Method GET and fill in the URL to our endpoint. If you do not have a SSL setup for testing, just use http://yourrealtestdomain.dev/api/pages/1. If you happen to have a SSL test site with a self signed certificate, you need to point your browser to the URL https://yourrealtestdomain.dev/api/pages/ first in your test browser and add the security exception permanently. Otherwise RESTClient addon won't be able to retrieve data. If you have a test site with a 'real' SSL certificate, everything should be fine with using the https://... URL Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string with data of your page. now change the 1 i the URL to some id that does not exist in your site and hit send again. You should get a 404 Status Code in the Response Headers tab and an error message "{"error":"The page does not exist"}" in the Response Body (Raw) tab. If you get these results, congrats! The GET request is working. For further testing you can save this request through the top menu Favorite Requests->Save Current Request. 4.1 test the PUT request Choose Method PUT and fill in the URL to our endpoint ending with 1 (http://yourrealtestdomain.dev/api/pages/1). In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remember me" and hit Okay. You now should see Content-Type and Authorization headers in the "Headers" panel. Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. As I will update the home page for this example, my JSON reads { "title" : "Newhome", "name" : "newhome" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon. Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page updated successfully"}". Now go to the PW backend and check if title and name of your page have been updated. If yes, congrats again. 4.2 test the POST request Choose Method POST and fill in the URL to our endpoint without any page id (http://yourrealtestdomain.dev/api/pages/). In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remenber me" and hit Okay. You now should see Content-Type and Authorization headers in the "Headers" panel. Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. I will create a new page with template basic-page and parent /about/ for this example, my JSON reads { "template" : "basic-page", "parent" : "/about/", "title" : "New Page created through api", "name" : "newapipage" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon. Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page created successfully","url":"https:\/\/mysite.dev\/api\/pages\/1019"}". Now go to the PW backend and check if title and name of your page have been updated. If yes, you're awesome! Summary By now you have learned how to build a simple REST API with ProcessWire for exchanging data with mobile devices or other websites. Notes I tested this on a fresh PW 2.7.2 stable install with the minimal site profile and can confirm the code is working. If you experience any difficulties in getting this to work for you, let me know and I will try to help. There purposely is quite a lot of repetion in the example code to make it easier to digest. In real life code you might not want to use procedural coding style but rather separate repeating logic out into classes/methods. Also, in life applications you should do more sanity checks for the authentication of clients with the API / for the data that is delivered by the client requests and more solid error handling. I skipped these to make the code shorter. RESTful services are by definition stateless (sessionless). My implementation within PW still opens a new session for each request and I haven't found a way around that yet. If anyone can help out this would be much appreciated. And finally big thanks to clsource for putting the Rest.php classes together. pages.php.zip

Great to have that options array for the save method. I just discovered this when trying to set the modifiedUser of a page. Had to do a google search and read some forum posts until I finally found it here. Would be really great, if this was mentioned in the cheat sheet for http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-save-page/ , http://cheatsheet.processwire.com/page/built-in-methods-reference/page-save/ and http://cheatsheet.processwire.com/page/built-in-methods-reference/page-save-field/

Not yet. I will be working on that project in the new year and get back here with new findings

I can also confirm that the error is gone with 0.0.8 on PW 2.7.0. Thank you very much

SOLVED This was related to the module FieldtypeFontIconPicker. Author ukyo has just released an update that fixes the problem.

I needed to calculate recurrent dates for a project and at that time discovered that there is a PHP DatePeriod class for such type of calculations. It was not so easy for me to get my head around this but I finally came up with a function that is calculating recurrences from start date, end date and an interval. Not the same as your scenario, but maybe it can help to get you started. // DatePeriod calculation taken from http://php.net/manual/de/class.dateperiod.php#109846 function getRecurrences($startTime,$endTime,$interval) { $format = 'Y-m-d H:i'; $start = new DateTime(); $end = new DateTime(); $start->setTimestamp($startTime); // if interval 0 we calculate weekdays and set start = end; $end = ($interval == 0) ? $end->setTimestamp($startTime) : $end->setTimestamp($endTime); // if start and end time are the same, we calculate for weekdays and set endtime to 3 month from starttime $end = ($start == $end) ? $end->modify('+90 days') : $end->modify( '+1 minute' ); // set duration to move on in 1 day steps, if we are calculating timestamps for weekdays $duration = ($interval != 0) ? 'PT' . $interval . 'M' : "P1D"; $interval = new DateInterval($duration); $daterange = new DatePeriod($start, $interval ,$end); return $daterange; } EDIT: After reading carefully through your post again, I am wondering about your interval. You say you let the user define an interval as timestamp. But a timestamp typically is one point in time. So I am wondering how your timestamp looks like for describing a time range? Can you give an example? If you are using something like "+1 day", "+1 week" as an interval, you could use strtotime for your calculations, like $new_timestamp = strtotime('+1 week', time()); // + 1 week from today

@ukyo Thank you for updating your great module. The update is not visible in ProcessUpgrade module so I would have to update manually. Is this intended? My installed version is 0.0.7. Your github commit message for the module file itself says "FontAwesome updated to 4.4.0 and module updated to 0.0.7". Shouldn't this be updated to 0.0.8 so that the ProcessUpgrade module can know that a new version is available?

@modifiedcontent I am assuming you want to do this on the frontend of your website? in post #3 you can find the basic code that you need to create a user and the profile page for that user from the API side. In that code the profile page is created before the user page and the author uses to link the 2 pages together by the username which is unique and that should be ok. I'd suggest to first create the user and then the profile page and make the profile page owned by the user. I use this code to create user and profile page // sanitize input $uname = $sanitizer->pageName($registrationForm->get("uname")->value); $email = $sanitizer->email($registrationForm->get("regemail")->value); $fullname = $sanitizer->text($registrationForm->get("name")->value); $pass = $registrationForm->get("pass")->value; $timezone = $sanitizer->text($registrationForm->get("timezone")->value); // create new user $u = new User(); $u->name = $uname; $u->email = $email; $u->pass = $pass; $u->addRole("frontend"); // the specific role that you defined $u->save(); // create profile page $user = $users->get($uname); // get the user $users->setCurrentUser($user); // set the user as current user so he will own the profilepage $uid = $user->id; $p = new Page(); // new page is created and owned by the currently set user // set the template and parent (required) $p->template = $templates->get("userprofile"); // your user profile template $p->parent = $pages->get("/profile"); // the parent page for the user profiles // populate the page's fields with sanitized data $p->title = $uname; $p->name = $uname . "-" . $uid; // just to be sure that the name is unique $p->fullname = $fullname; $p->timezone = $timezone; $p->save(); Now the profile page is owned by the user. To make it only editable by that user, in your profile page template you can implement something like this (assuming the user is logged in) if($page->created_users_id != $user->id) { echo "You are not allowed to edit this resource"; } else { // render the user profile edit form } Above solution is kind of outdated. Because since PW 2.5.14 you can create alternate user templates with Multiple templates or parents for users that contain your custom fields. You can use these as userprofile pages. I'd recommend using these as they are easier to maintain with less code.

That helped, thank you! EDIT: For security reasons I don't post my solution here.

Hello, I am trying to get the cleartext password in a hook on saveReady in an autoload module. But I get the already hashed value of the password: Session: pass: L1/CERxHKqXJCJkogk89O48b4bMnsqW What I have protected $templates = ["user", "server"]; public function init() { $this->pages->addHookAfter('saveReady', $this, 'hookSaveReady'); } public function hookSaveReady(HookEvent $event) { $page = $event->arguments[0]; if($page->isNew) return; if(!in_array($page->template, $this->templates)) return; if($page instanceof User) $this->collectUserData($page); } public function collectUserData($page) { foreach ($page->fields as $field) { /*if( $page->isChanged($field) ) */$this->message($field->name . ": " . $page->$field); } } I guess I am hooking too late in the process but have no idea where to place the hook instead. EDIT: same with addHookBefore

I' m not quite sure what you mean by reports. I am using Lister Pro to show all the signup pages that were stored for the events. They can then be filtered and sorted by event, by signup date etc. Possibilities are almost endless and depend on your specific scenario. It is definitely worth reading up on what Lister Pro can do. In particular interesting are the lister pro actions. You can export lists to CSV and more. This might sound like I am advertising the module here. And, hell yeah, I do because I find lister pro really useful and well worth the money

@LostKobraKai Wouldn't you actually need window.onload or $(window).load for that? $(document).ready fires when the DOM is ready and does not wait for all resources like scripts/images. See here and here.

I made an events page with PW where users can sign up for events. Every signup is stored as a page in PW. Reports for events/attendees can be managed through Lister Pro. You could code your own Action for Lister Pro without too much hassle for sending out group reminders/confirmation.

Hi BernhardB, I have a small module that injects a script tag right before </body>. Here's the relevant lines public function init() { $this->addHookAfter('Page::render', $this, 'addInlineScript'); } public function addInlineScript($event) { $page = $event->object; if ($page->template->name !== "admin" && $page->inlineScript) { $event->return = str_replace("</body>", $page->inlineScript . "</body>", $event->return); } } You can adjust that to your situation. Hope it helps.

Frontend members area is no problem at all with PW. You just need to build the login logic via API. I built this with no prior experience with help from the forum. Now there is also a module out there: http://modules.processwire.com/modules/frontend-user/ And this thread is worth reading. Going on from there you either use Form Builder for your forms or you create them via the API and do validation etc yourself. As for the paypal integration, I have no experience myself. But you may find some useful info/code here: https://processwire.com/talk/topic/5281-paypal-payment-method-for-processwire-shop/

I had this issue once with a client site for a photographer. It turned out to be a color profile issue, like mentioned by elabx. Converting images to sRGB before upload solved it for me.

Am I on the right path at all when I try and replace the ___setPass($value) method so that it sets $this->data['hash'] = $value (value that gets passed in to the method)?