Beiträge von Stefan S

Also das normale Navigationsmenü erhält ja all seine Einstellungen zentral aus den Layout-Einstellungen.

Das Widget "Navigation" ist von uns eigentlich nur für Ausnahmen, wie z.B. One-Pager etc. gedacht und da ist es wie bei allen anderen Widgets auch, jede Instanz hat seine eigenen Einstellung. Daran werden wir auch sicherlich mittelfristig nichts ändern. Also im Problemfall liber einfach das im Layout-Enthaltene Navigationsmenü nutzen, oder ein Widget "Navigation" entsprechend vererben (dabei werden ja auch die Farbeinstellungen etc. mit vererbt).

Hallo,

ob alle benötigten PHP-Module / -Funktionen vorhanden sind, sollte von "Website-Features prüfen" erkannt werden. Also am besten zunächst mal "Extras > Optionen > Aktionen > Website-Features prüfen" ausführen.

Danach dann im error.log des Web-Servers schauen ob es da mehr Details zum fehlerhaften Formularversand gibt.

Wenn das nix bringt, bitte im Formular in "Optionale Einstellungen" nach unten scrollen und die Option "DEBUG Ausgabe" aktivieren (nicht vergessen, das später wieder zu deaktivieren). Danach dann veröffentlichen, das Formular "live" absenden und ggf. die Debug-Ausgabe beachten.

Auf diese Art sollte man eigentlich genau ermitteln können, was schief läuft.

Andre G. ich antworte im von Ihnen neu geöffneten Beitrag: ZP14 > Formular > Could not instantiate mail function.

Hallo,

das kann ich so nicht bestätigen. Wenn ich das nachstelle, übernimmt die Kopie die aktuellen Layout-Einstellungen. Nach dem Kopieren des Layouts müssen die Seiten allerdings neu erstellt werden. Das passiert normalerweise automatisch. Vielleicht hilft bei Ihnen "Erweitert > Erstellen > Alle Seiten erstellen"?

Hinweis: Kopierte Layouts profitieren nicht mehr von Updates. Wenn wir also Fehler in unseren Layouts beheben, wirken sich diese Korrekturen nicht auf kopierte Layouts aus. Für diese Layouts sind Sie dann selbst verantwortlich.

Aktuell kenne ich da keinen Schalter um dies zu unterbinden. Kann nicht auch sein, dass dies schon länger so läuft, aber bisher nicht vom SiteGuard überwacht wurde? Kann man den SiteGuard nicht konfigurieren, damit er bestimmte Verzeichnisse ignoriert?

Nach Rücksprache habe ich noch folgende Informationen:

zp-server ist ein Backend-Prozess (mit Version 14 eingeführt) über den unter Anderem auch Backups auf dem Webserver gesichert werden können. Damit dieser Prozess funktioniert, werden in regelmäßigen Abständen UpdatePrüfungen (für den verwendeten Code) mit unserem zentralen Server durchgeführt.

Ich denke, das ist die Ursache für die Dateizugriffe, denn die Kommunikation mit zp-server wird in Log-Dateien protokolliert…

Hallo,

prüfen Sie in Ihrem (Ihren) Projekt(en) bitte mal: "Erweitert > Erweiterte Einstellungen > Cloud". Ist da die Option "[BETA] Synchronisation über eigenen Server" ggf. aktiviert?

Falls nicht, könnten uns die Einträge in einer der log*.txt Dateien Aufschluss geben.

Meiner Meinung ja. Dass sind ja Query-Strings (beginnt mit ?) und diese sind nicht Bestandteil des Pfades einer URL. Am Verhalten von .html-Seiten haben wir mit den in diesem Artikel erwähnten Einstellungen eh nichts verändert.

Die SMTP-Option in den Formular-Einstellung sollte das Problem mit sehr hoher Wahrscheinichkeit auch umgehen und wäre die präferierte Lösung.

Das Zusenden und analysieren von Projekten bieten wir eigentlich nur im Rahmen eines Premium-Support-Ticket an, daher kam der Vorschlag nicht gleich. Bei hohem Support-Aufkommen, fehlt uns oft einfach die Zeit für nicht sachbezogene Kommunikation und wir erwarten einfach, dass uns überlassen wird, wie wir helfen und ggf. unsere Fragen beantwortet werden. Das führt dann eigentlich auch immer zu einer Lösung.

Pete Ja, das Problem betrifft (zumindest wenn Apache als Webserver verwendet wird) anscheinend alle PHP-Seiten, egal, wie diese erstellt wurden. Ja, sie haben die Lösung richtig verstanden. Bei angehängten Pfaden tritt dann ein 404-Fehler (Seite nicht gefunden) auf, wenn der Pfad nicht existiert. Welche Fehlerseite dann angezeigt wird, hängt von Ihren Webserver-Einstellungen ab.

In Ihren Einstellungen hatten Sie ja als Fehlerseite bereits die Zeta Producer Seite "Seite nicht gefunden" definiert. Damit diese korrekt angezeigt wird, ist die Lösung aus Antwort 21 notwendig.

Ihre Formular funktioniert gerade auf Ihrem Server nicht. Also muss die Seite auch dort getestet werden. Es wäre ein schlechter Test, Ihre Seite auf einem anderen Server mit völlig anderer Umgebung und Webserver-Einstellungen zu testen. Das würde zu nichts führen.

Wenn Sie eine Lösung wollen, biete ich Ihnen an uns das Projekt (inkl. funktionierender FTP-Einstellungen) zu senden (das FTP-Passwort können Sie gerne vor und nach meinen Tests ändern), damit wir das Projekt ansehen können und ein paar Tests auf dem Server durchführen können. Wenn Sie das auch nicht möchten, kann ich wirklich nicht helfen, weil mir schlicht die Datenbasis dazu fehlt, den Fehler zu ermitteln.

Falls Sie uns das Projekt zusenden möchten, geht das so:

1. Öffnen Sie Ihr Projekt in Zeta Producer
2. Gehen Sie auf das Menü "Extras"
3. Klicken Sie auf den Button "Optionen"
4. Klicken Sie auf "Aktionen"
5. Klicken Sie rechts auf die Aktion "Projekt Senden" damit diese Markiert ist
6. Klicken Sie unten auf den Button "Ausführen"
7. Geben Sie im 1. Feld Ihre E-Mail-Adresse ein, damit wir Sie für Rückfragen kontaktieren können
8. Geben Sie als Referenz ins Feld Bemerkungen den Link zu diesem Forum-Artikel ein (per Kopieren und Einfügen)
9. Klicken Sie auf den Button "Senden"

Ihre Kritik bzgl. meinem Ton können Sie gerne weitergeben. Ich fand meinen Ton bisher aber absolut sachlich und kann auch nicht erkennen, welche Aussage "unhöflich" gewesen sein sollte.

Ah, ok. Meiner Meinung nach war die Ursache für das Verhalten bezüglich URLs zu php-seiten mit angehängtem Müll geklärt. Das konnte ich auf all unseren Servern so reproduzieren, unabhängig von irgendwelchen .htaccess-Einstellungen. Das Problem scheint also php generell zu haben, was man aber mit der in Antwort 24 geschilderten Einstellung umgehen kann. Problem Nummer 2 sind ja lediglich die relativen URLs in der Fehlerseite aus dem Zeta Producer Projekt, was man über das erwähnte Attribut beheben kann.

Wird aber langsam auch schwierig in diesem Thread noch durchzublicken. Vielleicht mache ich mir die Mühe und schreibe eine Zusammenfassung und schließe das dann hier.

Vielleicht das Leerzeichen zwischen "!" und "important" entfernen?

Hallo newbusinessvision ,

auf dieser Basis kann ich Ihnen leider nicht helfen.

Ah, ok. Verstehe wahrscheinlich nicht, was Du genau testen willst.

Die Fehlerseite funktioniert aber bereits bestens, das muss m.E. also nicht nochmals isoliert getestet werden.

Andre G. keine Ahnung. Wer kennt schon den Google Algo.

Das heißt, Sie haben nun eine funktionierende Lösung. Gut.

Muss mich korrigieren, AcceptPathInfo scheint noch nicht zu greifen, siehe https://www.erma.ch/News.php/blah.php da müssen Sie sich mal beim Provider erkundigen, wie die Einstellung am besten zu machen ist.

Sie können den Seitentyp ruhig auf .php lassen. Mir war nur nicht verständlich warum dies so ist. Es so zu lassen ist sicher einfacher als alles umzuleiten, damit man das google ranking nicht verliert…

Also bei https://www.erma.ch/falscher-ordner/falsche-seite.php erhalte ich jetzt korrekt "Seite nicht vorhanden…"

Die vorgeschlagenen Änderungen für die .htaccess werden es ja gerade verhindern, dass jemand auf derart falsche Links kommt und dass die "Seite nicht gefunden" ohne CSS und mit falschen Links angezeigt wird.

Scheint bei Ihnen auch zu greifen, Sie sollten vermutlich nut vor dem Testen Ihren Browser-Cache löschen.

Ok, das Feld für die Menge können Sie im Warenkorb aber nicht per CSS ausblenden, weil diese Regel ja nur für manche (aber nicht alle) Artikel gilt, richtig?

Und warum beantworten Sie meine Fragen nicht?

Genereller Hinweis: Provider passen Ihre Sicherheits-Einstellungen und Restriktionen, wie z.B. die Einschränkung auf von Ihnen gehostete E-Mail-Adressen (oder Adressen, die über das Verwaltungs-Interface eingestellt sind), immer wieder mal an. Über solche Änderungen könnten wir gar nicht informieren, weil uns diese Änderungen nicht bekannt sind.

newbusinessvision Wie ist denn Ihre Webadresse und bei welchem Provider sind Sie denn?

Maler 1 ist die sogenannte Branchen-Vorlage. Das verwendete Layout ist "Flat Responsive" und da verhält es sich, wie in meiner 1. Antwort beschrieben.

PS: wir speichern keine Benutzernamen und können daher auch nicht nachsehen, wie diese wohl lauten.

Grundsätzlich ist mir nicht klar, wie Sie denn auf die URL https://www.erma.ch/News.php/Plakatstaender.php kommen? Diese wird ja wohl nicht von Zeta Producer generiert, oder? Wenn diese nur in der Search-Console angezeigt werden, kann es sein, dass jemand anders einen falschen Link auf Sie gesetzt hat, und der sollte ggf. korrigiert werden.

Mir ist auch nicht klar, warum anscheinend all Ihre Seiten die Dateierweiterung .php haben.

Zitat von Pete

- warum leitet das bei mir nicht auf die "Seite nicht gefunden" um?

- warum wird das Layout nicht geladen

- warum zeigt es die Links in diesem "komischen Format" an (https://www.erma.ch/News.php/Plakatstaender.php)

1. Das tut es schon, wenn es nicht um .php Seiten geht. Beispiel https://www.erma.ch/falscher-ordner/falsche-seite.html

2. Das wird es, wenn es nicht um .php Seiten geht. Beispiel https://www.erma.ch/falscher-ordner/falsche-seite.html

3. Weil die Regel bezgl. AcceptPathInfo aus irgend einem Grund noch nicht greift. Hierzu ggf. den Web-Hoster kontaktieren, kann sein, dass er diese Einstellung per .htaccess nicht erlaubt oder so.

Ich weiß jetzt auswendig nicht mehr, welches Layout Sie nutzen etc., aber in manchen Layouts ist das der Fall, wenn in der 1. Menüebene so viele Einträge sind, dass diese nebeneinander nicht mehr auf die Seite passen, oder ein Untermenü enthält, dessen Höhe größer als die Höhe des Browserfensters ist (notwendig, weil z.B. wegen fixiertem Menü nicht gescrollt werden kann).

Wir bieten ja keine wirkliche Benutzerverwaltung. Das Passwort gilt jeweils für alle Geschützten-Seiten mit dem selben Bereichsnamen, Schnittmengen über Bereiche hinweg sind daher nicht möglich.

Wie haben Sie es denn für die Artikel umgesetzt? Das ist mir noch nicht ganz klar.

Das ist technisch nicht möglich (da Zeta Producer die Einstellungen hierfür verwaltet). Das Passwort kann nur in Zeta Producer geändert werden, was ja irgendwie auch zusätzliche Sicherheit bietet.

Zitat von Pete

gilt diese Anleitung jetzt auch für mich (Seiten sind ja mit php) und meine Seite geht ja gar nicht zur "Seite nicht gefunden"?

Laut Ihrer .htaccess haben Sie als 404-Seite auch die Zeta Producer Seite "Seite nicht gefunden" gesetzt. Sie können also beide Vorschläge umsetzen.

Die AcceptPathInfo-Einstellung ist von uns nicht getestet. Sollte Ihr Shop mit dieser Einstellung nicht mehr funktionieren oder andere Probleme entstehen, entfernen Sie die Einstellung einfach wieder.

Zitat von Unknown

Gilt dies allgemein oder jetzt speziell auf Pete sein Post?

Dies gilt nur für Nutzer, die es stört, dass man an URLs, die auf eine gültige .php-Seite verweisen auch noch irgendwelchen Mist anhängen kann ohne dass dies in einem 404-Seite-Nicht-Gefunden-Fehler resultiert. Dies betrifft aber den jeweils genutzten Webserver und hat mit Zeta Producer zunächst mal gar nichts zu tun (wir haben trotzdem geholfen).

Das Verhalten bezgl. der PHP-Seiten kann mit folgendem Eintrag in der .htaccess behoben werden:

<Files ~ "\.php$">
AcceptPathInfo Off
</Files>

Für diejenigen (z.B. Mario), die über ihre .htaccess die 404-Seite auf die von Zeta Producer erstellte Seite "Seite nicht gefunden" eingestellt haben, hilft dieses Vorgehen:

• Wechseln Sie in Zeta Producer zur Seite "Seite nicht gefunden" oder was Sie sonst als 404-Seite festgelegt haben
• Doppelklicken Sie links im Seitenbaum auf diese Seite
• Klicken Sie auf "Attribute"
• Klicken Sie unten auf den Button "Attribute" und wählen Sie die Option "+ Neu"
• Geben Sie als Namen folgendes ein: make-all-rendered-urls-absolute
• Geben Sie ins Feld darunter folgendes ein: true
• Klicken Sie auf den OK-Button um das neue Attribut für diese Seite zu speichern.
• Klicken Sie auf den OK-Button um die seitenbezogene Attributsverwaltung zu schließen.

Nun werden alle URLs auf dieser Seite Absolut ausgegeben, was eine Fehlerfreie Darstellung zur folge haben sollte auch wenn in der URL auf nicht existierende Verzeichnisse verwiesen wird…

Hallo,

die Fragen im FAQ-Widget werden in der in den Layout-Einstellungen festgelegten Linkfarbe angezeigt. so ist für den Nutzer auch gleich zu erkennen, dass er die Frage anklicken kann, eben wie jeden Link auch.

Wenn Sie dafür trotzdem unbedingt eine andere Farbe wählen möchten, geht das nur über angepasstes CSS:

• Klicken Sie im Menü Website auf "Einstellungen"
• Klicken Sie auf CSS
• Fügen Sie folgende Textzeilen (ohne Überschrift und ohne Zeilennummern – am besten über das Dokumente-Icon rechts oben im Quellcode-Kasten kopieren) in das Feld "CSS" ein und schließen Sie den Dialog dann mit Klick auf "OK"

<style>
    .zpSO-faq-question a{
        color: rebeccapurple !important;
    }
</style>

("rebeccapurple" einfach durch die gewünschte Farbbezeichnung, einen RGB, RGBA oder Hex-Wert ersetzen…)

Anschließend müssen Sie evtl. Ihre Seiten neu erstellen (Erweitert > Erstellen > Alle Seiten erstellen) und ggf. veröffentlichen.

Siehe auch: Fehlermeldung bei ZP14-Start

Ich glaube nicht, dass wir das Problem mit .php Seiten lösen können, weil es nicht durch uns zu entstehen scheint. Das scheint wirklich schon in der PHP Webserver-Erweiterung zu entstehen. Das einzige, was wir tun können, ist zu vermeiden, dass derart falsche Links von unserem Programm generiert werden. Dass dem so ist, wäre mir aber neu.

Ich würde da ggf. einfach mit Varianten arbeiten. Variante 25er Pack, 50er Pack etc. Dadurch würde sich die Mengenangabe dann jeweils auf die Anzahl Packs beziehen und das sollte ja auch gut funktionieren.

Das scheinen beides die im Projekt angegebenen Fehlerseiten zu sein, die mit relativen Links arbeiten. Durchnage erfundenen Verzeichnisse ( der Slash) kommen alle relativen Links durcheinander und daher die falschen URLs und fehlendes CSS etc. Das Problem bei den .php Seiten ist ein anderes.