WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: astricia on September 10, 2019, 10:12:45 AM
-
Hallo zusammen,
ich bin so nach und nach dabei, alte WB-Installationen, die noch auf 2.8.3 sp7 und mit alten PHP-Versionen laufen, auf die neue 2.12.2 zu aktualisieren. Immer wenn die Foldergallery dabei ist, gibt es in der Regel Probleme... Daher mache ich das dann immer so, dass ich mir eine Kopie der Installation auf den eigenen Server ziehe - dort upgrade und alles ausbessere, bis die Seite wieder so aussieht, wie sie soll... und dann eine Kopie der upgegradeten Version auf den Kundenserver ziehe und dort erst mal in einer Subdomain teste. Und an dem Schritt hakelt es gerade.
Alte Version (wb 2.8.3 sp7, PHP 5.6): https://www.atelier-karina-jeggle.de
Neue Version auf eigenem Server (wb 2.12.2, PHP 7.2): http://karina.netschmiede24.de
Kopierte Version auf Kunden-Server (wb 2.12.2, PHP 7.2): http://neu.atelier-karina-jeggle.de
Sieht auf den ersten Blick alles gut aus. Aber geht man auf "Malerei" oder "Fotografie" (die Seiten, auf denen sich die Foldergallery befindet), gibt es bei der letzten Version einen Abbruch der Seite genau an der Stelle. Auch im Backend bekomme ich hier bei diesen beiden Seiten leere Seiten angezeigt. Warum???
LG,
Astrid
-
Die unter neu.atelier-karina-jeggle.de ergab die Meldung:
09.10 11:22.57, [Warning] Initial request returned with code: 500 (Internal Server Error).
und ist danach überhaupt nicht mehr erreichbar.
MfG. Evaki
-
Weiß nicht wo du das stehen hast. Finden und erstmal gerade biegen, wirft einen JS Error (SyntaxError: unterminated string literal):
function gaOptout() {
document.cookie = disableStr + '=true; expires=Thu, 31 Dec 2099 23:59:59
UTC; path=/';
window[disableStr] = true; }Die Zeile mit UTC soll wohl eins höher mit ran.
Der Link zur alten Version öffnet sich nicht, rödelt und rödelt.
karina und neu haben wohl in der Datenbank noch die Bild-Pfade zur alten Installation. Prüf mal. Jedenfalls wird es dahin geleitet.
-
Nun sollte die Site nicht mehr funktionieren :-D
Habe die Vermutung, daß es an der Konfiguration der Subdomain liegt, also serverseitig ein Problem vorhanden ist.
Ob dies auch Auswirkungen auf WB hat, vermag ich aber nicht zu sagen.
ps. Ist die Installation per http und httpS aufrufbar?
MfG. Evaki
-
Weiß nicht wo du das stehen hast. Finden und erstmal gerade biegen, wirft einen JS Error (SyntaxError: unterminated string literal):
function gaOptout() {
document.cookie = disableStr + '=true; expires=Thu, 31 Dec 2099 23:59:59
UTC; path=/';
window[disableStr] = true; }Die Zeile mit UTC soll wohl eins höher mit ran.
Das gehört zu Google Analytics.... hat sicherlich nichts mit der Foldergallery zu tun. Läuft auch auf allen anderen Unterseiten.
Der Link zur alten Version öffnet sich nicht, rödelt und rödelt.
karina und neu haben wohl in der Datenbank noch die Bild-Pfade zur alten Installation. Prüf mal. Jedenfalls wird es dahin geleitet.
Öffnet sich bei mir alles. Untermenü-Punkte unter "Malerei" und "Fotografie" sind vom Typ Menu-Link, weil sie spezifisch auf einzelne Alben der Foldergallery verlinken - die brauche ich nicht ändern, wenn dann irgendwann die Hauptdomain auf die neue Version verweist. Einfach nur die Oberseiten aufmachen - dann seht ihr den Fehler.
-
ps. Ist die Installation per http und httpS aufrufbar?
Nein, aktuell sind die neuen Versionen nur unter http - das dürfte aber keinen Unterschied machen?
-
Jo http, bei https bringt's halt nur 'ne Zertifikatmeldung.
Jedenfalls ist bei mir neu.atelier-karina-jeggle.de ------ malerei.php mit error 500 dabei
Dieser Server error sperrt die Site für xxx-Zeit, bevor sie wieder erreichbar ist.
Bei erneutem Aufruf des Testscript wiederholt sich's
-
Auch wenn du direkt den Link öffnest?
http://neu.atelier-karina-jeggle.de/pages/de/malerei.php
-
Die Website ist nicht erreichbar
-
Das kann ich nicht nachstellen... welchen Browser nutzt du denn dafür?
-
Diverse Browser. Wenn überhaupt, läge es am lokalen Netzwerk. Komischerweise funktioniert sonst alles hier. Nach einer gewissen Zeit xxx ist sie auch wieder erreichbar. Starte ich den Test- war's das.
Alles merkwürden. Ich gucke mir das mal über ein anderes Tool an. Erstmal ist Pause zu Ende.
MfG. Evaki
ps. Guckt man sich den Quellcode an, scheint der Schluß zu sein, daß ab Beginn der Galerie die Seite/Page stoppt, also die Ausgabe von HTML unterbrochen wird xyz... und kein </body></html>
Kannst ja mal in die Server error.log reinschauen, was sich so an Einträgen zu dieser Stund angesammelt hat.
Noch ein Nachtrag. Es liegt hier ein Netzwerkproblem (Hamburg: Telekom "Backbone" oder sonstwat) vor. Über meinen Hamburger Proxy bekomme ich Deine Domain zu sehen.
-
Auch im Backend bekomme ich hier bei diesen beiden Seiten leere Seiten angezeigt. Warum???
wäre mein Ansatzpunkt...
meine Vermutung geht in Richtung Datenbank, alles andere ließe sich mit Folgefehlern gut erklären.
Wenn du die Möglichkeit hast, arbeite mit zwei Monitoren, jeweils die DB der "guten" und der "bösen" DB auf dem Bildschirm. Vergleiche die Tabellen "sections", "pages" und die drei der Foldergallery (hier insbesondere die settings-Tabelle), ggf fehlen ein paar Datensätze.
Alternativ das Backup (oder Teile davon) neu importieren, vielleicht auch in eine zweite Datenbank. Vielleicht kannst du in der config.php auch mal die DB-Daten einer funktionierenden Installation eintragen. Ist das ein anderer DB-Server, sollte es per default nicht erlaubt sein, aber z.b. bei AllInkl. könnte man den Zugriff auf die DB von extern per Mausklick erlauben.
Hast du keine zwei Monitore, macht es auch ein Ausdruck, braucht aber viel Konzentration.
Das Backend arbeitet mit den gleichen Daten wie das Frontend, bereitet sie nur anders auf
-
meine Vermutung geht in Richtung Datenbank, alles andere ließe sich mit Folgefehlern gut erklären.
Wenn du die Möglichkeit hast, arbeite mit zwei Monitoren, jeweils die DB der "guten" und der "bösen" DB auf dem Bildschirm. Vergleiche die Tabellen "sections", "pages" und die drei der Foldergallery (hier insbesondere die settings-Tabelle), ggf fehlen ein paar Datensätze.
Da gibt es in der Tat ein paar Unterschiede in der Datenbank. Wenn ich die Struktur der "guten" DB aufrufe, stehen da in den Tabellen der Foldergallery andere Größen (aber auch in einigen anderen Tabellen), zudem gibt es da in einigen Tabellen einen "Überhang" (was auch immer das ist), den es in der bösen Datenbank nicht gibt.
Ich habe also im ersten Schritt die "böse" Datenbank komplett geleert und noch einmal von der guten Datenbank (also der auf meinem eigenen Server) importiert. Wenn ich die dann mit MySQLAdmin öffne, sieht die aber genauso aus wie vorher - kein Unterschied!
Vielleicht kannst du in der config.php auch mal die DB-Daten einer funktionierenden Installation eintragen. Ist das ein anderer DB-Server, sollte es per default nicht erlaubt sein, aber z.b. bei AllInkl. könnte man den Zugriff auf die DB von extern per Mausklick erlauben.
Das habe ich jetzt im zweiten Schritt probiert. Die config.php von neu. greift jetzt also momentan auf die Datenbank von karina. zu. Und trotzdem ist da noch der gleiche Fehler.... ?????
Bin absolut ratlos...
LG,
Astrid
-
Und was sagt das Backend jetzt?
Die Dateien, speziell im Ordner /modules/foldergallery mit denen der funktionierenden Version zu überschreiben, hast du sicher schon probiert, oder?
Die config.php von neu. greift jetzt also momentan auf die Datenbank von karina. zu. Und trotzdem ist da noch der gleiche Fehler.
dann wäre die Datenbank wohl raus :|
zudem gibt es da in einigen Tabellen einen "Überhang" (was auch immer das ist), den es in der bösen Datenbank nicht gibt.
jede Tabelle arbeitet mit einem internen Speicher, eine Art "Cache". Werden nun Daten dieser Tabelle bearbeitet oder gelöscht, ist der vorher reservierte Speicher größer als der real benötigte. Diese Differenz ist dann der Überhang. Zum Korrigieren nutzt man die Funktion "Optimiere Tabelle / Optimize Table" in den Tabellen-Optionen.
Das sollte von Zeit zu Zeit erledigt werden, weil sonst das System langsamer wird, da es Speicher reserviert, der nicht benötigt wird und ggf an anderer Stelle fehlt.
P.S.: für unsere relativ kleinen Installationen wird die Verzögerung für den Laien kaum spürbar sein, also kein Grund, deswegen nun in Panik zu verfallen
Was mir noch einfällt, wäre die Verlinkung der Dateien, hier insbesondere der JS-Dateien und speziell die der benutzten Lightbox. Diese wird ja zu Beginn der Sektion geladen bzw sollte geladen werden. Wenn da auf domainfremde Dateien verlinkt ist und die Sicherheitseinstell ungen den Zugriff verbieten, könnte das den 500er Error schon erklären.
-
Und was sagt das Backend jetzt?
Das gleiche wie vorher. Weiße Seite bei Malerei und Fotografie.
Die Dateien, speziell im Ordner /modules/foldergallery mit denen der funktionierenden Version zu überschreiben, hast du sicher schon probiert, oder?
Nein, noch nicht. Was mir noch eingefallen ist - ich habe beim Hochladen zu karina. zuerst das falsche Backup (das von gestern mit der wb 2.8.3) hochgeladen. Ist mir dann natürlich sofort aufgefallen, als ich die Seite aufgerufen habe. Dann habe ich den Inhalt des Verzeichnisses auf dem Server gelöscht und die richtigen Dateien hochgeladen. Aber vielleicht ist dabei irgendwas schief gegangen. Um das zu testen, lade ich gerade das komplette Backup noch einmal in ein anderes Verzeichnis hoch und mache den ganzen Prozess noch mal.
dann wäre die Datenbank wohl raus :|
Tja, denke ich wohl auch...
Was mir noch einfällt, wäre die Verlinkung der Dateien, hier insbesondere der JS-Dateien und speziell die der benutzten Lightbox. Diese wird ja zu Beginn der Sektion geladen bzw sollte geladen werden. Wenn da auf domainfremde Dateien verlinkt ist und die Sicherheitseinstell ungen den Zugriff verbieten, könnte das den 500er Error schon erklären.
Ich sehe nicht, wo da auf was domainfremdes verlinkt ist...? Das Lightbox-Script ist auf dem eigenen Server...
Evaki, hast du denn den 500er-Fehler auch bei der karina. Seite? Oder nur bei neu. ?
LG,
Astrid
-
Was mir noch eingefallen ist - ich habe beim Hochladen zu karina. zuerst das falsche Backup (das von gestern mit der wb 2.8.3) hochgeladen. Ist mir dann natürlich sofort aufgefallen, als ich die Seite aufgerufen habe. Dann habe ich den Inhalt des Verzeichnisses auf dem Server gelöscht und die richtigen Dateien hochgeladen. Aber vielleicht ist dabei irgendwas schief gegangen. Um das zu testen, lade ich gerade das komplette Backup noch einmal in ein anderes Verzeichnis hoch und mache den ganzen Prozess noch mal.
OK - das war es dann wohl auch. Die neue Version läuft - auf den ersten Blick - einwandfrei. Siehe:
http://wb2-12-2.atelier-karina-jeggle.de
Allerdings kriege ich im Backend im Errorlog direkt jede Menge Anzeigen - und das, obwohl die PHP-Fehlerberichte ausgeschaltet sind. Wie folgt:
Tue, 10 Sep 2019 13:58:05 +0000 [E_DEPRECATED] /include/PHPMailer/PHPMailerAutoload.php:[45] from /config.php:[20] require "__autoload() is deprecated, use spl_autoload_register() instead"
Was ist das? Das kommt bei der karina. Version nicht.... habe ich sonst auch noch nie bei WB 2.12.2 gesehen.
LG,
Astrid
-
Also die Meldung hat ja irgendwas mit der PHP-Version zu tun. An der entsprechenden Stelle in PHPMailerAutoload.p hp steht:
if (version_compare(PHP_VERSION, '5.1.2', '>=')) {
//SPL autoloading was introduced in PHP 5.1.2
if (version_compare(PHP_VERSION, '5.3.0', '>=')) {
spl_autoload_register('PHPMailerAutoload', true, true);
} else {
spl_autoload_register('PHPMailerAutoload');
}
} else {
/**
* Fall back to traditional autoload for old PHP versions
* @param string $classname The name of the class to load
*/
function __autoload($classname)
{
PHPMailerAutoload($classname);
}
}
Aber die PHP-Version ist garantiert 7.2. Hier sind die Angaben aus der Info:
Webserver Software: Linux dd22726 3.13.0-170-generic #220-Ubuntu SMP Thu May 9 12:40:49 UTC 2019 x86_64
PHP-Erweiterung: mysqli Dokumentation curl Dokumentation mbstring Dokumentation
PHP-Version: 7.2.19
WebsiteBaker-Version: 2.12.2 -r379
Wie kann das sein??? Bei jedem Aufruf der Website kommt eine solche Zeile zu dem Errorlog hinzu.... !!!
-
Und was zeigt dir dieses Script an, wenn du das mal auf den Server hochlädst?
<?php
if (version_compare(PHP_VERSION, '5.1.2', '>=')) {
if (version_compare(PHP_VERSION, '5.3.0', '>=')) {
echo 'Größer als PHP Version 5.3.0, meine Version: ' . PHP_VERSION;
} else {
echo 'Kleiner als PHP Version 5.3.0, meine Version: ' . PHP_VERSION;
}
} else {
echo 'Kleiner als PHP Version 5.1.2, meine Version: ' . PHP_VERSION;
}
?>
-
Gibt das hier aus:
Größer als PHP Version 5.3.0, meine Version: 7.2.19
Kann es daran liegen, dass die www-Domain noch die php-Version 5.6 hat? Wenn ich also umstelle, dass dann alles OK ist?
-
Kann es daran liegen, dass die www-Domain noch die php-Version 5.6 hat? Wenn ich also umstelle, dass dann alles OK ist?
Daran liegt es nicht. Habe die Haupt-Domain jetzt auf das neue Verzeichnis umgeleitet und die PHP-Version entsprechend umgestellt. Der Fehler bleibt.
Bitte dringend um Hilfe, woran das liegen kann bzw. was ich tun kann, damit der Error-Log nicht weiter mit jedem einzelnen Klick im Front- oder Backend um eine Zeile wächst...
-
Evaki, hast du denn den 500er-Fehler auch bei der karina. Seite? Oder nur bei neu. ?
Nur bei neu. Habe es soeben mit anderem Tool aufgerufen - also nicht mit einem Browser - und es gibt weiterhin für diese Seite (pages/de/malerei.php) einen 500 error, wobei ich mich diesmal aber nicht aussperre.
Frag bei bitte Deinen Hoster, ob auf dem Server Schutzeinrichtungen aktiv sind, und ob diese Auswirkungen darauf haben könnten. - dürfte im error.log zu sehen sein.
ps. Ist die Galerie auf dem neuesten Stand - ganz unabhängig davon, ob diese sonstwo unter php7.x funktioniert?
MfG. Evaki
-
Nimm es nicht persönlich, aber irgendwie mußt du an deinen Arbeitsmethoden arbeiten, denn es ist ja nicht das erste Mal, das sich zahlreiche Leute mit Problemlösungen beschäftigen und sich am Ende herausstellt, das das Problem doch aus deiner Methodik resultiert.
Ich würde vorschlagen, lösche aus dieser Installation, die aktuell die Fehlermeldungen wirft, die Ordner
- account
- admin
- include
- framework
- languages
- search
sowie die Ordner im /modules-Verzeichnis, die im Vollpaket WB 2.12.2 enthalten sind, komplett per FTP
und übertrage sie aus dem Vollpaket neu. Vermeide unbedingt das Überschreiben vorhandener Dateien und das Kopieren bearbeiteter lokaler Kopien, insbesondere, wenn du mit Windows arbeitest. Windows ist Groß-/Kleinschreibung egal, da kann es dann schon vorkommen, das am Ende auf dem Server "falsche"Dateien vorhanden sind.
Zu den Fehlermeldungen... ich würde sie alle getrennt betrachten. Die Meldung zum PHPMailer sollte (meiner Meinung nach) nur auftauchen, wenn dieser auch angesprochen wurde, also in irgendeiner Form eine Mail versenden möchte.
Wenn die Fehlermeldung sich weiterhin auf die PHP-Version bezieht, würde ich sie direkt in die Datei einbauen, die sie auslöst. Im Beispiel des PHPMailers also in der genannten Datei /include/PHPMailer/PHPMailerAutoload.php
Dazu vom Codeschnipsel, gepostet von sstvmaster, die erste und letzte Zeile weglassen und den Rest direkt vor dem Code, den du gestern um 17.03 Uhr gepostet hast
Frag bei bitte Deinen Hoster, ob auf dem Server Schutzeinrichtungen aktiv sind, und ob diese Auswirkungen darauf haben könnten. - dürfte im error.log zu sehen sein.
access.log wäre auch noch eine Quelle
den 500er Fehler habe ich nur unter Verwendung von Tools auf der Seite, die vorher nicht ging, also der neu-Domain. Das sollte mittlerweile aber erledigt sein
Nur mal gefragt: hast du PHP 7.3 zur Verfügung?
-
den 500er Fehler habe ich nur unter Verwendung von Tools auf der Seite, die vorher nicht ging, also der neu-Domain. Das sollte mittlerweile aber erledigt sein
Ebenso. Nur nach Zeit xxx war doch wieder Schluß.
malerei.php : HTTP status 500
himmel.php : Unexpected Redirect Response Body (Too Large) ... it generally indicates a programming error. In PHP applications, call exit() after you redirect the user.
php7.3 bei mir nicht installiert - weiß nicht mehr was mich daran hinderte, möglicherweise irgendeine Meldung eines Hosters.
MfG. Evaki
-
Zu den Fehlermeldungen... ich würde sie alle getrennt betrachten.
Es gibt nur die eine Fehlermeldung, zu dem PHPMailer. Diese taucht im Errorlog bei JEDEM Klick auf - sowohl im Backend als auch im Frontend.
Die Meldung zum PHPMailer sollte (meiner Meinung nach) nur auftauchen, wenn dieser auch angesprochen wurde, also in irgendeiner Form eine Mail versenden möchte.
Wenn die Fehlermeldung sich weiterhin auf die PHP-Version bezieht, würde ich sie direkt in die Datei einbauen, die sie auslöst. Im Beispiel des PHPMailers also in der genannten Datei /include/PHPMailer/PHPMailerAutoload.php
Dazu vom Codeschnipsel, gepostet von sstvmaster, die erste und letzte Zeile weglassen und den Rest direkt vor dem Code, den du gestern um 17.03 Uhr gepostet hast
Nicht ganz verstanden was du meinst - aber ich habe jetzt einfach in den else-Zweig der PHP-Abfrage (also das, was eigentlich erst kommen dürfte, wenn eine kleiner PHP-Version vorhanden ist). den Code eingefügt, den er bei einer aktuellen PHP-Version nimmt. Scheint zu funktionieren.
Frag bei bitte Deinen Hoster, ob auf dem Server Schutzeinrichtungen aktiv sind, und ob diese Auswirkungen darauf haben könnten. - dürfte im error.log zu sehen sein.
Im Errorlog war nix zu sehen außer zig identische Zeilen der PHPMailer-Meldung.
access.log wäre auch noch eine Quelle
den 500er Fehler habe ich nur unter Verwendung von Tools auf der Seite, die vorher nicht ging, also der neu-Domain. Das sollte mittlerweile aber erledigt sein
Eine Quelle für was? Den 500er-Fehler habe ich nirgendwo, sehe ich auch nirgendwo, kann ich nicht nachstellen oder nachvollziehen. Weder auf dem PC, noch dem Laptop, noch dem Handy. Auch verschiedene Browser ausprobiert... wird überall normal dargestellt. Hat das denn außer evaki noch jemand???
Nur mal gefragt: hast du PHP 7.3 zur Verfügung?
Ja, hätte ich. Nehme aber bislang immer nur 7.2...
ps. Ist die Galerie auf dem neuesten Stand - ganz unabhängig davon, ob diese sonstwo unter php7.x funktioniert?
Ja, das ist FG 3.0.14
-
Dann wiederhole ich nochmal
>>evaki: Guckt man sich den Quellcode an, scheint der Schluß zu sein, daß ab Beginn der Galerie die Seite/Page stoppt, also die Ausgabe von HTML unterbrochen wird xyz... und kein </body></html>
anders
</header>
</div>
<div id="wrapper">
<div class="container">
<section class="sixteen columns content">
</section>
</div>
<div class="container">
<section class="eight columns content">
</section>
<section class="eight columns content">
</section>
</div>
<div class="container">
</div>
<div class="container">
<section class="twelve columns content">
Danach kommt der Einstieg des Modules = eben nix mehr - leer, Wüste ---
Was ist die Ursache? Code, Dateirechte/-format, AppFW, isländische Feen ?
MfG. Evaki
-
Die Unterseiten von Malerei und Fotografie (auf den beiden Subdomains) leiten zur Hauptdomain atelier-karina-jeggle.de/...
Jedenfalls landet man da nach Klick.
-
Dann wäre ein Broken link report ja sinnvoll.
Anbei der Broken link report for September 11, 2019 at 16_03_20.7z
"Eigentlich" nachvollziehbar, wenn die DB nur importiert wird und anscheinend sonst nix passiert ist - naja schon: Dateien fehlen. Wo 500er auftauchen ist auch zu sehen.
MfG. Evaki
-
Dann wiederhole ich nochmal
>>evaki: Guckt man sich den Quellcode an, scheint der Schluß zu sein, daß ab Beginn der Galerie die Seite/Page stoppt, also die Ausgabe von HTML unterbrochen wird xyz... und kein </body></html>
...
Was ist die Ursache? Code, Dateirechte/-format, AppFW, isländische Feen ?
MfG. Evaki
Genau das war das anfänglich beschriebene Problem auf den Unterseiten, die eine Foldergallery beinhalten - das habe ich inzwischen aber doch gelöst und die Seite wird vollständig dargestellt... ? Ich rede von der www-Adresse!
Die Unterseiten von Malerei und Fotografie (auf den beiden Subdomains) leiten zur Hauptdomain atelier-karina-jeggle.de/...
Jedenfalls landet man da nach Klick.
Das ist Absicht - hatte ich doch auch schon geschrieben. Es gibt keine andere Möglichkeit, einen einzelnen Ordner der Foldergallery als Menüpunkt anzusprechen - das geht nur übers "hart verdrahten" mit Menulink. Die entsprechenden Menulinks habe ich auf den Testseiten nicht verändert, weil sie am Ende ja eh wieder auf die www-Seite verlinken sollen!
Dann wäre ein Broken link report ja sinnvoll.
Anbei der Broken link report for September 11, 2019 at 16_03_20.7z
Die Datei öffnet sich bei mir nicht...
-
Ich gehe wie im Topic angegeben von
Neue Version auf eigenem Server (wb 2.12.2, PHP 7.2): http:// neu.atelier-karina-jeggle.de
aus.
Wer sonst noch? - eben...
*7z geht halt mit 7z aufzumachen, aber auch mit Winzip.
MfG. Evaki
-
Nee, dann hast du nicht alles verfolgt, was ich geschrieben habe.
Inzwischen läuft auf der www.atelier-karina-jeggle.de die 2.12.2 - bitte nur noch davon ausgehen. Die anderen Subdomains lösche ich gleich mal alle...
Entzippen konnte ich es - aber eine .mhtml kann mein Browser nicht auflösen. Hab mit nem Texteditor reingeschaut - du hast da die neu-Subdomain genommen.
-
mhtml ist mit chrome aufzumachen
Den anderen "Kram" gucke ich mir später - nicht unbedingt heute - nochmal an.
MfG. Evaki
-
Wie gesagt - es läuft jetzt eigentlich (von meiner Seite aus) einwandfrei. Warum diese PHPMailer-Meldung im Errorlog auftauchte, weiß kein Mensch, aber das ist ja jetzt auch behoben.
Wäre nur noch zu klären, ob du immer noch einen 500er-Fehler bekommst, dann müsste ich da noch mal weiter nachhaken.
-
Wie gesagt - es läuft jetzt eigentlich (von meiner Seite aus) einwandfrei
Das konnte ich für den Browser bestätigen, also so der erste Eindruck.
Die zu prüfende Site/Page: www . atelier-karina-jeggle.de/pages/de/malerei.php
(damit es keine weiteren Mißverständnisse gibt)
Mein nächster Schritt war der Linktest, der anscheinend drei fehlende css anzeigt - ist aber noch nicht geklärt, da nach weiterem Schritt (Scan) die Site mich wieder rausgeschmissen hat.
Das Verhalten kommt mir bekannt vor, nämlich bei auf Servern installierten Sicherungssystemen.
Nun warte ich erstmal die Zwangspause ab, und mache dann den Linktest.
MfG. Evaki
-
Anbei Broken link report for September 11, 2019 at 18_25_36.zip
MfG. Evaki
ps- Falls Du die nicht unbedingt benötigst (www . atelier-karina-jeggle.de/admin.pl) entfernen, oder zumindest in der robots.txt "verbieten".
-
Ämmm.... also ok, die Datei ist ganz schön lang. Aber wie gesichert ist denn das, was da drin steht?
Fängt schon oben an:
Er meckert, dass die Datei include/jquery/domready.js nicht gefunden wird. Stimmt - die Datei heißt ja auch domReady.js mit einem großen R. Und im Quellcode steht auch eindeutig der Dateiaufruf mit großem R.
Die ganzen Bilder, die er angeblich nicht findet - die will er in einem Verzeichnis events/bilder suchen. Das Verzeichnis heißt aber Bilder mit großem B und ist auch auf der Seite so verlinkt. Auch weitere Bilder - die haben teilweise Großbuchstaben im Dateinamen. Bei mir wird das alles richtig dargestellt.
Hast du bei dir irgendwas installiert, was sämtliche Großbuchstaben zu Kleinbuchstaben macht? Anders kann ich mir das nicht erklären....
LG,
Astrid
-
Hast du bei dir irgendwas installiert, was sämtliche Großbuchstaben zu Kleinbuchstaben macht?
Mannomann, schön, daß Du aufpaßt, denn da könntest Du u.U. richtig liegen, obwohl die Option lautet bei mir "URLs to lower case".
Ich mache das gleich noch einmal. Dann schauen wir weiter. Tools sind manchmal zwar hilfreich, aber trotzdem fehlerhaft. Schauen wir mal...
MfG. Evaki
ps. Jetzt dreimal wiederholt und überhaupt keine Fehlermeldung zu sehen.
Ups, ich sehe jetzt "no connection", muß wohl wieder die Pause abwarten.
Es könnte sehr gut sein, daß die Meldungen dadurch zustande kommen, daß mein Scanner natürlich keine Daten oder sonstwas findet, wenn Dein Server zwischenzeitlich aussteigt :evil:
Ein "sauberer", also vollständiger Scann, kann nur ausgeführt werden, wenn der Server dies auch zuläßt. Das scheint bei Deinem nicht der Fall zu sein, deshalb die Probleme einen ordentlichen Test auszuführen zu können. (Tricks gibt's natürlich - wobei es auch schwieriger wird durch den Code zu steigen, aber dies ist nur für den äußersten Notfall vorgesehen)
Kannst Du denn jetzt den einwandfreien Betrieb bestätigen?
-
Falls alles wie gewünscht funktioniert, gibt es die Möglichkeit den w3c-Validator zu bemühen, damit zumindest gröbere Fehler, falls vorhanden, ausgebügelt werden können.
MfG. Evaki
ps Schei.. Telemom. Hamburg anscheinend seit zwei Tagen gestört.
-
Zumindest hab' ich noch 'nen Versuch unternommen, 'nen Ausschnitt des Protokolls festzuhalten.
Kannst ja mal schauen, ob sich das wie dort gezeigt verhält.
Mehr geht im Moment nicht.
MfG. Evaki
-
Nachdem nach Stunden Rumgefummle - benutze den Arbeitsrechner nur noch selten, daher immer ein paar Fragezeichen möglich - nun klar ist, daß durch die lokale Netzstörung diverse Dienste und Tools aus dem Ruder laufen - Tschuldigung für die Unannehmlichkeiten - mal ganz praktisch >>brokenlinkcheck.com und gut war's. Einzig der Link zu www . aktion-kleiner-prinz.de ist unbrauchbar, da die Domain anscheinend nicht mehr existiert.
Tja, die Zeit mußte ich mir nehmen, damit nicht irgendwelcher Schrott oder irgendwelche Fragen zurückbleiben. Hilfsangebote sollen die Anwender ja "nicht in den Wald schicken".
MfG. Evaki
-
OK, es lag dann also nur lokal an dir. Hätte ich mir auch nicht anders erklären können, da niemand sonst das Problem mit 500er-Seiten hatte...
Danke für deinen Einsatz! Und den anderen Helfern auch ein Dankeschön! :-)
LG,
Astrid
-
Das mit den beiden 500er errors kam aus der subdomain, und war trotzdem gültig, die serverseitige Sicherheitsreaktion - Sperrung der IP - bei einem Scan genauso. Die Tools konnten in diesen Umständen ihre Aufgabe nicht erfüllen.
Einzig der Linkprüfer hat wohl 'ne Macke (dynamischen Seiten), und wird nach nochmaliger Überprüfung gegebenenfalls ausgetauscht.
Ha, und das Telemom-Netz scheint heute Morgen wieder richtig zu flutschen :-D
MfG. Evaki
-
Der Linkprüfer lag wohl auch nicht daneben, wenn man die Ergebnisse mit denen aus
validator.w3.org/checklink
vergleicht.
Die widrigen Umstände waren wohl das größere Problem.
Es lohnt sich also noch einmal genauer hinzuschauen.
MfG. Evaki
-
Nun der letzte Kommentar zu der Site.
Die angemeckerten Broken links sind tatsächlich welche, da sich z.B. sowas im Quellcode befindet:
<link href="css/base.css" rel="stylesheet" type="text/css">
<link href="css/layout.css" rel="stylesheet" type="text/css">
<link href="css/skeleton.css" rel="stylesheet" type="text/css">
<link rel="stylesheet" type="text/css" href="https://www.atelier-karina-jeggle.de/templates/atelier-karina-jeggle/css/CookieNotice.css" />
<!-- Basic Page Needs ================================================== -->
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<!-- CSS ================================================== -->
<link rel="stylesheet" type="text/css" href="https://www.atelier-karina-jeggle.de/templates/atelier-karina-jeggle/css/base.css" />
<link rel="stylesheet" type="text/css" href="https://www.atelier-karina-jeggle.de/templates/atelier-karina-jeggle/css/skeleton.css" />
<link rel="stylesheet" type="text/css" href="https://www.atelier-karina-jeggle.de/templates/atelier-karina-jeggle/css/layout.css" />
Trotz mehrerer Verbindungsprobleme gab es zwischenzeitlich intakte Ergebnisse, sprich die Fehlermeldungen waren korrekt - genauer, aktuell kann man feststellen, daß die hausgemachten Fehler nach wie vor bestehen.
So, das war ich mir selber schuldig - so besoffen kann ich nicht sein, um derart daneben zu liegen.
:-D :-D :-D
Ich empfehle die Site zu validieren, in jeglicher Hinsicht. Sonst besteht die Gefahr, daß sie Dir irgendwann "auf die Füße fällt". Beispielsweise gibt's auch noch einige wenige ISO statt utf8-Seiten, was möglicherweise mit einem Modul zusammenhängt.
MfG. Evaki
-
Alles gut - diese broken links sind Relikt eines alten Templates, das sich nach und nach verändert hat. Tun nicht weh - und bei über 100 Kunden-Websites, die ich betreue, gibt es Prioritäten. Und die liegen momentan nicht bei diesen Kleinigkeiten.
Trotzdem danke für deinen Input.
LG,
Astrid
-
Ist das nur bei mir so?
Die Unterseiten von Malerei und Fotografie zeigen die Thumbs untereinander im Chrome. Im FF ist es ok.
-
Ist das nur bei mir so?
Die Unterseiten von Malerei und Fotografie zeigen die Thumbs untereinander im Chrome. Im FF ist es ok.
Lösch mal deinen Browser-Cache.... War bei mir auch kurzfristig so, lag aber daran, dass da noch eine frontend.css aus der alten Version geladen wurde.
LG,
Astrid
-
Verdammt, hast recht. ;D *peinlich*