Erweiterte Suche: Database error

Ich möchte ja nicht, aber ich muss... Also ein neuer Fehler / Bug in der Suche von vBulletin 5.1.0

Um es zu reproduzieren....

War in der erweiterten Suche und suchte nach "foren upgrade". Rechts hatte ich den Punkt "nur Titel" ausgewählt. Mehr nicht. Dann auf suchen und vBulletin meinte "Error".

Die URL dazu:

https://seo-nw.de/search?searchJSON={%22keywords%22%3A%22foren+upgrade%22%2C%22title_only%22%3A1%2C%22sort%22%3A{%22relevance%22%3A%22desc%22}%2C%22view%22%3A%22%22%2C%22exclude_type%22%3A[%22vBForum_PrivateMessage%22]}&btnSubmit=&humanverify[input]=&humanverify[hash]=&humanverify[input]=&humanverify[hash]=

So, nun müsstes zu noch weitere Mails haben. Hatte das hier gelesen

Zitat

Datenbank Fehler bei bestimmten Suchen ( Reproduzierbar bei anderen Suchen? )

und es einfach mal versucht.... Ehrlich gesagt, ich weiß nun nicht, was ich davon halten soll.... Denk Dir Deinen Teil selber...

Ich habe immer nach fiktiven Begriffen gesucht oder eben nach Befehlen. Ausgehen eigentlich von "vbulletin upgrade", weil es da einen Thread zu geben müsste.

so, das seltsame ist:

vbulletin upgrade -> Fehler
datenbank upgrade -> Fehler
datenabnk insert -> Fehler
datenbank select -> Fehler
scheibenwischer insert -> kein Fehler
database select -> Fehler
database anfeuchten -> kein Fehler
database insert -> Fehler
abcdef insert -> kein Fehler
mysql insert -> Fehler
mysql stoppen -> Fehler
auto stoppen -> Fehler
vbulletin hund -> Fehler
vbulletin hundezwinger -> kein Fehler
auto hund -> Fehler
mofa hund -> kein Fehler
auto blau -> Fehler

Also ich werde daraus nicht schlau.

Das komische ist nur, dass das wohl kein Bug ist. Im vB-Forum gehen die Suchbegriffe und die URL ist 100% identisch mit Deiner:

https://seo-nw.de/search?searchJSON={%22keywords%22%3A%22datenbank+upgrade%22%2C%22title_only%22%3A1%2C%22sort%22%3A{%22relevance%22%3A%22desc%22}%2C%22view%22%3A%22%22%2C%22exclude_type%22%3A[%22vBForum_PrivateMessage%22]}&btnSubmit=&humanverify[input]=&humanverify[hash]=&humanverify[input]=&humanverify[hash]=
ulletin.com/forum/search?searchJSON={%22keywords%22%3A%22datenbank+upgrade%22%2C%22title_only%22%3A1%2C%22sort%22%3A{%22relevance%22%3A%22desc%22}%2C%22view%22%3A%22%22%2C%22exclude_type%22%3A[%22vBForum_PrivateMessage%22]}&btnSubmit=&humanverify[input]=&humanverify[hash]=&humanverify[input]=&humanverify[hash]=

Bekommst Du eine Meldung, was genau falsch ist? Also die Query etwa? Ich tendiere da ja schon fast in den Bereich Suchindex.

Also erst mal gute Nacht.

Aber zu der Query kann ich Dir sagen, dass die schlicht falsch ist.

Die Tabelle heißt doch eigentlich searchtowords_u, eben die Tabelle für die Begriffe mit u. In der Query steht ja auch searchtowords_u.is_title, als Tabelle wird aber forum_searchtowords_u angebeben. Also entweder heißen die ganzen searchtowords_... bei Dir so, dann ist das forum_ falsch oder die beginnen alle mit forum_, dann ist die Spaltenangabe im AND falsch.

SELECT nodeid FROM forum_searchtowords_u WHERE wordid = 11169 AND searchtowords_u.is_title = 1

Die DB wird aber doch damit erzeugt, oder?

CREATE TABLE IF NOT EXISTS `searchtowords_u` (
  `wordid` int(11) NOT NULL,
  `nodeid` int(11) NOT NULL,
  `is_title` tinyint(1) NOT NULL DEFAULT '0',
  `score` int(11) NOT NULL DEFAULT '0',
  `position` int(11) NOT NULL DEFAULT '0',
  UNIQUE KEY `wordid` (`wordid`,`nodeid`),
  UNIQUE KEY `nodeid` (`nodeid`,`wordid`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Wobei ich nun darauf hin tendiere, dass das Forum eine falsche Query zusammenbaut, denn

vbulletin upgrade -> Fehler
upgrade vbulletin -> geht

Wobei es die forum_searchtowords_u aber eigentlich geben müsste, sonst wäre der MySQL-Fehler ja, dass die Tabelle nicht existiert.

Ist sogar hier bei mir reproduzierbar. Deine Tabelle heißt forum_searchtowords_u und das Forum versucht auf searchtowords_u zuzugreigen. In Where-Bereich löst das aber keinen Fehler ala "Tabelle nicht gefunden" aus, sondern einfach ein "Unknown column".

Möglich auch, dass da einfach ein "AS searchtowords_u" nach dem "FROM forum_searchtowords_u" fehlt.

Wie dem auch sei, das Präfix "forum_" hast Du wohl irgendwo vergeben und genau damit hat das System irgendwo ein Problem. Kann gut sein, dass des Support-Forum ohne Präfix arbeitet und es daher funktioniert.

Deren Liste wird aber auch immer länger... Habe mir mal die Bugfixes der 5.1 angesehen... Tztztz, was da alles an Fixes drinnen ist. Da hätte die 5.0.5 auch nie auf den Markt kommen dürfen.

Na wie ich das gemacht habe? Ich sage das mal so ein etwa, denn da ist auch ein Script von mir beteiligt und das behalte ich für mich

Man nehme die alten URLs und die neuen URLs
Baue bei den alten URLs erst mal die Forennamen mit in die URL, damit die in etwa gleich sind wie die neuen URLs, zumindest vom Anfang her. (je genauer, desto besser)

Dann geht man her und dupliziert die alten Links. In der Kopie lässt man alle IDs (von den Posts bzw. Threads) entfernen - da die nicht mit den neuen IDs übereinstimmen
Nun werden die ID-losen URLs in einer Tabelle denen mit ID gegenübergestellt. Sortiert wir die Spalte mit den ID-losen. Dadurch sortiert sich auch die eigentliche Liste mit.

Das mit dem Duplizieren, IDs entfernen und gegenüberstellen macht man auch mit den neuen Links. Ebenfalls sortiert.

So hat man also vier Listen, die alle nach dem Alphabet sortiert sind und nicht mehr wild durcheinander wegen den falschen IDs.

Dann geht man her und nimmt aus den beiden Gegenüberstellungen jeweils die Liste mit den IDs, denn das sind die Originalurls, die ohne ID waren nur für die Sortierung. Nun kann man her gehen und die per Hand alle vergleichen. Ich für meinen Fall habe da eine Art "winmerge", das Input "links" und "rechts" vergleicht, nicht nur String für String, sondern auch per Ähnlichkeit. Und hier kommt dann aber die bestmögliche Übereinstimmung vom Anfang zum Tragen. Je näher die URLs von links und rechts zusammen stehen, desto wahrscheinlicher ist die Übereinstimmung.

Letztendlich war es dann aber dennoch etwas Handarbeit (mehr als gedacht), da manche URLs eben sehr verfälscht wurden. Gerade im Bereich SEO und Off-Topic. Bei SEO wegen dem SEO und PR und insbesondere im Off-Topic, da da viele Titel waren, die ein Was, wer wie, wo drinnen hatten, das alte Forum die aber nicht in die URL aufnahm. Folge war dann, dass eine URL, die eigentlich nach hinten in den Bereich "w" gehört plötzlich ganz vorne stand, da das erste Wort fehlte. Und da die Liste Off-Topic extrem lang ist kommt der Abstand von links und rechts hier extrem zum Tragen.

Im Grund hatte ich das Script damals mal entworfen um zwei verschiedene Exports von Backlinkcheckern zu vergleichen, welche Links gleich sind, welche ähnlich etc.

Ansonsten, ein anderer Ansatz, den ich gestern ja versuchte, daher auch der DB-Error. Man kann alle alten URLs abfangen, diese an ein PHP-Script schicken und dort den Titel auslesen. Diesen Titel fragt man im neuen Forum per Suche ab (direkte Query). Wenn es da mehrere Treffer geben sollte, kann man das auch lösen.

Oder, man biegt die vbSEO URLs dynamisch wieder um auf das original vb4 und schickt die Anfrage dann direkt an das Forum. vb5 setzt das dann selbst um.

Nee, sowas behalte ich immer für mich. Habe durchaus ein paar Spielsachen, die ich nie weitergeben werde oder fremdnutze. Hier und da mal, ok, aber nicht offiziell. Zudem wird das nicht lange eine Marktlücke sein, denn technisch ist es kein Problem. Wenn man das alte Forum noch hat, dann ist das sogar fast schon ein Kinderspiel. Ein Script erstellt, das die Umsetzung macht und die URLs dann direkt aus dem alten Forum ziehen. In dem Script muss nur hinterlegt werden, wie das neue Forum die URLs will oder selbst aufbereitet. Dann kann man die auch so ausgeben lassen. Klar, die gehen dann im alten Forum nicht, aber das müssen sie auch nicht, soll ja nur eine Liste sein. Für das neue Forum bräuchte man dann ein zweites Script, das die URLs anhand des Strings abfragt und nicht nach der ID, die ID aber in den String hinzufügt, denn das ist dann ja die neue. Möglicherweise könnte man da sogar noch einen Timestamp mit in die URL packen, um die Treffergenauigkeit zu erhöhen. Den kann man später ja entfernen lassen.

Für jemanden der in Sachen vB-Programmierung fit ist, sollte das kein Problem sein.

Gedanken habe ich da viele. Noch einfacher wäre es, wenn das neue Forum einfach die alten IDs auch mit ablegt. Dann könnte man alle alten Zugriffe direkt erfassen, anhand der hinterlegten ID erkennen und weiterleiten.

alles mit .html erkenne -> id aus alter URL erfassen -> im neuen Forum abfragen -> neue URL bilden -> weiterleiten.

So was ähnliches habe ich für WP und die Permalinks damals gemacht, damit das neue WP auch die Links der alten Installation kennt und entsprechend beachtet, ebenso für das uralte phpld. Hab sogar eine Migration von phpld auf WP, aber nie genutzt, nur getestet und dann doch von WP Abstand genommen

Und gibt es schon eine Meldung, wann vBulletin 5.1.1 kommen wird? Im Support-Forum steht ja an einigen Stellen, dass der Bug und der Bug und der Bug auch in der vBulletin Version 5.1.1 behoben ist. Und wann kommt die? Gibt es so was wie eine vBulletin Roadmap? Das sind so Dinge, wegen denen ich mich angemeldet hatte, um zu sehen, ob es das gibt.

So, und wie es scheint haben wir den Fehler hier auch:
/core/includes/functions_search.php

$add_where = $is_title_only ? " AND searchtowords_$word[suffix].is_title = 1" : "";
            // limit the current matches to the list of existing matches (skip this if it is the first iteration)
            if (!$first_run AND $word['joiner'] != 'OR' AND $word['joiner'] != 'NOT' AND is_numeric($wordid))
            {
                $this->db->query_write($query = "
                    DELETE FROM " . TABLE_PREFIX . "temp_search
                    WHERE nodeid NOT IN (
                        SELECT nodeid
                        FROM " . TABLE_PREFIX . "searchtowords_$word[suffix]
                        WHERE wordid = $wordid $add_where
                    )");


                if (!empty($config['Misc']['debug_sql']) OR self::DEBUG)
                {
                    echo "$query;\n";
                }
            }

In Zeile 9 ist noch allen in Ordnung, da ist der TABLE_PREFIX vorhanden.
Kommt aber eine Sache dazu, nämlich das "in Titel suchen", dann kommt Zeile 1 zum Tragen. Und genau dort fehlt das TABLE_PREFIX. $add_where wird dann am Ende der Query angehängt und schon haben wir den Fehler.

Also muss das so sein

$add_where = $is_title_only ? " AND " . TABLE_PREFIX . "searchtowords_$word[suffix].is_title = 1" : "";

vBulletin 5.1.1 RC1 : Fehler besteht weiterhin

Zitat

There has been a database error, and the current page cannot be displayed. Site staff have been notified.