ManiacDan

A Tuple is usually a datatype that consists of two pieces of data. Sometimes called a "pair", especially by the popular C++ libraries.

Keep $oldGroupName in a variable. Check it with every iteration of the loop.

Make a new variable called $total. $total += $pts; You could also make an array for $total, so it can hold the points for each team.

have you also tried imagecopyresized?

You could use the group_concat function. You could also simply order by the group ID, and only print it when it changes.

You're still not making sense. Tuple doesn't mean what you think it means.

Did you not read what I said? I'm not going to delete the * and type out merk_name for you.

You can form one big INSERT query with multiple values and insert it in one block. that's more efficient: <?php $query = "Insert INTO item(item_code, item_description, item_price, item_stock, item_sale, item_reg) VALUES('{$item_code}','{$item_description}','{$item_price}','{$item_stock}', '{$item_sale}', NOW())"; $last_id = mysql_insert_id(); $query1 = "Insert into item_category (category_id, item_id) VALUES "; foreach($_POST['item_cat'] as $cat_get_ins) { $query1 .= "('{$cat_get_ins}','{$last_id}'),"; } $result1 = mysql_query(trim($query1, ','),$connection); ?> mysql_insert_id is the perfect function for this situation, yes.

I told you already, but I'll try to explain again: Regular expressions are their own language entirely. They are not PHP, SQL, or anything else you're familiar with. Inside regular expressions you can have parts of the expression wrapped in parentheses. Those parentheses, when used in preg_match, are used as "capture groups." Capture groups are put into the matches array as their own entries in the $matches array.

The browser won't care? If I have a space in my URL...it shouldn't work.

Did you read the TWO posts now about other things you can try? Specifically, the one above yours that talks about how you don't seem to have read or understood the posts you've been given.

Ignace, those URLs wouldn't work anyway since the HTML would be invalid. bbmak, preg_match_all puts an array of matches into the third argument, in this case it's $matches. $matches[0] is an array of the matches for the full pattern, then $matches[1] through $matches[9] are arrays of the sub-pattern matches, the items inside parentheses inside the expression. When you use a string like $location as an array, it becomes an array of characters, which is why you were getting the individual letters of the string as results. Regular expressions as well as array access are both really complex problems, so this is a very very basic answer.

This is...pretty much the entire purpose of PHP. The direct answer to "how do I do this" is "use PHP." You don't need a templating language or anything, just take the query xyph gave you and start dumping the data out to the screen, performing more queries as necessary.

Only select the columns you need. If you're only displaying merk_name, then only select merk_name from the table. Then your DISTINCT will work. Also, this is not the right way to set up your database, look into normalization and third normal form. Your "merk"s should be their own table, with each row linking back to them. That way, you could have done a select * from merk to get your dropdown.

Ignace's expression is correct as long as all the URLs are "double quoted" and none are 'single quoted' or unquoted at all. This should get all of them: if (preg_match_all('!(href|src)=[\'"]?([^\'"\s]+)[\'"\s>]!', $string, $matches)) { foreach ($matches[2] as $location) { //use $location } }

And when you added debug output, what happened? We can't just look at this and figure out what error message is being thrown by mysql. Make use of mysql_error to figure out why that query is failing. Also, unrelated to the current problem, but you have no security whatsoever. There's no hashing on your password table and there's not even basic sql injection protection.

...and what's the problem here?

There's a number of things wrong here. First, your thread title is absolutely useless. Use the title to actually describe the problem. Now, to your actual code. Look at the error message: mysql_select_db is failing, with the error that the supplied argument is not valid. What argument are you supplying to that function? Let's look: mysql_select_db($database_cicpriva_reg, $cicpriva_reg); So your code believes $cicpriva_reg is the database object. Why isn't that correct? Go look at where you make the database object: $dibby = mysql_pconnect($hostname_cicpriva_reg, $username_cicpriva_reg, $password_cicpriva_reg) or trigger_error(mysql_error(),E_USER_ERROR); As PFMaBiSmAd and mikosiko have both already explained, $dibby is not $cicpriva_reg Your database column names are unusual, but not technically incorrect if this is MySQL. You should try to avoid using special characters like / and \ in your column names, and stick to only letters, numbers, and the underscore character. That ensures interoperability.

Are you sure the tags are part of the file? Some music players store the tags outside of the file itself. Also, bumping threads is against the rules. You posted in the middle of the night US time.

PHP is a young language. Tutorials which are 5-6 years old are no longer valid, yet they still exist because that's really not that long ago. Using the session in the URL is wrong. Stick to books and tutorials written since the release of PHP 5.3. It's part of the request header, visible from $_COOKIE since it's a cookie. I don't believe it's in $_SERVER, that's another part of the header. It is not in GET or POST Welcome to web programming. 5 distinct languages, 10 technologies, and an entire theory of programming. Good luck. The problem you're having is twofold: 1) Most of what you're saying isn't part of "web programming" at all, it's part of "internet communications." The REMOTE_ADDR that you see in PHP's $_SERVER array is not special to PHP, apache, or the web. It's part of TCP itself. That same header is where cookies live, but cookies are unique to web development. 2) It's difficult to answer such a deep question without getting too technical. To give you half the answer is disingenuous, because then you end up thinking you have the whole answer when you don't have much at all. Everything is built in layers. Honestly, if you're that interested, start at the OSI Model. That's the actual "stack" that governs internet communication as a whole. Understanding that allows you to realize that Apache and PHP sit at the uppermost layer (layer 7, application). Once you know how internet communication works and how actual messages are constructed and what constitutes a "connection" (which is really just random packets), then you understand why client-server programming is stateless (and it's silly to try to maintain form post state, like we discussed before). A good top-level summary of PHP is: 0) The user clicks a link, which instructs his computer to set a GET (or POST) request to your server. The browser formulates the base packet headers. 1) Other things (apache, the OS, the network card itself) manage communications speeds, getting data to and from the client, and handling communication metadata (IP address, user-agent, cookies, forwarding headers, proxying, cache control, and dozens of other pieces of information that come through with every request). POST is part of the header as well. 2) PHP receives a request and $_SERVER, $_COOKIE, $_GET, and $_POST already exist. PHP scripts are, for the most part, safe to assume everything in those arrays is correct (correct, not valid). 3) PHP processes its data, performs queries, reads files, etc. While the session is unique to each user, and $_POST and $_GET (as well as all other script variables) are unique to each request, the files and database are unique only to each server. It's confusing, and must be thought through extensively before you get good at it. 4) PHP spits out (usually) an HTML formatted string, which may or may not contain references to other documents, CSS, JavaScript, etc. 5) That message is transmitted to the user, along with all the header information relevant to that request. The headers that the server sends include the content type, cache control, location headers, status codes, redirects, cookies, and more. This is the packet header, not the HTML <head> tag. Do not get them confused. 6) The user receives the packets from the server and constructs them into a displayable message, rendering the HTML and executing the javascript on the user's end. Javascript is executed on the user's computer and has no access to anything but (usually) the current page contents. If any additional documents were linked to (like <img> or <script> tags), they are fetched as well. 7) A request has been complete, from click to display. PHP clears out memory entirely when your script dies. Each PHP "program" runs for less than a second apiece (if you do it right). PHP also clears out physical session files periodically based on the php.ini settings. Additionally, your operating system clears out /tmp periodically based on file age, since that's what /tmp is for. You are not responsible for garbage collection on any level. The only exception to this is if you store garbage in your database on purpose (like if you store sessions in the database) or if your scripts are using so much memory that they need to be cleaned mid-execution.

Not a valid reality, unless there's a very serious security hole in the browser itself. If the browser itself is compromised, your site is just as vulnerable as everyone else's. Both methods are valid. Note that absolute paths are probably always preferred anyway, so in case you move a page to a different "depth" in your site, all the links still work. Kicken addressed this, but I wanted to back him up: Negligible. All true. You can use php.ini to make the session cookie last longer than the current browsing session, but that's rarely done. The serialization format is not the same as the one for serialize(). It's very similar, but not the same. Nobody knows why, it's annoying and stupid. The reason why I mentioned tabbing is because if you use $_SESSION['formCheckHash'] to store this form validation hash, what happens if you draw two forms back to back in the same session? There will be two hashes, and only one value. One form will never be valid. I don't bother using form validation like this, it's too much of a pain in the ass. Rely on your other security methods to secure the session as a whole. PHP (and the web in general) is stateless. There is no "flow". Don't try to arbitrarily enforce one, it ends with this kind of unsolvable problem. As for the whole "what is the session ID" question, which is a few paragraphs: You don't ever have to know what the session ID is. Until you start writing your own session handler or changing fundamental behaviors of the session in general, you don't care about the session ID. You don't have to validate it, you don't have to pass it anywhere, you don't have to manually set it, you just trust that session_start() always establishes a session, using an existing one if available. Sessions are maintained by cookies, so while technically "they are passed with GET or POST" is true, it's actually part of the communication header itself, and is processed by the web server. The session comes through on all communication from the browser, including ajax calls. Yes, the sessions are automatically destroyed by the OS and/or by PHP, so if you close your browser, and someone else uses your session ID two hours, it's possible the session file was destroyed. However, session cookies are never stored on your hard drive, so it would be difficult, if not impossible, for someone to hijack them like that. Almost always. Some database technologies make pagination really unreasonably difficult, but for the most part as long as you use LIMIT clauses, you're fine. SSL has nothing to do with it. GET does not show the session ID. Anything you see with ?sessionid= in the URL is 5+ years old and should be disregarded. It's no longer a recommended method. The session ID is included in the communications headers alongside the message, it is not part of the message itself. Use POST for POSTing data, and GET for links and GETing data. This is the most commonly invented "solution" to man in the middle attacks, but it doesn't think about the asynchronous nature of the web. What if you make a page which contains ajax calls, and the user makes two simultaneous ajax calls AND submits a form at the same time? You'd log them out. Session garbage collection is built into PHP and you don't have to worry about it. If you move your session directory back to /tmp, then the OS will also clean up old sessions. Yes

First of all, I really love this post. It was really well written and I appreciate someone who tries not to ask for handouts. This is all fine. Overkill, actually. Good for you. SQL Inection is prevented through either PDO bound parameters, or by wrapping all string inputs in mysql_real_escape_string and all numeric inputs in floatval. There's more to the theory, but that's the baseline answer. The session ID is always valid as long as the temporary file still exists. The security problem is usually session hijacking. You can prevent that by either going full SSL (like facebook did) or by storing user-agent and IP in the session and validating it every time. Rotating the session ID on every page load is a tactic used by the super-paranoid who believe man-in-the-middle attacks are likely and not just possible. I'm not saying it's a bad idea, but it feels like overkill. The session works like this: - You call session_start for the first time - A temp file with a random name is created - A cookie called PHPSESSID (or the cookiename set in php.ini) is added to the header, with the value of that cookie being the name of the temp file - Anything you add to $_SESSION is serialized in a custom format and stored in the file - That file is unserialized every time session_start is called thereafter, and placed into $_SESSION. session_start checks for the existence of the session id cookie, and will either create a new session, or load an existing one No data in the session is passed to the user, it is completely safe unless you purposely echo session values (or the server is compromised, obviously). You can rely on POST data up to a point. It CAN be tampered with. If you really want to secure your post forms, do this: -Hash the microtime and username of the current user -put that in a hidden form field -put it in the session -when the form is submitted, compare them Note that this tactic will stop your site from working in multiple tabs at once, as the session is global for the whole browser window. If you're really this concerned about your sessions, simply switching to straight SSL for the whole site would solve all your problems. The rest is just thought exercises, and none of them are 100% secure. It's like home security. Installing steel plates over your windows is 100% secure. The rest is just locks on a piece of glass. But steel plates are expensive and ugly. If anything else is still confusing, let me know.

What is the problem here? Converting this to PHP is as easy as adding punctuation: if ( $current_bid < $reserve ) { //bids too low } else { $current_bid = $high_bid; $c = $Data['ends']; } Of course, this assumes a LOT about your structure and code layout. If your question was "write an auction house script for me," then we're not going to do that.

The political discussion that had started in this thread is now split into its own thread. Please use this thread to discuss domain registrars and web hosts only.

A fox news reader!? GET HIM!