hadoob024

I have a db populated with real estate listings. On our search page, the user can enter in a City name in a text field that I then want to use as a search term on the db. My 2 thoughts on how to do this are the following: $where[] = "ofrelistings.city = '".$city."'"; -or- $where[] = "ofrelistings.city like '%".$city."%'"; I don't want to bog down my db by using "like", but if someone types in "Atlant" instead of "Atlanta", I would want the search to go through. Any thoughts, improvements, suggestions? Thanks!

Cool. Thanks for the tip!

OK. I kinda figured something out. I think the error's in this part: {1,500} I think I can't test a value greater than 256. Is there any workaround to this?

I can't figure out what this is for the life of me. Here's the error I'm getting: Error Message: eregi() [<a href='function.eregi'>function.eregi</a>]: REG_BADBR Error Code: 2 This error corresponds to the following area of code: if (!eregi('^[a-zA-Z[:blank:].`\'\-]{1,30}$', $city)) { $problem = 5; $problemtext .= "<B>City (or Country if international) name can only be composed of the letters A through Z, and the following symbols: -, ', and `.</B><P>"; } if (!eregi('^[[:blank:][:punct:][:alnum:][:space:]]{1,500}$', $listingdescription)) { $problem = 5; $problemtext .= "<B>Listing description can only contain letters, numbers, punctuation, tabs, and spaces.</B><P>"; } Any thoughts?

sweeeeet!  that's good enough for me  ;D

Yup.  Running Linux and Apache, and I have access to the server so I should be able to make that change.  And as for the "user experience" and as far as spiders are concerned, setting the default page to aboutus.php doesn't matter, right?  This is stuff done on the server side, so it really shouldn't affect anyone for anything, correct?

Hmmmm... That's exactly what I was worried about.  I'm thinking about gutting all that stuff, and instead just adding a disclaimer to the copyright section mentioning the same stuff but without requiring user interaction.  Now, suppose I want the user to go to aboutus.php by default (this page has the most amount of informational text which is what I'm guessing the search engines are looking for), can I set this on my server, or will it be looking for index.php?

Oops.  A quick edit.  Actually, index.php isn't the main page.  Even this page does a redirect.  It checks to see if the EULA cookie has been set.  If so, then it sends the user to the main page.  If it hasn't been set, then it sends them to the disclaimer page.

OK.  Here's my setup.  I want to see what changes I need to make in order to help with search engine optimization.  First of all, my first main page that does anything is index.php.  Now, I know by default, pages get directed to index.html, right?  So, to get it to index.php, I'm assuming that I have to do something similar to this in order to bypass user interaction: <meta http-equiv="refresh" content="0;URL=http://www.blahblah.com/index.php"> So, my first question is how does this affect search engines?  Because index.html is technically the first page, but it doesn't have anything in it that search engines look for other than maybe an appropriate TITLE and a META description tag, right? Then my second question is regarding the index.php page.  On this page, we have a simple form verifying whether or not the user has read our EULA.  How does having this simple form affect spiders crawling my site?  Will they be able to read through it and then crawl the rest of my site?  Thanks in advance!

Sweet!  Everything else worked.  In case someone's looking for an example.  Here's mine.  It basically takes records older than 30 days, and copies them into an archive table.  It then deletes records that match both tables from the main table.  It then runs a query to see if any records match both tables, if they don't then the previous 2 transactions ran properly.  And finally, we delete records older than 60 days from the archive table. [code]//We first lock both the main listings table and the archive table so that //we can lower the chances of corrupting the database.  In addition, we have //to create a couple of aliases for our tables and lock those as well. $lock_query = "LOCK TABLES ofrearchive WRITE, ofrearchive AS ofrearchive1 WRITE, ofrelistings WRITE, ofrelistings AS ofrelistings1 WRITE"; $lock_result = mysql_query($lock_query); if (!$lock_result) { $problemtext = "Error LOCK-ing db tables and aliases.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } else $summary .= "LOCK-ed both tables and aliases. \r\n"; //Copying records older than 30 days from main table into archive table. $insert_query = "INSERT INTO ofrearchive SELECT ofrelistings.* FROM ofrelistings LEFT JOIN ofrearchive AS ofrearchive1 USING(uniqueid) WHERE ofrearchive1.uniqueid IS NULL AND DATEDIFF(now(), ofrelistings.dateadded)>30"; $insert_result = mysql_query($insert_query); if (!$insert_result) { $problemtext = "Error INSERT-ing information into archive table in Cron job.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } else $summary .= "INSERT-ed records older than 30 days from main table into archive table. \r\n"; //Deleting records older than 30 days from main table $delete_query = "DELETE ofrelistings.* FROM ofrelistings INNER JOIN ofrearchive USING(uniqueid)"; $delete_result = mysql_query($delete_query); if (!$delete_result) { $problemtext = "Error DELETE-ing information from main table in Cron job.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } else $summary .= "DELETE-d records older than 30 days from the main table. \r\n"; //Verify that the previous transactions worked.  If it did, then this //query should return nothing. $select_query = "SELECT * FROM ofrelistings INNER JOIN ofrearchive USING(uniqueid)"; $select_result = mysql_query($select_query); if (!mysql_num_rows($select_result)) $summary .= "Verified that transaction ran correctly because this query returned an empty set. r\n"; else { $problemtext = "Error completing the backing up of information from main table to archive table in Cron job.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } //DELETE records older than 60 days from the archive table. $deletearchive_query = "DELETE ofrearchive.* FROM ofrearchive WHERE DATEDIFF(now(), ofrearchive.dateadded)>60"; $deletearchive_result = mysql_query($deletearchive_query); if (!$deletearchive_result) { $problemtext = "Error DELETE-ing information from archive table in Cron job.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } else $summary .= "DELETE-d records older than 30 days from the archive table. \r\n"; //UNLOCK-ing both tables so users can access them again $unlock_query = "UNLOCK TABLES"; $unlock_result = mysql_query($unlock_query); if (!$unlock_result) { $problemtext = "Error UNLOCK-ing db tables.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } else $summary .= "UNLOCK-ed both DB tables. \r\n"; [/code]

Dude.  You're a freakin' genius!!!  I don't know how I keep missing these little things.  Sweet.  I just gotta check and make sure that it actually moved the appropriate records, although it looks like it did.  Do you see anything that might be wrong?  The syntax seems right, it seems like it moved all records older than 30 days from the main table to the archive table. I'm gonna try out the next section: [code]//deleting records older than 30 days from main table $delete_query = "DELETE ofrelistings.* FROM ofrelistings INNER JOIN ofrearchive USING(uniqueid)"; $delete_result = mysql_query($delete_query); if (!$delete_result) { $problemtext = "Error DELETE-ing information from main table in Cron job.\r\n".mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } [/code] This section of code's supposed to then delete those records that are older than 30 days from the main table.

Hehe... You're gonna laugh, but I forgot to do "SELECT ofrelistings.*" and just did "SELECT *".  That step seems to work now. However, it's still not doing what I want it to do.  Here's my INSERT statement: [code]$insert_query = "INSERT INTO ofrearchive SELECT ofrelistings.* FROM ofrelistings LEFT JOIN ofrearchive AS ofrearchive1 USING(uniqueid) WHERE ofrearchive1.uniqueid IS NULL AND DATEDIFF(ofrelistings.dateadded, now())>30"; $insert_result = mysql_query($insert_query);[/code] It's supposed to move records older than 30 days from main table into archive table, but I ran the script and nothing got inserted into the archive table. 

Hmmm.  Weird.  I don't see it.  Here're the result of doing a DESCRIBE on both tables: DESCRIBE ofrearchive: Field                Type  Null              Key  Default  Extra uniqueid             int(10) unsigned   PRI       0 firstname             varchar(30)       lastname           varchar(30)       emailaddress            varchar(50)       phonenumber        varchar(14)       companyname       varchar(30)       askingprice           int(10) unsigned           0 listingtype             tinyint(2) unsigned           0 location             varchar(20)       city                       varchar(30)       listingdescription   text       picture             varchar(4)       dateadded           date                             0000-00-00 DESCRIBE ofrelistings: Field                Type  Null              Key  Default  Extra uniqueid             int(10) unsigned   PRI       NULL     auto_increment firstname             varchar(30)       lastname             varchar(30)       emailaddress           varchar(50)       phonenumber         varchar(14)       companyname         varchar(30)       askingprice             int(10) unsigned           0 listingtype             tinyint(2) unsigned           0 location             varchar(20)       city                       varchar(30)       listingdescription     text       picture               varchar(4)       dateadded           date                     0000-00-00 I still don't see it.

Yup.  They have identical table definitions except that 'uniqueid' in ofrelistings is an int that's set to auto-increment, but in ofrearchive, 'uniqueid' is just an int.  So you're saying to change: [code]SELECT * FROM ofrelistings LEFT JOIN...[/code] to: [code]SELECT ofrelistings.* FROM ofrelistings LEFT JOIN...[/code] Is that right?  I've never seen that before, but I'll give it a shot. Edit: OK.  I tried this, but I'm still getting the same error.  Any thoughts?

Cool.  OK.  So I change: [code]$lock_query = "LOCK TABLES ofrearchive WRITE, ofrelistings WRITE";[/code] to: [code]$lock_query = "LOCK TABLES ofrearchive WRITE, ofrearchive AS ofrearchive1 WRITE, ofrelistings WRITE, ofrelistings AS ofrelistings1 WRITE";[/code] and: [code]$insert_query = "INSERT INTO ofrearchive     SELECT * FROM ofrelistings LEFT JOIN ofrearchive USING(uniqueid)     WHERE ofrearchive.uniqueid IS NULL AND DATEDIFF(ofrelistings.dateadded, now())>30";[/code] to: [code]$insert_query = "INSERT INTO ofrearchive     SELECT * FROM ofrelistings LEFT JOIN ofrearchive AS ofrearchive1 USING(uniqueid)     WHERE ofrearchive1.uniqueid IS NULL AND DATEDIFF(ofrelistings.dateadded, now())>30";[/code] right?  Well I tried that and now this is the error I'm getting: [quote]Column count doesn't match value count at row 1[/quote] I can't even figure out what this error is referring to.

OK.  I think I see where this problem might be coming from.  I just came across this in the MySQL docs: [quote] Also, you cannot use a locked table multiple times in a single query. Use aliases instead, in which case you must obtain a lock for each alias separately. mysql> LOCK TABLE t WRITE, t AS t1 WRITE; mysql> INSERT INTO t SELECT * FROM t; ERROR 1100: Table 't' was not locked with LOCK TABLES mysql> INSERT INTO t SELECT * FROM t AS t1; [/quote] I think I'm getting the same error message as from this example.  I guess my question is that since I use the tablename 'ofrearchive' four times in that INSERT query, do I need to create a new alias for each time I need to use it in the query?

Hello.  I'm working on a script that takes records older than 30 days from the main table and puts them into the archive table.  Here's the section of code giving me problems: [CODE] //We first lock both the main listings table and the archive table so //that we can lower the chances of corrupting the database. $lock_query = "LOCK TABLES ofrearchive WRITE, ofrelistings WRITE"; $lock_result = mysql_query($lock_query); if (!$lock_result) { $problemtext = mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } //Moving records older than 30 days from main table into archive table $insert_query = "INSERT INTO ofrearchive     SELECT * FROM ofrelistings LEFT JOIN ofrearchive USING(uniqueid)     WHERE ofrearchive.uniqueid IS NULL AND DATEDIFF(ofrelistings.dateadded, now())>30"; $insert_result = mysql_query($insert_query); if (!$insert_result) { $problemtext = mysql_error($connresult); trigger_error($problemtext, E_USER_ERROR); } [/CODE] When this executes, it gets passed the LOCK statement just fine (because I don't get any error messages), however, it seems that the INSERT statement is causing this error: "Table 'ofrearchive' was not locked with LOCK TABLES" Any thoughts on what could be causing this?  Thanks!

SWEET!!!  Thanks a bunch!  I finished up everything late last night and gave up on it at like 4 a.m.  Then I just started again and couldn't find it.  Thanks, you saved me from a miserable afternoon!

I have now been looking at this for about 2 hours and cannot for the life of me see where this error is coming from.  I thought it usually means that I have a '(' or '[' out of place, but still can't seem to find it.  Anyway, the error message is: "Parse error: parse error, unexpected T_STRING in /blah.php on line 204" And here's the code: [CODE] if (isset($_POST['expyear'])) { if ((strlen($_POST['expyear']) == 4) && (is_numeric($_POST['expyear']))) $expyear = $_POST['expyear']; else { $problem = 7; $problemtext .= '<B>You did not enter a valid credit card expiration year.</B><P>'; } } else { $problem = 7; $problemtext .= '<B>You did not enter a valid credit card expiration year.</B><P>'; } if (isset($_POST['cvm'])) { if (strlen($_POST['cvm']) == 0) $cvm = ''; elseif (((strlen($_POST['cvm']) == 3) || (strlen($_POST['cvm']) == 4)) && (is_numeric($_POST['cvm']))) $cvm = $_POST['cvm']; else { $problem = 7; $problemtext .= '<B>You did not enter a valid CVM number.</B><P>'; } } else { $cvm = ''; } if (isset($_POST['cvmnotpres'])) { if ($_POST['cvmnotpres'] == 'on') $cvmnotpres = $_POST['cvmnotpres']; else { $problem = 7; $problemtext .= '<B>You did not enter a valid value for the "Code not present" checkbox.</B><P>'; } } if (isset($_POST['bname'])) { if (strlen($_POST['bname']) <= 60) $bname = $_POST['bname']; else { $problem = 7; $problemtext .= '<B>Billing name is too long or wasn't entered.</B><P>'; } } else { $problem = 7; $problemtext .= '<B>Billing name is too long or wasn't entered.</B><P>'; } [/CODE] Anyway, the error line comes to this line "$problem = 7;" in the "if (isset($_POST['bname']))" section.  I included the lines before it to because I know the line numbers usually don't line up properly with this kind of error.  Anyone see anything?  I've already gone cross-eyed and need to take a break.  Thanks!

Hello. I have a form field in formpage.php. A user enters in info, and then submits it. This info gets sent to formprocessor.php where I perform my error checking/sanitizing. If something is wrong, the user clicks on the 'back' button to go back and edit their fields. Now, when using HTTP, when the user clicks on the 'back' button, all their previous information is still there. However, when using HTTPS, when the user clicks on the 'back' button, all the information gets cleared. Any thoughts on why this is happening? Incidentally, I call the following at the beggining of each of these scripts: [code]header("Expires: Sat, 01 Jan 2000 00:00:00 GMT"); header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT"); header("Cache-Control: post-check=0, pre-check=0",false); session_cache_limiter("must-revalidate");[/code]

oh yeah!  that's a good idea...  i'll probably go with it after reading through the docs.  from the way they've setup other stuff, it seems like they've encountered all these kinds of issues before and cater to them pretty nicely.  but if they don't, then that seems like a good way to protect myself for issues of just one of the transactions going through, and not the other.  thanks!

Cool.  Thanks for the advice.  Yeah, I think I'll wait until I get through the docs for the payment gateway before making my final decision.  If they allow for pass-thru variables, then maybe I can have both listing and payment info on 1 page.  Otherwise, I'm guessing I'll have to split it up.

OK.  Cool.  But if I have them enter payment info and the listing info on the same page, the form action sends them to the merchant account gateway, and when they get sent back, won't I have lost my form information for the listing itself? Also, I was thinking about doing the payment info first because there seems like there could be more issues with paying than just entering form info.  Because once the listing form info is sent, I send myself an email saying that the following listing info was submitted.  I then send myself an email once the info actually gets added to the db.  That way I know that for a successful addition, I'll get 2 emails.  Doesn't this seem like it will handle the situations you talk about?  If I did it the other way, what do I do with the listing information while I'm waiting to find out whether the payment went through successfully?  Thanks!

hmmm... yeah, i was thinking of going the SESSION route, but with SESSION hijacking couldn't that be a problem?

OK.  I have a real estate listing site where searches are for free, but we charge the customer to list their property.  Here's how I'm setting up my site: Add Listing p.1 - Customer enters listing type (to determine how much to charge customer).  Form action sends control to Add Listing p.2. Add Listing p.2 - Customer enters payment info on a form on our site.  The action of the form sends the information to the merchant account payment gateway.  The return value of this determines whether or not the payment went through. If payment goes through, we send control to: Add Listing p.3. - Customer enters in listing info.  The action of the form sends control to Add Listing p.4, which basically is a confirmation that the info was added to the db and that the payment went through. Basically, I want to know is how can I prevent anyone from accessing Add Listing p.3 without getting a 'yes' confirmation from the payment gateway?  Like I don't want someone to try and access Add Listing p.3 by directly entering the URL, thus bypassing the payment part.  Any thoughts?