News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

nach update auf 1.1.1: neuanmeldungen werden sofort admins!

Started by beenhakker, January 06, 2007, 01:16:37 PM

Previous topic - Next topic

beenhakker

eine katastrophe: meine neuanmeldungen von heute sind (nach dem gestrigen upgrade auf 1.1.1) alle direkt in der admin-gruppe und haben alle rechte!

woran liegt das und wie kann ich mir helfen?

danke schonmal für eure statements und einen schönen restsamstag noch.

gr.,
been

dieter4

Erstmal zur Sicherheit die Registrierung deaktivieren.

Jetzt die Standardfragen:
Von welcher Version auf 1.1.1? Modifikationen installiert? Selber an SMF rumgeschraubt?

beenhakker

hallo,
die registrierung haben wir gestoppt.

habe gestern von 1.0.9 auf 1.0.10 und dann auf 1.1.1 upgegraded. wie es in den mitteilungen gestanden hat.
mods habe ich keine drin und rumgeschraubt (bis auf das entfernen der buttons unten im copyright-table) hab ich auch nicht. ok, die style.css natürlich - aber das dürfte ja nicht der urheber des problems sein.

gruß,
been

beenhakker

wenn es hilft, dann stelle ich mal ein paar codeschnipsel hier rein. ich müsste nur wissen, aus welcher / welchen dateien.
zur info auch mal der link zum forum: http://forum.vorupoer.info [nofollow]

gruß,
joe

dieter4


beenhakker

nun, ich habe mir die downloads "smf_1-0-10_update" und "smf_1-1-1_update" aus dem download-bereich geholt und beide nacheinander per ftp auf den server übertragen.
hätte es ggf. ausgereicht, wenn ich nur das "smf_1-0-10_update" auf diese weise installiert hätte um dann im anschluss über den paketmanager im forum das upgrade auf 1.1.1 durchzuführen?

wenn dadurch der fehler auftrat, wie bekomme ich jetzt das problem gelöst? macht es ggf. sinn, wenn ich für gewisse php-dateien frühere backups der 1.0.9 version aufspiele oder aber ein komplettes backup der dateien aus 1.0.9 auf den server lade und vorher alle aktuellen dateien lösche, um anschließend den richtigen weg des upgrades nochmal durchzuführen?

gruß,
joe

beenhakker

also wenn dieser fehler schwer zu beheben ist, würde ich dann mal probieren, die alten daten aus 1.0.9 wieder auf den server zu packen und die alte version wieder rennen zu lassen. (oder wurden bei den letzten upgrades datenbanktabellen so verändert, dass ein rückschritt zu 1.0.9 nicht funktionieren würde???)
dann kommt das 1.0.10 drüber und dann müsste ich ja das patch-paket für das update auf 1.1.1 im paketmanager finden, oder?

gruß,
been

Daniel D.

Hast Du Backups gemacht? Wenn ja, dann spiele das Datenbank-Backup zurück und ebenfalls Deine 1.0.9 Dateien. Danach solltest Du wieder bei 1.0.9 sein. Jetzt lädst Du Dir das 1.1.1 Upgrade Paket runter, entpackst es, lädst die Dateien auf den Server hoch und führst die upgrade.php aus.

beenhakker

mein letztes dump ist von september 2006. ich wäre deshalb froh, wenn es auch ohne datenbank backup ginge. meinst du ich kann es so riskieren?

und: ich dachte ein direktes upgrade von 1.0.9 auf 1.1.1 geht nicht (also ohne 1.0.10) dazwischen...

gruß,
been

Daniel D.

Das mit den Backups wird aber oft genug gesagt :-\.

Warum sollte das nicht gehen? Dazu ist doch die Upgradeversion. Hast Du irgendwann die upgrade.php ausgeführt?

beenhakker

ja ich weiß... diese backups immer  ::)

ich habe mir die upgrades von 1.0.10 und 1.1.1 besorgt und beide nacheinander über das ausführen der upgrade.php draufgespielt.
ich habe nicht den paketmanager benutzt.

also im grunde habe ich es gemacht wie du jetzt beschreibst, hatte aber die 1.0.10 dazwischen. daran wirds wohl gelegen haben.

habe übrigens bei der installation von 1.0.10. (letzten samstag) das glück gehabt, dass die install.php alle aktuellen tabellen gebackupt hat. also werde ich alle diese backups zurückspielen, bis auf die smf_messages (um keine beiträge seit samstag zu verlieren) und die smf_topics und ein paar von den smf_log_...

da bin ich ja mal gespannt!

danke erstmal für eure hilfe! melde mich wieder, wenns nachher schlimmer aussieht als jetzt  :-X

been

Daniel D.

Die install.php hättest Du nicht ausführen müssen/sollen! Die sollte auch nicht im Paket gewesen sein.

beenhakker

stimmt, hast recht. ich meinte die upgrade.php. sorry!

ianus

Grüße!
Kristallkugel rubbel:

,,habe übrigens bei der installation von 1.0.10. (letzten samstag) das glück gehabt, dass die install.php alle aktuellen tabellen gebackupt hat. also werde ich alle diese backups zurückspielen, bis auf die smf_messages (um keine beiträge seit samstag zu verlieren) und die smf_topics und ein paar von den smf_log_..."

Was heißt ,,zurückspielen"?

Die backup_smf_dingsda Tabellen sind mit der Version 1.1.x nicht kompatibel!

Du musst, wenn Du diese Tabellen benutzen willst wieder eine 1.0.x Version laufen lassen.

Doch Vorsicht. Ich habe versucht die backup_smf_dingsda Tabellen mit einem 1.0.x SMF zu benutzen, was bei angepassten Pfaden funktioniert.
Ein neuerliches upgrade auf 1.1.x hat dann aber alle Tabellen komplett zerschossen. Es werden keine backup_backup_smf_dingsda Tabellen erzeugt.

Also, erst würde ich nun empfehlen Deine Datenbank zu sichern. PHPmyadmin->exportieren
Und immer und überall daran denken: Save often, save early!
Das gilt generell und nicht nur beim SMF.

Dann habe ich bemerkt, dass es vorkommt, dass nach einem SMF upgrade von 1.0.x auf 1.1.x, einige Einstellungen etwas frei interpretiert werden.
Auffällig wurde dies bei mir zum ersten Mal bei den Spracheinstellungen, das tut aber hier nichts zur Sache.

Gehe im Admin Menü auf die Seite mit den (Erlaubt,Nicht-Erlaubt-) Einstellungen für die Mitgliedergruppen. Öffne jede einzelne, also modify, und speichere diese dann erneut.

beenhakker

also ich habe jetzt nach allen erkenntnissen von hier die sache nochmal durchgezogen:

- datenbankbackup von 1.0.9 eingelesen
- alle dateien auf dem server zur version 1.0.9 verändert (backups)
- das forum zum laufen gebracht, also version 1.0.9 (und die test-anmeldungen waren in ordnung, neue werden user - nicht admins!)

- dann das upgrade von 1.1.1 gezogen,
- auf den server gespielt, upgrade.php ausgeführt
- upgrade lief durch ohne probleme

- dann meine getunte style.css draufgeladen
- version 1.1.1 lief

aaaber: neuanmeldungen werden wieder admin!

tja. was ist da los? ist wohl ein thema für ne doktorabeit?!

übrigens ianus: deine tipps habe ich beherzigt, was die mitgliedergruppen betrifft. hier war aber im grunde alles wie gehabt.

wäre nett, wenn noch jemand tipps auf lager hat! die community muss wachsen ;)

gruß,
been

beenhakker

zur info: an dem gewählten theme kann es nicht liegen. das user/admin-problem taucht auch bei den themes babylon und default auf.

deshalb vermute ich den fehler nicht in einer datei im theme-verzeichnis. welche php-dateien sind denn für das reg.-management im root zuständig?

übrigens: wenn ich einen neuen user aus dem admin-bereich anlege, dann funktioniert es und er kommt in die usergruppe.

im übrigen habe ich im registrierungs-management nicht die option eingestellt, dass neue user admin werden sollen.

gruß,
been

Jorin

Puh... Ich glaube, ich habe die richtigen Stellen gefunden (nach langem Suchen). Da ich aber kein PHP-Experte bin, kann ich dir nur sagen, wie es bei mir ausschaut. Zum Vergleich.

Die Registrierung selbst wird in der /Sources/Register.php verwaltet. Dort steht bei mir ab Zeile 137:
// Actually register the member.
function Register2()
{
global $scripturl, $txt, $modSettings, $db_prefix, $context, $sourcedir;
global $user_info, $options, $settings, $func;

// Well, if you don't agree, you can't register.
if (!empty($modSettings['requireAgreement']) && (empty($_POST['regagree']) || $_POST['regagree'] == 'no'))
redirectexit();

// Make sure they came from *somewhere*, have a session.
if (!isset($_SESSION['old_url']))
redirectexit('action=register');

// You can't register if it's disabled.
if (!empty($modSettings['registration_method']) && $modSettings['registration_method'] == 3)
fatal_lang_error('registration_disabled', false);

foreach ($_POST as $key => $value)
{
if (!is_array($_POST[$key]))
$_POST[$key] = htmltrim__recursive(str_replace(array("\n", "\r"), '', $_POST[$key]));
}
require_once($sourcedir . '/CustomProfile.php');
CheckFieldInput();

// Are they under age, and under age users are banned?
if (!empty($modSettings['coppaAge']) && empty($modSettings['coppaType']) && !isset($_POST['skip_coppa']))
{
// !!! This should be put in Errors, imho.
loadLanguage('Login');
fatal_lang_error('under_age_registration_prohibited', false, array($modSettings['coppaAge']));
}

// Check whether the visual verification code was entered correctly.
if (empty($modSettings['disable_visual_verification']) && (empty($_REQUEST['visual_verification_code']) || strtoupper($_REQUEST['visual_verification_code']) !== $_SESSION['visual_verification_code']))
fatal_lang_error('visual_verification_failed', false);

// Collect all extra registration fields someone might have filled in.
$possible_strings = array(
'websiteUrl', 'websiteTitle',
'AIM', 'YIM',
'location', 'birthdate',
'timeFormat',
'buddy_list',
'pm_ignore_list',
'smileySet',
'signature', 'personalText', 'avatar',
'lngfile',
'secretQuestion', 'secretAnswer',
);
$possible_ints = array(
'pm_email_notify',
'notifyTypes',
'ICQ',
'gender',
'ID_THEME',
);
$possible_floats = array(
'timeOffset',
);
$possible_bools = array(
'notifyAnnouncements', 'notifyOnce', 'notifySendBody',
'hideEmail', 'showOnline',
);

if (isset($_POST['secretAnswer']) && $_POST['secretAnswer'] != '')
$_POST['secretAnswer'] = md5($_POST['secretAnswer']);

// Needed for isReservedName() and registerMember().
require_once($sourcedir . '/Subs-Members.php');

// Validation... even if we're not a mall.
if (isset($_POST['realName']) && (!empty($modSettings['allow_editDisplayName']) || allowedTo('moderate_forum')))
{
$_POST['realName'] = trim(preg_replace('~[\s]~' . ($context['utf8'] ? 'u' : ''), ' ', $_POST['realName']));
if (trim($_POST['realName']) != '' && !isReservedName($_POST['realName'], $memID))
$possible_strings[] = 'realName';
}

if (isset($_POST['MSN']) && preg_match('~^[0-9A-Za-z=_+\-/][0-9A-Za-z=_\'+\-/\.]*@[\w\-]+(\.[\w\-]+)*(\.[\w]{2,6})$~', $_POST['MSN']) != 0)
$profile_strings[] = 'MSN';

// Handle a string as a birthdate...
if (isset($_POST['birthdate']) && $_POST['birthdate'] != '')
$_POST['birthdate'] = strftime('%Y-%m-%d', strtotime($_POST['birthdate']));
// Or birthdate parts...
elseif (!empty($_POST['bday1']) && !empty($_POST['bday2']))
$_POST['birthdate'] = sprintf('%04d-%02d-%02d', empty($_POST['bday3']) ? 0 : (int) $_POST['bday3'], (int) $_POST['bday1'], (int) $_POST['bday2']);

// Validate the passed langauge file.
if (isset($_POST['lngfile']) && !empty($modSettings['userLanguage']))
{
$language_directories = array(
$settings['default_theme_dir'] . '/languages',
$settings['actual_theme_dir'] . '/languages',
);
if (!empty($settings['base_theme_dir']))
$language_directories[] = $settings['base_theme_dir'] . '/languages';
$language_directories = array_unique($language_directories);

foreach ($language_directories as $language_dir)
{
if (!file_exists($language_dir))
continue;

$dir = dir($language_dir);
while ($entry = $dir->read())
if (preg_match('~^index\.(.+)\.php$~', $entry, $matches) && $matches[1] == $_POST['lngfile'])
{
// Got it!
$found = true;
$_SESSION['language'] = $_POST['lngfile'];
break 2;
}
$dir->close();
}

if (empty($found))
unset($_POST['lngfile']);
}
else
unset($_POST['lngfile']);

// Set the options needed for registration.
$regOptions = array(
'interface' => 'guest',
'username' => $_POST['user'],
'email' => $_POST['email'],
'password' => $_POST['passwrd1'],
'password_check' => $_POST['passwrd2'],
'check_reserved_name' => true,
'check_password_strength' => true,
'check_email_ban' => true,
'send_welcome_email' => !empty($modSettings['send_welcomeEmail']),
'require' => !empty($modSettings['coppaAge']) && !isset($_POST['skip_coppa']) ? 'coppa' : (empty($modSettings['registration_method']) ? 'nothing' : ($modSettings['registration_method'] == 1 ? 'activation' : 'approval')),
'extra_register_vars' => array(),
'theme_vars' => array(),
);

// Include the additional options that might have been filled in.
foreach ($possible_strings as $var)
if (isset($_POST[$var]))
$regOptions['extra_register_vars'][$var] = '\'' . htmlspecialchars($_POST[$var]) . '\'';
foreach ($possible_ints as $var)
if (isset($_POST[$var]))
$regOptions['extra_register_vars'][$var] = (int) $_POST[$var];
foreach ($possible_floats as $var)
if (isset($_POST[$var]))
$regOptions['extra_register_vars'][$var] = (float) $_POST[$var];
foreach ($possible_bools as $var)
if (isset($_POST[$var]))
$regOptions['extra_register_vars'][$var] = empty($_POST[$var]) ? 0 : 1;

// Registration options are always default options...
if (isset($_POST['default_options']))
$_POST['options'] = isset($_POST['options']) ? $_POST['options'] + $_POST['default_options'] : $_POST['default_options'];
$regOptions['theme_vars'] = isset($_POST['options']) && is_array($_POST['options']) ? $_POST['options'] : array();

$memberID = registerMember($regOptions);

// If COPPA has been selected then things get complicated, setup the template.
if (!empty($modSettings['coppaAge']) && !isset($_POST['skip_coppa']))
redirectexit('action=coppa;member=' . $memberID);
// Basic template variable setup.
elseif (!empty($modSettings['registration_method']))
{
loadTemplate('Register');

$context += array(
'page_title' => $txt[97],
'sub_template' => 'after',
'description' => $modSettings['registration_method'] == 2 ? $txt['approval_after_registration'] : $txt['activate_after_registration']
);
}
else
{
setLoginCookie(60 * $modSettings['cookieTime'], $memberID, sha1(sha1(strtolower($regOptions['username']) . $regOptions['password']) . substr($regOptions['register_vars']['passwordSalt'], 1, -1)));

redirectexit('action=login2;sa=check;member=' . $memberID, $context['server']['needs_login_fix']);
}
}


Wichtiger ist aber wohl die /Sources/Subs-Members.php, wo letztendlich für sich registrierende User die Membergroup eingestellt ist, in der sie dann automatisch landen (ab Zeile 744:
if (isset($regOptions['memberGroup']))
{
// Make sure the ID_GROUP will be valid, if this is an administator.
$regOptions['register_vars']['ID_GROUP'] = $regOptions['memberGroup'] == 1 && !allowedTo('admin_forum') ? 0 : $regOptions['memberGroup'];

// Check if this group is assignable.
$unassignableGroups = array(-1, 3);
$request = db_query("
SELECT ID_GROUP
FROM {$db_prefix}membergroups
WHERE minPosts != -1", __FILE__, __LINE__);
while ($row = mysql_fetch_assoc($request))
$unassignableGroups[] = $row['ID_GROUP'];
mysql_free_result($request);

if (in_array($regOptions['register_vars']['ID_GROUP'], $unassignableGroups))
$regOptions['register_vars']['ID_GROUP'] = 0;
}

beenhakker

puh!  ;D
dann werd ich doch mal jeweils beide abgleichen! danke zunächst mal - vielleicht wirst du der mit dem doktortitel!

beenhakker

hier das ergebnis:

nach austausch der zeilen in der register.php (die sich in gewissen bereichen schon von meiner register.php unterscheidet), meldete beim absender der registrierung das script eine fehlermeldung mit verweis auf zeile 186 in der register.php.

läuft bei dir auch die version 1.1.1? vielleicht macht es sinn, wenn ich mal deine komplette register.php bei mir reinpflanze... ggef. auch deine komplette subs-members.php.

die subs-members.php ist bei mir in diesem abschnitt allerdings absolut identisch mit deiner.

gruß,
been

Jorin

1.1RC3. Kann sein, dass sich da etwas geändert hat und du deswegen die Fehlermeldung erhälst. Deswegen sagte ich auch nichts von "ersetzen", sodern sprach von "vergleichen"!  ;)

Spricht ja aber nichts dagegen, diese beiden Dateien nochmal aus dem frischen Zip-Paket der 1.1.1 zu nehmen und auf den Server zu kopieren.

ianus

Grüße!

Ja, die Idee ist wirklich gut, die Umsetzung scheinbar jedoch etwas schwieriger.

Ich habe auch nach der Stelle gesucht, an der die Angaben bei einer neuen Registrierung in die Datenbank geschrieben werden.
Gefunden habe ich jedoch keine konkretere Stelle, als die hier schon genannten.

Neben den Dateien, die nehcregit genannt hat, lohnt sich vielleicht auch noch ein Blick an folgende Stellen in der Subs-Members.php

Dort finden sich (in der Version 1.1.1) folgende Einträge:

// Fetch a list of groups members cannot be assigned to explicitely.
$implicitGroups = array(-1, 0, 3);
$request = db_query("
SELECT ID_GROUP
FROM {$db_prefix}membergroups
WHERE minPosts != -1", __FILE__, __LINE__);
while ($row = mysql_fetch_assoc($request))
$implicitGroups[] = $row['ID_GROUP'];
mysql_free_result($request);

Und vor allem


// Some of these might be overwritten. (the lower ones that are in the arrays below.)
$regOptions['register_vars'] = array(
'memberName' => "'$regOptions[username]'",
'emailAddress' => "'$regOptions[email]'",
'passwd' => '\'' . sha1(strtolower($regOptions['username']) . $regOptions['password']) . '\'',
'passwordSalt' => '\'' . substr(md5(rand()), 0, 4) . '\'',
'posts' => 0,
'dateRegistered' => time(),
'memberIP' => "'$user_info[ip]'",
'memberIP2' => "'$_SERVER[BAN_CHECK_IP]'",
'validation_code' => "'$validation_code'",
'realName' => "'$regOptions[username]'",
'personalText' => '\'' . addslashes($modSettings['default_personalText']) . '\'',
'pm_email_notify' => 1,
'ID_THEME' => 0,
'ID_POST_GROUP' => 4,
'lngfile' => "''",
'buddy_list' => "''",
'pm_ignore_list' => "''",
'messageLabels' => "''",
'personalText' => "''",
'websiteTitle' => "''",
'websiteUrl' => "''",
'location' => "''",
'ICQ' => "''",
'AIM' => "''",
'YIM' => "''",
'MSN' => "''",
'timeFormat' => "''",
'signature' => "''",
'avatar' => "''",
'usertitle' => "''",
'secretQuestion' => "''",
'secretAnswer' => "''",
'additionalGroups' => "''",
'smileySet' => "''",
);


Eigentlich spricht nichts dagegen, den gesamten Source Ordner durch einen neu herunter geladenen zu ersetzen.
Da dieses Problem offensichtlich nicht häufiger auftritt, ist der Source code wohl nicht fehlerhaft. So lässt sich dann ausschließen, dass hier irgendwo ein Fehler liegt.


Dann habe ich überlegt, ob es vielleicht an den Vorhandenen Benutzergruppen liegt. Scheinbar braucht das SMF die Gruppe der ,,unzugeordneten Benutzer" um sicher zu stellen, dass Benutzer nicht plötzlich ganz ohne Gruppe da stehen, wenn die Gruppe zu der sie eigentlich gehören gelöscht wird.
Fragt sich also, ob Du irgendwelche Benutzergruppen gelöscht hast, die vielleicht notwendig sind. Z.B gibt es eine beitragsabhängige Gruppe die die Beiträge 0 bis wasauchimmer abdeckt?

Dann ist da die Frage, was in die Datenbank eingetragen wird, wenn sich ein Benutzer anmeldet. Die fragliche Tabelle ist wohl smf_members und darin die ID_Post_Group.


Notdüftig flicken lässt sich die Anmeldung vielleicht mir Membergroup On Registration. Das ist aber sicherlich keine Antwort auf das generelle Problem.


beenhakker

danke erstmal! alleine für die mühe, die ihr euch hier mit mir macht, sollte ich euch ggf. ein glas vollmich ausgeben. wer bier mag, bekommt auch sowas!

ich werde nachher mal die codes in der subs-members.php auf den neuen tipp checken und wenn das nicht funzt, das download ausprobieren. letzteres wäre zwar wirklich nur eine notdürftige flickerei - aber wenn's funktioniert eine sehr gute :)

bis später!
been

Jorin

Lieber Milch mit einem Löffel Kakao! Einfach lecker!  :D

beenhakker

ich habe jetzt nochmal die subs-members.php genauer betrachtet.
wie es mir scheint, spielt die id_post_group in der smf_members nicht die wesentliche rolle, da hier lediglich die rangliste auf basis der geschriebenen einträge ermittelt wird.

eher ist es die id_group. hier haben alle normalen user, egal was für einen rang sie haben, den eintrag 'null', also '0' in der smf_members tabelle.

die admins (und wir sind nur zu zweit!) haben die 'eins', also '1'.

neuanmeldungen werden generell in die datenbank mit id_group = 1 verschoben. richtig wäre doch id_group = 0.
jetzt brauche ich nur noch jemanden, der herausfindet, an welcher stelle in welcher datei (oder welchen stellen in welchen dateien!) genau diese unterscheidung gemacht wird.

alle, die kakao haben wollen: bitte grübeln sie jetzt!

ps. nachher teste ich mir mal das membergroup-mod. wenn's dann funzt, ok. aber den fehler mit den nullen und einsen (besteht hier nicht alles aus nullen und einsen...? - ich wäre da so eine 'null' ;) ) würd ich schon trotzdem gerne beheben.

Jorin

Was die Group-ID angeht, hast du recht: 0=Mitglied, 1=Admin. Aber ich weiß auch nicht, wo letztendlich dieser Eintrag gemacht wird, entschuldige.

ianus

Grüße!

Bei der Gruppenzordnung habe ich mich ein wenig vertan, mein Fehler.
So wie ich das sehe, gibt die ID_Group die generelle Benutzergruppe an, die ID_Post_Group die Mitgliedschaft in einer ,,beitragsbasierten" Gruppen.

Gedanklich war ich bei meinem obigen Beitrag noch bei eventuell gelöschten Benutzergruppen und habe mich gefragt, was passiert, wenn es keine beitragsabhängige Gruppe gibt, in die ein neu angemeldeter Benutzer hinein passt.

Zur Zuordnung in eine Gruppe bei der Registrierung habe ich folgenden Beitrag gefunden.
Re: Set custom membership as default

Das löst dieses Problem zwar nicht direkt, gibt aber imho einen Hinweis auf die Stelle, an der bei der Registrierung festgelegt wird, in welcher Gruppe ein neues Mitglied landet.

Quote from: akabugeyes on October 15, 2006, 09:35:16 PM
Well, not only are they placed in the Newbie post count based group, but they are placed in the group "Regular Members" although that group doesn't appear next to the members posts and in their profile.

Anyways, what you can do is,

Open Sources/Subs-Members.php,

Find:

// Otherwise it must be awaiting approval!
else
$regOptions['register_vars']['is_activated'] = 3;


Add after:

// Respect the possibility of an external script registering...
$regOptions['memberGroup'] = isset($regOptions['memberGroup']) ? $regOptions['memberGroup'] : 9;


Changing the 9 in the code to the group ID you want your members to register to.

Ich wollte aber nicht eine Gruppe speziell definieren, sondern sicher sein, dass die Gruppe 0 gewählt wird. Etwas unter den angegebenen Zeilen findet sich der code

$regOptions['register_vars']['ID_GROUP'] = 0;

und um zu testen, habe ich die Zeile auf meinem localhost geändert, also die 0 durch eine 6 getauscht.
(Bei mir gibt es nur die Gruppe ,,Newbie", die Gruppe 4 als beitragsabhängige Gruppe – was so dann auch in die ID_Post_Group eingetragen wird. Die Gruppe 6 ist eine der Regulären Gruppen, die unter ID_Group erscheint.)


Ich habe in der gleichen Datei dann auch die Zeilen

// Do the actual updates.
if ($type == 'only_additional')
db_query("
UPDATE {$db_prefix}members
SET additionalGroups = IF(additionalGroups = '', '$group', CONCAT(additionalGroups, ',$group')))
WHERE ID_MEMBER IN (" . implode(', ', $members) . ")
AND ID_GROUP != $group
AND NOT FIND_IN_SET($group, additionalGroups)
LIMIT " . count($members), __FILE__, __LINE__);
elseif ($type == 'only_primary' || $type == 'force_primary')
db_query("
UPDATE {$db_prefix}members
SET ID_GROUP = $group
WHERE ID_MEMBER IN (" . implode(', ', $members) . ")" . ($type == 'force_primary' ? '' : "
AND ID_GROUP = 0
AND NOT FIND_IN_SET($group, additionalGroups)") . "
LIMIT " . count($members), __FILE__, __LINE__);
elseif ($type == 'auto')
db_query("
UPDATE {$db_prefix}members
SET
additionalGroups = IF(ID_GROUP = 0, additionalGroups, IF(additionalGroups = '', '$group', CONCAT(additionalGroups, ',$group'))),
ID_GROUP = IF(ID_GROUP = 0, $group, ID_GROUP)
WHERE ID_MEMBER IN (" . implode(', ', $members) . ")
AND ID_GROUP != $group
AND NOT FIND_IN_SET($group, additionalGroups)
LIMIT " . count($members), __FILE__, __LINE__);

entsprechend geändert.

Dabei habe ich aber keinen Schimmer, was dort nun genau eingestellt wird, sondern einfach auf Verdacht gebastelt.

Das Ergebnis bleibt aber gleich. Der neue Benutzer erscheint, doch die ID_Group bleibt 0.

Zumindest weist Du nun, wo Du mit etwas eingefügtem code eine Zuweisung erzwingen kannst.
Auch dies klärt aber die generelle Frage nicht.

Damit bin ich mit meinen Ideen am Ende. Wenn Du den Sources – Ordner mit einem neu herunter geladenen überschrieben hast, sollten die Einstellungen in den php Dateien in Ordnung sein.
Wenn Du auch keinen Schnitzer in der Gruppenzuteilung hast und bei Dir in der Datenbank eine 0 angezeigt wird, ...

Vielleicht schaut hier ja jemand rein, der in dem SMF code zuhause ist. Alternativ würde ich anbieten diese Frage im englisch sprachigen support zu stellen.

beenhakker

jo vielen dank nochmals an alle, die versucht haben, zu helfen!  :)

ich habe mich vor drei tagen entschieden, das smf komplett neu aufzulegen und sauber bis zum 1.1.1 upzugraden. das ist jetzt erledigt, alle beiträge etc. sind wieder in die datenbank reingeschrubbelt worden und nu läuft der kasten, wie er soll.

wahrscheinlich hatte ich meine unegalen finger in den letzten jahren zu häufig in den codes und daraus entstand wohl eine gewisse instabilität. das lass ich jetzt sein, denn ich habe mir eine testumgebung für das forum geschaffen, wo ich alle spielereien an datenbanken und codes vorher ausprobieren werde!

viele grüße,
been

Advertisement: