Login

Gary · 04-22-2020, 04:38 AM

Ok... I have some answers:

1) Regarding the toolbar, which was not being updated, and which I've found to frequently disappear (if one looks at several older questions/posts by other users regarding the toolbar not showing, this may be related):

In system\Debug\Toolbar.php:

Code:
public function prepare(RequestInterface $request = null, ResponseInterface $response = null)

{

  if (CI_DEBUG && ! is_cli())

  {

    ...

    // Non-HTML formats should not include the debugbar

    // then we send headers saying where to find the debug data

    // for this response

    if ($request->isAJAX() || strpos($format, 'html') === false) // << request AJAX || response doesn't have a 'html' content-type header

    {

      $response->setHeader('Debugbar-Time', "$time")

        ->setHeader('Debugbar-Link', site_url("?debugbar_time={$time}"))

        ->getBody();

       return;

     }

If one's site is navigated by AJAX posts (as my current one is), this will have a notable impact on the toolbar's behavior. If there are no knock-ons elsewhere in the framework, may I suggest investigating the possible removal of $request->isAJAX() from the check (since it is not uncommon for an AJAX request to result in a redirection or something that does force a page refresh). The strpos($format, 'html') check currently prevents- and after the mod, will contunue to prevent- the toolbar script from being injected when the reply looks like it's destined for JavaScript digestion** (as does the <head> check in the code following this extract (not shown here)).

2) Regarding the related phenomenon of my code not having other AFTER filters applied... it so happened that the bits of code I was working on (that was outputting material destined for client-side JavaScript) ended in 'exit' and not 'return'... which works great, IF there is nothing else to be done by the framework. As soon as one requires additional AFTER filter processing, if 'exit' is used, this obviously stops these filters from being invoked. Adding a comment about this in the User Guide under Filters may perhaps save other folk a lot of time and headache in the future (?).

** $format is generated from $response->getHeaderLine('content-type'), and MAY also require $response->populateHeaders() to be run before it is called in this check to refresh the array it references (?)

Leo · 04-23-2020, 12:54 AM

Great! I've got this in events:
Events::on('post_system', function () {
if(isset($_SESSION)) {
session_destroy();
}
});

I guess I have been seeing my flash messages because I've been putting exit() after redirects. Afterwards, though, when they have already seen the flash message, it gets destroyed as intended. So yeah, exit() also prevents 'post_system' events from working - which in my case works out well.

You can see things I made with codeigniter here: itart.pro its not overly impressive as I have very little time to learn.

Gary · 04-23-2020, 03:14 AM

Yeah... exit() kills everything right there... like a flu excuse on a global financial system.

How one terminates is like a box of chocolates... sometimes it works out ok, sometimes it sux. The best place to have exit() is evidently where one knows nothing further will or can ever happen afterwards (saves a hiccup like mine when one comes to insert more code further down the execution chain, a long time after one's forgotten about the code in the preceding flow). I suspect (without having looked into the fine details) the very last return will also end up destroying everything anyway (?).

Leo · 04-23-2020, 05:14 AM

(04-23-2020, 03:14 AM)Gary Wrote: Yeah... exit() kills everything right there... like a flu excuse on a global financial system.

How one terminates is like a box of chocolates... sometimes it works out ok, sometimes is sux. The best place to have exit() is evidently where one knows nothing further will or can ever happen afterwards (saves a hiccup line mine when one comes to insert more code further down the execution chain, a long time after one's forgotten about the code in the preceding flow). I suspect (without having looked into the fine details) the very last return will also end up destroying everything anyway (?).

Yes. The last return gets to the post event and sessions get destroyed. Without the exit() it gets destroyed before a redirect happens and the message is not seen, I tested this after reading your post. I've had tons of session files plague my CI3 projects, to the point where a client had to buy more space on hosting, and, though my coding improved since then, I'm just trying to keep sessions down to flash messages and short term data.

You can see things I made with codeigniter here: itart.pro its not overly impressive as I have very little time to learn.

Gary · 04-24-2020, 09:07 AM

For folk navigating with a lot of JavaScript- for possible use/comment/correction/criticism, how I've hacked Toolsbar.php is shown below.

So far it doesn't appear to have had any untoward side-effects. Be aware that this still doesn't updated the on-screen toolbar with every JavaScript request/response, but does permit an update with a JavaScript-induced page-nagivation update (so it simply moves some of the previously header-only feedback to on-screen feedback)).

From:

Code:
     $format = $response->getHeaderLine('content-type');

     // Non-HTML formats should not include the debugbar

     // then we send headers saying where to find the debug data

     // for this response

     if ($request->isAJAX() || strpos($format, 'html') === false)

     {

To:

Code:
     $response->populateHeaders();

     $format = $response->getHeaderLine('content-type');

     // Non-HTML formats should not include the debugbar

     // then we send headers saying where to find the debug data

     // for this response

     if (strpos($format, 'html') === false)

     {

Gary · 04-28-2020, 10:09 AM

Separate from the main topic, your problem with session files overrunning the server seems to be experienced by quite a few folk... and I suspect the ones that haven't had a problem are oftentimes either lucky (in that they've not needed to think about it because of the way their code was (inadvertently) written- and wasn’t generating a lot/sizeable of session files more by accident than by design), or perhaps have reasonably high-end systems which helps hide the issue, or perhaps addressed it the American way (pretty much like you did) by simply getting a bigger hammer.

I have had my eye on my own session files from before your comment, but since then I've been monitoring them more closely (and although they're tiny, but they do seem to have been growing in number - concerning, because it's only my test traffic at the moment).

I've not looked into the details as yet, though, the impression I have gleaned- only in passing, whilst looking for other unrelated material- is that it may be more of a PHP garbage-collection issue than one with the CI framework (?)… and there may well be ways to address it on the PHP side (I’ve not looked into this).

That being said, the one place CI does permit some control over session data is in the App.php file: $sessionRegenerateDestroy, which is set to FALSE by default (perhaps there is a good reason for this default ?)... which I've changed to TRUE, with no apparent problems to my site, yet. This doesn't stop them from accumulating when users close their browsers without signing out, but it seems to have slowed the accumulation down a bit.

Leo · 04-29-2020, 01:07 AM

Thanks, I'll just set it to true also.

You can see things I made with codeigniter here: itart.pro its not overly impressive as I have very little time to learn.

Gary · 04-30-2020, 06:10 AM

From what I can gather, the other setting that will probably make a difference is $sessionExpiration, which a the commment in the framework has this to say about: "Setting to 0 (zero) means expire when the browser is closed."

Leo · 04-30-2020, 12:44 PM

(04-30-2020, 06:10 AM)Gary Wrote: From what I can gather, the other setting that will probably make a difference is $sessionExpiration, which a the commment in the framework has this to say about: "Setting to 0 (zero) means expire when the browser is closed."

I always thought that meant the number of seconds regardless of the state of the browser...but I guess it actually means the number of seconds a session lasts AFTER the browser is closed. OR MAYBE NOT haha. But yeah, to zero it is. Maybe I can even remove my

PHP Code:
Events::on('post_system', function () {
    if(isset($_SESSION))
        session_destroy();
}); 

with these alterations. Only time (with testing) will tell.

You can see things I made with codeigniter here: itart.pro its not overly impressive as I have very little time to learn.