Artikel ist im Backend weg - wird aber im Frontend angezeigt

[wosch]

Contenido V 4.6.8.5 - lokale WAMPP-Installation - und ja, auch Bowoser-Cache und con_code sind geleert

Es ist schon seltsam, im Backend _war_ in einer Kategorie ein Startartikel (Artikelliste) und ein Muster-Artikel.
Nun sind beide weg, die Kategorie enthält keine Artikel, das Löschsymbol für die Kategorie wird angezeigt.

Wenn ich dagegen im Frontend auf die Kategorie klicke wird der Startartikel (Artikelliste) aufgerufen und dort kann ich auch auf den Link zum Artikel klicken und aufrufen.

In der mysql-Datenbank ist der Artikel ebenfalls vorhanden, muß ja, sonst würde er im Frontend nicht angezeigt.

Es geht mir nicht um den Artikel, den habe ich schnell wieder angelegt, mir geht es um:

Wie kann das passieren und wie kann man das vermeiden, nicht das sonst eine ganze Reihe Artikel aufeinmal weg sind.

Wenn ich den Artikel neu anlege, was passiert dann mit dem alten in der Datenbank, bläht die sich immer mehr auf (Datenbankgröße?).

[fidelio]

für mich ist das ein sehr (SEHR) grosses problem da ich hunderte artikel habe.

die sind alle im frontend da. im backend werden die kategorien auch angezeigt aber die liste mit den artikeln ist einfach leer.

session beendet, cookies sind gelöscht, verschiedene browser probiert bringt alles nichts...

da kommt das errorlog:
[04-Nov-2006 11:30:33] MySQL error 1054: Unknown column 'b.idtplcfg' in 'on clause'
SELECT
a.preid AS preid,
a.postid AS postid,
a.parentid AS parentid,
c.idcat AS idcat,
c.level AS level,
b.name AS name,
b.public AS public,
b.visible AS online,
d.idtpl AS idtpl
FROM



Upgraden kann/will ich nicht. gibt es eine andere möglichkeit,...?
bin für jede hilfe dankbar...

[HerrB]

Upgraden kann/will ich nicht.

Unabhängig vom Problem... weil?

Auf jeden Fall solltest Du noch kein Update fahren, da es sich vermutlich um ein DB-Problem handelt.

Die Fehlermeldung dürfte sicherlich länger gewesen sein (denn das angegebene SQL-Statement endet vor der "on clause"). Wäre ganz interessant, wie es weitergeht. Dann kann man vielleicht auch nachvollziehen, woher das kommt.

Angegeben wird ja, das b.idtplcfg fehlt. Nun muss man aus dem restlichen SQL-Statement ermitteln, was "b" wäre und dann diese Tabelle überprüfen (die DB zu überprüfen ist an sich schon eine gute Idee...).

Gruß
HerrB

[wosch]

Bei mir gibt es vermutlich eine Erklärung wie das passiert ist.
(HerrB hat mich drauf gebracht mit seiner Bemerkung: "...es sich vermutlich um ein DB-Problem...")

Hier:
http://www.contenido.de/forum/viewtopic.php?p=89659
war meine DB defekt, mit dem Tipp von emergence wurde die DB repariert. Aber wohl doch nicht ohne Verluste wie ich annahm.

Ich habe die 2 Sicherungen (vor dem defekt und direkt nach der Reparatur) zurückgespielt und mir die Inhalte der betreffenden Kategorie/Artikel angesehen.
Vor dem defekt sind die Artikel da, nach der Reparatur fehlen sie.

c'est la vie

Bleibt also nur über:
Wie kriegt man den Artikel wieder ins Backend ohne die DB weiteraufzublähen.
(Und warum sind sie im Frontend sichtbar und im Backend nicht?)

[HerrB]

Weil sie in der con_code zwischengespeichert werden. Die Frage ist aber, ob nach der Reparatur die gleichen Fehlermeldungen im errorlog auftreten.

Wenn ja, fehlen ganze Spalten in der DB. Wenn nein, würde ich die Sicherung vor dem defekt wieder einspielen - aus der con_code oder manuell sind Artikel kaum wiederherstellbar ("kaum" bedeutet "Heidenarbeit" und aufgrund der Verknüpfungen ist die Gefahr, die Strukturen endgültig zu zernageln höher, als die Wahrscheinlichkeit, die Artikel wiederherzustellen).

Gruß
HerrB

[wosch]

Weil sie in der con_code zwischengespeichert werden.

Der Defekt an der Datenbank war am 13.10.
bis heute habe ich con_code zig mal geleert.
Dort kann es nicht zwischengespeichert sein.

Die Frage ist aber, ob nach der Reparatur die gleichen Fehlermeldungen im errorlog auftreten.

Nach der Reparatur waren die Fehlermeldungen weg.
Im Errorlog sind keine Fehlermeldungen, es ist leer.

Wenn ja, fehlen ganze Spalten in der DB. Wenn nein, würde ich die Sicherung vor dem defekt wieder einspielen - aus der con_code oder manuell sind Artikel kaum wiederherstellbar ("kaum" bedeutet "Heidenarbeit" und aufgrund der Verknüpfungen ist die Gefahr, die Strukturen endgültig zu zernageln höher, als die Wahrscheinlichkeit, die Artikel wiederherzustellen).

Den Artikel wiederherstellen lohnt nicht, den habe ich in 10 Minuten neu eingegeben.
Da ich nach dem Defekt jede Menge neue Artikel eingegeben habe möchte ich mir eigentlich das Einspielen der Daten vor dem Defekt ersparen, allerdings, wenn ich bedenke das es doch noch zu weiteren Verlusten von Artikel kommen könnte weil ... (aber was ist weil?)

Ich finde den Artikel in der Datenbank (mit myphpAdmin),
ich habe die Daten mit anderen Artikel verglichen,
es ist nichts auffälliges was ins Auge springt, es sieht alles gleich aus.
Was ich allerdings nicht finde, das liegt aber an mir, ist der Startartikel (News aus dem Beispielmandanten),
auch ein Export als xml bringt mich da nicht weiter.

Übrigens findet auch das Modul inuse_by von Beleuchtfix
http://www.contenido.de/forum/viewtopic.php?t=12169
findet den Startartikel und Artikel und zeigt alles richtig an.

Wenn ich nicht schon soviel Zeit in die Seite reingesteckt hätte,
mein "sportlicher Ergeiz" mich nicht von einem System/Maschine bevormunden zu lassen ist mehr als geweckt,
wenn du noch Infos, Daten, Fakten brauchst - nur zu, wenn ich sie liefern kann gerne.

Gruß
wosch

[HerrB]

Mmmh, das mit der con_code ist ein Argument. Wenn der Artikel dann nicht sichtbar ist, fehlt irgendeine benötigte Referenz (es gab da auch mal ein Lost & Found [Content -> Artikel, links], keine Ahnung, ob das was enthält).

Wenn Du den Artikel noch in der DB findest, musst Du Dich durch den Code buddeln, der zur Artikel-Übersichtsseite führt und da die SQL-Statements analysieren.

Sollte sich alles in dieser Datei oder daraus aufgerufenen Funktionen befinden:
include.con_art_overview.php

Und dann die benötigte, fehlende Referenz ergänzen. Viel Erfolg.

Gruß
HerrB

[wosch]

(es gab da auch mal ein Lost & Found [Content -> Artikel, links], keine Ahnung, ob das was enthält).

Das Lost & Found habe ich auch probiert, gab auch kein Ergebnis.
Ich habe gerstern und heute lange überlegt was ich mache,
ob es nicht besser, sicherer, wäre einen Schnitt zu machen.
Beim Überlegen habe ich alles x-Mal gesichert, gespeichert und mit dem Webspider eine HTML-Kopie aller Seiten erstellt.
Und dann hat mein "Sport-Geist" doch gesiegt, wenn ich schon alles gesichert habe, kannste auch noch mal "Spielen".
Ein "Spiel" war: Kategorie (der verschwundenen Artikel) löschen, beim durchsuchen der Datenbank habe ich dann gesehen das die im Frontend nicht sichtbaren Artikel auch weg waren.
Neue Kategorie (mit gleichem Namen) angelegt, die 2 Artikel mit exakt gleichen Inhalten erstellt, alles zu sehen im Backend und Frontend.
In der Datenbank haben diese Artikel nun eine andere ID.
Ich habe den "Schnitt", eine Neueingabe aller Daten, erstmal verschoben.
Hoffentlich war mein Entschluß richtig.

Das hilft allerdings fidelio nicht bei seinem Problem mit hunderte von Artikel.
Wie er es rekronstruiert bekommt ???

[johannesAT]

kanns sein, dass es an deiner verwendeten mysql-version liegt? wir haben hier das gleiche problem, und ich hab grad von der technik gehört, dass es an der veralteten left join syntax liegen könnte.

wenn du ein zu neues mysql hast, dann kollidiert das miteinander.

[wosch]

kanns sein, dass es an deiner verwendeten mysql-version liegt?

Nein, kann und dürfte nicht sein.
Es war die ureigene Contenido-WAMP mit Contenido 4.6.8.5 - da paßten eigentlich alle Komponenten zusammen.

[johannesAT]

ok, endgültige lösung:

der index-baum muss neu erstellt werden, dazu folgende zeile temporär ändern, und nach erfolgtem neuaufbau, wieder zurückändern:

datei includes/include.con_str_overview.php:

if (!is_string($serializedRootCatItem))

auf

if (true || !is_string($serializedRootCatItem))

[HerrB]

Das müsste sich auch durch Anlegen (aber nicht speichern!) eines neuen Baumes bewerkstelligen lassen.

Gruß
HerrB