Veröffentlichen von Fotos und Grafiken mit https unmöglich !?

Das Problem der unvollständigen Veröffentlichung ist auf RW sehr gross! Achtung!! - Es hängt mit sog. “gemischten Inhalten” (sowohl http wie https gelandenen) zusammen, die auf https veröffentlicht, eine völlig unbrauchbare Darstellung bringen. Setzt man die URL auf http zurück, so werden Grafiken, Bilder, Logos, Headers nicht richtig übernommen.

Nach mehreren Stunden TeamViewing mit dem sehr hilfsbereiten Provider-Support ist es auszuschliessen, dass von seiner Seite die Lösung erfolgen kann. Es muss vom RapidWeaver-Support kommen, der jedoch sich ahnungslos zeigt (oder meine Englischkenntnisse nicht ausreichen, ihm eine Ahnung zu vermitteln). Das Ganze hat viele Tage Arbeit gekostet, wobei das Problem ungefähr Ende 2017 auftrat (zuvor vier Jahre keine Probleme mit fast täglichen Website-Änderungen). Mir graut es davor, die nicht ganz kleine Website mit einem neuen Programm neu aufbauen zu müssen. Das letzte, was mir abschliessend heute der Host-Support mitteilt, ist dies. Vielleicht gibt es jemanden, der mir aus Erfahrung zielführend weiterhelfen kann. Das wäre ein Glücksfall.

Supp: Leider fehlt uns das Knowhow um dieses Problem zu lösen. Da von unserer Seite her nicht klar ist
wie der RapidWeaver die Dateien aus den Resourcen entfernt bzw. wie sich nicht mehr benötigte
Dateien “un-publizieren” lassen. Dies müssten Sie mit einem Techniker von RapidWeaver prüfen.

Ich: Im Forum zum RapidWeaver-Programm dies gefunden, was für Sie hoffentlich
aussagekräftiger ist:
http://forums.realmacsoftware.com/t/ssl-mixed-content-security-error-due-
to-fonts/10872
http://forums.realmacsoftware.com/t/ssl-mixed-content-security-error-due -to-fonts/10872 und:
http://forums.realmacsoftware.com/t/ssl-and-image-warehousing-on-a-separa
te-none-ssl-server/13431/4
http://forums.realmacsoftware.com/t/ssl-and-image-warehousing-on-a-separ ate-none-ssl-server/13431/4

Support: Das Abändern der Links von http auf https im ersten Artikel ist dass worüber wir gestern am Telefon gesprochen haben. Ich ging davon aus, dass es eine Funktionalität des RapidWeavers gibt welche dies vor dem Publizieren vor nimmt. Falls jedoch sämtliche Dateien lokal abgeändert und erst dann hochgeladen werden müssen bleibt Ihnen wohl leider nichts anderes übrig.

Wenn ich mich an Letzteres machen sollte - wie finde ich und woran erkenne ich die “lokal abzuändernden Dateien”?

1 Like

So richtig weiß ich nicht genau, was Du zum Ausdruck bringen möchtest!?

Ich habe schon dutzende RW Webseiten von http auf https umgestellt und noch nie irgendwelche Probleme gehabt.

Hast Du https auch im RW Projekt eingestellt?
Und kannst Du mit einfachen Worten sagen, was das genaue Problem ist.
Und eine URL wäre sehr sehr hilfreich.

Gruß

Viele, die RW seit einigen Jahren betreiben, haben eine http-URL. Wenn diese nun einen von RW empfohlenen online-Shop wie etwa Ecwid anstelle von RapidCart hinzufügen wollen, so geht dies nur mit Umstellung auf eine zertifizierte https-Seite. Wenn dies nun geschehen ist, gibts Problem alleweil, von denen vielleicht im deutschen Bereich noch nicht viel, im englischen jedoch häufig die Rede ist.

Denn die Browser melden dann „gemischte Inhalte“ (d.h. ungesicherte) und geben keine korrekte Darstellung (der über SFTP hochgeladenen Inhalte). Wenn man den Schutz vorübergehend auflöst - was bei Firefox leicht zu machen ist, bei Safari nicht unbedingt - so ist die Darstellung korrekt, aber ohne die neuen Änderungen.

Das heisst, dass das RW-Programm am besten eine Voreinstellung haben müsste, durch die alles auf https-Modus geändert werden kann. Ansonsten muss man bei jedem Pic oder jedem Link nachschauen gehen, ob diese zertifiziert oder unzertifiziert hochgeladen wurde.

Behelfsmässig hat der Provider eine vorübergehende Einstellung vorgenommen, welche dazu führt, dass alle Aufrufe über https://www.das-seminar.ch https://www.das-seminar.ch/
automatisch als http://www.das-seminar.ch http://www.das-seminar.ch/ sichtbar werden.

Das kann nur vorübergehend sein, weil der Ecwid-Shop so nicht läuft.

Ich würde mich freuen, wenn jemand, welcher die Erfahrung kennt, antworten könnte.

Reto Andrea Savoldelli

Das kann doch aber nur ein Problem sein, wenn du Assets extern (d.h. per Warehousing) auf einen HTTP-Server ausgelagert hast. Ich selbst habe die Mehrzahl meiner Seiten auf HTTPS ohne jedes Problem umgestellt, allerdings sind meine Assets auch nie auf externe Server ausgelagert. Eine seltene Ausnahme mag es bei externen Scripts geben

RapidWeaver schreibt intern eigentlich sämtliche URLs um, wenn du in den General Settings die URL von http auf https umschreibst

Was hast du denn für eine Einstellung für die Verlinkung? Hast du das auf “Relative to Page” oder auf etwas anderem stehen stehen?

1 Like

Danke für die nochmalige Erklärung. Mir sind solche Probleme Gott sei Dank nicht bekannt.

Ich gehe davon aus, das im Projekt die URL auf https gestellt ist. Ja, natürlich muss jeder Link, der irgendwann mal auf der Website gesetzt wurde, geändert werden. Das habe ich bei meiner eignen Seite mal machen müssen … da muss man sich Zeit nehmen und übersieht hier und da mal immer einen Link. Mit entsprechenden Tools kann man das überprüfen lassen.

Ich würde, nachdem das gründlich geschehen ist, alle zu ersetzende Dateien der Website auf dem Server löschen und das Ganze neu hochladen. Aus meiner Kenntnis bleibt kein http nach … außer man hat Links übersehen und nicht manuell nachgearbeitet. Aber das RW das irgendwann ganz alleine macht … kann ich mir kaum vorstellen. Das gleiche gilt für Seiten mit www und ohne www.

Nebenbei: So ganz sauber ist Deine Website nicht aufgebaut…

Vielleicht findet sich hier ja jemand, der Dir weiterhelfen kann. Viel Glück!

1 Like

Ich wollte mir gerade deine Seite anschauen, aber das ist ein bisschen schwierig, weil alle Aufrufe der sicheren Version auf die unsichere umgeleitet werden. Auch die internen Verlinkungen beginnen somit alle mit http:// Insofern ist die Fehlersuche nicht so einfach

1 Like

Noch ein Nachtrag:

Vielleicht hilft dir das weiter: https://httpschecker.net/guides/https-checker

2 Likes

Ich habe hier noch etwas zum Thema geschrieben:

(Fast) keine Probleme mit RapidWeaver bei der Umstellung von Webseiten auf HTTPS

Besten Dank! Das ist vermutlich eine Hilfe. Bitte diesen Satz korrigieren: Du musst deinen Server also zwingen, Aufrufe von “https//” auf “https://” umzuleiten.

Es grüsst,
R.A.Savoldelli

Das ist eine sehr wertvolle Hilfe für viele. Ich weiss nicht, warum sich so wenige mit diesem Problem hier äussern. Aber dass ich wahrlich nicht allein bin, ist klar. Das müsste auch die RW-Produzenten sehr interessieren, die damit verbundenen Probleme leicht lösbar zu machen. Sonst springen doch viele auf Programme um, die damit besser umgehen (wie ich es mir auch überlege.)

Ich denke, Du erwartest da etwas zu viel. Auf welches Programm würdest Du denn umspringen wollen, wo das alles sich von alleine reinigt!?
Du hast doch bei apfelpurer gelesen, das sich viele Fehler auch in den Themenvorlagen “verstecken”. Und in ausgelagerten Dateien - auf verschiedenen Servern verteilt. Ist doch auch irgendwie logisch, wenn sich dort “Links” befinden, die noch auf http verweisen … vor noch nicht mal allzu kurzer Zeit liefen die meisten Webseiten unter http …

Warum sich so wenige zu diesem Thema äußern, hat sicher etwas mit dem Grundproblem von RapidWeaver zutun:

Einst als reiner DIY-Programm konzipiert, ist daraus ein Programm geworden, das komplexen Anforderungen genügen kann und muss. Und das Web und seine Anforderungen sind im Laufe der Jahre immer komplexer geworden. Der RapidWeaver-Nutzer kommt da nicht mehr mit und glaubt immer noch, das Webseiten erstellen so etwas wie Plakate kleben im Internet ist.

Und so sehen manche Webseiten dann halt auch aus. Selbst wenn es an der Oberfläche ganz gut hinhauen mag, gruselt einen mitunter der Blick auf das Backend. Das Ignorieren von Dingen wie SSL gehört dazu und ich bin sicher, das so mancher RapidWeaver-Nutzer mit diesem Kürzel gar nicht anfangen kann. Also wird er auch gar keine Notwendigkeit sehen, entsprechende Fragen zu stellen.

Danke Apfelpuree für die offene Antwort. Ich sehe es genau so. Umso mehr freut mich Deine Hilfsbereitschaft hier.

@rasavol
Was siehst Du genauso?
Das Deine Website technische Mängel aufweist und sogar die Oberfläche nicht gerade glänzt?

Das allgemeine bashing von RW Nutzern (Anfängern - mal eben eine Website bauen wollen) nutzt keinem etwas. Dafür ist RW nun mehr oder weniger ausgelegt.
Jeder kann auf eine andere Möglichkeit umsteigen, leider blieb meine Frage dahin auch unbeantwortet: auf welches Programm möchtest Du umsatteln?

@apfelpuree
Das sich so wenige zu diesem Thema hier äußern hat meiner Meinung mehr damit zu tun, das hier grundsätzlich kaum etwas los ist. Ansonsten ist das Thema SSL nicht jedermanns Sache, wenn man nicht gerade “professionell” unterwegs ist… und mit RW kann man professionell arbeiten (kleine u. mittlere Projekte), es richtet sich aber zuerst an “Anfänger”. Wäre das nicht so, dann könnte man sich selbst saubere Webseiten bauen, weil man ja die Grundlagen von Web-Programmierung mit HTML, CSS und JavaScript beherrscht … und bräuchte RW nicht.

1 Like

Danke dir Michael, das war ein guter Tipp :grinning:

Ich hab jetzt nicht alle Freds gelesen, möchte aber gerne meinen Senf dazu geben, da ich just gestern auf das “Verlinkungsproblem” mit den Bildern gestossen bin. Und. Ich habe es gemeinsam mit einem “klassischen” Programmierer von Typo3-Seiten gelöst bekommen.

ALLE Links kommen jetzt über https.

Das Problem liegt beim hosten oder Einbinden der Bilder.
Wenn die Bilder “gewarehoused” sind, ist das ein relativer Pfad. Sind die Bilder direkt im RW eingebunden,
ist es ein absoluter Pfad. In dem 2ten Fall ist es am Einfachsten. In den Publishing-Settings und den Settings den Pfad durch https://deinedomain.* ergänzen und alles ist gut.

Sind die Bilder von einem anderen Server oder aus dem resources-Ordner von RW geladen (warehouse)
müssen all diese Links per Hand geändert werden. Eine Fleissarbeit, aber machbar. Heisst: Bild anklicken, ein “s” im Link hinter “http” ergänzen. Dann "republish all files. Ist alles sauber gemacht, hat die Browserzeile ein grünes Schloß vorne. Wenn nicht muss man mit der Konsole überprüfen wo noch Bilder oder Schriften aus http geladen werden. Ich sag ja: mühsam :wink:
Und nicht die Partials vergessen, da sind gerne mal Logos drin.

Ich hoffe, ich habe keinen unsinnigen Senf dazugegeben und konnte dem ein oder anderen helfen.

Gruß

Thomas

Solange ein RapidWeaver-Projekt so angelegt ist, dass die Links relativ sind (General Setting > Advanced > File Links are Relative to Page), brauchst du, wenn du die Basis-Adresse auf https:// umstellst, hinsichtlich der internen Links, d…h auch bezüglich der Links auf Dokumente, die im Resources-Verzeichnis abgelegt sind, gar nichts zu tun. Die in dem Projekt angelegten Links auf Dokumente, die im Resources-Verzeichnis liegen, werden automatisch überschrieben.

Das manuelle Umschreiben ist lediglich bei extern abgelegten Assets nötig, wenn also die Bilder z.B. auf einem anderen Server liegen - und das auch nur, wenn sich die Zieladresse geändert hat

Insofern verstehe ich deinen Post nicht so ganz

1 Like

Hallo Michael,

(General Setting > Advanced > File Links are Relative to Page), brauchst du, wenn du die Basis-Adresse auf https:// umstellst, hinsichtlich der internen Links, d…h auch bezüglich der Links auf Dokumente, die im Resources-Verzeichnis abgelegt sind, gar nichts zu tun.

Genau so war/ist die Einstellung gewesen.
Ich habe dann die Adresse (https) in den General Settings und im Publishing Setting geändert.
In den resources hat RW das auch geändert. Bild1

Bild1

Aber in der Link in den Stack Settings stand noch http Bild2 allerdings schon geändert.
Dadurch sind die Bilder immer noch von http geladen worden.

Bild2

Erst nachdem ich diesen Link (je Bild geändert habe, wurden ALLE Bilder von http geladen.

btw.: ich habe beim Support vom Joe Workman nach gefragt, ob es eine schnellere Methode gibt.
Hier die Antwort:

Hello Thomas,
Sorry to say I do not know of any way to make it go any faster, this is the one draw back to doing warehoused images, if you switch from http to https. Especially if you use a LOT of images.

Aber ich werde mal ein Testprojekt im RW7 bauen und mit den Advanced Settings spielen.

Also wenn ich mir deine Beschreibung anschaue, gehts du beim Warehousing auf das Resources-Verzeichnis so vor, dass du die Links als URLs anlegst und nicht als relative Links direkt auf das Resources-Verzeichnis. Wenn du direkt auf das Resources-Verzeichnis verlinkst, sollten die Links auf https:// geändert werden, wenn du die Basis-URL entsprechend änderst. Wenn du mit URLs arbeitest (was ich für recht umständlich ansehe und eigentlich nur bei extern abgelegten Assets nötig ist), musst du natürlich zu Fuß nachbessern

Hmmmm,

warum mach ich das so… ich hab in einem Tutorialvideo gesehen, dass es ein schneller Weg ist,
wenn man in den Resources-Ordner geht, das Bild markiert, rechtsklickt, “Copy URL”

46

Das kopier ich dann in den Link für das warehoused image

Jetzt, mit https ist ja alles richtig, aber ich würde schon gern wissen, warum zeigt das tutorial es so, wenn es doch offensichtlich zu Problemen führt. Führen viele Wege nach Rom und jeder hat da seine eigene Wahrheit?
Oder ist der Fehler, wie immer VOR der Tastatur

Gut, das ist nun einmal passiert, aber wenn man viele Bilder hat, ist das eine Höllenarbeit.
Und dann: warum schreibst du “Asset:”

Ich bin nicht tief genug im Coding um sagen zu können ich hätte Ahnung. Deswegen nutze ich den RW, weil er für Leute wie mich ideal ist. Mein Wissen zieh ich dann aus den Tutorials :wink: