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?