Suche

[junky]

Ich habe schon lange nicht mehr versucht einen neuen User auf meiner Site selbstständig anzulegen, aber heute war es dann soweit.

Also rein ins Admin-Menü auf Benutzer geklickt, einen Usernamen/Pass vergeben und dann folgende Meldung erhalten:
"User existiert nicht"

Bei Benutzer konfigurieren fand ich zwar den Namen, aber wenn ich den auswähle erscheint wieder "User existiert nicht"

Also schnell ein Blick in die Datenbank und siehe da, der neu angelegte User hat eine UID im mehrstelligen Bereich erhalten (4294967295). Somit hat er keine laufende Nummer, sondern eine völlig falsche erhalten. Welches Modul generiert denn hier falsch? Eigentlich müßte es bei UID 655 weitergehen.

Die Datenbank ist eine  MySQL 3.23.55-Max

[Biker]

Hm...habs eben bei mir getestet....weil man ja nicht alle Tage selbst einen User anlegt, aber bei mir funzt es....also kein Fehler im 2.1a

Das müsste dieser Bereich in der admin/users.php sein: (Zeile 323-398)...wobei ich mal darauf tippe, dass Du in Zeile 339-341 einen Fehler hast!? Vergleich es mal mit Deiner users.php!

Code Auswählen Erweitern

function addUser($pvs) {
global $user_prefix, $prefix;
#mxDebugFuncVars($pvs);
$pvs = mxAddSlashesForSQL($pvs);
extract($pvs);
$chng_uname = trim($chng_uname);
if (!($chng_uname && $chng_email && $chng_pass && !ereg("[^ a-zA-Z0-9_-]",$chng_uname))) {
include("header.php");
GraphicAdmin();
title(_USERADMIN);
OpenTable();
echo "<center><b>"._NEEDTOCOMPLETE."</b><br><br>"._GOBACK."";
CloseTable();
include("footer.php");
die();
}
$result = sql_query("select uid from ${user_prefix}_users where uname='$chng_uname'");
list($new_uid) = sql_fetch_row($result);
if (!empty($new_uid)) {
include("header.php");
GraphicAdmin();
title(_USERADMIN);
OpenTable();
echo "<center><b>"._USERYESEXIST."</b><br><br>"._GOBACK."";
CloseTable();
include("footer.php");
die();
}

$chng_pass           = md5($chng_pass);
#$chng_user_viewemail = (empty($chng_user_viewemail)) ? 0 : 1;
$chng_newsletter     = (empty($chng_newsletter))     ? 0 : 1;

$chng_user_ingroup   = (empty($chng_user_ingroup))   ? $GLOBALS['default_group'] : $chng_user_ingroup;
$chng_user_sexus     = (empty($chng_user_sexus))     ? 0 : (int)$chng_user_sexus;
$chng_user_stat      = (empty($chng_user_stat))      ? 0 : (int)$chng_user_stat;

$isdate = checkdate((int)$bday_month, (int)$bday_day, (int)$bday_year);
$bday = ($isdate) ? sprintf("%04d-%02d-%02d", $bday_year, $bday_month, $bday_day) : "";
$setbday = (empty($bday)) ? "NULL" : "'$bday'";

$user_regdate = mxGetNukeUserregdate();
$user_regtime = time();

$fields[] = "name = '$chng_name'";
$fields[] = "uname = '$chng_uname'";
$fields[] = "email = '$chng_email'";
$fields[] = "femail = '$chng_femail'";
$fields[] = "url = '$chng_url'";
$fields[] = "user_regdate = '$user_regdate'";
$fields[] = "user_icq = '$chng_user_icq'";
$fields[] = "user_aim = '$chng_user_aim'";
$fields[] = "user_yim = '$chng_user_yim'";
$fields[] = "user_msnm = '$chng_user_msnm'";
$fields[] = "user_from = '$chng_user_from'";
$fields[] = "user_occ = '$chng_user_occ'";
$fields[] = "user_intrest = '$chng_user_intrest'";
#$fields[] = "user_viewemail = '$chng_user_viewemail'";
#$fields[] = "user_avatar = '$chng_user_avatar'";
$fields[] = "user_sig = '$chng_user_sig'";
$fields[] = "pass = '$chng_pass'";
$fields[] = "newsletter = $chng_newsletter";
$fields[] = "user_ingroup = $chng_user_ingroup";
$fields[] = "user_regtime = $user_regtime";
$fields[] = "user_sexus = $chng_user_sexus";
$fields[] = "user_bday = $setbday";
$fields[] = "user_stat = $chng_user_stat";

$qry = "INSERT INTO ${user_prefix}_users SET ".implode(', ',$fields)."";
$result = sql_query($qry);
#print $qry; exit;
if (!$result) {
mxErrorScreen("Database error, cannot add to users-table", "Error"); die();
}
$uid = sql_insert_id();
if (!empty($chng_newsletter) && $result) {
      


Mir ist aber nach der Löschung des Testusers noch etwas anderes aufgefallen, denn gelöschte User bleiben ja als deleted in der DB, und werden somit im Block "zuletzt angemeldete User" immer noch angezeigt, obwohl sie gar nicht mehr existieren.

Nur mal so am Rande!
Gruß
Bernd

[junky]

Der Fehler muß woanders liegen, weil der Fehler auch auftritt wenn ein user sich selbst anmeldet. Das hat ja dann mit der users.php nix zu tun, oder?

Habe meine Dateien gerade nochmal mit den des 2.1a Basic/AddOn Packs ersetzt - genau derselbe Fehler.

Ich hatte dieses Problem damals schon einmal, keine Ahnung was es damals war....

Kann es etwas damit zu tun haben, daß ich damals von einem alten phpnuke geupdated hatte und nun noch in der DB nuke_users_ stehen habe?

Neuerdings müßte das doch mx_users_ sein, oder ist das wurscht?

Wenn ich mir den letzten User anschaue, der sich bei mir selbst registriert hat so war das am 08.11.03 !
Nun finde ich in meiner DB die Spalten:   _mx_installed_tables_2003_11_26_05_54_25 die vom 26.11.03 zu sein scheinen.

Welchen zweck haben diese Spalten?

Liegt es vielleicht daran?

Struktur der VKPMX 2.1a DB:

#
# Tabellenstruktur für Tabelle `mx_users`
#

CREATE TABLE `mx_users` (
  `uid` int(11) unsigned NOT NULL auto_increment,
  `name` varchar(60) NOT NULL default '',
  `uname` varchar(25) NOT NULL default '',
  `email` varchar(100) NOT NULL default '',
  `femail` varchar(100) NOT NULL default '',
  `url` varchar(255) NOT NULL default '',
  `user_avatar` varchar(30) default NULL,
  `user_regdate` varchar(20) NOT NULL default '',
  `user_icq` varchar(15) default NULL,
  `user_occ` varchar(100) default NULL,
  `user_from` varchar(100) default NULL,
  `user_intrest` varchar(150) default NULL,
  `user_sig` varchar(255) default NULL,
  `user_viewemail` tinyint(2) default NULL,
  `user_theme` int(3) default NULL,
  `user_aim` varchar(18) default NULL,
  `user_yim` varchar(25) default NULL,
  `user_msnm` varchar(25) default NULL,
  `pass` varchar(40) NOT NULL default '',
  `storynum` tinyint(4) NOT NULL default '10',
  `umode` varchar(10) NOT NULL default '',
  `uorder` tinyint(1) NOT NULL default '0',
  `thold` tinyint(1) NOT NULL default '0',
  `noscore` tinyint(1) NOT NULL default '0',
  `bio` tinytext NOT NULL,
  `ublockon` tinyint(1) NOT NULL default '0',
  `ublock` text NOT NULL,
  `theme` varchar(100) NOT NULL default '',
  `commentmax` int(11) NOT NULL default '4096',
  `counter` int(11) NOT NULL default '0',
  `newsletter` int(1) NOT NULL default '0',
  `user_posts` int(10) NOT NULL default '0',
  `user_attachsig` int(2) NOT NULL default '0',
  `user_rank` int(10) NOT NULL default '0',
  `user_level` int(10) NOT NULL default '1',
  `user_ingroup` int(10) NOT NULL default '1',
  `user_lastvisit` int(11) NOT NULL default '0',
  `user_regtime` int(11) unsigned NOT NULL default '0',
  `user_lastip` varchar(60) NOT NULL default '',
  `user_lastmod` varchar(40) NOT NULL default '',
  `user_lasturl` varchar(255) NOT NULL default '',
  `user_pm_poptime` smallint(4) unsigned NOT NULL default '0',
  `user_stat` tinyint(1) NOT NULL default '0',
  `user_bday` date default NULL,
  `user_sexus` tinyint(1) unsigned NOT NULL default '0',
  PRIMARY KEY  (`uid`),
  UNIQUE KEY `uname` (`uname`),
  KEY `user_ingroup` (`user_ingroup`),
  KEY `user_stat` (`user_stat`),
  KEY `user_lastvisit` (`user_lastvisit`),
  KEY `user_lastmod` (`user_lastmod`),
  KEY `user_bday` (`user_bday`)
) TYPE=MyISAM AUTO_INCREMENT=2 ;

Struktur meiner jetzigen DB:

Code Auswählen Erweitern

#
# Tabellenstruktur für Tabelle `nuke_users`
#

CREATE TABLE nuke_users (
  uid int(11) unsigned NOT NULL auto_increment,
  name varchar(60) NOT NULL default '',
  uname varchar(25) NOT NULL default '',
  email varchar(100) NOT NULL default '',
  femail varchar(100) NOT NULL default '',
  url varchar(255) NOT NULL default '',
  user_avatar varchar(30) default NULL,
  user_regdate varchar(20) NOT NULL default '',
  user_icq varchar(15) default NULL,
  user_occ varchar(100) default NULL,
  user_from varchar(100) default NULL,
  user_intrest varchar(150) default NULL,
  user_sig varchar(255) default NULL,
  user_viewemail tinyint(2) default NULL,
  user_theme int(3) default NULL,
  user_aim varchar(18) default NULL,
  user_yim varchar(25) default NULL,
  user_msnm varchar(25) default NULL,
  pass varchar(40) NOT NULL default '',
  storynum tinyint(4) NOT NULL default '10',
  umode varchar(10) NOT NULL default '',
  uorder tinyint(1) NOT NULL default '0',
  thold tinyint(1) NOT NULL default '0',
  noscore tinyint(1) NOT NULL default '0',
  bio tinytext NOT NULL,
  ublockon tinyint(1) NOT NULL default '0',
  ublock text NOT NULL,
  theme varchar(100) NOT NULL default '',
  commentmax int(11) NOT NULL default '4096',
  counter int(11) NOT NULL default '0',
  newsletter int(1) NOT NULL default '0',
  user_posts int(10) NOT NULL default '0',
  user_attachsig int(2) NOT NULL default '0',
  user_rank int(10) NOT NULL default '0',
  user_level int(10) NOT NULL default '1',
  user_ingroup int(10) NOT NULL default '1',
  user_regtime int(11) unsigned NOT NULL default '0',
  user_lastvisit int(11) NOT NULL default '0',
  user_lastip varchar(60) NOT NULL default '',
  user_lastmod varchar(40) NOT NULL default '',
  user_lasturl varchar(255) NOT NULL default '',
  user_stat tinyint(1) NOT NULL default '0',
  user_pm_poptime smallint(4) unsigned NOT NULL default '0',
  user_bday date default NULL,
  user_sexus tinyint(1) unsigned NOT NULL default '0',
  PRIMARY KEY  (uid),
  KEY user_ingroup (user_ingroup),
  KEY user_stat (user_stat),
  KEY user_lastvisit (user_lastvisit),
  KEY user_lastmod (user_lastmod),
  KEY user_bday (user_bday)
) TYPE=MyISAM;

Sieht jemand Unterschiede?

Was mir noch auffällt ist die "Kardinalität" der UID636, welche ich als Admin User bin. Kann man das entfernen?
Und das mir Myphpadmin bei den Eigenschaften dieser Spalte:  Nächste Autoindex      4.294.967.295

[Andi]

Moin

die uid wird automatisch vom mySql generiert. Das erledigt die Funktion mysql_insert_id(), welche den nächsten verfügbaren autoincrementwert der jeweiligen Tabelle ausliest.
Diese Funktion kann durcheinander kommen, bei fehlerhaften Tabellenimporten, oder wenn in dieser uid-Spalte negative Werte drin stehen.

Ist also kein Fehler im vkpMx, sondern einfach nur in der Usertabelle selbst.

Schau mal nach, wie viele User mit solchen verrückten UID's, oder mit negativen UID's,  in der Tabelle sind. Sind es nicht viele und haben die noch nichts auf der Seite geschrieben, dann lösche die. Anschliessend machst du über das adminmenü eine Datenbankoptimierung. Das Problem müsste dann behoben sein.
Sind es zu viele, dann müssen wir das anders machen....

Kann es etwas damit zu tun haben, daß ich damals von einem alten phpnuke geupdated hatte und nun noch in der DB nuke_users_ stehen habe?

Neuerdings müßte das doch mx_users_ sein, oder ist das wurscht?

Solange der user_prefix auch "nuke" lautet, kein Problem...

Welchen zweck haben diese Spalten?

Diese Tabelle enthält die ursprüngliche Tabellenstruktur, vor der Installation des vkpMx. Braucht man nur zur Fehlersuche im Support. Wenn das Setup problemlos durchgelaufen ist, kann man diese Tabelle löschen.

[junky]

kein User hat eine negative UID!

Ab UID Nr:11 laufen die UID bis 654 fein säuberlich in einer Schritten durch!

Trotzdem sagt mir die sql: Nächste Autoindex      4.294.967.295 !!! Und genau die Nummer bekommt dann der neue User!

Ich finde keinen auffälligen User! Mir fehlen nur ein paar UIDs komplett: 2,3,5,6,7,8,10 die bestimmt mal von Hand gelöscht wurden.

UID1 ist der Anonymous User....

Jetzt weiß ich nicht mehr weiter...

[Andi]

Oki, ist doch alles im grünen Bereich.

Wenn du im phpMyAdmin die Tabelle optimierst, müsste der Fehler weg sein.

Wenn nicht, dann:
- exportiere die Usertabelle ohne die Option "AUTO_INCREMENT-Wert hinzufügen" anzukreuzen.
- lösche die Usertabelle, oder benenne sie um
- spiele den vorher exportierten Dump wieder ein

[junky]

Das Optimieren hat gar nix gebracht, aber wenn man in der Tabelle auf "Operationen" geht, sieht man unten den Wert "Auto Increment", und dort stand diese wahnsinnig große Zahl drin. Wer weiß warum. Die habe ich da raus gemacht und ok gedrückt!

Siehe da, er tut es wieder!

Danke euch Jungs....

[Andi]

Die habe ich da raus gemacht und ok gedrückt!

uuups, siehste, diese Methode kannte ich auch noch nicht...
Man lernt nie aus 

[Biker]

Der Fehler muß woanders liegen, weil der Fehler auch auftritt wenn ein user sich selbst anmeldet. Das hat ja dann mit der users.php nix zu tun, oder?

Na datt hättse auch jleich saaje könne.... meen Jung! *lol*
Dann hätt isch doch datt Fehlerken nich inne users.php jesucht!

Aber egal...jetzt läuft ett ja widda!

Gruß
Bernd