Die kurze Antwort: Ja

Die etwas längere: Ja, es gibt diese Option, nur ist sie etwas versteckt.

Dafür kennt das Plugin den Parameter more - damit lassen sich an den Link beliebige Dinge anfügen, so eben auch data-Attribute.

Praktisch sieht das ganze dann so aus ... der Aufruf erfolgt via

{cms_selflink page='banane' more='data-tooltip="Wie gehts"'}

Das Resultat ist dann folgendes

<a href="http://heute-all.es/banane.html" data-tooltip="Wie gehts">Banane</a>

Sollte sowohl mit CMSMS-1 als auch CMSMS-2 funktionieren.

Der 2 Zeiler würd mich mal interessieren.

Hab ich nicht wieder gefunden (vlt. auch falsch erinnert).
Diverse 10kb-Dinger gibt das Netz her, wenn man nach sortable.js sucht.

eine sehr komplizierte und umfangreiche Geschichte dieses Portal.

CMSMS != Portal

Setze jetzt eher auf Iron (Chrome based).

ich suche gerade nach nem "how-to" cache

Bist du an der Stelle weitergekommen?

man merkt ja eigentlich immer erst was es so für Probleme geben kann, wenn die dann auftauchen... Folgendes Problem schaute also mal vorbei:

Die Felder bei CGUser Directory lassen sich nur bis zu einem gewissen Grad sortieren  (z.B. UserDetailView.tpl), da zunächst die festen Variablen abgefragt werden und dann die custom fields durch die foreach Schleife verarbeitet werden. Die Customfields können in dieser Logik also nicht variable ausgetausch werden. Handelte es sich bei den Customfields um Optionsfelder, deren Optionstext auch Sonderzeichen enthielt, z.B. "Verkehr & Mehr" und sich deshalb von seinem Optionswert (Verkehr & Mehr = veme) unterschied, so steht am Ende nur der value (hier veme) als Smartyvariable zur Verfügung (Aber man will da ja "Verkehr & Mehr" stehen haben...).

Deshalb also how-to-sort-foreach:
Das capture captured jedes Item unter dem {$propname}.

{* properties *}
  {foreach from=$oneuser.properties item='onepropvalue' key='propname'}
     
    
{if $properties.$propname.type == 6}       
{* image *}

      {capture assign=$propname} <img src="{$file_location}/{$onepropvalue}" width="100"/>{/capture}
    
{elseif isset($properties.$propname.opts)}       
{* dropdown/multiselect/radiobtns *}

      {capture assign=$propname} {$properties.$propname.opts.$onepropvalue}{/capture}
    {else}
     {capture assign=$propname}  {$onepropvalue}{/capture}
    {/if}

  {/foreach}

Hinterher kann man dann die einzelnen Werte über die Feldnamen als Variable abfragen (z.B. {$branche_auswahl}).
Damit man die Variablen verwenden kann, muss man natürlich die foreach Schleife vorher aufgerufen haben.

MfG

Ist "dynamisch und einfach" jetzt deine Marke ?

MfG

Und hier noch mal im ganzen zum Mitschreiben, ähmm, Mitkopieren

<input type="search" class="search-input" id="{$search_actionid}searchinput" name="{$search_actionid}searchinput" size="20" maxlength="50" value="" placeholder="{$searchtext}" pattern=".{ldelim}5,}" required title="5 Zeichen Minimum" />

Doch aufgepasst ... einige Browser passen das Aussehen des Suchfeldes der jeweiligen Arbeitsumgebung (Windows, Mac OS X) an und verbieten dabei teilweise das Stylen des Eingabefeldes per CSS.

Abhilfe schafft folgender Reset:

input[type=search]{
    -webkit-appearance: none;
    appearance: none;
}

Oder ist das wieder so 'ne seltsame Smarty-Nummer, dass man nur einen Tag warten muss, und alles ist gut ?

Nix Smarty-Nummer, die Seite ist immer noch im Menu .

Man nehme dazu ein stark vereinfachtes MenuManager-Template

{* Simple template to get only menu aliases *} 
{if $count > 0}
  {foreach from=$nodelist item=node}
    {$node->alias}{if !$node@last},{/if}
  {/foreach}
{/if}

(hier mal benamst als "plain") und füge an Stelle des bisherigen MenuManager-Aufruf folgendes ein

  {menu childrenof='alias1' template='plain' assign='a1'}
  {menu childrenof='alias2' template='plain' assign='a2'}
  {$getData = $a1|cat:','|cat:$a2}
  {menu items=$getData template='dein_Ausgabe_Template'}

Die ersten beiden MenuManager-Aufrufe "sammeln" die Aliase der untergeordneten Seiten ein, in Zeile 3 werden die gesammelten Daten aus Menü-Zweig 1 und Menü-Zweig 2 zusammengefügt. Und in Zeile 4 wird der Parameter items des MenuManager-Moduls genutzt, um die Seiten als Menü anzuzeigen.

Ich weiß, performance-seitig nicht ganz optimal, aber der Kunde ist ja bekanntlich König ... und der Vorteil, die Modifikation bleibt bei einem Update des Moduls erhalten.

Vor einiger Zeit wurde die Frage an mich heran getragen, wie man ein eigenes Admin-Theme erstellen bzw. genauer gesagt ein vorhandenes Theme für den Eigenbedarf modifizieren kann, um z.Bsp. bei Kunden-Webseiten die Administration in der eigenen Corporate Identity (oder der des Kunden) erscheinen zu lassen.

Dies ist grundsätzlich (insbesondere seit Version 1.11.x) nicht all zu schwer - so müssen nur die Namen des Theme-Verzeichnisses und einer Klasse sowie die Pfade in den Template-Dateien und der CSS angepasst werden.

Der Einfachheit halber nehm ich mal das in CMSMS-1 voreingestellte Admin-Theme "OneEleven" als Beispiel. Gegeben sei eine (fiktive) Internet-Agentur Xaver Mayer, weswegen das neue Theme "InterMayer" heißen soll.

So funktioniert es:

1. Das Verzeichnis des Themes in /admin/themes/OneEleven duplizieren und dann in "InterMayer" umbenennen

2. im neuen Verzeichnis /InterMayer die Datei OneElevenTheme.php in InterMayerTheme.php umbenennen

3. dann die Datei InterMayerTheme.php in einem Editor öffnen und diese Zeile

class OneElevenTheme extends CmsAdminThemeBase {

in

class InterMayerTheme extends CmsAdminThemeBase {

ändern.

4. jetzt müssen noch die Pfade in den Template-Dateien in /InterMayer/templates angepasst werden, also

in

ändern, usw. Bei diesem Theme betrifft es insbesondere die Dateien

• login.tpl

• pagetemplate.tpl

• topcontent.tpl

5. Jetzt noch die Pfade der CSS (/InterMayer/css/style.css) anpassen, von

in

usw.

6. Nach dem Hochladen des Verzeichnisses "InterMayer" solltet ihr nun unter "Webseiten-Administration > Globale Einstellungen > Allgemeine Einstellungen"  für das System und den Login sowie unter "Meine Einstellungen > Mein Konto > Nutzerspezifische Einstellungen" für das aktuelle Nutzer-Konto euer Theme sehen, auswählen und speichern können.

Und das war es auch schon - jetzt könnt ihr das neue Theme nach Lust und Laune anpassen (Kenntnisse in Smarty, HTML und CSS vorausgesetzt), ohne euch den Rückweg auf den Standard "OneEleven" zu verbauen .

Viel Erfolg dann bei euren Experimenten!

PS: Noch ein kleiner Tipp zum Abschluß ... eure Experimente solltet ihr tunlichst NICHT mit dem Konto des Super-Admins ausführen, sondern ausschließlich mit einem separaten Admin-Konto für Testzwecke!!!

Alternativ - haltet immer ein zweites Fenster offen, in dem ihr das Theme umstellen könnt . Bei Gefahr im Verzug ermöglicht das dann immer noch das Zurücksetzen auf den (funktionierenden) Standard.

Dieses Modul bot neben den bekannten FEU-Optionen die Möglichkeit, den Backend-Login auch für das Frontend zu nutzen. Fand ich immer hilfreich, denn wozu braucht es zwei parallele Login-Systeme ?!

Das lässt sich jedoch auch mit Bordmitteln und ohne Modul erreichen.

Damit im Backend nix schief geht (Fehleingaben etc.), müsst ihr für die User, die eigentlich keinen Backend-Zugang haben, eine (neue) Dummy-Gruppe ohne jegliche Berechtigungen einrichten.

Im Frontend fügt ihr für den zu schützenden Inhalt dies ein

{$guid = get_userid(false)}
{if !$guid}
   ... geheimer Text ...
{/if}

Damit wird abgefragt, ob der Webseiten-Besucher in der Administration angemeldet ist und im positiven Fall dann "... geheimer Text ..." angezeigt, wobei für "... geheimer Text ..." sämtliche bekannten Optionen (Module, Tags, UDT's, GCB's etc.) offen stehen.