My App initializes 3 times everything

[eluser]Mareshal[/eluser]
I was looking in CI Log fiile(debug) and everything is loaded 3 times. EVERYTHING.

I can't post the log here because I don't have it, but I put a log_message() in one of my models and I got that message 3 times in log file.

Also I've extended CI_Controller with this

/core/MY_Controller.php

class Admin_Controller extends Controller {}
class Guest_Controller extends Controller {}

I can't check if I delete one of them everything will be loaded 2 times. but is weird. anyone had this problem ?

[eluser]John_Betong[/eluser]
Quite some time ago I had a similar problem which was not easy to trace.

I think there was a missing favicon.ico which produced a PHP error and the subsequent application was loading more than once.

Set the following code and check your PHP error log files.

Code:

error_reporting(E_ALL);
  ini_set('display_errors', 'On');

 
 
 

[eluser]WanWizard[/eluser]
Indeed. Usually .htaccess rewrite rules are the culprit here.

If often see people use (I see even the wiki recommends this):

Code:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?/$1 [L]

DONT!. This is a lazy man's .htaccess, and will cause these kind of errors.

Instead, make the design of your directory structure, and design your rewrite rules accordingly. For example, create a /assets directory, put all your assets (js, css, images) in this directory structure, and exclude this directory.
Result: no request of a missing image will ever be rewritten to request index.php anymore!

[eluser]Jelmer[/eluser]
@WanWizard
While I would agree with you that it's best to create a strong asset structure, I would disagree a lot with how you qualify those .htaccess rules. Also if this causes the triple load, there should be a clear time gap between the 3 loads - so the next question would be if there is?

That simply says: rewrite everything that's neither a file (!-f) nor a directory (!-d) to the index.php. Which is pretty much what you should want it to do, let CI handle everything but what "physicly" exists on your server (and as such you could add very specific error handling for certain cases). It gives you a lot more flexibility and portability then a very specific RewriteCond.

EDIT: @Mareshal
Such extentions would only cause this if they're all 3 instantiated, which none of them should be (only the controller extending one of those should be instantiated). You could try adding a log_message() containing the request URI, maybe you could find out if it's a tripple load on single request or 3 distinct requests (if the 3 loads are caused by files which aren't found).

[eluser]WanWizard[/eluser]
@Jelmer,

I know exactly what it says, and I disagree.

First, for every request of a file that doesn't exist, a rewrite happens. And that includes a missing image. This can cause al sorts of trouble because it will trigger a CI request, and it is very difficult to troubleshoot if you don't have your loglevel to 4 (so you see the multiple requests).
Second, this will make all sorts of files and directories accessable that you don't want to be accessed, for example the entire system directory, a folder with uploaded files, etc.

Imho, the only things accessable from the browser are your assets, and your index.php. The user has no business elsewhere. Offcourse, you could (and perhaps should) move all but your assets outside the docroot, but on a lot of shared hosting plans, that is not possible.

The only exception is if CI has to co-exist with another application in the same docroot, but even then I think you should tailor your rewrite rules to your specific situation.

I agree that it's easy, simple, and more portable. Hence the "lazy man's .htaccess" statement...

[eluser]Jelmer[/eluser]
@Wanwizard

The most I took issue with is that you call it a lazy-man's approach. I have a system that should work on almost any host, but if I were to make my .htaccess that specific I could never include some updates on every website.
I do get to put my system directory outside the webroot on all my hosting accounts, and to be honest I would push any client to another server if I couldn't do that. So that's not a problem for me.

While you might be right that's it's more difficult to find some errors, it's still a very good approach for many users (like me). It's not lazy to keep things portable, that actually prevents mistakes. That's not lazy, that's a best practice in my book. Maybe that's because I generally have little trouble finding those mistakes, as I load very little that I wouldn't notice missing right away.

In the end I don't fully disagree with you, I just take issue with you calling it "a lazy man's approach". It may be harder for some to find their mistakes and it may be more dangerous if you can't put your system directory outside the webroot. But in the end if you're writing a system that needs to be usable in more then just a couple implementations, you're far better off (IMHO) using code that is flexible.

I'm sorry, I can be a nitpicker on these things: just generally calling something "lazy" because you had a bad experience with it will not go for everyone. I want my system to handle requests that the filesystem can't. I generally combine both approaches, both making some directories excempt from CI handling and allowing for real files to be handled by the .htaccess. Part of that might be that I generally use ".htm" extentions with CI (which would already excempt images and other stuff).
But to reitterate: using a solution like the one we're talking about might cause errors in some situations but it might also be a very good practice in others. Calling it "lazy" in all cases is a generalization I take issue with, not that it might not be the best practice for all.

[eluser]WanWizard[/eluser]
@Jelmer,

I don't want to offend anyone by using the word "lazy". I'm (like you) not a native english speaker. I'm just a perfectionist, and not easily satisfied with a "more generic" solution if a better fitting one exists.

I use this .htaccess for all my projects, which doesn't use the generic file or directory check. If I have to exclude more from rewriting, I prefer adding a RewriteCond manually then rely on something generic, so I'm always in control of the magic mod_rewrite performs.

Code:

<IfModule mod_rewrite.c>

    # ATTENTION: if this .htaccess doesn't work, check if rewrites
    # are allowed in httpd.conf. You need to specify:
    # <Directory "my-website-directory-here">
    #     Options +FollowSymLinks
    #     AllowOverride FileInfo
    # </Directory>
    # or have these options defined globally in your httpd.conf file
    # to allow a .htaccess with rewrite rules to work!

    # activate URL rewriting
    RewriteEngine On

    # if the application is installed in a sub-directory of the document
    # root, modify the path below accordingly
    RewriteBase /

    # nasty hack to capture ruined URI's by a mod_rewrite bug.
    #
    # You need these two lines when you use mod_vhost_alias, and this
    # .htaccess file generates a "500 internal server error".
    # In the rule below, replace --DOCROOT-- by your full docroot path,
    # without a leading slash, but with a trailing slash!
    # (i.e 'path/to/my/docroot/', without quotes offcourse)
    #
#    RewriteCond $1 index\.php/$
#    RewriteRule ^--DOCROOT--(.*)$ /$1 [S=1]

    # Do not rewrite links to our documentation
    # You should remove this on production sites!
    RewriteCond $1 !^docs

    # do not rewrite links to website assets
    RewriteCond $1 !^assets

    # do not rewrite for our php files in the document root,
    # or for robots.txt requests
    RewriteCond $1 !^(index\.php|cron\.php|file\.php|ajax\.php|robot\.txt)

    # but rewrite everything else
    RewriteRule ^(.*)$ index.php/$1 [L]

</IfModule>

<IfModule !mod_rewrite.c>
    # If we    don't have mod_rewrite installed, all 404's
    # can be sent to index.php, and everything works as normal.
    # Submitted by: ElliotHaughin

    ErrorDocument 404 /index.php

</IfModule>