getJSON not working when not connected

[Guy Verville]

I am wondering if my problem has a link with the previous bog I wrote about some hours ago...

I have an ajax call to pages. The code is based on:

The only difference is that since I use the TemplateFactoryEngine, I must add an exit() command in the code.

So, in my template file (controller), I wrote this:

if($config->ajax) {
   $json = array(
    'id' => $page->id,
    'title' => $page->title,
    'body' => $page->body,
    'photos' => $photos
  );
  // Output your json
  echo json_encode($json);
  // halt template rendering
  exit();
}else{
  $view->set('photos',$photos);
}

and the AJAX call is made by script:

 $('#menuAlbum li').on('click', function () {
        var url = $(this).find('.chemin').text();
       $.getJSON(url, function (data) {
            if (data) {
                ....

Now the weird part:

When I am logged, everything is fine.

When I am not logged, no data is returned.

($this->halt() does not work in that context)

I receive no error, I checked that the script was running when not logged (the url is retrieved).

How can data can be fetched when logged and not fetched when not logged?

 

 

[horst]

permission differences between guest and superuser

check the settings for the template that you use for the ajax call.

[Guy Verville]

which permission is responsible for that?

[horst]

which template is involved with the ajax call?

does it have a file?

which settings are bound to that template?

[Guy Verville]

Yes, this is a normal template file. The only difference is that this template is placed in a controller folder since I use FactoryTwigEngine.  If I go directly to the page requested, I can see, not logged, the content.

[horst]

hhm, Idon't know that template engine, and how it works. maybe you can debug the user / permissions for the calls? log into a file and compare, if there are any differences between superuser, normal call, ajax call, guest user normal call and ajax call?

 

[Guy Verville]

The strange thing being that no such ajax permission exists. I will try to investigate...

[Guy Verville]

I found the culprit: debug mode. I realized that when the Tracy debugger was on, everything was fine, even not logged. This debugger reroute Processwire debug mode, I presume... So I switch off the debug mode in config.php and voilà!

Remains this bug...

 

[adrian]

I think if turning off debug mode is fixing things then it's a sign that there is an error being returned from the getJson call that you need to debug. Tracy does seem to be suppressing some ajax errors, which is why things work with it on or with debug mode off. I have posted an issue on the core Tracy Github page: https://github.com/nette/tracy/issues/233 - will see what comes of that, but I probably need to do some more testing at my end too.

[adrian]

Some more details on Tracy suppressing these errors - turns out (for me at least) that if you have your browser dev console open, you'll get the error from the ajax call output there, which is actually really nice, but I am hoping that the Tracy guys can get this into the Errors panel on the AJAX bar so there is a still an obvious indicator that there is a problem.

[Guy Verville]

I did checked the browser console, but nothing appeared there. It was completely silent (either in Chrome, Opera or Safari). 

And why removing the PW debug mode gives me the result wanted in every browser? If I had such an error in my json result, why would then the process succeed? Would it be more plausible that the debug mode blocks part of the process?

[adrian]

55 minutes ago, Guy Verville said:

And why removing the PW debug mode gives me the result wanted in every browser? If I had such an error in my json result, why would then the process succeed?

Because with debug mode off PHP notices and warnings aren't reported so they don't corrupt the returned json.

[Guy Verville]

but the returned json works...

anyway. someday, I will be good at programming ;-)

[adrian]

Just now, Guy Verville said:

but the returned json works

Doesn't it only work with debug mode off. Isn't it broken with debug mode on? Or did I misunderstand?

[adrian]

On 11/13/2016 at 6:09 PM, Guy Verville said:

I did checked the browser console, but nothing appeared there. It was completely silent (either in Chrome, Opera or Safari). 

Just occurred to me that that this is probably because you don't have firelogger installed - it is needed for Tracy to send php errors to the console. You can read more about this here: http://processwire.com/blog/posts/introducing-tracy-debugger/#firelog - it is available for both Firefox and Chrome.

[Robin S]

42 minutes ago, adrian said:

it is available for both Firefox and Chrome

Sadly Firelogger for Firefox hasn't been updated since 2013 and isn't compatible with the current version of Firebug.

[adrian]

7 hours ago, Robin S said:

Sadly Firelogger for Firefox hasn't been updated since 2013 and isn't compatible with the current version of Firebug.

Despite the documentation, it actually works for me just fine with the latest version of Firebug. Remember that with Firefox/Firebug it actually logs to the Logger tab rather than the Console tab like it does in Chrome.

Does that work for you?

[Robin S]

6 hours ago, adrian said:

Does that work for you?

It does work! I tried to use Firelogger back when Tracy Debugger was first released and couldn't get it working. Really glad to be able to use that tool now.