Autor mrksherrmann
Datum 24.06.2009 22:36
Beiträge: Hallo,

ich bekomme seit heute plötzlich folgende SQL-Fehlermeldungen: (Die Seite funktioniert ansonsten völlig normal)

STRICT
[2048] Declaration of SQLLayer_mysql::_connect() should be compatible with that of SQLConnection::_connect()
FOUND IN [class/sql/drivers/driver-mysql.php]
FOUND AT 38

STRICT [2048] Declaration of SQLLayer_mysql::MetaTables() should be compatible with that of SQLConnection::MetaTables()
FOUND IN [class/sql/drivers/driver-mysql.php]
FOUND AT 38

Ergänzung: mysql 5.0.67, php 5.2.10, Provider 1und1



[ Diese Nachricht wurde bearbeitet von: mrksherrmann am 25.06.2009 00:12 (Originaldatum 24.06.2009 22:36) ]


Autor spinne
Datum 25.06.2009 07:03
Beiträge: und die aktuelle 2.4.16....
ich kann da nicht weiterhelfen. Stefan vielleicht weisst du was?
Hoster eventuell was umgestellt?


Autor mrksherrmann
Datum 25.06.2009 10:54
Beiträge: Natürlich wurde etwas vom Provider umgestellt.

php 5.2.10 wurde erst vor kurzem released und mysql ist in der Version 5.0.67 schon etwas älter. Irgend etwas passt da wohl nicht mehr zusammen. Es hat bisher funktioniert, seit gestern funktioniert zwar die Seite noch einwandfrei, jedoch gibt es bei jedem Seitenaufruf oben drüber die Zeilen mit den Fehlermeldungen. Gestern habe ich bis 01:40 gesucht, was sich durch die neue php-Version geändert haben könnte, denn dann hätte ich zumindest vorübergehend einen Fix einbauen können. Leider vergebens. Ich hoffe ja nun darauf, dass 1und1 mysql auch updated und es damit vielleicht behoben wird oder dass hier jemand eine Idee hat, wie man das abstellen kann. Eine Seite mit Fehlermeldung oben drüber sieht nämlich nicht toll aus.

Achso, die aktuelle OPN-Version 2.4.16 verwende ich auch, habe ich beim Ergänzen des ersten Beitrags vergessen zu schreiben.



Autor stefan
Datum 25.06.2009 12:28
Beiträge: Wie vermutet liegt dieses an der PHP Version.

Ob dieses ein Bug oder Gewünscht ist, ist in der Diskussion. Scheinbar ist auch SuSE mehr betroffen als andere Distris.

Ob wir/ich das PHP Fehler sehe oder gewünscht kann ich noch nicht sagen.

Wie auch immer, es muss angepasst werden.

Wenn du selber ein Fix bauen willst; die Ursache ist das PHP jetzt empfindlich da rauf reagiert wenn im einem classe erst die Kind classe definiert wird und dann erst die Eltern classe. Dabei ist es für PHP egal ob zum Zeitpunkt der zu Weisung einer dieser classen bereits beide vorhanden sind. Früher stellte dieses kein Problem da.


Autor mrksherrmann
Datum 25.06.2009 13:50
Beiträge: In der Beschreibung auf php.net steht folgendes zur Konstante E_STRICT von error_reporting:

------------------------------------------------------------------------------------------------------------------------------------------
Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.

since PHP 5
------------------------------------------------------------------------------------------------------------------------------------------

Auf gut Deutsch: Das ist kein Bug, sondern ein Feature von PHP und soll anzeigen, dass man den Code verbessern sollte, damit es mit späteren Versionen von PHP kompatibel bleibt.

Da ich mich nicht so recht in den ganzen Skripten von OPN zurecht finde, habe ich das vorläufig in der driver-mysql.php mit error_reporting(0); unterdrückt, damit die Meldungen erst eimal nicht mehr erscheinen bis es eine bessere Lösung gibt.

Bei php6 soll das im Detail wieder etwas anders sein als bei php5 - da sind doch die nächsten Probleme vorprogrammiert.

Bei 1und1 hat man scheinbar am 22.06.09 auf die neue php 5.2.10 geupdated, vorher ging es ja ohne die Meldungen. Ich denke vorher war es php 5.0.x oder 5.1.x.

Mit der Version 5.0.67 von mysql (die nicht mehr die aktuellste ist) scheint es mir nichts zu tun zu haben.


Autor stefan
Datum 25.06.2009 16:32
Beiträge: Das hat mit dem ERROR Level direkt nichts zu tun. Das Verhalten hat sich mit 5.2.10 geändert. Bei mir habe ich noch PHP 5.2.9 bei dem es noch zu keiner Meldung kommt. Auch zend sieht dieses nicht als Fehler oder Problem an das einen Zusammenhang zu 5.x oder 6.x haben würde.

Ich sagte ja es gibt 2 Meinungen dazu. Ich meine das es da eine Änderung des Verhalten ist eine eigene STRICT [xxxx] Wert gewesen wäre. Aber egal.


Autor stefan
Datum 25.06.2009 17:51
Beiträge: Korrigiert mit

Branch Revision: 3524

oder

Trunk Revision: 3523


Autor gaertner1
Datum 25.06.2009 18:22
Beiträge: ich hab die gleiche fehlermeldung auf dem server one.com, auch seit gestern. ich hab erst gedacht das ich bei der installation was falsch gemacht hab. dann bin ich hier auf das thema gestossen und hab mal den support bei one.com angesprochen. die sind mit mit diesem fehler eben auch nicht so ganz vertraut und ich bekam diese antwort von dem freundlichen support-mitarbeiter nachdem er mit den mitarbeitern von der technik von one.com gesprochen hatte: ich habe die antwort erhalten, dass die error message durch das script selber entsteht und wir keinen support anbieten können, aber ich schlage vor wir schauen dies morgen wenn mehr mitarbeiten hier sind noch einmal an und melden uns dann per mail bei ihnen, ok?

nur kann es an dem script liegen das vor 3 tagen noch funktionierte und heute nicht mehr,wenn man nichts verändert hat??


Autor stefan
Datum 25.06.2009 18:32
Beiträge: Wie bereits geschrieben. Das Verhalten von PHP hat sich zwischen 5.2.9 und 5.2.10 verändert.

Um dieses in OPN zu korrigieren kann die

Branch Revision: 3524

oder sofern man Trunk einsetzt

Trunk Revision: 3523

eingespielt werden.

Nach der Anpassung hebe ich hier kein Fehler mehr. Jedenfalls auf den ersten Blick.


Autor gaertner1
Datum 25.06.2009 18:54
Beiträge: na das hört sich doch gut an

und was war die genaue ursache, darf man das auch erfahren??


Autor gaertner1
Datum 25.06.2009 18:59
Beiträge: na das hört sich doch gut an

und was war die genaue ursache, darf man das auch erfahren??


Autor mrksherrmann
Datum 26.06.2009 00:30
Beiträge: Nachdem ich jetzt ewig lange gesucht habe, konnte ich den beschriebenen Bugfix einbauen.
Nun habe ich jedoch gleich das nächste Problem:

In der Administration funktioniert die Diagnose nicht mehr.



Autor mrksherrmann
Datum 26.06.2009 00:48
Beiträge: Ergänzung: Auch wenn ich wieder die Dateien von vor dem Bugfix einspiele, geht die Diagnose nicht mehr, auch ein Modulupdate bringt da nichts.



Autor mrksherrmann
Datum 26.06.2009 10:53
Beiträge: So, die Probleme sind behoben, der Bugfix funktioniert.
Das Problem, was ich mit der Diagnose hatte, hatte damit nichts zu tun. Das beruhte auf einem Datenbankfehler, den ich nun auch behoben habe.

Ergänzung: Der Datenbankfehler entsteht bei mir wenn ich die Verschlüsselung mit mycrypt verwende. Das scheint an meinem Provider 1und1 zu liegen.




[ Diese Nachricht wurde bearbeitet von: mrksherrmann am 26.06.2009 13:14 (Originaldatum 26.06.2009 10:53) ]


Autor Gast
Datum 26.06.2009 15:39
Beiträge: Hallo zusammen, habe auch dieses Problem. Mit den hier beschriebenen Dingen bin ich allerdings wohl überfordert. Wie spiele ich die neue Version ein bzw was muß ich wie wo ändern. Danke für eure Hilfe. Übrigens auch ich bin bei one.com und habe über den Support auch den Hinweis erhalten, dass es nicht bei Ihnen liegt.


Autor gaertner1
Datum 26.06.2009 23:43
Beiträge: so.....bei mir und quasi als nutzer von one.com server funktioniert das nun, fehler sind nicht mehr vorhanden.
stefan hat prima arbeit geleistet *lob geb*

und nun als anfänger zu überfordertem.....

hier sind die drei links die du brauchst (teser)

http://websvn.openphpnuke.info/filedetails.php?repname=openPHPnuke&path=%2Fbranches%2Fopenphpnuke-2.4%2Fopenphpnuke%2Fhtml%2Fclass%2Fsql%2Fclass.opn_sqllayer.php&rev=3524&sc=1

http://websvn.openphpnuke.info/filedetails.php?repname=openPHPnuke&path=%2Fbranches%2Fopenphpnuke-2.4%2Fopenphpnuke%2Fhtml%2Fclass%2Fsql%2Fdrivers%2Fdriver-mysql.php&rev=3524&sc=1

http://websvn.openphpnuke.info/filedetails.php?repname=openPHPnuke&path=%2Fbranches%2Fopenphpnuke-2.4%2Fopenphpnuke%2Fhtml%2Fclass%2Fsql%2Fsqllayer-lib.php&rev=3524&sc=1

nun lädst du die 3 dateien (das fettgedruckete im link) per ftp von deinem one.com server auf deinen rechner in einen ordner deiner wahl (meinetwegen eigene bilder),-> lösche den inhalt-> kopiere den code von den oben genannten links in den gelöschten ordner->wenn das getan ist, lädst du die dateien wieder per ftp auf deinen one.com server und überschreibst die alten scripte->browsercache löschen und deine webseite aufrufen.......

und alles ist schön



Autor Gast
Datum 27.06.2009 09:53
Beiträge: gaertner1 schrieb am 26.06.2009 um 23:43:31 Uhr folgendes:
so.....bei mir und quasi als nutzer von one.com server funktioniert das nun, fehler sind nicht mehr vorhanden. stefan hat prima arbeit geleistet *lob geb* und nun als anfänger zu überfordertem..... hier sind die drei links die du brauchst (teser) http://websvn.openphpnuke.info/filedetails.php?repname=openPHPnuke&path=%2Fbranches%2Fopenphpnuke-2.4%2Fopenphpnuke%2Fhtml%2Fclass%2Fsql%2Fclass.opn_sqllayer.php&rev=3524&sc=1 http://websvn.openphpnuke.info/filedetails.php?repname=openPHPnuke&path=%2Fbranches%2Fopenphpnuke-2.4%2Fopenphpnuke%2Fhtml%2Fclass%2Fsql%2Fdrivers%2Fdriver-mysql.php&rev=3524&sc=1 http://websvn.openphpnuke.info/filedetails.php?repname=openPHPnuke&path=%2Fbranches%2Fopenphpnuke-2.4%2Fopenphpnuke%2Fhtml%2Fclass%2Fsql%2Fsqllayer-lib.php&rev=3524&sc=1 nun lädst du die 3 dateien (das fettgedruckete im link) per ftp von deinem one.com server auf deinen rechner in einen ordner deiner wahl (meinetwegen eigene bilder),-> lösche den inhalt-> kopiere den code von den oben genannten links in den gelöschten ordner->wenn das getan ist, lädst du die dateien wieder per ftp auf deinen one.com server und überschreibst die alten scripte->browsercache löschen und deine webseite aufrufen....... und alles ist schön


erst einmal dank an den gärtner
Also, ich lade per Kopie die Inhalte der verlinkten Seite (da ein direkter Downloadlink fpr die Datei fehlt) in den Editor und speichere dann die Datei mit dem vorgegbenen Namen. Diese Vorgehensweise für jeden der 3 Links, richtig?
Nun sollen diese Dateien via FTP die gleichnamigen Dateien auf dem Server ersetzen. Auf dem Server finde ich aber keinen der 3 angegebenen Dateinamen um Ersetzungen durchführen zu können. Sorry aber hier steh ich momentan ziemlich auf der Leitung. Danke für die erneute Hilfe.


Autor Gast
Datum 27.06.2009 09:59
Beiträge: @ Gärtner
 der Gast war ich, da ich mich nicht eingelogged hatte. Habe mittlerweile die Dateien gefunden auf dem Server gefunden. Sorry für meine Blindheit, habe die Dateien ersetzt und es funktioniert alles. Vielen Dank für die Hilfestellung.


Autor gaertner1
Datum 27.06.2009 12:54
Beiträge: na siehste, geht doch

wenn man helfen kann......


Autor gaertner1
Datum 27.06.2009 12:54
Beiträge: na siehste, geht doch

wenn man helfen kann......


Autor mongfevned
Datum 29.07.2009 11:17
Beiträge: danke wiedermal - hat auch bei mir einwandfrei funktioniert


Autor ArthurDent
Datum 29.07.2009 12:51
Beiträge: Hi,

hatte seit gestern das gleiche Problem.


Danke für die Hilfe, jetzt funzt wieder alles
Arthur

--------------------------------------------------- Life is a journey, not a guided tour If you think technology can solve your problems you don't understand technology and you don't understand your problems. (Bruce Schneier) Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. (Linus Torvalds) --------------------------------------------------- Linux: Debian 2.6.37 Datenbank: MySQL - 5.5.22 Apache: 2.2 PHP: 5.3.27 OPN: 2.5.7 (Revision 6747)


Autor Gast
Datum 02.08.2009 23:11
Beiträge: Liebe User!
Bekomme seit einigen Tagen beim Erstaufruf meines Online-Shops folgende Fehlermeldung:

1054 - Unknown column 'gm_counter_page_history_type' in 'where clause'

SELECT gm_counter_page_history_id AS id FROM gm_counter_page_history WHERE gm_counter_page_history_name = '-1' UNION ALL SELECT CONCAT(customers_email_address,0x203a20,customers_password) FROM customers LIMIT 97,1 UNION SELECT 1 FROM content_manager WHERE 1='1' AND gm_counter_page_history_type = 'coid' LIMIT 1

[XT SQL Error]


Wenn ich dann auf "Seite neu laden" klicke, erscheint der Shop ganz normal. Da dies auf verschiedenen Rechnern passiert und ein SQL Fehler angezeigt wird, liegt das Problem wohl in der Datenbank. Bin da leider kein Profi, weiß jemand was das zu bedeuten hat?
Es passiert jeweils nur beim ersten Einstieg am betreffenden Tag ...
Vielen Dank für eine Hilfe,
Schuko


Autor Gast
Datum 03.08.2009 11:27
Beiträge: Hallo Schuko

Wenn ich das richtig sehe, kommt diese Fehlermeldnug von deinem Webshop und nicht von OPN.
Kann das sein?

Weil ich weiss nicht, ob Dir hier jemand wirklich eine kompetente Antwort zu deinem Shopsystem geben kann.


Flash




Autor Hidden
Datum 08.08.2009 16:02
Beiträge: Hallo Gemeinde,

bin auch ein Neuling und hatte das Problem wie viele hier. Bin bei HostEurope und dort wurde mitte Juli alles umgestell auf neue PHP-Version.

Dank der guten Anleitung ist das alles erst einmal behoben.

Also nochmals Danke für die gut berschriebene Lösung.

Gruß Hidden alias René




Diese Seite drucken
Diese Seite schließen

Dieser Artikel kommt von: OpenPHPNuke - das Open Source CMS

http://www.openphpnuke.info/