[FINAL] Blackfog 3.3.11

[Tastenplayer]

Style ist aktualisiert nach 3.2.8.2 und zur Validierung eingereicht. Was sie in der Validierung zu meinem geänderten Style meinen, bleibt abzuwarten.

Download und Bilder in meinem Forum sind aktualisiert (Demo ist allerdings noch nicht aktualisiert, da Board noch unter 3.2.7 läuft)

Änderungen in 3.2.8.2
-----------------------
* top_blackfog (Beschreibung und search header) komplett geändert (weil bei fehlender Forenbeschreibung die Search-Header ganz nach oben rutschte und es war einfach nicht perfekt mit der bisherigen Lösung)
* div.rules komplett geändert
* Schriftfarbe im message panel geändert
* Box-shadow eingefügt in cp-mini
* Faqlinks line-height geändert

Edit: Style ist validiert

[LukeWCS]

Hi Tastenplayer

Da ich bei LFWWH2 gerade auf RC und Validierung hinarbeite, habe ich auch alle meine angepassten Templates mit den neuesten Style Versionen getestet und angepasst. Dabei ist mir bei Blackfog 3.2.8 aufgefallen, das es bei einer bestimmten Einstellung von LFWWH2 nicht mehr passt. Genauer gesagt werden die Templates für "Oben" und "Unten" nicht identisch dargestellt. Wie ich dann rausfand, ist das Problem folgendes:

Das Event index_body_stat_blocks_before befindet sich ausserhalb von statistics-container.
Das Event index_body_stat_blocks_after befindet sich jedoch innerhalb von statistics-container.

Das war bei der letzten Version die ich getestet hatte (3.2.5), noch nicht der Fall. Ist diese Änderung beabsichtigt gewesen?

edit: zur Verdeutlichung, hier habe ich den Testmodus aktiviert.
[ externes Bild ]

[Tastenplayer]

Muss ich mir definitiv nochmals genauer anschauen, wenn ich endlich mein Notebook eingerichtet habe . Die Apps in Win10 spinnen komplett. Mein Computer war von Anfang an defekt und jetzt schwirrt er immer ab. Letztens kam ich 5 Stunden nicht mehr rein.
Eigentlich sollte im Blackfog nur das Event nach dem Statblock geändert sein. Sehr komisch.

[Tastenplayer]

Das Event index_body_stat_blocks_before befindet sich ausserhalb von statistics-container.
Das Event index_body_stat_blocks_after befindet sich jedoch innerhalb von statistics-container.

Das war bei der letzten Version die ich getestet hatte (3.2.5), noch nicht der Fall. Ist diese Änderung beabsichtigt gewesen?

Das Event index_body_stat_blocks_before ist definitiv in jeder validierten Version oberhalb von <div class="statistics-container">. Hätte mich schwer gewundert, da ich da nie etwas änderte. [ externes Bild ] . Keine Ahnung was Du da für eine spezielle Version hast.

Möglich, dass es falsch platziert ist. Wurde in der Validierung nie bemängelt. Für mich heisst es ganz klar: Event vor dem Statblock, also soll es nicht im formatierten Block sein.
Aus dem gleichen Grund hatte ich ja auch das <!-- EVENT index_body_stat_blocks_after --> nach dem formatierten Block eingefügt. Was definitiv falsch war wie man an der 24hours Ext von rmcgirr83 erkannte.

Das wird in jedem meiner Styles mit Statistikblock so sein.
Bleibt die Frage, ob es wirklich keine Extension gibt, die tatsächlich vor den Block muss.

[chris1278]

Also was die beiden Events angeht, so sind die im Prosilver zwar außerhalb der div Containers allerdings, wenn man Das mittel z.B. dem Statblock von kirk lädt würden diese Events ja mehr Sinn machen, wenn diese auch innerhalb des Statblocks angezeigt würden, insbesondere beim wwh.

Falls man wirklich ein Event benötigen würde um etwas vor diesem Statistik-Block (ob jetzt optisch in einem Container oder Standard bei Prosilver) anzeigen lassen muss, könnte man ja auch das Event <!-- EVENT index_body_forumlist_body_after --> nutzen. Dann würde es dennoch vor dem Statistik-Block angezeigt werden. Der einzige hacken dabei wäre nur das Wenn man ausgeloggt ist dann darunter das Login Feld erscheinen würde. Aber da man davon ausgehen kann, das die meisten regelmäßigen Besucher sich eh einloggen kann, man dieses Detail eigentlich ignorieren.

Selbst wenn man explizit was unter halb des Statistik-Blocks anzeigen lassen will, könnte man dieses Event hier nehmen
<!-- EVENT overall_footer_content_after -->.

Das nur als Anregung.

[LukeWCS]

Guten Abend

Das Event index_body_stat_blocks_before ist definitiv in jeder validierten Version oberhalb von <div class="statistics-container">. Hätte mich schwer gewundert, da ich da nie etwas änderte. [ externes Bild ] . Keine Ahnung was Du da für eine spezielle Version hast.

Ich hab keine spezielle Version, sondern wie immer von hier: https://www.phpbb.com/customise/db/styl ... g/demo/3.2

Möglich, dass es falsch platziert ist. Wurde in der Validierung nie bemängelt. Für mich heisst es ganz klar: Event vor dem Statblock, also soll es nicht im formatierten Block sein.

Da wird auch nur mit Wasser gekocht und die können unmöglich jedes Detail prüfen, bei der Menge an Styles und Exts.

Aus dem gleichen Grund hatte ich ja auch das <!-- EVENT index_body_stat_blocks_after --> nach dem formatierten Block eingefügt. Was definitiv falsch war wie man an der 24hours Ext von rmcgirr83 erkannte.

Dazu kann ich nichts sagen, da ich die Ext schon lange nicht mehr nutze.

Der Punkt ist, entweder konsequent alle zusammengehörige Events innerhalb eines Containers oder ausserhalb, aber nicht das eine hier und das andere da. Insbesondere wenn es um thematisch gleichgestellte Events wie index_body_stat_blocks_before und index_body_stat_blocks_after handelt. Diese sollten sich auf demselben Struktur-Level befinden, was bei 3.2.8 jedoch nicht der Fall ist.

Momentan ist das wie folgt:

Code: Alles auswählen

<!-- EVENT index_body_stat_blocks_before -->

<div class="statistics-container">

Also ausserhalb, wie bei 3.2.5.

Dann aber das hier:

Code: Alles auswählen

<!-- EVENT index_body_stat_blocks_after -->
</div>

Also innerhalb.

Und das Letztere meinte ich, das war früher nicht der Fall. Bei 3.2.5 waren beide Events noch ausserhalb. Konsequenterweise sollte jetzt auch index_body_stat_blocks_before innerhalb sein, dann wäre es aus meiner Sicht wieder korrekt.

[Tastenplayer]

Da wird auch nur mit Wasser gekocht und die können unmöglich jedes Detail prüfen, bei der Menge an Styles und Exts.

Das stimmt leider (obwohl Raul veles sieht, was zuvor validiert wurde). Man sehe .row .pagination beim Silver-Xmas-Modern. Merkwürdig, dass da bis jetzt kein Benutzer Meldung gab.

Der Punkt ist, entweder konsequent alle zusammengehörige Events innerhalb eines Containers oder ausserhalb

Das stimmt definitiv nicht immer.

[LukeWCS]

Das stimmt leider (obwohl Raul veles sieht, was zuvor validiert wurde). Man sehe .row .pagination beim Silver-Xmas-Modern. Merkwürdig, dass da bis jetzt kein Benutzer Meldung gab.

Da hätte ich noch andere Beispiele. Ich habe mir gestern einen Style näher angeschaut der ebenfalls offiziell validiert wurde, aber im Statistik Bereich in der Version 3.2.8 ein heilloses Chaos aufweist und zudem dort mehrere wirklich krasse Fehler hat. Bei früheren Versionen war da noch alles ordentlich. Da frage ich mich auch, wie das durchgehen konnte.

Das stimmt definitiv nicht immer.

Mir ist klar, das man manchmal Kompromisse eingehen muss. Aber in dem Fall sehe ich das nicht. Es ist weder logisch noch begründbar, warum das eine Event innerhalb und das andere ausserhalb ist. Entweder beide innen oder beide aussen, denn so müsste ich jetzt theoretisch das Template-Design für beide Events unterschiedlich gestalten, obwohl sich beide Events thematisch und strukturell auf derselben Ebene befinden und somit auch ein identisches Template-Design bekommen würden, bzw. sollten.

edit:

@chris1278

Die von dir genannten Events sind nicht so ideal für den Zweck, den Grund hast ja schon selber genannt.

[Tastenplayer]

Event in allen 3.2.9/3.3.0 Styles verschoben.

[LukeWCS]

Hi

Da es ja ne Weile dauern kann bis die Validierungen durch sind: wie hast du dich jetzt entschieden bezüglich der beiden besagten Events? Dann könnte ich nämlich meine Black Fog Anpassung schon darauf vorbereiten. Oder kann man den Style irgendwo schon vorab herunterladen?