Beiträge von dwet

Ich habe einen Blog Artikel verfasst - Wie benutze ich die Suche richtig - Bitte diesen beachten und auch umsetzen bevor Ihr ein Neues Thema eröffnet!

  • Unterstützung - Mehraugenprinzip - Spieldaten - Torschützen - Karten

    Nur die Ruhe, ich sehe da kein Mosern. Nur einen Hinweis auf ein mögliches Problem.


    Man kann so einen Hinweis ja auch als Mitarbeiten verstehen, woanders ist es ja auch üblich, dass die Nutzer aufgefordert sind, mögliche(!) Fehler oder Probleme zu melden. Nichts anderes hat der Threadersteller doch hier gemacht. Nicht, das sich am Ende keiner mehr traut, hier was zu posten, nur weil er selber bisher noch nichts in Code oder Daten konkret umgesetztes geschrieben hat, das wollen wir doch alle dann auch wieder nicht?

  • Verdächtig "guter" Tipper

    wenn jemand nachträglich die Tipps ändern kann, kann der womöglich auch die Timestamps anpassen... insofern ist ein Screenshot schon eine gültige und sicherere Option

  • Unbekannte User ausgewertet

    Die Lösung hat @ingoh oben doch shcon gepostet: du musst in dne Tabellen emtipp_tipps udn emtipp_bonus-Tipps die Zeilen, wo in der Spalte usr die entsprechnden User-ID steht, löschen (besser vorher ein Backup dar Datenbank machen ;-)). Das geht am besten via phpmyadmin.


    bei mir sind es die USR-IDs 5 udn 11 in der Tabelle emtipp_tipps udn 5,6 udn 11 in emtipp_bonus_tipps

    Zitat von Horst

    Wie habt Ihr denn die ID der User heraus gefunden?

    in meiner User-Tabelle fangen die User-IDs erst mit 12 an (abgesehen von admin mit der ID 1. Im SQL-Dump aus dem Download, mit dem ich die DB angelegt hab, stand beim CREATE-Befehl für emtipp_users bei den Parametern "AUTO_INCREMENT=12"). Zum Prüfen am besten in der Tabelle emtipp_users nach der Spalte id sortieren


    In den Tabellen emtip_tipps und emtipp_bonus_tips habe ich dann nach der Spalte usr sortiert, so konnte ich direkt sehen, welche User-IDs kleiner als 12 sind und diese Zeilen löschen (enweder man klickt sie an oder man nimmt die beiden SQL-Befehel von @ingoh oben. Danach DB-Refresh der Ranglisten aus dem Admin-Menü, und die Namenlosen Biester sind weg.

  • Probleme bei Mobilversion

    ich habe die Weiche in der /index.php deaktiviert - entweder komplett einkommentieren oder die Abfrage

    Code
    1. if ($mobile_browser > 0) {


    auf

    Code
    1. if ($mobile_browser < 0) {

    ändern (die Variable $mobile-browser wird durch die Browser-Abfrage nur größer oder bleibt gleich 0, sie wird nie negativ, also wird die Weiche dann nie aktiv)


    Dazu noch sicherheitshalber in der config-Datei die Variable $CONFIG['PATHM'] = ""; gesetzt (statt vorher ="m/"), falls wie zB in Passwort-vergessen-Datei, ein mobiler Pfad via PATHM ausgegeben wird.


    Und damit niemand einfach so die Mobile Version aufruft via URL mit em2016/m/... habe ich das Verzeichnis m/ gelöscht (ggf. reicht auch umbennen und/oder dem Webserver die Rechte an dem Verzeichnis nehmen).


    Denke, das müsste reichen.

  • Wartungsseite lässt sich ohne Login aktivieren

    guter Hinweis! Hab zwar bei mir eh die komplette Mobile-Versipon deaktiviert, aber kurzer Blick in den Code der /m/index.php und Vergleich mit der normalen /index.php sagt:


    Ersetze

    Code
    1. $RUNTIME = createRuntime();# Wartungsmodus - Status setzenif (isset($_POST['msubmit'])){ $msql = "REPLACE INTO ". $CONFIG['MYSQL']['PREFIX'] ."settings (id,maintenance) VALUES (1,". $_POST['maintenance'] .")"; mysql_query($msql);}


    mit

    hab's aber nicht getestet :-)

  • Speichern von Admin/Konfiguration erzeut immer einen 403

    offenbar ist die SQL-Query schiefgegangen udn gibt ein "false" statt der Ressoruce zurück.


    Du kannst zum Testen ja mal nach der Zeile

    PHP
    1. 3559 $query = mysql_query($sql);


    ein

    PHP
    1. if (!$query) {
    2. die('Invalid query: ' . mysql_error());
    3. }

    einfügen, dann gibt die Webseite dir den MySQL-Fehler aus.



    Oder du checkst erst mal, ob deine Datenbankstruktur identisch ist mit der Datenbankstruktur aus der FINALEN VERSION. Das finale Update ändert nämlich afaik nicht die Datenbankstruktur, falls da vorher etwas fehlte.
    Vgl. dazu den Thread EM Tipp - Fehler beim speichern der Einstellungen

  • Finales Update un Vollversion EM 16

    off topic:
    falls das (u.a.) an mich gemeint war: ich hatte gesucht... aber vielleicht mit den falschen Begriffen. Ich kann deine Reaktion in gewisserweise durchaus auch verstehen, aber Foren sind zur Dokumentation halt etwas suboptimal.
    Hast du einen Link zu einem passenden Thread, wo das mit den Versionsnummer erläutert wird? Auch dass die Update-(Benachrichtigungs-)Funktion nie funktionieren wird, hatte ich wohl verdrängt oder vergessen (ich nutze nur alle 2 Jahre wm- und emtipp). Ich weiß jetzt auch gar nicht, was ich im Profil denn bei der emtipp-Version eintragen soll.


    Aber egal, ich will auch nicht nerven. Das wesentliche hattest du in deiner Antwort ja geschrieben. :-)

  • EM Tipp - Fehler beim speichern der Einstellungen

    stimmt, @Harald, hätte ich noch dazu schreiben sollen... das ggf. fehlende Feld fügt man am einfachsten per phpmyadmin hinzu, entweder über den passenden Button, oder indem man folgenden SQL-Befehl ausführt:



    SQL
    1. ALTER TABLE emtipp_config ADD `owapi` varchar(32) NOT NULL DEFAULT '';

    (Tippfehler vorbehalten ;-) Code sollte man aber idealiter eh immer auch erst mal selber checken, bevor man ihn ausführt)


    Falls ihr ein anderes Präfix für die Tabellen habt als "emtipp_", müsst ihr das natürlich ersetzen.

  • EM Tipp - Fehler beim speichern der Einstellungen

    die Config-Daten werden doch nicht mehr in der config-datei gespeichert, sondern in der Datenbank. Dann müssten die Dateirechte da auch keine Rolle spielen bei dem Problem.


    Ich hatte das Problem auch, nach dem Update auf die FINALE VERSION. Es lag daran, dass mit der FINALEN VERSION im Gegensatz zu der bei mir vorher installierten, in der Tabelle "config" das Feld "owapi" hinzugekommen war.
    (`owapi` varchar(32) NOT NULL DEFAULT '')
    Ich hatte beim Updaten nur die PHP-Dateien der FINALEN VERSION auf den Server geladen, aber die Datenbank nicht neu erstellt (weil ich da bereits schon Userdaten drin hatte)


    Nachdem ich das Feld "owapi" in meiner Datenbank in der Tabelle "config" ergänzt hatte, lief alles sauber durch.

  • Finales Update un Vollversion EM 16

    hmmm... kommt denn dann die Update-Funktion für das Script, die man unter
    index.php?page=admin/admin/updatedata/
    findet, nicht durcheinander?


    Bei mir steht da aktuell:


    <<<<
    EMTIPP Script-Version


    Version auf dem xcript-Server:
    Deine Version: 2.1.001
    >>>>


    das hatte ich bis vorhin, als ich dann hier auf der Seite zufällig was gucken wollte und die neue Finale Version entdeckt habe, so interpretiert, dass es noch kein Update gibt, weil da ja bei "Version auf dem xcript-Server:" nichts steht? Oder funktioniert das eh erst jetzt mit der Finalen Version?

  • Finales Update un Vollversion EM 16

    hm. irgendwie passt das, was als Versionsnummer in der version.php steht, nicht zudem, was ich am 26.4. runtergeladen habe:


    meine ältere, runtergeladene Version vom 26.4.:
    version.php:
    $svnrevision = '$Rev: 001 $';
    $svndate = '$Date: 2016-04-01 22:22:00 +0200 $';
    define('VERSION', "2.1");


    die neuere, heute heruntergeladene Finale Vollversion:
    version.php:
    $svnrevision = '$Rev: 269 $';
    $svndate = '$Date: 2015-12-26 19:48:21 +0200 (So, 17 Jun 2012) $';
    define('VERSION', "1.1.0");


    wie hängen die beiden Versionen denn nun zusammen?