@Indigo66
Wo kann man dies wieder entfernen? Gibt es eine Art von Cache?
Beiträge von mg327
-
-
Hallo und schon mal vielen Dank für die Antworten. Leider benötigen wir das Plugin "System-Umleitung", sofern dies für die "suchmaschinen-freundlichen URL's" verantwortlich ist. Einen Menüpunkt "Suche" haben wir nicht, das ist ein Modul.
Wir haben mal exemplarisch ein paar Links mitgeschickt, wie schon gesagt, sind es mehrere Tausend, da sich die Kategorien beliebig "kombinieren" lassen.
Hier erst einmal der richtige Link zu einem der Berichte:
und nun drei zufällige falsche:Codehttp://www.testpraktiker.de/2-uncategorised/hund-katz/mobilitaet/fahrrad/telefon-mobiles/smartphones/haushalt-wohnen/testberichte-computer/lautsprecher/mobilitaet/fahrrad/testberichte-computer/speichermedien/haushalt-wohnen/198-testbericht-bruno-kaltschaummatratzen.html
Codehttp://www.testpraktiker.de/2-uncategorised/telefon-mobiles/smartphones/telefon-mobiles/smartphones/haushalt-wohnen/testberichte-computer/speichermedien/haushalt-wohnen/198-testbericht-bruno-kaltschaummatratzen.html
Codehttp://www.testpraktiker.de/2-uncategorised/wellness/fitnessgeraete/mobilitaet/fahrrad/haushalt-wohnen/telefon-mobiles/smartphones/testberichte-computer/speichermedien/testberichte-computer/speichermedien/haushalt-wohnen/198-testbericht-bruno-kaltschaummatratzen.html
Wie man leicht sieht, ergibt die Abfolge der Kategorien keinerlei Sinn, obwohl es jede davon tatsächlich gibt.
Es geht, wie schon eingangs beschrieben, mit jeder Kombination, wenn nur der Name des Beitrags am Ende korrekt ist und am Anfang eine Kategorie mit der zugehörigen ID steht.Außer in mühsamer Kleinarbeit alle ID-KATEGORIE-Kombinationen in der .htaccess auf die Startseite umzuleiten fällt uns nicht wirklich etwas ein. Die Seite ist bei Google angemeldet, nutzt Piwik und wird von Sistrix überprüft - wir konnten nirgends ein Problem feststellen. Die Datei mit den 3.600 (!) Beispielen, stammt von einem Kunden, die Links haben wir stichprobenartig geprüft und sie landen alle auf der selben Seite. Es ist eine Seite, die so nirgends existiert, nämlich die Startseite mit dem jeweiligen Beitrag. Alle Module gehören zur Startseite und keines der Module dieses Beitrags wird angezeigt.
Wir hoffen, daß war ausführlich genug und es gibt eine einfache Lösung.
-
Hallo,
wir bekamen heute eine Mitteilung, daß ein Link unserer Seite von mehreren tausend Unterseiten gesetzt sei. Zum Glück befand sich auch eine Liste dabei, die schnell ein System erkennen ließ. Alle Beiträge sind nach folgendem Muster erreichbar, wenn auch die anzuzeigenden Module immer zur Startseite gehören:
domain.xy/2-uncategorised/...[beliebige Anhäufung tatsächlicher Kategorien in beliebiger Reihenfolge].../[korrekter Beitrag]
"2-uncategorised" kann hier auch gegen jede "echte" Kategorie-Nr. und -Bezeichnung ausgetauscht werden. Das Ergebnis ist jedesmal eine korrekte Startseite mit dem entsprechenden Beitrag. In der Konfiguration wurden "suchmaschinenfreundliche URL's", "URL-Rewrite" und "Dateiendung" ausgewählt.
Eine Suche bei Google mit site: ergab keine Treffer dieser Art.Ist das ein normales Verhalten?
Wie kann man es ausschalten?
In leicht abgewandelter Form kommt es offenbar auf mehreren Seiten vor, nur daß hier gar kein Beitrag angezeigt wird. (Seiten mit https und ohne Dateiendung).Für eine Aufklärung und Beruhigung wären wir sehr dankbar.
-
Hallo,
kann man in einer Modulposition unterschiedliche Inhalte zeigen, abhängig davon, ob es ein angemeldeter Benutzer ist oder nicht?
Konkreter Fall:
Nur registrierte Benutzer sehen einen bestimmten Menüpunkt samt den Unterpunkten. Im Fußbereich gibt es zu jedem Hauptmenüpunkt ein Modul, welches die Unterpunkte anzeigt, natürlich wird der interne Punkt nicht angezeigt und die Position könnte wunderbar für das Login genutzt werden. Sobald der Benutzer aber angemeldet ist, wäre das Login ja überflüssig, aber stattdessen der Menüpunkt richtig Cool.
Geht das mit einfachen Mitteln? Falls es nur mit viel Aufwand möglich ist, packen wir das Login einfach an eine andere Position und zeigen den Menüpunkt eben nur dann an, wenn es sein soll.Danke schon mal
Michael -
Hurrah!!!
Es geht wieder, vielen Dank an alle.
Dank Eurer Tips konnten wir das Problem in den Domaineinstellungen des Serververwaltungstools i-mscp finden und korrigieren. Warum allerdings diese Domain neuerdings die PHP-Richtlinien nicht mehr ändern durfte, bleibt schleierhaft. Wir sind selbst der "Provider" und haben dies garantiert nicht absichtlich ausgeschaltet. Man muß es zwar absichtlich einschalten, wenn man eine neue Domain einrichtet, aber das liegt schon Jahre zurück und es lief ja. Einzige Erklärung, hier hat sich beim i-mscp Update ein Fehler eingeschlichen oder es war schlicht menschliches Versagen und wir meinten eine andere Domain (Zeile verrutscht o.ä.).
Ganz klar war uns jedenfalls, wo der Fehler zu suchen sei, als das einfache
funktionierte, das Nachladen einer Datei aber nicht. -
Guter Tip, aber leider auch eine Fahrkarte. Beide haben PHP 5.5.9, lediglich der Built ist beim V-Server ein paar Tage neuer (19.Mai zu 01.Juni) - daran wird es wohl nicht scheitern.
-
Danke für die Antwort, aber das haben wir alles schon durchprobiert. Wie gesagt, haben wir sogar die neuere Version installiert, aber ohne Erfolg. Aus Verzweiflung hatten wir es sogar komplett deinstalliert und dann neu installiert, alle Einstellungen verglichen und nichts gefunden.
Was wir oben vergessen hatten zu erwähnen ist, daß es gute drei Jahre lief ohne Probleme. Wann es genau ausfiel, können wir nicht sagen, da wir keine Meldungen von Seitenbesuchern hatten. Was wir wissen ist, vor einem Monat ging es noch, seit drei Tagen geht es nicht mehr. Alle Updates wurden immer auf beiden Seiten gemacht und stichprobenartig kontrolliert. Eigentlich hätte es uns auffallen müssen, es ist also sehr wahrscheinlich, daß es noch bis vor einer Woche lief. Danach wurde nur Akeeba und JCE upgedatet. -
Wir haben mal wieder ein sehr seltsames Phänomen. Ein mit Sourcerer eingebundenes Codeschnipsel funktioniert auf der Entwicklungsversion, jedoch nicht auf der richtigen Seite.
Beide Versionen liegen zwar auf unterschiedlichen Servern (Entwicklung ist ein V-Server, richtige Seite Root-Server), beide Server haben aber Ubuntu 14.04 als Betriebssystem und eigentlich sollten beide Seiten identisch sein. Hier die Links zum Problem:
Testversion:
http://vu2032.admin.asuncion.i…eagate-expansion-3tb.html
Richtige Seite:
http://www.testpraktiker.de/te…eagate-expansion-3tb.htmlEs geht um die Tabelle am Ende des Beitrages, hier soll die Liste von Schottenland erscheinen. In der Testversion ist das auch OK, in der richtigen Version nicht. Die Erweiterung Sourcerer läuft offenbar, denn wenn man den Namen des Tags verändert, wird der Code angezeigt. In der Originalversion haben wir die neueste Version installiert, weil wir glaubten, das Problem damit lösen zu können, es war aber vorher und nachher gleich. Andere Unterschiede sollte es hier nicht geben, was uns nun völlig im Trüben fischen läßt.
Das Problem bezieht sich auf alle Testberichte, in denen Schottenland eingebunden ist.Wir freuen uns auf Ideen, wo man noch suchen kann.
MichaelPS.: Diesmal haben wir den Adblocker wirklich ausgeschaltet und auch Rückmeldungen von Freunden, wo es auch nicht geht.
-
Hallo,
gut daß wir uns gegenseitig zurückhalten konnten, bevor wir mit dem Kopt gegen die Wand gerannt sind ...
Darauf soll man erst mal kommen - im Nachhinein völlig klar und etwas kurzsichtig vom Template Entwickler eine Position "advert" zu nennen.
Da sind wir voll drauf reingefallen. Wir hoffen nur, daß wir dadurch einigen anderen weiter helfen können.Fazit: Werbung ist voll sch... - Adblocker sind eigentlich super - Namen sollte man sorfältig wählen.
Wir werden die Positionen nun umbenennen, denn das Template ist wirklich gut.
Vielen Dank nochmal
Michael -
OK, das Argument zieht, wenn wir auch dachten hier sei etwas anders.
Die Seite lautete:
http://griese-gegend.de
Hier nochmal die ersten Zeilen vom Firebug zum schnelleren Finden:HTML
Alles anzeigen<!DOCTYPE html> <html class="no-js" lang="de-de" dir="ltr" xml:lang="de-de" xmlns="http://www.w3.org/1999/xhtml"> <head> <body> <div id="fav-containerwrap" class="clearfix"> <div class="container-fluid"> <div id="fav-container"> <div id="fav-advertwrap" class="container-fluid" style="display: none ! important;"> <div class="row-fluid"> <div id="fav-advert" class="span12" style="display: none ! important;"> </div> </div> <div id="fav-headerwrap" class="container-fluid">
Danke
Michael -
Wieso lustig? Wir haben doch gesagt, daß wir eine "Notlösung" gebaut haben, natürlich sieht man das Problem nun nicht mehr, weshalb wir die betreffenden Codestellen ja auch gepostet haben.
Also nochmal die Zusammenfassung von dem, was wir wissen:
1. Die beiden betroffenen DIV-Kontainer fav-advertwrap und fav-advert haben im Template-Code keinen Inline-Style, aber eine ID
2. Suchen in den betreffenden Verzeichnissen mit find und grep ergaben keinen Hinweis auf den Inline-Style. Wir haben alle Dateien durchsucht, nicht nur .js
3. Die "Seitenquelltext"-Vorschau des Firefox zeigt die DIV-Kontainer gar nicht, was aber normal scheint, denn sie werden ja nicht angezeigt.
4. Firebug ist da schon auskunftsfreudiger und zeigt den oben geposteten Code.Vermutung: Es handelt sich um eine externe Javascript-Datei - aber wie finden wir die?
Zuletzt wurden der JCE und Akeeba upgedatet, teilweise wird die Mediabox verwendet. Könnte eine Erweiterung evtl. die selben ID-Namen verwenden? Dann müßte diese aber auch ein externes Script laden.
Wir hoffen nun ist Einiges klarer geworden, wenn es gar nicht anders geht, müssen wir auf einer Testseite versuchen, das Problem mutwillig zu erzeugen und dann schauen, was wir wann gemacht haben. Vielleicht hat ja jemand ein ähnliches Problem.
Wie gesagt, halten wir einen Hack eher für unwahrscheinlich, da die Seiten auf mehreren Servern, bei verschiedenen Providern liegen - nur das Template ist überall gleich, aber auch kopiert, umbenannt und bearbeitet.Hoffentlich ist nun einiges klarer geworden und es gibt eine triftige Erklärung - da wir die ID's der DIV-Kontainer nicht benötigen, ist auf den Seiten nun alles wieder OK, wenn es aber doch ein Hack ist ... NEIN, daran wollen wir erstmal gar nicht denken.
Danke schon mal
Michael -
Hallo,
wir haben ein sehr seltsames Phänomen bei dem Template Favourite, welches wir bei diversen Webseite einsetzen, auf verschiedenen Servern, was die Wahrscheinlichkeit eines Hacks ja doch deutlich verringert.
Das Problem ist eine Style-Angabe, die einfach nicht zu finden ist. Der Originalcode lautet:PHP<!-- Advert --> <?php if ($this->countModules('advert')) { ?> <div class="container-fluid" id="fav-advertwrap"> <div class="row-fluid"> <div id="fav-advert" class="span12"> <jdoc:include type="modules" name="advert" style="icon" /> </div> </div> </div> <?php } ?>
Schaut man es sich mit Firebug an, dann sieht es so aus:Code<div id="fav-advertwrap" class="container-fluid" style="display: none ! important;"> <div class="row-fluid"> <div id="fav-advert" class="span12" style="display: none ! important;"> </div> </div>
Die beiden Styles scheinen per Javascript eingefügt zu werden, allerdings finden wir den verantwortlichen Kandidaten nicht. Als Sofortmaßnahme haben wir die ID's entfernt, was bei fast allen Webseiten den gewünschten Erfolg brachte, nur bei einer nicht, aber das werden wir morgen suchen. Zwei Seiten zeigten sogar auf einem unserer Rechner das Modul "advert" an, auf einem anderen nicht. Versuche mit unterschiedlichen Bildschirmauflösungen brachten auch nicht weiter.
Wo könnte dieser Style herkommen? Externe Javascript-Datei? Wie finden?
Vielen Dank im Voraus
Michael