Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 7 of 7
  1. #1
    Regular Coder
    Join Date
    Jul 2004
    Location
    Tampa
    Posts
    223
    Thanks
    23
    Thanked 0 Times in 0 Posts

    PHP Notice: A session had already been started - ignoring session_start()

    I have a permission file I include at the top of each page in my application that I am use to do the session_start() and check for the session.

    I am getting an error that shows on each page though that says:

    PHP Notice: A session had already been started - ignoring session_start() in C:\DATA\htdocs\includes\permissions\universal.php on line 2

    Any help would be greatly appreciated.

    The page runs fine, but the error shows.

    I tried searching for an answer, but the query in the search box was freaking the site out.

  • #2
    Senior Coder CFMaBiSmAd's Avatar
    Join Date
    Oct 2006
    Location
    Denver, Colorado USA
    Posts
    3,146
    Thanks
    2
    Thanked 333 Times in 325 Posts
    Either you are including the file multiple times on a page; or you are including it on a page that has its' own session_start() statement; or your php.ini (possibly .htaccess) is automatically starting a session before you do - http://www.php.net/manual/en/ref.ses...ion.auto-start

    Edit: You can use the following logic to only start a session if it has not already been started -
    PHP Code:
    if(!isset($_SESSION))
    {
    session_start();

    If you are learning PHP, developing PHP code, or debugging PHP code, do yourself a favor and check your web server log for errors and/or turn on full PHP error reporting in php.ini or in a .htaccess file to get PHP to help you.

  • #3
    Regular Coder
    Join Date
    Jul 2004
    Location
    Tampa
    Posts
    223
    Thanks
    23
    Thanked 0 Times in 0 Posts
    Thank you that was my next question. It looks like an include for calendar on the page has the session start too. Thank you for your help!

  • #4
    Senior Coder NancyJ's Avatar
    Join Date
    Feb 2005
    Location
    Bradford, UK
    Posts
    3,174
    Thanks
    19
    Thanked 66 Times in 65 Posts
    You can also just supress the error message with @
    eg.
    @session_start();

    It wont do any harm if it fails, its a notice, its not even a warning, let alone a fatal error. PHP is letting you know, just in case somethings going on that shouldnt be or that you dont know about.

  • #5
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,108
    Thanks
    11
    Thanked 101 Times in 99 Posts
    a suppressed error is still an error (and still uses up cycles to handle internally (more so if you log errors)), there are times when an error may be part of the normal scheme of things often with database calls etc which maybe expected to fail from time to time but for general use you should (IMO) try and fix the error, not hide it.
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)

  • #6
    Senior Coder NancyJ's Avatar
    Join Date
    Feb 2005
    Location
    Bradford, UK
    Posts
    3,174
    Thanks
    19
    Thanked 66 Times in 65 Posts
    But its not an error. Its a 'notice'. In terms of processing time it takes no longer to check if the session is set than it does to attempt to start the session and supress a notice.
    PHP4 & 5 suppress this level of errors by default. If your error reporting hadnt been changed to display notices, you wouldnt need to do either of these things.

    Notices can help when debugging, they can help point out typos and crap like not quoting array keys when you mean them to be strings not constants - stuff you should fix if you can but if your script works (and you understand the notices and what they mean) theres nothing wrong with supressing them.
    In a production environment, its normal for all errors to be supressed.

  • #7
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,108
    Thanks
    11
    Thanked 101 Times in 99 Posts
    In a production environment, its normal for all errors to be supressed.
    correct, but normal testing environment would work with E_ALL and remove as many notices or warnings as possible by fixing the error/notice/warning ,not by hiding them.

    In the example of this thread we have a session getting started from ...somewhere... surely its best to track that down and find out what else that page is doing that it should not be ? the end result is probably harmless here, but when you start debugging you need as much info as you can get and not have it hidden.

    My advice (now, since I used to be of the same opinion as yourself) is to turn on E_ALL whilst testing and only suppress with '@' when you know why you are doing so and when the alternative is not desirable.
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •