Beiträge von Synonym

Don't use directories to create a new store. You should always point another domain or sub domain to your hosting.

Das ist völlig richtig so, denn technisch wäre alles andere ein Fehler. Der Browser sendet bei einer Anfrage den angeforderten Host mit, immer. Das ist eben genau der Punkt, wo der Apache dann prüft, ob er dafür überhaupt zuständig ist. Das prüft der aber auf Basis von Hosts, nicht von Ordnern.

Auch in Sachen DNS. Man kann kein anderes Ziel oder DNS für einen Ordner haben, für eine Domain oder Sub schon. Bzw. der Apache macht das dann. Das ist dann das "%{HTTP_HOST}%". Aber eben nur den Host. Also shop1.domain.de shop2.domain.de Darüber erfolgt ja die Erkennung, was angefordert wurde. In HTTP_HOST steht aber kein Ordner dabei. Also http://domain.de/shop1/ und http://domain.de/shop2/ sind im HTTP-Header als HOST schlicht beides domain.de

Das ganze Zeug mit den Hosts ist ja nur intern und per DNS bzw. eben als sichtbare Domain dann im Browser. Wenn man das mit einem Ordner machen würde, dann müsste ja auch in der URL jeweils "shop1" oder "shop2" stehen. Und das geht eben auch nicht, denn die Multistores sind ja alle gleich vom URL-Aufbau her, nur die Domain ist eine andere. Der Pfad aber identisch. Würde mit Ordnern im Pfad nicht gehen.

Ganz normal, rein regulär hätte man ja

Domain-alt -> Docroot-alt -> Files von alt

Domain-neu -> Docroot-neu -> Files von neu

Dann hätteste aber zwei verschiedene Installationen, die völlig eigenständig sind. Das willste ja nicht, daher docroot ändern. Dabei komtm dann eben das raus

Domain-alt -> Docroot-alt -> Files von alt

Domain-neu -> Docroot-neu -> Files von neu (Gibt es nicht, muss ja auf "alt" zeigen)

Du hast keine zwei htaccess. Wenn Du das hast, dann ist da schon ein Fehler im ersten Schritt.

Du hast bisher Domain-alt. Die zeigt auf Docroot /var/www/domain-alt

Dann schaltest Du eine zweite Domain auf, domain-neu. Die hätte ja per default einen anderen Docroot, also was wie /var/www/domain-neu. Genau das muss ja geändert werden, denn Du willst ja die gleiche Installation haben wie vorher. Daher das in der Anleitung, Bild 1.

Dann zeigen beiden Domänen auf den alten Docroot "/var/www/domain-alt" und in dem liegt eben nur eine htaccess, eben die alte, die schon immer da lag. Daher die erforderlichen Änderungen an der, denn die muss dann ja auf mehr reagieren oder eben nicht.

Du hast dann physisch mehrere Hosts / Domänen, aber nur EINEN Docroot. Die neue Domain hat keinen eigenen Webspace, keine eigene htaccess, die nutzte das vom Hauptshop, der die Grundinstallation ist.

Alles was dann auf den Seiten selbst anders ist, das macht dann das CMS selbst. Also eventuell andere Bilder etc. Das legt das CMS dann entsprechend in andere Ordner oder benennt sie anders. Es ist und bleibt dann aber physisch alles im Docroot "/var/www/domain-alt".

Und doch, das was da in dem Link oben von mir steht müsste genau so gehen. Was da nur fehlt ist das Thema htaccess und da weiß ich eben nicht, ob das dann das CMS selbst machst, wenn Du da einen neuen Store hinzufügst oder ob Du das manuell machen musst, weil vorher auch manuell gemacht.

Also technisch braucht man dazu auch nicht mehr.

Unabhängig vom CMS, wenn da mehrere Domänen oder Subs auf einen Host zeigen passiert ja schlicht nichts anderes als

Anfrage an "index.php" kommt rein. Das CMS muss nun prüfen, für welche Domain das reinkommt und dann entsprechen ausliefern.

Das was Du da mit den IDs hattest, macht das CMS hier nun wohl einfach mit dem Host direkt, der wird bei jeder Anfrage ja im Header gesendet. Also "biste shop.domain.de oder web.domain.de oder shop.anderedomain.ch". Genau genommen musste das Magento auch so machen, denn die müssen ja auch unterscheiden, welche Domain angefragt wird. Der Browser kennt die IDs ja nicht, der sendet nur den angefragten Host.

Der Punkt ist nur, dass zwischen "Anfrage" und "CMS" eben auch die HTACCESS ist. Wenn das CMS diese automatisch anpasst, wenn man eine weitere URL dort hinterlegt, dann gut. Wenn das aber nicht automatisch passiert, dann muss man das per Hand machen.

Denn mit HTACCESS ist das ja

Anfrage an "index.php" kommt rein. HTACCESS schaut nach, ob das http://www.domain.de ist. Wenn nicht, leitet die weite an .de. Dann erst kommt das CMS und filtert aus der Anfrage: "Ah, Anfrage für .de", also DE-Shop ausliefern.

Die Konstellation ist ja Anfrage / Browser -> htaccess -> CMS. Das CMS wertet aus, was der Browser angefragt hat. Nur wenn die htaccess das vorher umwurschtelt, dann kommt das eigentlich angefragte am CMS nie an.

Bei dem Link oben steht das eigentlich alles drinnen. Dort als Beispiel mit der Sub. Das ist aber technisch für das CMS egal, ob das eine andere Sub ist oder eine andere Domain, beides sind andere Hosts. Das mögliche Problem mit der HTACCESS hat man also bei beiden Varianten. Auch wenn da eine anfrage über sub1.domain.de reinkommen würde, würde die htaccess sagen "nee, du bist nicht http://www.domain.de" ich leite weiter.

Und das andere ist eben der Server. Der Host ist ja pauschal an eine Domain gebunden, also an domain.de bzw. http://www.domain.de. Die haben den gleichen Docroot. Da musste entsprechen eine weitere Domain / Sub mit anlegen. Als Alias oder sonst wie, kommt auf das Interface an, das wird aber Alex wohl sagen können. Und das eben, wie bei ohne und mit www auch, auf das gleiche Docroot. Dann haste drau verschiedene Hosts auf dem gleichen Docroot, die alle drei auf die gleiche htaccess zugreifen. Daher muss die eben dann auch für alle drei passen und nicht nur für "nicht oder mit www".

Und das macht eben eigentlich alles Plesk / htaccess und CMS

Bei einer anderen Domain ist das technisch. Domain anlegen -> DNS-A-Record auf die Hauptseite zeigen lassen.

Dann dem Host der Hauptseite beibringen, dass der nun eben auch auf die "neue Domain" reagieren soll. Das ist das mit dem Alias wie bei "host und http://www.host".

Dann der htaccess beibringen, dass da eben nun eine Anfrage mit einem anderen Host kommen kann und die gültig ist. Also "neue-Domain" ist gültig und darf nicht weitergeleitet werden an die alte.

Ab dann übernimmt das CMS.

Sind also drei Bereiche:

1. DNS und Host. Das übernimmt eigentlich Plesk, also DNS einrichten und eben den vorhandenen Host um eine weitere Sub oder Domain erweitern.

2. Server-Config. Das ist das Thema htaccess

3. CMS-Config. Das ist dann nur, wie das CMS eben auf unterschiedliche Anfragen von unterschiedlichen Hosts reagieren soll.

Zu Deinem zweiten Problem. Es wird nicht klar, wer hier weiterleitet, aber hast Du auch die Htaccess entsprechend geändert?

Wenn Du domain.de und domain.ch hast und beide auf den gleichen Docroot zeigen, dann musste natürlich (in der Regel) auch die htaccess ändern, denn die ist dann ja die gleiche bei beide Domänen, in der Regel aber nur für eine ausgelegt.

Sprich. da ist ja bestimmt was drinnen wie "wenn nicht http://www.domain.de" oder nicht "SSL", dann leite weiter an SSL-domain.de. Genau das würde ja auch greifen, wenn da nun ein eigentlich erfolgreicher Zugriff von der domain.ch kommt. Das würde so eine Rule auch auslösen und entsprechend weiterleiten auf die domain.de.

Es darf dann also in der htaccess nichts sein, das explizit auf eine bestimmte Domain weiterleitet. Das muss dann alles variabel sein im Sinne von: Wenn es von .de kommt, dann an .de leiten. Kommt es von .ch, dann an .ch leiten.

Also so was da darf dann nicht vorkommen:

Denn das leitet ja explizit alles, was nicht domain.de ist eben ausdrücklich an domain.de weiter. Da kannste so also unendlich mit ner domain.ch drauf zugreifen, die RewriteCond sagt da immer "nee, Du bist keine "http://www.domain.de", also leite ich dich mal an "http://www.domain.de" weiter.

So was musste dann in zwei Teile trennen und jeweils ergänzen als

RewriteCond %{HTTP_HOST} domain.de
RewriteCond %{HTTP_HOST} !^www.domain.de$
RewriteRule ^(.*)$ https://www.domain.de/$1 [R=301,L]

RewriteCond %{HTTP_HOST} domain.ch
RewriteCond %{HTTP_HOST} !^www.domain.ch$
RewriteRule ^(.*)$ https://www.domain.ch/$1 [R=301,L]

Der erste Block greift dann nur, wenn "domain.de" aufgerufen wurde, aber nicht "www". und der Zweite, wenn "domain.ch" aufgerufen wurde, aber nicht "www". Und jede hat dann ihr eigenes Ziel, nämlich einmal .de und einmal .ch.

Die erste Zeile prüft also immer nur, ob es überhaupt eine entsprechende TLD ist, egal ob ssl, www oder sonst was. die domain.TLD muss stimmen. Erst die zweite prüft dann wie vorher, ob das "www" fehlt. Wenn beides True ist, dann leitet sie in Zeile drei weiter.

Kommt man da also mit domain.ch drauf, dann wird Zeile 1, 2 und 3 ignoriert, da bereits Zeile 1 ein FALSE ergibt, denn es muss ja DE sein.

Auch so was wie Deine händischen Weiterleitungen müssten geändert werden, denn die haben ja auch eine bestimmte Domain als Ziel.

Also ich hab davon nicht wirklich eine Ahnung, aber Dein Ansatz 1 hört sich eigentlich nach dem richtigen Weg an. Dürfte wohl auch das hier sein, oder? https://docs.opencart.com/en-gb/administration/multi-store/

"weil der Server angeblich die DNS nicht auflösen kann."

das wäre der interessante Punkt. Warum sollte das der Server nicht können? Eigentlich ist das ja völlig schnuppe, was da dann als Daten kommt, Sub ist Sub. Ob die auf einen eigenen Docroot zeigt oder nicht ist auch eigentlich völlig egal. Ich könnte mir da höchstens vorstellen, dass es ein Problem mit SSL geben könnte, aber das auch nur eher gering. DNS sollte laufen und hat ja so gesehen nichts mit dem Shop zu tun.

Leg doch mal eine Sub mit eigenem Docroot an und schau, ob das geht. Wenn ja, dann Docroot auf den Hauptshop ändern und wieder schauen. Das sollte eigentlich alles kein Problem sein und ist im Prinzip die Minimalversion von jedem CDN, wo zig Subs auf einen identischen Docroot zugreifen.

Der Rest ist dann Sache von OpenCard, also was die dann für die jeweiligen Domänen ausspielen, aber OpenCard hat so gesehen ja mit DNS nichts zu tun.

Und ich lehne mich da mal aus dem Fenster. Das sollte auch mit einer anderen Domain gehen, also nicht nur mit einer Sub. Im Grunde hab ich das ja auch, wo von verschiedenen Domains (de, com, net jeweils verschiedene Subs img1, img2, img3) auf einen Docroot auf einem anderen Server zugreifen. Eben auch per DNS. Wobei das dann vom Server abhängig ist, ob die andere Domain überhaupt auf die Daten der Hauptdomain zugreifen darf. Aber technisch ist das schon möglich.

Wenn ich das nun richtig verstanden habe, dann möchte Bing die Nutzung des Chats wohl für normale Nutzer einschränken. Wie dem immer so ist, es übertreiben halt einige immer zum eigenen Nutzen. Die Einschränkung soll dabei wohl vor allem die Textlängen betreffen, nicht die Anzahl an sich.

So, das Oktober Update ist ja mittlerweile fertig. Ein anderes war auch schon dazwischen und nun läuft seit dem Abend des 2.11.23 das "November 2023 core update".

Und irgendwas hat mich am 21.9. erwischt. Da lief noch das Helpfull-Update

Da haste recht, das kann vorkommen, kenne ich zugute. Wobei das eher der Fall ist, dass da zu wenig ersetzt wird als zu viel. Wenn ich das oben richtig deute, dann kann das auch nur sehr bestimmte Dinge ersetzen. Wenn da irgendwas anders ist, dann bleibt es halt wie es war. Nochmal einen normale Suche drüber laufen lassen, ob der "Suchbegriff" weg ist sollte da reichen. Wenn nicht weg, dann hat der halt ein anderes Muster.

Aber ja, falsch oder fehlerhaft ersetzen, das hatte ich vor den Rohdaten mit dem CSS-Zeug. Das waren fertige Files, die dann mal in die DB kamen - an die 72.000 Stück. Und dann, jahre später, sollte umgestellt werden auf CSS3 mit Gradient etc.... Da sagte ich auch Danke.... Fertige Files, mal mit Leerzeichen nach dem : mal ohne, mal mit ; an der letzten Anweisung, mal ohne etc. Mal alles in einer Zeile, mal eine Zeile für Wert. Oder Daten, die der Kunde eingetragen hat im Sinne von "border-width: dicker" oder "color: dunkles rot". Oder trivial, aber korrekt, Farben als Hex mit 6 oder 8 Stellen, als rgb, rgba etc.

Da konnte man regex auch vergessen, zumindest in der DB. Das ging dann alles Stück für Stück in PHP ins JSON, dann alles bereinigen, was ohnehin falsch ist, neu sortieren, dass das alles die gleiche Reihenfolge hat und dann die einzelnen Werte und Klassennamen per regex holen. Fertiges JSON bilden und zurück in die DB als "Rohdaten". Daraus dann das fertige CSS machen und abspeichern. Bei der nächsten Änderung wieder JSON laden und eben anders machen

Problematisch also eigentlich immer dann, wenn man keinen fixen Start- oder Endwert hat. Teilweise auch mit HTML-Tags, wenn die verschachtelt sind, oder willkürliches Zeug wie ein HTML-Link, der in 100 Varianten aufgebaut sein kann. Aber so wie da oben ist das eigentlich kein Problem. Da gibt es nur zwei Möglichkeiten. Wird ersetzt oder eben nicht.

Zitat von Abakus Forumsfossil

Mit regex ein update ueber die ganze tabelle fahren ist eher was fuer leute, die gerne gefaehrlich leben

Warum? Wenn man die Tabelle vorher kopiert, einfach nur als neue Tabelle mit neuem Namen speichert, da braucht es noch nicht mal ein Backup, oder eben nur die Spalte kopiert und als Sicherung führt, dann dauert eine Wiederherstellung im Fehlerfall weniger als 30 Sekunden.

So mit den Rohdaten mache ich das selbst eigentlich auch, z.B. im Kalendersystem mit User CSS. Da ist auch alles Roh gespeichert, damit man das dann umwandeln kann wie man will und final als fertiges CSS in der Datenbank steht. Aber es geht an vielen Stellen schlicht nicht, da nicht vorhanden. Selbst die ganzen Posts hier im Forum gibt es nicht als Rohdaten. Sieht man sehr gut an den alten Posts, die schon 3 oder 4 Systemwechsel hinter sich haben und endlich Dinge nicht mehr funktionieren, weil die das System bei der Speicherung hinzugefügt hat. Das geht so weit, dass selbst Dinge wie Fettschriften mal als BB-Code drinnen stehen, mal als HTML. Absätze als HTML oder eben als \n\r etc. Bilder, als Bild-URL, aber auch als interner Code, der dann im Editor wieder als BB-Code kommt. Da gibt es also für das identische Bild drei Angaben. Bearbeiten kann man aber nur das, was in der Datenbank vorhanden ist und auch überhaupt dort ankommt.

Zitat von Alex07

Was man aber nicht vergessen darf ist, die Heizung muss gewartet werden.

Was ich gefühlt drei mal in meinem Post geschrieben habe, mit dem Zusatz, dass die Wartung einen Bruchteil kostet. Und eben keine monatliche Pauschale, bei der man sich nach 12 Monaten dennoch eine neue Heizung kaufen könnte.

Wenn der einen 4-stelligen Betrag berechnet, für Linkaufbau, also Offpage, dann ist das so. Das ist teuer. Onpage hingegen wäre es völlig überzogen und genau auf dem Trip sind SEOs meiner Meinung nach eigentlich immer. Erzählen dem Kunden, das muss so, muss gemacht werden, vom SEO, weil sonst kommste in die Hölle. Dass das aber oft Arbeiten sind, die man mit einer 2-Stündigung Einweisung selbst könnte, das wird einem nicht gesagt.

Und viele SEOs machen eben auch Aufgaben, die mit SEO absolut nichts zu tun haben. Gut, alles aus einer Hand, hat Vorteile, aber ob man dann auch die SEO-Stundensätze für Hilfsarbeitertätigkeiten zahlen muss, ist eine andere Frage. Das wird aber auch gerne als "Wartung" verkauft. Teilweise besteht es auch nur daraus, zwei mal im Monat in irgendwelche Tools zu sehen, einen PDF-Bericht erstellen zu lassen, ohne den auch nur ansatzweise selbst zu analysieren und dem Kunden zu erklären, warum weshalb, sondern einfach nur: Schau, minus, gefallen, nicht gut, Hölle und so. Seo muss was machen. Dabei wissen die selbst nicht, warum das gefallen oder auch gestiegen ist. SEOs arbeiten auch nur mit den Daten aus der Vergangenheit und haben genauso Null Plan, sind die sprichwörtliche Kuh vorm Berg, wenn Google ein Update gefahren hat.

Es gibt aber natürlich auch andere. Die senden einem auch ein PDF zu und eben einen 10-20 Seitigen Bericht dazu, was wo wie gemacht werden sollte und warum. Das ist dann eben die individuelle Analyse, zugeschnitten auf den Kunden und den Moment. Und überlassen es dann dem Kunden, ob der das selbst machen will oder eben den SEO machen lässt. In dem Fall wurde er für das PDF und eben dessen Auswertung mit Lösungsvorschlägen bezahlt. Das ist dann eine Dienstleistung, die in der Tat nützlich ist. Eigentlich sollte so was überall Standard sein, denn eine Auswertung erstellen lassen, ohne eine Erklärung oder Lösungsansätze dazu zu haben, kann man auch selbst nahezu kostenlos.

SEOs machen es sich meiner Meinung nach immer ganz einfach. Einen Vetrag, gerne Monate oder Jahre, hohe monatliche Summen, ohne aber auch nur ansatzweise ein Ziel zu haben, was erreicht werden muss. Wenn es nicht geschafft wird, dann halt "hoppla", ging nicht so, tut mir leid. Bei anderen Gewerken gäbe es eine Rückforderung der Zahlung oder Nachbesserung wegen Nichterfüllung.

Ohne da was genaueres zu wissen, kann man nicht viel bis gar nichts speziell zu dem Fall sagen.

Es gibt jedenfalls keinen Grund, da täglich, wöchentlich oder monatlich irgendwas an "Einstellungen" zu drehen.

Ich vergleiche das mal mit einer Heizungsanlage. Die neu einzubauen ist teuer. Damit die weiterhin gut funktioniert, muss sie gewartet werden. Die Wartung kostet jedoch nur einen Bruchteil einer neuen Anlage.

Der ROI selbst ist weniger wichtig. Er muss deutlich überschritten sein. 4000 Eur zu investieren, nur damit man 4000 Eur mehr hat macht keinen Sinn, denn da kommt 0 bei raus, der ROI ist aber erreicht. Der Gewinner bei der Rechnung wäre nur der SEO. Also muss da mehr bei rauskommen, als investiert wird und das eben monatlich in Bezug auf die Monate davor - davor, nicht zum Anfang, denn der Seo wird ja monatlich bezahlt.

Die Frage wäre da also, was in dem 4-stelligen Betrag enthalten ist, was der SEO da überhaupt tut. In vielen Fällen sind es schlicht ganz simple Dinge, die man selbst machen könnte, die die SEOs dann aber ganz gerne machen, weil es einfach ist und eben zu SEO-Stundenlöhnen abgerechnet wird. Also quasi so, wie ein Meistergehalt zu bezahlen, nur damit der die Baustelle fegt. Muss auch gemacht werden, keine Frage, dazu braucht man aber keinen Meisterlohn.

Wenn die Seite schon gut rankt, dann sind die eigentlichen Maßnahmen (Neuinstallation der Heizung) schon erfolgt, es folgt also nur noch Wartung. Daher aber eben die Frage, was in den Kosten enthalten ist. Einige dieser SEO haben z.B. auch nur Offpage-Pakete (Linkaufbau), die eben monatlich bezahlt werden müssen. Wenn man aussteigt, ist das, was vorher offpage gemacht wurde, wieder weg. Man kauft quasi nie eine derartige Dienstleistung, sondern mietet sie. Bei anderen behält man das, was man schon hatte, aber es kommt nichts neues dazu. Also auch hier wieder der Punkt, was in den Kosten enthalten ist. Wenn nichts neues mehr kommt, dann wird es langsam wieder nach hinten gehen, also das muss man schon weiter betreiben. Zumindest ist das abhängig von der Konkurrenz. Wenn man selbst nichts macht, die anderen aber schon, dann gerät man ins Hintertreffen. Kann man aber auch nicht viel zu sagen, wenn man den Markt nicht kennt. Aber es ist keinesfalls mehr der Aufwand, der anfangs war oder eben mit anderen Schwerpunkten, z.B. kein Onpage mehr und verstärkt Offpage, Linkaufbau, SocialMedia etc.

Allerdings verkaufen einem SEOs gerne diese monatlichen Wartungen zu völlig überzogenen Preisen. Die Hauptarbeit ist schon gemacht und ja, zurecht teuer bezahlt, aber dann ist nicht mehr sonderlich viel, denn das Ausgangsmaterial ist dann ja deren eigenen Arbeit. Wenn die also gut war, dann gibt es nicht mehr viel zu machen, außer Wartung eben.

Alles was Onpage gemacht wurde, sagt ja schon der Name aus, ist auf Deiner Seite. In dem Fall auf der Webseite, Deinem Wordpress und somit in Deiner Datenbank. Das verliert man nicht, das ist ja da. Dafür gibt es auch keine App oder so was, um das zu exportieren. Warum auch? Das ist in Deiner Datenbank, genauso wie Deine Texte, Bilder und sonstiges Zeug. Das ist also auf Deinem Webspace und in den Backups.

Ob die getätigten OnPage-Maßnahmen aber nach x Monaten / Jahren noch wirken oder aktuell sind, ist eine andere Frage. Es gibt jedenfalls aber keinen Grund, das, was erst kürzlich gemacht wurde, einen Monat später wieder zu ändern. In so einer kurzen Zeit hat man noch nicht mal die Möglichkeit, Veränderungen in den Suchmaschinen überhaupt zu erkennen.

Machen einige SEOs aber gerne, Stunden anhäufen, und halt immer wieder das Gleiche machen. Oder sie haben selbst keine Ahnung und testen einfach aus, was geht und was nicht. Lassen sich dann aber natürlich alles bezahlen. Wie ein Maler, der 4 Stunden Tapeten an die Wand klebt, sie wieder abreist, noch mal 4 Stunden hinklebt und dann 8 Stunden berechnet.

Und gerade bei Wordpress ist Onpage ja alles in Wordpress. Entweder direkt im eigentlichen Wordpress oder eben in AddOns dazu. Gibt je gerade bei Wordpress unzählig viele, damit man das eben (selber) machen kann. Der Seo hat vielleicht bessere Erfahrungen, aber wie schon gesagt, was schon gemacht ist, ist schon gemacht. Der SEO kann einen Text vielleicht besser optimieren, aber ob der für SEO-Lohn auch einen schreiben muss, ist die andere Frage. Updates von Wordpress kann man auch selbst machen, oder einen Webmaster beauftragen. Das ist ja nur rein technisch, im besten Fall ein Klick auf einen Button und fertig, wenn alles problemlos läuft. Ob man dazu SEO-Stundenlöhne bezahlen muss....

Onpage gehört also ohnehin Dir, ist auf Deiner Seite.

Auf Offpage haste keinen Einfluss. Kann bleiben, kann stagnieren, kann komplett wegbrechen, je nach Vertrag.

Um wieder bei der Heizung zu sein. Anfangs hat mein einen Modernisierungsauftrag, danach dann nur noch einen Wartungsvertrag.

Du merkst also.... Ohne zu wissen, was in der monatlichen Summe genau enthalten ist, also zukünftig, nicht in der Vergangenheit, kann man nicht "viel" sagen.

Irgendwie verstehe ich nicht, was Du meinst. Du willst doch einen normalen Button, der ohne das ganze JS von FB und Co funktioniert. Also so wie das oben von heiseonline.

Das ist doch ein reiner HTML-Link. Der macht doch nichts anderes, als wenn Du bei FB direkt die URL in einen Post kopierst.

Bei FB selbst, oder per HTML ala

https://www.facebook.com/sharer/sharer.…en-handel.de%2F

passiert doch genau das gleiche. In beiden Fällen kommt dann der FB-Bot und holt sich das Bild bei Dir, das per OG hinterlegt ist.

Zitat von catcat

Versuche ich aber die Billo-Lösung mit ner Zeile JS, dann habe ich nur die URL im Posting.

Was willst Du denn sonst haben? Diese Sharer teilen alle nur einen Link. Irgendwie verstehe ich genau dieses Punkt nicht oder wir reden aneinander vorbei.

Das liegt aber an Deinem Shop, CatCat. Du gibst auf der Produktseite ja das Bild genau so für Facebook, also OpenGraph vor.

<meta property="og:image" content="https://www.seiden-handel.de/image/cache/catalog/seidenstoffe/crepe-de-chine//crepe-de-chine-08-1-600x315h.webp"/>
<meta property="og:image:width" content="600"/>
<meta property="og:image:height" content="315"/>

Genau genommen ist das auch nicht quadratisch, sondern rechteckig, das Bild hat nur links und rechts Weißraum:

https://www.seiden-handel.de/image/cache/ca…-1-600x315h.jpg

Du hast also ein rechteckiges Bild, das passen würde, dessen Inhalt ist aber halt nur ein quadratisches, mit leerer weißer Fläche.

Für FB sollen es eigentlich eh Bilder in 1200x627 px sein. Deines ist die Hälfte, das geht auch, Format würde ja stimmen, ist aber bei hochauflösenden Displays dann unscharf.

Für Twitter haste ein anderes mit 200x200 Pixel:

https://www.seiden-handel.de/image/cache/ca…1-200x200h.webp

So beiläufig sehe ich auch gerade, dass da in der URL zwei Slashes nacheinander kommen: crepe-de-chine//crepe-de-chine

P.S. Kann Dir aber sagen, da bin ich vor zwei Wochen auch erst verzweifelt. Ein neues Bild als Vorschau für die Kategorie. Naja. Mal war links unten der Domainname "weg", mal fehlte rechts oben ein Teil der Schrift. FB skaliert halt überall anders, Desktop, Mobil. Diese 1200x627 sind eigentlich überall recht gut passend. Nicht zu verwechseln aber mit 1200x630, denn die sind nicht für URL-Posts, sondern für Bilderposts. Fb unterscheidet ja zwischen Bilderpost (16:9 oder 4:5), Stories und URL-Posts. Wobei bei den Bilderposts in 16:9 auch wieder skaliert wird auf etwas im Bereich 8:5 bzw. eben 16:10.

Die Sharer nutzen allesamt aber ausschließlich den URL-Post.

Jep, die Dienste machen das selbst. FB nutzt OpenGraph, Instagram, soweit ich weiß auch. Die Bilder kann man als OpenGraph hinterlegen, auch mehrere in verschiedenen Versionen. Twitter nutzt einen anderen Tag, den Twitter-Card.

Was Du wohl eher meinst, CatCat, ist ein Bild direkt zu posten. Das machen die Dienste über diese Share-Funktion aber in der Regel gar nicht. Da könnte man dann aber direkt über das AddOn ein Bild senden. Glaube nur Pinterest erlaubt das aktuell. Alle anderen erlauben nur URLs und eventuell Text und dann holen sie sich das Vorschaubild selbst.

Du hast auf der Seite ja schon OG eingebunden. FB nutzt das auch, siehe hier:

Das ist also Deine Giraffe in 600x315 px.

Und bei einem Produkt wechselt er auf ein anderes Bild, ist ein anderes per OG hinterlegt:

Dann gehe einfach mal von UTC aus, machen ja viele. Hinweis wäre nett, aber das wäre ja Arbeit, da 20 Zeichen zu schreiben oder so. Mein FTP-Prog nervt mich auch ständig mit UTC. Da lad ich um 10 Uhr eine Datei hoch, die um 10 Uhr gespeichert wurde (Windows-Zeit). Auf dem Server steht dann 10 Uhr (Debian-Zeit). Lade ich die direkt wieder runter, steht bei mir lokal (FTP-Zeit) dann 8 Uhr. Und natürlich steht da auch kein UTC+-00xx bei, wäre ja zu einfach.

Die Zeiten sehen aber irgendwie normal aus? Ist das nicht einfach nur die UTC? Du bist UTC+3, wir UTC+2. Beides ergibt dann jeweils diese angezeigten 23:42 Uhr.

Recht hat er aber schon. Das Script macht auch nichts anderes als einen href zu erzeugen. Kommt aber auf das System an. Da muss man halt nur einen Platzhalter setzen, den Rest macht Js.

Ich mache das aber auch nicht anders. Die Url für die Seite schreibe ich per php rein, entspricht dem Canonical. Description wird auch aus Meta genommen, wenn benötigt, z.b. für telegram. Bild kommt eh aus opengraph bzw twittercard. Popup hab ich nicht. Ich mach die einfach in einem neuen Tab auf.

Gut, das script ruft auch im Hintergrund die Counter ab und bindet sie ein.

Das Ding da ist z.b. der Wrapper für Wordpress. Also auch ohne Js, dafür mit Php. Im Prinzip erzeugt der aber auch nur Links mit der Url der Seite. Von dort hab ich aber die SVG für die Icons

https://github.com/3UU/wordpress-shariff-wrapper

Achso, das meinst du. Ist mir bei dir im forum schon aufgefallen. Da waren viele lupen aber keine bilder. Hier ist mir das noch nicht aufgefallen.