Ihr Haupt-Arbeitswerkzeug ist der Block-Editor. Mit ihm erstellen, füllen, verschieben und löschen Sie alle Inhalte in Blöcken.

Welche Blöcke gibt es? Links zu den Videoanleitungen und Demo-Websites.

Blöcke für Karten, Grids, Formatierungen, Standard und JGU-spezifisch, direkt zum Ausfüllen. Manche Blöcke blenden dynamisch Daten anderer Systeme wie FIS, IdM, Jogustine, Veranstaltungskalender und Beiträge anderer Subsites ein.

Erleben Sie alle Blöcke live.

Die Überblicksseite ist so aufgebaut, dass Sie zu jedem der Blöcke eine kurze Beschreibung sowie Beispiele aller Varianten haben. Für jeden Block finden Sie eine ausführliche Seite.

Sie erhalten keinen leeren Website! Profitieren sie von der Arbeit und den Erfahrungen anderer. Die Kopiervorlage nimmt ihnen viel Arbeit ab.

In der gemeinsamen Übungswebsite, dem „Sandkasten“ in der Stage-Umgebung, probieren Sie den Block-Editor und die Blöcke aus. Rechte darauf haben alle, die auch auf dem alten Sandkasten Rechte haben. Fragen Sie die Rechte an, indem Sie sich an der Sandkasten Spielwiese anmelden und dann Berechtigung beantragen wählen.

Illustrationen, die auch in der Kopiervorlage verwendet werden und andere Medien, die wir gemeinsam verwenden, befinden sich im Intranet CMS WP, auf welches alle Personen mit JGU Account Lesezugriff haben. Bitte beachten Sie, dass Sie beim Übertrag der Illustrationen in die Mediathek, die Metadaten (etwa Infos zu den Bildrechten) setzen müssen. In der Kopiervorlage wurden die Eingaben für alle Dateien in der Mediathek bereits vorgenommen.

Header-Icon, Site-Title, Quicklinks-Fuß und Menü werden alle im Customizer eingestellt. Wechseln Sie nach Dashboard > Design > Customizer und schauen Sie die Optionen an. Besonderheit ist im Quicklink-Menü, dass ausschließlich die Elemente der zweiten Menüebene angezeigt werden.

  • Footer: Leichte Sprache, Barrierefreiheit, Impressum, Datenschutz: um die Inhalte dieser Seiten müssen Sie sich kümmern.
  • Impressum: Jede Seite benötigt ein eigenes Impressum. In der Kopiervorlage ist das Impressum der Startseite übernommen. Geben Sie ihr Redaktionsteam als Kontakt an.
  • Datenschutz: In der Kopiervorlage verwenden wir die zentrale Datenschutzerklärung der JGU. Wenn Sie darüber hinaus Daten erfassen, etwa in Formularen, wenden Sie sich bei Bedarf an den Datenschutzbeauftragen.

Sollten Sie eine zweisprachige Website umziehen, so ist es empfehlenswert, beide Sprachen in einem Rutsch umzuziehen.

Zieht nur eine Sprache um, so sind danach Links im nichtumgezogenen Website defekt. Vor allem Bilder, da zum Verlinken immer die primäre und dann bereits umgezogene Webadresse verwendet wird. Ist nur eine Sprache umgezogen, dann fehlen in dem neuen Auftritt Bilder, die für die alten Webseiten der anderen Sprachvariante nötig sind. Darum ist es sinnvoll, beide Sprachen zeitgleich umziehen.

Mit dem WordPress Multilingual Plugin WPML übersetzen Sie Ihre Texte auf Wunsch mit DEEPL automatisiert.

Wenn Sie die Webadressen ihrer beliebtesten Webseiten wiederverwenden, haben Sie einen Benutzer- und Suchmaschinenfreundlichen Umzug.

  • Alter Webauftritt: Classic Editor, Layout: calamedia
    • DE URL = primärer Domainname:
      ihrinstitut.uni-mainz.de/uebergeordnete-seite/titel-der-seite
    • Subsite: Dahinter steckt diese zusätzliche Adresse:
      www.blogs.uni-mainz.de/fb-xx-ihrinstitut/uebergeordnete-seite/titel-der-seite
      Diese Adresse bleibt nach dem Umzug mit allen Daten erhalten.
    • EN URL:
      example.uni-mainz.de/parent-page/page-title
    • Subsite:
      www.blogs.uni-mainz.de/fb-xx-your-website-en/parent-page/page-title
    • Login nach erfolgtem Umzug:
      www.blogs.uni-mainz.de/fb-xx-your-website-en/wp-admin
  • Neuer Webauftritt: Blockeditor, Layout: 360vier
    • DE URL = Multisite/Subsites:
      cms.zdv.uni-mainz.de/fb-xx-ihrinstitut/uebergeordnete-seite/titel-der-seite
      Diese Adresse bleibt nach dem Umzug mit allen Daten erhalten.
    • EN URL:
      cms.zdv.uni-mainz.de/fb-xx-ihrinstitut/en/parent-page/page-title
    • Login vor dem Umzug:
      cms.zdv.uni-mainz.de/fb-xx-ihrinstitut/wp-admin
    • Blöcke wie Akkordeon, Ankernavigation, Registerkarten erzeugen Sprungmarken. Diese sollten Sie beim Anlegen sinnvoll benennen, damit Ihre URLs sprechend sind!
      Nicht so: https://projekt.uni-mainz.de/seitentitel#lebenshaltungskosten-amp-miete
      Sondern so: https://projekt.uni-mainz.de/seitentitel#kosten
    • /uebergeordnete-seite/: nötig für die Ordnung und das Breadcrumb-Menü: haben Sie die aktuelle Seite einer anderen untergeordnet (optional). Dies sollten sie aus Ihrer alten Website übernehmen!
    • titel-der-seite: die Seite selbst. Dies sollten sie aus Ihrer alten Website übernehmen!

Es gibt an der JGU einen zentralen Übersetzungsservice

Das Backend mit der Behandlung von Seiten und Beiträgen ist weitgehend identisch und darum erst einmal nicht extra mit Anleitungen versehen

  • Bulletpoints sind nicht zu finden: der Block heißt Liste
  • Silbentrennung: dies ist nicht browserübergreifend gelöst.
  • Farben fehlen (zum Beispiel Grün): dies klären Sie mit dem CIO.
  • Eigene Icons erweiterbar?: dies ist technisch im Prinzip machbar, derzeit jedoch noch nicht möglich.
  • Rechtevergabe: dies machen die Verwalter selbst. Beim Template fb-all haben alle Zugriff, die in einer der Fachbereichsrechtegruppen eingetragen sind.
  • Intranet-Funktion: wird es nicht geben
  • Studiengangsfinder: man kann beim Abschicken auf eine andere Website verweisen via URL. Damit seine Parameter auch auf eine weitere Seite übergeben werden, sollte entweder nur die Studiengangssuche in der Zielseite sein. Wenn nicht, muß per Anker auf den Zielseite gesprungen werden  (Testen) #studiengangsuche.

Ihnen fällt sicher auf, daß es immer wieder unvollständig oder fehlerhafte Dinge gibt. Bei der Menge an Blöcken und Funktionen, den Schachtelungsmögllichkeiten und den sich damit ergebenden Wechselwirkungen wäre ein Team von Web-Programmierern nötig, um alle Fehler zu fixen und alle Wünsche zu erfüllen. Wir haben mehrere hundert dieser Fehler aufgenommen und arbeiten sie nacheinander ab, wobei auch Performanz, Barrierefreiheit und Datensicherheit immer beachtet werden. Hier eine Liste der Dinge, die uns schmerzlich fehlen und die wir gern bald beheben würden:

  • Statistik: da wir die vorhandenen Plugins immer voreinstellen müssen für den Betrieb in die Multisite, ist dies leider nicht mit einer Installation getan.
  • Quickedit öffnet sich hinter den darunterliegenden Elementen: ein Z-index-Problem, welches wir uns angeschaut haben.
  • Burgermenu mobile Ansicht: das „mehr erfahren“ soll weg
  • Intranetfähigkeiten: dies werden wir nicht umsetzen.
  • Kategorien- und Schlagwortseiten funktionieren noch nicht und werden im Menü nicht angezeigt. Im Moment gibt es mit ähnlicher Funktion die Beitragsauflistung (=Post Listing)
  • das more-Tag wird nicht beachtet.
  • da es keine Widgets gibt, fehlt auch das RSS

Die Schulung ist hybrid, d.h. Sie schauen Videos und führen Übungen auf dem gemeinsamen Subsite aus. Zugriffsrechte erhalten Sie in der Fragestunde, per Mail an webmaster@uni-mainz.de und ab Mai, wenn sie sich per Antrago für einen WordPress Workshop anmelden. Sind dann noch Fragen offen, so stellen Sie diese in einer Kurs-Fragerunde, mit der der Kurs für Sie endet.

  • Mailingliste (offener Newsletter) für Informationen zum Relaunch: jgu-cms@lists.uni-mainz.de

Newsletter abonnieren/abbestellen

Die Mailingliste ist ein offener Newsletter, das bedeutet:

  • Wer kann senden?
    • Nur Moderatorinnen und Moderatoren
    • Ihre Nachrichten werden sofort verteilt
  • Wer kann die Liste abonnieren oder abbestellen?
    • Alle – Das Abonnement der Liste ist frei
  • Wohin werden Antworten geschickt?
    • An die Adresse, von der eine Nachricht an die Liste geschickt wurde

Stellen Sie Ihre Fragen, schauen Sie bei der Problemlösung zu im wöchentlichen WordPress Forum, welches per BBB stattfindet: https://bbb.rlp.net/rooms/slo-mk5-tdt-xe0

  1. Sie entscheiden selbst, ob sie während der Arbeit privat oder öffentliche Seiten haben möchten. Die Filter dazu stehen oben in der Seitenliste bereit. Obacht, das verlinken, Parent-zuordnen und im Menü einbauen funktioniert nur bei öffentlichen Seiten.
  2. Identifizieren Sie wichtige Seiten, die in Suchmaschinen weiterhin gefunden werden sollen und nennen Sie die URLs entsprechend genau so wie in der alten Website.
  3. Entrümpeln Sie: nur öffentliche Inhalte gehören nach WordPress. Interna ziehen sie nach Sharepoint um.
  4. Sobald Sie fertig sind, setzen Sie alle Seiten von Privat auf öffentlich per Mehrfachaktion.
  5. Als letztes ziehen wir Ihnen die Webadresse der alten Website zur neuen um.
  6. Der umgezogene alte Website wird vor Zugriff geschützt. Es werden nur Seiten geschützt. Die Medien sind nicht geschützt! Ihre ganzen alten Dateien sind also weiterhin in den Suchmaschinen zu finden.
  7. Sollte sie das irgendwann stören, so können wir den Website archivieren, dann ist die gesamte Website nicht mehr zugreifbar. Auch nicht für Redakteure. Bei Bedarf können wir die Archivierung wieder zurücknehmen.
  8. Der letzte Schritt ist dann die vollständige Entfernung des alten Websites nach einigen Monaten. Das übernehmen wir für Sie.

Warum gibt es keinen automatischen Umzug wie beim Umstieg von OpenText nach WordPress? Der automatische Umzug ist aus folgenden Gründen unerwünscht:

  • Die Struktur der Webseiten ist eine komplett andere, man kann die Block-Elemente nicht nutzen beim automatischen Umzug.
  • Altlasten vom vorletzten Umzug würden mit übertragen. Veraltete Inhalte sind nicht gut.
  • Die Leitung der JGU wünscht eine zielgruppenbasierte Darstellung und Ansprache.
  • Alles interne soll in einem Intranet aufbewahrt werden.
  • Bilder müssen in genau passender Größe geliefert werden. Daher ist ein automatischer Bildübertrag nicht sinnvoll.

Beantragen Sie Ihre neue Website.

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