Thor

Well, only me will have access to the admin side. And since there is a superuser role built into PW (which you can't delete) would it not better to instruct it by role instead of page edit? Like, "superuser" allow, everyone else deny redirecting to another page. Just asking because maybe in the future, you want a user role that has page-edit permissions for another page (not admin.php).

Yes, they only see the Continue page as now, but I don't like them to see anything at all, not even that its ProcessWire. I guess editing the admin page would be the quickest way, thank you. I see you used the page-edit as a variable check before redirection. Isn't it better to test the role group? Like if not super admin or administrator, then redirect?

Is there a way I can restrict the admin backend only to administrators? I changed it to a random name so users can't access it by mistake but there certainly should be a better way. I noticed that if I'm logged as a user, I can access the admin side and change profile, view pages, etc. I don't want this, even without permissions, they can still view it, and while I do want users to be able to change their username and password in the future, I think I would be better off creating a template page just for those functions rather than allowing them to access the admin side.

Thank you, I will then.

Thank's Rick. I will research that. Is that production ready or just for debugging?

If put the username no 500 error anymore. But of course, just like with all my other tests, no data is saved to the field. So I tried another field before giving up, and it worked. Thanks! I have no idea what it's not working with the my_planet field. I tested one that just receives integers with a number and it worked in my first try. Maybe some permission problem? I can't find anything in the logs. Just one question. Is this required in the code? $u->of(false);

Ok, tried this instead: $u = $users->get("username"); $u->of(false); // http://cheatsheet.processwire.com/page/built-in-methods-reference/page-setoutputformatting-true-false/ $u->my_planet = "mars"; $u->save(); Same error 500 with your code. No difference. Logs in the admin side say: (line 387 of /home/example/public_html/wire/core/PagesEditor.php) Yes, the field is added to the template. And yes, I'm loading the page logged as the user from another browser.

Do you mean this? $u->of(false); // http://cheatsheet.processwire.com/page/built-in-methods-reference/page-setoutputformatting-true-false/ $u->name = "whatever"; $u->save(); It gives me a 500 errors. I can pull data out of my field. But I cannot save anything to it.

Does nothing. No errors. I also check the table in the MySQL database and nothing is saved.

This would be cool, while Ryan answered some here about auto login a user: That is not really very secure at all or practical. What would be cool is a module that can generate a temporary token that when executed with a page can temporarily and automatically log any user (except admin) into PW without asking for a password. This would be helpful for people that need to interconnect or bridge platforms. Example, a secure secret API page is called with PW. PW generates a token back to that system that requested it. (the page can be restricted by login and IP or both so only the authorized system can call it) This token can now use to call am auto login template file that will log in automatically any specified user passed to it. This can be done with hashing as well and of course encoding everything in the url so the user ID is not exposed. The token expires after the user has logged in immediately or if not after XX time. Another one has to be generated for another login.

Ok, it seems PW does indeed relate data only to the logged user. So my main question here is solved. I tested this several times now, and it works as expected. Example, I can get my user data field and with this code it will restrict only to the particular user logged in: $planet = $user->my_planet; echo $planet; Perfect But for the hell of me, I have tried every possible combination for 1 hour now, and I cannot find how to do the reserve. Save data !!! This does not work and I tried multiple combinations now or 10 or 20 different arrangements: $user->my_planet = "mars"; $user->save('my_planet'); $user->save(); Or $value = "mars"; $page->my_planet->($value); $page->save(); Why is it so hard to find this information? Everything I can find is related to people making forms or saving with forms and I just want something simple to test and learn. Not create a full form yet. I want to understand how to save the data to a field when the user is logged on or at least manually specify the user (if I run as another user that needs to save data to another user). Then if it works, try with sanitization. I have read the API and docs several times and not one single example. At least everything I try fails. No data is saved to my field when I run as the logged in user.

Looks good to me. What page do you want to restrict exactly? The one that processes the form? Two quick ideas come to my mind, restrict by IP the specific page (use your server IP or 127.0.0.1) or check the referer if it's coming from the previous page. That way, the page can't be accessed directly by the public but only through the form. Another more clean and elegant way is to use the permission/groups with PW and make the form submit like logged as that user, but I'm also new to PW so I don't know exactly about that.

Sounds good. So a better proposal is to just use live data for developing and stop emails out? I guess that could work, then before doing some dev, you just copy your production DB to the dev first, so you have an environment as close as possible. Make all your dev, and then merge changes back. That would keep the changes to merge and apply from dev to production to a minimal. Also instead of intercepting emails, another way would be just to alter the email formats on the sync/transfer process. Example changing all emails from account@example.com to account-example.com or similar. That would make all emails out as invalid as well or better, replace all of them with an all catch in the address in your domain like changing account@example.com to account-example.com@yourdomain.com I think that approach would be better just to be sure because the module you mentioned is only for emails using the WireMail function. So if you have PHP code that does its own email sending, or any other form or system sending emails mixed up or made up on PW templates, that module would not work.

Yeah, I forgot the config file, you are right, I will take a note as the dev has different settings and logins of course. So basically that means having a live copy? Sounds great! I actually did this just an hour ago, and indeed, my other site is an exact copy. But it's just a few pages and test data, so it was not a problem. Now with live data in the future. I don't think that would be a big problem unless you let users create tables and fields on your live site. Let me explain why (and please correct me if I'm wrong). Unless you change fields name by renaming them which you created before, which is not something people usually (and PW even warns about that regarding data loss) from the short time I tested the software it seems it creates a new ID and tables for everything. So it's very unlikely you will end up with the same ID for a new field, page, user, etc. If you just copy the dev DB to the live DB then, of course, that would overwrite everything, including your production data but that is not how I would do it. I would compare the DB and tables and just merge the differences (the dev would usually have the new stuff but no data). And differences would just be the new fields, pages, etc. which don't exist yet on the live DB, so there would be no data there to overwrite there. Maybe I'm wrong, but PW creates a new table for fields, so those will not exist in the live site yet. Now, if you let users create pages and other things, then you are probably right, and I see how that can create a conflict. In that case, maybe you can do the opposite before starting developing. Copy the production BD over to the Dev DB so you have a similar match. Personally, I never did that because I'm always afraid of using real users data with testing sites, in case it emails them something for example while I'm testing to a real customer with a real email. So usually I just use dummy data on my dev installations. This is what I use for databases in case someone is wondering: http://sqlyogkb.webyog.com/category/290-database-synchronization

So I just cloned my testing PW installation to a second live server to keep things clean after a few days of testing PW (yes, I'm convinced with the software ) So I can properly test and code in the development environment. But I was wondering since PW stores everything into the database (pages, fields, others). Besides transferring or merging the database is there something else I should take into account when I need to move changes from staging to production? I will just sync/merge the database so all the fields and data appear on the live site after I make some changes. Or are there specific things that PW will write or save to the disk regarding config that I should also be aware? When I mean transferring, I only refer to the /site folder and MySQL database. Not the wire folder which I will never touch as instructed on the documentation except for upgrades. To resume, if I transfer the site folder, and database, all the new fields, settings, and changes should appear on the live site correct?

Hi, I'm new to PW and I'm looking to buy the Form Builder module, but I can't find in the description/sales page if the form builder supports the pattern feature that text fields have with PW. Does the form builder allow for pattern/regex checking on data submission? I ask this for sanitization and security reasons when users submit data with forms created with the form builder module. I was not able to find this information from the description and images. Also, is it possible to do the following with form builder? 1. Users posts data (cross post to another place or just to something else in your PHP code template) 2. Form waits for the result of your PHP action, error or success. 3. If success, saves data to database otherwise fails to error. Basically what I need is for users to submit data to the database, but first I need to execute some action with the data and depending on that result it should be saved or not to the DB.

Thanks, Rick. I will try to do some testing with what you mentioned. It seems pages is the way to go.

Thanks, I also found this: It seems from reading what most people do is actually create a unique page for each user and restrict it to that user only. Sounds a bit messy but maybe that is the way to go. I will try to find some tutorial or example for users submitted data, as most are just very general explaining how PW works, and how the role, permissions work but for all users. None is actually talking about protecting users submitted data from other users in PW (excluding admins of course...). Sanitization is something I'm aware. I will add some data myself and some data will be added by users. The only concern I have is to make sure that one user is not able to hack or manipulate the system and try to access data from another user.

Thank you, Rick, this seems to be the clearest response so far. So matching the author ID to the page is one way? I will research that. Thanks. That is what I was asking. Let me clarify for everyone; I know how the page/role permission works but the last granular way is per user data. So, the guest has Read access to everything. Home has to be accessible, I redirected home to a login and used an include for all other templates, so they require login. So no pages can be accessed by guest now. Done. And I restricted some pages per roles, assigning test users to those roles. Also done. But Roles gives access to all users assigned to that role. That was also clear from the beginning, but the last step higher permission system is PER user data. This means that even users in the same role, and accessing the same page and same fields, can only get data that belongs to them. I think some are just creating unique pages for each user, but even so, you need to have some code somewhere (if PW does not do this by default) to make sure only that user can load his content. Otherwise, someone that also has that role can load the page manually. To clarify, I was asking if PW had a build in feature to link submitted data only to the user sending the data, or this has to be coded somehow or used with a module? I imagine this is something built in, but I could be wrong. Something that checks the user ID and then links all submitted data for those fields only to that user ID. So the $author seems one way to do it. Any other way? Should I also be looking at this? http://modules.processwire.com/modules/page-edit-field-permission/

I already know that. But the profile was just an example I made. I'm not actually asking here for the profile data of a user, but any data. This means any custom data and fields I create, or the user submits, if that will be unique to that user only or it will be just general data.

Wow, great. Didn't saw that yet. I guess that solves it both ways Thank you!

So the $user variable tells PW that piece of the data belongs only to that user forcing only that user (besides admin) to be able to retrieve it? What you mentioned is exactly what I want to avoid. Example, using page ID for each user, I don't want someone loading the ID of another user and pulling out his data. Assuming you use pages to store users data like /profile/user/1, /profile/user/2. Do I make sense? Sorry but I don't know PW enough. Yet...

Well, I purchased that IDE a month ago and so far its works great with everything I throw at it. It's a bit slow and laggy sometimes, but the features are unmatched by any other IDE it seems. I'm new to PW so I can't comment on how well it will integrate. I will surely be interested in this as well.

Good to know. Maybe this should be clarified somewhere in the admin side or docs. While I already imagined this (pattern works on users input, but not when using the API directly in your code), I can imagine that some people will make the mistake of assuming it works with the API as well. And get data with GET or POST from another system thinking that PW is going to validate the data now and it's secure when it's not the case. So great to read this post and that you are still required to make your own server-side validation if the user is not directly submitting the data. Using the API, of course, its assumed its safe and validated as users can't tamper with server/file code, but more than one person probably thinks the pattern/regex validation works globally in PW.

I purchased PHPStorm a month ago. It would be great if someone could post some tricks or hacks on how to integrate it with the PW API, so you can just use PW code directly without having to copy and paste from the reference site. I'm new with both, so anything that helps it's a nice addition. Both PHPstorm and ProcessWire seem to match great together and while PHPStorm has support for some frameworks out of the box, PW would be a great addition.