ZitatNur wie lange soll man ein 2.5x oder 2.6 noch am laufende halten?
Wir werden bei der 2.6 bleiben, da wir diese extrem stark angepasst haben.
Die Version zu ändern, hätte für uns keinerlei Nutzen.
ZitatNur wie lange soll man ein 2.5x oder 2.6 noch am laufende halten?
Wir werden bei der 2.6 bleiben, da wir diese extrem stark angepasst haben.
Die Version zu ändern, hätte für uns keinerlei Nutzen.
Hey, wir könnten es an einem Shop durchspielen und vielleicht eine Step by Step-Anleitung erstellen.
Was ich aber bisher noch nicht ganz durchgetestet habe ist das Backend. Sitze noch am Frontend - hat aber weniger mit der Umstellung auf PHP7 zu tun.
Also die V2.6 läuft durchaus auf PHP7.
Es müssen lediglich ein paar Dateien angepasst werden, da alles auf mysqli laufen sollte - das ist in 1-2 Stündchen gemacht - getestet werden muss natürlich ordentlich.
Das Session-Problem von gestern ist kein prinzipielles PHP7 Thema, da es bei Profihost läuft, nur lokal bei mir nicht - Aber das ist inzwischen behoben.
Ich habe es wie folgt behoben:
function _sess_read($key) {
$value = xtc_db_fetch_array(xtc_db_query("SELECT value FROM " . TABLE_SESSIONS . " WHERE sesskey = '" . xtc_db_input($key) . "' and expiry > '" . time() . "';"));
if ($value['value']) {
return base64_decode($value['value']);
}
return '';
}
Wie es aussieht, darf _sess_read kein false zurückgeben, sondern einen leeren String, ansonsten wird die Session auch nicht geschrieben.
Damit ist der Fehler reproduzierbar, wenn keine Session-Variable vorliegt / sessions-Tabelle geleert wurde und Session-Handling per DB übernommen wird.
Ich wundere mich, ob das neu in PHP7 ist - jedenfalls habe ich dummerweise viele Stunden daran gesessen - ich hoffe die kann ich jemanden ersparen.
Nachtrag: gerade folgendes bei XTC gefunden:
function _sess_read($key) {
$value_query = xtc_db_query("select value
from " . TABLE_SESSIONS . "
where sesskey = '" . xtc_db_input($key) . "'
and expiry > '" . time() . "'");
$value = xtc_db_fetch_array($value_query);
if (isset($value['value']) && $value['value'] != '') {
$value['value'] = base64_decode($value['value']); //DokuMan - 2010-11-16 addded base64_decode
return $value['value'];
}
//return false;
return ("");
}
Alles anzeigen
Grüße - Alex
Hallo,
ich wollte mal wieder etwas am Shop basteln und habe mir daher eine lokale XAMPP-Instanz aufgesetzt:
PHP Version 7.1.12
Zend Engine v3.1.0
Xdebug v2.5.5
Beim schreiben der Session landet nichts in der Session-Tabelle.
Ich habe einen Breakpoint auf die _sess_write gesetzt, jedoch springt er da nicht rein - _sess_read hingegen funktioniert super - leider bekommt er kein Ergebnis, aufgrund der leeren Tabelle.
Wenn ich define('STORE_SESSIONS', ''); (leer) setze, dann läuft alles Ordnungsgemäß.
Unter PHP Version 7.0.23 (Remote) funktioniert das schreiben der Sessions einwandfrei.
Ich sehe in der PHP V 7.1.12 lediglich Bugfixes - da sollte sich nichts am Sessionhandling geändert haben.
Hat die 2.6 jemand unter xampp-win32-7.1.12-0-VC14- getestet?
Da wir einige Anpassungen im Shop haben, habe ich die aktuelle sessions.php aus fp5_qf1_plus gezogen. Leider auch hier erfolglos.
Beste Grüße - Alex
Habe die Ursache gefunden. Der InputFilter liefert eine leere $_GET-Variable zurück.
Daher laufen die Abfragen auf die Contenseiten ins leere. Nun funktioniert wieder alles prima - und das unter php7
Hey... ich wollte im Testshop mal PHP7 testen. Die Constuctors in einigen Klassen habe ich entsprechend angepasst, da sich da wohl der Standard gändert hat.
Nun sieht das ganze so aus, dass Contentseiten und Artikelseiten leer sind. Header / Menü und Footer wird gezeigt.
Kategorieseiten führen mich auf die Startseite.
Errors.log ist leer / keine Fehler oder Warnungen.
Gibt es dazu Hilfestellungen was noch angepasst werden müsste?
Das ist ja sicherlich kein akutes Thema, aber interessant
Grüße
Alex
"Sicherheitsfix bei Kundenkonto Löschen" - Welche Dateien sind dabei betroffen?
Ach einfach davorsetzen... alles klar - das hat geklappt.
Vielen Dank
Hey.. wie googel ja verlauten lassen hat, spielt SSL beim Pagerank eine untergeordnete Rolle, das könnte sich aber bald Ändern.
Nun kann ich in der Config ja alles auf SSL stellen indem ich beispielsweise HTTP_SERVER mit https definiere.
Das verhindert leider nicht, dass die Artikel ohne https weiterhin erreichbar sind, was doppelten Content bedeutet.
Wie ist diese Regel in der htaccess anzupassen, um das auch mit abzuprüfen:
RewriteCond %{HTTP:X-Forwarded-Server} !^ssl\.webpack\.de$ [NC]
RewriteCond %{HTTP:X-Forwarded-Server} !^sslsites\.de$ [NC]
RewriteCond %{HTTP_HOST} !^www\..* [NC]
RewriteCond %{HTTP_HOST} !^.*\..*\..* [NC]
RewriteCond %{HTTP_HOST} !^localhost(.*)$ [NC]
RewriteRule ^(.*) http://www.%{HTTP_HOST}/$1 [R=301,L]
Da muss nun irgendwie folgende Regel hinzu: RewriteCond %{SERVER_PORT} !^443
wenn ich das www entferne, leitet der an https://www.domain.com weiter.
Entferne ich dann das www, also https://domain.com, dann leitet der mich zu https://www.www.domain.com.
Kann es sein, dass sich www und https nicht richtig mit einer Regel vereinbaren lassen?
Besten Dank im Voraus.
Ach da werden dann praktisch Produkte "generiert" - so hat jede Variante quasi ihre eigene Artikelnummer.
Ist schon abzusehen wie das mit der pflege aussieht?
Der Oxid hatte das glaube so gemacht...
Aus 4 Merkmalen ergeben sich schon alleine 24 Artikel (max. Anzahl an Kombinationen).
Wenn ich nun ein Produkt habe, das in 4 Variationen existiert, dann haben alle 24 Kombinationen den selben Preis (mal angenommen die sind preisunabhängig) - die mussten glaube auch dann wirklich bei einer Preisänderung separat gepflegt werden - Falls das nicht alles gepflegt werden muss, dann wäre das durchaus interessant.
Was ist die Varianten Matrix?
Warum wurden die Snippets entfernt? Machen die nur auf Produktebene Sinn?
2.5.1 nutzen wir.
Wurde etwas daran geändert? Dann müsste ich das manuell mal einspielen.
Bei der Anmeldung eines Kunden, entstehen bei der Datumsprüfung Fehler.
Der Chrome gibt das Datum in a) einer anderen Reihenfolge und b) mit "-" getrennt zurück, der IE gibt es in "original" zurück.
Liegt wohl darum, dass ein Input-Feld vom Typ "date" inzwischen von Chrome anders bearbeitet wird.
Gibt man beispielsweise das Datum "09.10.1958" ein, so meckert er immer, dass das Datum falsch wäre.
Weiß nicht, ob das inzwischen behoben wurde (arbeite mit einer älteren Version).
Grüße Alex
Habe schon die neueren Dateien durchforstet und dabei fiel mir diese Aktualisierung auf... hab es gleich mal übernommen - danke.
Kann irgendwann mal mit eine Art Changelog pro Version gerechnet werden - so dass man sieht an welcher Datei gearbeitet wurde?
Ist sicherlich ziemlich aufwendig, aber für Entwickler wäre das eine schöne Geschichte.
Hey...
Die Tabellen sind mit endlos vielen Datensätzen gefüllt u würde gerne die Datenbank gering halten.
Würde es sich auf die Funktionalität des Shops auswirken, wenn die entsprechenden Daten nicht in die DB schreiben lasse?
Grüße
Alex
Sollte man den Ordner "admin" gleich mit htaccess sperren?
Haben es so gemacht...
Ja, aber den Internet Explorer würde ich am liebsten nicht mit anbieten