Beiträge von Re:Later

Wenn du Probleme mit einem frischen Joomla 3.8.12 unter PHP 7.2 hast und KEINEN Software-Installer des Providers verwendest, sondern ein von offizieller Quelle heruntergeladenes, in einem zuvor leeren Verzeichnis (kein Unterordner einer bestehenden Installation) und neuer Datenbank, solltest du dich an die beteiligten Provider wenden und dich nicht abwimmeln lassen mit "Das liegt an Joomla". Liegt es nicht.

Ja, stimmt schon. Ich bin halt System-Plugin-"Fan", weil die früher geladen werden und weitere Methoden anbieten, die VIELLEICHT noch interessant sein könnten. Man kann so z.B. die Pfade zu eigenen Feldern, eigenen XML, die das Plugin vielleicht verwaltet, frühzeitig systemweit bekannt machen und ähnliche Spielereien oder auch Prüfungen auf existierende Tabellen und Kram. Aber da denke ich vielleicht immer zu groß An TE-n vorbei...

https://www.google.com/search?q=Joomla+1.5+Cookie+Hint

Scheinen zumindest laut Kurzbeschreibung noch welche dabei zu sein.

Ich glaube, es geht darum, dass bei Installation und Verwendung des Moduls (was ja eigentlich nur Beiwerk ist) auf einem anderen Joomla erst die Artikelfelder eingerichtet werden müssen, damit das Modul überhaupt funktionieren kann.

Weiß nicht, ob Module Installations-script.php und SQL-Dateien unterstützen. Das wäre dann eine etwas komplexere Angelegenheit, mehr wegen des Prüfens, ob Felder schon angelegt wurden und wegen Abhängigkeit von diesem "Advanced Custom Fields" (von dem ich nicht weiß, wie es arbeitet. Leider muss man sich registrieren.).

Wenn das so gemeint ist wie Satz 1, hätte ich eher mit einem eigenen System-Plugin als Dreh-und ANgelpunkt begonnen, vielleicht sogar ganz old-fashioned (in Artikel-params-Feld schreiben) oder mit eigener DB-Tabelle, wenn die Datenmenge zu groß wird oder eben auch ein Modul schnell abfragen können soll.

Weil auch so kann man eigene Felder, auch via XML-Dateien, in Artikeln (Formularen) hinzuzaubern (EDIT: Und speichern, wenn man eigene DB-Tabelle verwenden will). In den Grafiken sehe ich nichts, was man nicht mit althergebrachten Joomla-Standard-Feldern abwickeln kann. Und mit etwas Trainig und Abspicken kann so ein Plugin ebenso eigene oder "geklaute" Formulare-Felder bereit stellen, die man in den XMLen verwendet.

Mit der Module-Manifest-XML kommst du nicht weiter. Die hat einen anderen Zweck

Auch, wenn man das alles noch etwas beobachten muss, bevor man Legenden verbreitet, eine schüchterne Theorie (nicht nur von mir):

Es kann AUCH mit dem derzeit erfolgendem Umstellen aller Seiten auf Mobile-First-Indexing zu tun haben. Zwar äußert sich da Google nicht so explizit in seinen Nachrichten, aber beim radikalen Umstellen auf mobiles Indexing treten natürlich auch mobile Faktoren für das Ranking mehr in den Vordergrund, z.B. PageSpeed. Zusätzlich kann man nat. erwarten, dass "Usability" bzw. "akademisch" berechnete, mobile Nutzererfahrung einen Einfluss haben könnten.

Vielleicht gibt dir die Google SearchConsole etwas Auskunft, ob du im Mobile- und Desktop-Bereich über die letzten und kommenden Wochen gleichermaßen Einbrüche seit den Umstellungen beobachten kannst.

Ich sehe da z.B. schräge Phänomene, dass es bei 2 Seiten mobil schon immer zwar ein weitaus höheres Ranking (durschnittliche Position der Impressionen pro Suchworte-Kombination) gibt, trotzdem die Anzahl der Impressionen mobil weitaus niedriger ist, als für Desktop-Suche. Im Desktop-Bereich ist die Klickrate aber sehr stark seit Umstellung auf Mobile-First angestiegen. Der Teufel mit viel Zeit zum Forschen weiß es... Kann auch einfach mit der unterscheidlichen Darstellung der Google-Suchergebnisse zu tun haben.

In einer Frontend-CSS-Datei, die auf dieser ARtikel-Bearbeitungs-Seite geladen wird, so etwas in der Art:

#sp-component div.edit.item-page{
    max-width:500px;
}

harry-bo

Mit Version Joomla 3.9 wird dieses Feature im Core eingeführt. Man kann dann sowohl die Einleitungsbilder als auch die Beitragsbilder der Beiträge per Backend-Option im Modul mod_articles_news aktivieren/anzeigen lassen.

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

Zuerst prüft man die Einstellungen in der configuration.php.

Datenbankdaten.

tmp und log-Pfad zeigen auf den neuen Ordner? Vergisst ma nämlich leicht und so lange der alte noch da ist, hat Joomla auch nix zu meckern.

Das Drüberkopieren war schon richtig. Dabei war johann aber ein kleiner Fehler passiert, was man durch Vergleich zweier Backups halbwegs zügig rausbekommen konnte. ZUM GLÜCK GAB ES NOCH EIN ÄLTERES (das an alle, die zu selten Backups machen ).

Läuft wieder durch erneutes vollständiges "Drüberbügeln" und entfernen von falsch hochgeladenen Ordnern.

PowerAdmin kann in diesem Fall nicht deaktiviert werden wie oben von mir plump empfohlen. Es handelt sich um eine PRO-Version mit diversen Abhängigkeiten.

Was allerdings PowerAdmin zum Kollaps brachte, bleibt offen.

Ich geh mal davon aus, dass dieses unsägliche JSN PowerAdmin 2 installiert ist. Wäre nicht die erste Seite...

Jedenfalls deaktiviert das das von joomlawunder genannte Modul und mischt sich weiters in jeden Sch... im Backend ein.

In der Datenbank wären das diese beiden Erweiterungen in der Tabelle "xyz_extensions", wo du Spalte enabled auf 0 setzen musst. Sollte danach das Menü gänzlich verschwunden sein, sind wir vermutlich auf dem richtigen Weg und man muss dann noch ein bisschen in der DB rumpopeln wie JoomlaWunder ja schon angedeutet hat .

Zitat von johann

Die Option Datenbank reparieren habe ich gar nicht.

Gib im Browser ein

example.org/administrator/index.php?option=com_installer&task=database.fix

example.org natürlich bei dir deine Webadresse.

Wenn du damit meinst, die Seite läuft zukünftig eh nur noch in deutsch:

- Daektiviere die Sprachplugins.

- Prüfe deine Kategorien, Menüeinträge, Beiträge, Module auf Sprach-Einstellungen anders als "Alle".

- Und wennst willst kannst unter Sprachen > Inhaltssprachen die englische deaktivieren.

- Unter Sprachen > Installiert, deutsch als Standardsprache fürs Frontend (Site).

Wenn ich in den Seitenquelltext schaue, sieht man keine Untermenüeinträge

Zitat von Stewa88

ich habe Kategorien definiert

Weil "Kategorien" nicht gleich Menüs sind, frag ich zur Sicherheit noch mal: Du hast auch UnterMENÜEinträge angelegt?

Wenn ja, sieht das für mich so aus, als hättest du

- "Untermenüeinträge anzeigen" nicht auf JA im Modul.

- oder" Letzte Ebene" nicht auf ALLE im Modul.

- oder die Untermenüeinträge haben keine öffentliche Zugriffsebenen

Zeig mal einen Screenshot deiner Menüs (also die Übersicht/Liste der Menüeinträge) und von den Moduleinstellungen.

Zitat von Mister.X

Hier kann ich die Argumentation nicht nachvollziehen.

War ja auch keine Argumentation. Wollte es nur wissen, da ich eben Menüüberschriften nur mit Public verwende und das seit Jahren ohne Probleme.

Hab gestern auch noch gerätselt und ich glaube der Hund liegt begraben bei den unterschiedlichen Rechten der Menüeinträge(????)

Zitat von Mister.X

Bemerkung: Zugriffsberechtigungen sind entsprechend gesetzt und auch der anschauende Nutzer hat die richtigen Zugriffsberechtigungen!

Generell wäre also interessant, ob es auch bei Alles-Public-Einträgen nicht funktioniert.

Die angebotenen npm:css und ähnliche haben gewisse Nachteile beim Einsatz "für die tägliche Arbeit", weil sie das komplette Joomla im Hauruck-Verfahren durchlaufen, also ohne Schnitzerei und Konsolegetue nicht nur eine einzelne CSS neu kompilieren, sondern mindestens Backend und Frontendtemplate. Man muss also wissen, was man wie und wo tut. Ein unbedachter Start kann verheerende Auswirkungen haben in einer Umgebung, die einem wichtig ist, in der schon viel Arbeit steckt.

Der Ansatz geht in die Richtung den "Joomla-Machern" die Pflegearbeit zu erleichtern (ist ja OK!!), aber eben nicht "normalen" Usern.

Deine eigentliche Frage:

Aber es gibt in Joomla 4 die neue Komponente com_csp, die wie zero24 klar stellte, eigentlich nicht dafür gedacht ist, aber bei meinen ersten versuchen, gelang es mir damit, Zugriffe auf bestimmte CDNs komplett zu verhindern, darunter auch die relevanten für die Google-Fonts, die die Erweiterung sammelt und recht leicht identifizierbar macht.

Weiß nicht mehr, wo sich das hier im Forum findet, wo ich kurz beschreibe wie. Glaub es ging auch mit dem jetzt schon verfügbaren plg_system_httpheaders in Joomla 3. Überblick verloren...

Wie drüben im "alten Thread" schon erwähnt, ist dir das in Joomla 4 zahlreich verbaut. Zumindest zum jetzigen Stand.

Die min wird automatisch geladen, wannimmer im Ordner vorhanden, sowohl css als auch js. Einen Schalter, auch codeseitig, das zu verhindern, habe ich noch nicht gefunden. Soll mich wer korrigieren, wenn das nicht (mehr) der Fall ist oder ich schon immer was übersehe. Man muss also die min stilllegen, damit die template.css geladen wird. Oder die template.css nach Bearbeitung selber minifizieren. Ginge z.B. mit Koala. Es gibt auch ein Minifizierer-Joomla-Plugin von mir, von dem ich aber noch nicht weiß, ob geeignet für J4.

Die SCSS/SASS-Dateien sind nicht fehlerfrei nutzbar, wenn du ein fertig gebautes Joomla-Paket verwendest. Eigentlich die richtige Stelle, wenn man die Einarbeitung nicht scheut, die bei anfänglich kleineren Änderungen nicht so Drama wäre. Soooo schwer ist das eigentlich nicht, aber in Casseiopaia einfacher Einstieg eben verbaut. Die Kompilierung UND Minimierung funktioniert auch mit dem oft zitiertem "npm:css" nicht, da Dateien fehlen.

Im "alten Thread" drüben habe ich das Tutorial von firstlady genannt, mit diesem wäre es möglich, auch nachträglich noch mal die npm-Befehle für css und js nach Änderungen laufen zu lassen, wenn man also mit dem unvollständigen Paket von GitHub beginnt und nicht ein komplettes "build" laufen lässt, aber ebenfalls mit Stolpersteinen und nicht über ein schon normal installiertes Joomla 4, ohne diverse Ordner dort nachzurüsten oder Dateien von dort nach dort rumzukopieren.

Nach (meinem) derzeitigem Stand ist "einzig und allein benutzerfreundlich" die zusätzliche user.css zu verwenden. Alle anderen Wege brauchen wohl weitere Tutorials, für die es aber derzeit zu früh ist. Oder noch besser, gleich andere, autarke Templates.

Zitat von chr-hl

Vielleicht kann mir Jemand auch einen Tipp zum Thema LESS/SASS geben

SASS/SCSS war hier Thema.

https://github.com/joomla/joomla-cms/issues/22325

Es wurden Dateien verschoben, die ein Arbeiten mit den Template-SCSS-Dateien unmöglich machen, ohne zusätzliche Kenntnisse, Dateigeschiebe und Pfadänderungen in SCSS-Dateien, wenn man ein Joomla 4 "wie ausgeliefert" verwendet, was wohl meistens der Fall sein wird. Was wir dort als Antwort erhalten haben, ist in Teilen nicht "richtig gedacht", sondern richtig ist, dass einzelne Dateien aus plumper Nerdigkeit nun eben schlicht fehlen und man somit als "normaler" User SCSS-Dateien out-of-the-box, egal welche Art man zum Kompilieren verwendet, nicht mehr fehlerfrei zu CSS kompilieren kann.

Mit Protostar/ISIS und LESS war das noch möglich, so wie Joomla die Dateien im fertigen Paket mitbrachte. Auch deswegen war eben Protostar so etwas wie ein gut geeignetes Lerntemplate, wenn man mal LESS ausprobieren wollte, was tatsächlich mit 2, 3 Zeilen Erklärung und 2 Minuten Arbeitsaufwand für die Einrichtung fehlerfrei möglich war, ohne, dass man sich um technischen und anderen Krimskrams kümmern musste.

Der Verweis auf user.css ist aus jenem Munde etwas enttäuschend für mich, da das eine zusätzliche Datei ist, die geladen werden muss, neben einer sowieso schon überdimensionierten template.css (die man jetzt eben nur noch auf Umwegen ausdünnen kann, wenn man die Stärken von SCSS/SASS und Bootstrap 4 nutzen will).

Zusätzlich zu dem Ganzen sind in den SCSS des "Standardtemplates" Sachen verwendet, die ein Kompilieren scheitern lassen, mit Compilern, die nicht die geringsten Probleme mit einem Original-Bootstrap-4-Paket haben.

Kurz: Stichwort Glaubenskrieg. Ich ergänze mal: "an Benutzern vorbei".

Browser-Cache gelöscht?