TheNavigator Posted September 30, 2012 Share Posted September 30, 2012 I'm having a php page for registration and login. The problem is that it doesn't refresh correctly when trying to login/register. It just displays a white page after pressing enter, and I need to click on the URL, press enter again at the browser to see the result. The page is taken from a demo, but I've edited it. The demo works perfectly, my page doesn't though. Here's both codes. http://pastebin.com/f5qeXXMn -> My code http://pastebin.com/6iuPbj3c -> Demo code And that's the link of the page http://project.unlicrea.com/demo.php Can someone help please? Quote Link to comment Share on other sites More sharing options...
Adam Posted September 30, 2012 Share Posted September 30, 2012 What does ini_get('display_errors') return? Quote Link to comment Share on other sites More sharing options...
TheNavigator Posted September 30, 2012 Author Share Posted September 30, 2012 :| I'm a PHP beginner, so how am I supposed to know that? :| Quote Link to comment Share on other sites More sharing options...
Adam Posted September 30, 2012 Share Posted September 30, 2012 Well that's why I linked to the manual for ini_get. Just add this line to the start of your script. If an error then shows up instead of a blank script, you know errors aren't being displayed and the error should explain what's wrong. ini_set('display_errors', 1); Quote Link to comment Share on other sites More sharing options...
TheNavigator Posted September 30, 2012 Author Share Posted September 30, 2012 <?php ini_set('display_errors', 1); define('INCLUDE_CHECK', true); require 'connect.php'; require 'functions.php'; // Those two files can be included only if INCLUDE_CHECK is defined I did this And still, nothings shows up. I'm a C/C++ algorithm and iOS developer, so if you can explain it in such way then I'll be much thankful Quote Link to comment Share on other sites More sharing options...
TheNavigator Posted September 30, 2012 Author Share Posted September 30, 2012 Just tried logging ini_get('display_errors') It returns an empty string. Quote Link to comment Share on other sites More sharing options...
Adam Posted September 30, 2012 Share Posted September 30, 2012 Does it actually return an empty string, or is that you're passing 0 (and so treated as false) to your logging function? var_dump is the best way to determine the correct type. Are you getting the error on a shared host? Quote Link to comment Share on other sites More sharing options...
TheNavigator Posted September 30, 2012 Author Share Posted September 30, 2012 (edited) It's a shared host yes. And I'm using error_log ( ini_get('display_errors') ) ; As ini_get returns a string, the string shall be there at the error_log file. It returns something actually, but it's nil or empty. [30-Sep-2012 22:20:50 UTC] [30-Sep-2012 22:21:04 UTC] [30-Sep-2012 22:21:47 UTC] Edited September 30, 2012 by TheNavigator Quote Link to comment Share on other sites More sharing options...
White_Lily Posted October 1, 2012 Share Posted October 1, 2012 I've never really liked pre-written code - so all i am going ot suggest is that you look into creating your own login/registration forms, i would be more than happy to help you with this. Quote Link to comment Share on other sites More sharing options...
Adam Posted October 1, 2012 Share Posted October 1, 2012 It's a shared host yes. And I'm using error_log ( ini_get('display_errors') ) ; Use error_log(var_dump(ini_get('display_errors'))). That will tell you the exact type of data it is in English. I suspect it's boolean 0 and just not showing up in the logs as a result. It's not uncommon for shared hosts to prevent you changing the ini settings, which would explain why ini_set() had no impact. Was tired last night so can't believe I didn't think about this, but given you're dumping to the logs you should be able to see the errors there..? Unfortunately though as this is written by someone else, you should probably contact them for support. We don't generally provide bug fixes for scripts you've just downloaded. Quote Link to comment Share on other sites More sharing options...
TheNavigator Posted October 1, 2012 Author Share Posted October 1, 2012 It's not a bug. The original version works perfectly. I don't know what edit ruined things And yes I can see the error logs. error_log(var_dump(ini_get('display_errors'))) returns an empty string too. Quote Link to comment Share on other sites More sharing options...
Jessica Posted October 1, 2012 Share Posted October 1, 2012 Then I'd start over with the demo, and add your changes back line by line until it breaks. And look into version control. Quote Link to comment Share on other sites More sharing options...
White_Lily Posted October 1, 2012 Share Posted October 1, 2012 Its exactly the reason why i now write my own coding, with pre-written code it is very difficult to edit most of the scripts, and you dont know your way around. Whereas if you write it yourself you know your way around the process, if you get errors and read the error message properly you know what its talking about, and you know how the script handles the data should there be a complication further along the line. Seriously instead of copying someone else, write your own - so much easier than it looks. Quote Link to comment Share on other sites More sharing options...
Christian F. Posted October 1, 2012 Share Posted October 1, 2012 var_dump () returns void, so no surprise that it doesn't log anything. That function will only output to "screen", or in this case the web browser. gettype () on the other hand, will return the type of the variable for you. Which, I suspect will be "bool", as mentioned above by others. What you really should do, to turn error reporting on, is to edit your php.ini. Then restart your web server. As far as pre-made vs. homebrewn code goes: No point in re-inventing the wheel, if you have a perfectly good wheel available. Which you do in most cases. However, it is always worth learning how to make said wheel, so that you can tell for yourself whether or not the pre-existing wheel is any good. Which is why I recommend everyone to try and make as many different systems they can, from the ground up, for themselves. However, for production use I recommend using existing solutions. Not only will they tend to be more secure, but it also saves you a whole lot of work and time. Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted October 1, 2012 Share Posted October 1, 2012 Your php code has been tabbed over, so it now contains white-space before the first opening <?php tag. That will prevent all the session/cookie related statements from working. You need to have php's error_reporting set to E_ALL and display_errors set to ON in your master php.ini on your development system to get php to help you. You will save a TON of time. You should also be developing and debugging php code on a local development system, not a live server. Quote Link to comment Share on other sites More sharing options...
White_Lily Posted October 1, 2012 Share Posted October 1, 2012 Live server debugging is fine, but make sure that a username and password is needed to enter the site. (an example of this is heartinternet's own control panel which allows you to add a username and password to the site which people need before seeing any content). Quote Link to comment Share on other sites More sharing options...
Jessica Posted October 1, 2012 Share Posted October 1, 2012 Live server debugging is fine If you don't care about possibly losing/corrupting your data, and shutting down the site for actual users when a problem occurs, sure. Quote Link to comment Share on other sites More sharing options...
White_Lily Posted October 1, 2012 Share Posted October 1, 2012 (edited) Solution: Keep a copy of the site on your local hard drive, re-upload if something goes wrong... Edited October 1, 2012 by White_Lily Quote Link to comment Share on other sites More sharing options...
Jessica Posted October 1, 2012 Share Posted October 1, 2012 Quote Link to comment Share on other sites More sharing options...
White_Lily Posted October 1, 2012 Share Posted October 1, 2012 (edited) But then again, what if you debug it locally, and the files become corrupt? youd have to rebuild it all over again, so either way whether you edit online or offline your still guna have pretty much the same risks lol As for keeping users offline while debugging online, which you rather: have the problem there staring every user in the face, or take the site down while you fix the problem so that error doesnt occur anymore? Edited October 1, 2012 by White_Lily Quote Link to comment Share on other sites More sharing options...
Jessica Posted October 1, 2012 Share Posted October 1, 2012 The difference is one site is being used by your users, and has up to date, valuable data. Do you seriously not see that? Quote Link to comment Share on other sites More sharing options...
White_Lily Posted October 1, 2012 Share Posted October 1, 2012 So take a backup of the site & database before making changes? (Which is what most people and companies do anyway). Quote Link to comment Share on other sites More sharing options...
Jessica Posted October 1, 2012 Share Posted October 1, 2012 So, no, you really don't see the difference. Quote Link to comment Share on other sites More sharing options...
PFMaBiSmAd Posted October 1, 2012 Share Posted October 1, 2012 The short answer is - programming is not painful. The OP has spent a number of hours with this problem, when in fact, had he been learning php, developing php code, and debugging that php code on a local development system, properly setup with error_reporting and display_errors set as suggested, it would have taken him probably 3 minutes to determine what was causing the problem and could have probably fixed it himself. Quote Link to comment Share on other sites More sharing options...
TheNavigator Posted October 2, 2012 Author Share Posted October 2, 2012 (edited) Jessica: Okay then I'll try White_Lily: I'm not experienced enough Christian F.: Yes that's a point I consider and that's why I actually got a demo and just edited it though. Thanks for your reply, if I needed to get the type I'll use this method. PFMaBiSmAd: I'll try this. And for the local server, yea I know. That was a big fault I've done actually. I'll fix this error and then I'll continue developing that on local server and update it from time to time For the solution, THAT WAS IT! Thanks! White_Lily: Actually I did that, but I didn't have recent enough backups. I used to have much backups, didn't think it was really important to keep really recent ones though. Now I do. For your other post, I don't know what do you mean. It's a completely new project so it's not even released yet Jessica: It's not. It's still not released. Of course, OF COURSE when it's live everything will change! PFMaBiSmAd: It IS painful at a point. For the hours point, yes of course I know that every single minute that passes lets me gain much more experience, and that's why I'm doing it. Much thanks for your replies guys. It's resolved now! And sorry for late replying. I had problems accessing the site. Edited October 2, 2012 by TheNavigator Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.