Moved_XH: Ausgabe auf eigene Fehlerseiten möglich? (gelöst)

Third Party Plugins to CMSimple - how to install, use and create plugins

Moderator: Tata

lck
Posts: 2963
Joined: Wed Mar 23, 2011 11:43 am
Contact:

Re: Moved_XH: Eigene Fehlerseiten nutzen?

Post by lck » Tue Apr 19, 2022 11:35 am

Michael_G wrote:
Mon Apr 18, 2022 8:31 pm
Nachtrag: Habe die Überschriften meiner eigenen Fehlerstatusseiten 404 und 410 passend gemacht.
BTW: Unterdrücken durch Ausblenden der Zeile in der Datei NotFoundController.php brachte nichts, auch Änderungen an der Sprachdatei de.php waren wirkungslos.
Eine Veränderung müsste bei diesen Änderungen auf alle Fälle sichtbar sein. Wichtig dabei, Cache komplett löschen (machst du ja sowieso) und die Seite mit STRG + F5 neuladen, evtl. auch mehrmals hintereinander.
Michael_G wrote:
Mon Apr 18, 2022 8:31 pm
Nur fast: Der Text in <h1>-Überschrift von Moved_XH wird weiterhin angezeigt, also doppelte h1-Überschrift.
In der Sprachdatei unter Notfound könntest du folgendes eintragen, analog in der/den anderen Sprachen.

Code: Select all

<span style="display:none">Seite nicht gefunden</span>
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“   👉 Ludwig's XH-Templates for MultiPage & OnePage

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: Moved_XH: Eigene Fehlerseiten nutzen?

Post by cmb » Tue Apr 19, 2022 11:57 am

lck wrote:
Tue Apr 19, 2022 11:35 am
Michael_G wrote:
Mon Apr 18, 2022 8:31 pm
Nachtrag: Habe die Überschriften meiner eigenen Fehlerstatusseiten 404 und 410 passend gemacht.
BTW: Unterdrücken durch Ausblenden der Zeile in der Datei NotFoundController.php brachte nichts, auch Änderungen an der Sprachdatei de.php waren wirkungslos.
Eine Veränderung müsste bei diesen Änderungen auf alle Fälle sichtbar sein. Wichtig dabei, Cache komplett löschen (machst du ja sowieso) und die Seite mit STRG + F5 neuladen, evtl. auch mehrmals hintereinander.
Der Browsercache sollte hier irrelevant sein; allerdings vermute ich, dass ein PHP Bytecode-Cache (vermutlich OPcache) aktiv ist. Je nach Einstellung, kann es dauern, bis dieser aktualisierte PHP-Dateien erkennt (unter Umständen "ewig"). Im Zweifel mal in der PHP-Info (Einstellungen → Info → PHP-Info) nachschauen, was da konfiguriert ist.
Christoph M. Becker – Plugins for CMSimple_XH

Michael_G
Posts: 185
Joined: Thu Feb 18, 2016 11:01 pm
Contact:

Re: Moved_XH: Eigene Fehlerseiten nutzen?

Post by Michael_G » Tue Apr 19, 2022 1:37 pm

@lck: ja, Cache leeren und Seite neu laden ist für mich Standard (MacBook Air, daher Menü „Entwickler/Cache-Speicher leeren” und zum zwangsweise Neuladen dann Cmd+R anstatt STRG+F5).
Danke für das neue Code-Snippet, das wird bestimmt funktionieren – werde ich nachher gleich mal testen und berichten!

@cmb: guter Punkt, damit hatte ich aber bisher zum Glück nie Probleme.
Aber genau wie jeder Profi auch mal vergisst, den Cache zu leeren, sollte man generell „nie nie sagen”. ;)

Also nochmal vielen Dank und ich melde mich nachher gleich nach Test.
Ciao
Michael

Let's Encrypt!

Michael_G
Posts: 185
Joined: Thu Feb 18, 2016 11:01 pm
Contact:

Re: Moved_XH: Eigene Fehlerseiten nutzen?

Post by Michael_G » Tue Apr 19, 2022 4:31 pm

Nachtrag:

Nochmals getestet habe ich das Ausblenden mittels // in der Datei NotFoundController.php;
relevant ist hier die 3. Zeile dieses Ausschnitts: $title = $this->lang['title_notfound'];

Code: Select all

		} else {
			$this->statusHeader('404 Not found');
			//$title = $this->lang['title_notfound'];
			$url = urldecode($su);
			if (!$this->isUtf8($url)) {
				$url = $su;
			}
			(new View('moved'))
				->template('not-found')
				->data(['url' => $url])
				->render();
			$this->log404();
		}
Habe es auch nochmal anders probiert, nämlich die Zeilen mit $title ganz entfernt und weil das auch nicht wie gewünscht funktionierte, auch den Aufruf

Code: Select all

	public function defaultAction()
	{
		global $su, $title;
geändert in …

Code: Select all

	public function defaultAction()
	{
		global $su;
… damit hier gar nichts mehr für den $title läuft.
Aber anscheinend ist $title noch an anderer Stelle im laufenden Programm aktiv und so findet das Script wieder seine Datei nicht und zeigt wieder als h1-Überschrift „Fehler 404 – Seite nicht gefunden” (meint aber wohl nicht die zum Testen absichtlich falsch eingetippte nicht gefundene Seite, sondern seine eigene PHP-Seite?!).

:!: Wenn man da nicht wüsste, dass ein anderer Titeltext erscheinen muss, würde man meinen, es funktioniert.

Es wird: „Fehler 404 – Seite nicht gefunden” als h1-Überschrift angezeigt.
Aber das kommt irgendwie daher, dass das PHP-Script seine Datei nicht findet …

@lck: Leider hat Dein neuer Snippet-Vorschlag doch nicht funktioniert, weil in der PHP-Datei keine Style-Syntax funktioniert.
Zwar ist in der Originaldatei HTML-Code <p>…</p>, aber die funktionierende Modifikation ist reines PHP, welches externes HTML aufruft. Daher gibt es leider nur eine FM, dass der Befehl „display” (für display:none) unbekannt ist.

Übrigens ist mir bei der ganzen Aktion auch noch aufgefallen, dass die beiden Plug-ins Moved sowie das dafür erforderliche Pfw nicht für PHP 8.1 bereit sind.
Ich ließ meine Websites schon mindestens zwei Monate mit PHP 8.1 laufen, aber wenn man im Plug-in-Menü des Adminmenüs Moved aufruft, erscheint folgende Meldung:

Code: Select all

DEPRECATED: Return type of Pfw\View\ArrayViewValue::current() should either be compatible with Iterator::current(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:31
DEPRECATED: Return type of Pfw\View\ArrayViewValue::next() should either be compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:47
DEPRECATED: Return type of Pfw\View\ArrayViewValue::key() should either be compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:39
DEPRECATED: Return type of Pfw\View\ArrayViewValue::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:63
DEPRECATED: Return type of Pfw\View\ArrayViewValue::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:55
… und wenn man dann Pfw aufruft, sieht es ähnlich aus:

Code: Select all

DEPRECATED: Return type of Pfw\View\ArrayViewValue::next() should either be compatible with Iterator::next(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:47
DEPRECATED: Return type of Pfw\View\ArrayViewValue::key() should either be compatible with Iterator::key(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:39
DEPRECATED: Return type of Pfw\View\ArrayViewValue::valid() should either be compatible with Iterator::valid(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:63
DEPRECATED: Return type of Pfw\View\ArrayViewValue::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
/var/www/===anonymisiert===/plugins/pfw/classes/View/ArrayViewValue.php:55
Also habe ich auch noch über das Providermenü meine Websites auf die empfohlene PHP-Version 8.0 zurückgestellt, um es damit nochmal zu testen.

Fazit: keine Veränderung beim Verhalten der Fehlerstatusseiten (wenigstens lag es dann wohl nicht an PHP 8.1).

Nicht schlimm, denn mein Wunsch, eigene noch professioneller aussehende 404- und 410-Seiten nach neuesten Webdesign-Erkenntnissen nutzen zu können, wurde dank eurer raschen Mithilfe trotzdem rasch wahr. :D
Ciao
Michael

Let's Encrypt!

Michael_G
Posts: 185
Joined: Thu Feb 18, 2016 11:01 pm
Contact:

Re: Moved_XH: Eigene Fehlerseiten nutzen?

Post by Michael_G » Tue Apr 19, 2022 5:56 pm

cmb wrote:
Tue Apr 19, 2022 11:57 am
Der Browsercache sollte hier irrelevant sein; allerdings vermute ich, dass ein PHP Bytecode-Cache (vermutlich OPcache) aktiv ist. Je nach Einstellung, kann es dauern, bis dieser aktualisierte PHP-Dateien erkennt (unter Umständen "ewig"). Im Zweifel mal in der PHP-Info (Einstellungen → Info → PHP-Info) nachschauen, was da konfiguriert ist.
Habe auch noch die OPcache-Einstellungen meines Providers UD Media nachgeschaut:
Über ca. 2 Monate bis vorhin hatte ich PHP 8.1 genutzt, da ist OPcache laut PHP.ini-Seite nicht aktiv (kein OPcache-Eintrag).
Unter PHP 8.0 ist der (Zend) OPcache aktiv, aber zur Speicherdauer ist auf der PHP.ini-Seite nichts zu finden.
Ciao
Michael

Let's Encrypt!

Michael_G
Posts: 185
Joined: Thu Feb 18, 2016 11:01 pm
Contact:

Re: Moved_XH: Ausgabe auf eigene Fehlerseiten möglich?

Post by Michael_G » Sat Apr 23, 2022 9:24 pm

Nachtrag: Zusammenfassung mit komplettem Lösungsweg (für Apache-Webserver)

Frage/Problem:
1. Ich verwende seit Jahren eigene Fehlerseiten. Diese werden Besuchern aber nur angezeigt, wenn diese eine Webadresse ohne Fragezeichen eintippen. Echte CMSimple_XH-Seiten enthalten aber ein ? und dann zeigt das Plug-in Moved_XH nur einen zweizeiligen Text anstelle der eigenen hilfreichen hübschen Fehler-404-Seite.
2. Nachdem ich es geschafft habe, dass Moved_XH meine Fehlerseite anzeigt stelle ich fest, dass es weiterhin stur die h1-Überschrift über der Überschrift meiner Fehlerseite anzeigt. Das ist doppelt und sehr unschön.
Ich könnte die h1-Überschrift meiner Fehlerseite weglassen, aber ich bin Perfektionist.

:idea: Antwort/Lösungsweg (auch für Anfänger geeignet):
Basis für eigene Fehlerstatus-Seiten ist dieser Eintrag in der .htaccess-Datei im Hauptverzeichnis der CMSimple_XH-Installation (root):

Code: Select all

# Nette Fehlerseiten
	ErrorDocument 403 /?403
	ErrorDocument 404 /?404
	ErrorDocument 410 /?410
:idea: Tipp für mehrsprachige Websites:
Erstelle eine .htaccess-Datei mit folgendem Text in Deinen Sprachordnern (also z. B. de und en), hier die de-Version:

Code: Select all

DefaultLanguage de

# Nette Fehlerseiten
	ErrorDocument 403 /de/?403
	ErrorDocument 404 /de/?404
	ErrorDocument 410 /de/?410
In CMSimple_XH legst Du mittels PageManager (Admin-Menü „Seiten”) pro Sprache mindestens die Seiten 403 und 404 an, besser auch gleich die 410.
Diesen verpasst Du dann einen schönen Erklärungstext (inspirierende Beispiele findest Du massenhaft mittels Suchmaschine; Suchbegriff „eigene Fehlerseiten entwerfen”).

Besonders wichtig für die 404 (HTTP Nicht gefunden), denn damit bedienst Du Deine Besucher/Kunden, welche nicht gleich abwandern sollen.
– Aufmunternde tröstende Worte, eine Suchmaske und ein paar Links (zur Startseite, zur Sitemap und ggf. Hilfeseite) helfen, dass der Besucher nicht wütend die Fehlerseite verlässt …

Wer mag, macht das auch für die 410 (HTTP Gone).

Die 403 (HTTP Verboten) bedarf keiner großen Mühe, da genügt die offizielle Erklärung a la Wikipedia.

:!: Damit diese Fehlerseiten auch für Seitenaufrufe ohne das für CMSimple_XH notwendige Fragezeichen korrekt verarbeitet werden, fügst Du in der Quelltextansicht folgenden Text ein:
Seite 403:

Code: Select all

<div>#cmsimple header('HTTP/1.0 403 HTTP Forbidden');#</div>
Seite 404:

Code: Select all

<div>#cmsimple header('HTTP/1.0 404 Not Found');#</div>
Seite 410:

Code: Select all

<div>#cmsimple header('HTTP/1.0 410 Gone');#</div>
:!: Damit das alles nachher auch zusammen mit dem Plug-in Moved_XH perfekt funktioniert, kopierst Du die fertigen Seiten 404 und 410 und vergibst dafür folgende Namen: 404 -> Kopie 4o4 (in Worten: vier-o-vier). 410 -> 41o (in Worten: vier-eins-o).
Bei diesen Kopien löschst Du die h1-Überschrift heraus, denn diese wird vom Plug-in und ansonsten von CMSimple_XH eingefügt (lässt sich nicht verhindern, daher die Seitenkopien als effektiver Workaround).

Wenn Du in der Sonderzeichenersetzungstabelle von CMSimple_XH auch Großbuchstaben beim Speichern von Webseiten in Kleinbuchstaben verwandeln lässt, kannst Du als Seitennamen 4O4 (großes O - sieht eher wie eine Null aus) und 41O verwenden.
Beim Speichern der Seite werden diese dann zu 4o4 und 41o.

Beliebige andere Namen wären auch möglich, aber vielleicht schwerer zu merken bzw. einheitlich zu halten.
Es hätte auch einfach „Not-Found” und „Gone” funktioniert, denn es geht hier nur darum, nicht die vorhandenen 404 und 410 zu verwenden (Problem: doppelte Überschrift).

Gleich sind wir fertig, nun geht es um die Dateien in Moved_XH, Menüpfad aus Deinem Hauptverzeichnis:
plugins/moved/views

Hier bitte die Dateien not-found.php und gone.php zuerst an andere Stelle sichern (falls etwas schief geht oder das alles auf Deinem Webserver nicht funktioniert und Du alles rückgängig machen musst).
Danach ersetzt Du den Inhalt der Datei not-found.php mit folgendem Inhalt:

Code: Select all

<?=newsbox('4O4')?>
Achtung, das ist nicht vier-null-vier, sondern vier-O-vier (Großbuchstabe O in der Mitte)!

Und in der Datei gone.php ersetzt Du den Inhalt mit folgendem Text:

Code: Select all

<?=newsbox('41O')?>
Achtung, das ist nicht vier-eins-null, sondern vier-eins-O (Großbuchstabe O am Ende)!

:!: Der Trick ist folgender: wenn eine interne Webseite von CMSimple_XH (also mit Fragezeichen) falsch eingetippt wird, wird die Fehlerseite mit der speziellen Schreibweise aufgerufen, in der Du die h1-Überschrift weggelassen hast. Denn die fügt das System immer ein und das wäre sonst doppelt.

Ruft jemand eine Webseite ohne das notwendige Fragezeichen auf, wird die „normale” 404-Seite aufgerufen, in der Du eine h1-Überschrift hast (also semantisch korrekter Aufbau mit h1, dann h2, dann Text).

Hier sind wir beinahe fertig, aber wenn die h1-Überschriften angepasst werden sollen, bitte auch noch die Sprachdateien on Moved_XH kontrollieren oder ändern:
Menüpfad: plugins/moved/languages
Die Datei de.php sieht bei mir nach Modifikation in den beiden relevanten Zeilen so aus:

Code: Select all

$plugin_tx['moved']['title_notfound']="Fehler 404";
$plugin_tx['moved']['title_gone']="Fehler 410";
und die Datei en.php sieht bei mir nach Modifikation in den beiden relevanten Zeilen so aus:

Code: Select all

$plugin_tx['moved']['title_notfound']="Error 404";
$plugin_tx['moved']['title_gone']="Error 410";
Das kannst Du gern anders machen, denn die Geschmäcker sind verschieden. Aber Du sollst wissen, wo die Stellschrauben des Systems sind, um die eigene Kreativität nicht auszubremsen.

Hier noch eine Ergänzung für alle, die eine mehrsprachige Website mit 2 Domains auf einem Apache-Webserver betreiben:
Damit Besucher bei fehlerhafter Seitenabfrage ohne das CMSimple-typische Fragezeichen die Fehlerseite in ihrer Sprache erhalten, bitte noch die .htaccess um folgenden Code erweitern (Beispiel für Deutsch + Englisch, ggf. anpassen):

Code: Select all

# Fehlenden Sprachordner (de|en) einfügen
	RewriteCond %{REQUEST_URI} !^/(de|en)		[NC]
	RewriteCond %{HTTP_HOST} ^deutsche-domain\.	[NC]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ /de/$1  	[R=301,NE,QSA,L]

	RewriteCond %{REQUEST_URI} !^/(de|en)		[NC]
	RewriteCond %{HTTP_HOST} ^englische-domain\.	[NC]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule ^(.*)$ /en/$1	[R=301,NE,QSA,L]
Wer sich das zutraut, kann das auch von der Browsersprache des Besuchers abhängig machen.
Dann verwende stattdessen diesen kürzeren Code:

Code: Select all

# Spracherkennung + Hauptdomains | läuft bei mir seit 28.03.2022
	RewriteCond %{HTTP:Accept-Language} ^((?!en).)*de	[NC]
	RewriteCond %{QUERY_STRING} !filebrowser(.*)		[NC]
	RewriteRule ^$ /de/					[R=301,L]

	RewriteCond %{HTTP:Accept-Language} ^((?!de).)*en	[NC]
	RewriteCond %{QUERY_STRING} !filebrowser(.*)		[NC]
	RewriteRule ^$ /en/					[R=301,L]
Vorteil: Das funktioniert auch mit nur einer Domain.
Nachteil: Google sowie fast alle anderen Online-Testtools arbeiten mit fest eingestellter Browsersprache Englisch, daher werden diese keine fälschlicherweise ohne Sprachordner abgefragten deutschen Seiten finden bzw. als fehlerhafte Links melden/anzeigen.
Das musst Du dann berücksichtigen und zur Fehleranalyse in Deinem Browser (mit hinterlegter Sprache Deutsch) testen.

Beispiel: Du hast eine Webadresse https://example.com/de/?software
Ein deutscher Besucher gibt falsch ein: https://example.com/?software
Dank Browserspracherkennung wird das zu: https://example.com/de/?software
Ein englischer Besucher gibt falsch ein: https://example.com/?software
Dank Browserspracherkennung wird das zu: https://example.com/en/?software
Wenn Du die Seite „Software” in beiden Sprache angelegt hast, ist alles super.
Wenn Du diese Seite aber nur in Deutsch angelegt hast oder wenn es ein Wort ist, welches nicht in beiden Sprachen gleich ist, wird die Seite von internationalen Besuchern nicht gefunden.

– Kein echtes Problem, denn wir haben ja schöne eigene Fehlerseiten in jeder Sprache angelegt.
Oder Du hinterlegst in der Tabelle von Moved_XH (/content/en/moved.csv) eine Umleitung vom deutschen Wort auf den korrekten Pfad der passenden englischen Seite.
– Aber das sollte man im Hinterkopf behalten. Und im Text der Fehlerseite 404 erwähnen, dass Deine Website Inhalte auch abhängig von der Browsersprache ausliefert.
Ciao
Michael

Let's Encrypt!

Post Reply