scootstah

You probably don't want to work with 400+ results all at once. If you have a few thousand users pulling hundreds of results at the same time you're going to use a lot of unnecessary memory. You'd be better off with pagination and only displaying 20-30 at a time. Therefore you'll probably need some sub-queries to count the categories that correspond to the keyword. I'm having a hard time coming up with a good example, though.

libxml is a library that a bunch of extensions (such as SimpleXML) depend on. So if libxml is not installed, those extensions won't work. Both libxml and SimpleXML are included by default with modern PHP versions, and must be explicitly disabled. You should be pretty safe to rely on them. Any shared host worth a damn will have them enabled, and they are easy enough to switch on in a VPS/dedi environment. You can check for them, and any other PHP extension, by running this: <?php phpinfo(): ?>

Sort of. They are dynamic pages, but the content still has to come from somewhere. In the examples you provided, URL rewriting is being utilized. This means that there isn't necessarily a physical file associated with the URL. The URL is being dynamically rewritten for semantics, and some other benefits. I will give you a very basic example using a MySQL database. First, make a "users" table. CREATE TABLE users ( id int(11) NOT NULL UNSIGNED AUTO_INCREMENT PRIMARY KEY, name varchar(30) NOT NULL, email varchar(255) NOT NULL ); Let's give it some random data. INSERT INTO users (name, email) VALUES ('bob', '[email protected]'), ('john', '[email protected]'), ('mark', '[email protected]'); So now our three users each have a unique ID. We can then create a page to select one of these three users dynamically. <?php // create a new mysql connection $mysql = new mysqli('localhost', 'root', 'root', 'dbname'); // get the user ID from the URL // it is a numerical ID, so cast to an integer $user_id = (int) $_GET['id']; // try to get the user from the database $result = $mysql->query("SELECT * FROM users WHERE id='$user_id'"); // did we find a user? if ($result->num_rows == 1) { $row = $result->fetch_assoc(); echo 'Name: ' . $row['name'] . '<br /> Email: ' . $row['email']; } else { echo 'Sorry, that user was not found'; } EDIT: Forgot this. The URL for this script would be something like: user.php?id=2. The script takes the "id=2" from the URL, and then selects a user with the id "2". Hopefully you'll get the gist of it, anyway.

Then you need to turn on error reporting. ini_set('display_errors', 1); error_reporting(-1);

deja vu! Huh?

Then obviously the "activated" column is not updating; so you need to look there first.

You can do that fairly easily using jQuery.

<textarea disabled id="infoArea"><?php echo $desc; ?></textarea> Like that?

Without seeing all of the formats I can't really give a solid answer. But I would probably just have a few if/elseif statements to check for the different formats. Clever use of regex should cut it down a bit. For example, one pattern matches the first three formats you listed.

And if you have CPanel you can use the File Manager to uncompress zip files.

1. You don't need to do anything to store linebreaks. If you are submitting data from a textarea and there are linebreaks in the textarea, there will be linebreaks in the database. They are invisible characters so you cannot see them, but they are there. In order to make them appear on the page once you retrieve the information all you need to do is use nl2br to convert the invisible \n characters to HTML <br /> tags. 2. But what is $id?

Your question (statement?) is a bit vague. Can you describe your problem in more detail?

What you are attempting to do looks pretty dangerous. Never trust your input, especially with sending emails. If you are just feeding in whatever $_GET has to offer, your script could potentially be used to send mass spam by an attacker. Anyway, you said you need to get emails out of the database but I don't see that happening anywhere, nor do I see any form data. What are you trying to do?

Well the first three are easy enough: $file = 'House MD\episode name. s1e07.mkv'; if (preg_match('/s([0-9]+)e([0-9]+)/i', $file, $matches)) { array_shift($matches); print_r($matches); list($season, $episode) = $matches; } The last two might be tricky because they're too ambiguous. For example, 105 could either be season 1 episode 05, or season 10 episode 5. How do you distinguish that? Also it is impossible to derive the season number from "EP01".

There's a couple things that stuck out in your script that are wrong: 1. You don't need to use addslashes and mysql_real_escape_string at the same time - that will just end up looking like: a string \\\' with a quote in it which will then be saved in your database as: a string \' with a quote in it. 2. You are using session_register which is deprecated as of PHP 5.3 and completely removed as of PHP 5.4. As for your problem, this is where debugging comes in. Skimming quickly I didn't see anything too obvious, so it's up to you to make sure things are right. Some things to try: - What is the value of $authcode? Does it match what is in the database? - Are you getting any rows returned when you match the authcode? - Was the cookie set properly? As for the session garbage collection, you can change everything about that. Here is three settings you can change to alter the behavior of the garbage collection: http://us.php.net/manual/en/session.configuration.php#ini.session.gc-probability Namely: gc_probability, gc_divisor, and gc_maxlifetime.

That's adds no real difficulty in brute forcing the password, and limits entropy in your final digest. Not to mention that in the end, no matter how complicated the thing you hashed was, MD5 is still breakable in < 10 minutes on modern computer hardware. Seriously, stop using MD5 for passwords.

Perhaps $OAuth->get() has decoded it already. I'm not familiar with the library.

except that prices vary a little more than realistic/feasible "estimate" ranges depending on what part of the country (or world even) you are in... for instance, I pay about $2/pound for ribeye steak at my local grocery store...but I do live in farm country, where I can go pet my meal before I eat it if I really want to...but traveling around the states, I've seen it upwards of $10/pound even upwards of $20/pound in some places... or like a loaf of bread...I pay ~$1 (more like 75c but I round up), $1.50-$2/gal for milk.. but I've been to places that charge like $3 per load of bread, $5 for gallon of milk... even an overall "average" price throughout all of the US (or world) would be too much of a difference in my case for a lot of things... Damn, I wish I lived where you live. Bread is $2-3 per loaf here, depending what you get. Milk is ~$4.50/gallon.

The error tells you that it is running out of memory - so changing the max upload file size directive is not going to do anything. Post the rest of the script please.

You shouldn't do that because then you are duplicating data in your database. What if you change the price? Then you have to update it in a whole bunch of places, which is a lot slower. Instead, you can just store the product ID - from there you can use a JOIN to reference the products table based on the product ID. As a rough example let's say you have these three tables: products ------------- id : int(11) : unsigned : primary key : auto_increment name : varchar(70) price : float users ------------- id : int(11) : unsigned : primary key : auto_increment username : varchar(30) cart ------------- user_id : int(11) : unsigned : primary key product_id : int(11) : unsigned : primary key So you see, the "cart" table just holds two ID's: one for the user, and one for the product. This way if you update the product the changes take place anywhere that the product is referenced from the "cart" table - and you only need to update it in one place. You could take it a step further (if you are using INNODB) and use Foreign Keys in the cart table. Foreign Keys will allow you to cascade changes to the referenced table. For example, if you delete a product from the "products" table, that item will automatically be removed from the "cart" table. When you want to see the price and such you will use a SQL JOIN to get the "products" and/or "users" tables. You would run a SELECT query to the "products" table with the product ID in a WHERE clause and then count the returned rows. Since the ID is unique, you should get one row returned. If you get no rows returned you know that the product does not exist. You can do this with the mysql_num_rows function, or, use a COUNT() query. Either of these will work: $id = (int) $_GET['id']; $result = mysql_query("SELECT id FROM products WHERE id='$id'"); if (mysql_num_rows($result) == 1) { // the product exists } $id = (int) $_GET['id']; list($num_rows) = mysql_fetch_row(mysql_query("SELECT COUNT(id) FROM products WHERE id='$id'")); if ($num_rows == 1) { // the product exists }

It would be as simple as running the INSERT query on the add.php page, using the ID from the query string. $id = (int) $_GET['id']; mysql_query("INSERT INTO cart (user_id, product_id) VALUES (1, '$id')"); That's the gist of it. You would want to make sure that $_GET['id'] is in fact populated, that the product actually exists, and that it's not already in the cart.

Hmm, that's a good point. Like I said earlier if you could plug into an API or scrape the page to try to find sales and whatnot and then have them SMS'ed or emailed to you, that would be pretty neat.

What I'm saying though (and maybe this is just where I live) is that prices fluctuate for the stores that I do go to. For example I might buy bread in store A one week for $2.34, and the next week in the same store it might be $2.40. So my concern is that you have recorded that bread costs $2.34 for store A on week 1. On week 2, it might cost more than $2.34 and in fact be cheaper in store B - but you wouldn't really know that.

But how accurate would that really be? Or is 100% accuracy not really your goal?

Start here: http://php.net/manual/en/book.imap.php