Beiträge von Trubadix

  • Protostar user css

    OK RC 3.6.0-RC liegt an und tut auf den ersten Blick auch nicht weh :thumbup:
    Mach mich jetzt mal dran meine Tabellen für's Smartphone brauchbar zu machen.
    Beispiel --> http://www.nesselblatt-test.ksv-nesselblatt.de/index.php/spor…huetzen-lm-2016
    Ich arbeite mit dem Beispiel 1 von: http://elvery.net/demo/responsive-tables/#html-3 Ausblenden nicht so wichtiger Spalten.
    Muss nur die richtige Stelle in der user.css finden wo ich das zerwürgen kann :saint:

    Anbei die gewünschte SYSTEMINFO

  • Protostar user css

    SEF war schon zu 1.x Zeiten eine Katastrophe, daher sitzt das bei mir immer noch tief drin "weg damit".
    Wenn ich dich richtig verstanden habe ist das aber mittlerweile so tief im Core drin das es unverzichtbar ist !?

  • Protostar user css

    Mhh
    ich dachte, da es sich um eine Testseite handelt reicht die Einstellung Mindeststabilität der Aktualisierungen Release Candidate RC reicht und er macht das automatisch.
    Sei es wie sei, ich lade mir mal das RC runter und spiele es ein.
    Wenn dann die Test-Seite kurzzeitig etwas verwirrt sein sollte, dann knirscht es halt und ich brauche noch ein wenig für die Rasur.

  • Protostar user css

    Hi Later
    solch Problemfälle wie SEF und Konsorten sind bei mir Grundsätzlich deaktiviert, da es ja allgemein bekannt ist das sie derartige Dinge produzieren.
    Vor der Umstellung schicke ich auch alles was ID > 1000 ist und nicht zwingend benötigt wird erst mal nach Hause und aktiviere dann nach der Umstellung Stück für Stück um einen Anhaltspunkt zu haben wo es knirscht.
    Einige Dinge sind je nach Seite aber lebensnotwendig und bereiten dann halt mehr oder weniger Kopfzerbrechen.
    Nun ja, das auch mal in einem Core-Element etwas nicht stimmt, dass ist nun mal so.
    Und man merkt dann schnell, man ist nicht allein!!

  • Protostar user css

    Hi addi
    sehe ich auch so, ist halt Auslieferungszustand.

    Code
    $doc->addStyleSheetVersion('templates/' . $this->template . '/css/user.css');


    Das wir dann wohl mit dem nächsten Bugfix auf etwas funktionierendem rasiert werden.
    Bis dahin nehme ich mal Beispiel 1 von Later.
    Wichtig ist mir eine funktionierende user.css
    Wie ich meine Anpassungen "siehe Top Left Image Navigation" in der index.php vor Überschreibung bei Update schütze, dafür habe ich derzeit nur eine manuelle Lösung.

  • Protostar user css

    Mit Änderung von Beispiel 1 läuft kommt kein Fehler mehr.
    Das liefert var_dump jetzt.

    Code
    Set for a custom CSS file :string(73) "/--/--/--/--/--/htdocs/ksv23999/templates/protostar/css/user.css"


    und für die Ausführung bei gefunden:

    Code
    On found for a custom CSS file :string(33) "/templates/protostar/css/user.css"

    Ach ja die Testumgebung ist natürlich kein Geheimnis, Subdomain mit eigener DB.
    Mit Bordmittel umgestellte 2.5.28 auf 3.5.1:
    http://www.nesselblatt-test.ksv-nesselblatt.de
    Ist natürlich nicht Stable, kann von Zeit zu Zeit natürlich Blödsinn anzeigen weil ich gerade daran werkle.
    Wie zum Beispiel jetzt an Responsive (Fluide) Tabellen a La "http://elvery.net/demo/responsive-tables/"
    http://www.nesselblatt-test.ksv-nesselblatt.de/index.php/spor…huetzen-lm-2016

  • Protostar user css

    Hi Leutz
    hat schon einer von euch eine user.css zum laufen gebracht, damit man eigene Anpassungen nicht nach jedem Update neu machen muss :?:
    Meine Seite läuft auf Strato, Joomla 3.5.1
    Ich scheitere an einem Fehler 404 thinking
    Ergebnis ist:

    Zitat

    http://meine-domain/index.php/spor…0b017f3c60e4a4c 404 (Kategorie nicht gefunden)

    Der produzierte Link sieht für mich wie völliger Quatsch aus.

    Was stimmt da am Code nicht :?:

    Code
    // Check for a custom CSS file
$userCss = JPATH_SITE . '/templates/' . $this->template . '/css/user.css';


if (file_exists($userCss) && filesize($userCss) > 0)
{
    $doc->addStyleSheetVersion('templates/' . $this->template . '/css/user.css');

    Vielleicht hat sich ja einer von euch schon damit beschäftigt und eine Lösung gefunden beer

  • Frontend OK, Backend weis, Ich will's wissen

    Hi Later
    vielen Dank, du hast mir mit deinen Hinweisen Sehr geholfen.
    Das System läuft ohne Zicken im Front/Backend.

    Einfach neu rüberkopieren, neee. nicht mit mir.
    Dann läuft's eventuell aber man hat keine Ahnung warum.
    Also hab ich mich an die Kleinarbeit gemacht und die Dateien verglichen.
    Das ist zwar mühsam aber erfolgreich.
    Sonst hätte ich per FTP Stable drüberbügeln können bis ich grün werde.
    Der verdammte Filezilla hat sich bei der Menge einfach verstiegen, ohne Fehlermeldung, und es fehlten bei einigen, kriegsentscheidenden Datein einige Bytes.
    Hab meinen guten alten Totalcommder genommen und fragliche Dateien damit übertragen.
    Damit war es dann schon beinahe erledigt.
    Dein Geruchssinn hat dich also nicht getäuscht.
    Der nächste Knaller, den habe ich Dussel mir selbst zuzuschreiben.
    Also Augen auf beim Verkehr.
    Ich hatte beim Erstellen der Datenbank latin-codierung deutsch angegeben.
    Beim Importieren der Tabellen, welche utf-8 sind führte das dann natürlich zu unvorhergesehenen Ereignissen.
    Wenn dann nun Joomla mit einem Zugriff auf so eine Tabelle kam, hat Joomla zu Recht die Arbeit verweigert.

    Ich habe mit deiner Hilfe sehr viel gelernt, welches mir für die kommenden 12 Umstellungen viel Zeit sparen wird.
    Dafür nochmal an dieser Stelle mein ganz besonders herzliches D A N K E S C H Ö N für deine Mühe.
    Gruß Hans-Jürgen

  • Frontend OK, Backend weis, Ich will's wissen

    @Later
    du hast den entscheidenden Tipp gegeben, nun weis ich schon mal wo es knallt D A N K E

    Zitat

    Notice: Undefined property: LoginController::$input in /.../.../../../......./htdocs/ksv23001/administrator/components/com_login/controller.php on line 36 Fatal error: Call to a member function set() on null in /.../..../../../...../htdocs/ksv23001/administrator/components/com_login/controller.php on line 36


    Hmm grübel grübel, na gut dachte ich mir com_login hat nen Knall na gut kann ja beim Kopieren passiert sein also com_login auf dem Server gelöscht und aus "Joomla_3.5.1-Stable-Update_Package" rüberkopiert.
    Neuer Versuch, gleicher Fehler.
    Grummel Grummel das war's also noch nicht.
    Ergo was macht Zeile 36

    Zitat

    $this->input->set('view', 'login');


    Hmm function set() on null, was soll das denn!?

  • Frontend OK, Backend weis, Ich will's wissen

    @'Indigo66
    Sicher, ich war so angefressen, dass ich mir die Datei in einen Hexeditor geladen habe um ja nichts zu übersehen.
    Seltsam ist nur das nach admin/indes "$app->execute();" nix aber auch nichts nachvollziehbares mehr zu sehen ist.
    Bau ich in die Configuration "public $error_reporting = 'maximum';" ein so knallt's mir mit error 500 nicht nur im Frontend sondern auch im Backend. Setzte ich Debugging auf 1 ist im Frontend alles gut aberim Backend sehe ich nichts, was auf einen Fehler hindeutet.
    Seltsam ist das im Frontend das Debugging erscheint aber beim Versuch sich ins Backend einzuloggen kommt da nix.
    Ist schon echt Misteriös, ich hab einfach noch keinen Anhaltspunkt wo es wirklich knallt.

  • Frontend OK, Backend weis, Ich will's wissen

    @firstlady
    ja sicher hätte sein können aber was soll da am Syntax falsch sein "public $error_reporting = 'maximum';"
    Ich glaube mit Notepad++ bin ich eigentlich zufrieden, aber man soll nie NIE sagen. vielleicht hat ja die aktuelle Version einen Knax.
    Ich werd's mal mit einer Alternative versuchen.

    @Later
    Wie lang der Weg wird ist mir egal, ich will's wissen und verstehen.

    Erst mal vielen Dank das ihr euch reingehängt habt :)

  • Frontend OK, Backend weis, Ich will's wissen

    Zitat von Re:Later

    public $error_reporting = 'maximum';
    public $debug = '1';

    Debug Maximum ist wenig hilfreich, hat für Front und Backend einen Fehler 500 zur Folge.
    Nehm ich das wieder raus läuft zumindest das Frontend wieder.

    Wenn ich nun wüsste was index.php als nächsten aufruft, könnte ich mich mit var_dump weiter ranarbeiten.

    http://www.sc-apelern.ksv-nesselblatt.de/ der Link zur Main
    http://www.nesselblatt-test.ksv-nesselblatt.de/ der Link zur Test
    für den, der mal schauen möchte.

  • Frontend OK, Backend weis, Ich will's wissen

    Liebe Sportfreunde ich brauche Hilfe.
    Was hab ich gemacht.
    - subdomain test mit eigener Datenbank bei Strato angelegt
    - Dateien/Ordner einer umzustellenden Domain nach Test kopiert/importiert.
    - Wackelkandidaten auf der Testdomain deaktiviert
    - Umstellung von 2.5.28 per Update kurzzeit-support auf 3.5.1 durchgeführt
    - Anpassungen durchgeführt, Backend und Frontend der testdomain laufen ohne Zicken
    - Dateien auf Domain gelöscht, Datenbank der Testdomain in Domain-Datenbank importiert mit "delete if exist"
    - Ergebnis, Frontend der Domain läuft, Backend weise Seite
    - tabelle sessions in domain geleert, immer noch weise Seite
    - dump in index vor execute app

    Code
    echo "<pre><b> DUMP BEFORE EXECUTE APP CONTAINS:</b>", var_dump($app->execute), "</pre>";

    von administrator eingebaut
    - Ergebnis " DUMP BEFORE EXECUTE APP CONTAINS:NULL"
    - mach ich den Dump nur auf $app bekomme ich eine ellenlange Liste, welche ich allerdings nicht so recht interpretieren kann. Was mir auffällt ist das in dieser Liste die Daten der config nicht richtig interpretiert werde "Umlaute" , schein etwas mit UTF-8 zu sein obwohl die config utf-8 ohne bom ist.
    - besagte Liste kann ich natürlich nichtt öffentlich machen, da sie alle sensiblen Daten enthält.

    Ich brauch also einen Tipp, wie ich weiter vorgehe, denn ich will's wissen.
    z.B. wo im weiteren Verlauf lohnt es sich einen weiteren Dump einzufügen.

    Also bitte keine Tipps wie "Neu Installieren" oder ähnliches eine 1 zu 1 Kopie bei der lediglich die config angepasst wurde, das muss doch zu finden sein. search