Installiere/aktiviere es und tausche com_phocagallery gegen com_eventsbooking, wenn du meinst. Siehste dann ja, was rauskommt und, wenn was rauskommt, wo. Vielleicht muss man es dann noch in den Plugins an letzte Stelle sortieren, weil man nicht weiß, was EventsBooking noch so treibt. Aber ????
Download hier
https://github.com/GHSVS-de/plg_system_noindex4pg/releasesUnter Joomla 5 tut es bei einer Testseite zumindest noch, was es soll, wenn ich com_content im Code einsetze.
Falls also jemand grundsätzlich eine kreative Idee hat,
Schon: So was in der Art: https://github.com/GHSVS-de/pl…lob/master/noindex4pg.php
Aber das wird dir nicht viel helfen und ich habe doch keine Ahnung von deiner Seite und einer Pro-Erweiterung, die sich hinter einem Ticketsystem versteckt, welche Parameter man ergänzen müsste, um die Events mit einem noindex,nofollow auszeichnen müsste 
Meiner Meinung nach eine saubere htaccess
Aber mindestens mal nicht ausreichend für die Option in Joomla, falls das wirklich die gesamte htaccess sein soll., die du da postest
Steigt die Seite auch aus, wenn du die Joomla-Konfiguration erst mal auf NEIN lässt?
Kann man es im Backend unter Erweiterungen > Verwalten finden?
Kann man es im Backend unter Erweiterungen > Überprüfen finden? (Nicht installieren klicken, wenn du unsicher bist, ob das nicht ein Hack ist!)
Gibt es unter Update-Quellen einen Eintrag? Wie lautet die XML-Datei dazu?
Gibt es einen Datenbankeintrag in Tabelle _extensions?
Hoster reklamieren ja normalerweise nicht ganze Ordner, sondern geben an welche Dateien(???).
Ich finde im Netz 2 unterschiedliche Erweiterungen mit diesem Namen. Wenn du per FTP NUR(!!!) die XML-Datei im Ordner herunterlädst bzw. öffnest, was steht im Kopfbereich der Datei, wo ja normalerweise auch die AUtoren, Version etc.pp. genannt werden.
und liegen auf dem gleichen Server
Da ist es, wenn es denn ein Hack sein sollte, gelegentlich möglich, dass sich Seiten gegenseitig infizieren. Aber nur so erwähnt, weil nix genaues weiß man ja nicht.
Dann gönne ich mir den Spaß, benenne es um und komprimiere es zu diesem hier:
Damit hat die ZIP-Datei selbst eine andere Checksumme. Und damit wird deine Meldung klar. Dein Entpacken, neu packen ist mir ein Rätsel, aber ich habe nicht alles gelesen.
Uuund, so Erweiterungen lassen sich viel einfacher deinstallieren (soweit man überhaupt darf), nachdem sie ordentlich installiert wurden.
Das hängt auch von der Bildschirmbreite ab, ob das static offensichtlich ist.
Hier zur O>rientierung: https://blog.astrid-guenther.d…peia-statisch-oder-fluid/
(Das einzige, was nicht so gaaanz stimmt: "Das Stylesheet von template.css gibt Stile für diese Klasse [.wrapper-static] vor."
Die CSS-Klasse kommt in der CSS-Datei gar nicht vor.)
Auf einem 1960-Bildschirm sehe ich deutlich, dass der Bereich auf 1300 oder so begrenzt wird.
Na, dann installiere die Sprachen doch neu. Es geht ja NICHT um die Inhaltssprachen, sondern wohl links nur um die Sprachpakete (?)
Dann in die Inhaltssprachen. Sprache öffnen und prüfen, ob eine Grafik unter "Bild" zugeordnet ist und das Bild auch angezeigt wird
Mache ein Häkchen vor die Erweiterung und klicke installieren.
Gehe die Erweiterungen eine nach der anderen durch. Nicht alle auf einmal.
Vorher zur Sicherheit ein Backup.
Hinterher kannst dann unter Erweiterungen > Verwalten oder unter Plugins durchgehen, ob die wirklich aktiviert sein müssen. Die Beispieldaten z.B. wird man nicht brauchen...
Hat jemand damit Erfahrung. Bzw. hat den bei sich installiert?
Schon irgendwie, weil ich halt ein eLTS bezahlt habe, aber ich denke, wenn, dann sollte man SniperSister fragen, ob er den auch ohne Subskription rausrücken will, den Fix. Anders wäre unfair.
Was sagt denn die Ecke System (Dashboard) > Installieren > Überprüfen ?
Manchmal: Leere das tmp/-Verzeichnis (je nachdem, wo es bei dir ist). Probiere erneut.
Ist das eine Frage oder nur ein Hinweis für Leute, die bei one.com hosten??
Weil das Problem ist lange bekannt, die Lösung auch, sowie, dass man die nach fast jedem Update wieder einsetzen muss, die blöde Zeile.
Ein ewiges Rätsel bleibt, warum one.com seine Datenbankserver jetzt nicht endlich mal korrekt konfiguriert bzw. richtiger: warum one.com nicht endlich die veraltete Konfigurationszeile entfernt, die ursächlich für das Problem bei denen ist.
Andere Hoster haben das ja mittlerweile auch hinbekommen und man braucht den dummen Fix nur noch selten.
Ja, die Meldungen sind teils recht alt, die da noch auftauchen. Prüfen tun die nix. Geben nur in DB hinterlegten, festen Text aus und lassen sich deswegen ein-/aus-blenden.
Es kommt doch darauf an, wie diese Webseiten im Hintergrund aussehen, um zu beurteilen, ob das Ergebnis brauchbar ist oder eben nur eine Webseite, bei der man z.B. technisch Vieles effizienter machen könnte.
KI-betriebene Robotoren können vermutlich autark ein Auto aufgrund gesammelter Erfahrungen des letzten Jahrzehnts bauen. Will man da einsteigen und losfahren oder es gar kaufen, weil es KI-generiert ist? Ich mal nicht.
Ich habe via Mastodon die letzten Tage bestimmt 10 Links mit mehr oder weniger fundiertem Geschwafel gelesen, was KI angeblich leisten kann, könnte oder wollen werden würde. Bis hin zu sorry: "verblödeten" Politikern, die keinen Ansatz einer Ahnung haben, wovon sie reden, wenn sie z.B. ihnen anvertraute Menschen an KI-Systeme zur weiteren Bewertung übergeben wollen. Nahles träumt bspw. von 60% Arbeitsersparnis im Arbeitsamt, weil ihr das so verkauft wurde, von Leuten, die scharf auf Aufträge sind.
Uns werden täglich KI-generierter Schrott (bis hin zu "Nachrichtentexten") und schlecht zusammengeschusterte Plagiate untergejubelt. Bis hin zu effekthaschenden Bildern, die einen an den schlechten Geschmack der 80er/90er eriinnern. Dieser ganze Trial&Error-Zufalls-Müll, weil die, die vor dem Rechner sitzen, geblendet sind von den Ergebnissen, die nicht auf eigenen Ideen basieren, die mittels digitaler Hilfe ausgearbeitet wurden. Oder Bücher mit tatsächlich gefährlichen Inhalten bis hin zu giftigen Pilzgerichten oder zusammengebastelten Texten, die man nicht lesen mag, weil pure Zeitverschwendung.
Das kann KI derzeit, wenn man es alleine machen lässt, ohne Plan und Vorbereitung.
Genau. Das ist jedenfalls immer die Basis.
Falls du in der Vergangenheit die .htaccess oder robots.txt speziell angepasst hast und die Änderungen wichtig waren, dann musst die Änderungen von der alten in die neue übernehmen.
Je nach Hoster ist es dann eventuell nötig, einzelne Zeilen zu deaktivieren oder Blöcke zu entfernen, aber das siehst dann schon und meldest dich halt noch mal.
Wenn das beim Speichern von Beiträgen passiert, prüfe die AddOns Deines verwendeten Browsers.
Sichere die alte .htaccess und robots.txt auf deinem Rechner.
Ersetze sie online durch die htaccess.txt und robots.txt.dist (natürlich dann umbenannt).
Die configuration.php lasse wie sie ist.
tmp-Verzeichnis. Keine Ahnung. In 99,999% der Fälle ist die Warnung komplett unnötig. Eine php.ini, .php.ini oder .user.ini oder ... ist ja auch per se nicht da, sondern man legt ggf. eine an. Da musst den Hoster fragen, welche bei dir nun die richtige ist. Manchmal läuft das nämlich immer noch über .htaccess. Manchmal geht auch gar keine.
Mich verwirrt, dass zB in meiner .htaccess immer noch das Jahr 2005 steht.
Weil man sich zurecht darauf geeinigt hat, dass beim Copyright das Startjahr entscheidend ist, auch, weil man sonst bei jedem Jahreswechsel ALLE Dateien des Joomla-Cores entsprechend überarbeiten müsste, was Dateiabgleiche übrigens zur Hölle macht.
Nur ein kleiner Nebenbeikommentar.
Ich bekomme heute folgende Email, aus der klar wird, wie bescheurt die Denke von G aus Sicht von Usern ist: "Indexiert, obwohl durch robots.txt-Datei blockiert". Nebenbei habe ich an dieser robots.txt schon seit > 1 Jahr nichts mehr geändert.
Die angeblich aktuell betroffene URL
https://ghsvs.de/component/content/category?layout=protostarbs3ghsvs:wookghsvs&Itemid=644und an der sehe ich, dass die aus frühesten Joomla-3-Zeiten stammt und schon laaaaaange joomlaseitig auf eine 404-Seite führt, laaaange nicht mehr bei mir auftaucht und laaange zusätzlich per robots.txt (Disallow: /component/content/) und einem eigenen Plugin unzugänglich wäre, sogar mit einem 405, wenn es sie denn gäbe
Und entfernt habe ich sie auch schon desöfteren in der Console. Kommt halt immer wieder.
Einzige Möglichkeit wäre also Disallow: /component/content/ aus der robots.txt zu entfernen, Aufrufe radikal ins Leere laufen lassen, abzuwarten, bis auch Google das kapiert UND diverse andere Aufrufe, die G im Jahre 1888 mal gesammelt hat über längere Zeit zu kontrollieren, ob die jetzt blöderweise wieder mit irgendwas Inhalt aufrufbar sind; ohne 404 oder 405.
Das mentale Problem, dass ich damit habe, ist, dass Google die weiterhin, ungewiss ob mit Inhalten oder nicht, beharrlich behält. Und natürlich diese bescheuerten Formulierungen, die auch Kunden immer wieder veranlasst bei mir rückzufragen, was da für eine Katastrophe passiert ist. In meiner Console ist das dann so formuliert, dass diese gesperrte URL meinen Suchergebnissen schaden könnte.
Wenn der Provider keine On-the-Fly-Änderungen erlaubt, hilft vermutlich nur, in der Joomla-Konfiguration "Fehler berichten" zu deaktivieren, was eh nicht falsch ist.