Beiträge von rolf303

    Ich habe hier schon PHP5.5 am Laufen, also bisher sehe ich da keine Schwierigkeiten.

    Ich bewundere Leute mit Optimismus... :)

    Nun da geb ich mal einen kleinen Tipp, obwohl das ein anderes Thema wird...

    Dir ist sicher bekannt, dass die mysql_... Funktionen aus php verschwinden. Ich habe hier schon mal eine php 5.5.9 am laufen, da ist das bereits so. Du wirst dich also mit mysqli_... auseinandersetzen müssen. Das sind dann circa 500 gefühlte Änderungen im Shopcode (können auch mehr sein). Mit Deiner getesteten php-Version müsstest Du bereits etliche "deprecated" in den apache-Logs finden. Ich hab mal einige meiner Projekte umgestellt, eine Fleißarbeit die alten bzw. uralten Programme umzustellen...

    Und warum, dass alles? Weil sich der mysql-Server in den Jahren weiter entwickelt hat, die php-mysql-Treiber aber nicht Schritt halten konnten.

    Auf php.net findet man dazu: Deprecated features in PHP 5.5.x

    Zitat

    The original MySQL extension is now deprecated, and will generate E_DEPRECATED errors when connecting to a database. Instead, use the MySQLi or PDO_MySQL extensions.


    Nun zum Problem.
    Ich weiß nicht genau seit wann die neuen mysqli-Treiber in ALLEN Distris, besser gesagt in php, voranden waren. Vielleicht ab php 5.3 oder so... (Wen's genauer interessiert kann's mal bitte nachlesen.)
    Nehmen wir weiter an, ab Version 5.6 ist der alte mysql-Treiber endgültig raus. Es wird also nicht mehr lange dauern bis sich die Kunden so ein PHP installieren.

    Übrigens die Wirkung bei einem Update von php 5.3 auf >= 5.6 wäre das keine Datenbankzugriffe mehr funktionieren. Also z.B. ein Login nicht mehr möglich ist. Aber vermutlich wird es noch viel schlimmer.

    Es wird deshalb nicht reichen nur die Funktionen umzuschreiben, sondern ihr müsst im Installer die Requirements anheben, sagen wir mal auf php >= 5.4.

    Den Rest kann sich jeder selbst ausmalen.
    Also mir fiel erstmal die Kinnlade runter als auf dem Testserver nichts mehr ging...

    Und das ist nur ein Problemchen in der schönen neuen PHP-Welt.

    Hi DessousandToys,

    Also ein Bug ist das nicht gerade. Das rewrite in der .htaccess soll bestimmte SEO-Vorteile bringen. Und wie immer, wo Licht ist, ist auch Schatten...


    Warum nennst Du die Datei nicht um? Da Du dem Shop permanent eine einzelne landing page voran stellen willst bzw. mit einer einzelnen "Vorschaltseite" umleiten möchtest sollte das gehen.

    Hier mal ein Lösungsansatz (nicht getestet!)

    1. Nenne die original index.php in index2.php um.
    2. Nenne die index.html in index.php um.
    3. Füge nun als erste Zeile in deiner umbenannten index-Datei

    PHP
    <?php ; ?>


    ein

    4. Ändere die .htaccess

    alt

    Apache Configuration
    # immer auf den root verweisen, damit die Startseite (/index.php) nicht zweimal vorkommt
            # die folgenden beiden Zeilen auskommentieren wenn Sie eine index.html nutzen wollen
            RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(html?|php)\ HTTP/
            RewriteRule ^index\.(html?|php)$ http://%{HTTP_HOST}/ [R=301,L]

    neu

    Apache Configuration
    # landing page vor shop setzen
    	RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index\.(html?|php)\ HTTP/
            RewriteRule ^index\.(html?|php)$ http://%{HTTP_HOST}/index.php [L]
    
    
            # immer auf den root verweisen, damit die Startseite (/index2.php) nicht zweimal vorkommt
            # die folgenden beiden Zeilen auskommentieren wenn Sie eine index.html nutzen wollen
            RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index2\.(html?|php)\ HTTP/
            RewriteRule ^index2\.(html?|php)$ http://%{HTTP_HOST}/ [R=301,L]

    Der neue Code-Block bzw. deren 1. Abschnitt muß in der .htaccess relativ weit oben stehen, genauer gesagt vor dem ersten Block mit den Anweisungen

    Apache Configuration
    ...
    	RewriteCond ....
    	RewriteCond ....
    	RewriteCond ....
            RewriteRule ...  L]
    	...

    Weil das L-Flag dafür sorgt, dass keine weitere RewriteRule ausgeführt wird. Deine Rule würde, wenn Sie weiter unten steht nicht mehr greifen.

    Es geht natürlich einfacher, wenn man direkten Zugang zu den apache conf-Dateien hat. Dann kannst Du das machen was der admin vorgeschlagen hat.

    Das musst Du Deinem Server beibringen, die index.html Seite als primäre Seite zu nehmen.

    Alles klar, habs gefunden - bzw umgangen : htaccess umbenannt sodass sie nicht greift, dann lief die Installation wie gewohnt ab (wegen dem Hinweis oben hinsichltich subdomain) ; wär aber schön, wenn man da irgendwo drauf hinweisen könnte

    Installation war auf v2next.domain.de , wie gesgat ohne die htaccess wurde der User ganz normal angelegt - das "problem" ist aber neu odeR? hab da sonst noch nie schwierigkeiten mit gehabt.

    OK, das mit der Subdomain ist ein Hinweis. Wobei ich sagen muss, dass ich auch schon oft auf Subdomains installiert habe mit der aktuellen .htacess.

    Okey, Ihr habt beide Recht. Subdomain aber funktioniert nur wenn im vhost des apache als ServerAlias *.subdomain.meinedomain.de oder http://www.subdomain.meinedomain.de vorkommt. Das Übel ist hier die "starre" Umleitung auf www.subdomain.meinedomain.de. Wie in meinem 1.Beitrag zu diesem Thema beschrieben, werden im Response-Header durch das rewrite der .htaccess die Url-Parameter nicht mehr übernommen. Die header sind dann einfach leer.

    Hallo zusammen,

    Was man auch gern immer wieder vergisst, ist ein aktiviertes suhosin modul im apache. Das führt zu Problemen mit den Sessions. Leider kann die Shopsoftware, das fängt bereits bei osCommerce an, nicht mit verschlüsselten Sessions umgehen. Um festzustellen ob suhosin aktiviert ist einfach mal phpinfo() per php-script aufrufen. Falls man nicht auf suhosin verzichten will, kann man in die php.ini usw. suhosin.session.encrypt = Off einstellen, das sorgt dafür, dass die Sessions wie ohne suhosin nicht verschlüsselt werden. Dies wäre dann wieder der "Normal-Zustand" für die Shopsoftware, wobei es m.E. zu begrüßen wäre, die Software irgendwann mal für verschlüsselte Sessions umzuschreiben.

    In wie fern das aber was mit dem ursprünglichen Problem zu tun hat kann ich nicht sagen, da sich EarlHicky bisher nicht mehr geäußert hat.

    Hi 8tom,

    So einfach ist das nicht. Hast Du nicht auch schon mal das Gefühl gehabt nicht ernst genommen zu werden?

    Aus langjähriger eigener Erfahrung kann ich nur sagen es gibt zu 99% oder so, keine fehlerfreie Software. Von ein paar Genies die das tatsächlich mal drauf haben abgesehen. Aber dazu gehören wir alle nicht, sonst würden wir unsere eigene Shopsoftware schreiben und unser eigenes Ding machen.

    Aus eigener Erfahrung weiß ich, wie schwer es ist bestimmten Fehlerursachen auf die Spur zu kommen. Als wirtschaftlich denkendes Unternehmen muss man dann abwägen ob "Der Kunde König ist" oder ob man es sich noch leisten kann wertvolle Ressourcen zu binden. Ich persönlich neige aber eher dazu den Kunden nicht hängen zulassen.

    Ich bin hier auch nicht ein beta Tester, sondern nur ein Kunde der ein großes Interesse hat die Software möglichst fehlerfrei zu bekommen.

    Nun noch zu deiner Aussage das man den Fehler erstmal bei sich suchen muss. Dem kann ich hier leider nur zu 20% zustimmen.

    1. Befinden wir uns hier in einem geschlossen Service-Forum, dort sollte der Serivce-Gedanke im Vordergrund stehen.
    2. Hat EarlHicky ja schon geschrieben was er bereits alles unternommen hat um das Problem zu lösen.

    Das sieht mir nicht danach aus das er von nichts eine Ahnung hätte oder schnell aufgeben würde.
    Im Gegenteil, da haben Andere schon lange nach Neuinstallation geschrienen.
    Aber nach meiner Erfahrung sieht es für mich so aus, als wenn EarlHicky auf ein immer noch unentdecktes Problem gestoßen ist und sich in einer Art Endlos-Schleife befindet (und täglich grüßt das Murmeltier).

    3. Wenn Du auch schon mal nach dem Fehlerbild gesucht hättest (Hier auf der Plattform) oder im Internet wäre Dir vielleicht aufgefallen, dass dieses oder ein ähnliches Problem von Zeit zu auftaucht, also kann EarlHicky ja durchaus noch mit seinem Anliegen im Recht sein. Nach meiner Annahme würde ich mal sagen gehen wir mindestens bis 2009 zurück. Dazu kommt noch, das bestimmte Fehler die serverseitig korrigiert werden, zu neuen oder alten Problem in der Shopsoftware führen können.

    Wenn es also stimmt das dieses Problem schon so lange einige Kunden zur Verzweiflung treibt, würden bei mir als Hersteller schon mal alle Glocken klingeln.

    Es hilft da nicht, und ist nicht sonderlich konstruktiv überall mal drauf zu schlagen, am allerwenigsten auf den Kunden. Ja, und natürlich will man für seine Arbeit auch Anerkennung...
    Eigentlich bin ich mir sicher, dass das auch die Entwickler so sehen, aber wenn man sich mal für was Neues entschieden hat, da gibt's wohl kein zurück mehr.

    Da ich weiter davon Ausgehe, dass das geschilderte Problem nicht sonderlich beliebt ist, ist das für mich überhaupt erst genug Motivation mich hier helfend ein zu klinken. Rote Teppiche werden einem so oder so nicht ausgerollt. Bis zum Beweis des Gegenteils, ist man halt doch "nur" der Kunde.

    Hallo EarlHicky,

    Also ein anderer Fehler. Ich kann Deinen Ärger gut nachvollziehen, irgendwie fühlt man sich immer als Beta-Tester...

    Ist das Fehlerbild so wie von mir beschrieben?

    Weißt Du ob der Installer komplett durch läuft? Was ist mit der CE-Version. Hast Du da die gleichen Probleme?
    Hat bei Dir überhaupt schon mal eine Installation funktioniert?

    Kannst Du unmittelbar nach der Installation in das Backend wechseln oder nicht? (Ich tippe immer noch auf leere POST-Variablen...)

    Wenn Du nach der Installation "normale" Kunden anlegen kannst sollte die Datenbank ja eigentlich korrekt nach Vorgabe installiert sein...

    Falls Du nicht weiter kommst, könnten wir ja auch mal telefonieren.

    Viel Erfolg

    Hallo, wie Admin schon geschrieben hat, am Shop liegt es definitiv nicht, was hast du für einen Provider / Server Version, hole dir bei einem anderen Anbieter einen Test-Account und dann wirst Du sehen es klappt.
    Du brauchst die Provider nur anschreiben und dann bekommst du einen Test-Account für 5-7 Tage. und schon wirst du sehen es klappt :)

    Alles klar der User ist mal wieder der Doofe...

    Das von EarlHicky beschriebene Problem kenne ich gut. Höchst wahrscheinlich (ich schau mal tief in meine Glaskugel) hat er so ne coole Domain wie http://fassbier.de und da will er sicher nicht http://www.fassbier.de in der Browserzeile stehen haben.

    Warum auch?

    Also hat er bei der Installation eben in der /includes/configure.php und in der /admin/includes/configure.php

    Code
    define('HTTP_SERVER', 'http://fassbier.de'); 
    define('HTTPS_SERVER', 'https://fassbier.de');
    define('ENABLE_SSL', false);

    stehen.

    Nun zur Praxis:

    Falls in der Browserzeile http://www.fassbier.de/login.php ausgeführt wird, steht aber im Formular

    Code
    <form id="loginForm" method="post" action="http://fassbier.de/login.php?action=process">


    weil das ja in der /includes/configure.php mit

    Code
    define('HTTP_SERVER', 'http://fassbier.de');


    so gewünscht wurde.

    Also wird in der .htaccess der rewrite auf http://www.fassbier.de angestoßen (und das wiederum hat der Programmierer so gewollt) bevor die Formulardaten dann

    per POST weitergeleitet werden. Dies funktioniert leider nicht immer, je nach Servereinstellungen und ggf. Version. Beim header-redirect gehen also u.U. die POST-Variablen "verloren" und $_POST ist danach leer. Das login-script wiederum fängt die leere Variable "email_address" und "password" nicht richtig ab, so dass man die lapidare Meldung

    "Die eingegebene E-Mail-Adresse ist nicht registriert. Bitte versuchen Sie es noch einmal." erhält.

    Obwohl, und da beißt die Maus keinen Faden ab, "email_address" und "password" richtig in der Datenbank stehen.

    Testen könnte man dieses Verhalten ganz leicht auf dem eigenen Server, wenn man wie oben beschrieben, aus der configure.php mal das "www." oder "shop." oder was man da so alles eingegeben hat, entfernt. Interessieren würde mich an dieser Stelle, bei wie vielen Servern dieses Problem dann eigentlich tatsächlich so auftritt.

    Hätte der User nicht den aberwitzigen Einfall gehabt, anfangs seine Domain möglichst kurz einzugeben, wäre eigentlich nicht viel passiert...

    Aber wie schon Eingangs ge-quotet "Es liegt definitiv nicht am Shop!"

    Tach auch...

    Hallo Leute,

    Es gibt mindestens ein Zahlsystem das für Händler und Kunden kostenlos ist. Im Moment bieten Sie nur Zahlung gegen Kontoaufladung an. Treuhandservice ist ebenfalls kostenlos. Also einfach mal google'n...

    Ich jedenfalls wüste nicht wie man mit einem Disagio von 7,0% Mindestens 1,50€ Deutschland noch irgend einen Umsatz generieren kann.

    Hallo,

    Wie steht es eigentlich um die kommenden Domain-Endungen, ist der Shop dazu kompatibel?

    Nehmen wir mal an es würde einen Shop geben mit der Domain bäckerei.gmbh

    Hier haben wir es ja gleich mit 2 Problemen zu tun

    1. Umlautdomain
    2. Neue Top-Level-Domain

    Was ist mit bereits installierten und verkauften Shoplösungen?
    Muß man nun auf eine neuere Version umsteigen?
    Wenn ja, auf welche Version?

    Sagen wir mal es wird eine Freemaildomain geben mit der Domain free.email
    Und nehmen wir weiter an free.email hat bereits 10.000 Nutzer.
    Soll man als Shopbetreiber auf diese potentiellen Kunden verzichten?

    Ein Beispiel, worum es hier überhaupt geht,

    Füllen Sie ihren Warenkorb und registrieren Sie einen neuen Kunden
    Z.B. mit der email Max.Mustermann@free.email

    Beim Absenden des Anmeldeformulars erhalten Sie,

    "Fehler Ihre eingegebene E-Mail-Adresse ist fehlerhaft - bitte überprüfen Sie diese."

    Offensichtlich, muss der emailcheck an die neuen Gegebenheiten angepasst werden. (getestet Version plus 2.1.2.11)

    Nun, für dieses Problem sind nur noch ca. 6 Monate Zeit.

    In Deutschland hat jeder Geschäftskunde den Anspruch auf eine Rechnung mit korrekt ausgewiesener MwST. Ein Abschalten in der Rechnung ist nur dann sinnvoll wenn man ausschließlich Privatkunden beliefert. Das ist nicht sehr wahrscheinlich! Da die MwST mit der Vorsteuer bei gewerblichem Verkäufer und Käufer verrechnet werden kann, kann das bei fehlerhaften Angaben mit dem Finanzamt Stress geben. Man sollte auch auf jeder Eingangs-Rechnung die beim Finanzamt eingereicht wird die ausgewiesene MwST nochmal nachrechnen. Fehler passieren ja überall.

    Rundungsfehler entstehen dadurch dass,

    Wir in Deutschland 7% und 19% MwST haben. Das ist niemals nicht durch 10 teilbar...

    Und intern wird immer mit mehr Nachkommastellen (Registerbreite systembedingt) gerechnet, auch wenn man das auf 2 Nachkommastellen begrenzt. Deswegen gibt es die so genannte kaufmännische Rundung. Warum man das aber so macht, naja...

    Der Fehler entsteht oft, wenn man mehr als ein Stück kauft. Bei der Division oder Multiplikation verbleibt ein Rest weil, wie schon gesagt, der MwST-Satz nicht durch 10 teilbar ist.
    Vermeiden kann man den Fehler durch frühst möglichen Einsatz von Addition und Subtraktion in der Berechnung der Mehrsteuer. Beispiel: ein Artikel kostet

    1x 3.46 EUR x 1.19 = 4.1174 EUR gerundet 4.12 EUR

    2x 3.46 EUR x 1.19 = 8.2348 EUR gerundet 8.23 EUR (hier fehlt bereits 1 Cent)

    Denn wenn 1 Artikel 4.12 EUR kostet, warum kosten dann 2 Artikel nur 8.23 EUR ?

    Die Frage ist nun in welcher Höhe muß die MwST an das Finanzamt abgeführt werden? 1.31 oder 1.32 EUR ?

    Ich denke dass es korrekt ist die MwST für jeden Artikel zunächst zu bestimmen und danach alle Netto und Mehrwertsteuerbeträge zu addieren. In diesem Fall würde ich nach Addition dann 1.32 EUR an das FA abführen. Außerdem wenn ich hinter jeden Artikel die MwST-Beträge schreibe stimmen sowohl alle Zeilen und Spalten der Rechnung bis auf den Cent.

    Übrigens auch bei der Divisionsmethode kann die Differenz nur maximal +/- 1 Cent betragen, sonst ist grundsätzlich was an der Berechnung fehlerhaft.

    Hallo,

    Bei der Bestellung des Demoartikels wird folgendes angezeigt.

    [ATTACH=CONFIG]85[/ATTACH] Bestellvorgang

    [ATTACH=CONFIG]86[/ATTACH] Auftragsbestätigung per Mail

    Der Steuersatz steht auf 19.0000 und der Nettobetrag wird in der Artikelbeschreibung auch korrekt dargestellt.

    Was könnte da falsch sein?
    Version v2plus 2.1.1.4

    Okey, die Darstellung ist wohl etwas verwirrend...
    Z.Z. ist das DHL Paket nach UStG umsatzsteuerfrei
    Damit sind die Versandkosten im Beispiel 6,70 EUR eher ein "Bruttopreis".

    Diese Versandkosten werden aber der Nettosumme zugeschlagen.
    Nettosumme + 19% UST ergibt natürlich einen
    anderen Gesamtbruttopreis als angezeigt wird.

    Vielleicht wäre es besser Steuerfreie Zuschläge direkt über der Zeile Gesamtsumme darzustellen