eregi replace error

[bradgrafelman]

You're using [man]eregi_replace/man, but you shouldn't be, since that function is deprecated.

(In other words, exactly what the error message says.)

[GeorgeInFlorida]

Thanks, is there an alternative to removing this syntax if it is used?

[bradgrafelman]

That depends. Are you actually using regular expression patterns? If so, then [man]preg_replace/man is the replacement. If not, then you shouldn't have been using eregi_replace() in the first place - [man]str_ireplace/man is a better fit.

[GeorgeInFlorida]

I am also getting this error message,
Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /home/content
Here is the code. The second line is the one that is giving the error
$sql_doublecheck = mysql_query("SELECT * FROM scenemembers WHERE id='$id' AND password='$hashpass' AND email_activated='1'");
$doublecheck = mysql_num_rows($sql_doublecheck);

[GeorgeInFlorida]

I don't have a clue, I guess I am just an idiot.... One of these days I am going to have to take a course in PHP I guess. I am just trying to get a website up and running, and this is the activation page.

[NogDog]

This usually means that MySQL choked on the query and returned a Boolean false instead of a query result resource. Therefore, you need some defensive coding to check if $sql_doublecheck == false, and if so, generate some debug info and probably abort the rest of the normal processing.

[GeorgeInFlorida]

Ok, I appreciate all the responses. I guess I just don't know enough to even understand what you guys are saying. I will have to stop what I am doing, and try to learn more about PHP. Sucks, because I really wanted to get this site up and running, but obviously, I don't have the knowledge. Thanks again.

[NogDog]

Consider these two lines:

$sql_doublecheck = mysql_query("SELECT * FROM scenemembers WHERE id='$id' AND password='$hashpass' AND email_activated='1'");
$doublecheck = mysql_num_rows($sql_doublecheck); 

If the call to mysql_query() in the first line works, then $sql_doublecheck will be some arbitrarily assigned (by PHP) resource identifier. You don't need to know what it is, just that it is not false (which is what gets returned if the function call fails for some reason.

The second line uses that resource id as a parameter for the call to mysql_num_rows(), but if the first line failed for any reason, then you're instead passing a Boolean false, which is not what that function requires. Therefore, you should always protect against such a situation, both to avoid crashes and to help debug when things go wrong. A fairly simple way to debug for now would be:

// let's put the query itself into a variable, just in case things go bad:
$sql = "SELECT * FROM scenemembers WHERE id='$id' AND password='$hashpass' AND email_activated='1'";
// now go ahead and run the query:
$sql_doublecheck = mysql_query($sql);
// let's handle any failure:
if($sql_doublecheck == false) { // uh-oh
    $errMessage = mysql_error()."\n".$sql; // we'll output whatever mysql has to say about it along with the actual query used.
    error_log($errMessage);
    if(ini_get('display_errors') == true) {
        echo "<pre>$errMessage</pre>";
    }
    die("Sorry, there was a fatal error, debug info has been logged.");
}
// otherwise we should be good to go...
$doublecheck = mysql_num_rows($sql_doublecheck);   

[GeorgeInFlorida]

Excellent!!!! Got rid of the problem. The word Password should have been pass1 Now it appears to be working properly except it is saying your account could not be activated, please email site administrator for manual activation. Looks like all the data is in the database, so I must have the email_activated type set wrong. I have it set as enum '0','1' Is that not correct?

[GeorgeInFlorida]

Ok, after looking at the database again, I noticed one of the items is blank, and it should have a value. I created a code identical to the birthmonth, and birthday codes, and they work fine. Do I have something wrong here I don't see?? Or can that code not be used in a drop down menu of this type?

<select name="profile_type" class="formFields" id="profile_type">
<option value="<?php print "$profile_type"; ?>"><?php print "$profile_type"; ?></option>
<option value="01">Pro photographer</option>
<option value="02">Non pro photographer</option>
<option value="03">Wedding photographer</option>
<option value="04">Commercial photographer</option>
<option value="05">Professional model</option>
<option value="06">Amateur model</option>
<option value="07">Promotion model</option>
<option value="08">Licensed agent</option>
<option value="09">Event coordinator</option>
<option value="10">Talent manager</option>
<option value="11">Actor</option>
<option value="12">Musician</option>
<option value="13">Performer</option>
<option value="14">Make up arist</option>
<option value="15">Designer</option>
<option value="16">Studio owner</option>
<option value="17">Shop owner</option>
</select>

[johanafm]

GeorgeInFlorida;11016733 wrote:

I created a code identical to the birthmonth, and birthday codes,

A code? What code? This is very unclear to me, but if you are saying that you store birth dates as anything other than date or datetime data types, then you should redesign your table. Some people opt for unix timestamps insteada of date(time)s, which would be stored as INT UNSIGNED.

GeorgeInFlorida;11016733 wrote:

I noticed one of the items is blank

... but we don't know which one.

GeorgeInFlorida;11016733 wrote:

Do I have something wrong here I don't see?

Possibly yes, possibly no. One thing is certain though: We see nothing, so whatever is wrong is something we don't see.

GeorgeInFlorida;11016733 wrote:

Or can that code not be used in a drop down menu of this type?

Nothing is impossible, the question is just how much work you're willing to put in to make something work in a particular manner. Oh, and you do have to get things right for whatever solution you choose anyway. But it may or may not be appropriate to choose a particular solution if you want it to be easy to implement. In this case, based on absolutely nothing I've seen (I still havn't seen anything, remember), I'd say a select element should work fine.

GeorgeInFlorida;11016733 wrote:

<option value="01">Pro photographer</option>
[/qoute]
I would however drop the 0 in front of numbers 1-9. They'd only make sense in the following cases
1. Formatting when being read by humans. Since they won't be shown to humans, this is not the case
2. Storing things as strings, that is working with numeric characters, or numeric strings if you will. This should be stored as some numeric data type, or an unsigned integer to be more specific, so this isn't the case either.
3. Sometimes used for times, as in 03:35

It doesn't really make any difference in the end, since you should be casting these to integers server side anyway, before you insert the values into the database.

if (isset($_POST['profile_type']))
{
	# If $_POST['profile_type'] is ... then $pt will be ...
	# 01 => 1
	# hello => 0
	# 15 => 15
	$pt = (int) $_POST['profile_type'];
}

Finally, I'd advice against storing these values as enums. Instead, use a separate table to hold those values. As such, you'd be storing an integer in the user table and keep the profile types stored in a separate table as id / profile description pairs

CREATE TABLE user (
	id	INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
	username	VARCHAR(20),
	first_name	VARCHAR(20),
	email		VARCHAR(50),
	profile_type	TINYINT UNSIGNED,

FOREIGN KEY (profile_type) REFERENCES profile_type(id)
);

CREATE TABLE profile_type (
	id	TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
	name	VARCHAR(30),
);

This approach has some benefits over the other one if you ever want to add a new profile type. You won't have to alter the user table to change your enum values. You'd simply add a new row to the profile_type table. This also means that you won't have to rebuild the profile_type index in the user table. At least I'm guessing you should have an index on that field. The foreign key in my solution automatically creates an index for it.

But perhaps more importantly, you won't have to hard code your select box values as you've done now.

# My pretend database interface. Get stuff from the db as you usually do
$profiles = $db->getResult("SELECT id, name FROM profile_type");

$select = '<select name="profile_type">';
foreach ($profiles as $p)
{
	$select .= sprintf('%s<option value="%d"%s>%s</option>',
		"\n\t" /* just used for formatting of html code */,
		$p['id'],
		$p['id'] == $user->getProfileId() ? ' selected' : '',
		$p['name']
	);
}

As for replacing eregi_replace with preg_replace, the proces is usually rather simple. preg patterns need a starting and ending delimiter, which according to the php manual can be any non-alphanumeric, non-backslash, non-whitespace character. After the ending delimiter you can optioanlly include pattern matching options, which in this case should include i for case insenitive match, this

$pattern = '#your_old_pattern_here#i';

But be adviced that I do not know if ereg supported patterns which preg can't handle, so the actual process of converting a pattern may be more involved. However, I've come to believe (for no real good reason) that this process always works from ereg to preg, but it wouldn't always work in the reverse.

[GeorgeInFlorida]

Thank you Johanafm, you gave me a lot to digest, and I can appreciate your sense of humor. Maybe I was not descriptive enough? What I meant to say, is it appears the register page is going through with no errors, and posting all of the data to the database, EXCEPT the profile_type in that field, it is blank, no selection was made. Nothing was populated in that field at all. It should have been one of the options I listed earlier, but nothing is there at all. I will read your post again, and try to understand it better. It was pretty clear, so not your fault, I am just having to learn all this as I go.

[Weedpacket]

<select name="profile_type" class="formFields" id="profile_type">
<option value="<?php print "$profile_type"; ?>"><?php print "$profile_type"; ?></option>
<option value="01">Pro photographer</option>
<option value="02">Non pro photographer</option>  <!-- You mean "Amateur photographer", right? -->
<option value="03">Wedding photographer</option>
<option value="04">Commercial photographer</option>
<option value="05">Professional model</option>
<option value="06">Amateur model</option>
<option value="07">Promotion model</option>
<option value="08">Licensed agent</option>
<option value="09">Event coordinator</option>
<option value="10">Talent manager</option>
<option value="11">Actor</option>
<option value="12">Musician</option>
<option value="13">Performer</option>
<option value="14">Make up arist</option> <!-- "artist" -->
<option value="15">Designer</option>
<option value="16">Studio owner</option>
<option value="17">Shop owner</option>
</select> 

Why does the first option have a value of $profile_type and a display text of $profile_type? Where does $profile_type come from? Should the value and the display text really be the same?

And this has nothing to do with an "eregi replace error", suggesting a new thread should have been started for it.