Namics launcht Digital Marketing Kampagne mit Sitecore DMS

Digital Marketing

Neue Tools, neue Möglichkeiten, aber fehlende Integration? Unter digitalmarketing.namics.com stellt Namics einen Quicktest zur Verfügung, der Marketers dabei hilft, die eigene Reife im digitalen Marketing einzuschätzen. Anhand von wichtigen Studien aus dem Bereich erhält der User eine fundierte Einordnung seines … Weiterlesen

Sitecore Native Wildcard Funktion

Struktur für Verwendung von Wildcard

Auf gewünschter Ebene kann in der Navigationsstruktur ein Item mit Namen: „*“ hinzugefügt werden. Damit das Abfangen der Requests funktioniert, ist es wichtig, dass der Name keine weiteren Zeichen enthält. Zur besseren Begrifflichkeit kann der DisplayName verwendet werden.

(mehr …)

Unser Wissen für Euren Erfolg – New Release of Namics Logger Module v1.1

Vor einiger Zeit haben wir das Namics Logger Module in der Version 1.0 auf den Plattformen Sitecore Marketplace und Codeplex veröffentlicht.

In der nun veröffentlichten Version 1.1 haben wir die beiden folgenden Anpassungen vorgenommen:

DatabaseLogProcessor wurde zum Grundpaket hinzugefügt
Neu kann man Log-Einträge auch in eine entfernte Datenbank speichern lassen. Hierzu muss lediglich eine Datenbank-Connection mit dem Namen „DatabaseLog“ hinzugefügt werden. Benötigte Tabellen werden mit genügend Berechtigungen des Users automatisch erzeugt. (mehr …)

Sitecore Lock and Edit und Erstellen neuer Version unterdrücken

Ist ein User bei Sitecore nicht Administrator, muss er standardmässig jedes Item, das er bearbeiten möchte, mittels „Lock and Edit“ auschecken und nachdem er mit dem Bearbeiten fertig ist, wieder einchecken. Zusätzlich wird mit jedem Lock and Edit eine neue Version erstellt.

Lock and Edit in Sitecore

Diese Standardfunktion ist insbesondere bei grossen Content-Teams mit zahlreichen Editoren und dedizierten Workflows sehr hilfreich. Bei kleineren Teams kann dieses Feature aber zu unnötigem Mehraufwand führen, da selten mehr als ein Autor im System arbeitet. (mehr …)

Customizing: Öffnen des Content-Editors innerhalb des PageEditors

Es gibt Situationen in denen man gerne innerhalb des Page-Editors auf die Werkzeuge des Content-Editors zugreifen möchte. Für diese Anforderungen kann man in Sitecore den PageEditor-Ribbon mit weiteren Buttons einfach und ohne Programmieranpassungen erweitern: (mehr …)

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 4

Terrific Composer Struktur

Die Struktur im Terrific Composer sieht leicht anders aus als im Terrific wie oben beschrieben. Für den Start mit dem Terrific Composer kann man alle Folder ignorieren bis auf den „/src“ Folder, darin ist sämtlicher Code für unser Frontend enthalten. Für den Frontendengineer ändert sich nichts, er kann sich normal ein Composer Projekt aufsetzen wie er es kennt. Einzige Anpassung ist die, dass im Verzeichnis „web“ ein Folder „assets“ erstellt werden muss für unseren JS- und CSS-Handler. Weiter werden in diesem „assets“-Folder auch zusätzliche Elemente wie die fonts oder images angelegt.

SVN Externals für Composer Projekt

Wie das Erstellen von SVN Externals funktioniert, wissen wir nun ja. Für ein Composer Projekt müssen diese wie folgt erstellt werden. Dies passiert wieder auf dem übergeordneten Folder, sprich bei einer Einzelseite z.Bsp. auf dem Projekt Kundenname.WebApp.

Path URL Bemerkung
Layouts https://svn-url/projektname/…/src/Terrific/Composition/Resources Baselayout, CSS/JS Libraries
Modules
(Views bei MVC Projekt)
https://svn-url/projektname/Terrific/trunk/src/Terrific/Module Alle Module/Komponenten inkl. JS, CSS, LESS
Assets https://svn-url/projektname/Terrific/trunk/web/assets Alle Bilder, Fonts, Handler für JS und CSS

 

Wichtig: als nächster Schritt muss auf der WebApp ein SVN Update gemacht werden. Hier werden nun diese Folder in unserer Solution erstellt/hinzugefügt und anschliessend kann die Solution Commitet werden.

Die Handler für den Composer wurden leicht angepasst. Die Files für den CSS-Handler müssen in der richtigen Reihenfolge hinzugefügt werden, z.Bsp.

1
files.Add(GetLayoutFile("reset"));

Die Methode „GetLayoutFile“ holt sich aus dem Framework den entsprechenden RootPath und baut sich mit dem jeweiligen Filenamen die CSS Files in eine Liste.

1
2
3
4
private string GetLayoutFile(string pFileName)
{
return string.Format("{0}/Layouts/public/css/{1}.less", FrontendFileHandler.RootPath, pFileName);
}

Für den JS-Handler gibt es im Vergleich zur Terrific Integration keine grossen Unterschiede, nur dass die Pfade entsprechend angepasst werden müssen, hierzu ein Beispiel für die Methode „GetContent()“:

1
2
3
4
5
sb.Append(FrontendFileHandler.ReadFile("/Layouts/public/js/jquery-1.8.3.min.js", true));
sb.Append(FrontendFileHandler.ReadFile("/Layouts/public/js/terrific-2.0.1.min.js", true));
sb.Append(FrontendFileHandler.ReadDirectory("/Layouts/public/js/statics"));
sb.Append(FrontendFileHandler.ReadDirectory("/Views"));
sb.Append(FrontendFileHandler.ReadFile("/Layouts/public/js/bootstrap.js", true));

Sitecore – Frontend Settings
Für das Laden des aktuellen oder gewünschten Frontendfiles (JS und CSS) haben wir im Sitecore ein Template erstellt, welches bei der Site, dem jeweiligen Mandanten oder in einer allgemeinen Configuration Section platziert ist erstellt. Gemäss Frontendhandler haben wir hier die Möglichkeit, die Files dynamisch bei jedem Laden oder statisch zu holen (Checkbox „static“). Während der Entwicklungsphase ist es sinnvoll, beim Aufruf den Parameter „debug=true“ zu setzen, damit keine Komprimierung stattfindet und den Browser Cache zu deaktivieren (Checkbox „debug“). Damit beim Kunden sicher das aktuellste File geladen wird, haben wir dem Filepfad noch den Assembly-Key hinzugefügt – bei jedem Deployment wird gemäss Konzept die Assembly-Version aktualisiert. Wenn nur CSS oder JS Anpassungen stattgefunden haben, kann auch nur das Item „Version Key“ erhöht werden, damit ein aktuelles File geladen wird. Je nach Website (Mandanten z.Bsp.) benötigen wir einen Root Folder Prefix für die Frontend-Themen oder bei 2 Websites (Mandanten) mit den selben Funktionen, jedoch unterschiedlichen Farben kann gut mit Skins gearbeitet werden.

Vorteile/Nachteile – Mehrwert für Projekt

Ein Vorteil für ein Projekt ist sicher der, dass es keine Missverständnisse mehr gibt, welches CSS, JS oder Frontendtemplate aktuell ist – denn es gibt nur einen Stand. Die HTML-Files, in unserem Falle die phtml-Templates sind so an der korrekten Stelle im Projekt und können dann direkt in ein UserControl umgewandelt werden. So benötigt der Software Engineer keine lokale Terrific Installation oder Zugriff auf den Terrific-Staging – so kann das Markup direkt aus dem phtml verwendet werden. Die Filehandler können beliebig erweitert werden bei Bedarf und können aus dem Framework für alle Projekte verwendet werden – somit besteht ein geringer Projektsetup.

Next Steps und Ausblick

Für unsere Sitecore Projekte werden wir in Zukunft eine abgespeckte Terrific Version einsetzen, diese nennt sich Terrific Micro und ist massiv schlanker als das ursprüngliche Terrific. Hierfür wurde ein „Frontend Handler 2.0“ entwickelt welchen wir demnächst präsentieren werden.

Vorinformation von Mark Lowe zu dieser überarbeiteten Version:

„Überarbeitete Version vom bewährten Terrific Handler (JS / CSS) mit Performance-Verbesserung, voller LESS Unterstützung + Terrific Micro Unterstützung.“

Funktionen:

– Zusammenführen der verstreuten Files
– Reihenfolge welche in einem JSON File definiert sind einhalten
– Komprimieren
– Caching Serverseitig
– Browser Caching

 

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 3

Die Logik der Handlers

Welche Handler und/oder Helpers werden benötigt? Für die Rückgabe des korrekten CSS wird ein CSS-Handler eingesetzt  – dieser erbt vom CssHandler aus unserem eigenen Framework:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/// <summary>
/// CSS Handler for the Customer-Page Frontend. Returns the correct CSS.
/// </summary>

public class Css : CssHandler
{
///<summary>
/// Get all CSS files in the correct order. First all libraries, utils, elements
/// and plugin files. then the layouts css and at the end the sublayouts css.
/// </summary>

///Content of all files

protected override string GetContent()
{
var sb = new StringBuilder();
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/libraries"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/utils"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/elements"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/plugins"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Layouts"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/SubLayouts"));
return sb.ToString();
}
}

In einem BaseHandler wird der FrontendFileHandler gesetzt. In einer nächsten Methode wird der Inhalt aller CSS Files inkludiert mit der Definition des Filenamen, Unterscheidung ob der Cache geleert werden soll oder nicht.

Im Header-Usercontrol werden die CSS-Includes gerendert. Hierfür wird die Methode GetCssInclude mit entsprechenden Parametern aufgerufen. Die Beschreibung zu den Parametern gleich nachher in der Beispielmethode. Hierzu ein Codebeispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/// <summary>
/// Renders the CSS includes.
/// </summary>

private void RenderCssIncludes()
{
try
{
StringBuilder sb = new StringBuilder();

sb.AppendLine(ConfigurationManager.GetCssInclude(null, true, Assembly.GetExecutingAssembly(), true));
sb.AppendFormat("<!--[if IE]>{0}<![endif]-->\n", ConfigurationManager.GetCssInclude("ie", true, Assembly.GetExecutingAssembly(), true));

this.litCssFiles.Text = sb.ToString();
}
catch (Exception)
{
Logger.Error("Error can't render CSS Includes in Head.ascx");
}
}

Die Methode „GetCssInclude“

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/// <summary>
/// Returns the include for the Stylesheet Files.
/// </summary>
/// <param name="pTag">
/// Tag of the Stylesheet. IE, IE6, IE7, usw.
/// </param>
/// <param name="pUseLocalPathOnStaticCall">
/// Use Local Path On Static Call.
/// </param>
/// <param name="pAddAssemblyToVersionKey">
/// The p Add Assembly To Version Key.
/// </param>
/// <param name="pUseSitecoreVersionNumber">
/// The p Use Sitecore Version Number.
/// </param>
/// <returns>
/// Returns the Include Tag for a stylesheet
/// </returns>

public static string GetCssInclude(string pTag = null, bool pUseLocalPathOnStaticCall = false, Assembly pAddAssemblyToVersionKey = null, bool pUseSitecoreVersionNumber = false)
{
string url = GetFrontendFile("css", pTag, pUseLocalPathOnStaticCall, pAddAssemblyToVersionKey, pUseSitecoreVersionNumber);

return !string.IsNullOrEmpty(url)
? string.Format(" ", url)
: string.Empty;
}

Die Methode „GetFrontendFile“ gibt den Pfad für das CSS oder JS-File zurück. Ebenso wird anschliessend noch z.Bsp. eine Assembly-Version dem File angehängt um sicher immer das aktuellste File zu laden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
/// <summary>
/// Returns the Path to the JS or CSS file thats requestetd. Depeding on the Config
/// Settings of the Frontend Settings Item in the Configuration Part. It checks if the
/// file exists and returns then the correct url to the handler or to the static file.
/// </summary>

////// The Extension of the file. Normally JS or CSS
/// ////// Tag of the File (IE, IE6, usw.)
/// ////// The p Use Local Path On Static Call.
/// ////// The p Add Assembly To Version Key.
/// ///Activate the Sitecore Version Number
/// Suffix
/// ///
/// Returns the URL of the Frontend File
///
public static string GetFrontendFile(string pExtension, string pTag = null, bool pUseLocalPathOnStaticCall = false, Assembly pAddAssemblyToVersionKey = null, bool pUseSitecoreVersionNumber = false)
{
// Get the Configuration Items
Item frontendSettingsItem = GetConfigItem("/Frontend Settings");
if (frontendSettingsItem == null)
{
Log.Warn("The config item for the Frontend Settings do not exist.", typeof(ConfigurationManager));
}
else
{
CheckboxField debugCheckboxField = frontendSettingsItem.Fields["Debug"];
CheckboxField staticCheckboxField = frontendSettingsItem.Fields["Static"];
TextField rootFolderPrefix = frontendSettingsItem.Fields["Root Folder Prefix"];
TextField additionalVersionKey = frontendSettingsItem.Fields["Version Key"];
string folderPrefix = rootFolderPrefix != null ? rootFolderPrefix.Value : string.Empty;
var version = VersionNumber(pAddAssemblyToVersionKey);
var versionPrefix = string.Empty;
var browserTag = string.Empty;

if (pUseSitecoreVersionNumber &amp;&amp; additionalVersionKey != null &amp;&amp; !string.IsNullOrEmpty(additionalVersionKey.Value))
{
version = string.Format("{0}_{1}", version, additionalVersionKey.Value);
}

if (debugCheckboxField == null || staticCheckboxField == null)
{
Log.Warn(
"The config item for the Frontend Settings does not have the static or debug checkboxfield.",
typeof(ConfigurationManager));
}
else
{
// returns the ashx-handler if the dynamic file content is needed
if (pUseLocalPathOnStaticCall &amp;&amp; staticCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower().Equals("true"))
{
if (!string.IsNullOrEmpty(version))
{
versionPrefix = "?version=";
}

if (!string.IsNullOrEmpty(pTag))
{
browserTag = pTag + ".";
}

If (debugCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower().Equals("true"))
{
var fileDebug = string.Format("{0}/assets/base/static/base.{2}debug.{1}", folderPrefix, pExtension, browserTag);
if (System.IO.File.Exists(string.Format("{0}{1}", MappedApplicationPath, fileDebug.Replace("/", "\\"))))
{
fileDebug = string.Format("{0}{1}{2}", fileDebug, versionPrefix, version);
return fileDebug;
}
}

var file = string.Format("{0}/assets/base/static/base.{2}{1}", folderPrefix, pExtension, browserTag);
if (System.IO.File.Exists(string.Format("{0}{1}", MappedApplicationPath, file.Replace("/", "\\"))))
{
file = string.Format("{0}{1}{2}", file, versionPrefix, version);
return file;
}
}

if (!string.IsNullOrEmpty(version))
{
versionPrefix = "&amp;version=";
}

return string.Format(
"{4}/assets/base/{0}.ashx?debug={1}&amp;static={2}{3}{5}{6}",
pExtension,
debugCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower(),
staticCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower(),
!string.IsNullOrEmpty(pTag) ? "&amp;tag=" + pTag : ^ string.Empty,
folderPrefix,
versionPrefix,
version);
}
}

return string.Empty;
}

private static string VersionNumber(Assembly pAssembly)
{
try
{
if (pAssembly != null)
{
var assemblyName = pAssembly.GetName();
if (assemblyName.Version != null)
{
return assemblyName.Version.ToString().Replace(".", "-");
}
}

}
catch (Exception)
{
return string.Empty;
}

return string.Empty;
}

Eine weitere wichtige Klasse ist das TerrificUserControl. Hier werden zum einen verschiedene Properties gesetzt wie: zusätzliche Attribute, Connector, Modulname, Skin oder auch ein Tagname. In der RenderControl-Methode wird das entsprechende Terrific User Control gerendert mit dem jeweiligen Modulnamen, Skin und allen benötigten Connectors. Z.bsp.:

1
pWriter.Write(string.Format("", ModName, SkinName, ConName, AdditionalAttributes, TagName));

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 2

Frontend-Integration in VisualStudio Solution

Das Terrific wird nun wie folgt in unsere VisualStudio Solution integriert. Als Versionskontroll-Software setzen wir TortoiseSVN ein. Mittels SVN-Externals setzen wir die Verbindung zu den benötigten Elementen für das Layout, die Module sowie die benötigten Elemente aus dem Assets-Folder (css, js, images, etc.).

Was benötigen wir alles? Dies ist mal sicher der „layout“-Folder aus dem Terrific für unser Seitenlayout (Grid). Weiter brauchen wir alle Module aus dem Terrific (public/modules) für unsere Komponenten sowie den Assets-Folder für die allgemeinen Elemente wie JavaScripte, CSS, Bilder usw.

Wie richte ich nun meine SVN-Externals ein?

Einzelseite: die SVN-Externals werden immer auf dem übergeordneten Ordner erstellt, sprich für diesen Fall direkt auf dem Projekt für die WebApplication. Im Fileexplorer mittels rechter Maustaste auf Kundenname.WebApp-Folder –> TortoiseSVN –> Properties.

Im nächsten Dialog klicken wir auf „New…“. Nun kommen wir zur Erstellung des Externals.

Local path: hier definieren wir den Namen des Externals welcher in der Solution dargestellt wird.

URL: hier geben wir den Pfad auf unseren gewünschten Terrific-Folder an.

Wir benötigen nun für unser Einzelseiten-Projekt folgende 3 Externals:

Path URL
Assets https://svn-url/projektname/Terrific/public/Assets
Layouts https://svn-url/projektname/Terrific/public/layout
SubLayouts https://svn-url/projektname/Terrific/public/modules

Wichtig: als nächster Schritt muss auf der WebApp ein SVN Update gemacht werden. Hier werden nun diese 3 Folder in unserer Solution erstellt/hinzugefügt und anschliessend kann die Solution Commitet werden.

Mandanten:  bei einem Auftritt mit mehreren Mandanten wird in der VisualStudio Solution im WebApplication Projekt ein Folder „Frontend“ angelegt. Darin wird für jeden Mandanten ein Folder angelegt und auf diese Folder setzen wir dann unsere SVN Externals.

Im Fileexplorer mittels rechter Maustaste auf „Kundenname.WebApp\Frontend\01_Mandant“-Folder  –> TortoiseSVN –> Properties. Dann wie oben beschrieben „New…“ –> „Externals“. Die Pfade benennen wir genau gleich wie bei einer Einzelseite und geben die entsprechenden Urls’s zum Terrific an.

Path URL
Assets https://svn-url/projektname/Terrific/01_Mandant/
public/Frontend/Mandant/Assets
Layouts https://svn-url/projektname/Terrific/01_Mandant/public/layout
SubLayouts https://svn-url/projektname/Terrific/01_Mandant/public/modules

 

Path URL
Assets https://svn-url/projektname/Terrific/02_Mandant/
public/Frontend/Mandant/Assets
Layouts https://svn-url/projektname/Terrific/02_Mandant/public/layout
SubLayouts https://svn-url/projektname/Terrific/02_Mandant/public/modules

All diese Einstellungen müssen natürlich für die entsprechenden Mandanten erstellt werden.

Wichtig: als nächster Schritt muss auf der WebApp ein SVN Update gemacht werden. Hier werden nun diese Folder in unserer Solution erstellt/hinzugefügt und anschliessend kann die Solution Commitet werden.

Für den Frontend-Engineer ändert sich grundsätzlich nichts, er kann nach wie vor in seiner gewohnten Umgebung arbeiten, einzig beim Einrichten des Terrifics muss darauf geachtet werden, ob es mehrere Mandanten gibt oder nicht und entsprechend die Folderstruktur erstellt oder von einem bestehenden Projekt kopiert werden.

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 1

Schon seit geraumer Zeit setzen wir für professionelle Frontendentwicklung Terrific oder seit letztem Jahr auch den Terrific Composer ein. Was ist Terrific in einem Satz?

Terrific basiert auf der Idee, das Frontend in wiederwendbare, modulare Lego-Bausteine aufzuteilen.

Eine detaillierte Beschreibung inkl. Downloads und Möglichkeit einen Teil der Features gleich auszuprobieren findet Ihr hier:  http://terrifically.org

History und Motivation

Beim Start von Terrific für die Frontendentwicklung gab es keine Integration in die entsprechende Sitecore VisualStudio Solution. Die Probleme sind da vorprogrammiert, denn die Frontend-Solution liegt nicht im selben Repository, eine mögliche Struktur sah wie folgt aus:

Die Schwierigkeit lag darin, dass nach Abschluss der Frontendentwicklung das generierte JS- sowie CSS-File aufgerufen, gespeichert und dann in der Sitecore-Solution integriert werden musste. Dies stellt kein Problem dar, wenn alles im ersten Schritt fertiggestellt wird, keine Fehler gemacht wurden, keine Änderungen/Change Requests kommen. Sobald die Backendentwicklung in Sitecore begonnen hat, besteht die Gefahr dass auf der Sitecore Seite Änderungen direkt im JavaScript oder CSS gemacht wird und Diese dann nicht in das Terrific zurückfliessen oder natürlich auch umgekehrt. Es liegen wenn man so will 2 Files im entsprechenden Projekt (Sitecore und Terrific) – wer ist nun der Master?

Ein weiterer Aspekt sind die ganzen Module sowie die Views (Pagelayouts) und das Layout selbst. Die Module und Views mussten im Terrific geöffnet und herauskopiert werden was doch ziemlich mühsam war und der Backendentwickler musste entweder dies auf einem Stagingserver tun oder selbst lokal Terrific am laufen haben.

Da stellt sich nun die Frage, wie können wir das ganze verbessern, vereinfachen sowie integrieren. Die Idee war, dass es doch möglich sein muss, die Zusammenarbeit zwischen Backendentwickler sowie Frontendentwickler zu vereinfachen:

–          JavaScript und CSS in VisualStudio Solution bringen

–          Module und Views in VisualStudio Solution bringen

–          Frontendentwickler kann unabhängig davon in seiner gewohnten Umgebung und Struktur weiterarbeiten

Terrific Struktur

Um nachher die Integration in die VisualStudio Solution duchführen zu können, bedarf es einiger Anpassungen. Gerne zeige ich gleich 2 Beispiele – Einzelwebsite sowie Mandanten-Websites. Hierfür schauen wir uns die Strukturen sowie den public-Folder der Terrific Installation etwas genauer an.

Terrific (Einzelseite) – public-Folder

Im „public“-Folder einer Terrific-Einzelseite finden wir wie schon in der Ausgangslage die Folder für das Layout sowie die Module. Was sich hier etwas geändert hat ist die Struktur im sogenannten „assets“-Folder. Darin platzieren wir einen Base-Folder für die beiden Handler (js/css). Weiter wird der „css“-Folder wie auch der „elements“-Folder aus der ursprünglichen Terrific-Installation mit den Files/Folder für „elements“, „libraries“, „pageEditor“, „plugins“, „utils“ usw. in den „assets“ Folder verschoben. Des Weiteren finden wir im „assets“-Folder ebenso die Files/Folder für die „fonts“,“ js“  und „img“.

Terrific (Mandanten)

Bei mehreren Mandanten wird im Root des Terrific für jeden Mandanten ein „eigenes“ Terrific erstellt mit der folgenden Struktur im „public“ Folder:

–          Configs, data, layout, modules und temp Folder identisch wie bei einer Einzelinstallation

Neu: Frontend-Folder
der „Frontend“-Folder bekommt folgende Struktur: Mandanten-Name > Assets > und darin dann wie gehabt die Struktur wie bei einer Einzelinstallation (base für die Handlergeschichten, css, fonts, img, js)

Seite 10 von 20« Erste...89101112...20...Letzte »