Antonio Conte

Sounds good! Looking forward to seeing the result. DBs take a while to settle usually. Functionality is added to the site, you do some changes here and there, another use-case requires a restructuring, things don't perform well enough... The list goes on. Changes has to be made accordingly and it can be a pain in the butt. Things always take way longer than expected too. Think the task will take one week? How about two! It's also hard to anticipate what you'll struggle with and it's often the one thing you expected to be a piece of cake. Weird, huh. Well. Anyways. Good luck! Sounds like a fun project.

You must be outputting something before trying to redirect. Do you include any files that could cause the issue or anything similar? I guarantee you this is the problem, so keep looking. Take specifically notice of the file and line number the error message is referring to and start looking from there. Good luck.

True that. It's often a nice way to not over complicate stuff. I use null values a lot myself. Just make sure no values are set to null unexpectedly. Say a query is ruined by bad input, and suddenly you have "Shoes" at the column's value. I'm pretty sure that'll default to null on an integer column. Just keep that in mind, as it can be hard to debug. That's my only inclination to use an unusual value like -1. What are you building here btw?

I would say there's no definite answer here, but your solution sounds good. An alternative is to give the items a specific status code, like -1. That way, it's easier to see that it's explicitly set. Null is totally fine though. There's some pitfalls using null (invalid input data = null) but I don't think it should give you any real problems.

Nice work, man. Sure someone will appreciate this.

Hard to tell for me simply by Looking at code. Make sure you set error_report to a low level and make sure display_errors are true. If there's namespace errors, you should get errors here.

If you are on Linux/Unix (OSX) ignore this. If you are on windows, you should get a command line tool like Git Bash. It'll follow along if you ever download GitHub for Windows or download "msysgit". Git Bash is close to regular Linux/Unix syntax, so the syntax should work for all operating systems moving forward. With that done (or ignored), you want to create a .bashrc inside your users/%username% folder. That is the same folder on both Mac and Windows to my knowledge. Not sure about Linux. (But I would guess so) There create a .bashrc file (notice the leading dot) and open it with any editor. Notepad/Vim/Nano/Etc. Replace the user with your own. $ cd c:/users/thomas/ $ touch .bashrc $ notepad .bashrc Inside that file, you'll need to somthing called an alias: alias mysql="D:/xampp/mysql/bin/mysql.exe" # Recommend to add this too # Defines a shortcut ls handle to view hidden files, etc. alias ls="ls -laG" Here, I've defined that 'mysql' is an aliases for the full path to the MySQL executable. This is likely a little different for you, and is based on XAMPP MySQL here. The same principle is true for Mamp though. Consider doing the same for PHP, composer and any other good stuff you might have. Save the file, restart the terminal (it won't be available otherwise) and there you go. Just ask if you have any questions.

If you read some of the comments, you'll see that the blog post has some inaccuracies. To cut it short, this is not really good code for you to learn from. You are absolutely right about return values in a constructor - it doesn't work. The general principle of Rest is really good and one you should stick with. What it basically does is allowing the client to utilize any programming language to get a response from your server. I could be coding Ruby, PHP, Java, Python, whatever, and still be able to use something like a cURL-request to send requests and get responses from your server. Good luck and ask if you have other questions.

The difference here is that DOMDocument is an object that builds a structure internally by loading XML. To make it as usable as possible, the API was probably written to allow invalid XML. In other words, that an implementation choice. Next, you need to study the API better. While DOMDocument::schemaValidate() takes the Schema as String param, DomDocument::validate() will validate according to the internally linked schema. By changing your code to the following, you should be able to remove the reference to the DTD. $xml = new DOMDocument(); $xml->load('books4.xml'); if ( ! $xml->validate() ) { echo "invalid<p/>"; } else { echo "validated<p/>"; } If that should not work for any reasons, you might need to play around with some constants/changing some properties. Here's a link describing a solution: http://www.php.net/manual/en/domdocument.validate.php#84905 Good luck.

Google it. The installation is pretty straight forward. My MacBook broke yesterday, and my iPhone is hard to write on. Hope you don't mind.

Did you ask him about Composer? I study Computer Science myself, and the teachers aren't necessarily always updated on the newest technologies. Composer is "the new" pear. Pear is a pain in the butt to use, so spare yourself the agony and jump on to the composer train.

I agree, Jon. I successfully used it in a project recently and would love to use it for local businesses here in Norway too. It'll come, though. It's to great for it to keep it to a few countries in the long run. Also, Larry; Norway is one of the few EU countries not affected by the global economic crisis. We are a very highly educated people with a strong IT community. Make Stripe support the Norwegian Kroner, please!

Pear is the previous way of doing things. You should instead download composer and install the package found in the link below. All major software in the PHP community is moving in that direction, and you should move in that direction to. Things move quickly in the programming world. Packagist and Composer is just another package repository, though, so this is more of a move in infrastructure than in the way of actually doing things. https://packagist.org/packages/phpdocumentor/phpdocumentor

Yeah, Jeapee. Nice way to learn some Ubuntu, tweaking Apache, install different language invironments and things like that. I'm not really into the server stuff, but I've recently gained interest in it following a class I have on Ubuntu and Apache.

Try uploading the image to some image uploading site. I can't remember anyone now expect a Norwegian one called www.bildr.no, but you can at least use that. Something you can try is to place these on the top of your script. Some of the problem might be connected to your IF checks with $_SESSION. If those keys are not found, the code below might reveal some of the problem for you. init_set('display_errors', 1); init_set('error_reporting', -1); Get back to us.

Huh? You have a total of four posts on this forum, in two threads. You don't really have to be a rocket scientist to figure it out. http://www.larryullman.com/forums/index.php?/topic/2717-help-on-ch-15/

Dude. I wrote you some steps to take in your first thread. Have you tried anything of that yet?

- Post your query here. We can't guess how it looks - Run it something like PHPMyAdmin and see where it fails. - Assign your query to A variable instead of directly inside mysqli_query() and use echo on it. Make sure variables (If any) inside your query assigns values as expected.

You have an error in your SQL syntax. That's the problem.

I know, Jon, but given how you phrased it, I wanted to clear that up. It's a natural next step to search for "CSS reset", and I wanted to clarify for anyone else reading the post moving on. I actually think we discussed resets vs normalizing something like a year ago, and it was then I switched over myself.

Normalizing is currently considered a better practice than CSS resets. http://nicolasgallagher.com/about-normalize-css/ If this is the only problem though, just target the select element in CSS and set the margins yourself: select { mmargin: 0; }

As stated earlier, it looks like you don't have set auto_increment on your primary key, but instead handle that through code. You at least need to confirm or deny that before we can really help you out. Haven't stated how you integer size is on the key neighter. We need to know... You can do some steps until you've given us the info: 1. Go into the "operations" tab on the table. If you have an auto_incremented primary key, you should see a auto_increment value there. Make sure that the value is in fact one higher than your latest added row. 2. In the same operations tab, look for some options at the bottom left. Try clicking "Check table", make sure it's ok. Then do "analyse table". 3. Increase the int size of your primary key/key that's related to your problem. It can't break anything, only prevent a problem in the future. 11 is a reasonable number.

I guess your program handles the incrementing itself? Try setting the primary key to auto_increment, increase it's size and see what happens. Also, check your relationships. If other tables depend on the key, you might want to hard link that using foreign keys and looking at transactions in the DB handling code. You might also want to manually set the increment in your table to the latest row. Most of these things are found under structure or operations tabs when you look at a table in phpmyadmin.

Keep in mind that if you have auto_incremented primary key, deleting rows won't affect anything. It's not really the total number of rows that's interesting, but what the ID value is. Even failed inserts will in most cases increase the auto_increment value and deleting rows won't decrease it. The easiest way to at least discard that is is the problem is to click "structure" when you browse the user table, click "edit" on user_id and setting it to 11. If it works, that was the problem. If not, we'll have to dive deeper into the problem. Doing the change will also further-proof you a little bit.

Sorry, I meant your keys in general, not especially the primary key. In my case one key was was set to something like SMALLINT(3). When row number 1 000 was inserted (and the key thus had a size of 4) the program couldn't insert more rows. This was a little bit hard to debug, as the problem was not even related to a primary key, but when I tried a manual insert into PHPMyAdmin, the problem was found. We insert 10 rows into our DB each football round in our league. (10 games * 36 rounds) * 2,8 seasons = 1080 match ids, and a too small key for storing the match_id. The program therefor ran nice for almost three full football seasons before crashing. It's really an edge case, but it's the only thing I can really provide at the moment.