StuRa Diskussion:Server/Website: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 2.391: | Zeile 2.391: | ||
* [http://www.stura.htw-dresden.de:8080/Plone/portal_skins/custom/public.css/manage_main public.css] | * [http://www.stura.htw-dresden.de:8080/Plone/portal_skins/custom/public.css/manage_main public.css] | ||
als Anpassungen eingetragen. Diese wurden einfach (ersatzlos) gelöscht. | als Anpassungen eingetragen. Diese wurden einfach (ersatzlos) gelöscht. | ||
---- | |||
falls wirklich wer den foo vermisst: | falls wirklich wer den foo vermisst: | ||
Zeile 2.403: | Zeile 2.405: | ||
* Clone vom alten snapshot zerstören | * Clone vom alten snapshot zerstören | ||
* ehemals aktuellen snapshot als Jail starten | * ehemals aktuellen snapshot als Jail starten | ||
---- | |||
Im Übrigen war bei [http://www.stura.htw-dresden.de:8080/Plone/portal_css/manage_cssForm portal_css] ''ploneCustom.css'' (neben ''++resource++plone.app.jquerytools.overlays.css'') gar nicht angewählt und entgegen der Standardeinstellung bei ''CSS Media'' nicht mit ''all'', sondern nur ''screen'' versehen gewesen. Auch ''Caching allowed?'' war entgegen der Standardeinstellung nicht angewählt. |
Version vom 20. Januar 2017, 01:26 Uhr
theme
- Vorschlag
- World Plone Day 2010 theme
-- PaulRiegel 22:11, 21. Feb 2011 (CET)
Konzeption des Arbeitsablaufes
Salve Interessierte zur Website,
lieber Bereich Administration Website,
bei der praktischen Konzeption stehe ich an einer Gablung. Ich darf euch die um eure Meinung bitten:
Konzeption des Arbeitsablaufes Variante 1 (bisheriger Stand)
Benutzerinnen und Benutzer erhalten (fast) uneingeschränkte Rechte in den dezentralen Bereichen der Website (für die sie als Mitglieder des Bereiches Verantwortung haben).
- Für jeden Bereich sollte es eine Gruppe geben. Also mit Bereich ist hier auch studentische Vertretung im Senat, Wahlausschuss oder fzs gemeint. Etwa eine Person wird Mitglied beim Bereich Erstsemester, dann müsste sie in eine bestehende Gruppe Erstsemester eingetragen werden. Danach könnte die Person im Bereich Erstsemester der Website alles machen! Sollte für die hohe Anzahl von benötigten Gruppen (50 + x) der Bereiche verzichtet werden, so gäbe es "nur" (15 + x) große Gruppen. Demnach wäre die Person dann Mitglied der Gruppe Qualitätsmanagement und könnte auch in deren anderen Bereiche, etwa Alumni oder Studieren mit Kind, alles machen.
Vorteile:
- Es kann sehr schnelle was von Berechtigten für den jeweiligen Bereich online gestellt werden.
Nachteile:
- Die Benutzerinnen und Benutzer sollten Details zur Funktionsweise vom Plone kennen.
- Es sind viele spezielle Gruppen notwendig, in die Personen ein- und ausgetragen werden müssen.
- Das Nacharbeiten webadmin ist eigentlich zu spät, da der Artikel schon online ist.
Konzeption des Arbeitsablaufes Variante 2 (alternativer Ansatz)
An zentraler Stelle dürfen (typische) Benutzerinnen und Benutzer Zur Veröffentlichung einreichen.
- Alle aktiven Benutzerinnen und Benutzer können "Kreuz der Quere" Artikel anlegen und dann zur Redaktion einreichen. Für die Ausgangskontrolle (vor der tatsächlichen Veröffentlichung) sorgen aber Einzelne, die dafür bestimmt wurden. Das kann jede Person sein, die dazu mit den Rechten ausgestattet wird. Beispielsweise sollte das Referatsleitung Öffentlichkeitsarbeit und die Sprecherinnen und Sprecher sein.
Vorteile:
- Termine, Nachrichten usw. können zentral an- und abgelegt werden.
- (Gestalterische) Kontrolle und Einheitlichkeit (Erscheinungsbild, Bezeichnung usw.) der Artikel.
- Die praktische Umsetzung ist auf der Website etwas einfacher (Statt mehreren Ordnern mit jeweils vorgeschalteten Kollektionen sind nur einzelne Kollektionen je Bereich notwendig).
Nachteile:
- Ohne die Veröffentlichung, wozu nur vergleichsweise Wenige berechtigt sind, ist nichts für Externe auf der Website verfügbar.
Konzeption des Arbeitsablaufes Variante 3 (Kontrollschichten)
1. Schicht
- Das Erstellen von Artikeln werden alle angemeldeten Benutzerinnen und Benutzern zugesprochen.
2. Schicht
- Die Einreichung zur Veröffentlichen werden den Referatsleitungen und Bereichsleitungen gestattet, aber nur in ihren Bereich.
- Bei nicht besetzter Referatsleitung übernehmen dies die Sprecherinnen und Sprecher.
3. Schicht
- Nur den Referatsleitungen ist es gestattet Artikel in ihrem Referat und Bereichen zu veröffentlichen.
- Bei nicht besetzter Referatsleitung übernehmen dies die Sprecherinnen und Sprecher.
Erweiterte Rechtevergabe
- Den Referatsleitungen ist es gestattet die von ihnen als kompetent eingestuften angemeldeten Benutzerinnen und Benutzer erweiterte Rechte in ihrem Bereich zu zusprechen.(Veröffentlichen, ...)
Vorteile
- Mitglieder der Referate wissen über ihren Zuständigkeitsbereich der Website besser Bescheid.
- Kontrolle über Artikel in den einzelnen Abschnitten ist gegeben.
Nachteile
- Hoher Aufwand der Erstellung von Gruppen. (einmalig)
- Größere Zeitspanne bis ein Artikel veröffentlicht wird.
- Es sind viele spezielle Gruppen notwendig, in die Personen ein- und ausgetragen werden müssen. (Aufgabe der Referatsleitungen)
Abstimmung der Konzeption des Arbeitsablaufes
Bitte tragt eure Meinung (zur Übersicht) in die entsprechende Tabelle mit Name (oder im StuRa bekannter Nick) ein.
(überwiegend) Kollegiale
-- 12:45, 3. Sep 2011 (CEST)
Gruppen
Bitte das Ergebnis dokumentieren.
Ticketsystem für Reviews
Salve Aktive,
soll das eine persönliche (entsprechend dem Recht zur Veröffentlichung) Revisionsliste werden?
Dabei sollte vielleicht geprüft werden, wenn nicht sogar schon geschehen, in wie fern das das persönlich angezeigte dashboard (Persönliche Seite) dies ohnehin bei der angezeigten Revisionsliste tut.
Kollegiale
-- PaulRiegel 02:15, 12. Nov 2011 (CET)
PloneMeeting
Salve Aktive zur Website,
bei der Recherche zur Dokumentation (nach eines völlig anderen Sachverhaltes) für die Bedingungen von Plone stolperte ich über ein "Handbuch" zu PloneMeeting/HubSessions. Das erscheint mir interessant für uns, oder?
Ergänzend stieß ich dazu auf:
Hat wer Bock sich damit "zu bespaßen"?
Aus meiner Sicht wäre folgendes zu tun:
- separates Plone aufsetzen (damit unser übliches nicht zerschossen werden kann)
- als eigenes jail
- Ich habe diese Erweiterung nicht als "Produkt" auf plone.org finden können. Daher ist womöglich besondere Vorsicht angebracht.
- HubSessions ergänzen und testen
- Insbesondere sollten potentielle Aktive darüber informiert werden. Daher sollte der Verweis mindestens an intern@stura bekanntgegeben werden.
- evaluieren und entscheiden
- In die Entscheidung sollten mindestens folgende einzubeziehen:
Für Fragen und gewünschte Mitwirkung stehe ich zur Verfügungen.
Kollegiale
-- PaulRiegel 01:49, 24. Dez 2011 (CET)
Domain (ergänzend zu www.stura.htw-dresden.de)
Salvete Aktive (im Bereich Administration Website,
lieber Bereich Administration Rechentechnik,
ergänzend zu wiki.htw.stura-dresden.de habe ich eben einen (DNS-)Eintrag für www.htw.stura-dresden.de vorgenommen. Wie auch htw.stura-dresden.de verweist dieser auf die Website.
Es wäre zu überlegen, wie womöglich diese Domain (www.htw.stura-dresden.de) technisch etabliert wird.
Kollegiale
-- PaulRiegel 10:44, 5. Aug 2012 (UTC)
Überarbeitung
Startseite
- Nachrichten
- kategorisieren
- als default auf die startseite
- 10 stk siehe http://www.stura.tu-dresden.de
- wunschgemäß? (in Anlehnung an der tatsächlichen Seite http://www.stura.tu-dresden.de/aktuelles)
- kommt dem schon nahe wenn man Darstellung Ganzer Text einstellt --Matthias Jakobi (Diskussion)
- Prüfen ob es möglich ist im Plone einen gezwungenden Textbruch zu erzeugen
- wunschgemäß? (ergänzend mit der Sammlung (Einlesen der eigenen RSS-Feeds) von speziellen Kategorien (exemplarisch die beiden erstgenannten Referate))
- Nein ----Matthias Jakobi (Diskussion) 16:36, 15. Apr. 2013 (UTC)
- Nachrichttemplate
Analyse
Dokumentation zum wirksam werden von vorgenommen Änderung zu administrativen Einstellungen per Frontend
Salvete Aktive,
ich habe heute (gestern) was per Zope-Management-Oberfläche bei unserem Plone geändert (Ausmerzen eines Fehlers der Darstellung beim Drucken (print.css
), welche Angestellte ja bei täglichen Arbeiten müssen nutzen können).
Der Fehler ist (scheinbar) nun erfolgreich behoben.
Mich daran (dann) zufällig erinnernd, wusste ich, dass die Änderungen (durch entsprechende Einstellungen bedingt) nicht sofort wirksam werden. Ferner stellt sich aber trotzdem die Frage: "Wie kann ich sicherstellen, dass nun meine gemachten Änderungen wirksam sind (Oder ist das jetzt noch nicht wirksam?)?"
Für eine Erklärung, möglichst mit entsprechendem Test, wäre ich dankbar.
BTW: Apache (passend zum Plone) mit entsprechenden Einstellungen zum Cache ?!?
Kollegiale
--PaulRiegel (Diskussion) 03:51, 3. Mai 2013 (CEST)
Wenn es mal arg dinglich ist und sich hier immer noch keine Antwort angefunden hat: Einfach (brutal) den Apache neu starten:
apachectl restart
--Paul 01:01, 7. Jul. 2015 (CEST)
sicherheitskopie von ploneCustom.css
File at /portal_skins/custom/ploneCustom.css
Text wegen der Vielzahl von Zeilen verborgen! Im Modus zum Bearbeiten ist der text sichtbar
Bei /portal_skins/custom wurden 2016-03-14 die Dateien
- RTL.css
- 2015-10-06 15:18
- authoring.css
- 2015-10-06 15:19
- base.css
- 2015-10-06 15:19
- columns.css
- 2015-10-06 15:19
entfernt. Die Dateien enthielten offensichtlich keinen Inhalt.
css "mal anderes" eintragen
- plone machte ja immer faxen. daher soll versucht werden ein- und neu auszurollen.
kaputtes Layout 2017-01-19
- Done!
- Problem
Zu Morgen 2017-01-19 wurde festgestellt, dass die "doof kaputt" aussieht.
Alle Verantwortlichen waren in Ängsten (, denn Plone läuft auf srs2342, was "alt wie der Wald ist")!
Nachdem den ganzen Tag die verschiedensten Sachen (cache vom Apache "auseinandernehmen", Plone mit verschiedensten Einträgen zu CSS ausprobieren, an verschiedensten Konfigurationen herumstellen) probiert wurden (Dank an PT!) fiel user:PaulRiegel auf, dass einfach Dateien zum CSS geändert wurden. (Wohl hatte wer in besten Absichten sich daran zu schaffen gemacht das Layout der Website nun endlich einmal schöner zu machen. Leider führte das dann aber zur dauerhaften Störung der gesamten Website.)
- Lösung
Erstmal vorab: Um herauszufinden, ob die Änderungen zu CSS wirksam sind muss der Cache (von Plone, Apache und dem Browser) überwunden werden!
Standardmäßig ist der Intervall (Interval (seconds)) auf 3600 gestellt. (Temporär kann der Wert auch einmal auf nur 10 gestellt werden.)
Bei portal_skins/custom waren
als Anpassungen eingetragen. Diese wurden einfach (ersatzlos) gelöscht.
falls wirklich wer den foo vermisst:
- alten snapshot suchen
- zfs list -t snapshot | grep srs1 | grep 2017-01-19
- jail stoppen
- aktuellen snapshot erstellen
- Clone vom alten snapshot erstellen
- Jail starten
- Daten holen
- Jail stoppen
- Clone vom alten snapshot zerstören
- ehemals aktuellen snapshot als Jail starten
Im Übrigen war bei portal_css ploneCustom.css (neben ++resource++plone.app.jquerytools.overlays.css) gar nicht angewählt und entgegen der Standardeinstellung bei CSS Media nicht mit all, sondern nur screen versehen gewesen. Auch Caching allowed? war entgegen der Standardeinstellung nicht angewählt.