adrian

Sure that will work, but I still think it's better to create the PDF in a temp directory Also, just an FYI, building the path up using: $path = wire('config')->paths->files . $page->id . '/'; is not ideal. This is better: $page->filesManager()->path() because it handles custom paths just in case you have $config->pagefileSecure set to true, or if you have $config->pagefileExtendedPaths true. But still if you are using a temp dir, then this won't matter anymore

Any chance it has to do with where you are generating the pdf? I would do it in a temp directory first - I think there is likely a conflict with saving it to the assets/files/xxxx folder of the page and then adding it to the same page.

What happens if you save after removeAll(), before you add the new one?

New version just posted today as beta:

Two things stand out to me: Suhosin and suPHP. Neither of which may be the issue, but might be worth investigatng a little. I know that suhosin can be a pain - I used to use it but eventually found I was spending too much time configuring it to extend its limits anyways. As for suPHP - there is this thread: https://processwire.com/talk/topic/6088-cannot-allocate-memory-errors/ We never got a final resolution from the OP, but I did note that the error he was getting was common amongst suPHP users. Is there by chance anything in your error logs that mentions memory errors?

Hi everyone, I have just set up the ability to customize the potocol handler for opening files in your editor directly to the line of error - this is potentially a huge timesaver The new config setting is "Editor Protocol Handler": It is initially configured for SublimeText because that is my editor and I know lots of you also use it. To make things work, grab this free subl:// protocol registering app: https://github.com/saetia/sublime-url-protocol-mac - note the instructions at the bottom if you need to make it work for ST2 instead of ST3. If you're not using ST, there are other ways to set up your own custom protocol handler, but I'l leave you guys to figure that out. Once you have done that you will be able to click on any of the links in errors, dumps, and barBumps and it will open the file in ST to the exact line. Note: the links are to the actual original files, not the PW 3.x compiled versions !

Migrator can definitely do this sort of stuff. It hasn't seen much love of late (although I did just commit a quick patch for a bunch of Notices that I had been ignoring - Tracy made them too hard to ignore). Anyway, I still use the module regularly in my own development and rarely have any problems. I can't imagine working without it when setting up new sections of content for an already live site - just build the fields, templates, and pages in dev and then export/import and you're done. I do always test the import on another dev setup before importing to production as a check. That said I know there are still some issues to be dealt with. However, I have tested it successfully with a multi-language setup and with all the Profields (except Matrix Repeaters) and normal repeaters. I still want to get back to sorting out the last of the bugs, but some have been hard to reproduce. I would be curious to see if it works well for your needs.

Yeah - it sounds like maybe something is hooking into Session::login() I'd grep your site/modules directory for that hook.

Ok, what about getting $user->id and $name after this line: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L440 We know that a $user object is making it into the login function so we need to figure out where it is getting messed up. Maybe it's not passing the: if(is_object($name) && $name instanceof User) { condition for some reason? I hope I am not taking you on a wild goose chase here - this is pretty bizarre - I feel like I am missing something obvious.

I am not surprised that $user is undefined on 436 - it isn't passed to this function. Try echoing $user->id at 453. What about in here: line 505? public function forceLogin($user) { echo $user->id; return $this->login($user, '', true); }

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.