.josh

In this case, without seeing what you are assigning, yes, it is a matter of preference, a matter of code readability, but you just need to really pay attention to order of operations when it comes to ternaries, throwing in multiple assignment operators like that...you can very easily make your code behave unexpectedly.

it is the pattern delimiter. You used # in yours. You can use pretty much any non-alphanumeric char as the pattern delimiter, I personally like ~ because IMO it looks cleaner and more different than other chars, easier to see them, especially if you use modifiers (like the i modifier i added to make it case in-sensitive).

Firstly, whether or not you use the brackets is personal choice, though you certainly need them if you want to execute more than one line of code inside the condition. but as a side note, your ternary is kinda funky. The ternary would be cleaner like so: $icon = ($s_forum['type'] == 4) ? '' : ''; But on that note... you are also assigning an empty string to $icon whether whether true or false, so there's no point in having that at all...unless you typoed and meant to assign different values, you should just do if ($s_forum['type'] == 4) $icon = '';

that doesn't account for <BR> <BR /> <br/> <BR /> etc... lots of other ugly formats that browsers will render properly

p.s. i would write the regex like this: return preg_replace('~<br\s*/?>~i', "\n", $string);

well your regex could be a little more efficient, but other than that, I see nothing wrong with it, problem is elsewhere.

"force downloads" is a browser thing. It is a http header sent with the response to tell the browser to initiate download. It means absolutely nothing to server-side scripting unless you write your script to look for it and do something. Same thing w/ browsers, actually...just that browsers ARE written to look for it and do something.

oh yah you were on staging. i dunno then. I tried exact string as shown in ss and works fine for me :/ maybe try a different browser or maybe you have some kind of browser addon messing with something?

well i posted a test code tag by itself and wrapped inside a nobbc tag. did it in both quick reply and normal reply. i saw them just fine. random hiccup? I know Phil was (maybe still is) messing with some bbcode related updates...

so compare your code on the index page to that page and find the difference.

I knew if we badgered him enough one of them would stick!

works fine for me..

$zip->extractTo('image_processing/resizing/'); I don't know what your "unique folder" naming convention is supposed to be but it should be implemented somewhere in that line of code...otherwise all your zips are being unzipped to that same folder.

1) Your regex does not have any captured groups so there is not $1 or $2 2) your preg_replace doesnt't use that $replace Are you sure you are even looking at the right code? 3) you should know the song and dance by now: post examples of what the regex is supposed to be looking for and what you expect the outcome to be

This topic has been moved to MySQL Help. http://www.phpfreaks.com/forums/index.php?topic=360653.0

Was this picture a link?

you should be fine on that count, no worries. Server root is always /. The difference is what may be hiding behind the curtains depending on who is requesting it and from what context. Just like with a browser requesting a page on your website, like /index.php, the "root" starts at the designated "public root" folder that your domain resolves to. There is usually a file like http.conf somewhere on the server that basically has instructions that say "if the domain is www.xyz.com, "/" starts in "/this/folder/here/" so going to "www.xyz.com/index.php" makes the server look in "/this/folder/here/index.php" that same principle carries over when a server is running a server-side script on a shared server. So if you are on a shared server and you have a script that does like include "/somefile.php"; There is another file somewhere on the server that basically says the same thing in principle: starting "/" really means like "/[user]/". So if you start on a shared server, for your user account, your root is / even though there is technically more structure above that. The server routes it to the correct /[user account/ "root" based on ...well it depends on the server setup. Some server setups will always automatically prefix your username as the beginning dir in the document root. So for instance, if I go to http://www.mysite.com/index.php $_SERVER['DOCUMENT_ROOT'] might be /josh/htdocs/ or it might just be /htdocs/ (server may or may not show your user dir) So a relative link in an img tag requested by a client as "/image.jpg" would resolve to (absolute path from client's PoV) : http://www.mysite.com/image.jpg and internally (server absolute path) be /josh/htdocs/image.jpg But with a server-side include for instance if I do this: <?php include "/myscript.php" ?> With a shared server, the real root path would be [ic]/ and all accounts might be in a /users/ dir so from someone who has access to the real server root, they would see it as /users/josh/htdocs/myscript.php But from the user's perspective, /josh/ is the highest level they have access to, so they would only see /josh/htdocs/myscript.php or depending on server setup, even only see /htdocs/myscript.php and that is usually reflected in $_SERVER['DOCUMENT_ROOT']. For portability, like if you were to migrate to a dedicated server, you don't really need to worry about this. $_SERVER['DOCUMENT_ROOT'] should always show the root path of the user account running the script, to the "public" document root, whether the account is the root/su (super user) account or some other account without root directory access. So if you have include $_SERVER['DOCUMENT_ROOT']."/myscript.php"; It should work if you port your script from shared to dedicated, or whatever.

Okay so here is the short version Basically it boils down to this: There are two different definitions of "document root" depending what you are trying to do. The "document root" is different for these two things, because in each example, the code is being evaluated by two different entities in two different contexts. In the first example, you have a client that is looking at a relative location on a remote server. In the second example, you have a server looking at a relative location to itself. When including a server-side script in your server-side code, you need to use that $_SERVER['DOCUMENT_ROOT'] for an server's-perspective absolute path/to/file, or else make the path relative to the running script. If the /inc in /inc/head.php is in the same directory as yourscript.php that is including it, you need to remove the forwardslash prefix and just include 'inc/head.php'. If you need to go up a dir level then you prefix it with ../inc/head.php. When including an image for client-side code to be evaluated by a client, you can do as explained in the previous post. The TL;DR version Let's put this in human terms to better understand it. Most everybody has a "public" face that they share with most people, and a separate "private" face that they share with few or no people. The "public" face is the information about themselves they are willing to share with most anybody. For instance, lets say you, as a random internet stranger, ask me where I live. I might be willing to tell you the country I live in, possibly the state/zipcode I live in, and possibly even the city I live in. So as far as you are concerned, I live in /city/zipcode/state/country/. This is like your first example with the image link. You are the client (the browser on a visitor's computer) asking for the location of an image. You are provided with a relative link, and you know the domain is www.xyz.com, so as far as you are concerned, the path starts at /img/, like xyz.com/img/.., because the relative link started with a forward slash. But the city I live in is a big city. There are zones and neighborhoods and streets and houses. And even if you know my home address, my own home is broken down even further into different rooms. From my perspective I "live" at my house, more specifically, my personal bedroom where I sleep in. So from my perspective, I live in /[my room]/[house/lot number]/street/city/zipcode/state/country/. This is like your second example, with including a file in a script. I am the server, running a script on myself, referencing a location of a file somewhere within me. The script provides a relative link to some file, and the domain means nothing in this context (I can look at the domain for other purposes but for this purpose, I already know what domain I am on so it is meaningless to prefix the file with a domain) so as far as I'm concerned, the path starts at /inc/, literally /inc/head.php... but that's not where the file is really located. From my (the server's) perspective, the file is really located at /[my room]/[house/lot number]/street/city/zipcode/state/country/inc/head.php. But it's a pita to have to type all that out in your coding. That is where that $_SERVER['DOCUMENT_ROOT'] environment variable comes into play. It contains the full directory path, starting at the server root (from the server's perspective) to the root directory that is displayed to the outside world (the client's perspective). So in this example, $_SERVER['DOCUMENT_ROOT'] would be /[my room]/[house/lot number]/street/city/zipcode/state/country, so if I do <?php include $_SERVER['DOCUMENT_ROOT'].'/inc/head.php'; ?> It should work out just fine. NOTE: If you had removed the forwardslash prefix in your include, like this: <?php include 'inc/head.php'; ?> This would have made the server try to locate the file, relative to the script that is running. So for instance, lets say your script is called myscript.php and it is located here: www.xyz.com/myscript.php or from the server's perspective it is located here: /[my room]/[house/lot number]/street/city/zipcode/state/country/myscript.php If you take off the forwardslash prefix, it would try to look for the include here: /[my room]/[house/lot number]/street/city/zipcode/state/country/inc/head.php Which may actually be accurate, if that's how your two scripts are located, relative to each other. Or lets say your myscript.php is located in its own subdir (relative to root), so it's on the same level as myscript.php but in a different subdirector. Ffor instance www.xyz.com/control/myscript.php www.xyz.com/inc/head.php or /[my room]/[house/lot number]/street/city/zipcode/state/country/control/myscript.php /[my room]/[house/lot number]/street/city/zipcode/state/country/inc/head.php Without the forwardslash prefix, it would try to look for it here: /[my room]/[house/lot number]/street/city/zipcode/state/country/control/inc/head.php which wouldn't work. But you can still tell the server to look for the file, relative to the running script, by using ../. This tells the server to move up one directory level before looking for the rest of the path. So for instance if your structure looks like this: /[my room]/[house/lot number]/street/city/zipcode/state/country/control/myscript.php /[my room]/[house/lot number]/street/city/zipcode/state/country/inc/head.php You can do this: <?php include '../inc/head.php'; ?> And you can stack ../ to keep backing up dirs, all the way to the server root. NOTE: you can use ../ with the img src url that the client looks at, as well. But the difference is, as far as the client is concerned, /country is the root dir (and it doesn't even know what that dir is, it has the www.xyz.com as the placeholder), so from its perspective, doing ../../head.php would *technically* work in this case, because once it gets to the root dir from its perspective, it ignores further ../ but it will not try to look for it at /[my room]/[house/lot number]/street/city/zipcode/inc/head.php (same level as /country/) because as I said, from the client's perspective, the document root starts at /country/. One additional note to really make your head hurt if it hasn't been twisted in knots already: While this is all you *really* need to know for your purposes, note that even this isn't the complete story. Depending on the server setup, the actual real root dir of the server may go even more deeper than /my room/. This is common in for instance shared hosting environments, where multiple people share the same server. There would for instance be the real server root, and a directory for each user account and from their perspective, the root is really a "root" that starts at their account home directory. And the rabbit hole goes deeper still, because...ah fuck it, you're head probably esploded by now.

looks like from your sql query you meant to alias the COUNT(*) operation as TotalCount, but are missing the as: $sql = mysql_query('SELECT user, COUNT(*) TotalCount FROM '.$table.' GROUP BY minecraft_user HAVING COUNT(*) > 1 ORDER BY COUNT(*) DESC'); should be $sql = mysql_query('SELECT user, COUNT(*) as TotalCount FROM '.$table.' GROUP BY minecraft_user HAVING TotalCount > 1 ORDER BY TotalCount DESC'); and you should be using $data['TotalCount'] in your echo

use a session variable to keep track of whether or not the form has been submitted. example code your_form_handling_script.php <?php session_start(); if ( !isset($_SESSION['submitted']) ) { // your regular stuff here that checks if $_POST exists, validates form fields, inserts into db, etc... // if all of the above stuff checks out and form is successfully completed // (make sure to only set this if everything is successfully done; you don't // want to set this if visitor failed a validation or something, because then they won't be able to re-submit... $_SESSION['submitted'] = true; } else { // form was already submitted, tell visitor to stop being submit-button-trigger-happy or do nothing or whatever } only problem with this is if visitor clears their cookies it will destroy the session and they can resubmit. Only real way around that is to basically put the form behind a login system and store a flag value in a database or flatfile with the username and instead of using a session variable flag, check the database/flatfile to see if user already submitted. But EVEN THEN, wouldn't stop visitor from creating a new account! But anyways, if you're simply trying to deter trigger-happy people then the above code should work just fine, because beyond that, people are past being trigger-happy and are purposely trying to resubmit.

You don't need to add anything. If you do this... <link rel="stylesheet" href="/css/style.css"> ...the browser will automatically make a relative link that starts from the "public root" dir, for example http://www.yoursite.com/css/style.css (or https if the page is ssl). Alternatively, if you do this, without the beginning forward slash... <link rel="stylesheet" href="css/style.css"> ...the browser will make a relative link that is relative to your current page. So for instance if you are currently on http://www.yoursite.com/path/to/page.html it will make the link http://www.yoursite.com/path/to/css/style.css

phpretarded I would suggest in addition to reading up on how to properly use AES_DECRYPT within a mysql query, you should also read up on php syntax in general. Even if AES_DECRYPT was a php function, you still did it wrong. $row (I assume) is a variable you assigned from something like mysql_fetch_assoc or similar, which means it would be an array of data, for instance $row['FNname']. Well you can't just split up the array and its index like that. Also, function calls within (double) quotes don't work, only variables. The syntax would be more like echo AES_DECRYPT($row['FName'], 'salt']); but again, that's just "if it were..." scenario..again, and as others have mentioned, AES_DECRYPT is a mysql function, not a php function.

1) I don't see how that link provided any more details that what you already posted here... 2) Does the code I posted not do what you asked? Here is a breakdown of what it does: $string = "1811-011"; $string = preg_replace_callback( // function to match and replace a value with a LPI prefix and possible 2k if it is a 2k date '~^[0-9]{2}~', // match the first 2 digits in the string (example 19 in 1969) create_function( // create anonymous function to handle the matched value '$m', // passing the matched value to the anonymous function 'return // return the following: "LPI ". // the LPI prefix you want to add (($m[0]==20)? // is the matched 2 digits 20? "2K": // if yes, add the 2K prefix "");' // if no, nothing more to add ), // end of create_function call $string // the original string value to perform the regex on ); // end of preg_replace_callback call

$string = "1969-011"; $string = preg_replace_callback('~^[0-9]{2}~',create_function('$m','return "LPI ".(($m[0]==20)?"2K":"");'),$string);

How are you "choosing" another cat(egory)? Perhaps you added more selections to a dropdown and forgot to change the selection values?