+1

+1

Wir sollten also unterscheiden zwischen einer "Ich darf alles editieren"-Rolle (Editor-in-chief)

und einer "Ich-darf-Nutzer-bearbeiten"-Rolle (CVD?)

Wenn man sich per http://pirobaseimperia.userecho.com/topics/15-git-integration-von-templating-elementen/ mit seinen Änderungen vom eigentlichen Imperia-Core abtrennt, fällt das "releasen" schon einmal leichter.

> git checkout release-201701

> make update

Für das Aktualisieren dann vom eigentlichen Imperia-Core hätten wir auch ein Skript im Angebot.

Für das Aufsetzen einer kompletten Imperia-Devbox benutzen wir Vagrant und puppet-files, wobei wir uns dort aus dem stage-System die Daten ziehen, um dieselben Testdaten sofort in der devbox verfügbar zu haben.

Würde mich auch interessieren, wie andere das bewerkstelligen.

+1

Wobei sich das bevorzugt an Entwickler und Administratoren richtet (analog zu der früheren Mailing-Liste, die auch möglich wäre), da für "normale Redakteure" das meiste auf Grund individueller Templates sehr unterschiedlich aussehen kann.

Ich plädiere eher für Jira!

Ähnlich wie bei Redmine (Tickets+Wiki) sollte man das an Jira einbauen, da dort die "Fragen" auflaufen, und viele Antworten darauf sehr gut in eine FAQ/Howto-Sammlung passen würden.

+1

Oder die Versionsnummer generell unten im Footer beim copyright mit einbauen

Kopieren haben wir bei uns nur so implementiert, dass ganze Dokumente geklont werden.

Zwecks Kopieren in andere System, geht am einfachsten der Weg über einen Export-Knopf der eine Import-Datei erzeugt, die man in site/import/ kopieren könnte.

Problem dabei ist immer, dass zu diesem Zeitpunk bereits die Ziel-Category (mit cat/id) bekannt sein muss, da müsste man sich also als Select-Liste gönnen.

Wir haben solche "Migrationen" so gelöst, dass wir im Quell-System den site/meta Datensatz als JSON Export haben den dann auf der Ziel-Seite passend zum neuen Datensatz-Schema in eine import-Datei umwandeln.

Ich stelle mir das als bin/ admin Skript vor, dass zwei Modi kennt

1) zeige alles zu einem User (login oder uid)

2) zeige alles zu einer Rolle (groupname oder uid)

Ausgabe per Switch zu den Attributen (templates, ...)

Da das alles ein wenig anders funktioniert, kann man das Skript auch iterativ erweitern.

Kommandozeile hat den Vorteil der tabelarischen Darstellung und schnellem nach-grep

Geht bereits.

Wir haben im eigentlichen Imperia-site-Ordner symbolische Links in unser repository für:

• flex
  
• include
  
• metafiles
  
• slot
  
• templates
  

Wir haben zusätzlich in der system.conf Regelungen für views und modules, wo wir gewinnen wollen, aber den Fallback von Imperia benutzen

"VIEW_TEMPLATE_DIRS" = "GITDIR/imperia/view/"

Zum Module-Pfad sich vorsetzen (imperia/modules) muss man leider an zwei Stellen ran:

1) Apache:

<Perl>
unshift @INC, '/srv/www/imperia9/site/modules/core';
unshift @INC, '/srv/www/imperia9/site/modules/collection';
unshift @INC, '/srv/www/imperia9/berlinonline/imperia/modules';
push @INC, '/srv/www/imperia9/site/modules/fallback';
umask 0002;
$ENV{'PERL5LIB'} = join ':', @INC;
</Perl>

2) für die commandline-Skripte

muss man leider (aber es ist nur dieser eine Patch) in Zeile 30 von modules/core/Imperia/Core/ScriptEnv.pm

## diff install/imperia-current/site/modules/core/Imperia/Core/ScriptEnv.pm modules/Imperia/Core/ScriptEnv.pm

30a31,32
> my $bomodulepath = Cwd::abs_path($site_dir . '/../berlinonline/imperia/modules');
> unshift @INC, $bomodulepath;