Antonio Conte

Tweak your error_reporting levels. That's why you see no errors. It's correc that you should not see any output here. A singleton is simple forcing one object per page request. I don't think the pattern is a good match for the stuff you want. Not sure what would really.

Projects are simply structures to organize folders. It's very easy once you get the hang of it. Your problem might be that you don't have the PHP version? You should be able to add a "PHP project". When that is done, just think of it as a main folder organizing your code. Glad you solved the problem. Thanks btw. It was a good match!

Define "perfection". I can add juvenorge.no as a domain name, and you have no way of knowing that is real. When you are pretty sure the email is valid, and when it does not break functionality or security, leave it at that. Getting is "perfect" is really not an option unless you want to study regexes. I know the feeling, but trust me: leave it at "good enough for the purpose."

Sorry about that. We have a different timezone here in Europe. I should not post while drunk. As a Juventus fan (If any of follow (real) Football (or Soccer)) my team won just some hours ago an important match... However. I tried your script one more time, making sure of the file name. I receive no errors when posting here, only a blank screen. (which makes sense following your logic) This does not correlate to the parse error you received. Are you sure this is the exact same version you are posting to? A parse error is triggered regardless of status (successful posting/errors received) and is thereby not tied to logic. Did you solve the error?

I tried the script here. It seemed to be working fine. However. You do posting to register.php which is not posted here. Check that file instead. I'm sure the error is there.

"You don't have to approve, as long as you validate." It's word I've been living be for a couple of year. (not perfectly translated) It's more important to ensure of security and usability than it is of validity. You can't really prevent users of typing in bad chars, so as long as it does not impose a treat to security, leave it be.

I really need to fix some classes in my own project. This looks pretty compared to some I my code. That's the bad part about laziness, haha! You do some really serious nesting here. Hope you never have to debug that method. I find that the most simple thing to do when introducing exceptions is to twist the logic around. I usually twist it like this: try { if ( ! $modelItem->save() ) { throw new Exception("Huston?..."): } // More tests.... // All tests passed. do shit. $transaction->commit(); $this->redirect(array('view','id'=>$modelItem->id)); } catch ( Exception $e) { $transaction->rollback(); } Do you do it similarly, or what's your plan? I enjoy your work log btw.

It's obviously a parse error, and probably connected to a logical test including a call to isset(). You only post parts of your code here, so it's difficult to find the specific part that causes the error. The easiest solution is to get an IDE with error highlightning. Try downloading Eclipse or Netbeans (Both free) and check your code there. It should tell you the line of code that causes the error. I added the two missing if-clauses to make the script parse correctly. With those, the script is perfectly valid. I would consider looking more at those, as I suspect the error to be there. Notice that the code above is not a solution to your problem. It only solves your parse errors. (And proving the rest of your code is free for parse errors.) <?php if ( true ) { // First missing if if ( true ) { // Second missing if } else { // Report the errors. echo '<h1>Error!</h1> <p class="error">The following error(s) occurred:<br />'; foreach ($errors as $msg) { // Print each error. echo " - $msg<br />\n"; } echo '</p><p>Please try again.</p><p><br /></p>'; } // End of if (empty($errors)) IF. } // End of the main Submit conditional. ?>

Glad you solved it.

First of, an auto_incremented integer cannot be null. If you try assigning that value, the next available unsigned integer will be stored instead. Null is actually a data type itself, (as a representation for "nothing" also must exist) so it does not make sense as a value in itself. Increasing the integer is MySQL's chosen implementation. As for the names, that has a data type of "String". (Or Varchar more specifically) An empty value here is therefor "" (an empty String) and not null. I'm guessing you are using PHP to add content to this table? All data submitted using PHP has the standard value of an empty string. That is therefor completely valid values to insert. The most basic, and therefor also the "default value" for a String type, is therefor also an empty String as it's the least amount of info accepted. If you try to explicitly add null directly into a query (using something like phpMyAdmin) then MySQL will complain about illegal values. As for solutions, leave user_id be. That's standard functionality you'll enjoy it's there once you get familiar with it. As for the names, you need to add some validation to your input before you save it to the database. Simple functions for this include strlen(), !empty(), or even isset(). You'll find more on that in the book.

Thanks, Captain.

It matters a bit. Namespace support was added in 5.3, so at least that's not the problem. Since you got a blank page, try adding these lines to the top of your file: <?php // Display errors ini_set('display_errors', 1); // Full error reporting error_reporting(-1); ?> Do you get any more information now?

Generally, your code needs to go through these steps for a sucessful login: 1. Submitting a username and password. - Make sure you are actually getting these values into your script. Apply simple debugging like using echo on the variables. 2. Encryption of password. - This can be done in both PHP and within the database query. Make sure your password is getting encrypted correctly. 3. Validation against records in the Database - Make sure your find a user with this method. Also debug the query by printing it out, and check if it works manually yourself in phpMyAdmin or similar. Make sure the values you add into the query (username and encrypted password) looks correct. 4. Sessions - Make sure you have started a session on all pages that depends on sessions values. 5. Check logic for session validation - Make sure your checks for sessions values are correct. Does it store the correct values you need? Are your checks written properly. Simply trying to echo this info to screen, and checking logic routing (what kind of if/else the logic follows) will take you a long way. These are general suggestions that should make you able to solve your problem. If it's not enough, we need to see some of your code.

Are you sure you are on PHP 5.3? A small search teaches me that this error is common when Namespaces are not supported. Try printing out the version information to confirm what your host tells you: <?php echo 'Current PHP version: ' . phpversion(); ?>

Yeah it should. We have a way of derailing the topic. Don't take it like that, man. I don't belittle people. Trust me on that. Your qualification is not a question. I was just trying to give you a recommendation. I'm sorry if you took it as insulting, buddy.

Thus, the "it's not clear how you are overriding". Did not mean to offend you. Chillax.

Then you go to http://yii.larryullman.com/, pay for the book and download it.

It really depends on wheter your banners are static or not. In my experience, adds and banners are randomized, switched out and managed by a solution. Creating a widget for such tasks make completly sense to me because of these reasons. Clips may be an even better solution for this, but I haven't really looked into their purpose yet, so that's not something I can really judge. However, I think a widget does make sense if you want more than one static banners.

It's not clear how you are overriding, Edward, but don't do it directly to the bootstrap files. Create a new stylesheet and overload it there instead. That way, you can easily upgrade bootstrap for example.

Maybe a widget makes more sense then?

Yes. I really bodged this one. 1. Create a simple link to the controller action 2. The controller should serve the form 3. That same form should recive the post request from the form 4. The controller should use a model to validate the post data 5. The controller should send the feedback email as appropriate. (As stated, I'm not sure where the email content belongs. Larry may clarify this.) I think I'm back on safe ground now. Sorry for providing some bad suggestions here. Let a poor man rectify himself a little.

I've looked at the Facebook PHP API a bit. Anyone can find it here if interested: https://developers.facebook.com/docs/reference/php/ A general problem is that you don't read that API. I doubt that's really the issue, but take getLoginUrl() as an example: From the API: You don't give facebook any of the keys they require. No scope and no redirect_uri. Facebook provides some application code example here btw: - https://github.com/facebook/facebook-php-sdk/blob/master/examples/example.php Your main problem is that you redirect way to much. I don't really think you should do that at all considering the example usage above.

What's the error message? What debugging steps have you taken? You provide to little context for anyone to help you.

Yes, try that. You might need to change some configuration for it to work at the new directory. If so, a new install might be easier to perform. Your app does need access to the framework folder as an example.

Ok. Then you should scratch my regard for a default model. Not sure where I was going with that anyway now that I think about it. The submission and feedback should be handled by a controller, while the validation should be placed in a model using the rules() method. That method should be initialized in the controller action the submission is done to, with a method call to validate(). You should then send the feedback over email considering validation. As you want this on every page, a default controller makes much sense. Guess you should wait for Larry to confirm if you are unsure about my approach. I got to admit I'm not 100% sure about this one. The email could possible be a model to. It makes sense to me, but I'm not really that sure.