adrian

No - you are experiencing a namespace issue - looks like the function is being defined in the global namespace, but you are calling it from within the ProcessWire namespace.

Not sure what version of PW you are running, but that should work in 3.x. However, try this which should work in all versions. wire('config')->paths->root

The easiest thing with paths is to make use of $config->paths->root. include($config->paths->root.'sendgrid-php/sendgrid-php.php');

A standard php include works fine for me in a hook. Any chance it's a path problem?

Seems like the main problem is that the setKeyAndValidate() method is called on every PW ready(). I just commented that out and load times go back to being normal. I don't know the Tiny API, but I would think it would be possible to either just do this once, the first time the API key is entered, or perhaps if it's needed for each call to Tiny, then it could be called only when one of the hooks is triggered. Perhaps @Roope can take a better look since it's his module.

Any chance you could point us to the module code?

@oma - you can see what @Robin S means here (Tracy Captain Hook panel) - see how $page is the first argument?

Yeah, I was thinking about that, but thought Users::saveReady might be a tiny bit more efficient because it's only called when a user is saved, but it probably doesn't make any different, so perhaps Pages::added with a check for the admin template like you suggested would be better.

Are you using a module that has already been posted here, or your own custom one? I am curious if the slow response is only the first time a page is loaded? I feel like the module should be able to cache compressed versions and only ever have to run the call to the service once.

That approach sounds good to me - very flexible. The only dedicated user hook is: Users::saveReady so you might need to add some logic if you don't want existing users altered when their details are changed. Regarding finding appropriate hooks, take a look at the Captain Hook panel in Tracy: https://processwire.com/blog/posts/introducing-tracy-debugger/#captain-hook-panel It makes it easy to search through classes and methods for things you might need and if you have the editor link protocol set up properly, it will open the file to the class/method you click on.

If you name the roles to match the page names, then it's much simpler: if($user->hasRole($page->parent->name) { //allow access } else { //404 } At least I think that's what you need?

@oma - you will need to somehow define what users/roles have access to which parent pages (and their children - I think that is what you want). You could do as @Sérgio Jardim suggested, or come up with some other approach - perhaps the role's name could include a reference to the allowed parent page - you could even name the roles: property-1, property-2 etc and make that role name to the parent page name to determine if the user is allowed to view the page or not.

My apologies - yes, that's not what you want You still may choose to go with a "you don't have access" message, rather than a 404 - I guess it depends on your use case. Either way, sorry for the confusion

Yeah, that is the gist of it. I would consider carefully the 404 though - you might want to show a login form instead.

No need to remove "view" rights, just do a check at the top of your template file (or in an included file if you need this across your site) which checks the user and determines if they should be able to view the page. If not, then you could redirect them elsewhere. Does that make sense?

I don't really understand still - surely if the PDF script is generating errors that Tracy is reporting, you'd want to know, but maybe there is some weird interaction that is causing problems when there really isn't any. As for providing a way to switch off for some scripts, I just had a try at implementing something, but I don't think it's going to be possible because Tracy is loaded before anything else so that it can catch all errors, but this means that any variable you try to set from a script won't be available when it's time to enable Tracy or not. Does that make sense?

@Roych - are you talking about this module: If so, please see the second post where the problem is explained and a fix provided.

@MilenKo - if you want and it's online somewhere, I can take a look if you PM me login details.

Well in that case, the error is because you didn't put a semi-colon at the end of your bd call

The console is awesome, but it won't have access to $input->post->cite because you haven't submitted the form to the console. That said, I also don't know why you are getting a 500 error. If I run that bd call in the console it just returns null as you would expect because it isn't set. Anymore details on that 500 error? Do other bd calls in the console work ok, eg: bd('test');

I just added: bd($input->post->cite); to the: if ($input->post->submit) { block and it output the name correctly. Where are you putting it? Did you check the browser dev console for info on the 500 error?

I just tested the code you posted last and it works perfectly for me, so not sure what it going on at your end. If you are new to Tracy, have a quick read of the docs: https://processwire.com/blog/posts/introducing-tracy-debugger/#bardump

Did you clarify that the hidden cite form field is being populated with the correct value from $user->name ? In the DB for the comments field, you mention that the cite field getting populated with "admin" - if that is happening, then it's got to be due to the form population or processing and adding of the comment via the API. Do a test debug of the value of $input->post->cite in your code to make sure it is showing "test" and not "admin". Tracy Debugger's bd($input->post->cite) would be the easiest approach to this.

I'd love to know which module was causing the problem

Ok, but when looking at the comment form, is $user->name correctly populating the username of the currently logged in user? What about when you are processing the submission form - are you still using: $c = new Comment(); $c->name = $sanitizer->name($input->post['name']); or did you change this to the correct: $c->cite = $input->post->name('cite'); Note that I am using the $input sanitizer, but the key thing is that I am making use of the POSTed 'cite' field.