Beiträge von Re:Later

    Haben mich aber leider nicht weiter gebracht, steh also noch am Anfang.

    In Zeile 3 deines Bildes findest du Pfad zur defekten index.php-Datei deines Templates ashton. Und die Zeile, wo der Fehler ist.


    In der Zeile steht wahrscheinlich auch dieses Fragment, dieser Teil

    Code
    1. JSite::getMenu()

    und exakt den Code-Fitzel, nicht mehr und nicht weniger der Zeile, tauscht aus gegen

    Code
    1. JFactory::getApplication()->getMenu()

    Das wurde aber tatsächlich schon gefühlte 100x in den letzten Wochen in den Joomla-Foren besprochen und sonstwo ;-)

    Ich habe die Seite wohl gefunden. Es handelt sich um eine Suchindex-Suche, die ich da sehe, also nicht com_search, sondern com_finder.


    Damit sind natürlich nur die Einstellungen in dieser Komponente relevant und search-Plugins komplett Bohne.

    Und da die ihre eigene, vollkommen undurschaubare Logik hat, bin ich mal raus hier. Weiß nur, dass man Faktoren vergeben kann, was nun relevanter ist als anderes.

    Das Erste, was ins Auge sticht, ist die JavaScript-Meldung:

    Zitat

    Error: Bootstrap's JavaScript requires jQuery version 1.9.1 or higher, but lower than version 3

    Deine Seite lädt JQuery 3.1.0. Warum? Jedenfalls zu hoch für normales Joomla 3. Reicht nicht das joomlaeigene JQuery?

    Code
    1. https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js

    In Folge dann Haufen JS-Features, die Fehler werfen und nicht funktionieren.


    Um das zu testen, musst aber aus der "komischen" Frameumgebung rausgehen, die du mir geschickt hast und die richtige Seite mit dem relaunch im Namen durchsehen.

    Im HEAD ist das wohl das System-Plugin JQueryEasy. Fraglich, ob du das unter Joomla 3 überhaupt brauchst.


    Jedenfalls solltest du prüfen, ob aktuell und in den Einstellungen mal rumschauen. Man sollte jedenfalls einstellen können, dass JQuery und weitere, falls aktiviert, aus dem Joomla-Framework geladen wird und nicht von extern.


    (Gab zumindest früher auch eine Einstellung, welches Protokoll verwendet wird, aber, wenn du das Framework wählst, statt extern, sollte das hinfällig sein.)

    googleapis

    Such mal in den Dateien und Datenbank NUR danach.


    Deaktiviere schrittweise Plugins, Module, andere Erweiterungen, die als "Autor" nicht "Joomla! Project" haben. Wenn's eine neuere Seite ist sind das Erweiterungen mit einer ID > 10.000.


    Leider ist die betr. Seite derzeit nicht zu erreichen.

    Man darf davon ausgehen, dass das Modul, vermutlich im helper, wo die $list zusammengestellt wird, eben eine Funktion verwendet, die HTML-Tags entfernt, bevor dann der Text gekürzt wird. Das ist das übliche Vorgehen bei (nicht nur) Modulen, die eben Text kürzen.


    Wenn z.B. ein Text auf 20 Zeichen gekürzt werden soll, dann ist es natürlich Nonsens ein

    Code
    1. <p>Hallo Welt, <span class="leuteheute">heute gibt es Butter auf die Fische</span></p>

    zu kürzen, weil invalides HTML rauskäme, was dir das Markup der kompletten Seite zerstört

    Code
    1. <p>Hallo Welt, <span

    Also entfernt man erst die HTML-Tags, damit rauskommt

    Code
    1. Hallo Welt, heute gi...

    Vielleicht auch, je nach verwendeter Truncate-Funktion

    Code
    1. Hallo Welt, heute gibt...

    Einige Module manipulieren im helper direkt das $item->introtext. Andere sind netter und generieren eine neue gekürzte Eigenschaft, so in der Art $item->displayIntrotext.


    Können wir nicht wissen, wenn das Modul kostenpflichtig ist.


    Was das soll, versteh ich übrigens gar nicht. Das echo natürlich, aber warum diese Zuweisung, dass man jetzt auch noch den fulltext "kaputt macht"?

    echo $item->fulltext = $item->introtext;

    Du wählst als Menüeintrags-Typ "Beiträge" > "Haupteinträge" (oder heißt's Hauptbeiträge?). Die Sortierung stellst auf "Reihenfolge Haupteinträge".


    Jeden Beitrag kannst du als Haupteintrag markieren. Unter Menü Inhalt > Haupteinträge kannst dann diese sortieren.

    Ich hab mir unterdessen sagen lassen, dass ich das Problem den Änderungen in PHP mit der 3.9.1 Version wohl verdanke!

    Da müsstest du die Quelle mal posten, bitte. Wüsste nicht, dass sich in com_search da was geändert hat. Diese Suche wid aber in Joomla 4 ersatzlos gestrichen. Nur als Hinweis. Wäre also der Hinweis von j!-n vielleicht nicht ganz falsch, auf die com_finder-Suche (= Suchindex) umzustellen, auch, wenn die sehr datenbankbelastend arbeitet. Für Popel-Provider-Pakete also vielleicht nicht ganz geegnet.


    Das einzige, was in com_search geändert wurde, ist, dass, wenn ein Suchwort im Titel vorkommt, der Treffer dann höher sortiert wird. Kann nat. sein, dass sich da ein Fehler eingeschlichen hat.


    com_search ist tatsächlich nie besonders trickig gewesen. Nur nebenbei.


    In der Suche hat man ja ein Feld "Anzahl Suchtreffer pro Seite". Bist sicher, dass die Beiträge nicht auf hinteren Seiten stehen?


    Im Menüeintrag kann man die Sortierung einstellen. Weiters einstellen, ob man weitere Filterfelder im Frontend anzeigen lässt. Mit denen würde ich mal rumprobieren, ob die Beiträge tatsächlich gar nicht erscheinen.


    Deaktiviere mal testweise alle anderen search-Plugins, außer das für Beiträge. Noch mal probieren, ob da der Hund begraben liegt.

    Und sortiere sie mal um. Ob das eine Auswirkug hat auf die Reihenfolge der Treffer aus den verschiedenen bereichen.