PHP-FUSION DEUTSCHLAND
  • DEIN CMS - DEINE ZUKUNFT
Thread Verfasser: Wisselsheim
Thread ID: 1432
Thread Info
Es gibt 12 Beiträge zu diesem Thema, und es wurde 3716 Mal angesehen.

PHP-Fusion Deutschland - Offizielle Supportseite » Support Allgemein » Anfängerfragen

 Thema drucken
Datenbank SQL bei gmx/1und1 wird nicht gefunden
Wisselsheim
Top  #1 Beitrag drucken
Geschrieben am 26.02.2018 um 09:31
Hallo,,
ich habe php Fusion 7.02.7 auf meinem WebSpace geladen, bei Aufruf geht es bis zum Schritt 4, dann geben ich die Datenbankinformationen ein und es geht nicht weiter, weder eine Fehlermeldung noch ein Fortgang.

Habe ich etwas falsch eingestellt ?

Bin etwas verzweifelt, da es meine erste php Fusion Istalllation ist.

Grüße und Danke
Sven Klausnitzer
 
WWW
Ernst74
Top  #2 Beitrag drucken
Geschrieben am 26.02.2018 um 19:14
Bei 1 und 1 hast du PHP 7.0.22 da musst du das inoffizielle DE Paket für die Installation nehmen.
 
WWW
Wisselsheim
Top  #3 Beitrag drucken
Geschrieben am 28.02.2018 um 19:57
Hallo,
leider geht es noch immer nicht, Schritt 4 hängt, weder eine Meldung, dass die Datenbank nicht gefunden wird, das PW falsch ist etc. Hängt einfach !
die Seite liegt auf http://www.wisselsheim.net

Ich habe das inoffizielle Paket von eurer Seite heruntergeladen, da steht aber auch 7.02.07 das von dir genannte 7.0.22 finde ich nicht !

Grüße
Sven
 
WWW
Ernst74
Top  #4 Beitrag drucken
Geschrieben am 01.03.2018 um 08:08
PHP ist nicht gleich PHP Fusion. Dann bleibst du bei der Installation hängen, weil dein MySQL Server nicht mit dem birthdate Format klar kommt. Vielleicht sollte man das mal in der setup.php ändern.
 
WWW
Wisselsheim
Top  #5 Beitrag drucken
Geschrieben am 01.03.2018 um 09:04
Sorry, aber wie mache ich das ? Bin absoluter Anfänger diesbezüglich !

Danke
Sven
 
WWW
Systemweb
Top  #6 Beitrag drucken
Geschrieben am 01.03.2018 um 18:13
Im Inoffiziellen Update ist aber das DB-Feld für Birthdate geändert, daran sollte es also nicht liegen.
 
WWW
Wisselsheim
Top  #7 Beitrag drucken
Geschrieben am 01.03.2018 um 19:16
Es hängt noch immer bei Schritt 4 Konfiguration der Datenbank :-(

Zusammengefügt am 02. März 2018 um 08:14:50:
Habe WordPress zum testen installiert, Mit WP funktioniert die Datenbank, wurde imitiert.
Bearbeitet von Wisselsheim am 02.03.2018 um 08:14
 
WWW
Systemweb
Top  #8 Beitrag drucken
Geschrieben am 03.03.2018 um 20:13
Hast du evtl. Zugriff auf die error.log des Webservers oder kannst du das error_reporting in der php.ini aktivieren?
 
WWW
Rolly8-HL
Top  #9 Beitrag drucken
Geschrieben am 04.03.2018 um 16:40
Zitat: Systemweb schrieb:
Im Inoffiziellen Update ist aber das DB-Feld für Birthdate geändert, daran sollte es also nicht liegen.

Wenn ich das aber jetzt mit diesem Eintrag wie dort angegeben ist anwende.
Code
user_birthdate VARCHAR(10) NOT NULL DEFAULT '0000-00-00',
Dann geht das
Code
$result = dbquery("SELECT * FROM ".DB_USERS." WHERE user_birthdate like '____-".date("m")."-__' ORDER BY DAYOFMONTH(user_birthdate) ASC");
und das
Code
$result_eoup_nav3 = dbquery("SELECT user_id, user_name, 

user_level, user_status, user_birthdate 

FROM ".DB_USERS." 

WHERE user_birthdate LIKE '____-".date("m")."-".date("d")."' AND user_lastvisit !='0'  AND !user_status= 1 AND user_lastvisit>'$time_overdue_nav' ");
nicht mehr.
Sollte man den nicht doch lieber den Server wechseln?

Es sei denn es gibt eine Lösung dafür, für die Ausgabe diesen Monat und Heute Geburtstag.
Gruß Rolly8-HL
Was für Andere Wichtig ist muss für mich nicht genauso Wichtig sein!
Bin Dickkopf Unbelehrbar mache aus Protest nicht das was andere für Richtig halten!
Das gibt einem zu Denken oder?
 
WWW
Systemweb
Top  #10 Beitrag drucken
Geschrieben am 22.03.2018 um 18:19
@Rolly:
Problem ist, dass der default-Wert "0000-00-00" für ein Datenbankfeld vom Typ "date" nicht mehr gültig ist. Genullte Datumsangaben sind damit unzulässig.
Ist der Datenbank-Server so eingestellt das "STRICT_MODE" eingeschaltet ist (also striktes Einhalten der Regeln auf "ja") kommt es bereits bei einer Neuinstallation vom originalen PHP-Fusion 7 zu einem Fehler.

Sicher kann man raten "Wechsel doch einfach den Server bzw. Anbieter" bzw. "Ändere deine Serverinstellungen", aber das kann nicht die optimale Dauerlösung sein. Null-Angaben beim Datum sind in MySQL nun ungültig, auf STRICT_MODE = off umzustellen ist im Prinzip nur eine Verschleppung dieses Problemes.
Das entspräche dem gleichen Prinzip, als wenn man durch ein PHP-Update hervorgerufene PHP-Warnungen oder Fehler mittels Error_Reporting-Direktive unterdrückt, ohne für die nahe Zukunft eine entspr. Anpassung zu planen.

Nun könnte man hergehen und den Defaultwert auf ein gültiges Datum setzen, z.B. 1931-01-01. Die Installation klappt damit, aber man kommt zum nächsten Problem: jeder neu registrierte, der sein Geburtsdatum nicht angegeben hat, wird als 87-jähriger angegeben, denn PHP-Fusion geht nur bei genullten Werten von einem noch nicht gesetzten Geburtsdatum aus.

Als wirkliche Problemlösung bieten sich 2 Wege an:
1. Fusion beibringen, dass das Datum 1931-01-01 als "nicht angegeben" eingestuft wird und den Defaultwert wie oben ändern. Das wäre aber nur gut bei Neuinstallationen. Bei bereits bestehenden Fusionseiten würden dann Mitglieder auftauchen, die über 2000 Jahre alt sind. Man müsste also ebenfalls 0000-00-00 als "nicht angegeben" bewertet lassen. Manche Infusionen müssten dann ggfs. ebenso angepasst werden.
2. Dem Datenbank-Feld einfach einen anderen Typ zuweisen, damit man weder Fusion noch diverse Infusionen (die auch aufs Geburtsdatum zurückgreifen) umbauen muss. Hierbei muss aber sichergestellt sein, dass stets korrekte Werte im Datumsformat in diesem Feld gespeichert werden.

Setzt man also den Typ "varchar(10)", kann man weiter damit arbeiten ohne das System umbauen zu müssen. Einzig die Überprüfung durch MySQL auf einen Wert im Datumsformat entfällt, der Datenbank-Server nimmt also theoretisch alle zu speichernden Werte ohne Protest an, z.B. auch "1234567890" oder "abcdefghij", die keinem Datumsformat entsprechen.
Da PHP-Fusion die gemachten Angaben im Profil jedoch vor dem Schreiben in die DB selbst auf gültige Eingaben überprüft und das zu speichernde Geburtsdatum korrekt formatiert, kann man das vernachlässigen. Somit sollte Methode 2 angebrachter sein.

Deine Codebeispiele funktionieren dabei weiterhin problemlos.
Zur Sicherheit habe ich dein 1. Beipiel getestet unter dem Update-Pack 2.0, bei dem ebenfalls varchar(10) gesetzt ist. (Dieser Datums-Fix war aber bereits im Updatepack v1.1 enthalten.)
Es wurde ein Panelcode per Vorschau getestet mit folgendem Inhalt:
Code
$result = dbquery("SELECT * FROM ".DB_USERS." WHERE user_birthdate like '____-".date("m")."-__' ORDER BY DAYOFMONTH(user_birthdate) ASC");

while ($data = dbarray($result)) {

   echo $data['user_name']."<br />\n";

}

Dein 2. Codebeispiel funktioniert folglich ebenfalls, allerdings ist die von dir gewählte Bedingung "AND !user_status= 1" nicht zu empfehlen, da hierbei auch suspendierte und vor allem auch anonymisierte User dem Suchmuster entsprechen, lediglich deaktivierte werden herausgefiltert.
"AND user_status= 0" ist hier zu empfehlen.
 
WWW
Rolly8-HL
Top  #11 Beitrag drucken
Geschrieben am 22.03.2018 um 21:32
Da ich so einen Server nicht habe um dieses zu testen muss ich hier mal die Frage stellen.
Wäre dann eine Installation unter diesen Kriterien mit diesem Eintrag möglich?
Code
user_birthdate DATE NOT NULL DEFAULT '1901-01-01'

Wenn ja? dann hat sich meine Frage erledigt, den Rest habe ich dahingehend schon alles angepasst.
Gruß Rolly8-HL
Was für Andere Wichtig ist muss für mich nicht genauso Wichtig sein!
Bin Dickkopf Unbelehrbar mache aus Protest nicht das was andere für Richtig halten!
Das gibt einem zu Denken oder?
 
WWW
Systemweb
Top  #12 Beitrag drucken
Geschrieben am 22.03.2018 um 22:27
Meines Wissens sollten alle Datums/-Zeitangaben in MySQL ab 1000-01-01 00:00:00 akzeptiert werden.
 
WWW
Springe ins Forum: