.josh

$array = array(2,6,11,17); if (in_array($_SESSION['userid'],$array)) { // true }

How are those references stored? That is, 1 has 5,8,15 associated with it. Is "5,8,15" stored as a string or something? Also, if 1 directly connects to 5, how come 1 isn't in 5, as well?

possibly with exec or shell_exec

Mine was a bit more in-depth.... - It accepted any image format that the gd library can handle. - You could have the image resized first - You could specify x1,y1,x2,y2 coords to asciify a target area. - It "weighed" the pixel color and matched it to a certain ascii character, to give it more depth. For instance, '#' has more of a presence than '.' So '#' was used for darker colors and '.' was used for lighter colors. My ascii palette consisted of like 10 'shades.' or something. - You could specify how many ascii characters used to render - Render it in color or black and white (black and white ones looked better the more ascii chars you used) - Option to save the output to a file I think there was 1 or 2 other features but it's been a while. Like, I know I was working on user being able to enter in their own ascii chars (to make your own palette), but I'm not sure if I finished that or not. I'll have to dig around for it.

<?php mysql_connect("localhost", "designby_x", "password") or die(mysql_error()); mysql_select_db("designby_x") or die(mysql_error()); $result = mysql_query("SELECT frozen FROM members WHERE username = '$myusername' AND frozen = 'yes'") or die(mysql_error()); if (mysql_num_rows($result) > 0) { header('location:frozen.php'); } ?>

Although...it's pretty hard to enforce copyright on scripts. You aren't able to just look at code unless you gain the right server access, and even if you did, it's pretty easy to alter script enough to keep from infringing copyright. That's why people attempt to obfuscate and encrypt script files.

Kind of losing focus but...right. Treat cookies in general like javascript or ajax. Something to enrich your site, but do not depend on them for your site to function.

Basically when you start a session a session id is generated. By default it is randomly generated and stored as a cookie on the client. You do have the ability to specify your own session id, as well as regenerate it. You can also pass the session id through the url via the GET method (like you did with page.php?foo=bar in one of your earlier threads) to keep the session alive, if the user has cookies disabled. The session variables are stored in a special folder on the server. On a shared server everybody's session data is stored in the same place. Since it is possible to set a specific session id, it is conceivable that you can use a rainbow table or some other algorithm to assign random session ids and do a $_SESSION vardump, accessing other people's sessions on the shared server. Now, that isn't as scary of a thing as it sounds. For one thing, the id is encrypted. It's pretty hard to decrypt it. But regardless, if it makes you sleep better at night, you also have the ability to specify your own place where session information is stored. So anyways, the actual session variable:data is stored on the server in a flatfile, and the session id is used to access it, and the name of the session variable is used to find the data associated with it. In principle, it more or less works like a flatfile database (except no fancy queries with sort bys or limits or joins or anything), except that when you close your browser, the cookie is automatically destroyed, thus ending the session on the client-side. Also, if there is no session activity (page requests with session_start) for x amount of time, the session times out. I'm not 100% sure but I think you can set the timeout length in php.ini or somewhere, and I think the default timeout is like 9 minutes or something. You can also in your script unset session vars and manually destroy a session.

well I'm hoping that that's pseudo-code. In actuality it would look more like this: <?php session_start(); if (!$_SESSION['logged']) { header("Location: login.php"); exit(); } // rest of your code here And you'll know it works because the only time you create the session variable is if the user logs in and the name/pw matches. If they didn't go through the login.php and match the name/pw combo, then $_SESSION['logged'] wouldn't exist, and if it doesn't exist, user gets redirected to login script. Or you could log the access attempt or whatever else you like, inside that condition. Read up on how sessions work to understand how the session variable gets carried from page to page.

You can use curl to interact with other servers. For instance, serverA can use curl to post info to a page on serverB and retrieve the results (if any). file_get_contents, as darkwater said, simply grabs the page (the output, as in, what someone's browser would see) and puts it into a string.

form value is called which_date but you assign 'which_month' to $curr_month

think you're looking for rawurlencode. js example (from w3schools.com): <script type="text/javascript"> document.write(escape("Visit W3Schools!") + "<br />"); document.write(escape("?!=()#%&")); </script> vs. php echo rawurlencode("Visit W3Schools!") ."<br/>"; echo rawurlencode("? !=()#%&"); js output: Visit%20W3Schools%21 %3F%21%3D%28%29%23%25%26 php output: Visit%20W3Schools%21 %3F%21%3D%28%29%23%25%26

well yeah, but we're talking about what you're thinking about when you watch that sort of stuff happen to other people, not what's happening to you firsthand. I will certainly agree that most of us are not sadists when it comes to personally being in the bad situation.

One thing: there's no reason for you to be doing a blanket query and returning your entire table every single time, because you're only using 1 row each page load. Move the $x assignment to before the query and then base your query off of $x (SELECT * FROM $tbl_tableTest where ID = $x)

I'm not disagreeing with you guys; I'm sure that the "looking out for danger" does play a factor in there on some level. I'm willing to bet that % even goes up the closer to home the news is. I wonder if there's a study on that, or it would be interesting to run a study on that, if there's not. Anyways, I think Dan is closer to the truth on that count. One could indeed argue that we're interested in watching it happen to someone else, so as to better protect ourselves from such things in the future. We can better understand what we'd go through when it happens, so it won't seem as scary and mysterious, etc.. blahblahblah. But that doesn't really explain why we watch the same stuff over and over and over again. Also, the tendency of people having to 'learn the hard way' seems to negate Dan's theory. That is, people have a tendency to not truly take other people's advice, warnings, etc.. because they somehow don't think they will fall victim to the peril. This tendency contradicts the notion that people would watch that sort of thing in the interest of self-preservation. So why do we really like watching that sort of thing? My theory is that we're all a bunch of sadists. We like violence, competition, conflict, etc...be it games or solving problems, etc... humans seem to get off to it. We want to assert our dominion and influence over others. We want to command. Survival of the fittest. Your pain/bad luck == one less person for me to compete against. I'm running a race and the guy ahead of me and he trips and falls. Sure, I may feel sorry for the guy on some level, but it can't be on a higher level, because that kind of defeats the purpose of conflict/competition: to win. Sure, I might consider what he did wrong so I can avoid the same peril, but as mentioned, people tend not to think about that, because they tend to believe it won't happen to them. I believe that the highest thing on my mind is "Yes! one more person down, I'm that much closer to victory, RAH!" And I believe that the closer you are to victory, the less the chance of you feeling sorry for the guy who tripped and the less the chance of you considering it might happen to you, it will be. 100 yards to the finish line, down to me and one other dude. Forget anything else, just focus on moving those legs as fast as possible. He trips. "HELL YEAH I'M GOING TO WIN WOOT WOOT WOOT!!!" Yep, that's what's gonna go through my mind. And that makes me a sadist. His pain == my pleasure. Oh I'm sure that there are people out there that would stop and help the guy, even if it means they'd lose. But a) that just points out that you don't win by being the nice guy, and b) most people won't stop. Bottom line is, some of use are downright afraid and concerned and heed the folly of others. Most of us probably are the same on some smaller, unconscious level. But at the forefront, face it, most of us are sadists.

Okay so I found the bug. I was fairly certain of what it was last night. Just too tired to confirm it. Problem is that when you go back to a previous user, and add more to it, it overwrites part of the next entry, since the next entry starts at the byte position after the previous one. One way to fix this is to create a fixed line length by padding the line with spaces. Basically same principle as like in a database char type column where if you have for example char(20) and the data is 10 chars, it will pad it with spaces to make it 20 chars. So for instance if you want each line to be a total of 50 chars long, you would just do 50-strlen(data to insert) to find out how many spaces to pad the data with. Problem with this method is if you're unsure how long each user's line can get. If it can get longer than the max length, then we're back to square one. Another way is to make use of a 3rd, temporary file. Basically the idea would be that every time there is a match on user (not a new entry), you would start a loop that loops through each line of the destination file and writes each line to a new file (basically copying destFile to tempFile, line by line. Throw in a condition to write the altered line in at the right time, finish writing the rest of the lines, save the temp file as destFile and delete the tempfile. wash, rinse and repeat. Advantage of this is that you don't have to worry about how long each user's line will get, because each line would be written to the end of the file. Disadvantage of it is that it's throwing another file and another loop into the mix. More resources, longer processing time, etc.. but..you can always break the process down to a couple hundred lines at a time, to avoid possible timing out. Anyways, if your source files are already sorted by user, the already posted code should work fine. If it is not, then you can consider adding onto the posted code, with one of those 2 options. Or maybe you or someone else can think of a better option. Lord knows, I do have a tendency to over complicate things. Or...another option that involves using a database: Make a table with 2 columns, one for user, another for value. Read the file line by line, exploding the line to have user/val separated. Insert the line into the table with user in user column, val in value column. Then you can select the rows ordered by user, run a loop that builds the string until user changes, fwrites the line, wash rinse and repeat. Or hell, it may very likely be possible to write a sql statement that will format the output for you. Maybe doing an inner join and a substringed concat or something. Not sure though. I'm not a sql expert.

I wrote a script a while back that turned a picture into ascii art. Not really a difficult thing to do, but it's novel.

What an earth made you decide to look into starting a certificate authority? If you just saw certificates being handed out for x price and thought hey, now there's some potential! Then as corbin said, you're mistaken. There are very few actual certificate authorities. By far and large, you have vendors who resell them, and by far and large, it's hosting companies who buy them and then offer them as part of their hosting packages.

How do you suppose to get something done or even ask for help, when you aren't even sure what you're working with? Unless I misunderstood, you asked how to return results containing submitted data. names John Mary Greg Rita Return all names with for example 'a' in them, right? Use the sql LIKE comparison. Instructions on how to use it are in the link.

You need to put your data in your database. You can put it in by hand or use a loop to insert those arrays into your table. Once your data is in your database, you can get rid of those arrays. Since it looks like you're wanting to pull info one row at a time, the only part of the pagination tutorial you really need, is the part that checks to see if the current page number from the $_GET var is valid, and generate a prev/next link from that.

Okay so I was bored. Here's what I came up with. Idea is to loop through source and destination file 1 line at a time, instead of making a giant array. <?php // open source file for reading $sourceFile = fopen("data.txt", "r"); // while not end of source file while (!feof($sourceFile)) { // get the current line and explode it into an array $sourceLine = explode(',', fgets($sourceFile, 4096)); // set found to false because we haven't found a username match yet $found = false; // open destination file for reading and writing $destFile = fopen("data2.txt", "r+"); // while not end of destination file while (!feof($destFile)) { // find out what byte the file pointer is currently at (so we know what line to change) $lineLoc = ftell($destFile); // trim the current line (to get rid of the \n) and explode into array $destLine = explode(',', trim(fgets($destFile, 4096))); // check to see if the current user from source is same as // the current user from destination. If it's a match.... if ($sourceLine[0] == $destLine[0]) { // remove the username from the source array array_shift($sourceLine); // append source info to the destination array and implode to a string $newLine = implode(',', array_merge($destLine, $sourceLine)); // move file pointer to the right line (because fgets moved it forward to the next line) fseek($destFile, $lineLoc); // overwrite the old line with the new line fwrite($destFile,$newLine); // set found to true $found = true; // since match was found, no need to keep checking lines, so break out of loop break; } // end if match found } // end while destFile // if we did not find a match... if ($found == false) { // move pointer to end of the file fseek($destFile, 0, SEEK_END); // add the source line to end of file as new entry fwrite($destFile, implode(',',$sourceLine)); } // end if !found // close the destination file fclose($destFile); } // end while sourceFile // close source file fclose($sourceFile); ?> Okay so I tested it out. It seems to from formatA to formatB just like you wanted...except for one small bug. In order for this code to work, the usernames must be sorted. In your example, they are sorted. But if you have for instance, this: user1,2006 user2,2005 user2,2006 user2,2007 user1,2005 for some reason it bugs and ends up doing this: user1,2006, 2005 ,2005,2006,2007 another example, this: user1,2005 user1,2006 user2,2005 user2,2006 user2,2007 user3,2001 user3,2000 user3,1999 user2,1111 turns into this: user1,2005,2006 user2,2005,2006,2007,1111 ,2001,2000,1999 I'm not entirely sure why. Maybe someone else can spot the bug, or find a better solution; I'm tired, going to bed.

so what did you change?

So...you just started learning php 2 days ago, and yet managed to master it enough to come up with all that? And what about that "It used to work" statement? Since you just started php 2 days ago, did it used to work, what, yesterday?

your sql server is down so you opt to make a flatfile solution instead of fixing the server?

depends. Are the values/descriptions something you're pulling from a database or file? Use ajax. Are they being generated from for example, $x+1 or something? Use javascript.