Beiträge von franz.wohlkoenig

  • params-Field in __users "Wegen seiner Länge ist dieses Feld vielleicht nicht editierbar"

    Danke für deine Hilfe, @Re:Later. Ich habe sukzessive Plug-Ins wie k2, später alle nicht-Core-Plugins deaktiviert, ohne Änderung des Feld-Verhaltens.


    Die Ursache konnte ich finden:


    In einem CB-Feld kann man einstellen, welche Felder aus params angezigt werden (zb Backend-Sprache, Zeitzone ...). Hier hatte ich alle Felder auf "Verbergen" gestellt. Wenn ein Feld angezeigt wird (zb Anzeige der Frontend-Sprache) tritt der Fehler aus meinem ersten Post nicht auf.


    Nochmal Danke an alle, die hier mitgelesen haben.

  • params-Field in __users "Wegen seiner Länge ist dieses Feld vielleicht nicht editierbar"

    Servus,


    Das Problem


    beim Speichern eines Userprofiles mit Community-Builder (CB) im Frontend ändert sich der Wert in der Tabelle __users von default:


    Code
    {"admin_style":"","admin_language":"","language":"","editor":"","helpsite":"","timezone":"Europe\/Vienna"}


    zu (2. Speichern):


    Code
    {"admin_style":"","admin_language":"","language":"","editor":"","helpsite":"","timezone":"Europe\/Vienna","0":"{\"admin_style\":\"\",\"admin_language\":\"\",\"language\":\"\",\"editor\":\"\",\"helpsite\":\"\",\"timezone\":\"Europe\\\/Vienna\"}"}


    zu (3. Speichern):


    Code
    {"admin_style":"","admin_language":"","language":"","editor":"","helpsite":"","timezone":"Europe\/Vienna","0":"{\"admin_style\":\"\",\"admin_language\":\"\",\"language\":\"\",\"editor\":\"\",\"helpsite\":\"\",\"timezone\":\"Europe\\\/Vienna\",\"0\":\"{\\\"admin_style\\\":\\\"\\\",\\\"admin_language\\\":\\\"\\\",\\\"language\\\":\\\"\\\",\\\"editor\\\":\\\"\\\",\\\"helpsite\\\":\\\"\\\",\\\"timezone\\\":\\\"Europe\\\\\\\/Vienna\\\"}\"}"}


    und so weiter. Nach dem 18. Speichern kommt eine weiße Seite > so fiel mir das Problem auf.


    Bisher getan


    Mit Error-Report kam der Hinweis auf zuwenig Speicher-Limit, nach Suchen kam ich auf die Tabelle mit den sich ändernden Werten. Neben dem params-Feld steht der Hinweis "Wegen seiner Länge ist dieses Feld vielleicht nicht editierbar".


    Zurücksetzen des Feldwerts auf Default (einkopieren von {"admin_style":"","admin_language":"","language":"","editor":"","helpsite":"","timezone":"Europe\/Vienna"} in phpMyAdmin)
    behebt das Problem.

    • Speichern des Profils im Backend ändert den Wert nicht (weder beim Speichern im Joomla-User noch im CB-User)
    • entsprechende Anfrage an CB brachte die Antwort "we don't handle params storage.. that's joomla.. just like username, etc.".
    • ändern aller Werte im params-Feld auf Default brachte keine Änderung
    • zurücksetzen der php-Version auf die vorher verwendete 5_6_13 brachte keine Änderung
    • ein neu aufgesetztes Joomla 3.5.1 hat dieses Verhalten nicht verändert.

    Weil die Site ursprünglich mit 2.5 erstellt wurde (und ich da kein reibungsloses Update zusammenbrachte), habe ich die installierte Joomla-Version mit einem neuen 3.5.1 überschreiben lassen der > keine Änderung.


    Frage


    wie kann ich noch herausfinden, wodurch die Änderungen im params-Feld entstehen?


    Danke fürs Lesen und helfen im Voraus
    Franz

  • Einleitungstext in Artikelansicht per css ändern

    Deine Erklärung hat mir geholfen: Für Introtext habe ich deine 1. für fulltext die 2. Variante genommen.


    Falls das wer braucht: Den doppelten Einleitungstext in Variante 1 bekommst du weg, wenn du

    PHP
    <?php echo $this->item->fulltext; ?>


    verwendest.


    Nachteil: der Einleitungstext wird angezeigt, auch wenn er im Menü oder Artikel auf "Verbergen" gestellt ist.

  • Einleitungstext in Artikelansicht per css ändern

    Liebe Leute,


    der Einleitungstext eines Artikels (also der Bereich vor <hr id="system-readmore" />) wird standardmäßig genauso formatiert wird der nachfolgende Lauftext (ich verwende eine Kopie des Protostar-Templates).


    Im Override für com_content > article findet sich in der default.php

    PHP
    <div itemprop="articleBody">
        <?php echo $this->item->text; ?>
    </div>


    Damit wird allerdings der gesamte Artikeltext inklusive Einleitungstext angesprochen. Vermutlich sollte dort eine Unterscheidung zwischen

    • "vor <hr id="system-readmore" />" und
    • "nach <hr id="system-readmore" />"

    samt class="introtext" eingebaut werden.


    Dafür reichen meine spärlichen php-Kenntnisse nicht, bei j-over habe ich nichts dafür gefunden, deswegen mein Frage, ob mir wer bei der Lösung behilflich sein kann.


    Danke im Voraus

  • Extension: Module auf Mobile Webseiten ausblenden

    @ "Zwar nicht wirklich responsive"


    Ohne den Advanced Module Manager im Detail zu kennen, läuft das wohl über User Agent-Erkennung. Sprich bei zB einem mobilen Browser wird ein Modul nicht angezeigt. Bei "hidden-phone" wird geladen, um es dann nicht anzuzeigen - stell dir ne fette Slideshow vor, macht wenig Sinn, die zu laden nur um sie auszublenden.


    Hat nix mit Responsiv zu tun, mehr mit Sinnhaftigkeit.

  • Menüeinträge verstellen sich ohne dass ich etwas ändere

    Ich kenne bei eingeschaltetem Cache (System > Conservative oder Progressive macht keinen Unterschied) nur falsche Menüs. Damit meine ich, dass das erste Untermenü bei Aufruf andere Menüpunkte angezeigt wird. Auf Github hab ich das gemeldet, andere haben das Problem auch, bei den meisten scheint es aber zu funktionieren.


    Deswegen habe ich jedweden Cache abgeschaltet.

  • Replace-Befehl in MySQL mit "Platzhalter"

    Dieser Ablauf führte zum gewünschten Ergebnis:

    • Backup
    • Export der Tabelle als *.csv
    • TextWrangler:
      Suche: <p class=\\"classname\\">(.*)</p>
      Ersetze: <h3 class=\\"classname\\">\1</h3>
    • Leeren der Tabelle und Import in MySQL

    Anmerkungen:

    • Der Upload der 27 MB-Tabelle hat einige Minuten benötigt. Deswegen habe ich für die gesamte Zeit das Frontend-Editing deaktiviert (keine Redakteurin kann einen Artikel öffnen) und die paar Minuten ohne Artikel am Wochenende in Kauf genommen.
    • Es gab Artikel, die aus mir unbekannten Gründen Suchen+Ersetzen ignorierten. Die habe ich in MySQL suchen lassen und im JCE mit Suche=<p class="classname"> auf Ersetze=<h3 class="classname"> geändert. Beim Speichern des Artikels ändert JCE den falschen auf den richtigen schließenden Tag.


    Danke nochmal an alle, die mir geholfen haben.

  • Replace-Befehl in MySQL mit "Platzhalter"

    da war ich natürlich und hab einiges versucht: von '.*' über ".*" und {.*} oder [.*] sowie `.*`, auch ohne (). Leider alles erfolgslos, die Syntax stimmt (also keine Fehlermeldung), nur eben keine Änderung.


    Wenn ich nur <p class="zwischentitel"> suche, wird erfolgreich ersetzt, erst ab "<p class="zwischentitel">(.*)" bleibt die Abfrage folgenlos.

  • Replace-Befehl in MySQL mit "Platzhalter"

    Im Textwrangler klappt der Austausch der Tags mit dem Suchen/Ersetzen-Pärchen von @addi. In MySQL wird im Suchen-Teil (.*) ignoriert, also Syntax stimmt, nur der Wert (.*) muß offenbar ein anderer sein.


    Habt ihr einen Tipp, was ich in MySQL eintragen muß? Ich möchte diese Arbeiten in MySQL erledigen, um keine Downzeiten für Redakteure zu produzieren.


    Falls das nicht klappt, werde ich den von @CurlY BracketS vorgeschlagenen Weg mit Textwrangler gehen.

  • Replace-Befehl in MySQL mit "Platzhalter"

    @addi TextWrangler ist auch der meine. Upload-Größe ginge sich aus. Danke für den Hinweis.


    @CurlY BracketS Nach 2 Ersetzen-Durchgängen (zuerst <p class... in <h3 class..., dann alle </p> in </h3>) in MySQL zeigen Browser korrekt an. Im Quellcode steht zwar der falsche schließende Tag, aber lt. HTML ist der gar nicht zwingend nötig bzw. beim Testen alter IE (bis 5) klappt die Darstellung. Habe ich was übersehen oder spricht was gegen diesen Weg?


    Anmerkung: Direkt in MySQL hat gegenüber dem Export der Tabelle den Vorteil, dass Redakteure weiterarbeiten können (neue Artikel werden über JCE eh mit der neuen Syntax erstellt).