Beiträge von StefanSTS

    Nachdem das Prolem in der 4.2.18 nicht mehr auftritt konzentriere
    ich mich jetzt darauf diese Version zum Laufen zu bringen.

    Ich will Dich ja nicht aus dem Konzept bringen, aber 4.4.0 steht kurz vor der Tür. ;-)

    Die wird dann noch ein paar weitere Bugs erledigt haben. Da wird im Moment final getestet.


    STS

    SP Page Builder wirft da einen Fehler raus.

    Vielleicht schaltest Du den einmal ab und schaust wie die Darstellung mit dem Joomla Standard-Template aussieht.


    Gibst Du die Preise Brutto mit 4.9 an und lässt dann VM das Netto berechnen?
    Vielleicht spielt da eine falsche MwSt.-Regel mit rein.

    Am besten ist es, die Brutto-Preise selbst auf Netto herunterzurechnen. Möglichst mit mindestens 4 - 5 Stellen nach dem Komma.

    Und schau neben den Preisen, ob auch die richtige MwSt.-Regel greift.


    Halb Offtopic:

    SP Page Builder ist in meiner Favoritenliste übrigens ganz unten, da wo es heiß ist und die Software hinkommt, die nicht in den Himmel kommt.
    Dies ist nur für Mitleser, die sich fragen, was SP Page Builder ist und ob das toll ist. Meine Empfehlung für einen langfristig geplanten Shop: Finger weg von dem Ding.

    Grüße

    Stefan

    Hallo Faro,


    Google und die anderen Bots sollten eigentlich nur die Links Deines Menüs nutzen, oder die Links in einer Sitemap.
    Kann es sein, dass Du eine Sitemap hast, in der diese Pfade stehen?


    Bei der Eingabe von
    site:http://www.thomas-selendt.de Matrosen in lederhosen
    bei Google bekomme ich nur "ordentliche" Links in den Treffern.

    Du wirst Deine Produkte also nicht ausschließen, weil sie über die "richtigen" Links erreichbar sind.
    Ich nehme an, wenn da Produkte über /component/virtuemart/produktx gefunden werden, sieht Google die Canonical URL und gibt die richtige URL an, die Du im Menü hast.

    Übrigens bin ich kein SEO-Experte, ich habe mich immer darum gedrückt, wenn ich konnte, deshalb glaub mir kein Wort, das Du nicht selbst verifiziert hast.


    STS

    Ich denke, wenn ich diese Regel in der htaccess setze, könnten doch auch andere benötigten Dienste gesperrt werden?

    Der Crawler geht da über die ungeSEFte Standard-VM-URL.
    Du hast aber alle Produkte und Kategorien usw. durch Menüverweise mit einem eindeutigen Pfad versehen.

    Solange Du Deine Produkt-URLs nicht sperrst, ist das alles in Ordnung.


    component/virtuemart/ zu sperren, sperrt nicht die "schönen SEF-URL" Deiner Produkte wie:
    online-shop/musik-cd-s/matrosen-in-lederhosen/album-cd-3-cd-box-zum-jubilaeum-das-beste-detail.html


    STS

    Hallo Faro,


    ein Sicherheitsproblem eher nicht, aber die reizen evtl. Deine Server-Resourcen mächtig aus.

    Lösungsansätze:

    1. Du kannst Deinen Provider fragen, ob die da filtern können.


    2. Ich nehme stark an, diese Crawler halten sich nicht an die robots.txt.

    Hast Du Einträge in der robots.txt, die das verhindern sollten?


    3. Im Log steht:
    /component/virtuemart/featured.feed? 200 (200 = erfolgreiche Verbindung)

    Du könntest diese Pfade über die .htaccess blocken, wie schon den api-Pfad.


    Kurz: Über robots.txt kann man es versuchen, die macht aber nur "Vorschläge".
    Letztendlich ist es am besten, wenn der Provider es schon vor dem Server rausfiltert.


    Grüße

    Stefan


    PS. Vielleicht hat Max noch eine Idee, wie man zumindest die Fehlermeldungen im Log verhindert.

    Hallo Faro,


    ich deinstalliere immer alle Templates, die nicht mit Joomla kommen.

    Die Joomla-Templates, bei J4/J5 nur Cassiopeia, deaktiviere ich nur.


    Der alte J3-Kram horme_3, vmbeez3 darf raus. Du bist ja schon unter J5.

    Natürlich erst auf der Testdomain, nicht, dass Du noch einzelne Ansichten mit einem anderen Template darstellst.

    Davon gehe ich aber eher nicht aus, bei horme und vmbeez wäre sicher sonst Dein Bildschirm öfter mal weiß.


    Grüße

    Stefan

    Hallo Faro,


    ich muss da auch immer erst nachdenken, oder auf Github schauen, oder mitlerweile chatGPT fragen, das geht meistens am schnellsten.

    Folgendes müsste funktionieren:

    RedirectMatch 403 ^/api/


    Das gibt für den Zugriff auf den Ordner api ein Forbidden.


    Wenn Du mehr Beispiele brauchst, findest Du hier eine alte gute Liste mit .htaccess-Regeln:


    Grüße

    Stefan


    PS. Die Foren-Software hat den Link zum Gist verwendet, um das Gist gleich ganz hier hinein zu laden. Dinge gibt's...

    Servus,


    wenn nur im Hauptprodukt Bilder sind, werden diese Bilder bei allen Kindprodukten gezeigt.


    Wenn man bei den Kindprodukten eigene Bilder hinterlegt, werden bei den Kindern nur diese Bilder angezeigt.

    Möchte man bei Kind weiterhin die Bilder des Hauptprodukts haben, muss man diese Bilder im Kindprodukt explizit noch einmal auswählen.


    Grüße

    Stefan

    Servus Faro,


    die versuchen sehr wahrscheinlich, die gefixte Sicherheitslücke in der Joomla API anzusprechen, mit der sie dann Deine Installation übernehmen könnten.


    Da Dein Joomla aktuell ist, passiert über diesen Weg nichts, es gibt dann nur die 401-Meldung, unauthorised, und die landet in Deinen Logs.


    Im Grunde ist das weniger ein Error für Dich als eine für Dich positive Meldung, dass die Anfrage nicht durchging, weil der Aufrufende nicht berechtigt war, das zu tun.
    Ein Error ist es für den Angreifer, dem gesagt wird: Hey, Dich kenne ich nicht, Du hast hier nichts zu suchen, bleib draußen.


    Grüße

    Stefan

    Hallo Anna2709,


    Du kannst ein Selbsterstelltes Feld dafür erstellen.

    1. Im VM-Menü -> Produkte ->Selbsterstellte Felder anklicken.
    2. Neu anklicken.

    3. Benutzerdefinierter Feld-Typ: Plugins.

    4. Ganz unten auf der Seite - Wählen Sie ein Plugin: VM Custom - Customer text input.


    Grüße

    Stefan

    Servus miteinand,


    dass der OPC in Version 7.25 nicht funktioniert, ist komisch, ich habe den auf vielen Seiten in aktueller Version.


    Kann es sein, dass ein JavaScript-Konflikt in der Konsole angezeigt wird? Falls ja, was steht dort?


    Evtl. beißt sich da etwas mit dem JavaScript, das über den SP Page Builder hineinkommt.

    Nur eine vage Vermutung, weil ich mit dem in der Vergangenheit schon öfter einmal Probleme hatte.


    Grüße

    Stefan

    Also den redirect ausschalten, damit die htaccess funktioniert?

    Den Redirect über das VM-System-Plugin ausschalten, damit die Bots, die auf com_user zugreifen wollen, nicht zu VM weitergeleitet werden, wo sie dann ein neues Formular finden, das sie ausfüllen möchten (und können).


    Hintergrund:
    Bots kennen die URL des Joomla-Registrierungsformulars, das ist das Hauptziel der Bots.
    Das VM-Formular gehen die mir bekannten Bots nicht direkt über eine bekannte URL an. Das finden sie nur über Links oder eben diesen Redirect.


    Wenn man com_user durch eine Bearbeitung des Codes in com_user unwirksam macht, finden die Bots trotzdem den Weg zur VM-Registrierung, wenn der Redirect eingeschaltet ist. Es ist also nötig, die Registrierung über com_user in der .htaccess zu blockieren. (Ist auch sauberer, weil der Server die Anfragen gleich blockt und nicht zu Joomla weiterschickt.) Allerdings muss man die Funktion für die Passwort-Wiederherstellung in com_user offen lassen.


    Wenn man keine Links zur VM-Registrierung hat, finden die Bots die VM-Registrierung kaum, evtl. wenn sie über einen Link in den Warenkorb kommen.
    Wenn die Registrierung aber nur möglich ist, wenn ein Produkt im Warenkorb liegt, finden die Bots die Registrierung nicht, weil sie (bisher noch) keine Produkte in den Warenkorb legen können. Da brauchen die dann ein bisserl mehr AI, und das würde wahrscheinlich bei großflächigen Angriffen zuviel Rechenpower benötigen.


    Mit dem System ist man also ziemlich sicher vor Spam-Registrierungen.


    Eine Einstellung in der VM-Konfig, die Adresseingabe/Registrierung im Warenkorb nur anzuzeigen, wenn ein Produkt im Korb liegt, wäre in der Tat eine gute Sache, dann kann jeder Shop-Betreiber einfach entscheiden, wie er es haben möchte. Da müsste man sich nur über die Voreinstellung streiten. ;-)

    Um das Verhalten nicht zu verändern, scheint es sinnvoll, die Registrierung per default weiterhin anzuzeigen.


    Grüße

    Stefan

    Hallo Sigrid,


    wenn das über die iStraxx Tools nicht funktioniert, fragst Du am besten gleich den Max dazu.


    Wenn Du auch ohne die Tools Brutto-Preise als Default haben möchtest, könntest Du in den Kundenfelder beim Feld virtuemart_country_id unter Standard das Land eintragen, in dem der Shop beheimatet ist. Die einzutragende ID findest Du in der Liste der Länder.


    Damit verhält sich VM so, als ob der Kunde im Warenkorb das "Shop-Land" eingetragen hat.

    In vielen Shops wird das so gewünscht. Der individuelle MwSt.-Satz stellt sich dann erst ein, wenn man ein anderes Land im Warenkorb angibt.


    Es gibt Shops mit Sternchen bei den Preisen, die dann unterhalb darauf hinweisen, dass sich Preise je nach MwSt.-Satz des Käuferlandes ändern.


    Grüße

    Stefan

    Das Update mit VM 4.2.18.11061 setzt das Layouts übrigens nicht mehr auf bs5, das hab ich gerade getestet.


    In der nächsten veröffentlichten Version ist das Zurückstellen auf das Alt-System, oder das "Normal-System" wie ich es nenne, nicht mehr nötig.

    Die Einstellung bleibt beim Update unverändert.


    Grüße

    Stefan