Es geht um das Bewerbungsformular von Prugnator.
Und zwar habe ich folgendes Problem. Wenn jemand das Formular ausfüllt, kommt nur die Hälfte bei mir im AdminBereich an. Hab es mal selbst ausprobiert. Bewerbung komplett ausgefüllt, die meisten Dinge kommen aber noch nicht mal in der SQL Datenbank an, meist nur die Dinge die mit Zahlen ausgefüllt werden müssen. Der Rest bleibt leer. Woran könnte das liegen? An PHP7 ?

Bei PHP 7 geht das Standard Bewerbungsscript nicht mehr. Es müssen alle mysql_ nachgearbeitet werden.

Oh mein Gott, wenn ich wüsste was da nachbearbeitet werden muss.

Da sind nur keine mysql_ Angaben vorhanden

Zusammengefügt am 29. Mai 2017 um 15:237:
Ich habe mir die Antwort mal selbst gegeben. Harlekin hat auf seiner Seite im Downloadbereich das Bewerbungsscript für PHP7
https://harlekinpower.de/downloads.ph...load_id=58

Sind doch welche drin. Zum Beispiel in der functions.inc.php

Ich hab es bei mir als Download für Projekt PHP7 (pdo), ob es so auch mit dem SQLI Fix funktioniert, habe ich nie probiert.

Wenn ich mich recht erinnere, ist im Adminscript die Funktion "mysql_num_rows" vorhanden. Die einfach in "dbrows" ändern und alles läuft wieder.
In infusion.php würde ich noch prüfen, ob dort type="myisam" statt engine="myisam" verwendet wird.
Bin mir da nicht mehr sicher, falls ja kann man das mit suchen->ersetzen einfach austauschen.
Hab vor kurzem dieses Script erst für jemanden installiert und es läuft unter PHP 7.1 mit dem MySQLi-Fix einwandfrei

In der protected.inc.php ist auch noch:


Für meine PDO Geschichte habe ich es angepasst als Download auf meiner Seite. Ob es aber auch so auf dem mysqli Fix läuft, habe ich nicht probiert und kann daher dazu nichts sagen.

Theoretisch müsste beim mysqli Fix daraus werden:

Hallo,

habe eben die PDO Version auf einer Testseite mit dem SQLI Fix getestet und dies Schein vom ersten Anschein nach auch dort zu funktionieren

Septron

Der SQLi Fix enthält in der maincore entspr. Definitionen für die veralteten Funktionen "mysql_field_name" und "mysql_escape_string".
Dies kann man erweitern für die Funktion "mysql_real_escape_string":Wenn man das wie gehabt in der globalen maincore.php festlegt muss man kaum Infusionen nachbearbeiten, außer es sind darin noch die alten mysql-Befehle statt der DB-Funktionen von Fusion enthalten.

Ich bin momentan dran das System fit für PHP7 zu machen, da ich aber gleichzeitig noch einige weitere Anpassungen an dem System vornehmen will dauert es noch ein wenig bis zum Release.

Die meisten Stellen wo etwas angepasst werden muss habt ihr aber glaube ich schon zusammen getragen. Was jedoch noch fehlt ist in der admin/forum_post.inc.php ist mehrmals Folgendes zu finden:

dieses müsste man auch entsprechend anpassen:

Hallo,

wieso noch eins auf PHP7 PDO Harlekin hat dies doch schon angepasst das was vielleicht noch als extra sein müsste wäre für den Fix von Krelli

Also die Anpassung von Harlekin (für PHP-Fusion v7.02.07 PDO)

Funktioniert für diese PHP Fusion Version so wie auch für diese PHP Version 5.3.x - 7.0.x (vielleicht müssten die Funktionen für den Fix noch ausgebessert werden)

lg Septron

funktioniert so aber nur mit dem mysli Fix! Für mein Projekt PHP7 (7.02.07 mit PDO) https://github.com/HarlekinPower/Proj...t-PHP7-1.1 musste ich das anders lösen.

Aber da habe ich es ja auch schon fertig!

Moin. Ich hab das gleich Problem, kann aber leider der Problemlösung nicht ganz folgen. Anzumerken bleibt, das ich mich auch erst seit kurzem mit phpFusion befasse. Die Fragen, die sich mir hier nach dem lesen auftun sind:
1. Wer oder was ist SQLI Fix ?
2. Wo bekomme ich den her ?
3. Die Links auf Harlekins Webseite enden im "Stop ! Download geschlossen - Grund: Wartungsarbeiten.

Kann mir sonst mal jemand den Lösungssatz in einfacher Sprache mitteilen ?? Nicht das ich nicht intelligent bin, aber hier habe ich gerade meine Probleme.

Ich habe den Herrn Prugnator auch schon per E-Mail angeschrieben, aber leider bis zum heutigen Tag keine Antwort bekommen. Vielleicht erhalte ich ja hier Hilfe, oder ich bin echt zu alte für so etwas.
Gruß
Ingo

Daten: phpInfusion 7.02.07 und PHP Version 5.6

Grübel... Was müssen Ihr jetzt von mir denken....

1. Bei PHP 5.6 sollte das Bewerbungsscript noch normal funktionieren.
2. Schau mal oben rechts, da findest du die Links zum V7 MYSQLi Paket und auch zum V7 PDO Paket.
3. In eigener Sache:
Ich hab das normale Downloadsystem ausgeschaltet und nutze jetzt das PDP. Alle Links sind aber auch angepasst worden, daher kann ich das mit der Stopseite nicht verstehen.
Und auf meiner Seite das Bewerbungsscript von Prugnator funktioniert nur mit Projekt PHP7 (V7 PDO)! Und nicht mit V7 MYSQLi oder dem normalen PHP Fusion 7.02.07.

Das kommt aus diesem Link wahrscheinlich.

Moin. Danke für die schnelle Antwort. Wenn ich das richtig sehe, brauche ich den SQLFix erst ab der PHP Version 7 und den POD ist quasi eine Eigenentwicklung. Wenn der SQLFix nun aber schon in der PHP 5.6 Version aufgespielt wurde, beeinflußt das eventuell auch das Bewerbungsformular ??
Fragen über Fragen
Gruß
Ingo

Mal zur Erklärung:
PHP 5.6 ist mehr oder weniger tot. Viele Webspaceanbieter haben mittlerweile nur noch PHP 7 im Angebot. Aktuelle PHP Version ist 7.1.8. Wer also jetzt seine Seite aufbaut, sollte das am besten gleich auf PHP 7 tun. Dann ist er auf der sicheren Seite. Auf PHP 7.x läuft aber das normale PHP Fusion 7.02.07 nicht mehr.

Systemweb und ich haben Zeigleich, ohne das wir davon wussten an einer Lösung gearbeitet um PHP Fusion auf PHP 7 zum laufen zu bekommen. Dabei hatten wir unterschiedliche Ansätze in der Grundpaketwahl und in der Datenbankanbindung.

Projekt PHP7 (PDO) ist das original PHP Fusion 7.02.07 Paket (keine Eigenentwicklung, nur eine Anpassung) mit bereits intrgierter deutschen Locale, welches auf PHP7 läuft mit Datenbankanbindung PDO. Das sollte auch auf PHP 5.6 laufen,PDO gibt es glaube ich seit PHP 5.1, habe es aber nie getestet. V7 MySQLi oder auch MYSQLi Fix genannt ist die PHP-Fusion 7.02.07 DE-Edition, welche als Datenbankanbindung MySQLi nutzt.

Ich hoffe, das erklärt erstmal die Unterschiede zwischen den Paketen. Ich bin jetzt nur noch zusätzlich beigegangen und habe für Projekt PHP7 (PDO) schon Infusionen komplett angepasst, die ich bei der ein oder anderen Seite gebraucht habe. Diese Infusionen biete ich nun als Service für Projekt PHP7 mit an. Diese arbeiten aber nur mit der PDO Datenbankanbindung und nicht mit MySQLi!

Hallo Harlekin. Soweit habe ich das verstanden. Mein Problem ist, das ich mich zur Zeit noch nicht richtig eingearbeitet habe da es für mich Neuland ist. Nicht das ich nicht schon HPs erstellt habe, aber das ist inzwischen 8 Jahre her und nicht mit PHP. Warum ich nun PHP 5.6 gewählt habe ist folgender, da der PCPIN Chat leider auf PHP7 nicht funktioniert, zumindest nicht nach meinen Tests. Sicherlich gibt es auch andere Chats, aber meine Modis aus dem Web Radio waren / sind den gewöhnt und das ist nicht so einfach denen das wieder abzugewöhnen auch wenn sie in absehbarer Zeit damit rechnen müssen. So, nun haben wir uns gegenseitig viel erklärt, aber das Problem nicht gelöst. Das Bewerbungsformular habe ich nun zum zweiten Mal installiert, aber außer der PLZ. der Anzahl der Musiktitel und der IP Adresse werden keine weiteren Daten übermittelt. Wie oben angeführt hab ich zur Zeit noch gar keine Ahnung wo ich da suchen soll.
Gruß
Ingo

Im MySQLi Fix wurde dafür die Funktion "db_lastid()" im Handler integriert.

Man müsste also in Infusionen nur alle Vorkommen von mysqli_insert_id durch db_lastid ersetzen.

(Wenn im PDO Handler für PDO::lastInsertId eine gleichnamige Function db_lastid integriert wird, hätten wir dann weitere Infusionen die generell funktionieren, egal ob PDO oder MySQLi verwendet wird.)

Systemweb schrieb:


Ich fange mysql_insert_id doch im DB Handler ab. Das sollte reichen.

Allerdings hatte ich einiges schon vor der Erweiterung des DB Handlers fertig. Und ich werde auch weiterhin direkt Infusionen an die PDO anpassen, weil es oft nicht nur an den Datenbankabfragen hapert, sondern auch an den Änderungen am Code durch PHP 7.Da ist das ein Abwasch.

Nun aber zurück zum Problem, ich glaube das hatte was mit der Variable $wert zu tun in der functions.php, kann da aber nicht weiterhelfen, weil ich nur mein altes Notebook mit habe.

Das wird jetzt leider etwas ausführlicher, aber ich muss mal einiges loswerden und schreibe einfach frei von der Leber weg.
Manch einer wird sich auf den Schlips getreten fühlen, aber klare Worte müssen auch mal sein. Ist teilweise ziemlich Offtopic, dafür aber aktuell:

Leider reicht das nicht. Zahlreiche Hoster (z.B. Str*to) kompilieren die zur Verfügung gestellten PHP-Versionen komplett selbst und bauen hierbei das veraltete MySQL-Modul zwecks Abwärtskompatibilität mit ein. (Dass dabei mitunter total verbuggte PHP-Versionen im Einsatz sind sei hier nur nebenbei erwähnt.)
Auch gibt es immernoch Leute, die aus Kompatibilitätsgründen noch PHP Version 5.x einsetzen, bei der neben PDO u. MySQLi noch das alte MySQL Modul ebenfalls im Einsatz ist.
Hier lässt sich die Funktion also nicht auf diese Weise "abfangen".
Das PHP5.x-Problem betrifft allerdings nicht das Projekt 7.1, da dort generell für PHP 7.1 entwickelt wird.

Die einfache Methode, unbekannte Funktionen "abzufangen" indem diese einfach neu definiert werden, funktioniert also nicht überall. Unter PHP 7.0/7.1 wäre dann nämlich bei solchen Anbietern diese Funktion "bekannt" und würde als solche auch ausgeführt werden. Man hat also eine aktuell definierte PDO Verbindung zur DB und mittendrin wird ein mysql-query ausgeführt - das führt natürlich zu Fehlern.
Grundsätzlich ist es also immer ratsam, solche alten Funktionen ganz aus dem Code zu entfernen um Konflikte zu vermeiden.
Für MySQLi gilt das in gleicher Weise.

Man tut das bereits, überarbeitet die alten Infusionen, macht diese komptatibel zu PHP 7.1 und ersetzt die entspr. veralteten Datenbank-Befehle durch neue. Allerdings ausschließlich immer nur für PDO, weil dabei exakt der gleiche Fehler wiederholt wird: statt vordefinierter DB-Funktionen baut man direkte DB-Befehle in die Scripte ein.
Alle alten Scripte und Infusionen, in denen direkte mysql-Befehle im Code verwendet worden sind, müssen wir heute ausbessern.

Nehmen wir mal an, morgen hätte PDO ausgedient und würde durch ein neues Modul ersetzt werden. Dann wird es mit dem Projekt 7.1 genau das gleiche sein.
Sicher kann das noch lange dauern, aber so abwegig ist dieser Gedanke gar nicht: PDO gibt es schon lange (seit PHP 5.1). Es ist bei jedem Request um einige Millisekunden langsamer, benötigt mehr Code (bekanntermaßen werden alle Statements für die Datenbank ja vor dem ausführen "vorbereitet" mittels "prepare").
Manche behaupten, auf Grund der Preparation der Statements wäre es sicherer, aber Injections sind in PDO genauso möglich wie in MySQLi. Lediglich fehlerhafte Statements werden auf diese Weise abgefangen, um den Datenbank-Server damit nicht unnötig zu konfrontieren.

Der eine mag eher PDO, der andere lieber MyQLi. Das muss jeder selbst entscheiden.
ABER: Da scheinbar keine Einigung darüber möglich ist, kompatible DB-Handler mit den gleichen Funktionsnamen zu verwenden, können MySQLi Anwender die überarbeiteten Infusionen nicht ebenfalls einsetzen. Genau davor hatte ich mehrfach gewarnt. Nur weil man nicht bereit ist, auf standardisierte Funktionen zu setzen statt PDO-Befehle einzubauen spaltet sich die gesamte Weiterentwicklung.

Du baust also weiterhin alles so um, dass es nur mit deiner PDO-Variante läuft. Alle Infusionen müssen deshalb entsprechend gekennzeichnet werden, ob Sie für PDO oder MySQLi geeignet sind.
Der Allgemeinheit wäre mehr geholfen, wenn Infusionen generell funktionieren.
Stattdessen soll man wohl "gezwungen" sein, das "einzig wahre PDO" einzusetzen.

Wenn man Infusionen ohnehin PHP7-tauglich macht wäre es genauso nur "ein Abwasch", wenn man statt PDO-Befehlen einfach auf vordefinierte Funktionen zurückgreift.
Dass das Ganze problemlos möglich ist, hatte ich mit meiner seinerzeit zurückgezogenen voll funktionsfähigen PDO/MySQLi-Variante gezeigt.
In meinem Fix findet man keinen einzigen DB-Befehl in Scripten, sogar das ausführliche Datenbank-Backup-Script im Adminbereich greift auf Funktionen zurück, die im Handler bereitgestellt sind.

Auf deine Weise lenkst du die Entwicklung wie ausführlich bereits erwähnt auf 2 Schienen. Habe schon so oft auf diese eingeschlagene Richtung hingewiesen.
Inzwischen habe ich das Gefühl, ich könnte noch so gute Argumente bringen und mir den Mund fusslig reden, ich stoße stets auf "Beratungsresistenz".
Weitestgehend gemeinsame Schiene zu fahren war eigentlich abgesprochen... Unter dieser Voraussetzung hatte ich damals meine Version des PDO-Handlers wieder zurückgezogen.

Ich bleibe bei meiner Meinung, dass direkte DB-Befehle in den Scripten nichts verloren haben, dafür nutzt ein Entwickler globale DB-Funktionen.