Welcome Guest, Not a member yet? Register   Sign In
How to enable debug toolbar in CI4.0.0-rc.3
#11

(11-17-2019, 06:07 AM)andaru.ru Wrote: Just rename env file to .env & change # CI_ENVIRONMENT = production to CI_ENVIRONMENT = development (Delete #)
Yes I tried this way only, but still it is not getting displayed.
Reply
#12

Adding

Code:
SetEnv CI_ENVIRONMENT development

should fix the problem. Make sure .htaccess is allowed in your apache configuration.
Reply
#13

(11-18-2019, 03:26 AM)engel Wrote: Adding

Code:
SetEnv CI_ENVIRONMENT development

should fix the problem. Make sure .htaccess is allowed in your apache configuration.
I tried this one, enviroment do get set to development but I can not see debug toolbar or its icon.
Reply
#14

@engel What version of the framework are you using? There have been some toolbar bugs fixed since the last release, and some major issues fixed in the RCs before that.
Reply
#15

Issue is not to set environment, it is already set to development and that is working fine, issue is debug toolbar is not getting displayed on development environment.
Reply
#16

(11-15-2019, 09:11 AM)hbonds Wrote: I have set environment to development through .htaccess file using code

Code:
SetEnv CI_ENVIRONMENT development

environment is successfully set to development, but I am still not able to see debug toolbar.
How can I see debug toolbar on application?


Hi,

Did this question ever get resolved?

I had a similar experience today... the debug toolbar was working, and then disappeared whilst I was busy, but I didn't immediately notice it was gone.

I checked all the ENVIRONMENT settings, and even tried to stick additional extra-double-triple-sure settings in all the places mentioned in this post, and a few other places too (even though the ENVIRONMENT was initially only set in the .ENV file, which had worked- and still does for me- without a problem).

I could even tell when exactly the toolbar had ceased functioning (the logs in \writable\debugbar folder stopped, whereas the general \writable\logs were still being recorded)... but couldn't remember exactly what I was working on at the time.

Being a noob, it took me a while to work out that it was a variable that was not being assigned (or even defined) in the header portion of the page that was causing it ($_SESSION['user_session'] wasn't set, so there was no assignment of $user_session):

Code:
<?php
     ....
     if (isset($_SESSION['user_session'])) {
       $user_session = TRUE;
     }
     .....
?>

When $user_session was used again in the footer of the page, it didn't throw any errors that made it obvious that it wasn't defined (because the way I was testing for it), and the bits I was working on all seemed functional:

Code:
<?php
  ....
  echo('<script>');
       if (\App\Controllers\Vars::NOTIFICATION_WEBWORKER_PUBLIC) { // start shared WW if required for non-registered viewers
            require FCPATH.'assets/js/ww_inline.js';
       } else if (($user_session) && (\App\Controllers\Vars::NOTIFICATION_WEBWORKER)) { //  start WW when user signed in
            require FCPATH.'assets/js/ww_inline.js';
       } else if (($user_session) && (\App\Controllers\Vars::NOTIFICATION_SHARED_WEBWORKER)) { // start shared WW when user signed in
       if (\App\Controllers\Vars::NOTIFICATION_SHARED_WEBWORKER_XHR) { // if both XHR & SSE SWW off, then you get none
            $worker_type = 'sww_xhr.js';
       } else if (\App\Controllers\Vars::NOTIFICATION_SHARED_WEBWORKER_SSE) { // if both XHR & SSE SWW off, then you get none
            $worker_type = 'sww_sse.js';
       }
            require FCPATH.'assets/js/sww_inline.js';
       }
       // require FCPATH.'assets/js/post_inline.js';
  echo('</script>')
  ...
?>

If $user_session is simply defined somewhere before it's checked in the footer, the debugbar & its logs comes back. It's repeatable- so the debugbar can be broken on demand Wink.

I don't have a handle on why it happens... though, I'm sure one of the experts familiar with the internals could field this question without too much difficulty (?).

Hope this helps.

Noobie,
Gary
Reply
#17

Hello mate ! I had a similar issue before, using CI in a subfolder. What does your browser's console says ? Unable to reach some files ?
In a local environment, set your base_url to "http://localhost:8080/", then in your console launch "php spark serve". Is it working now with your app ?
Reply
#18

(This post was last modified: 01-17-2020, 03:46 PM by JNapolitanoIT.)

Hey there.

I would like to add my two cents on this topic. First off, might I suggest that instead of using the following code block to access/manipulate session data:

Code:
    ....
    if (isset($_SESSION['user_session'])) {
      $user_session = TRUE;
    }
    ....

that you use the built-in session library instead. This way you don't have to worry too much about sessions closing early, or not at all, or not on time, etc. The session library was built to do the heavy lifting for you so you don't have to worry about anything else.

For example, the way to do this is to call the Sessions service using its helper function like so:
Code:
$session = session();

Now, you can access your session data easily. Reformatting your code from before to utilize this would look like the following:

Code:
    ....
    if (isset($session->get('user_session'))) {
      $user_session = TRUE;
    }
    ....

    // OR, you can use a little 'magic' =)

    ....
    if (isset($session->user_session)) {
      $user_session = TRUE;
    }
    ....

You can read more about it here. The reason I bring this up is because the way you're accessing session data could impact the debug toolbar. For example, see here. Also it is always best to utilize the frameworks built-in libraries for consistency across your application. After this, you may want to make sure your write permissions are properly set for the following directory:

Code:
writable/debugbar/

I hope this helps you out and I am not talking out of my hind-end Tongue
A reader lives a thousand lives before he dies. The man who never reads lives only one.
George R.R. Martin

Reply
#19

(This post was last modified: 01-17-2020, 03:18 PM by Gary.)

(01-17-2020, 12:33 PM)Gary Wrote:
(11-15-2019, 09:11 AM)hbonds Wrote: I have set environment to development through .htaccess file using code
 
Code:
SetEnv CI_ENVIRONMENT development

environment is successfully set to development, but I am still not able to see debug toolbar.
How can I see debug toolbar on application?


Just to clarify... since, re-reading my previous post, I suspect it will be too easy to believe that the problem is the undefined variable... when it's really the way the the undefined variable is tested/checked.  If one uses a test like isset(), then the problem also seems to go away.


Gary

(01-17-2020, 03:06 PM)JNapolitanoIT Wrote: Hey there.

May I add my two cents on this topic. First off, might I suggest that instead of using the following code block to access/manipulate session data:

Code:
    ....
    if (isset($_SESSION['user_session'])) {
      $user_session = TRUE;
    }
    ....

that you use the built-in session library instead. This way you don't have to worry too much about sessions closing early, or not at all, or not on time, etc. The session library was built to do the heavy lifting for you so you don't have to worry about anything else.

For example, the way to do this is to call the Session services helper function like so:
'
Code:
$session = session();

No you can access your session data easily. Reformatting your code from before to utilize this would look like the following:

Code:
    ....
    if (isset($session->get('user_session'))) {
      $user_session = TRUE;
    }
    ....

    // OR

    ....
    if (isset($session->user_session)) {
      $user_session = TRUE;
    }
    ....

You can read more about it here. The reason I bring this up is because the way you're accessing session data could impact the debug toolbar. For example, see here. Also it is always best to utilize the frameworks built-in libraries for consistency across your application. After this, you may want to make sure your write permissions are properly set for the following directory:

Code:
writable/debugbar/

I hope this helps you out and I am not talking out of my hind-end Tongue

Brilliant!  Thanks JNapolitanoIT... I had just started with my experimenting with sessions, which is why I needed the toolbar, and then noticed I'd manage to break it... so now that I'm back up and running and about to pick up where I left off on sessions, your pointers are perfectly timed.

Gary
Reply
#20

(01-17-2020, 03:06 PM)Gary Wrote:
(01-17-2020, 12:33 PM)Gary Wrote:
(11-15-2019, 09:11 AM)hbonds Wrote: I have set environment to development through .htaccess file using code
 
Code:
SetEnv CI_ENVIRONMENT development

environment is successfully set to development, but I am still not able to see debug toolbar.
How can I see debug toolbar on application?


Just to clarify... since, re-reading my previous post, I suspect it will be too easy to believe that the problem is the undefined variable... when it's really the way the the undefined variable is tested/checked.  If one uses a test like isset(), then the problem also seems to go away.


Gary

(01-17-2020, 03:06 PM)JNapolitanoIT Wrote: Hey there.

May I add my two cents on this topic. First off, might I suggest that instead of using the following code block to access/manipulate session data:

Code:
    ....
    if (isset($_SESSION['user_session'])) {
      $user_session = TRUE;
    }
    ....

that you use the built-in session library instead. This way you don't have to worry too much about sessions closing early, or not at all, or not on time, etc. The session library was built to do the heavy lifting for you so you don't have to worry about anything else.

For example, the way to do this is to call the Session services helper function like so:
'
Code:
$session = session();

No you can access your session data easily. Reformatting your code from before to utilize this would look like the following:

Code:
    ....
    if (isset($session->get('user_session'))) {
      $user_session = TRUE;
    }
    ....

    // OR

    ....
    if (isset($session->user_session)) {
      $user_session = TRUE;
    }
    ....

You can read more about it here. The reason I bring this up is because the way you're accessing session data could impact the debug toolbar. For example, see here. Also it is always best to utilize the frameworks built-in libraries for consistency across your application. After this, you may want to make sure your write permissions are properly set for the following directory:

Code:
writable/debugbar/

I hope this helps you out and I am not talking out of my hind-end Tongue

Brilliant!  Thanks JNapolitanoIT... I had just started with my experimenting with sessions, which is why I needed the toolbar, and then noticed I'd manage to break it... so now that I'm back up and running and about to pick up where I left off on sessions, your pointers are perfectly timed.

Gary

You're very welcome I am glad I can be of some help. Good luck with your project. The session library if I am correct is a beefed up port from CodeIgniter 3 and if that's the case then you've got yourself a robust Session library to work with using CodeIgniter 4. It handles all of the session data and does all of the behind-the-scenes stuff so you can focus on developing your application and it is a very powerful library Smile
A reader lives a thousand lives before he dies. The man who never reads lives only one.
George R.R. Martin

Reply




Theme © iAndrew 2016 - Forum software by © MyBB