Support-Forum Mirko Böer Softwareentwicklungen

zu 1. \".hataccess & allow_url_fopen\"

#kopfkratz

Setting wo falsch - irgendwas auf \"777\" setzen oder \".htaccess\" umschreiben?

Das Problem \"kommt nix/weisse Seite\" tritt leider ja nicht nur bei der Fehlerseite auf. #seufz

allow_url_fopen ist eine Option für PHP selbst, diese kann man bei gemieteten Webspace eigentlich nicht ändern. Die .htaccess hast du oder irgendwer selbst erstellt, die könnte man ändern aber muss man nicht wenn man die Weiterleitung erzwingt.

Zu 2. [AltBrowserLink]

Ohjajetzt. Vielen Dank. Ich dachte/früchtete, ich müsste wesentlich komplexer noch einen Upload machen und ggf. Zugriffe für das Skript administrieren.

Nein beim SuperWebMailer ist das alles mit drin, muss man sich keine Gedanken machen oder noch irgendwas hochladen.

Verständnis-Frage dazu:
Funktioniert das nur auf Basis hochgeladener Vorlagen oder auch im Editor angelegter Seiten?
[<= Klingt sicherlich befremdlich, nur will ich Dkünfitge enkfehler durch Verständnis der Skript-Mechanik ausschließen.]

Die Frage verstehe ich nicht. Der Browserlink funktioniert nur in E-Mails und nur wenn man den Platzhalter VOR dem Versand einfügt. Der notwendige HTML-Code für den Browserlink wird im Hintergrund archiviert, das ist der gleiche wie der für den Newsletterarchiv-Eintrag.

Hallo Mirko,

zu 1. \".hataccess & allow_url_fopen\"

#kopfkratz

Setting wo falsch - irgendwas auf \"777\" setzen oder \".htaccess\" umschreiben?

Das Problem \"kommt nix/weisse Seite\" tritt leider ja nicht nur bei der Fehlerseite auf. #seufz



Zu 2. [AltBrowserLink]

Ohjajetzt. Vielen Dank. Ich dachte/früchtete, ich müsste wesentlich komplexer noch einen Upload machen und ggf. Zugriffe für das Skript administrieren.

Verständnis-Frage dazu:
Funktioniert das nur auf Basis hochgeladener Vorlagen oder auch im Editor angelegter Seiten?
[<= Klingt sicherlich befremdlich, nur will ich Dkünfitge enkfehler durch Verständnis der Skript-Mechanik ausschließen.]



Auf jeden Fall schon mal ein \"großes Danke schööön\" bis hier hin.


Viele Grüße

Spectator

Frage:
Was mag ich falsch gemacht haben?
Der Aufruf auf dem Webserver in meiner Webpräsenz angelegter Seiten hat per Eintrag der spezifischen URl nicht funktioniert, ohne dass ich die # gelöscht hätte.

Was habe ich getan?
Ich habe vollständige URL (mit http und allem zipp&zapp) in die Standard-Meldungen eingetragen.
Ok, da steht ODER. Verstanden.
Also habe ich die URL wieder raus genommen (gelöscht) und habe eigene Meldungen angelegt, die dann nur die URL enthalten.
Dem Skript habe ich mitgeteilt, dass es diese Seiten nun anstatt der vorbereiteten Standardseiten aufrufen soll. Die Einstellugn wurde auch evrarbeitet, die angelegten Seiten werden als \"in Benutzung\" o.ä. angezeigt. {Sueprtoll übrigens, dass bei der Entwicklung hieran gedacht wurde, diesen Hinweis zu zeigen. Danke.}

Aber ... die Seiten \"liefen\" trotzdem nicht. Es kam stattdessen eien weisse Browserseite, das Skript war stehen geblieben auf nl.php.

Das Skript bleibt nicht stehen, wenn ich die # entferne, bei Verwendung der selben vollständigen URL.

Wo habe ich mich also verrannt, wenn das Löschen von # als sehr atypisch gilt?

Du hast sicher nichts falsch gemacht aber auf manchen Servern, gerade bei gemieteten Webspace, klappt das Laden der externen Seiten manchmal nicht. Das ist der Fall wenn allow_url_fopen deaktiviert ist, das wird aber abgeprüft und automatisch das ForcePageRedirect angewendet, oder der Server liefert einfach nichts zurück bzw. es wird eine Umleitung per .htaccess intern gemacht. Es bleibt in dem Fall nur ForcePageRedirect zu verwenden. Das ForcePageRedirect würde ich aber nicht verwenden, zumindest nicht für die Fehlerseite, alle anderen Seiten ist in Ordnung.

Bonuskommentar mit Frage:
Es gibt im Manual Verbesserungspotenzial zum thema \"Anzeige von Alt_Browserlinks\". Zumindest habe ich nichts gefunden, was mir den \"Werdegang\" bis zum gewünschten Ziel erörtert.
Gibt\'s ein Kapitel dazu oder muss ich \"trial & error\" über HTML-Vorlage gehen?

Wie meinst du das? Du musst nichts machen, außer den Platzhalter [AltBrowserLink] in die HTML- oder Text-E-Mail hinschreiben bzw. aus der Platzhalter-Auswahlbox auswählen. Den Rest macht SuperWebMailer alleine, muss man sich nicht drum kümmern.

Danke sehr für die wie immer superzügige Antwort.




Ich lasse die anderen # drin.


Frage:
Was mag ich falsch gemacht haben?
Der Aufruf auf dem Webserver in meiner Webpräsenz angelegter Seiten hat per Eintrag der spezifischen URl nicht funktioniert, ohne dass ich die # gelöscht hätte.

Was habe ich getan?
Ich habe vollständige URL (mit http und allem zipp&zapp) in die Standard-Meldungen eingetragen.
Ok, da steht ODER. Verstanden.
Also habe ich die URL wieder raus genommen (gelöscht) und habe eigene Meldungen angelegt, die dann nur die URL enthalten.
Dem Skript habe ich mitgeteilt, dass es diese Seiten nun anstatt der vorbereiteten Standardseiten aufrufen soll. Die Einstellugn wurde auch evrarbeitet, die angelegten Seiten werden als \"in Benutzung\" o.ä. angezeigt. {Sueprtoll übrigens, dass bei der Entwicklung hieran gedacht wurde, diesen Hinweis zu zeigen. Danke.}

Aber ... die Seiten \"liefen\" trotzdem nicht. Es kam stattdessen eien weisse Browserseite, das Skript war stehen geblieben auf nl.php.

Das Skript bleibt nicht stehen, wenn ich die # entferne, bei Verwendung der selben vollständigen URL.

Wo habe ich mich also verrannt, wenn das Löschen von # als sehr atypisch gilt?




Bonuskommentar mit Frage:
Es gibt im Manual Verbesserungspotenzial zum thema \"Anzeige von Alt_Browserlinks\". Zumindest habe ich nichts gefunden, was mir den \"Werdegang\" bis zum gewünschten Ziel erörtert.
Gibt\'s ein Kapitel dazu oder muss ich \"trial & error\" über HTML-Vorlage gehen?


Vielen Dank & beste Grüße
Spectator

Nichts weiter an den define-Anweisungen in der userdefined.inc.php löschen, das ist nur für \"Profis\" die bestimme Dinge damit machen wollen bzw. auch zur Aktivierung des Debug-Modus. Diese speziellen Dinge sind nur über diese eine Datei aktivierbar, nicht über die Oberfläche selbst, damit es nicht zu viele Einstellungsoptionen werden.

Die Aktivierung von ForcePageRedirect sollte man normalerweise nicht aktivieren, dann dann etwaige Fehlermeldungen z.B. E-Mail-Adresse fehlerhaft nicht angezeigt werden. Besser ist es im SuperWebMailer die anzuzeigenenden Seiten zu definieren und keine Umleitungen auf externe Seiten zu verwenden, denn in den internen Seiten werden immer die Meldungen angezeigt. In externen Seiten geht das nur wenn SuperWebMailer diese problemlos laden und anzeigen kann.

Original von Mirko:
in der userdefined.inc.php vor define(\"ForcePageRedirect\", 1); das Raute-Zeichen (#) entfernen und dann mal probieren.

Guten Morgen.

Mein Hoster ist d)f.
Nach dem Entfernen der # läuft es auch bei mir.


Hmtja.
Ich bin unsicher.



1. Ich habe also nun manuell die Releasefähigkeit beeinflusst.
Beim nächsten Update sollte ich unbedingt daran denken, die # wieder zu entfernen, damit auch alles wie vorgesehen und bis dahin gewohnt wieder läuft.
#seufz

2. Da ich das swm-Skript erst nach und nach in Betrieb nehme, frage ich mich natürlich, an welchen Stellen ebenfalls noch Dysfunktionen auftreten werden, welche auf eine # zurückzuführen sein werden.


Frage:
In der o.a. Datei gibt es noch weitere \"define\" mit # davor.

Sollte ich die vorsichtshalber einfach alle löschen?
Kann ich die vorsichtshabler einfach alle löschen?



Bitte richtig verstehen:
Das Skript ist absolut grandios und in weiten Teilen auch für mich \"als interessiertem Laien\" ein kinderspiel in der Administration, der Funktionsumfang und die Leistungsfähigkeit beeindrucken mich sowieso, war ja schon bei der SM-Version so.
Aber - ich mache hier zZ sehr viele Dinge zum ersten Mal oder seit langer Zeit wieder Mal.
Wenn ich nun eine # irgendwo stehen habe, die mich wieder einen 3/4 Tag Arbeitszeit kostet, bis ich sie als \"point of failure\" eingegrenzt habe, dann wird das zum mehr als ärgerlichen \"running-gag\".
Wie sollte ich also nun weiter verfahren?


Mit allerbesten und im Grunde ja doch begeisterten Grüßen

Spectator

Jetzt geht\'s! Vielen Dank!

in der userdefined.inc.php vor define(\"ForcePageRedirect\", 1); das Raute-Zeichen (#) entfernen und dann mal probieren.

Folgendes Problem:

Unter Website -> HTML-Seiten/Umleitungen habe ich für die An- und Abmeldebestätigungen eigene URL\'s angebeben. Soweit so gut. Diese URL\'s werden, wenn ich Sie direkt im Browser aufrufe, korrekt angezeigt.

Wenn ich mich nun jedoch über das Formular an/abmelde, wird zwar im Hintergrund alles richtig abgearbeitet (d.h. ich kriege z.B. die Email mit dem Bestätigungslink), allerdings werden die URL\'s mit den Bestätigungen nicht angezeigt, weil der Browser in der Datei nl.php hängenbleibt.

Da ich diese Problem auf anderen Umgebungen, wo Superwebmailer läuft, nicht festgestellt habe, vermute ich, dass es an einer PHP- oder sonstigen Einstellung dieses betreffenden Webservers liegt.

Haben Sie eine Ahnung, wo das Problem liegen könnte? Wie gesagt: Die An- und Abmeldung funktioniert bis und mit Eintrag in die Verteilerliste korrekt, nur die Bestätigungsseiten werden nicht richtig angezeigt, was für den User natürlich verwirrend ist.

Besten Dank zum voraus für Ihre Antwort!