ManiacDan

Were you hired to clean up their act and take the reins of a faltering development group? Or were you hired to be another developer in that group? If it's the former, tell them that they're wrong and you know the right way to do things. If it's the latter, do what you're told. Perfectly valid reason not to pull down production data to a dev database. I don't even have access to the production database and I'm the second highest ranking dev at my company. There are credit cards in the production database. Nobody gets access to customer credit cards unless they absolutely need to. This, again, is a perfectly valid dev setup. When your site is small, it makes sense to have all the rows in dev and in prod at the same time. But when it's big...do you really think facebook has a dev database with billions of user profiles in it? And trillions of status updates? Sometimes dev is a mini version of prod. You're supposed to be smart enough to know algorithmic efficiency just by looking at it. Not unheard of, and not even standard practice. Unless you can follow this up with "the last 10 companies I worked for all ran hot copies of production" you shouldn't put this in your list. They know this already, and they've probably figured out a way around it, either by expecting you to write code which assumes large data sets, or by having a staging or prod-testing server which runs off the real data set. If this wasn't told to you when you started, ask. There's a document somewhere. If their developers are all honestly flying blind with no idea of the database structure, there's bigger problems than what you've been discussing. Very few companies will allow you to fix something that isn't broken. Every change, no matter how small, could break something else. OOP is, all other things being equal, much slower than spaghetti code. The efficiencies come from design and re-use, not execution time. Money is more important than writing code you can be proud of. And that, right there, is why this codebase sucks. Just go with the flow and keep your eyes open for more opportunities.

It's not looping already?

Any chance you could just spit out HTML and save it to PDF like I suggested? Seems very easy.

When people like this actually get their homework done for them by other people, they end up as the entitled d-bag junior devs who deliver the code that everyone hates. Let's turn this thread into a complaint about them! Today, my entitled d-bag junior dev committed a "utilities.php" file containing this code: class yesNoType { const Y = 'Y'; //string const N = 'N'; //strnig } Problems with this code: 1) PHP already has a boolean type 2) This class replaces a simple 'Y' with yesNoType::Y (which, you'll notice, contains 'Y') 3) The comments are supposed to be phpdoc blocks. 4) The comments are misspelled 5) Despite being named "type," this const struct cannot be used as a datatype, since it has no value storage. Literally, its only purpose is point #2, which replaces a 3 character string with a 12 character one. Do your own homework.

Christian meant "someone, somewhere, just wants to import your data with a single command and be done with it." There's no reason to export your database to a PDF so human beings can re-type everything into another system. That's stupid. If they really don't care about the inefficiencies and they insist on a PDF, have PHP spit out the document in HTML with all the tables and whatever, then install a "print to PDF" plugin for your OS. Everything but windows does it out of the box.

Sorry guy, email your professor and beg for mercy. programming is hard, and you're just going to be back here next week if we do your homework for you.

There are a LOT of problems with these scripts. For one, change your database username and password immediately, you posted them online. go, now, before you finish reading this. Change them. Now that your password is changed, you're unfortunately going to have to be more clear. Your original problem statement: What params are different? Why did you decide the solution was sessions instead of cookies? You say you changed TO cookies, do you mean AWAY from cookies and TO sessions? Do you realize that student.php uses $pass without ever getting it out of the session? Maybe that's your entire problem. If you're not seeing the warning that line would throw, you're developing without error_reporting turned on and that's wrong. You can never write good scripts if you have all your error reporting turned off.

Google gets millions, billions of simultaneous hits. I worked for a relatively small social network (5-10% the size of facebook) and peak usage would top 200,000 clicks per second.

Thousands a day? That's nothing. Seriously. I've worked on sites with hundreds of thousands of hits per second. MySQL can handle it. Use a database, that's what it's for. If it gets too slow, split this data off onto another database. Flat files are the wrong solution.

strftime() also respects the current locale, so if you use that you can get the french/german/spanish month names easily.

Are you using include() or require() to pull in the file? I don't see it

Do not ever use shell_exec() unless you're positive you know what you're doing. I could easily delete your whole website with this form. Basic syntax errors in this code means you're not ready for the security concerns around command line execution.

That means you're re-drawing the entire page. A form submission, as long as it's not interrupted with AJAX, re-loads the whole page. Put the conversion code alongside the output.

You really should be using a database for this. Also, serialize() is not meant for this. The format changes between PHP versions. Serialize() is meant for very short term message passing, not long-term storage. Databases would be more reliable. As for the actual question: the mime type doesn't matter. It's being determined dynamically and is not actually part of the file. Some of your files look like strings, some look like binary data. Regardless, the file is the file and opening it in a plaintext editor will allow it to be edited. Just ignore this and stop checking the mime type.

Is there a reason you're doing this?

If you don't understand a word in a post, you could google for it, read its wikipedia entry, or ask for more information. If you're completely out of your depth on a problem, you need to understand that some of the solution might be unknown to you.

Well, step 1 of figuring out what's wrong with yours is reading the error: Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/{myusername}/public_html/{sitename}/cms/home.php:10) in /home/{myusername}/public_html/{sitename}/cms/logincheck.php on line 2 Cannot send header information. Why not? The headers are already sent. Why were the headers sent? output started at /home/{myusername}/public_html/{sitename}/cms/home.php:10 Find that file, find that line, stop outputting. Also, don't run stripslashes on anything, it's deprecated. if your web host requires it, get a new web host which is less than 10 years out of date. You also do not need mysql_real_escape_string on values you'll be running through md5(), and even if you did, you would run it AFTER md5(), not before (but don't run it at all since md5 strings cannot contain sql injection)

Oh, so you have a comma-delimited list of items in a database column? That's why we're unable to help you: that's wrong. Make a second table which links these two, then you can just use LEFT JOIN to get every piece of data you need.

what is in the column artist_base, and how does the supplier table relate to the other two? You seem to think artist_base is important, but it's a long string field which doesn't have an ID in it.

If the directory is actually LOWER, that means it's DEEPER into the tree, and won't work. Always use absolute paths starting from $_SERVER['DOCUMENT_ROOT'] so you don't have this issue.

All of this code is commented out. What query do you have already? Show us table structures and example data/output

Wait...why do you say you use xyph's method? Xyph's method is multiple tables. You cannot dynamically remove an item from a delimited list stored in a database column. you have to pull the data out of the row into PHP, explode the list into an array, search the array for the item to remove, remove it, implode the list, and then update the database table. Or, as everyone has suggested, you could make your database design correct, because that's how you avoid this problem.

My database teacher barely spoke english. I had enough trouble with "row." Maybe if I had known he was trying to say "tuple" things would have made more sense.

Then what is the purpose of the user_id cookie? If it's just to pre-fill the form fields for login, then that's fine. It sounded like he was going to automatically log the user in just based on the ID in the cookie.

HTML5 is not a real thing yet, it's still in draft state. Some browsers will check for these proposed types and handle them properly, but it's not technically valid as of this writing. Also, the w3c is not related to w3schools and you should not use w3schools for anything, even basic research. The actual spec has a lot of good stuff in it, including built-in validation for the "number" type. Most of it isn't in use by anyone yet, because the spec isn't finalized and is subject to change.