Beiträge von Re:Later

    Ich mach so was über Plugins (public function onContentPrepareForm($form, $data)) sollte aber wohl auch anderswo so gehen.
    3 Varianten aus einem Demo-Plugin von mir


    Beim Debuggen des Neu-Indizierens wird ein SQL-Fehler (siehe Anlage) protokolliert. Ich bin aber nicht sicher, ob dieser Fehler mit dem eigentlichen Problem zu tun hat.


    Das sieht für mich so aus, als ginge es hier lediglich um die abschließende Anzeige der Liste. Ich denke das LIMIT wird variieren je nachdem was du im Auswahlfeld Anzuzeigende Anzahl # in Liste (oder wie es im Suchindex heißt) einstellst.
    Das wäre ebenfalls ein neues Issue auf GiHub wert.
    Meine Recherchen haben leider nichts ergeben, wo das doppelte LIMIT herkommt.


    Zu Debug: Ich bin nicht ganz sicher, kann mir aber vorstellen, da das neu Erstellen des Index über Ajax läuft, dass die Debugmeldungen "verschluckt" werden.

    Zitat

    Leider zeichnet sich in github.com/joomla/joomla-cms/issues/9534 noch keine Lösung ab.


    Chris Davenport (nicht ganz unbekannt bei Joomla) hat sich Datenbankauszüge zusenden lassen, nachdem seine Tipps alle nicht funktionierten. Wirst also vermutlich warten müssen, bis er das gesichtet hat.
    Es ist nie schlecht, auf GitHub kurz zu bestätigen, dass du das selbe Problem hast

    Mit der JCE Mediabox kann man ein PopUp mit der Fremdseite öffnen, indem man dem A-Tag die Klasse jcepopup hinzufügt.
    Find ich nicht mehr ganz zeitgemäß die Lösung, da auf kleinen Mobilgeräten viel Platz verschwendet wird.


    Die _blank-Methode läuft unter "schlechter Stil" (nicht nur) bezüglich Barrierefreiheit (Accessibility). Von der im neuem Fenster/Tab geöffneten Seite kann durch den Backbutton nicht zurückgeblättert werden. Man dreht das Problem also nur um. Die, die lieber mit Back navigieren sind hier dann die Gelackmeierten.


    Dem mündigen Internet-User sollte es schon selbst überlassen bleiben, ob er zurück will oder nicht oder ein neues Fenster/Tab bei Klick öffnet. Gibt Seuche-Seiten, da hat man am Ende 20 Tabs offen und die vermeintlich bessere Orientierung ist komplett dahin.

    Frontend wie Backend.


    Bzgl. Validierung einfach mal in XML, z.B. Kontaktformular oder Registrierung schauen als Ansatz.
    Generell unterscheidet Joomla zwischen clientseitiger Validierung (Fehler über Formular VOR absenden/neu laden der Seite) und serverseitiger (Fehlermeldungen durch PHP nach Absenden).
    Auch da hatte ich mal was in den Docs gefunden, aber auch da nicht ganz klar, was nun outdatet ist oder nicht.
    EDIT: Weiteree Stichworte: Eigene Rules bzw. addrulepath



    Eingereichte Klarstellungen im docs wurden mir mehrfach trotz Richtigkeit abgeblockt, weil man daran festhält, auch olle Kamellen (1.5, 2.5) drin zu behalten und Helfern abverlangt wird, das auf gemischten Seiten nachzurecherchieren, für welche Version was gilt. Zu Thema Validierung und eigene Rules (für serverseitig), wo ich paar Stunden im 3er-Core rumgewühlt hatte, was Joomla denn schon drin hat und was nun wirklich aktuell und "modern" ist, hatte ich bzgl. docs keine Lust mehr UND finde im Moment meine Notizen leider nicht mehr. Fange also beim nächsten mal wieder an ;-)

    Nachtrag. Hier scheint sich eine Lösung für meine Frage oben zu ergeben

    Zitat

    Muss jetzt jeder programmierer vor Updates, die die Datenbank betreffen auch noch irgendwelche, komplexeren Prüfungen der DB-fähigkeiten ausführen bevor man sein Installer-/Update-SQL "drüberbügelt"?


    Wenn sich der PR durchsetzt, übernimmt Joomla bei Installation/Updates die Prüfung auf utfmb4-tauglichkeit. Man kann seiner eigenen Erweiterung für Install / Updates SQL-Scripte beilegen, welche für utf8 und welche für utf8mb4, die dann entsprechend gezogen werden.
    Ob das noch in 3.5.0 Einzug finden wird, ist allerdings unklar. Weil ja eigentlich schon "geschlossen"; außer Bugfixing.


    https://github.com/joomla/joomla-cms/pull/9468

    @89hf4edc
    Falsch ist das, was ich schreibe, in , nenn ich mal: unüblichen, Serverumgebungen. Diese nennt TE bisher nicht.


    Wir sind in einem Joomla-Forum mit weitestgehend Fragenden, die ihre Seiten in üblichen Provider-Umfeldern betreiben, also teile ich erst mal die auf den allermeisten funktionierenden Empfehlungen seitens Joomlamachern mit. 644, 755, CGI. Im Normallfall werden die Rechte von FTP-Clients auch so gesetzt. Wissen wir bei TE aber nicht.


    Anfragen wie diese gibt es sehr häufig. Wenn configuration.php, htaccess passt, läuft es in 99,9[periode] der Fälle auf CGI hinaus, um Schreibrechte-Konflikte in Sekunden bis 1 Minute loszuwerden (Klick oder Konfigurationszeile). In Unkenntnis des Providers, kann man dazu nur Tipp geben, Provider gezielt nach CGI zu fragen, bspw. um zu erfahren, ob CGI für jede Domain separat aktiviert wird oder nicht.


    Bevor man also ellenlang Benutzerrechte diskutiert (wie schon so oft), TEs auffordert diese zu sichten, mitzuteilen, an diesen gar rumzuspielen, chown-Befehle auszuführen und sonstigen, vielleicht sogar aus Hilflosigkeit gefährlichen Kram vorchlägt, weil der eigene Server anders konfiguriert ist, sie mit nicht relevanten Details zuquaselt, wozu ich auch neige ;-) , sollte man schrittweise erst mal das Einfache von vorne nach hinten abhaken.


    Dazu liefert der TE aber auch zu wenige Details: Provider? Subdomain oder Zugang via Domain + angehängtem Ordner? Systeminformationen aus Joomla-Backend rauskopiert, sowohl der Hauptseite als auch der Testseite.


    Nebenbei weiß ich aus jahrelanger Arbeit damit wie man Server, nicht nur rechtemäßig, kaputtkonfigurieren kann und die Arbeit damit kompliziert gestalten kann ;-) Ist ja auch hilfreich bzgl. Lernens ("bin diesbzgl. nicht ganz doof") und Erkenntnis, dass man im Detail bei scheinbarer Fehlkonfiguration lieber Profis dranlässt, bevor man wild selbst loslegt.

    Frag beim Provider wie CGI aktiviert wird, prüfe dann, ob es für die Testdomain ebenfalls aktiviert ist. Ohne ist Joomla nahezu Unsinn.
    Könnte z.B. sein, dass das über htaccess geht und hier was fehlt..


    Dateien sollten Rechte 644 haben, Ordner 755.


    Beachte, dass sich Einstellungen der htaccess-Dateien nach unten vererben können. Besser fährst du also mit parallelen Ordnern und Subdoamin statt Unterordnern der Hauptdomain. Subdomain, falls du das noch nicht gemacht hast.

    Umgeschrieben muss nur dann, wenn die Erweiterungen MySql-Querabfragen machen von Tabellen zu Tabellen bzw. genauer: Tabellenfeldern, bei denen die Kollation (Collation) nicht übereinstimmt, besser: wo sie nicht kompatibel ist UND es zu SQL-Fehlermeldungen kommt.
    Also bei den JOINs.


    Das kommt nicht häufig vor, dass nicht kompatibel, aber kann passieren.


    In den allermeisten Fällen kann man also unbesorgt sein und alles wird funktionieren wie zuvor.


    Beachten sollte man halt, dass nun auch mehr und mehr 3rd-Erweiterungen umstellen werden. Eigene Erweiterungen, wie Plugins, Module etc., die ihre Daten aus diesen oder mehreren beziehen (zusammenführen), könnten also irgendwann mal betroffen sein.


    Bis hier: Soweit ich bisher durchblicke. Muss sich bei mir auch erst mal alles setzen, bevor ich da anfange. Außer eine Fehlermeldung schlägt auf.


    (In den 3.5 Beta und RC installiere ich viele 3.4-Erweiterungen querbeet. Aufgefallen ist mir bisher nichts außer bei einer eigenen, die sowieso Pillepalle ist.)

    Danke. Ja, werd ich machen. Bin schon kirre vom Updaten ;-) und Mitlesen
    Hab halt kein MySql 5.1 zum Testen. Ignorier ich also plump weg.


    Hab auch bei Kunena auf GitHub ein Prozedere gefunden wie man 3rd-Tabellen anpassen kann. (Find den PR grad leider nicht mehr). Die setzten die Indices auch auf Grö0e 191 runter. Werd ich dann auch so machen. Denke mal, das hat positiven Effekt auf reservierte Speichergröße für die Felder.