Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Buggy (I think) 404 pages #46

Open
abread opened this issue Oct 23, 2013 · 5 comments
Open

Buggy (I think) 404 pages #46

abread opened this issue Oct 23, 2013 · 5 comments
Labels
Bug Discussion

Comments

@abread
Copy link

abread commented Oct 23, 2013

I was trying the latest fuelphp version and I wanted to see if the 404 page had the same fancy look (congratulations for that by the way) as the other error pages...
And instead of an exception related to the router or just a page saying the good old "404 - Not Found" I got "Could not resolve: Fuel\Foundation\Response\ %Really_long_html_code_here_in_the_middle_of_the_title_that_looks_like_the_code_for_the_404_error_page%".

Just pointing it out to make sure that all the bugs are reported as soon as possible to release the new FuelPHP as soon as possible!
@WanWizard
Copy link
Contributor

I can't reproduce that, if I request http://fuel2.local/doesnotexist, I get the standard "Ow, crap" page that is also present in 1.x. What exactly did you do to install and produce this error? Which environment?

Please note that this is not "the latest FuelPHP version". This is the development environment for FuelPHP v2, which at the moment is far from ready.

@abread
Copy link
Author

abread commented Oct 24, 2013

Using MAMP Pro with PHP 5.4.4. My fuel installation is on a sub-folder and when I access fuelphp through an url like (sites.local/fuelphp-master/doesnotexist) I get the stack-trace error page (titled: Could not resolve: Fuel\Foundation\Response\CTYPE html> <title>Aw, Crap!</title> <style> #logo{ display: block; background-image: url(data:image/png;base64,iVBORw0KGgo (...)). Tried with a non-within-subfolder installation and the result is the same...
untitled-tiff

PS: Images seem a bit buggy in Github... But the image basically contains a print screen with part of the stack trace

@WanWizard
Copy link
Contributor

I'm clueless. You don't have a typo in your Welcome controller?
return \Response::forge('html', \Presenter::forge('welcome/error404', null, null, 'welcome/404'), 404);

if after 'html' you have a dot instead of a comma, You'll end up with a load request for Response\Html<the-output-of-the-presenter-concatenated>.

@abread
Copy link
Author

abread commented Oct 26, 2013

There was no dot after 'html' because there was no 'html' in the code!

Replaced return \Response::forge(\Presenter::forge('welcome/error404', null, null, 'welcome/404'), 404);
by return \Response::forge('html', \Presenter::forge('welcome/error404', null, null, 'welcome/404'), 404);
and it's now fixed...

But some thing you should look is the CTYPE html> appearing on the top of the page.

@WanWizard
Copy link
Contributor

Ok, so you've got an old version of the code. The Response subclass was added as a parameter recently, and because I use the Welcome controller for testing, I'd probably didn't commit that change yet.

What do mean with CTYPE html> ? I thought it was fixed now? With the old code you got that because it was trying to load the Response\<html>... due to the fact it tried to use the result of the Presenter as the Response subclass name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Discussion
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@WanWizard @abread