WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: VSG on January 12, 2019, 03:42:22 PM
-
Hallo zusammen,
und nachträglich ein gutes neues Jahr allen.
Ich habe noch im Dezember das Update auf WB 2.12.1 durchgeführt, nachdem meine üblichen Test keine Auffälligkeiten gezeigt haben.
Diesen Test habe ich aber nicht gemacht und wurde daher heute wirklich kalt erwischt …
Folgende Situation:
Meine Webseite ist in Untersektionen gegliedert, wobei normal als Bezeichnung das "pages"-Verzeichnis als Parent verwendet wird.
Eine Seite auf oberster Ebene heißt "Film- & TV-Kritiken", was als PHP-Datei in "film--tv-kritiken.php" angelegt wurde. Darunter befinden sich zwei weitere Unterebenen, deren Seiten auf dem Server im Ordner "film--tv-kritiken" liegen. Es ist mir seit Update auf 2.12.1 nicht mehr möglich, unter "Film- & TV-Kritiken" Unterseiten zu erstellen oder bestehende dorthin zu verschieben.
Das Problem daran ist, dass von WB nicht der bestehende Ordner "film--tv-kritiken" verwendet, sondern ein neuer Ordner "film-tv-kritiken" angelegt wird, der dann jedoch nicht über die erforderlichen Rechte verfügt, PHP-Dateien darin zu erstellen.
Meine Frage ist nun: Weshalb um alles in der Welt übernimmt das System nicht die bestehende Struktur, sondern fängt eine neue an? An den Seiten selbst wurde nichts verändert, bestehende Links funktionieren tadellos. Es lassen sich auch die Unterseiten unter "film--tv-kritiken" bearbeiten, nur keine neuen erstellen.
Der Fehler kommt ebenfalls, wenn ich versuche, eine Seite ohne übergeordnete Seite zu erstellen und dann darunter zu 'verschieben'.
Hat jemand eine Idee?
Denn so bedeutet es einen riesigen Aufwand, händisch die Eintragungen in der Datenbank zu verändern, damit die Links neuer Seiten am Ende funktionieren.
Besten Dank!
VSG
-
Was passiert nach Eingabe von
domain.tld/framework/helpers/rebuildAccessFiles.php
?
Man muß als admin angemeldet sein.
MfG. Evaki
-
Danke für die schnelle Antwort!
Darf ich nur kurz vorher fragen, was das macht? Nicht, dass es mir komplett die Datenbank zerschießt. :-o
Verändert es bspw. die Page-IDs oder sonstige IDs bspw. der News-Einträge?
-
Es schreibt die in der DB vorhandenen Datei-Einträge als Files(Namen) auffe Platte.
Die DB selbst bleibt davon unberührt.
Sollten also beim Upgrade Strukturänderungen vorgenommen worden sein, das vermutest Du ja, so würden, wenn das zuträfe, die Dateinamen etc neu geschrieben werden, entsprechend der DB-Einträge.
Käme mir aber sehr schräg vor, wenn wirklich Strukturänderungen vorlägen.
Ich hoffe, daß Du vor dem "damaligen" Upgrade ein DB-Backup angefertigt hast.
MfG. Evaki
p.s. Hatte mal nen ähnlichen Fall... Dat sacht abba nix.
Sehe gerade, daß die WB-Truppe "Helferkolonne" schon unterwegs ist :-D
-
Ok, Danke.
Das lief zwar durch, hat aber an der Struktur nichts verändert.
{"message":"Rebuild 1873 pages access files
\nRebuild 1308 news access files
\n
\n","success":true}
Aber behebt das Problem nicht, wenn ich eine neue Datei erstellen wollte:
"Methode createPath::invalid structure - missing file: film-tv-kritiken/test.php", da ein neuer Ordner angelegt wird ("film-tv-kritiken"), der dann nicht über die Schreibrechte verfügt.
Aber wieso wird neu angelegt, statt "film--tv-kritiken" weiterverwendet? :|
-
Es handelt sich hier um ein Feature.
Doppelte Bindestriche in Dateinamen ergeben keinen Sinn und sind für Google sogar kontraproduktiv.
Du wirst keine neue Seite mit mehreren aufeinanderfolgende n Bindestrichen anlegen können.
Die Lösung für dich müsste so aussehen.
Seite Film- & TV-Kritiken einmal abspeichern ohne was zu ändern. Das Accessfile ändert sich dadurch und weitere Unterseiten sollten möglich sein.
Eine 301 Umleitung in der .htaccess von film--tv-kritiken zu film-tv-kritiken (gilt dann auch für alle Unterseiten) kriegen wir sicher gemeinsam hin.
-
die angesprochene Funktion RebuildAccessFiles(), die du übrigens auch im InfoFenster (I-Button im Backend) erreichen kannst, liest die Datenbanktabelle pages und erstellt an Hand dieser Daten die AccessFiles im Ordner /pages neu
Wenn also etwas verändert wird, dann der inhalt dieser Dateien im /pages-Ordner
Ich glaube allerdings nicht, das dies dein Problem löst, zumindest nicht langfristig. Den Namen einer Datei oder eines Ordner bestimmt die Funktion page_filename(). Diese sorgt dafür, das z.b. keine Leerzeichen im Ordnernamen sind - ist eines angegeben, wie in deinem Beispiel, wird es mit einem Bindestrich ersetzt. Ergebnis war dein Beispiel Ordner "film--tv-kritiken"
Ich wüßte nicht, das dieses System, das es so schon ewig gibt, verändert wurde.
Welche PHP-Version hast du denn da im Einsatz? Ist es die Möglich, in der Datenbanktabelle /pages die Einträge in der Spalte "links" zu kontrollieren?
Alles weitere müßte man testen
-
Es handelt sich hier um ein Feature.
für mich eher ein Grund, nicht upzudaten :evil:
-
für mich eher ein Grund, nicht upzudaten
Nach meinem Verständnis wäre es eine Katastrophe, ob nun Struktur bzw. S.Engines betreffend.
Je länger die angelegte Struktur (als feststehendes Element) besteht, desto schlimmer die Nebenwirkungen.
Eine Bevormundung wär's außerdem. (Die KI im Editor nervt schon genug)
Sinnvoll wäre 'eine Abfrage einzubauen. Aber da sind die Dev's gefragt.
MfG. Evaki
-
Keine Bevormundung, eine Hilfe es richtig zu machen.
Ähnlich wie dort auch Umlaute umgewandelt werden.
-
Keine Bevormundung, eine Hilfe es richtig zu machen.
Ähnlich wie dort auch Umlaute umgewandelt werden.
Mit der Hilfe stimme ich unumwunden zu, doch gibt es halt auch die andere Seite, wenn's eben keine Neuinstallationen sind, sondern Übernahmen.
Bei den Umlauten kann man, wenns z.B. die Dateinamen betrifft, schon länger auf die "alten Regeln" verzichten, wenn auch nicht auf jedem Host, htaccess sollte schon zugänglich sein. Da dürfen Dateinamen auch in chinesisch geschrieben werden. (Habe ich im Dezember bei 'nem Anwender fleißig mit spielen dürfen :-) ) Das ist gerade bei -ich sag mal- MuliKulti.Websites eine enorme Hilfe für Anwender und Internetausdrucker.
MfG. Evaki
-
Eine "Hilfe" kann ich annehmen oder eben nicht - hier bleibt mir die Wahl zwischen WB und einen Fork :-o
das wäre jetzt auch meine Empfehlung an User VGS. Er hat sich zumindest gemeldet. Wie viele andere standen vor dem gleichen Problem und sind nun weg?
Wie oben angeführt und mittlerweile gestrichen, bin ich davon ausgegangen, das diese Funktion "wie früher" funktioniert und man nicht die Installationen der User zerschießt, die haben jetzt nämlich keine Wahl mehr - zu mal solch Änderung dann auch noch top secret zu sein scheint
P.S.: ist meine Meinung, aber dafür wurde ich ja auch gefeuert.
-
P.S.: ist meine Meinung, aber dafür wurde ich ja auch gefeuert.
Du bist gegangen ... und niemand wollte dich aufhalten. An einigen Postings kann man gut erkennen warum.
Wenn ein Bindestrich der Grund ist zu einem codetechnisch veralteten Fork zu gehen, dann kann man nichts machen. Empfehlen würde ich das nicht.
Probleme sind zum Lösen da, einen Weg hatte ich gezeigt. Das ist kein großes Problem.
-
Normalerweise Ein Sache von Sekunden
ich zitiere
Eine Seite auf oberster Ebene heißt "Film- & TV-Kritiken", was als PHP-Datei in "film--tv-kritiken.php" angelegt wurde. Darunter befinden sich zwei weitere Unterebenen, deren Seiten auf dem Server im Ordner "film--tv-kritiken" liegen. Es ist mir seit Update auf 2.12.1 nicht mehr möglich, unter "Film- & TV-Kritiken" Unterseiten zu erstellen oder bestehende dorthin zu verschieben.
Vor dem Problem stand ich einmal. Du musst nur hingehen in Seitenoptionen den Eintrag im Feld Zugriffs Datei auf "film-tv-kritiken.php" zu ändern oder leere das Feld, dann erstellt WebsditeBaker die Zugriffs Datei neu. Durch Speichern werden automatisch alle Link Eintrage in der Table pages korrigiert und die entsprechenden Ordner und die zugehörigen Zugriffsdateien im pages Verzeichnis. Geht Sekunden schnell.
Es wird dabei kein Eintrag in pages zerschossen sondern nur angepasst, sodaß alles wiede rnormal läuft.
Auf diese Art und Weise bekommt auch den Rebuild Accessfile wieder lauffähig, wenn der mal rumzickt, dass der Create Path nicht funktioniert, weil der macht den rebuiuld aus den Einträgen in der pages. Ist nämlich ein Zeicheen dafür das ein link Eintrag verkehrt ist.
Tut mir leid dass dies beim Upgrade nicht berücksichtigt werden kann. Ich arbeite aber an einem Wartungstool, was diese Aufgabe übernehmen soll. Mag sein, dass die Ein oder Andere Kritik berechtigt ist. Denke aber das eine Diskussion darüber nicht nötig ist.
Dietmar
-
Es handelt sich hier um ein Feature.
Ich will nicht undankbar erscheinen und ich weiß auch zu schätzen, wie viel Zeit Ihr in das Projekt steckt, aber es war ein Feature, das mich heute Stunden an Zeit gekostet hat – und das für eine gut besuchte Webseite, die ich auch nur als Hobby (also Freizeitspaß) betreibe. :oops:
Doppelte Bindestriche in Dateinamen ergeben keinen Sinn und sind für Google sogar kontraproduktiv.
Von meiner Seite sind knapp 1500 Unterseiten von Google tadellos erfasst worden und dort sogar mit Struktur abgebildet. Ich will nicht wissen, was der Suchalgorithmus damit anstellt, wenn ich die in Zukunft (Redirect hin oder her) alle umziehe, will ich mir nicht vorstellen. Auch nicht, wo die im Google-Ranking dann landen.
Auch sind die Seiten so in allen möglichen Datenbanken (u.a. Wikipedia) eingetragen … ohne Redirect wäre das also wirklich eine Katastrophe.
Du wirst keine neue Seite mit mehreren aufeinanderfolgende n Bindestrichen anlegen können.
Das wollte ich in dem Fall auch gar nicht. Aber dass das System nicht in der Lage ist, in eine bestehende Struktur neue Seiten einzufügen, ist in meinen Augen ein Bug und kein Feature. Zumal Ottonormalwender sich gar nicht erklären können, warum nicht. Die machen alles wie gehabt und urplötzlich klappt was nicht mehr.
Seite Film- & TV-Kritiken einmal abspeichern ohne was zu ändern. Das Accessfile ändert sich dadurch und weitere Unterseiten sollten möglich sein.
Die Seite wurde von mir heute geändert und neu abgespeichert, aber das Accessfile ändert sich dadurch nicht – und auch der dazugehörende Unterordner nicht. Würde sich das überhaupt auf alle Eintragungen der alten Struktur in der Datenbank auswirken? Bei jeder Unterseite ist in wb_pages ja der Pfad zur jeweiligen Accessdatei gespeichert. Das sind bei mir mehr als 1500. Oder sollte damit schlicht eine zusätzliche neue Ordnerstruktur angelegt werden? Das fände ich nicht wirklich günstig.
Eine 301 Umleitung in der .htaccess von film--tv-kritiken zu film-tv-kritiken (gilt dann auch für alle Unterseiten) kriegen wir sicher gemeinsam hin.
Da wäre ich sehr dankbar drum.
Meine Vorgehensweise sähe sonst jetzt so aus: Änderung sämtlicher Eintragungen der Datenbank (den Befehl für phpmyadmin müsste ich mir erst raussuchen) von "film--tv-kritiken" zu "film-tv-kritiken". Dann manuelle Umbenennung des Accessfile-Dateinamens "film--tv-kritiken" zu "film-tv-kritiken.php" sowie des Ordners im pages-Verzeichnis ("film--tv-kritiken" zu "film-tv-kritiken") und anschließend Einrichtung der Umleitung in .htaccess.
Hab ich was vergessen oder gibt es eine einfachere/bessere Lösung?
Danke auch für die anderen Ideen und Lösungsvorschläge. Zum Thema Fork werde ich mich ein andermal äußern, dafür reicht heut die Zeit leider nicht.
Besten Dank und viele Grüße,
VSG
PS: Nach Dietmars Antwort dann folgende Vorgehensweise – Änderung des Dateinamens von "film--tv-kritiken" zu "film-tv-kritiken" in den Einstellungen der Seite und anschließend Einrichtung der Umleitung in .htaccess.
Richtig, oder hab ich was vergessen?
-
Ich hatte mich da wohl geirrt, ja Dietmar schrieb was zu tun ist.
Den redirect such ich dir raus.
-
Du bist gegangen ... und niemand wollte dich aufhalten. An einigen Postings kann man gut erkennen warum.
Jau, deine Meinung und meine haben nicht mehr zusammen gepasst. Für mich stand WB immer an erster Stelle, für dich die Lösung deiner Probleme um WB. Dafür hast du eine Menge Leute eingespannt, mich inklusive. Sicher liegt es auch in der Verantwortung jedes Einzelnen, wie weit er da mit macht oder nicht.
Am Ende sind wir alle glücklich mit der aktuellen Situation, du hast deine Ruhe, ich hab meine - ein Zusammenkommen wird es nie mehr geben - alles gut....
Ich will nicht wissen, was der Suchalgorithmus damit anstellt, wenn ich die in Zukunft (Redirect hin oder her) alle umziehe, will ich mir nicht vorstellen. Auch nicht, wo die im Google-Ranking dann landen.
ich verwende meine Seitenstruktur seit 1996, egal, ob da ein statisches HTML hinter stand, Joomla, Wordpress oder auch WB. Sicherlich keine 1500 Seiten am Stück, aber ein paar hundert schon. Ich lege wohl nicht viel Wert aufs Google-Ranking, das wird eh nur mit finanzieller unterstützung interessant, hätte aber dennoch einen Batzen Arbeit, um solch Änderung nun abzufangen.
Mag sein, dass die Ein oder Andere Kritik berechtigt ist
Wer nix macht, macht nix verkehrt. Mich stört eher, das es nicht public gemacht wurde. zufälligerweise habe ich bei einer meiner Schauspielerinnen exakt die gleiche Ordnerstruktur wie VGS sie benutzt, das aber seit Anbeginn durch Short_Url angepasst
-
@VSG
Wenn du eine .htaccess im WB Root liegen hast und die beginnt mit RewriteEngine on
dann brauchst du das nicht nochmal eintragen. Wichtig ist dann nur die zweite Zeile.
Hast du keine .htaccess dann erstelle diese leere Datei (mit Punkt vorn).
Inhalt:
RewriteEngine on
RedirectMatch 301 /pages/film--tv-kritiken(.*) /pages/film-tv-kritiken$1
Ich habe das getestet und es funktionierte. Trotzdem sollte es ausgiebig getestet werden.
Verbesserungsvorsch läge sind gern gesehen.
Theoretisch und praktisch verlierst du kein Ranking.
-
Sicher hätte die Änderung in der Changelog oder wo auch immer erwähnt werden sollen.
Es wurde schlicht vergessen, weil viele kleine Änderungen überall gemacht wurden. Seht es uns nach.
Wenn man drüber reden kann statt gleich loszupoltern und alles in Frage zu stellen, kann man auch erklären und Lösungen finden. Oder sogar Dinge rückgängig machen.
Der Entwickler gelobt Besserung was Dokumentation betrifft.
-
"gepoltert" wurde erst nach und wegen deiner Erklärung - aber nun genug der Worte
-
@VSG
Wenn du eine .htaccess im WB Root liegen hast und die beginnt mit RewriteEngine on
dann brauchst du das nicht nochmal eintragen. Wichtig ist dann nur die zweite Zeile.
Hast du keine .htaccess dann erstelle diese leere Datei (mit Punkt vorn).
Inhalt:
RewriteEngine on
RedirectMatch 301 /pages/film--tv-kritiken(.*) /pages/film-tv-kritiken$1
Ich habe das getestet und es funktionierte. Trotzdem sollte es ausgiebig getestet werden.
Verbesserungsvorsch läge sind gern gesehen.
Herzlichen Dank, ich versuch es morgen und geb dann Rückmeldung! (Y)
-
Inhalt:
RewriteEngine on
RedirectMatch 301 /pages/film--tv-kritiken(.*) /pages/film-tv-kritiken$1
Ich habe das getestet und es funktionierte. Trotzdem sollte es ausgiebig getestet werden.
Erster Test heute hat funktioniert – nochmal Dankeschön!
Ausgiebig testen kann ich erst in den kommenden Wochen, werde aber dann nochmal Bescheid geben.
Du musst nur hingehen in Seitenoptionen den Eintrag im Feld Zugriffs Datei auf "film-tv-kritiken.php" zu ändern oder leere das Feld, dann erstellt WebsditeBaker die Zugriffs Datei neu. Durch Speichern werden automatisch alle Link Eintrage in der Table pages korrigiert und die entsprechenden Ordner und die zugehörigen Zugriffsdateien im pages Verzeichnis. Geht Sekunden schnell.
Es wird dabei kein Eintrag in pages zerschossen sondern nur angepasst, sodaß alles wiede rnormal läuft.
Danke, werde ich dann in Kürze auch testen und Bescheid geben. Wie gesagt, ich hoffe, dass das auch mit so vielen Unterseiten klappt. Es handelt sich hier wie gesagt um 1.500+.
Tut mir leid dass dies beim Upgrade nicht berücksichtigt werden kann. Ich arbeite aber an einem Wartungstool, was diese Aufgabe übernehmen soll.
Soll das dann auch für alle bestehenden Seiten gelten, so dass hier auch doppelte Bindestriche automatisch entfernt werden? Da bitte ich dann aber um einen grooooßßßßen Hinweis im Changelog, denn das betrifft dann ja auch so etwas wie News-Einträge & Co. Selbst wenn die Suchmaschinen irgendwann die neuen Links übernehmen, meine Sitemap wäre damit hinfällig.
Abgesehen davon, dass bestehende einzelne Seiten mit doppelten Bindestrichen ebenfalls in Wikis, Datenbanken und dergleichen eingetragen sind. Wenn WB das bei einem Update einfach alles "vereinfacht" und überschreibt, zerschießt das alle möglichen Verweise – und das lässt sich auch mit einem automatischen Redirect nicht einfach beheben.
Mein Vorschlag wäre (ob sich das umsetzen lässt, kann ich aber nicht sagen, ich bin kein Entwickler):
Eine solch grundlegende Änderung im Verhalten von WB sollte sich nur für neu angelegte Seiten auswirken. Bestehende Strukturen und Seiten sollten durch ein bloßes Abspeichern nicht geändert werden, um einen bereits existierenden (und ggf. außerhalb bekannt gemachten) Aufbau nicht zu zerstören.
Ich kann mir denken, dass das aus Entwicklersicht nicht schön ist, aber nach mehr als 10 Jahren mit dem System haben sich bei größeren und alteingesessenen Seiten einfach Sachen gebildet, die jetzt zu ändern einfach ein zu großes Unterfangen ist.
Beste Grüße,
VSG
-
Nochmal zur Klarstellung, bestehende Strukturen sollen nicht durch ein Upgrade verändert werden. Das will niemand.
Deine Seite wurde nicht umbenannt durch das Upgrade, wie du feststellen konntest, andere Seiten dann auch nicht.
Die Bindestrich-Regel sollte nur neue Seiten betreffen. Durch dich wissen wir jetzt, dass es da ein Problem mit neuen Unterseiten solcher alten Seiten gibt.
Durch die Umleitung in der .htaccess brauchst du dir um Links in z.B. Wikipedia keine Gedanken machen, denn die werden alle und immer umgeleitet.
Google nimmt im Falle dieser einen Seite und seiner Unterseiten zur Kenntnis, dass dein Ranking für -- nun für - gilt. Genau dafür steht die Zahl 301.
Das Umbenennen in den Seiteneinstellungen wirkt sich für alle Unterseiten aus, egal wie viele und egal wie oft noch weiter verschachtelt.
Das Wartungstool ist im Moment nur eine Idee und dann für Leute, die etwas ändern wollen und macht nichts ohne Auftrag.
Ich hoffe der erste Satz beruhigt etwas.
-
Ich denke ich habe eine schnelle vorläufige Lösung, um Abwärtskompatibel zu bleiben. Das Fix Paket werde ich morgen posten, weil ich erst nochmal was testen möchte.
Vorläufige Vorausetzung ist das Einfügen einer Konstanten Definition in der config.php. Wird später als Experten Modus in Seitenoptionen einzustellen sein.
define('PAGE_NEWSTYLE', 0);Lässt das alte Sanitize Verfahren zu,
keine Kosntantendefinitio n oder
define('PAGE_NEWSTYLE', 1);nimmt das neue Sanitize Verfahren
Dietmar
-
Ich denke ich habe eine schnelle vorläufige Lösung, um Abwärtskompatibel zu bleiben. Das Fix Paket werde ich morgen posten, weil ich erst nochmal was testen möchte.
Hallo Dietmar,
ich wollte fragen, ob das Paket schon verfügbar ist? Ich hab es nicht gefunden… :?
Viele Grüße,
VSG
-
Bin noch dran, Momentane Lösung sieht so aus, das der jeweilige bestehende parent Knoten nicht verändert werden soll, aber alle neu angelegten Seiten werden nach dem neuen Verfahren umgesetzt. Lass mir noch ein paar Tage. Ich möchte einfach nur sicher gehen.
Frage. hast du denn die Möglichkeit das erstmal in einem Backup zu testen, oder musst du das auf dem Live System machen.
Melde mich sofort bei dir,. wenn ich was fertig habe. Ich erstelle dann eine PagesFix.zip, die alle nötigen Dateien inkl. Ordnerstruktur enthält.
Dietmar
-
Hi und sorry für die späte Antwort!
Ja, ich habe hier ein Backup, allerdings lokal in einer XAMPP-Installation. Reicht das?
Danke im Voraus für die Mühe, ich werd es mir so bald ich dann kann anschauen.
VG,
VSG
-
Kleiner Bug, den ich gerade noch gefunden habe:
Wenn im Seitentitel Umlaute sind, werden die nicht konvertiert bei mir (also ä zu ae), sondern als HTML-Kürzel dargestellt. Das hat meines Wissens in der Vorversion von WB noch geklappt.
VG,
VSG
-
sondern als HTML-Kürzel dargestellt.
WO?
für's Backend kann ich das nicht bestätigen. Die Namensgebung funktioniert - Aus Seite "Dänemark" wird Datei daenemark.php
Ich schätze aber, du meinst nach Einspielen des Backups in die Datenbank. Wenn ja: zwei Möglichkeiten
1. Fehler beim Import (falsche Collation gewählt)
2. Datenbank wurde noch nicht konvertiert und zeigt noch Relikte älterer latin-Formate
-
sondern als HTML-Kürzel dargestellt.
WO?
für's Backend kann ich das nicht bestätigen. Die Namensgebung funktioniert - Aus Seite "Dänemark" wird Datei daenemark.php
Doch, genau da. Mag aber ein Fehler des PageCloners sein – da hatte ich die Umlaute als neuen Seitennamen eingegeben.
Und ja, ich weiß, PageCloner ist nicht das Gelbe vom Ei.
1. Fehler beim Import (falsche Collation gewählt)
2. Datenbank wurde noch nicht konvertiert und zeigt noch Relikte älterer latin-Formate
Hatte ich damals mit Deiner Hilfe gemacht, das sollte passen… :wink:
-
sondern als HTML-Kürzel dargestellt.
WO?
für's Backend kann ich das nicht bestätigen. Die Namensgebung funktioniert - Aus Seite "Dänemark" wird Datei daenemark.php
Doch, genau da. Mag aber ein Fehler des PageCloners sein – da hatte ich die Umlaute als neuen Seitennamen eingegeben.
Und ja, ich weiß, PageCloner ist nicht das Gelbe vom Ei.
1. Fehler beim Import (falsche Collation gewählt)
2. Datenbank wurde noch nicht konvertiert und zeigt noch Relikte älterer latin-Formate
Hatte ich damals mit Deiner Hilfe gemacht, das sollte passen… :wink:
Das war dieses ~50 Mb- Backup, nicht war?
Ja, das müßte dann passen, sofern die verwendete Datenbank dies auch unterstützt und mit der richtigen Collation angelegt wurde (utf8_general_ci bzw utf8mb4_general_ci)
Beim PageCloner muß man aufpassen, es ist eine sehr komplexe Geschichte, Seiten zu klonen und wenn dann noch Unterseiten verschiedenster Module hinzu kommen, wird's ganz kompliziert. Jedes zu klonende Modul muß im PageCloner auch mit entsprechendem Code angegeben werden. In den Versionen, die ich noch kenne, standen aber auch nur 6 oder 7 Module drin, die Großen halt. Es gibt wohl eine Version beim Fork, die ein paar Module mehr unterstützt, aber ob die noch kompatibel ist, weiß ich nicht.
Probiere erst einmal das Anlegen einer WB-Seite mit den üblichen Werkzeugen und Umlauten drin (Seitenübersicht, ganz unten). Wenn das nicht recht funktioniert, kann man über einen Bug diskutieren. Ansonsten bleibt das Problem auf den PageCloner beschränkt und man müßte sich die Speicher-Routinen anschauen.
-
Das war dieses ~50 Mb- Backup, nicht war?
Jaja … :roll:
Nochmals: Danke!
Beim PageCloner muß man aufpassen, es ist eine sehr komplexe Geschichte, Seiten zu klonen und wenn dann noch Unterseiten verschiedenster Module hinzu kommen, wird's ganz kompliziert.
Der PageCloner ist für mich an sich nur eine schnelle Möglichkeit, Unterseiten anzulegen. Das über die Haupt-Seiten-Ansicht zu machen, ist mir zu mühsam; auf Grund der vielen Unterseiten braucht die Seite lange zum Aufbau. Wenn man dann mehrere neue Unterseiten anlegen will, wird das eine echte Geduldsprobe. Zumal es schon immer ewig dauert, ehe WB den Seitenbaum aufgebaut hat, wenn man einstellt, welcher Unterseite die neue Seite angehören soll. Außerdem kopiert der PageCloner auch in der aktuellen Fassung zumindest die Seiten-Eigenschaft (ob sichtbar, versteckt etc.). Das hilft mir schon mal.
Ich weiß, dass WB an sich nicht für so viele Unterseiten ausgelegt war. Aber wenn es mal so viele sind, wird es umso schwerer, sich davon zu lösen und auf was ganz anderes aufzusetzen. Zumal ich nicht mal wüsste, was da besser geeignet ist.
-
Alternativ zu pagecloner gäbe es noch Multiplepage. Bestimmt im Forum zu finden.
-
Hallo Dietmar,
ich wollte fragen, ob es schon Neues zu dem Fix gibt, was das beschriebene Problem betrifft.
Viele Grüße,
VSG
-
Hallo, du hast die 2.12.2 ?
Gehe zu WB Optionen > Erweiterte Optionen > Servereinstellungen > Zugriffs Datei Einstellung
Aktiviere es und geh zu deiner Seite in die Einstellungen.
Du siehst jetzt unterhalb von Zugriffs Datei eine Checkbox und ein "?" für weitere Hilfe.
Das sollte dein Problem lösen.
-
Gehe zu WB Optionen > Erweiterte Optionen > Servereinstellungen > Zugriffs Datei Einstellung
Aktiviere es und geh zu deiner Seite in die Einstellungen.
Du siehst jetzt unterhalb von Zugriffs Datei eine Checkbox und ein "?" für weitere Hilfe.
Das sollte dein Problem lösen.
Guten Morgen!
Irgendwie ist deine Antwort seinerzeit vollständig untergegangen bei mir, sorry!
Dankeschön für den Tipp, den ich nach Update auf 2.13.2 auch wieder in Anspruch nehmen musste, nachdem eine neue Seite sich zwar zuerst erstellen ließ und auch keine Fehlermeldung kam, beim Ändern der Seiteneigenschaften dann jedoch ein Zugriffsproblem erschien, da WB die Zugriffsdatei (und den Ordner ohne - -) nicht erstellen konnte.
So klappt aber alles und danke für die Flexibilität von WB!
Beste Grüße
VSG