• In der Ansicht sind die Webseiten teilweise um das dreifache schneller geworden. Nun haben wir auch die Bearbeitungsseite optimiert. Die Inhalte Abschnitte / Sections, Registerkarten / Tabs und Akkordeons werden nun erst nach Klick geladen. Wenn also […]
  • Liebe Webseiten-Redakteure, nach Ende der dritten und letzten Test- und Fixphase werden wir nun, wie bereits angekündigt, in der nächsten Woche, am 17.02.2026 die überarbeiteten Module auch im Produktivsystem aktivieren. Ich würde gerne die Gelegenheit nutzen, mich bei Ihnen […]
  1. Sie füllen den Antrag für eine Umzugswebsite aus (unten bei „Website beantragen“).
  2. Sie bekommen einen neuen Website auf dem neuen Server mit neuer Adresse, vorausgefüllt mit der von Ihnen gewünschten Vorlage.
  3. Sie richten Ihre Website anhand der beiliegenden Checkliste ein und füllen die Vorlage mit Ihren Daten aus.
  4. Ihre neue Website ist öffentlich. Wenn niemand den Zwischenzustand Ihrer Website sehen soll: Auf privat setzen funktioniert für alle Seiten in Dashboard > Seiten > alle anhaken > bei Mehrfachaktionen auf Bearbeiten > Übernehmen > Status > Privat > Aktualisieren. Links setzen, übergeordnete Seite zuordnen, im Menü einbauen funktioniert nur bei öffentlichen Seiten. Entwurf geht auch. Passwortgeschützt funktioniert nicht wirklich.
  5. Welche Webadressen sollen auch nach dem Umzug gefunden werden? Vermeiden Sie „Seite nicht gefunden“. Nennen Sie die Seiten genau so wie in der alten Website. Der Effekt ist dann quasi wie eine Weiterleitung auf die alte Website!
    Wenn die Seiteninhalte in der neuen Website in einer anderen Seite enthalten sind, können Sie übergangsweise von einer neu angelegten Seite mit der gleichen URL auf diese andere Seite verweisen.
    Dies macht es Benutzern und Suchmaschinen einfacher, die Inhalte in der neuen Website zu finden. Seiten, die nur solch einen Verweis enthalten, löschen Sie nach einigen Wochen.
  6. Verlinken Sie nie „zurück“ in ihre alte Website! Die Adressen aller alten Seiten und Dateien ändert sich bei Umzug von ihrewebsite.uni-mainz.de/pfad/ nach www.blogs.uni-mainz.de/pfad und sind damit nicht mehr erreichbar.
  7. Interna ziehen sie nach Sharepoint um. Infos dazu finden Sie hier Teamweb: Dokumentation und FAQ | Zentrum für Datenverarbeitung (uni-mainz.de)
  8. Die Englische Fassung soll zeitgleich umziehen, sonst gibt es Chaos in den Verlinkungen der englischen Fassung.
  9. Wollen Sie die Website für Archivzwecke dauerhaft lokal aufbewahren, sichern Sie die alten Website z.B. per httrack. Benötigen Sie die alte Website nur noch einige Zeit nach Umzug, um etwas nachzuschauen und zu vergleichen, ist das unnötig, denn die alte Website bleibt ja noch Monate erhalten!
  10. Sie sind fertig mit dem Umzug und benachrichtigen uns, daß die Adresse nun umziehen kann. Planen Sie 2-3 Werktage ein, bis sich der Adressumzug im Internet verteilt hat.
  11. Spätestens jetzt dürfen Ihre neuen Seiten nicht mehr privat sein. Sonst erhält man nach dem Adressumzug einen „Seite nicht gefunden 404-Fehler“.
  12. Wir ziehen die Webadresse der alten Website zur neuen um.
  13. Die alte Website ist ab jetzt vor öffentlichem Zugriff geschützt. Es werden nur Seiten geschützt, keine Medien. Sie erreichen Ihre alte Website unter: https://www.blogs.uni-mainz.de/subsite-teilen-wir-ihnen-mit
  14. Die alte Website mit allen Dateien bleibt Ihnen erhalten und stellt damit eine komplette Datensicherung zum Zeitpunkt des Umzugs dar!
  15. Wir mailen Ihnen den Zugangslink nach erfolgtem Umzug per Mail.
  16. Der letzte Schritt ist dann die vollständige Entfernung des alten Websites nach drei Monaten. Das übernehmen wir für Sie. Gern bewahren wir die Seiten auch noch länger auf, melden Sie sich mit dem Datum, an dem Ihre alte Website entfernt werden soll.
  17. Diese Websites verwenden das neue Layout (Stand Februar 2025)

Die URL Ihrer Webseiten sollten Sie wiederverwenden. Wenn der hintere Teil der URL im alten und neuen Webauftritt identisch ist, erreichen Sie einen suchmaschinenfreundlichen Umzug ohne „File not Found“-Fehler!

Alle Adressen und Ihre Benennungen für einsprachige Websites:

Vor dem Umzug:

  • Alter Webauftritt:
    • Primäre Domain: ihrinstitut.uni-mainz.de
    • Subsite-Adresse (unsichtbar): www.blogs.uni-mainz.de/dies-bekommen-sie-von-uns
  • Neuer Webauftritt:
    • Subsite-Adresse: cms.zdv.uni-mainz.de/dies-bekommen-sie-von-uns
    • Login: cms.zdv.uni-mainz.de/dies-bekommen-sie-von-uns/wp-admin

Nach dem Umzug:

  • Neuer Webauftritt:
    • Primäre Domain: ihrinstitut.uni-mainz.de
    • Subsite diese Adresse bleibt unsichtbar erhalten: cms.zdv.uni-mainz.de/dies-bekommen-sie-von-uns
  • Alter Webauftritt:
    • Subsite-Adresse: www.blogs.uni-mainz.de/dies-bekommen-sie-von-uns, diese Adresse bleibt nach dem Umzug mit allen Daten noch 3 Monate erhalten.
    • Login: www.blogs.uni-mainz.de/dies-bekommen-sie-von-uns/wp-admin
  • Verlinkungen innerhalb der neuen Seiten bleiben auch nach Umzug der Primären Domain erhalten, die neue Adresse kommt zusätzlich hinzu.
Bildliche Darstellung des umlaufenden Textes

Statt des Classic Editors mit der Formate-Leiste verwenden Sie den Gutenberg Block-Editor, der seit Jahren der Standard in WordPress ist. In der alten Multisite setzen wir den Classic Editor ein. Der Editor ist einer der größten Unterschiede zwischen den beiden Multisites unter www.blogs.uni-mainz.de = ALT und cms.zdv.uni-mainz.de = NEU

Jede Seite besteht aus Blöcken. Die Block-Liste beschreibt den Block und verweist auf die ausführliche Anleitung mit Beispielen in der Demo-Website und der Videoanleitung.

Besonders arbeitssparend sind Blöcke, die dynamisch Daten aus anderen Systemen wie FIS = Publikationslisten, IdM = Personen und Organisationsstrukturen, Jogustine = Lehrveranstaltungen anzeigen.

Die Vorlagen sparen Ihnen Zeit und Arbeit, denn Sie überschreiben die vorhandenen Inhalte mit Ihren Daten. Im Antrag auf eine Website wählen Sie eine Vorlage aus:

Wenn Sie umziehen oder auch eine neue Website im JGU Layout möchten, füllen Sie folgenden Antrag aus:

Mehrsprachigkeit richten wir auf Ihren Wunsch hin ein. WordPress Multilingual = WPML übersetzt Ihre Texte automatisiert.

  1. Der künftige Translation Manager (wahrscheinlich sie selbst) muß sich im WordPress Subsite einmal erfolgreich angemeldet haben.
  2. Die Übersetzungssoftware WPML richten wir für Sie ein.
  3. Der Translation Manager gibt sich selbst und seinen Redakteuren Übersetzungsrechte.
  4. Ab jetzt dürfen diese Redakteure übersetzen.
  5. Im Editor entscheiden Sie seitenweise über automatische Übersetzung per WPML Editor oder eigene Übersetzung per WordPress Editor.
  6. Sie haben bei der automatischen Übersetzung die Möglichkeit, satzweise die Übersetzung zu ändern.
  7. Nach jeder Änderung der deutschen Seite zeigt WPML über den Rundpfeil an, daß Sie die englische Version nachziehen müssen.
  • Die von Ihnen angeforderte Seite ist von Ihrem Browser aus nicht erreichbar. Bitte nutzen Sie einen Arbeitsplatz-PC in Ihrem Büro an der Johannes Gutenberg Universität Mainz oder nutzen Sie die Remote Desktop Verbindung: Diese Fehlermeldung kommt, wenn Sie von außerhalb der JGU arbeiten und VPN nicht eingeschaltet ist. Die Meldung kommt auch, wenn Sie eine Seite als Entwurf gespeichert haben. Dann wird versucht, daß Sie sich anmelden und DAS wiederum geht nur mit VPN, RDV, oder direkt an der JGU.
  • Seite wird nicht gefunden 404: die Seite ist noch als Privat gekennzeichnet. Nur, wenn man Redakteur und eingelogged ist, hat man darauf Zugriff.
  • Schreibrechte: im Dashboard > JGU Tools > Benutzer werden die Personen mit Zugriff auf die Berechtigung-Ressource angezeigt. Diese Personen verwalten via Account.uni-mainz.de > Berechtigungen > Ressource Webseite die Schreibrechte. Administratoren meint dort die Rechteverwalter, „Inhalte bearbeiten“ die Personen in der Redaktion. Es reicht, wenn Sie Benutzer unter account.uni-mainz.de in die richtige Gruppe eintragen. Ein Klick auf den Knopf ‚Benutzerliste aktualisieren‘ ist im neuen WordPress nicht mehr notwendig.
  • Silbentrennung: Dies ist nicht browserübergreifend gelöst.
  • Farben fehlen: Die Hintergrundfarben der Blöcke sind auf die im Corporate Design der JGU festgelegten Farben beschränkt.
  • Eigene Icons verwenden: Dies ist technisch prinzipiell machbar, derzeit jedoch noch nicht möglich.
  • Intranet-Funktion: Finden Sie in Teams, LMS, Sharepoint, je nach Anwendungsfall.
  • Download-Center: Wohin mit den Downloads?
  • Alte Multisite wird abgeschaltet: dafür gibt es noch kein Datum
  • Re·launch /ˈriːlɔːnt͜ʃ,/ ist das, was Ihre Website mit dem Umzug bekommen hat 😉
  • Kurse – alles rund um die Bedienung: Wir stellen Anleitungen und Schulungen bereit, sind in Fragestunden und Foren für Sie da und helfen im Fehlerfall.
  • Newsletter Abo: Mailingliste (offener Newsletter) für Informationen zum blockbasierten Layout. Starten Sie das Abo, indem Sie eine E-Mail mit dem Betreff subscribe jgu-cms an sympa@lists.uni-mainz.de senden.
  • WordPress-Forum: Stellen Sie Ihre Fragen zur Bedienung von WordPress, schauen Sie bei der Problemlösung zu im WordPress Forum, welches per BBB stattfindet: https://bbb.rlp.net/rooms/slo-mk5-tdt-xe0
  • WordPress Anleitungen Layout 2012 mit Shortcodes und dreispaltigem Standard-Layout.
  • Koordination Webseiten: Stellen Sie organisatorische und inhaltliche Fragen in der Gruppe Koordination Webseiten (Zugänglich mit JGU Account). Sie trifft sich Montags von 12-13 Uhr alle zwei Wochen. Bei Interesse melden Sie sich bei:cio@uni-mainz.de.

Wir treffen uns am jeweils ersten Montag von 11 bis 12 Uhr und am dritten Donnerstag von 10 bis 11 Uhr für eine Stunde rund um WordPress.

  • 19.3. Donnerstag 10 Uhr: How to translate a menu and what if it goes wrong.
  • 6.4. Montag 11 Uhr
  • 16.4. Donnerstag 10 Uhr
  • 4.5. Montag 11 Uhr
  • 21.5. Donnerstag 10 Uhr
  • 1.6. Montag 11 Uhr
  • 18.6. Donnerstag 10 Uhr
  • 6.7. Montag 11 Uhr
  • 16.7. Donnerstag 10 Uhr
  • 3.8. Montag 11 Uhr
  • 20.8. Donnerstag 10 Uhr
  • 7.9. Montag 11 Uhr
  • 17.9. Donnerstag 10 Uhr
  • 5.10. Montag 11 Uhr
  • 15.10.Donnerstag 10 Uhr
  • 2.11. Montag 11 Uhr
  • 19.11. Donnerstag 10 Uhr
  • 7.12. Montag 11 Uhr
  • 17.12. Donnerstag 10 Uhr

Ihnen fällt sicher auf, dass es immer wieder unvollständige oder fehlerhafte Dinge gibt. Bei der Menge an Blöcken und Funktionen, den Verschachtelungsmöglichkeiten und den sich daraus ergebenden Wechselwirkungen ist ein Webprogrammierer-Team nötig, um alle Fehler zu fixen und alle Wünsche zu erfüllen.

Wir haben mehrere hundert Fehler aufgenommen und arbeiten sie nacheinander ab, wobei wir immer auch die Performance, die Barrierefreiheit und die Datensicherheit im Auge behalten.

Aktuelle Themen, die wir so schnell wie möglich beheben möchten:

  • Beiträge optimieren für Social Media: open-graph (og) featured pic
  • Kategorien- und Schlagwortseiten, die man im Menü auswählen kann, funktionieren noch nicht und werden im Menü nicht angezeigt. Es gibt ähnliche Funktion durch die Blöcke: Beitragsauflistung (=Post Listing), Magazin, Beitragsarchiv
  • Schriftgrößen und -arten, Ausrichtung: Im Layout werden mehrere Größen angeboten. Die Schriftart ist vom Layout vorgegeben. Die vorgegebene linksbündige Ausrichtung sollten Sie so eingestellt lassen.
  • Schriftfarben: Die Schriftvoreinstellung ist schwarz auf weiß. Das ist vom JGU Layout vorgegeben und soll nicht geändert werden.
  • Textausrichtung: sollte linksbündig sein und bleiben. Zentriert sieht komisch aus, und Blocksatz ist unleserlich und nicht mit dem Blocksatz einer gedruckten Seite zu vergleichen.
  • Bildskalierungen: Alles über 1200 Pixel Breite ist meist unnötig.
  • Layout generell: verwechseln Sie eine Website nicht mit den Gestaltungsmöglichkeiten von z.B. Word, Powerpoint oder einer Bildbearbeitungssoftware. Die Webseite ist dazu da, um Inhalte zu veröffentlichen. Sie können nicht die Anzeige auf jedem Gerät und in jeder Fenstergröße prüfen. Sorgen Sie sich nicht um das Layout. Dies ist vorgegeben und soll nicht händisch künstlich und mit Aufwand abgeändert werden. Damit machen Sie den Ihnen nachfolgenden Redakteuren das Leben schwer.

Shortlink für diese Seite: https://jgu.to/zdv/wordpress| Die englische Seite wurde mit DEEPL übersetzt.