Posts by yzdev

    Der Wunsch ist nicht neu, auf WoltLab würde ich allerdings nicht setzen: Tabellen pimpen


    Eine Möglichkeit ist, TableFilter einzubinden: Ergebnis

    Der Hauptknackpunkt an TF ist die nötige Definition der Datentypen der Spalteninhalte. Zwar wäre es möglich, diese beim Erstellen der Tabelle durch User angeben zu lassen, komfortabel ist das jedoch nicht (und seitens WL wird HTML ja sowieso sanitized …). Die Konfiguration aufgrund des Inhalts der jeweils ersten Zelle einer Spalte nachträglich mit JS vorzunehmen, erschien mir jedenfalls sinnvoller und hat sich bei uns als tauglich erwiesen. Sonderlich robust ist das Ganze nicht, aber für übliche Datentypen reicht es.

    Gino Zantarelli

    Im Falle der Standardfarben für Badges und Icons ist der Aufwand überschaubar [copy & paste aus o. g. Dateien + edit] und je nach Arbeitsweise und Anzahl zu bearbeitender Stile wahrscheinlich sogar flotter als WYSIWYG. Beim roten Farbton für diverse Elemente wird’s dann aber bald mühselig, zumal nicht gewährleistet ist, dass dieser zukünftig nicht noch für weitere Elemente genutzt werden wird.

    Ich betrachte die Optionen der Farbpalette als Hilfestellung für einen leichten Einstieg in die Stilerstellung/-konfiguration, denn schließlich ließe sich das Thema auch textbasiert abhandeln. Insofern halte ich es für sinnvoll, möglichst alle Farben dort konfigurieren zu können.

    An einigen Stellen sind rgba(204,0,0,1) bzw. rgba(204,0,1,1) als (background-/border-) color „hartkodiert“. Insbesondere bei dunklen Hintergründen ist das suboptimal, weil der zu geringe Kontrast bei Fehlermeldungen oder wichtigen Hinweisen kontraproduktiv ist. Es wäre prima, wenn in der Farbpalette eines Stils eine entsprechende Variable ergänzt und an den entsprechenden Stellen genutzt würde.


    Auch die default colors aus /style/ui/badge.scss und icon.scss sowie die dazugehörigen Schriftfarben harmonieren längst nicht mit allen Hintergründen und könnten konsequenterweise ebenfalls über Variablen definiert werden.

    trosty Beim Speichern eines Beitrags wird das Leerzeichen zwischen : und # entfernt:

    CSS
    .messageText [style="color:#0000FF"] {
        color: #FF0000 !important;
    }

    Allerdings sollte man bedenken, dass es diverse Varianten gibt, die Schriftfarbe zu definieren. Das Leerzeichen ist da nur ein Knackpunkt, Kleinbuchstaben beim Hexcode, rgb(a), font und andere Anweisungen in style wären weitere.

    Möchte man möglichst viele Varianten abfangen, braucht’s schon etwas mehr Code. Für Blautöne könnte man das z. B. so lösen:

    CSS
    .messageText, .redactor-box {
        & [style*="#0000FF"],
        & [style*="#0000ff"],
        & [style*="(0,0,255)"],
        & font[color="#0000FF"],
        & [style*="#0000CD"],
        & [style*="#000080"] {
            color: #7C7CFF !important;
        }
    }

    .redactor-box ist empfehlenswert, damit es keine Diskrepanz zwischen Entwurfsmodus und finalem Beitrag gibt.

    Edit: Ursache ist das Themen Ignorieren Plugin, s. Beitrag 2.


    Der Aufruf mancher Beiträge mit Beitragsvorschau [bbcode post / woltlab-metacode data-name="post" / postEmbeddedEntry] führt bei manchen unserer User zu Fehlermeldungen wie dieser:

    Befindet sich ein solcher Beitrag unter den letzten Aktivitäten, wird ein Aufruf des Dashboards mit dieser Fehlermeldung quittiert:

    Diese Fehler sind insoweit reproduzierbar, dass ein Entfernen des entsprechenden bbcodes aus dem Beitrag oder ein Ersetzen durch einen Link mit Text das Aufrufen des Beitrags und des Dashboards wieder ermöglicht. Allerdings tritt der Fehler nicht bei allen Beiträgen mit post bbcodes und auch nur bei einem Teil der User und bei Gästen offenbar gar nicht auf.

    Link 1 führt (bei einem Teil der User) zu besagten Fehlermeldungen, Link 2 nicht.


    Wir könnten ja gut damit leben, diese Vorschaufunktion komplett zu deaktivieren. Dafür scheint aktuell aber Quellcodeeingriff nötig zu sein …

    Der Status eines archivierten/geschlossenen Forums ist aktuell bei Ansicht desselben nur anhand des nicht vorhandenen +Neues Thema Buttons zu erkennen. Eine klarere Kennzeichnung wäre sinnvoll. (Schloss vor Titel wie in der Forenübersicht?)


    Nebenbei: Im ACP in den Foreneinstellungen steht „Archiv (Forum für neue Beiträge geschlossen)“, bei den individuellen Icons heißt es dann einfach „Geschlossen“.

    Beim Hovern u. a. in Mitgliederlisten werden Buttons angezeigt, deren Icons in Stilen mit dunklen Hintergründen kaum zu erkennen sind. Ursächlich ist offenbar:

    Code
    .containerList > li .buttonGroupNavigation > ul > li > a > .icon, .containerList > li .buttonGroupNavigation > ul > li > a > .invisible {
        color: rgba(0, 0, 0, 0.5);
    }

    Wünschenswert wäre, stattdessen z. B. opacity: 0.5 zu nutzen, so dass die im Stil definierte Schriftfarbe auch für die Icons verwendet wird.

    Falls du den Button einfach nicht anzeigen lassen möchtest, wäre das (bei 5.3) z. B. so möglich:

    Code
    .redactor-toolbar > li > a.re-woltlabFont {
        display: none;
    }

    Falls sämtliche expliziten font-family-Angaben ignoriert werden sollen, um stattdessen z. B. die hier üblichen Schriftarten zu verwenden, ließe sich das ebenfalls per CSS regeln:

    CSS
    [style*="font-family"] {
        font-family: "Open Sans", Arial, Helvetica, sans-serif !important;
    }

    Damit wäre dann auch der Workaround per Quellcodemodus (z. B. <span style="font-family: Comic Sans">) ausgehebelt. (Der Code bleibt unverändert.)


    Also, bei uns müsste ich mich nicht sorgen, aber wir sind auch kein Technikforum.

    Dazu braucht’s kein Wissen. Wenn „Text-Formatierung beim Einfügen in den Editor übernehmen“ aktiviert ist, reicht es offenbar, einen Text aus einem anderen Dokument einzufügen. Das passiert(e) bei uns jedenfalls so häufig, dass s. o. ;)

    In bestimmten Konstellationen kann es auch vorkommen, das keine gültige Template-Gruppe für die Auswahl zur Verfügung steht und somit eine Auswahlmöglichkeit besteht.

    Davon bin ich ausgegangen. Allerdings wäre meine Schlussfolgerung daraus, diesen Wert nur dann anzuzeigen, wenn er tatsächlich benötigt wird.

    Als Alternative böte sich an, den leeren Wert erst nach der Schleife einzufügen, so dass im Normalfall ein sinnvoller Standardwert gesetzt sein sollte. (2. Code-snippet oben)

    Ohne Erklärung muss man das wohl nicht verstehen.


    Falls mal wieder jemand darüber stolpern sollte.

    Entweder …

    Code: acp/templates/templateDiff.tpl
    {* <option value="0"></option>
    {assign var=depth value=0} *}

    … oder:

    Code: acp/templates/templateDiff.tpl
              {foreach from=$templateGroupHierarchy item='templateGroup' key='templateGroupID'}
                <option{if $templateGroup[hasTemplate] !== false && $templateGroup[hasTemplate] != $templateID} value="{$templateGroup[hasTemplate]}"{if $parent->templateID == $templateGroup[hasTemplate]} selected{/if}{else} disabled{/if}>{@'&nbsp;'|str_repeat:$depth * 4}{if $templateGroupID}{$templateGroup[group]->getName()}{else}{lang}wcf.acp.template.group.default{/lang}{/if}</option>
                {assign var=depth value=$depth + 1}
              {/foreach}
              <option value="0"></option>
              {assign var=depth value=0}

    Das ist keine „blöde Idee“, aber ein Duplikat: Auf Konversationen reagieren können


    Kann man da nicht irgend-etwas reinmachen, dass es nicht positiv wäre? […] Ich finde diese Einstellung nicht in meinem Forum wo man Reagieren, hinzufügen, bearbeiten und löschen kann?

    Übersehe ich das?

    Ja. Füge einfach einen weiteren „Reaktions-Typ“ hinzu.


    Nebenbei: Etwas mehr Mühe beim Formulieren deiner Beiträge wäre angebracht.