gizmola

FWIW, gmail offers support for IMAP. This is how phones connect, as well as imap compatible clients like thunderbird or outlook. Rather than trying to use curl, which will not work with gmail, because gmail is a giant javascript application, IMAP would be something you could actually accomplish. You would need of course support for secure imap, and given the limitations of the hosting company, who knows what they might support or not. Did you by any change attempt to engage them in regards to your outbound email issues? Did you ask them how you could perform legitimate and legal outbound emailing via your php based code? ISP's are understandably concerned about email blacklists, so there may be a particular set of hoops or configurations you need to jump through.

Andy-H makes some good points there. The site looks fine for me, but you do have a case of a bit of burying if for example, you actually want people to see your artwork. I also find that the navigation kinda disappears into the design. You only have 3 Nav items, so I'd make sure they are large and visible, perhaps with a bit of rollover eye candy. I don't know if you can get an updated screenshot for Robert's plumbing, but the empty boxes on the front doesn't reallly showcase your design skills. You might want to omit that one if you don't.

Hey thorpe is the closest thing that we have at phpfreaks to a superhero. The man spits out more working jquery code while he's drinking his coffee than most mere mortals will be able to develope in a week. You have to come up with something really crazy if you want the guy to break a sweat: something like "hey thorpe can you write a quick 8088 disassembler in javascript for me" or "how do I stop these chinese crackers from getting into gmail?" Anyways, if we've got your initial questions worked out, we like to close up threads and have people mark em "solved" for posterity. We like to try and localize threads to a specific set of problems rather than have long rambling threads that change directions a bunch of times. Good luck with the code pickup --- it's often a challenge to adopt a bunch of legacy code that isn't commented, and is lacking structure, and try and figure out how and why it works or not. PHP is one of the best languages in terms of documentation, thanks to php.net. A decent editor with color syntax highlighting and function inspection also goes a long way. Cheers!

Have you made any attempt to understand regex at all? If you understand the regex you provided then you should be able to figure out where to put: (post|topic){1}

I had to make a few assumptions from your post, but this seems to be in the right ballpark. This will of course replace (23) but not (231) nor (1). Seemed to be what you were going for. If any number of digits inside the () should get stripped then you'd want d+ rather than d{2}. $s = preg_replace('/\(\d{2}\)/','',$s);

[code=php:0] Code here [/code] Is basically what you want to use for any php code. The code you posted basically goes through the $_POST superglobal array, which is a php standard array that will contain the contents of the a form that used the post method which targetted the executing script. The names of the form elements will be associative keys. That snippet goes through that array one element at a time, runs stripslashes() on the value, and replaces any ' characters with the html entity ′ It stores this new, stripped and replaced value in a $val[] array where the keyname is the same as the original $_POST[]. It's not a real sophisticated script, and it appears to assume that magic_quotes_gpc() is on. What magic_quotes_gpc() does is automagically run the addslashes() command on any input coming from external sources. This is not helpful behavior, and is deprecated now. Slashes to escape quotes is not helpful at all for mssql, so it's understandable you don't want them, but before running stripslashes() you want to make sure it's needed. With mssql, as far as I understand you need to be concerned about the ' character as well as the [] characters in input. I'd highly recommend that you investigate the matter further. Here's an article that talks about the issue a bit. http://www.techtamasha.com/escape-single-quotes-and-wild-cards-_-in-ms-sql/20 I don't know that I would use html entities to solve this problem... it seems that the correct answer is that single quotes should be escaped by doubling them and the entire string needs to be contained within single quotes. Just my 2 cents, but hopefully this gives you an idea of what is going on with your code snippet. I don't know where the code is from, but in essence it's trying to solve the problem of escaping special sql characters so that they can be safely stored in a database.

scarhand has you on the right track for this. Your first mistake is that you don't check or save the result of the unlink function. It returns true or false. The second issue is that clearly you do not have the full path of the photo file in the database. That needs to be corrected unless the path relative to this script (the photos directory) is off the current directory. Without knowing the *real* filesystem path to where the photos reside, it is hard to say what the path should be, or if scarhand's advice is helpfull, although even if it is, you probably need to use dirname($_SERVER['SCRIPT_FILENAME']) or some variation of that. The first step is to figure out where on the server the photos have actually been stored.

© 2010-2015 www.EricWooley.com It's good to know that you are covered with copyright for the next 5 years. I was worried there that someone from the future would rip you off in 2014, but luckily you have that covered. I'm a bit worried about 2016 though.

No it's not. I thought that was obvious, although that's a SQL or in your case MS SQL syntax issue, and has nothing to do with PHP.

Yes well you might have more luck if you weren't trying to use a plugin for wordpress --- unless of course you're using this with wordpress. If so then by all means, keep plugging. Otherwise I'd point you to jquery, which makes ajax pretty much a snap. With that said --- Ajax really isn't appropriate for a contact form in my opinion. What is there to Ajax? You have a form, you fill it out, you hit submit --- this is what forms and $_POST do very well. You could certainly ajax, but what is the point? Ajax is good for many things, but this is not one of them. Incremental search--- Ajax, great! A Chat application --- Ajax! New user registration --- checking whether a username already exists.... Ajax! Contact form? Err not so much.

Just to be clear, that is an issue with the mysql_query() function in php. Obviously you can run batch mysql scripts through the mysql command line client.

If there is any way you can call mysqldump, that is by far the preferred solution to this problem. If and only if that is not a viable solution would I go to phpMyAdmin or the davidwalsh script.

So line 169: $team_sql = "INSERT INTO team (teamname,shirtcolor,league,captain) VALUES ('$vals[teamname]','$vals[shirtcolor]','$leagueId','$cptId',)"; See that dangling comma at the end of the VALUES list?

You can not batch SQL. You have to do one query at a time.

Here's some applications "made using php" http://www.yahoo.com/ http://www.digg.com/ http://www.facebook.com/ http://www.wordpress.com/ http://www.wikipedia.org/ http://www.flickr.com/ http://www.friendster.com/ http://www.photobucket.com/ ...... That doesn't even begin to mention all the ecommerce site, or forums powered by one of the php based forum packages. It seems you have an idea for an application. Rather than wait for someone to tell you what to do, why not get busy working on fleshing out your idea so that you can make an educated decision as to whether or not it will make a good project. PHP like most programming languages can be adapted to do all sorts of things, and is an excellent fit when you want to deploy the application via the internet and need to provide access to clients via a web browser. There's nothing more that needs to be said, AFAIAC.

I would suggest that you re-read what you wrote, and see if you can better formulate a question. Referential integrity is a good thing ... it will block improper inserts or updates. That is not a problem with any approach, although if you were doing a single insert previously, you might want to break it up into a series of individual inserts. There's not much else I can say --- you have only sketched out a database design, with no code, and no idea what your issue is.

mysql_fetch_assoc() most certainly does return an array, when it actually has something to fetch. It returns exactly what the name implies -- an array keyed by the names of the column. You have exactly one column in your select statement, so the array for one fetch would look something like: $row = array('RecordID' => ?); From your code, I'm not sure what you're trying to do, since I don't really understand your database design. What I can say is this -- when you fetch one row, you get one row. That is not by any means the entire result SET, it is only the first row -- and in this case a single value. If you're expecting a whole series of rows, your code is not accounting for that. You also don't want an array of arrays with a single key/value pair, since you're trying to use in_array() apparently to try and find the value. This would be more likely the code you would want: function completedresearch($User){ $Query = mysql_query("SELECT ......") or die(mysql_error()); $rows = array() while ($row = mysql_fetch_assoc()) { $rows[] = $row['RecordID']; } return $rows; } Again just my best guess, given the information you've provided to this point, which is far from clear. I don't know why you do a query that references one column, even though your initial query tried to ORDER BY another column, and then seems to look for another value. It's about as clear as mud, and also begs the question of why your query doesn't figure this out more directly... the database is perfectly able to return rows or not based on WHERE criteria, so I can't figure out why you would want to pull out a result set and then search through it, when the database is better and faster at doing that itself, and just giving you the exact result set specified.

https is the only way to insure the data can't be sniffed. This gets into networking, but for the most part people can't sniff data because they are on a switch and have no visibility to data on the network. A common exception to this rule would be wifi hotspots and places where you have a hub or a shared workstation. If I go into an internet cafe, jump on a computer and login to a site, if i don't know what I'm doing there's a possibility that a cookie will be left around. By default most sites implement a session cookie which is deleted as soon as the browser closes. If however, I leave and don't close the browser -- well it's possible that someone goes right onto the site, and it will of course think it's me. So what are some safeguards that people provide on the server side? One you might notice is that to change the password or account email, it might prompt you for the "old password" first. This is protection against this type of exploit, or even more commonly, the "I'm at college, I step away from my computer to get a drink and my roomate jumps on to the site and changes the password" problem. As data flows across the internet, there are places where someone could get access to packets. How important security is varies greatly. Pretty much anytime banking, personal medical information etc., is involved then https is pretty much insisted upon. For other things -- not so much. The overhead of ssl is not insignificant, so everything is a value judgement. Now for "guessing" a session ID, php uses by default a hash. The particular hash they use has the property that you can't reverse engineer (decrypt) it, and you can't guess what the next hash will be given yours. You can read the manual for more information. You do not have to use the default id.. and can change pretty much anything you want from the name of the cookie variable to the nature of the id itself, to the way sessions are stored. If you don't like the default hash you can make a different one. If you want to implement extra security you can -- for example, you could store the IP address in a $_SESSION variable, and if the IP address in $_SERVER['REMOTE_ADDR'] suddenly changes, you can choose to invalidate the session or require that they relog if they do anything that requires an "escalation" of privileges (for example, let em read whatever they want but don't let them actually change or add anything).. I've seen all sorts of different approaches used. It really depends on how paranoid you are, and how much time you want to invest in complexity. Often people change the way sessions work purely to support a web cluster. By default php stores sessions in files that are serialized and stored in the temporary directory of the server. When you have a cluster, this is a problem, because any request might arrive at any of the different web servers in the cluster. People often use a custom session handler that stores the sessions in a database or in memcache. I bring this up, just to reiterate that you can change all sorts of things about basic php sessions to suit your desires/requirements.

Look at your param: function completedresearch($User){ The name is $User. Now look at the variable that you are using in the query. Is that that same variable name? You can figure these things out with a simple echo statement, but I have to point out that you don't actually check to see if the mysql_query returns a valid result set. If you make that type of assumption, when things go wrong you get a runtime error, because fetching against a 'false/null' result set causes a runtime error.

A design that would work fine is very similar to what I described in this thread. You might be able to adapt the idea to your stumbleupon clone.

You mean where I pointed it out above? Well glad you got it sorted out. I'm just about psychic at this point

Just because I'm sure you'll be wondering, the structure I provided gives you a couple different ways of approaching things. 1st off you can do a search on the "title". I've added an index on there, but any such search would need to be either an exact match or a LIKE 'search%'. You could also consider adding a FULLTEXT index on any of the TEXT columns I types (ingredients, prep etc.) I changed serves to be numeric. If we assume "serves' is "a person" there's no reason to have a string in there. Now for searching by Tags, you could have a Tag cloud, or a drop down of the "tag" list, or let people enter into a box and search on tags. The end goal is to come up with one or more tags. I'm not going to go into the complexity of multiple tags right now for the sake of simplicity -- but from a database point of view, let's just assume that somehow the user indicated a particular tag they wanted to use to match recipes. Once that is known, we can assume that we also know the tag_id. I say this because typically the UI will already display the tag name, and have the associated tag_id. It can be specified in a query, but often the tag_id is already resolved. So using the prior example, let's assume that someone wanted to get back a list of all recipes that were tagged with 'Chicken'. SELECT * from recipes r JOIN recipestags rt ON (rt.recipe_id = r.recipe_id AND rc.tag_id = 3) I had one small omission on the last .sql --- use this one CREATE TABLE recipes ( recipe_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(100) NOT NULL, ingredients TEXT, prep TEXT, serves TINYINT UNSIGNED, created TIMESTAMP, CONSTRAINT PK_recipes PRIMARY KEY (recipe_id) ); CREATE INDEX IDX_recipes_1 ON recipes (title); # ---------------------------------------------------------------------- # # Add table "tags" # # ---------------------------------------------------------------------- # CREATE TABLE tags ( tag_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, tag VARCHAR(60) NOT NULL, created TIMESTAMP, CONSTRAINT PK_tags PRIMARY KEY (tag_id) ); CREATE INDEX IDX_tags_1 ON tags (tag); # ---------------------------------------------------------------------- # # Add table "recipestags" # # ---------------------------------------------------------------------- # CREATE TABLE recipestags ( recipe_id INTEGER UNSIGNED NOT NULL, tag_id SMALLINT UNSIGNED NOT NULL, CONSTRAINT PK_recipestags PRIMARY KEY (recipe_id, tag_id) ); CREATE INDEX IDX_recipestags_1 ON recipestags (tag_id,recipe_id);

Ok, so it does seem that you need some substantial rework of your database design. You seem to be confusing columns with rows. Your category table is almost entirely a repeating group, and doesn't actually relate to the Recipes in any useful way. You also don't have any primary keys or for that matter numeric keys, even though your queries included them. I'll do my best to sort you out, but you'll have to do some reading on database normalization. I could also editorialize here, that it seems you have a bit of a mix of different things in your Categories table: for example, you have Desserts and Drinks, which only seems to be missing 'Appetizer' and 'Entre', & 'Side' mixed in with 'Fowl', 'Meat' & 'Seafood' which seem to me more to indicate the ingredients. Of course you are free to do whatever works for you in the design of the system, but I thought it might be worth thinking about. Another system you could employ would be a 'Tag' system where you simply have a tag system, and you tag a Recipe with whatever tags you feel appropriate. That doesn't require too much thinking about your tags, and lets you side step the whole issue. If you think about a "tag" table as being the same as a 'Categories" row, it could work for you. Just to Help with the idea, I'll use your basic structure, but substitute a "tags" table for "Categories". When you look in tags, you're going to see something like this: tag_id: 1 tag: 'Dessert' tag_id: 2 tag: 'Chicken' tag_id: 3 tag: 'Pasta' tag_id: 4 tag: 'Cocktail' etc. You can have as many different tags as you find useful, and again any recipe can be tagged as many times as makes sense for the recipe. So the Main decision you need to make is: Can a Recipe have more than one tag? (YES) Can a tag be associated with more than one Recipe (YES) What this means is that the relationship between Recipes and Tags is "Many to Many". Thus the structure requires 3 tables (recipes, tags, and recipestags). Here's how you put it all together: If you find the diagram of use, make sure you copy it locally ... it's hosted on my server and I can't say for how long I'll leave it there. So the main thing this does is handle properly the design of your relationship between categories (which I called tags) and recipes. You might want to consider a similar exercise with ingredients -- it's more work, but would allow you to specify ingredients and get back recipes that use those ingredients. Ingredients also tend to have specific quantities associated with them, so it sometimes helps to quantify that, but this certainly adds greatly to the effort in loading in the data for a recipe. Depending on the nature of the site, while it offers advantages for searching, sorting etc., it makes it a lot tougher for data entry, which may or may not be worth it to you. Formalizing that would allow you to structure things like "substitutes" relationships -- but again this all depends on what you want out of the database. Hope this helps get you on the right track -- if you have questions just ask. # ---------------------------------------------------------------------- # # Add table "recipes" # # ---------------------------------------------------------------------- # CREATE TABLE recipes ( recipe_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, title VARCHAR(100) NOT NULL, ingredients TEXT, prep TEXT, serves TINYINT UNSIGNED, created TIMESTAMP, CONSTRAINT PK_recipes PRIMARY KEY (recipe_id) ); CREATE INDEX IDX_recipes_1 ON recipes (title); # ---------------------------------------------------------------------- # # Add table "tags" # # ---------------------------------------------------------------------- # CREATE TABLE tags ( tag_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, tag VARCHAR(60) NOT NULL, created TIMESTAMP, CONSTRAINT PK_tags PRIMARY KEY (tag_id) ); CREATE INDEX IDX_tags_1 ON tags (tag); # ---------------------------------------------------------------------- # # Add table "recipestags" # # ---------------------------------------------------------------------- # CREATE TABLE recipestags ( recipe_id INTEGER UNSIGNED NOT NULL, tag_id SMALLINT UNSIGNED NOT NULL, CONSTRAINT PK_recipestags PRIMARY KEY (recipe_id, tag_id) );

So let's assume that the value of the cookie file is phpsessid. If I can get your phpsessid value, and I alter my cookie file, when I make the next request to the site, the server will read whatever session values exist on the server for that session id. Typically people read user information and permissions into the session and store it. If I can set my cookie up to have the same hash value as you, AND there is an unexpired session on the server, as far as the site is concerned -- I am you. I can do anything you could do, and anything I do will look to the site as if you did it. There is nothing magical about it -- the session id is the thing that gets passed in each request (again typically as a cookie), and is used to read session values from the server back into the $_SESSION superglobal. Those are the basic moving parts. *If* I can get access to a valid session ID I can have my browser impersonate you, but this is by no means a trivial task.

Yeah I air balled on the group by, but you figured it out. Ok, so what I would say is that there are so many values that are NOT EQUAL to the one you want, that mysql has decided to dump out the entire table. So at any rate we're back to the simple fact that you have a base result that is returning a lot of rows (select count(*) from lunapr_c1price where sytle_name != 'Alaska Sg Maple2.5'. This is being used to join to all the other tables, so there's a lot of rows being examined, unless I'm missing something. When you do an explain on just that simple select statement, what do you get?