kein admin login möglich - neueste version DL 31.01.2014

Also mal von meiner Stelle: Ich habe EarlHicky MEHRFACH gebeten, mir mal die Daten zu geben, was er bei der Installation eingibt. Ergebnis bis heute = 0! Wie sollen wir also bitte das Problem ermitteln?!?! Wenn man ohne www installiert ist es korrekt, die .htacess zu bearbeiten, das die Umleitung auf www raus kommt. Offensichtlich werden aber hier nicht nachvollziehbare Sachen eingegeben und wenn wir nicht wissen, was genau eingegeben wurde können wir den Fehler auch nicht ermitteln. Wir installieren mehrfach in der Woche die v2next auf sehr unterschiedlichen Server und haben dabei keine Probleme. Lokal entwickeln wir auf XAMPP mit der jeweils aktuellsten Version.
Was bitte sollen wir also tun um das Problem zu lösen?

P.S.: Einen Fehler hatten wir beim Installer bereits behoben, wenn mann Hochkommas beim Firmennahmen / Shopname verwendet hat, konnte es durchaus zu benannten Problem kommen, DESWEGEN AUCH MEHRFACH DIE NACHFRAGE NACH DEN EINGEGEBENEN DATEN. Aber das ist definitiv in der aktuellen Version behoben.

Moin,

ich hab das hier beschriebene Problem grad ebenfalls - frischer Download der v2next von heute , Installation auf `nem Estugo-Server : nach Eingabe aller Daten (shop@domain.de als Adminadresse, nix ausgefallenes) kommt die meldung "Emailadresse nicht registriert" - ein Blick in die DB zeigt dann, dass die Customer-Table leer geblieben ist, ebenso dieadress_book usw.

Ne das ist nicht behoben, zumindest nicht im Paket welches man vor ca 20 Minuten herunterladen konnte.

Keinerlei Hochkommas etc benutzt bei der Registrierung

Kannst Du mir da mal Details per PN schicken? Wie gesagt, selbst auf Strato haben wir da bisher keine Probleme.

etwas mit safemode oder modsecur, oder den andere sachen die man in php noch wegen security machen kan?

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.

Halo MArio.
Nen ist seit lange, nur macht man normal die htaccess , gleich richtig wegen den subdomain, dan umgeht man es meist.

Aber wen man ohne sub mit ssl lauft es auf einige server nicht.

Problem seht man aber leider nachher nach den erst gelungen session verlaufen ist, danach ( sessiontime) geht dan nichts mehr weise seite error 500, waren damals ganz lange damit beschäfigd weil, dan lauft es wider und dan nach ein weile nicht.

Dan nach unterschiede gesucht woo es immer gelaufen hat, die war dan den subdomain. ( also bei uns den shop. war immer Ok, weil beim install passt man dan gleich den htacces richtig an.

Aber ohne und/oder ohne www. nen ist auf unserer Server nicht gelungen mit ssl

bei einer install komentiere ich die par zeile ins htaccess immer aus! vorab

Vorher waren die meiste hoster / server auf mit www. eingesteld, heute auch viele ohne den dan ein virtuel path unsw. ( also auf server umleitung von umleitung htaccess die gegenstreitig ist ......

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.

wen ohne subdomain, also kein www. oder was auch immer und ssl, dan lauft es nicht überall wegen etwas mit sessions
Also mit subdomain wen richtig eingesteld ( htaccess unsw) habe ich noch kein probs gehabt!

Man bekomt öfter probs wen es ein art umleitung weiter aufs server ist zum beispiel mittels settings in Control pannels wie: plesk / directadmin. Das also auch beim subdomains, und oder den https nicht richtig ... oder qwassi doppelt umleiten.

Problem bleibt irgenwie bei Uns den SESSIONS ( path oder speicher/temp) wen SSL und ohne subdomain
Glaube ich jedenfalls, oder doch etwas anders mit den https wen kein subdomain drinne ist und die virtuele weiterleitung von server auf den gleichen path wie den ohne https.

So ist auch meine Erfahrung, wir installieren oft auf Subdomains und schalten dann auf die korrekte Domain um. Habe da noch nichts festgestellt.

Hab mein letzte beitrag nochmal geänderd, aber Du ( Admin) hast es selbe für ein par Jahre her mal gesehen, und weiter haben wir dies nicht beheben können weil solche wichtige sachen ( server / path /tmp / https /ssl / sessions settings) änderd man nicht auf n live server wo noch andere Seiten domains drauf sind. ( nur um zu testen)

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.

Zitat von mbraune

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.

Zitat von admin

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.

uh ein subdomain macht man doch niemals sub sub

WWW ist nämlich ähnlich wie sub (oder fast gleich wie SUB). ( (D)NS technisch gesehen)

Da past man die htaccess an und ersetz www durch den SUB wie beispiel shop. nen nicht so sorry
Man macht dort dan ein htaccess wo alles auf ohne www. umgeleitet werdet

und oft braucht man die rewritebase auf / markierung drausholen.. ( also rewritebase / soll drin sein ohne den ***)

www ist eine Subdomain! Also ich habe jetzt schon oft auf Subdomain mit vollständiger .htaccess installiert und keine Probleme gehabt. Aber wie gesagt, da bisher keine Rückmeldung vom Problemmelder kam, können wir jetzt endlos spekulieren.

Ja, stimmt. Es könnte auch mit einer neueren(zu neuen) php5-Version zusammenhängen. Das wird uns wohl demnächst noch öfter treffen...

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

Zitat von admin

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.

Ist mir bewusst Die Vorarbeit dazu ist auch schon getan, nämlich alle mysql Befehle in die entsprechenden xtc_... gewandelt. Da gab es einige Stellen, wo noch direkt mit mysql gearbeitet wurde. PDO Umstellung steht auch ganz oben auf meiner Liste. Ich denke, dieses Jahr wird erst mal die Umstellung auf PHP5.4 bei den meißten Providern sein und wer aktuell PHP5.5 schon einsetzt, wird in der Regel noch den mysql Treiber drin haben, angeboten wird er ja noch. Eine Alternative wäre halt AdoDB als Zwischenschicht.