Jump to content
InvisionCommunity.de - Der Deutsche Invision Community Support

kingofcomedy

Mitglied
 View Profile  See their activity

  • Content count

    183

  • Joined

  • Last visited

Posts posted by kingofcomedy

  1. Posted · Edited by kingofcomedy · Report reply

    Hallo,

    ich möchte bei meinem Such-Script in der Anzeige das Suchwort hervorheben, aber so wie es in der Datenbank gefunden wurde, und nicht, wie es gesucht wurde.

    Beispiel:

    In dem DB-Feld steht "Alle meine Entchen."

    Der User sucht nach "Meine".

    Der aktuelle php-Code:

    $xyz = str_replace($suchstring, "<b>$suchstring</b>", $abc);

    str_replace ist case-sensitive, d.h. die Suche des Users bleibt erfolglos. Nutze ich statt str_replace eregi_replace gibt der php-Code mir aber "<b>Meine</b>" aus und nicht "<b>meine</b>".

    Ich hoffe, ich konnte das Problem halbwegs erklären. :)

    Grüsse,

    kingofcomedy

    P.S.: Ein besserer Name für das Thema ist mir leider nicht eingefallen, sorry. :)

  4. Posted · Report reply

    Achtung: Mal eine kleine Warnung zu dem Zusatz Crown System Installation in der Anleitung.

    Mit dieser Modifikation wird ja in den Themen bei dem jeweiligen Mitglied angezeigt, ob er/sie bei einem Spiel Führer in der Highscoreliste ist.

    Jedenfalls ist dieses "Kunstwerk" eine echte Katastrophe und ein Resourcenfresser ohne Ende.

    @Stefan: Hast du deinen "kleinen Fix" auch an den Modder geschickt? :)

  6. Posted · Report reply

    Dazu fliegt auf meiner Festplatte noch ein "AddOn" rum. :)

    Das Query

    $DB->query("SELECT a.title, a.forum_id, a.tid, b.pid, c.read_perms FROM ibf_topics a, ibf_posts b, ibf_forums c WHERE a.tid=b.topic_id AND a.forum_id = c.id AND b.author_id= '".$member['id']."' ORDER BY b.pid DESC LIMIT 1");
    wie folgt abändern 
    $DB->query("SELECT a.title, a.forum_id, a.tid, b.pid, b.post_date, c.read_perms FROM ibf_topics a, ibf_posts b, ibf_forums c WHERE a.tid=b.topic_id AND a.forum_id = c.id AND b.author_id= '".$member['id']."' ORDER BY b.pid DESC LIMIT 1");
    Anschließend folgenden Zeile 
    $info['lastpost'] = "<a href='".$this->base_url."&act=ST&f=".$lastpost['forum_id']."&t=".$lastpost['tid']."&view=findpost&p=".$lastpost['pid']."'>".$lastpost['title']."</a>";
    wie folgt abändern 
    $info['lastpost'] = "<a href='".$this->base_url."&act=ST&f=".$lastpost['forum_id']."&t=".$lastpost['tid']."&view=findpost&p=".$lastpost['pid']."' title='".$ibforums->lang['last_post_date']." ".$std->get_date( $lastpost['post_date'], 'LONG' )."'>".$lastpost['title']."</a>";
    Anschließend noch in der lang_profile.php folgendes hinzufügen 
    'last_post_date' => "Geschrieben am",

    Beim Überfahren des Links im Profil wird jetzt das Datum und die Uhrzeit des letzten Beitrags angezeigt.

    :)

  10. Posted · Report reply

    PS: Die sind gerade fleißig beim Updaten. Auf meinem zweiten MySQL-Server läuft bereits 4.0.16' date=' auf dem ersten noch 4.0.15a.[/quote']

    Hier bei uns läuft auch schon der MySQL-Server mit der Version 4.0.16' date=' und seitdem hatten wir auch keine Probleme mehr gehabt.[/quote']

    Na dann will ich mal hoffen, das die 4.0.16 auch bald meinen Server erreicht, und die Probleme damit behoben sind.

    So, heute nacht hat MySQL 4.0.16 auch meinen ersten DB-Server erreicht. Jetzt heisst es abwarten, wann wieder die ersten Datensätze verschwinden. :lol:

  13. Posted · Report reply

    Es gibt Neuigkeiten, die neueste Alpha hat eine Thread View, die ich ziemlich genial finde :)

    Hab ich heute auch bereits gesehen, und gefällt mir sehr gut. Das IPB 2.0 scheint, so wie es bisher aussieht, einige neue coole Features zu haben.

  15. Posted · Report reply

    Nun denn, ich möchte auch nicht unbedingt jedem empfehlen nach 1und1 zu gehen. Aber die Server sind nicht schlecht, da kann man nix gegen sagen.

    Es gibt einige Internet-Nutzer die nur schlecht über 1&1 reden, aber noch keiner von denen konnte einen für meine Bedürfnisse besseren Provider nennen.

    Und wie AliCremerU333 schon vollkommen richtig geschrieben hat:

    Da muß jeder seine eigene Rechnung aufmachen und herausfinden, welcher Provider für ihn am ehesten geeignet ist.

  18. Posted · Report reply

    Der Fehler tritt aber trotzdem weiterhin gelegentlich auf.

    Bei mir ist er seitdem nicht mehr aufgetreten. Keinerlei Probleme mehr ...

    Kommando zurück. Ich hatte damals unter phpMyAdmin 2.5.3b (oder so ähnlich) folgenden Befehl benutzt, um auf InnoDB umzustellen:

    ALTER TABLE ibf_posts TYPE=InnoDB;

    Dauerte ca. eine halbe Minute und dann kam wie üblich der Text, das der Befehl erfolgreich ausgeführt wurde. Aber wie ich gestern festgestellt habe, war das wohl nicht wirklich der Fall. Hab gestern mal direkt unter Operationen (diesmal phpMyAdmin 2.5.4) den Tabellentyp auf INNO DB umgestellt, und siehe da, diesmal scheint es wirklich geklappt zu haben. Und was sehe ich: Die Tabellengrösse ist von ca. 41 MB auf ca. 71 MB angestiegen. :blink: Da habe ich wieder direkt auf MyISAM umgestellt, da ich ja leider "nur" 100 MB Platz in meiner DB habe.

    P.S.: Noch läuft MySQL 4.0.15a.

  20. Posted · Edited by kingofcomedy · Report reply

    hmm Danke für den Tip Stefan, leider haut es nicht hin.

    Ich hab (fast) schon alles durch. Was ich nicht verstehe ist

       $ScreenWidth =  $ibforums->input['ScreenWidth'];


     $ibforums->input['LOGO']   = gettype($ScreenWidth);



if ($ibforums->input['ScreenWidth'] != 800)

{

$ibforums->input['logo'] = "logoNormal.gif";

}

             else

{

$ibforums->input['logo']  = "logo800.gif";

}

    Vielleicht die 800 mal in einfachen Anführungszeichen? :unsure:

  21. Posted · Report reply

    Da wird wirklich alles bis zum Erbrechen ausgetestet, protokolliert und analysiert, bevor eine Umstellung für die Kunden gefahrlos und für den Hoster bis auf's letzte Detail optimiert stattfinden kann

    *g* - man merkts ...

    Der Fehler tritt so selten auf, das man den wohl selbst bei einem ausgiebigem Test nicht unbedingt entdecken muss. Jede Software hat vermutlich Fehler, die nur in ganz bestimmten Situationen auftreten.

  23. Posted · Report reply

    welcher hoster is bitte wirklich so dämlich' date=' die allerneuste und ungetestete version zu nehmen?[/quote']

    Ich denke nicht, das PureTec eine neue MySQL-Version ungetestet installiert.

    PS: Die sind gerade fleißig beim Updaten. Auf meinem zweiten MySQL-Server läuft bereits 4.0.16' date=' auf dem ersten noch 4.0.15a.[/quote']

    Hier bei uns läuft auch schon der MySQL-Server mit der Version 4.0.16' date=' und seitdem hatten wir auch keine Probleme mehr gehabt.[/quote']

    Na dann will ich mal hoffen, das die 4.0.16 auch bald meinen Server erreicht, und die Probleme damit behoben sind.

  24. Posted · Report reply

    Der zweite Tip für Betroffene ist: Versucht, eure Tabellen auf einen transaktionssicheren Tabellentyp umzustellen, sofern euer Hoster dies in seiner MySQL-Kompilation aufgenommen hat. Es empfiehlt sich hier der Tabellentyp InnoDB.

    Ein kleiner Nachteil soll aber auch nicht unerwähnt bleiben: InnoDB unterstützt keine Volltextindizierung und der Speicherplatzverbrauch ist etwas größer.

    Nach der Konvertierung der Tabellentypen von MyISAM zu InnoDB ist der Bug seither nicht mehr feststellbar gewesen. Probleme aufgrund der Konvertierung sind bei mir nicht aufgetreten.

    Da ich auch zu den "4.0.15a - Geschädigten" gehöre, habe ich vor einiger Zeit einzelne DB-Tabellen bei meinem Forum auf InnoDB umgestellt, da mir das auch vom tollen PureTec-Support empfohlen (hatte dabei Glück den richtigen Supporter erwischt zu haben) wurde. Der Fehler tritt aber trotzdem weiterhin gelegentlich auf.

    Ich hoffe mal, dass das ganze mit 4.0.16 ein Ende hat, aber wer weiss, wann die Version installiert wird. :)

×