LOL... hey chief, thanks for all your guidance.

So IOW, ...

So then I can get away with
pun_setcookie(, , $expire);

Or Must I do:
pun_setcookie($cookie['user_id'], $cookie['password_hash'], $expire);

All righty then... now that I'm on track, can you tell me, can I simply reset the expire value inthe cookie and leave the rest, or do I have to re-write all values to the whole thing?

Smartys wrote:

Which where is the 'right place' to set it so that the session stays active as long as the user does something within the timeout period set?

check_cookie, as you guessed.

Nope, I think that's not correct.
In fact, it appears that, in the functions.php file (which definitely gets called for a cookie check via common.php anytime we do things)
...the cookie gets updated (pun_setcookie) only if authentication fails.  So either the 'so-called'  timer runs out, or the user set save_pass so the timer does not matter

So in fact, it appears there is no code written there that checks the updated $expire time(r), and then updates the cookie with the new $expire value!

So if I didn't overlook somethng or misunderstnad the check_cookie functionality, then it would seem I need to write a little bit of code that will do just that.

Your input on this is most welcome.

(Oh and @Divnain, yeah, I already took care of all that, thanks.)

Woops... I cannot figure out this next thing.
I thought it was all good, but then while the user is active in the session, no matter, when the time is up the user's session is killed.
  Which where is the 'right place' to set it so that the session stays active as long as the user does something within the timeout period set?

Now it would seem to me that..
1) Whenever an action is taken there is a flow through common.php and functions.php, and
2) so it seems check_cookie() function in common.php gets triggered on any event, such as clicking a link to another page, and then
3) that function is them run from functions.php, which
4) sets the "new $now()" time
5) which then updates the value in $expire = $now + 1800; (that I have configured there.
6) which should be getting used on down the line - thus keeping the cookie time 'within bounds'.

Or something like that - no?

All righty then... I'm in the saddle now - thank you so much, Smartys!

<twohawks rubbs his eyeglasses, ponders 'basic reading skills 101'>....

Let me get back to you  ...8^P

Okay.  Well, I located those files and, along with the changes mentioned above [post#5 regarding editing in functions.php file], I changed each occurance of "time() + xxxxxxx"  in the other files (where it related to cookie stuff) to "time() + 1" ,
...but the user still stays logged in after a lengthy idle time :^(

Just to mention, for testing I use a separate browser that is storing its own cookies, and  I log the user instance out, and then log it back in.  I can see the "end of session" cookies being set each time I log the user instance in.


Hmmmm..  I am not obtaining expected results...
Per #1) when you say "all over", I assume you mean limited to "in the function.php file", is this correct?

Per#2) I set it up as "$expire = $now + 1;" for testing.  Since "$now = time();" I assume this all means that the cookie knows the expiry time will be one second after I log in.
I also assume that this means that if after one second of being logged in I refresh the page, the cookie will be queried and the "session will know the time has passed" and require me to log back in.
But this does not happen... I remain logged in until I either log out or close the browser entirely and then re-open it.  I have tried differnt settings for $expire and I continue to get the same results.

What am I missing here?

Hi Smartys.  Thanks. 

I am still observing results different than expected. Please allow me to explain and try to obtain better clarity as to how this should work..

First, to be clear, I reset everything back to how it was originally (i.e., stock, or when downloaded).

Now let me see if I understand this proper...
If, right near the beginning of functions.php file where "cookie stuff" is setup...
$now = time()  (no changes made)
and then $expire is changed to something like  "= $now + #;" ...where # is some number representing seconds,
..then what should happen is the session cookie should expire after the # of seconds set, and also if/when the browser is closed...
Is this correct?

If so, some questions remain...
1) I do observe the session requiring login after closing and then reopening the browser, so no question there (except I do not know why it was not doing this before [smegma?].
2) I do not observe the session timing out (resetting and requiring a login) after  "#" of seconds of user inactivity.  Why is this?  Can I change it?
3) I do not observe the session resetting if I close a browser tab?  Can I enforce that?
4) How is any of this possibly related to "Save Username and Password between visits" setting in user's profile:privacy, and how would I over-ride that?

Cheers (and thanks for your, as always, indefatigable support ;^),

Hi Good Folks,
  Sorry to bother about this, I just couldn't find the answer...

The Problem:
- User walks away from the workstation... session never times out
- User closes browser, comes back later... gets right in without login

The three solutions I have seen are:
- set this in the user's profile

...and then I did find this...
Can i set cookie of punbb  which expires after user .. closes the Internet Explorer Window .. ??.
One answer was...
In functions.php

Search for: (about Line 151)
setcookie($cookie_name, serialize(array($user_id, md5($cookie_seed.$password_hash))), $expire, $cookie_path, $cookie_domain, $cookie_secure);

and replace it with:
setcookie($cookie_name, serialize(array($user_id, md5($cookie_seed.$password_hash))), 0, $cookie_path, $cookie_domain, $cookie_secure);

Comment by dev'r: DO NOT DO THIS.. WILL NOT WORK....
Search for
    $expire = $now + 31536000;    // The cookie expires after a year
and replace with
    $expire = 0;    // The cookie expires when session ends

I tried these things but its not working.
What I wish to do is Globally Set the situation so after about a half hour, no ifs ands or buts, no matter how the user, even the admin, sets up their personal settings, no matter if they leave the browser open or not, ....if there is no activity for about a half hour I want that session to time out and require a log in to get back in.

How can I accomplish this?
I am still using 1.2.12 (or .15... cannot recall offhand, I just haven't had time to do the upgrades... so many mods to watch out for breaking something that isn't broken just now ;^)  Just not enough time.

Best regards,
Rick / TwoHawks

No I did not do that.  I immediately checked the tables after recreating that group and the difference I mention was immediately apparent.  Willow (only other admin) could not have interfered either because at the time she was not at a computer.

I think the only thing left to do is... I have to do my homework, as mentioned above, and then very carefully record what takes place.

I hope to take time out over the weekend periodically.  I will wait until I assemble substantive and uniform information, and in the form of a demonstrable excersize for exposing an issue, if there is one that is not "user-error" related  ;^)

Thanks again, Smartys... I am very grateful for your assistance today.
Be well,
Two Hawlks

Hmmm... alrighty then, Smartys.. so you seem to be convinced things are functioning as they should be.  This is very encouraging.  I guess I have to consider manually grooming the whole place and then running some tedious tests, and then very closely monitoring how Willow creates new groups and changes things (?).
   Thank you so very much for taking the time.  I will post back here at some later date to provide updated feedback for anyone who may benefit, or if I feel there is still something "smelly in Denmark" ;^)

I have to say, though, this still does not explain why recreating the Validating Group auto-created more table entires in the database than were originally there (associations with newer forum_ids were generated). ?


Question, If I turned off read and post permissions for Validating (after recreating) then why would we have to go in and turn off the Post checkmark that appeared afterward in several forums?  Should it not become disabled when I turned those attributes off?

Whoa, wait a minute... I think that was something Willow did, I can turn that off...

Hmmm... but we used to give Guests read permissions, but right now if you turn that on you will observe they see Forums Christina, Two Hawks, and a small group, in the list (when not logged in, right)... and you cannot turn that off... but we always were able to before.

I just sent you an email ...including some snapshots and some descriptions.
Oh and btw, Willow (the admin for the forum) just came up and showed me how Validating is still messed up for some other forums 8^(

You may wish to include looking at the forums under the category "SPIRITUAL RELATIONSHIP" where she just had to turn off Post Replies for Validataing, and also you will see the greyed out check box with the checkmark in it in those forums.

What a disaster this is.

Thanks so much for looking & helping.

I clicked on your email link and sent you something.  Did you get it?  Is this something you wish to do and have time for?

Thank you very much, Smartys.
I will email you an admin login and password.
Please give me a little time to set that up, and I wish to include some snapshots inthat email for clarity... I am thinking I am failing to accurately describe the problem.

Nope, only has the view_users edit in it, applied two days after I deployed PunBB1.2.12 back in Sept last year. 

So I really do not htink its anything to do with changes to these files at all.

I will go look now. 
So you think that although redoing a fresh group allows the appearance to display correctly,
and even though this also creates different entries in the database (which seem to correct the problem),
that the admin_forums.php file might be the problem and not the database?

I will go check that out and edit this post in a couple minutes with repsonse to your question.

OKAY, I checked and the only mod to it is to add the "parent_forum_id" from I believe it is the sub-forum mod, which was added forever ago (Sep 22, 2006 to be precise), so I think I would have observed problems long before now if it was the culprit.

Validating Group was originally made long time ago last year based on guest (who have read permissions set to on), and then all permissions including read were turned off.  So guests can view certain public forums, but 'validating' users get nothing... they have to wait for the admin to custom setup their profiles.  Iknow, it sounds weird, but its the way she wants to handle it.

Anyway, I am going to look at the admin_groups.php file and see what's up there  as well.

Thanks for looking at this, Smartys.

Hmmm...  Well I wonder why when I 'rebuilt' (so-to-speak) the Validating Group that the new Validating Group then was included with the rest of the forum_id associations when it was not before?

In the BB it looked like this... 
   1) when going into Administration:Forums, selecting an older forum, and then observing the Groups listed, Validating Group should have the 'read attribute' appearing as Red with no checkmark, and it did,
   2) but what it was appearing as for recent forums was greyed out, with a checkmark in the greyed out box (when it should be same as in #1, to be sure).
   3) If I created a group with same attributes as Validating it would demonstrate the Red Highlighting with no checkmark, as it should, in old or new Forums lised in Administration.
   4) But if I edited the existing Validating Group, saved it, and then edited it back to original settings it would still appear greyed out, with a checkmark in there.  (I expected it might 'correct' itself if I edited it, but it did not).
   5) Deleting it and recreating it, as described in my original post, corrected it...

...but so many others are messed up as well, including Guest, Member, Moderator, and, well, I am uncertain yet about Administrator.  And how would I fix those if need be?
So I am trying to figure out just what this problem is and how to globally fix it?
Do you see the problem?  If its, as you say, not table corruption, then what is that exactly??

Hi Folks,
  I am out of my league with this one... got a call today because people are having access to things they shouldn't in one of the BB's...

  I finally discovered that in the forum_perms table there are expected rows missing for many groups...
   ...where a group_id #X  only has associations from forum_id 3 thru 126 instead of up to #138 !!!  I do not know what other tables may also have similar or related corruption.

   When I created a new Group in PunBB it seemed to re-include the full range (fixing the problem for that group), so for instance,
     - I have a group named Validating. 
     - Validating was screwed up in the forum_perms table (per the above). 
     - So in the BB I Created a new Group named TestGroup with all the same settings as the Validating Group,
     - then I deleted the Validating Group, moving all the Validating Members to TestGroup
     - After renaming TestGroup to Validating I checked...
     - Checking Forums and such via Administration the Permissions were correct(ed)
     - Checking the forum_perms Table in mySQL reveals associations for that group_id with All forum_id's are accounted for.

So now I am faced with there a way in mySQL to have the Table Repair/Correct itself??  Of course, I ran repairs and such, but that did not 'do it'.

One thing I am really concerned about, say the only way to fix this is to conduct the method above for every Group in the BB....  well what do I do about the built in Groups such as Admin, Guest, Moderator, etc ??? Those are corrupted as well !!!!

What a freaking mess this is... I am just sick over it... how in the heckl could this have happened???

Your help, as always, is much apreciated.

Okay, well here's what I (can) gather so far...

    Imagecreate commands necessarily take up about (width x height x 5) bytes of memory for processing.  There is no way as yet that I have found for buffering or chunking the memory allocation for this sort of processing, or chunking the process itself.
    What I found I can do is run a 'ini_set' command against the memory_limit only during certain script executions so I do not have to leave the default mem usage settings ridiculously high. 
   What I plan on doing is writing a script/function that will allow for special cases where I wish to allow automatic memory allocation for a specific type of upload.  Later on I think I might script in an option to simply upload certain types of pics, and then only generate thumbnails for those.... so memory allocation management issues may be reduced.
   These seem to be the options available for this sort of thing for now.

BTW, to answer your question, Jansson, I imagine that the reason for using imagecreatetruecolor is that,  because we are not directly uploading the images, but resizing, and thus recreating, the images, ...for certain types of images it thus requires recreating them with truecolor if one wishes to maintain the full-color integrity.  This reasoning seemed pretty 'simply apparent' to me once I read up on it.

   Although I am thinking about rebuilding the uploader at some point to allow for direct uploading (as opposed to image recreation) in certain circumstances, and this would certainly get around certain memory issues, this possibly will not allow for certain other types of control that are available when using php to re-manage (proprietary issues with certain) images.  For anyone reading this, this is something to keep in mind ;^)

Thanks for your input, guys.  I am open to any further news on this subject, should it come around ;^)  I hope others may find this information useful as well.


(27 replies, posted in PunBB 1.2 troubleshooting)

lie2815.. I am looking at this today an its broken in ie5.5 (I did not yet look in ie6 or 7, I need to access with another pc later as those are not installed on mydev machine)...

Couple questions...
1) did you fix this already?
2) is that with cal 2.06 as the code shows, or did you upgrade (2.07b+ has a fix for the week display but I never observed a problem with the main...)

Please let me know if there's anything I need to consider patching in the calendar mod!