im Homepageprogramm Magnolia finde ich eine Option „Seite exportieren“. Das habe ich mal mit einer Homepageseite gemacht und erhalte eine XML Datei recht großen Umfangs (ca. 9MB), bei der beim Öffnen lediglich der editierbare Code angezeigt wird, z.B. mit Firefox ebenso, wie mit Notepad++.
Als Info finde ich im Netz nur, daß es sich bei der XML-Datei um eine modernere Form einer HTML Datei handelt, oder habe ich das falsch verstanden? Was ich aber nicht hinbekomme, ist die Anzeige dieser Datei so, wie ich die Homepageseite am Bildschirm sehe. Frage ist also, wie ich die Datei selbst oder eine Veränderung im Dateiscript als Ergebnis sichtbar machen kann.
XML ist ein generisches, erweiterbares Format, das praktisch alles enthalten kann.
Mit dem Umbenennen wirst du daher höchstwahrscheinlich nichts erreichen.
mal davon ausgehend, dass @Christa mit ihrer Mutmaßung Recht hat, und es sich beim „Homepagebaukasten Magnolia“ um das CMS Magnolia handelt, dann ist der Export in eine CMS-Datei völlig normal.
Wenn Du den Inhalt darstellen willst, brauchst Du wieder eine Magnolia-Installation und musst die Daten dort importieren,
Warum ist das so? Das schöne an einem CMS ist die strickte Trennung von Inhalt und Design. Und wenn Du etwas sichern möchtest, reicht es, nur den Inhalt zu sichern und die Information, welcher Inhalt wo gespeichert wird. Dadurch bleibt der Inhalt weiter dynamisch. Wenn man das als HTML speichern würde, ginge die Dynamik verloren und es gäbe keine Trennung von Inhalt und Design mehr.
ja, es ist das CMS Magnolia. Ich pflege die Homepage unserer hiesigen Kirche, wo Magnolia als CMS durch das kirchliche Medienzentrum vorgegeben ist.
Mich interessiert, ob beim Exportieren der Startseite (hier heißt das Template „Homepage“, ist sicherlich eine index.html oder index.php) der ganze Klüngel unter dieser Seite auch exportiert wird oder nur die Seite alleine. Da die Startseite nur 1x existieren darf, kann ich sie nicht duplizieren. Dieses würde ich aber gern machen, damit, falls ich mal bei Änderungen richtigen Mist baue, eine Rettungskopie habe.
Nein. Es gibt ein Magnolia-System (ein PHP-Programm), das unter Benutzung von einem ganzen Haufen Style-Sheets und einem noch größeren Haufen von Bildern (in einer Datenbank) aus der XML-Datei die Seiten aufbaut.
Bei mir (auch Kirchenhomepage) hat die XML-Datei der Startseite eine Größe von 3,6MB. Und sie enthält die Beschreibung und die Texte aller Unterseiten.
Sprich doch mal mit dem Admin, der das Magnolia-System gestaltet hat. Sicher gibt es automatische Backups im Hintergrund, von denen das System ggf. wieder retauriert werden kann. Ob es mit einem Import der XML-datei auch funktioniert kann nur er dir sagen.
Aber vermutlich machst du dir viel zuviele Sorgen.
Ich habe mal versucht, mich ein ganz klein wenig in die Arbeit mit Magnolia einzulesen. Puh… Das ist ein paar Hausnummern komplizierter als mein geliebtes Wordpress. Ich finde genau zwei Arten von Texten:
hochtrabendes Marketingsprech, das ich nur zu 10% verstehe
technische Anleitungen in sehr kurz gefasstem, sehr grundlagenbezogenem Englisch
Ich muss leider zugeben, dass mir das erste völlig fremd ist (ich bin Techniker und brauche klare Ansagen) und das zweite zu hoch. Was ich aber deutlich verstehe: der Einstieg in Magnolia scheint deutlich herausfordernder als bei Wordpress.
Damit ich nicht schuld an Fehlern bin, die Du aus Vertrauen zu meinen Aussagen heraus begehst, will ich lieber gar keine Hilfe liefern.
Bis auf vielleicht eines: in den Magnolia-Docs wird ein Backup-Module besprochen. Vielleicht hilft das ja irgendwie… Link
danke ork für diese Info. Ich befürchtete schon, daß alle Unterseiten an dem Export dran hängen.
Das mit dem Support (das ist der Admin) ist eine gute Idee, wenngleich von dort Fragen von mir recht schnippisch beantwortet werden. Liegt aber an den Personen, nicht am System. Die mögen es nicht, wenn jemand tiefer ins System kriecht, als vorgesehen.
ich verwende Magnolia nur mit den Optionen, die durch das kirchliche Medienzentrum vorgegeben sind. Die haben also einen Baukasten zusammengestellt, der nur bedient wird, natürlich alles auf deutsch. Damit gibt es viele Grenzen, auch in der Gestaltung, die nicht beeinflußt werden können, jedenfalls nicht durch mich. Somit ist die Pflege der Homepage bzw. der Umgang mit dem CMS nicht besonders schwierig.
Das ist Sinn und Zweck eines CMS. Da unterscheiden sich „mein“ Wordpress und Magnolia nicht voneinander. Der Unterschied liegt wohl darin, dass „alte“ CMS wie Wordpress linear arbeiten. (Ich erstelle das Design der Seite, Du schreibst den Inhalt auf einem Backend, der in die Datenbank wandert und das Fronend berechnet daraus eine Seite und zwar nur die Internetseite.) Bei „neuen“ CMS wie Magnolia ist die Internetseite nur eine Anwendung. Du schreibst weiterhin den Inhalt, der in die Datenbank wandert. Aber ich designe ein Frontend fürs Internet, eine App für iOS, eine App für Android, eine API für smarte Fernseher usw., die alle auf die gleiche Datenbank zugreifen, aber die Daten völlig unterschiedlich verarbeiten.
Wenn ich mir das richtig zusammenreime (siehe meine Einschränkung oben), kannst Du nur „Deine“ Informationen aus der Datenbank sichern, das Design der Seite ist Dir als Redakteur gar nicht zugänglich.
XML ist für den Export eine gute Idee. Hier kann man speichersparend den Text und seine Bedeutung abspeichern (Überschrift, Footer, Menü…) sowie den Speicherort von Bildern, Videos und anderen Medien ablegen. Wenn Du also den Inhalt als XML sichern kannst, sollte sich daraus, so meine Vermutung, die Datenbank auch wieder herstellen lassen.
Einiges kann man durchaus ändern. Aber den Baukasten verlassen ist nahezu unmöglich.
Nein.
Es gibt eine Benutzeroberfläche für das Verwalten der Seite (also die indirekte Bearbeitung der XML-Datei). Und eine zweite für die Verwaltung der Medien (die sich in einer Datenbank befinden). Die Verbindung besteht aus Links, die man wegen der kryptischen Darstellung (endlose Buchstabenkombination) in der XML-Datei nicht interpretieren kann. Es ist unmöglich, aus dem Link auch nur erkennen, auf was er eigentlich zeigt. Und erst recht kann man sich daraus die Datenbank nicht restaurieren, wenn sie kaputt sein sollte.
Das gute daran: man kann die Struktur der Datenbank auch nicht versehentlich kaputtmachen. Man hat ja nur Zugriff auf die einzelnen Inhalte. Die kann man löschen, aber das war’s auch schon. Und versehentlich geht das eigentlich auch nicht, weil das ein zweistufiger Prozess ist und zusätzlich auf Verwendung der Dateien hingewiesen wird.
Was man kaputtmachen könnte wäre vielleicht die Struktur der Seiten - aber ich habe noch nichts gefunden, was das auslösen könnte.
