Inhalte (Einfache Seite) können nicht mehr bearbeitet oder gelöscht werden
am 15.10.2015 - 03:18 Uhr in
Hallo,
ich habe nun schon viel geschaut, und ähnliche Probleme gefunden, leider noch keine Lösung für unser Problem.
Wir haben das Problem das verschiedene Inhalte die als "Einfache Seite" erstellt wurden plötzlich nicht mehr gelöscht , bzw. bearbeitet werden können.
Klickt man also auf "Bearbeiten" oder "Löschen" unter Inhalte bei einem solchen Eintrag (übrigens ebenfalls über den Bearbeiten Tab des Frontends), erhält man eine Nachricht:
Seite wurde nicht gefunden
Die angeforderte Seite „/content/%C3%BCber-uns/edit“ wurde nicht gefunden.
oder :
Seite wurde nicht gefunden
Die angeforderte Seite „/content/impressum/edit“ wurde nicht gefunden.
Es scheint keine sichtbare Logik dafür zu geben, es wurden bereits mehrfach alle caches geleert und wir sind als Admin eingeloggt mit vollen Rechten.
Zuerst habe ich auf ein URL Umlautproblem getippt, ich habe zum Test einfach einen Inhalt (Einfache Seite) "Über uns" nochmal neu erstellt und dann funktionierte es plötzlich und der Inhalt konnte bearbeitet werden, und danach auch wieder gelöscht werden.
Das klappt anscheinend aber nur wenn ich selbst den Inhalt hier erstelle, bearbeitet mein Kunde den Inhalt haben wir danach anscheinend dieses Problem. Wo soll nun der Unterschied liegen? Wir arbeiten beide mit Firefox.
Das dumme ist dass wir die Inhalte nicht löschen können... (ich dann auch nicht mehr).
---
Falls es keine Lösung gibt, oder nichts bekannt ist, wie kann man einen Inhalt manuell über die Datenbank löschen?
Ich finde den Inhalt immer noch sauber in der Tabelle "node" stehen, und dachte ich könnte dort ggf. den DS einfach löschen, oder kann das Probleme geben?
Das Drupal ist fast frisch installiert. Version 7.39
Habt vielen Dank für jegliche Hilfe!
- Anmelden oder Registrieren um Kommentare zu schreiben
Hört sich für mich nach einem Berechtigungsproblem an
am 15.10.2015 - 06:59 Uhr
Hallo,
bist Du Admin der Seite? Dann schau mal die Berechtigungen durch. Es gibt ja auch Berechtigungen, dass man Inhalte die man nicht selbst erstellt hat löschen darf. Evtl. sind die bei Dir als Administrator nicht richtig gesetzt. Oder hat jemand anders die Seite erstellt?
Viele Grüße
Marita Betz
Das hört sich ja wirklich
am 15.10.2015 - 07:00 Uhr
Das hört sich ja wirklich schräg an.
"Ich finde den Inhalt immer noch sauber in der Tabelle "node" stehen, und dachte ich könnte dort ggf. den DS einfach löschen, oder kann das Probleme geben?"
Naja, Du müßtest alle Tabellen finden, in denen für diesen Node Daten hinterlegt wurden. Also auch in der Node-Revision-Tabelle und in den fields-Tabellen, bzw. evt.Taxonomie-Referenzen ect.
Und es wäre nur eine Symtom-Bekämpfung. Die Ursachen bestünden weiterhin.
"bearbeitet mein Kunde den Inhalt haben wir danach anscheinend dieses Problem"
Hört sich nach einem Berechtigungs-Problem an. Welche Module hast Du installiert, die die Berechtigungen beeinflussen?
Kommt irgendwo der Hinweis, daß die Berechtigungen neu aufgebaut werden müssen?
Steht was in den Fehlerlogs? Drupal bzw. Webserver?
Achtung!
am 15.10.2015 - 07:20 Uhr
wenn der User ein erweitertes Textformat genutzt hat, und du dieses Textformat nicht nutzen kannst, kannst du den Text nicht mehr verändern.
Dies kann nur jemand, der das gleiche Textformat nutzen kann oder darf.
Könntest du mit einem eingeschränkten Textfilter einen Text mit erweitertem, oder ohne Filter ändern, gingen die erweiterten Attribute wieder verloren, weil beim Speichern selbstverständlich dein Filter auf den ganzen Text angewendet würde.
Was ist das bitte für eine
am 15.10.2015 - 08:02 Uhr
Was ist das bitte für eine vergurkte Installation?
In der "Edit"-URL haben URL-Aliase - ob nun mit oder ohne Umlaut - rein gar nichts verloren! Eventuell hat da jemand (oder ein Modul) im Template Mist gebaut bei den Pfaden.
Die beinhalten immer nur die Node-ID, z.B. http://www.example.tld/node/5/edit oder http://www.example.tld/node/5/delete
Über http://www.example.tld/admin/content müsstest Du - falls Du entsprechende Berechtigungen hast - aber alle Inhalte mit den korrekten URLs zum Bearbeiten oder Löschen aufrufen können.
Falls nicht, kannst Du Dir behelfen, indem Du den den Quelltext der Beitragsseite aufrufst. Dort sollte im Body-Element eine Style-Klasse wie "page-node-5" mit der Node-ID drinstehen. Damit konstruierst Du dann mal die Links wie oben angegeben und rufst diese auf.
Hallo,ja sind wir, wir
am 15.10.2015 - 23:32 Uhr
Hallo,
vielen Dank erstmal für die schnellen Reaktionen!
1A
ja sind wir, wir loggen uns beide über den Admin Account ein.
Ich bin mir auch fast sicher dass es das nicht sein kann, denn dann wäre die Fehlermeldung sicher eine andere und wir hätten das Problem an mehr Stellen. Ich hatte auch schon irgendwo anders von einem fast ähnlichen Problem gelesen, da waren es ebenfalls nicht die Rechte.
Dennoch danke für den Tip!
2A
Ja mit den DS wäre klar, ich komme aus dem XT Bereich, ich wüsste nun schon wo ich welche DS ich in welchen Tabellen zu löschen hätte (es wäre zwar etwas unschön -performancetechnisch aber wohl kein Thema- hätte ja sein können dass das System schon beim fehlen des DS in der Node table diesen nicht mehr einliest), aber letztlich die Aussage
"Und es wäre nur eine Symptom-Bekämpfung. Die Ursachen bestünden weiterhin" ist absolut richtig. War zuerst auch eher als Notfallprogramm gedacht ;-)
Welche Module hast Du installiert, die die Berechtigungen beeinflussen? -> Bewusst keine. Ich glaube auch nicht an ein Berechtigungsproblem, an den Rechten waren wir auch überhaupt nicht dran.
Kommt irgendwo der Hinweis, daß die Berechtigungen neu aufgebaut werden müssen? -> Nein.
Steht was in den Fehlerlogs? Drupal bzw. Webserver? -> Es handelt sich nicht um einen Serverfehler etc. ist auch recht sicher denke ich. Das mod error log ist derzeit auch deaktiviert. Auf dem Server laufen x andere Accounts ebenfalls ohne Probleme. Dennoch behalte ich es im Auge, danke!
3A
Ich glaube hier wird die Sache schon wärmer. Erweitertes Textformat, hast Du da eine Idee , meinst Du Kopien aus Word heraus etc.? Sowas erlebt man ja auch gelegentlich....
Aber dann müsste ich doch zumindest bearbeiten können, es wird aber angezeigt dass die Seite nicht gefunden werden kann...mmmh . Ich muss nochmal schauen, wenn ich nicht täusche betrifft das momentan nur "Einfache Seiten", keine "Artikel". Ich müsste ggf. in die Datenbank schauen in welcher Art der Text abgelegt wurde, ob Steuerzeichen etc. vorhanden sind.
Wir haben übrigens den CKEditor installiert.
4A
Ich habe eigentlich schon hunderte Websysteme aufgesetzt (ist ja mein Job). Ich konnte während der Install nicht das kleinste Problem feststellen, geschweige denn wurde etwas gemeldet etc. Ok, bei Drupal bin ich neu, aber wie gesagt, es lief und läuft sonst alles prima..Von einer vergurkten Install würde ich daher nicht sprechen.
In der "Edit"-URL haben URL-Aliase - ob nun mit oder ohne Umlaut - rein gar nichts verloren! -> Das ist eine interessante Aussage, denn genau das wunderte mich auch. Im Prinzip hätte ich da fast die Standard URLs gelassen, dennoch (da es auch ein Freund von mir ist, wollte ich mir Mühe geben und das ganze etwas SEO freundlicher gestalten). Allerdings hatte ich da irgendwie keinen Einfluss drauf, es wurde dafür : Pathauto und Token – automatische URL-Aliase verwendet. http://www.softwareentwicklung-berlin.de/blog/drupal-7-must-have-module
Das könnte ebenfalls gut sein.
Den Gedanken den URL manuell zu manipulieren hatte ich auch schon. http://www.example.tld/node/13/delete?destination=admin/content#overlay-...
ist der URL der zum löschen aufgerufen werden soll. Die Seite liegt unter: http://www.example.tld/content/%C3%BCber-uns , also http://www.example.tld/content/über-uns . Da machte mich die Umlautübersetzung auch gleich stutzig. Klickt man dann drauf, steht ja : Seite wurde nicht gefunden
Die angeforderte Seite „/content/%C3%BCber-uns/delete?destination=%23overlay%3Dadmin%2Fcontent“ wurde nicht gefunden.
Genau aus diesem Grund hatte ich ja eine neue Seite "Über uns" angelegt. Mit dieser konnte ich dann aber sauber handeln.. alles funktionierte..
Ich habe das eben nochmal gemacht, also nochmal "Über uns" neu angelegt, mit gleichen Inhalten. Nun wird es interessant:
Eigentlich sollten sich die Inhalte ja nicht stören aber das scheint doch so .
------------- So war es vorher
Das ist der URL wenn ich löschen möchte des alten "Über uns" Eintrages, der nicht löschbar war/ist:
http://www.example.tld/node/13/delete?destination=admin/content#overlay-...
------------- So ist es jetzt:
Das ist der URL wenn ich löschen möchte des neuen "Über uns" Eintrages (der auch funktionieren würde):
http://www.example.tld/node/31/delete?destination=admin/content#overlay-...
Jetzt ist aber plötzlich aus dem alten URL zum löschen
http://www.example.tld/node/13/delete?destination=admin/content#overlay-...
Dieser geworden (für den alten Inhalt, es scheint es kommt sich da doch ins Gehege, denn da ist node 13 (die weg soll) und übergibt Node 31 (die neue)...)
http://www.example.tld/node/13/delete?destination=admin/content#overlay-...
Eigentlich müsste dann ja einer der modifizierten URLs :
http://www.example.tld/node/13/delete?destination=%23overlay%3Dadmin%2Fc...
http://www.example.tld/node/13/delete?destination=admin/content#overlay-...
http://www.example.tld/node/13/delete?destination=admin/content#overlay-context=content/über-uns
funktionieren, aber tut es nicht, ständig gleiche Meldung.
Teste ich:
http://www.example.tld/node/13/delete
lande ich auf:
http://www.example.tld/content/%C3%BCber-uns/delete
Und meldet:
Seite wurde nicht gefunden
Die angeforderte Seite „/content/%C3%BCber-uns/delete“ wurde nicht gefunden.
Boa...grausam sowas, dennoch vielen Dank für Deine Hilfe.
Weiß jemand zufällig wie ich die SF-URLs für den Admin deaktivieren kann?
Vielen Dank nochmal!
welcherTextfilter ist für den Admin eingestellt?
am 15.10.2015 - 18:24 Uhr
Wer ist der User mit der ID#1?
Das wäre wohl der Admin, also
am 15.10.2015 - 18:48 Uhr
Das wäre wohl der Admin, also ich und derzeit auch der Kunde selbst mit vollen Rechten.
Wir haben nur diesen einen user in Nutzung.
ok - klingt nach einem Datenbankfehler
am 15.10.2015 - 19:19 Uhr
Hast du irgendselche Manipulationen in der Datenbank vorgenommen?
Hast du eine Datensicherung der Datenbank?
Welche Textfilter sind aktiv?
Wurde etwas an den Textfiltern verändert?
Uid 1 ist Uid 1
am 15.10.2015 - 20:03 Uhr
Wenn der Kunde auch die gleichen Rechte wie der Admin bekommt, ist er trotzdem nicht User 1. Das bekommt nur der erstinstallierende Admin..
Mein Tipp wäre, Pathauto und urlalias zu deinstallieren und die Nodes mit Nid ansprechen zu lassen, Cron ausführen, Caches leeren, Tabellen in db evtl. manuell löschen.
Dann mal schauen und evtl. wieder pathauto und urlalias installieren. Ist ja schon schön, bis auf die Umlaute, aber solche Adressen lassen sich ja auch manuell vergeben.
Nein, keine Manipulationen
am 15.10.2015 - 22:15 Uhr
Nein, keine Manipulationen bisher.
Datenbank backup läuft automatisch, dummerweise aber nicht den Stand vor den URL Anpassungsmodulen gesichert. Ich wollte es noch machen, irgendwie verplant... schade hast Recht.
Ich wollte auch duplice Content vermeiden , Google war schon fleißig am einlesen und Kunde fleißig am hochladen .
Momentan ist leider alles etwas enger, und ich habe das Projekt für ein sehr geringes Geld ausgeführt. Und da ich mich gerade in Drupal einarbeiten wollte waren trotzdem 1,5 Wochen durch... als selbstständiger nicht so einfach.
Ok Textfilter ist jetzt auch Neuland, ich hatte lediglich die "img" Tag Erweiterung in den Filtered HTML Einstellungen zu den erlaubten Tags gesetzt.
Trotzdem nicht User1? Ok
am 15.10.2015 - 23:29 Uhr
Trotzdem nicht User1? Ok intreressante Info. Frage mich allerdings wie das System das erkennen will. Oder ist das nur der Stand bis zum ersten leeren aller Caches?
Tja Pathauto und urlalias waren ja dafür gedacht dass der Kunde eben solche Anpassungen nicht selbst vornehmen braucht. Er war schon Stunden nur mit den Inhalten beschäftigt... Das es auch manuell geht hatte ich schon gelesen...Hätte ich vielleicht aber doch machen sollen... Ich mag kein eModule die unzuverlässig sind.. naja man soll ja nicht meckern, war schließlch auch kostenlos. Ja vielleicht müssen wir uns tatsächlich daran machen, oder ich suche den Fehler selbst (kommt vielleicht auf das gleiche raus, denn bei Google muss dann auch neu indiziert werden), dann lerne ich gleich mal ein wenig mehr über Drupal. Ich wollte ja dass er die wichtigen Seiten (denn das unvollständige Impressum betrifft das ja auch, habe keine Lust auf Abmahnungen) Ich hatte ja gehofft es gäbe evtl. schonmal jemanden mit diesem Problem. Jetzt muss ich allerdings erstmal meine Steuern auf die Reihe kriegen, immer diese Zeitprobleme... :-)
-->
Was mir aber auffällt und mich stutzig macht ist die Eingabe beim edit URL.
Gebe ich ein:
http://www.example.tld/node/31/edit kann ich die neue "Über uns" Seite bearbeiten
Gebe ich ein:
http://www.example.tld/node/13/edit kann ich die alte "Über uns" Seite nicht bearbeiten (obwohl in der Datenbank die Parameter alle gleich sind - bzw. alle wohl nicht, aber ich bin am suchen)
Es wird dann nach:
http://www.example.tld/content/%C3%BCber-uns/edit weitergeleitet und der Fehler angezeigt... also scheint für die alte Node irgendwo doch eine Umleitung "fest" zu sitzen...
Vielen Dank aber!!!
kommt vor
am 16.10.2015 - 00:15 Uhr
dass ein Modul mal verkehrt operiert. Neuinstallation mit Bereinigen hilft meist.
Geht der Kunde mit den gleichen Zugangsdaten auf die Seite wie Du, also wirklich als admin mit uid1? Ich kenne den Kunden ja nicht, aber ich halte das für riskant. Ein eigener Account mit den benötigten Rechten tut es doch, er soll doch nichts installieren, oder? Und mit 2 mal uid1 gleichzeitig zugreifen, geht nie gut.
Hinweis
am 16.10.2015 - 07:32 Uhr
Nur der User, egal wie er heißt, mit der ID#1 hat volles Administrationsrecht.
Bei einem Kunden, der nicht die komplette Installationsverantwortung übernehmen will oder kann, sollte der User mit der ID#1 nicht bekannt gegeben werden.
Man kann Rechte nur einschränken, wenn man einen User mit einer anderen Rolle anlegt.
Auch ein User mit der Rolle Administrator ist eingeschränkt, wenn er nicht die ID#1 hat.
klar kann mal was falsch
am 16.10.2015 - 08:01 Uhr
klar kann mal was falsch laufen, kenne das nur zu gut... habe ja auch schon einige eigene Module programmiert.
Ja natürlich würde es ein eigener Acc. auch tun, kann ich ja nochmal einrichten.
Aber warum soll er sich nicht als Admin (wenn auch nur übergangsweise) einloggen, ihm ist bewußt dort nichts was er nicht weiß oder kennt zu verändern. Es wäre nur dann riskant (ausser bei Passwortklau etc.. aber das ist ja recht selten, ist kein FTP über Filezilla etc.) , oder wenn beide gleichzeitig Inhalte ändern, würde mich aber wundern (eigentlich wird sowas ja unabhängig von der Session entwickelt).
Sehe da jetzt aber überhaupt keinen Zusammenhang mit unserem Problem. Als er die Texte änderte war ich ja auch nicht eingeloggt (allerdings wäre es auch das erste mal dass ich von Problemen höre bei gleichzeitigem Admin Login höre, nun gut Drupal kenne ich nicht..) . Weißt Du zufällig warum es nie gut geht, wäre in dem Fall ja schonmal interessant (ich denke das hast Du dann sicher schonmal erlebt)... ok werde dann bei Zeit zur Sicherheit mal eigenen Acc. für ihn einrichten.
Neuinstall mit bereinigen hilft recht sicher, ist ja schließlich neu :-) Aber genau sowas nervt mich enorm. Kann doch nicht bei einem Problemchen davonlaufen und alles neu installieren (klar wenn es nicht anders geht der letzte Ausweg). Aber was wäre Drupal denn für ein System wenn man sowas nicht lösen könnte.. Denn dann wäre es für mich ggf nicht das richtige System, sowas bezeichne ich als unstabil. Es ist doch total unlogisch mit dem richtigen URL einmal löschen zu können und einmal nicht.. da packt mich jetzt eher der Ehrgeiz das Thema zu lösen...
Gestern Abend bin ich leider nicht weitergekommen, allerdings habe ich bereits die Text Inhalte in der Datenbank der beiden Über uns Seiten gefunden und den der ID13 mit dem der ID31 überschrieben (also Steuerzeichen im Content etc.. ausgeschlossen) , aber daran lag es dann auch nicht... Allerdings er hatte die Texte tatsächlich mit Wordpad bearbeitet, kopiert und eingefügt. Aber im Background schreibt der CKEditor eh nur HTML/CSS, der Rest wird wohl entfernt. Obwohl ich habe das auch mal beim FCKEditor in XT erlebt bei einem Kunden der mit Word arbeitete, der hat da MS eigene XML Tags eingeschleust die die Seite zerhauen haben.
Dennoch lieben Dank für Deinen Tip!
"Sehe da jetzt aber überhaupt
am 16.10.2015 - 09:16 Uhr
"Sehe da jetzt aber überhaupt keinen Zusammenhang mit unserem Problem."
Da sehe ich auch keinen Zusammenhang.
Das kommt bei unseren eigenen Projekten auch vor, daß mein Mann und ich gleichzeitig per Admin zugreifen.
Falls es einen Inhalts-Konflikt gibt, wird das vermeldet, aber Probleme wie die beschriebenen gab es damit noch nie.
" Allerdings er hatte die Texte tatsächlich mit Wordpad bearbeitet, kopiert und eingefügt"
Finde ich auch relativ normal. Auch wenn es natürlich nicht wünschenswert ist, wegen unerwünschter Formatierungen.
Aber es ghört zu den Dingen die gemacht werden und die nicht zu so einem Verhalten führen dürfen.
Ich glaube nicht wirklich dran, daß es mit dem Wysiwyg zu tun hat.
"da packt mich jetzt eher der Ehrgeiz das Thema zu lösen..."
Ginge mir genauso.
Ich würde vermutlich als nächstes ein Modul nach dem anderen deaktivieren, um das Problem einschränken zu können.
Das ist zwar mühsam, aber evt. der einzige Weg.
Leider fällt mir sonst auch nichts hilfreiches ein.
Ach noch was zu Deiner Antwort auf mein erstes Post: Ich dachte nicht, daß es ein Server-Error ist, aber in den Logs des Webservers werden manchmal mehr (PHP-)Fehler angezeigt, als im Watchdog.
da kommt mir gerade etwas
am 16.10.2015 - 10:16 Uhr
kann es sein, dass du einen Filter hattest, den du umbenannt, oder gar gelöscht hast?
Deaktiviere mal pathauto, leere alle caches, und aktiviere es später wieder.
Ein und denselbsn Pfad sollte es nur einmal geben können.
Konflikte
am 16.10.2015 - 11:29 Uhr
entstehen, wenn zufällig beide Zeit in die gleiche Node investieren, und bei einem war es dann umsonst. Einen Zusammenhang mit eurem Problem vermute ich hier auch nicht.
Und wenn Du dann mal hilfreiche Meldungen hast, Admin hat dieses und jenes aufgerufen, tja, wer war es dann und erinnert sich? Ein zweiter Account mit Adminrechten ist ja fix gemacht. Aber wenn ihr damit klar kommt, soll es gut sein.
Mit Neuinstallation meinte ich eigentlich nur die betreffenden Module und Tabellen. Aber wenn das Projekt so frisch ist, wäre die Komplettinstallation natürlich eine Gelegenheit, gründlich aufzuräumen.
Edit: Kopieren aus Wordpad etc. halte ich auch für harmlos und gewollt. CKEdit macht das rund, nach meiner bisherigen Erfahrung.
Module sind zum Teil unbezahlte Eigenentwicklungen und gerade am Anfang nicht immer astrein. Da kann Drupal als CMS Framework nichts für, das gehört zum Konzept der modularen Möglichkeiten. Pathauto als langjährig und häufig eingesetztes Modul gehört aber nicht dazu und sollte sauber funktionieren. Evtl. beißt es sich mit etwas anderem, neuerem? Nur so eine Vermutung.
Viel Glück!
Danke nochmal! Alles
am 18.11.2015 - 01:58 Uhr
Danke nochmal!
Alles getestet, nichts hat funktioniert. Auch das Token Modul etc.. Da die neuen Tokens der URL auch gespeichert werden vermute ich ein anderes Problem..
Jetzt habe ich eben quick n dirty den DS aus der node Table entfernt, das funktioniert erstmal ...
Sub-pathauto?
am 18.11.2015 - 10:23 Uhr
Moin.
Kann es sein, dass Du [do:subpathauto Sub pathauto] installiert hast? Das schreibt nämlich die edit-Links so um, dass der Alias dafür verwendet wird (und nicht mehr node/[nid]/edit) ...
Danke, nein. Das Modul heißt
am 18.11.2015 - 12:16 Uhr
Danke, nein. Das Modul heißt Pathauto .