Welcome Guest, Not a member yet? Register   Sign In
"php index.php" works, mod_php does not
#1

[eluser]tmcw[/eluser]
So, like a few other folks, I'm getting blank pages on my install of CodeIgniter. Here's the dreadful list of symptoms

- In my shell, I can run 'php index.php' (with php5-cli) and get the correct output

- I'm using Apache, proxied through Nginx. Internally, Apache receives connections at 127.0.0.1:8090.

- Looking at my Apache logs, it's getting a 200 code from Apache for each pageload. It's definitely seeing the requests, at least.

- Simple PHP (a test page, and adding a 'echo "working"' line in CI's index.php) works, for whatever reason.

- No error messages I can find so far.

- I've got php, mod_php, php-mysql, mysql, etc. installed.

Any ideas for what I can do here? It would be useful if I could summon a few errors - is there something I can change in Apache to do that? Anyone else had this problem? Thanks for any help on this one!
#2

[eluser]tmcw[/eluser]
- also, I just tried

grep -r " <?php" *

and

grep -r "?> " *

to find any whitespace, and no results besides views...
#3

[eluser]tonanbarbarian[/eluser]
turn on logging in the config and then look at the log file and see where it is finishing and work your way back
#4

[eluser]tmcw[/eluser]
I did - running 'php index.php' makes a normal-looking log entry, but accessing the site via the web doesn't write anything to the logs.
#5

[eluser]Pascal Kriete[/eluser]
Try adding a test echo to the beginning of system/codeigniter/CodeIgniter.php (don't forget to remove it again Smile). It seems that your application chokes after index.php so ideally you'll want to know where.
If that doesn't show, check that your BASEPATH and APPPATH get set correctly (again, easiest to simply echo them at the bottom of index.php- just before the include).
#6

[eluser]tmcw[/eluser]
All right, through judicious echoing, I've figured out that the application dies on the line

$EXT =& load_class("Hooks");

Anyone ideas?
#7

[eluser]tmcw[/eluser]
Found the solution. I needed to chown the /logs/ directory. Curious that this failure went silently and brought the whole thing down - but I'm going to focus on deployment for now Smile
#8

[eluser]MadZad[/eluser]
How on God's green earth did any of us ever get anything accomplished without a searchable catalog of user discussions? I thought I botched our install when moving changes and tracked my problem down to the same line of loading Hooks. Without tmcw's post, I have no idea how long I'd flounder before finding the (self-created) problem with the logs directory.

The active community was a big selling point in selecting CI, and y'all just saved me a bunch of time and frustration. Thanks!

Once nice newbie feature of OSCommerce was how it warned you right on the top of the page when common install problems occurred. Things like "delete your install directory" or "your config file is writable". Anyone know of any similar-minded CI contributions? Any EllisLab thoughts along these lines for 1.6.2 or beyond?
#9

[eluser]nmweb[/eluser]
A framework like CI's task shouldn't be to help you install it with nice error messages. It's not a CMS nor any other web-application. The /logs/ issue could be mentioned more prominently on the installation page although it's mentioned on the errors page. Building installation scripts for CI is not only adding useless overhead but also adding potential security risks.
#10

[eluser]MadZad[/eluser]
nmweb,
I agree about installation scripts - I wasn't referring to the part of OSC's hand-holding that walks you through a base install. While convenient for an application like that, I'm with you that a programming framework doesn't have that need.

What was in my mind (such as it is) with the last post is more of a diagnostic that would look for common issues that are unique to CI. The "hey dummy, you forgot to do X" messages. Surely any such tool would have to have have internal knowledge that you wouldn't want revealed, but any such security liability can be addressed - only run in a debug mode, write to a log instead of to the screen, and clearly keep the code out of the webroot. I certainly wouldn't advocate anything that complicates or slows down sites, but consider the various CI libraries/helpers that exist but you don't utilize. A diagnostic tool could be one more such unused feature that could potentially be a timesaver when you did dust it off.

If I had a better memory, I would have remembered about permissions on the logs dir. But then again if I had memory to spare, I'd probably devote it to the app code anyway. I just appreciate things that do automated checking of mundane things because that allows me to focus on business logic.




Theme © iAndrew 2016 - Forum software by © MyBB