Daniel0

You will have to explain us how it doesn't work. Try to echo your queries and make sure they actually look like you want them to.

Change if($_POST['submit']) to if(isset($_POST['submit'])). You are accessing the submit index of the $_POST array. You can only do that if that index actually exists.

It would be better to use an XML parser such as SimpleXML to do this.

<?php $string = 'ThisIsBestPhpHelpSite'; $newString = preg_replace('#(?<!^)([A-Z])#', ' $1', $string); This will not give you a leading space.

Yeah that too, but there you would make it <?php echo $PText ?> seeing as it needs to be inside a PHP block to be interpreted by PHP.

You would probably want to move code like $pname = $_POST['PName']; $uname = $_POST['UName']; $ptext = $_POST['PText']; $auteur = $_POST['Auteur']; $bundel = $_POST['bundel']; $jaartal = $_POST['jaartal']; inside the if($_POST['submit']) block. Those indexes won't exist in the $_POST array until your form has been submitted.

Remove {$PText} near the bottom. You can't do that. You probably want to to echo $PText;

You can also check if the domain name in question has valid MX records using a DNS lookup. getmxrr

FYI, there is a function called implode/join, which does the reverse of explode, so echo implode('<br>', explode(' ', $words)).'<br>'; would do what you are doing. Replacing spaces using str_replace is better in this case though.

That code does not generate those errors.

INSERT INTO table (useragent) VALUES ('$useragent'); Escape $useragent with a function like mysql_real_escape_string.

Should be better now.

It's not a viable solution anyway. My post was more like an FYI. It may or may not be supported by IIS7, I don't know. The technology that makes it possible, SNI (server name identification), is only supported on Vista's IE7 and above (i.e. not in XP's IE7). Again, it's a Microsoft product that is hindering progression.

With Apache's mod_ssl it's possible to have multiple domains use distinctive certificates using a single IP address.

Those people generally do not understand OOP properly yet. I see a lot of people who are supposedly OOPifying their code. They may make a "database handling" class (to use your example) and then just slam all their existing functions into one big class called e.g. mysql or database. Then they proceed to call it OOP, but they also look at it and say "why bother?" and "how the hell would it be a benefit doing this?" and then they dismiss OOP. The thing is just that they never used OOP in the first place. They just used the class as a kind of namespace. One of my teachers once said something like this: "You will be working in groups to gather information about one of the things and then present it to the class so we can get general knowledge about it, and so we can turn it into a discussion. I know most people often discuss things without knowing anything at all, but we are not going to to that."

Not as far as I'm concerned. Does this happen regularly?

Watch out for memory when using a such large data set. You might want to implement some sort of lazy loading.

Meh... OOP is a programming paradigm, so obviously the language itself is not OOP. Ruby is not OOP either. If he wants to be so picky then ruby isn't OOP either. It's entirely possible to write imperatively/procedurally with ruby just as it is possible to write object orientedly (that's probably not a real word) with PHP. The fact that everything is an object in ruby doesn't make ruby OOP. The fact that your code uses objects doesn't make it OOP either. OOP is about how you write your code and as such PHP, Ruby, Javascript, etc. support OOP, but they also support imperative programming. You sometimes refer to such languages as multi-paradigm languages. A language such as for instance Haskell is a purely functional language. I don't think the blog post was very interesting nor very accurate actually. Sort of redundant actually, like "I'm here and I important ('have done billion dollar ecommerce projects in PHP') and clever (I supposedly knows what OOP actually is)".

Post hoc ergo propter hoc, FTW.

You'll do like this using mod_rewrite: RewriteEngine on RewriteRule AAAA\.php index.php

Use version control (svn, git, mercurial, etc.) and do a checkout on the production server. The server that hosts the repository and your production server should both have high speed connections. When you've committed the changes you would just update the working copy on the production server. That's where version control comes in. Anyway, I think setting up a staging server is a good idea. This should of course use the exact same configuration as your production server does. You could write unit tests and functional tests and then have a continuous integration server on the staging server that runs all your automated tests. If it fails then it's back to work, if it doesn't fail then you can update the production server's working copy. I still think you should develop locally though. It saves you from uploading every single change and if your connection dies then you can keep on working. Why? Just get a certificate per (sub)domain or get a wildcard certificate.

http://en.wikipedia.org/wiki/Scientific_notation#E_notation

A login script is essentially so simple that it's not even worth dedicating a tutorial for that. Stuff involved is essentially form processing, database access and sessions/cookies. We have a tutorial for sessions and cookies and we have one for database access and another one focusing on joins and unions. Then you have form processing, but that's fairly straightforward. You simply read from the $_GET or $_POST superglobal. You might also be interested in this blog post that talks about breaking a script/application down into logical elements the same way I just did.

Yeah the login was made directly through our smf install.

Must be a bug in SMF.