adrian

Firstly, this should be sufficient - you don't want to try logging in more then once. $u = $users->get(4930); if ( $u->id ) { $session->forceLogin($u); } The first part of That error message is coming from: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L520 which shows that it is definitely receiving the $name populated as "guest". I realize that isn't what you are passing to it - so I am definitely confused The second part is coming from: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L488 which checks this: $user->id == $this->wire('config')->guestUserPageID I'd love if you could echo out the contents of $name and $user in that login function (starting here: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L435) to see what it is receiving and see if you can figure out at what point in that fuinction it is failing.

If it's just a password generator, then why are you assigning $name to its results? $name = self::passwordGen(); I suggest you start by taking the output of $name and $pass (from that echo line) and in a template file try the login command there to make sure it is working. I would also like to know that the new user is definitely being created and the roles you want are being successfully added. I still keep coming back to that initial error - it suggests to me that the user you are trying to login is "guest" which suggests there is something wrong with $name or $user depending on which you try. It also might be related to overwriting $user - have you tried using $u ?

Well, I don't know what passwordGen() returns so it's a bit hard to tell what's going on. Have you checked the values of $name and $pass right before you try to log them in? Regardless, as I mentioned above, you shouldn't be overwriting $user - try $u or similar. Also, please consider indenting your code here - it's hard to follow like that

It is still tagged as alpha:

Actually I just tested and I can successfully use forceLogin to login a user with just a guest role. The only time I can replicate that error is if I try to login the user named "guest". Keep in mind that: $this->session->forceLogin($user); will try to login the current user in the $user object, which will be the "guest" user. You need to specify the name of the user you are trying to login: $this->session->forceLogin('testuser'); or get the user object first, like: $u = $users->get('testuser'); $this->session->forceLogin($u); Remember it's never a good idea to overwrite $user.

You can't get the password like that and use it to log in - it is encrypted. What you need is: $session->forceLogin($user) Read more about it here: https://processwire.com/blog/posts/processwire-2.6.8-brings-new-version-of-reno-admin-theme-and-more/#new-session-gt-forcelogin-user-method-to-login-user-without-a-password PS Sorry, I see that you already tried the forceLogin option.

The "guest" user can't login - simple as that really That account is just to determine what access all non logged in users have to the site.

@siilak - I agree with mr-fan on your code styling choice - very hard to read That said, what you have there should work just fine. Do you have debugmode on? or Tracy (http://modules.processwire.com/modules/tracy-debugger/) installed? Are you getting any errors? What exactly is the HTML being generated? - can you view source and paste here for us.

Hey @ukyo - sorry about that - please try the latest version and let me know how it goes for you. That was actually some leftover code that wasn't needed anymore

Have you tried turning off (or adjusting) session fingerprinting? Here are the list of options: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/config.php#L195 Obviously add the setting to your site/config.php though.

Glad it's working fine now - please let me know if you come across any other problems with that.

Sorry about the database connection error. There was a problem with some attributes and the PW $database connection, but I have removed those two problem ones and now use $database. Please let me know if it is working properly again now with the latest version. I know about the panel moving issue - some do that weird resizing before they will move. It is on my list of things to take a look at - not sure if it's maybe a core Tracy issue, but I'll try to sort it out regardless.

Some more improvements: Fields List and Values section on the PW Info panel Take a look at the "images" field in the screeshot - much cleaner and more informative. I have populated all the files/images related properties: filename, ext, url, httpUrl, filesize, filesizeStr, width, height, description, etc. Think of it as a cheatsheet with properties and values built right in. I have also added formatted dates and user names in parentheses for reference. Variables Panel I have also recently tweaked the Variables panel to be easier to read and to separate into columns with the variable name, its type, and value: Development Tip One final thing - a bit of a development tip using Tracy - want a quick way to see the results of a PW selector? Try this out in one of your template files: bd($pages->find("template=basic-page")->explode('name')); You will see something like this in your Dumps panel: On a live site in production mode, it pays to do it like this: if($user->isSuperuser()) bd($pages->find("template=basic-page")->explode('name')); This way, even if your selector generates an exception (quite easy to do if you accidentally enter an incorrect field name), no-one but you will see the error.

Ok, the PHP 5.3 issue should be fixed in TracyDebugger and a PR has been submitted for Performance panel as well.

Sorry about that - I already adjusted one short array syntax issue with the Performance panel plugin. I'll take care of that one too - update coming shortly.

I just added the stripTags and also the other missing option: newlineReplacement, to the docs: https://processwire.com/api/variables/sanitizer/#options-that-may-be-provided-to-the-text-and-textarea-functions

Just a bit of a followup here. Have you tried the stripTags option for the textarea sanitizer? echo $sanitizer->textarea('I <span style="color:red"><3</span> ProcessWire', array('stripTags' => false)); That will allow all tags, including <3 to be submitted. Of course I still think the purifier might be a better/safer option, but thought I'd mention in case you didn't know about it. It's actually not listed on the $sanitizer docs page, but you can see it here in the source code: https://github.com/ryancramerdesign/ProcessWire/blob/b95e36a8d3071139bea5ed72b8b5025b876df976/wire/core/Sanitizer.php#L430

Yeah I agree - maybe I need to implement something like this (http://jsfiddle.net/PtskU/) as a new Inputfieldtype in PW. ASM's just don't always cut it.

Thanks for your thoughts @tpr - I am going to take a look at the settings in the next couple of days and clean them up a little. In the meantime, the latest version has some enhancements to the PW Info Panel. In particular, the "Fields List" section has been extended to be "Fields List & Values". It now additionally shows: some key Settings (at the moment just the maxFiles value, but might add some other key ones at some point) the type of value that is returned: object, string, integer, etc the value of the field - which is really nice for easily seeing what properties are available - see the phone_number in the screenshot for a useful example.

strip_tags removes anything after a "<" until the closing ">". If it is never closed, then the rest of the content will be removed. I think the best option might be the purify sanitizer like you are already using. I get the feeling though that the textarea sanitizer should probably replace strip_tags with purify - obviously the way it currently works is not satisfactory because it will also delete <$20 and anything else similar and obviously valid.

Not sure if you read this: http://stackoverflow.com/questions/5055845/php-strip-tags-allow-3-text-hearts As you said, it's not possible to use the allowableTags option of the textarea sanitizer either because it's not actually a real tag. You could convert "<3" to "<3" during your form submission (before you sanitize) and then it will be preserved.

It's not exactly like the HTML fieldset tag, but PW has fieldsetOpen and fieldsetClose field types which you insert into your template to group the fields between them. Same goes for fieldsetTabs - you can actually create new tabs on the top of the edit window - after the Content and before the Settings tab. Is this what you are looking for?

Sorry, I think I might be on a different wavelength to you guys - I already have the ASM for selecting and sorting the panels to be displayed. What other settings do you think would benefit from an ASM options? I honestly don't see it being a useful interface (compared with checkboxes) unless you need to have them sortable, or if there are a LOT of options - such that there are just too many checkboxes. But I am definitely keen to hear which ones you think would be better as ASM. I can definitely see that some collapsed fieldsets could be helpful to organize the settings into related sections - I'll have a think about this and figure out which settings belong together. I do have a habit of getting carried away with too many settings/options - thanks for reigning me in Thanks again for the feedback - we all work and debug differently so it's great to hear what you guys want for this - don't be shy!

I honestly don't know - I just tried replicating your setup with the "new TemplateFile" approach and it's working just fine. Anyway, it sounds like you are not using this, so maybe we don't need to worry about it at the moment