Änderungen und neues Theme

[paulbr]

Für die Comments der News hab ich es nicht geschafft die vorhandene relation tabelle mit d2
zum laufen zu bringen. Auf grund dessen habe ich die comments mal geclont zu cs_news_comments,
die einzelnen comments haben hier die zuständige news_id erhalten, so sind diese mit d2 auslesbar.
Das ist nur eine Alternative, wenn es anders geht kann man dies ja wieder ändern.

Ein neus Theme welches fast ausschliesslich auf div's anstatt tabellen besteht ist im svn committet.
Hier müssten wir uns mal Absprechen wie das mit den Userprofilen administriert werden soll.
Das Controll Center ist ja wohl eher Administrativ angedacht.
Der standard User, welcher kein Admin oder Moderator ist, hat da normalerweise nichts zu suchen.
Er muss aber seine persönlichen Einstellungen (profil, forum, hardware..) trotzdem machen können.
Auch in anbetracht eines späteren PM Systems und Galerien.

So viel Spass erstmal beim "dark" Theme anschauen, ich denke es kann sich sehen lassen

gruss
paul

[Jens-A. Koch]

Vielen Dank für das "dark"-Theme.
Bei mir läuft das Theme nicht so wie gewünscht. Es gibt leider ein Darstellungsproblem (FF4, GC) .
Evtl. hängt das mit dem Attribut "gridblock" zusammen.
Jedenfalls werden im "dark" alle Boxen untereinander dargestellt.
Das betrifft auch das Theme /frontend/standard, hier werden die Boxen "random user", "last registered user" und "user online" nun untereinander dargestellt.

Nebeibei: Eric Meyer's CSS Reset hab ich aktualisiert auf eine 2011'er Version.
Und ausgelagert aus der core_base.css in eine eigene reset.css.
Was dem einfachen Download der Datei von Eric's Website entspricht.
Die Datei ist natürlich via INI eingebunden und wird "gemerged".

Mit der Imagepfad-Ersetzung (doppelte Leerzeichen) liegst du richtig.
Da fehlt natürlich der weitere Pfadkontext, sonst greift der erste Replace zweimal
und der nachfolgende gar nicht mehr. Mein Fehler. Danke für den Hinweis - Gut gesehn.

News-Comments sind im Moment nicht meine Baustelle...

Also nach meiner Konzeption bleibt es beim Control Center auch für User.
Möglich ist auch, dass die Administration im Frontend erfolgt.
Konto-Existenz-Geschichten betreffen das Modul Account.
Userdaten-Profilfelder-Geschichten betreffen das Modul User.
Ein Modul ControlPanel für die Useradministration hatte ich nicht angedacht.
Ist aber auch erstmal egal, ich werde später ohnehin nochmal einige Funktionen in andere
Module verschieben, einfach um bestimmte Funktionalitätsbereich zu bündeln.

Wir müssten hier etwas aufpassen, dass nicht zuviele Module nur dem Namen nach angelegt werden, dann aber zu wenig an PHP-Inhalt haben oder auch einfach nur Templates darstellen sollen..

So ist das "Menü" des Users im Frontend ein Widget des Usermoduls.
Es wird nach Login angezeigt, usw.

Toolbox lässt sich als reines Link-Widget des eingeloggten Admins verstehen und gehört eigentlich ins User-Modul. Das ist für mich bloß ein gesondertes Verwaltungsmenü für Admins, welches Direktlinks auf das Backend beinhaltet.

So auch Toolbox CssBuilder. Die Funktionalität gehört für mich eher in den Bereich Theme-Modul.
Zudem ist es keine "action", sondern ne "admin_action", usw.

Das kann man alles auch später noch ändern (sind dann nur Änderungen in den Links und reine Funktionsverschiebungen).

Soviel erstmal, Jens

[paulbr]

Bei mir läuft das Theme nicht so wie gewünscht. Es gibt leider ein Darstellungsproblem (FF4, GC) .

Ich arbeite noch mit FF (3.6.15) da habe ich keine Verschiebungen.

Um sicher zu gehen das ich nichts vergessen habe ins svn zu laden, habe ich soeben meine dev version gesichert
und aus dem svn neu aufgesetzt.

1. PC-Check mit:
 - dual-core
 - nvidia gforce 8500gt
 - Monitor 19'' wide lcd Auflösung: 1140x900
 - Windows XP prof.

2. PC-Check mit:
 - Intel Core2 Quad
 - ATI Radeon HD 4860
 - Monitor 21'' wide lcd Auflösung: 1920x1080
 - Windows 7 ultimate

Browser-Check mit:
 - FF3 (3.6.15)
 - Google Chrome (11.0.696.68)
 - Safari (5.0.5)
 - Opera (11.10)
 - Internet Explorer (8.0.6001.18702)

Prüfung mit FF3, GC, Safari  und Opera ergaben keine Verschiebungen, es wurde alles korrekt dargestellt.
Einzig im IE8 wird der Header (Toolbar und Quicksearch) verschoben, der Main-Bereich mit den Widgets
und dem Contenbereich sowie der Footer stimmen hier auch exakt (wenn debug eingeschaltet ist).
Nach Ausschalten des Debug wird im IE8 ebenfalls alles wie es sein sollte dargestellt.

Ich mach mal nen Update auf FF4 und teste das mit dem.

Ich hab sowohl das dark theme mit obigen browsern getestet als auch das standard theme.
Das Standard theme verhällt sich ebenso wie das dark theme mit allen genannten browsern
wie es sein soll.
Ausnahme der IE8 hier wird beim standard theme alles verschoben, auch js fehler im xul-menü
(wenn debug eingeschaltet ist).
Nach Ausschalten des Debug wird im IE8 ebenfalls alles wie es soll dargestellt.

d.h. Der IE8 hat generell ein Problem mit der darstellung wenn der Debug eingeschaltet ist.


gruss
paul

-------
EDIT:
- Ich hab in der tat vergessen die geänderten daten von modules/news ins svn zu comitten.

[Jens-A. Koch]

Hmm... also der Fehler mit den Boxen liegt wohl an der fehlenden core_grid.css im import.css.
Daher gibt es auch die prozentualen Einteilungen, wie zB. "grid201" nicht.
Irgendwie wird das nicht mit einbezogen... muss ich erstmal nachforschen...

[paulbr]

Daher gibt es auch die prozentualen Einteilungen, wie zB. "grid201" nicht.

Stimmt die gibt es nicht.

grid 20% left (grid20l)
grid 20% right (grid20r)

Aber die core_grid.css ist in der csfw.css eingebunden und dadurch vorhanden.

Alle boxen in der reihe sind immer (l)eft ausser der letzten die muss (r)ight sein.
Wenn weniger als 10%, dann immer 0 davor, z.b. grid05l.

--------------

Ich hab für xdebug auch mal browseranpassung gemacht für auf im vorpost beschriebene browsern.
- Der FF hat die border angezeigt aber keiner der anderen browsern.
- Der IE hatte das lästige fieldset problem, wenn ein background im fieldset definiert ist und eine
   legend vorhanden ist, wurde der background bis auf höhe der legend (ausserhalb fieldset) angezeigt.
- Der Safari hat die <legend> immer mittig des fieldsets angezeigt anstatt links.

Was mir auch nicht so gefallen hat, das die pre's darstellung nur auf max. halben breite der box
angezeigt wurden.

Ich hoffe ich bin dir damit nicht in die quere gekommen, da du grade erst daran gearbeitet hast
bzw. noch dran arbeitest.

gruss
paul

[Jens-A. Koch]

Hallo Paul,

die Anpassung für XDebug ist super! Schöne Ergänzungen!
Wenn das so in allen Browsern aussieht, dann bin ich damit sehr einverstanden.

Ich werd noch ein wenig Javascript einsetzen, um die hardgecodeten "bgcolor" Attribute von den <td>s der Xdebug-Tabelle zu entfernen. Dadurch müssten die festgelegten CSS Werte auch für diese Element gelten. Mal sehn... Anders lässt sich das Biest wohl nicht bezwingen.
Nur mit CSS kommt man da nicht ran. Insgesamt nicht nötig, aber wenn wir gerade dabei sind...

Ich hoffe mal der Javascript Hack läuft in allen Browsern. Wird wohl darauf ankommen, obs die
Funtion getElementsByClassName() gibt. Bin gespannt.

Die Formatierungen der XDebug-Tabelle hab ich auf die Backtrace-Ausgabe des Errorhandlers angewandt.
Das Ganze sieht dann auch gleich viel netter aus.

---

Aber die core_grid.css ist in der csfw.css eingebunden und dadurch vorhanden.

Das is richtig. Im CSS Bündel des Frameworks ist sie enthalten.
Sie war auch in der import.css als @import vorhanden.
Nur die import.css wurde nicht geladen (zumindest im Frontend/Standard und wohl auch in den anderen Themes). Ich hab in der themes.core.php einen Slash gefixt (getCSSFile), danach lief es.

Gruß Jens

[paulbr]

Ich hab im xdebug noch die spaltenbreite angepasst, damit es einheitlicher ist.

Das schaut wirklich Klasse aus!

Schade das mal wieder der IE das nicht darstellen kann.
Der IE kennt kein getElementsByClassName.
Es gibt dafür zwar auch eine Lösung, aber ich denke mal das wäre mit kanonen auf spatzen geschossen.

Mir gefällt generell nicht das beim IE wenn debug aktiviert ist das seiten design zerschossen wird.
Am besten wäre wenn man den IE aus dem debug nimmt. Könnte man ja in clansuite.application mittels
browser abfrage regeln. Evtl. in der developer.config.php [error] ein parameter einfügen debug_ie=0
so kann man den nach belieben aktivieren/deaktivieren wenn man das möchte.

gruss
paul

-----------
Edit:
Achso wen es jemand interessiert:

Der IE kennt kein getElementsByClassName.

hier der link: http://www.pseliger.de/jsExtendedApi/jsApi.bundles.DOM.getters.js

[Jens-A. Koch]

Ich habs mir schon fast gedacht. 
Also für ne simple Restyling-Geschichte noch ne extra Funktion für den IE mitzuschleppen, ist mir dann doch etwas zuviel. Wäre tatsächlich mit Kanonen auf Spatzen.. das triffts.

Zu Ursache des IE-Problems: ich vermute, dass der IE in den Quirksmode gesetzt wird, wenn das Debug-HTML unten an die fertige Seite angehängt wird.
Ich würde vorschlagen, den IE nicht aus dem Debug zu nehmen, sondern die DebugConsole schlicht in nem Popup zu öffnen.

Gruß Jens

[paulbr]

Ich würde vorschlagen, den IE nicht aus dem Debug zu nehmen, sondern die DebugConsole schlicht in nem Popup zu öffnen.

Dann haben wir schon 2 popup's die jedesmal starten und mitunter nerven
Ich brauche eigentlich kein Debug für den IE, da ich den nur nutze um zu sehen ob die Styles
korrekt angezeigt werden. Ich glaube auch kaum das ein Entwickler/Designer den IE als Standard
Browser nutzt und daher das debug im IE benötigt. Probleme die nur beim IE auftreten werden sowieso
nicht in der DebugConsole angezeigt.

Fakt ist nun mal das der IE mit vielen Dingen Probleme hat.
Ich dentiere daher auf jedenfall dazu den Debug für IE separat ein/aus schalten zu können.
So hat man immer die Möglichkeit selbst und Situationsbedingt zu entscheiden ob man das haben will.

Alternative:
Wie wäre es wenn wir eine checkbox für DebugConsole on/off in die Developer Toolbox machen?
So kann man jederzeit durch klick entscheiden ob die DebugConsole angezeigt werden soll oder nicht.

Hmm..das gleiche würde sich auch für die SmartyConsole eignen.
So spart man sich auch das ausdokumentieren im template, wenn man die SmartyConsole nicht
permanent benötigt.

Auch kann so beides unabhängig voneinander ein/aus geschaltet werden.

Ist ja beides Developing und passt daher gut in die Developer Toolbox rein.

Beispiel:
  ? DebugConsole
     ? IE Debug
  ? SmartyConsole
       

Code:

<clansuite.application.php>

    private static function initialize_Debug()
    {
        self::checkDebugIE();

        if( true === IS_IE and false === DEBUG_IE )
        {
            define('DEBUG', false, false);
        }
        else
        {
            /**
             * @var Debug-Mode Constant is set via config setting ['error']['debug']
             */
            define('DEBUG', (bool) self::$config['error']['debug'], false);
        }
        ...
    }

    private static function checkDebugIE()
    {
        if(true === (bool) preg_match('/msie/i', $_SERVER['HTTP_USER_AGENT']))
        {
            define('IS_IE', true, false);
        }
        else
        {
            define('IS_IE', false, false);
        }

        if(true === (bool) self::$config['error']['debug']) {
            define('DEBUG_IE', (bool) self::$config['error']['debug_ie'], false);
        }
        else {
            define('DEBUG_IE', false, false);
        }
    }

gruss
paul

[Jens-A. Koch]

Ich glaube auch kaum das ein Entwickler/Designer den IE als Standard
Browser nutzt und daher das debug im IE benötigt.

Ja, das glaub ich auch.

Der Lösungsvorschlag ist natürlich machbar.
Das läuft darauf hinaus, dass wir anfangen uns um Sonderbehandlungen für den IE zu kümmern.
Gegenwärtig bist du der Einzige im Team, der sich die Mühe macht, Patches und Fixes im CSS Bereich beizusteuern. Dafür bin ich dir dankbar.

Wer MSIE einsetzt, schaltet Debug in der Configuration aus.
Wenn die Smarty Console nervt, dann "debug_popup = 0" in der Configuration.

Gruß Jens

Nachtrag zu "debug_popup":

Hmm..das gleiche würde sich auch für die SmartyConsole eignen.
So spart man sich auch das ausdokumentieren im template, wenn man die SmartyConsole nicht
permanent benötigt.

Ausdokumentieren musst du da eigentlich nichts.
Sorry, ich hab beim Update auf Smarty 3 schlicht vergessen, unsere Änderungen in die SmartyConsole zu übernehmen (Die Änderungen unterdrücken das Popup; deswegen ja auch "debug_popup" in der Config).

[Jens-A. Koch]

Habe die Änderungen eingefügt. Die Console wird nun bei "debug_popup 0" in die zu debuggende Seite eingefügt, bei "debug_popup 1" als Popup geöffnet. Sieht noch nicht so schön aus, aber läuft erstmal...

[Jens-A. Koch]

Hallo Paul,

durch deine letzte Änderung (Changeset #5344) ist die browserinfo.core.php gelöscht worden. Wollte nur kurz darauf hinweisen und keinen korrigierenden Commit machen oder reverten, um dir nich in die Quere zu kommen, evtl. arbeitest du ja die Datei um. Ich hab mir die letzte Version der Datei reinkopiert, um weiterzuarbeiten.

Gruß Jens

[paulbr]

hab die neu comittet.

Komisch die wurde irgendwie nicht mit comittet bei den änderungen.

gruss
paul