Fehler im Nickpagemodul

Begonnen von taranis, 07 Mai 2005, 23:38:40

⏪ vorheriges - nächstes ⏩

0 Mitglieder und 1 Gast betrachten dieses Thema.

taranis

Hallo,
ich habe heute die neue Nickpageversion auf einem MX 2.1 geupdatet.
Folgende Fehler treten im Betrieb auf:

Speichern der Konfiguration im Adminpanel:

Warning: Wrong parameter count for mysql_affected_rows() in /srv/www/htdocs/xxx/html/admin/modules/userpage.php on line 1031

Warning: Wrong parameter count for mysql_affected_rows() in /srv/www/htdocs/xxx/html/admin/modules/userpage.php on line 1106


Der Bildupload für die User funktioniert nicht.
Hier erscheint folgendes:

Warning: getimagesize(): Unable to access Array in /srv/www/htdocs/web4/html/modules/Nickpage/index.php on line 1581

Warning: getimagesize(Array): failed to open stream: No such file or directory in /srv/www/htdocs/web4/html/modules/Nickpage/index.php on line 1581


Ansonsten scheint alles soweit zu laufen.
Gibt es für o.a. eine Lösung oder muss ich noch etwas andere einstellen?

Weiterhin ist mir aufgefallen, dass die Sternzeichengrafiken nicht korrekt ausgegeben werden.
Ich habe noch nicht alle getestet jedoch kann ich bereits sagen, dass bei Zwilling - Krebs als Grafik angezeigt wird. Ist aber keine grosse Sache und das kann man schnell selbst in den Griff bekommen  ;)
Soll nur einfach als Hinweis dienen.

Allerdings ist mir zu den Fehlermeldungen oben noch keine Lösung eingefallen, bzw. habe ich da noch nichts gefunden....

Gruss

Andy

RiotheRat

Woher ist das Update? Ich habe die NP inzwischen selbst ein paar Mal bei Usern installiert ... sowohl 2F, als auch MX und Pragma ... nirgends "Macken".

Und wie wurde das Update durchgeführt? Mit dem Setup-Script oder einfach die SQL in die Datenbank eingespielt? Das mit dem Bildupload liest sich irgendwie so als würden da FTP-Pfade nicht stimmen.

RtR
Unaufgeforderte PNs & Emails werden ignoriert

Erst wenn die letzte Zeile Code verhunzt, der letzte Server gehackt und der letzte Script-Kidde befriedigt ist, erst dann, werdet Ihr feststellen, dass Nuke nicht sicher ist...

taranis

Hallo,

Das Script stammt von SourceForge.net aus dem Bereich Pragma (nickpage20).
Update wurde mit der setup.php gem. Readme durchgeführt  ;)
Gibt es noch eine andere Version die ich nicht entdeckt habe?

Gruss

Andy

RiotheRat

Version:
Nee, die passt ...  ;)

Rest:
Hmm, am besten mir mal einen Zugang gewähren. FTP,- und Admindaten wären schick. phpMyMyAdmin wäre "niche to have", ist aber kein "must" ...  ::)

RtR
Unaufgeforderte PNs & Emails werden ignoriert

Erst wenn die letzte Zeile Code verhunzt, der letzte Server gehackt und der letzte Script-Kidde befriedigt ist, erst dann, werdet Ihr feststellen, dass Nuke nicht sicher ist...

taranis

Vielen Dank für das Angebot,

macht für mich aber keinen Sinn, da die Version im Moment auf einer Testumgebung läuft.
Ein Einsatz auf der laufenden Community kann ich so nicht durchführen, da einfach zu viele User davon betroffen wären.

Daher werde ich wohl die alte Version weiter laufen lassen und nicht Updaten.

Gruss

Andy

taranis

Hi,
wieso kann man eigentlich als Datenbankbesitzer die Nickpagedaten nicht vernünftig über phpmyadmin editieren?
Aufrufen geht noch mit extremer Ladezeit, allerdings Änderungen (z.B. Links) werden nicht übernommen, weil sich phpmyadmin dabei tot speichert.

Am Ende bleibt dann alles wie es ist ohne Änderungen und man hat mal eben seinen Server etwas lahmer gemacht, weil der oben beschriebene Vorgang eine Ewigkeit dauert!

Ich denke man sollte doch als Admin auch den entsprechenden Zugriff haben.

Ich verwende aber weiterhin die alte Nickpage Version, weil es mit der neuen Fassung Probs bei mir gibt (Eröffnungsthread).

Ich denke mal die Probleme mit der Ladezeit liegen an der Ablage für die Texte. Diese können ja nicht über phpmyadmin eingesehen werden.

RiotheRat

Zitat von: taranis am 08 August 2005, 11:42:12...wieso kann man eigentlich als Datenbankbesitzer die Nickpagedaten nicht vernünftig über phpmyadmin editieren?
Aufrufen geht noch mit extremer Ladezeit, allerdings Änderungen (z.B. Links) werden nicht übernommen, weil sich phpmyadmin dabei tot speichert...

Sorry - das höre ich jetzt so zum ersten Mal, und das bei inzwischen einigen hundert NP-Installationen. Ich habs gerade eben bei mir selbst nochmal durchgetestet, kein Hänger. Die Datenbank läuft "normal" wie immer.

Du kannst aber mal hier die Struktur der Tabelle {prefix}_mynp_data posten, evtl. ist da etwas nicht i.O. - das ist das einzige was mir momentan dazu einfällt.

Zitat von: taranis am 08 August 2005, 11:42:12...Ich denke man sollte doch als Admin auch den entsprechenden Zugriff haben ... / ...Ich denke mal die Probleme mit der Ladezeit liegen an der Ablage für die Texte. Diese können ja nicht über phpmyadmin eingesehen werden...

Wieso "muss" ein Admin eigentlich in allen User-Daten, noch dazu per phpMyAdmin, rumwerkeln können? Wenn ein User illegale Einträge vornimmt, dann hat der Administrator immer noch die Möglichkeit die entsprechende NP zu deaktivieren oder löschen. Und genau aus dem Grund, weil ich weiss dass immer an den Userdaten "rumgearbeitet" wird, hatte ich mich beim Datenbankdesign für eine binäre Speicherform (longblob u. blob) entschieden.

ZitatEin BLOB ist großes Binärobjekt (Binary Large OBject), das eine variable Menge von Daten enthalten kann. Die vier BLOB-Typen TINYBLOB, BLOB, MEDIUMBLOB und LONGBLOB unterscheiden sich nur hinsichtlich der maximalen Länge der Werte, die sie aufnehmen können.

Die vier TEXT-Typen TINYTEXT, TEXT, MEDIUMTEXT und LONGTEXT entsprechen den vier BLOB-Typen und haben dieselben maximalen Längen und denselben Speicherbedarf. Der einzige Unterschied zwischen BLOB- und TEXT-Typen ist, dass beim Sortieren und Vergleichen bei BLOB-Werten Groß-/Kleinschreibung berücksichtigt wird, bei TEXT-Werten dagegen nicht. Mit anderen Worten ist ein TEXT ein BLOB ohne Berücksichtigung der Groß-/Kleinschreibung.
http://dev.mysql.com/doc/mysql/de/blob.html

Es liegt also definitiv -nicht- an der Speicherform. mySQL ist durchaus in der Lage mit binären Objekten umzugehen. Und wenn auch ein Administrator "Zugriff" auf die hinterlegten Usertexte haben soll, dann empfiehlt es sich den Spaltentyp zu ändern ...

ALTER TABLE `{prefix}_mynp_data` CHANGE `np_maintext` `np_maintext` LONGTEXT DEFAULT NULL
ALTER TABLE `{prefix}_mynp_data` CHANGE `np_footertext` `np_footertext` TEXT DEFAULT NULL


Der Wechsel des Spaltentyps kann (in dem Fall) auch dann erfolgen wenn bereits Daten hinterlegt sind. Ein Backup empfiehlt sich dennoch.

RtR
Unaufgeforderte PNs & Emails werden ignoriert

Erst wenn die letzte Zeile Code verhunzt, der letzte Server gehackt und der letzte Script-Kidde befriedigt ist, erst dann, werdet Ihr feststellen, dass Nuke nicht sicher ist...

taranis

Hi Rio,

erst einmal vielen Dank für Deine schnelle Antwort  :thumbup:

  `npuid` int(11) default NULL,
  `np_uname` varchar(25) default NULL,
  `np_urlname` varchar(50) NOT NULL default '',
  `np_status` smallint(1) NOT NULL default '0',
  `np_service` smallint(1) NOT NULL default '1',
  `np_pagelang` varchar(25) default NULL,
  `np_banner` smallint(1) NOT NULL default '0',
  `np_email` smallint(1) NOT NULL default '0',
  `np_gb` smallint(1) NOT NULL default '1',
  `np_gbadmincolor` varchar(20) default NULL,
  `np_hgcolor` varchar(7) default NULL,
  `np_txtcolor` varchar(7) default NULL,
  `np_linkcolor` varchar(7) default NULL,
  `np_activelink` varchar(7) default NULL,
  `np_vislink` varchar(7) default NULL,
  `np_headline` varchar(255) default NULL,
  `np_footintro` varchar(255) default NULL,
  `np_maintext` longblob,
  `np_footertext` blob,
  `np_fontface` varchar(50) default NULL,
  `np_linkface` varchar(50) default NULL,
  `np_fontsize` smallint(2) default NULL,
  `np_linksize` smallint(2) default NULL,
  `np_userbirth` varchar(10) default NULL,
  `np_zodiac` smallint(2) default NULL,
  `np_design` smallint(1) NOT NULL default '0',
  `np_enabledate` smallint(1) NOT NULL default '0',
  `np_datefull` smallint(1) NOT NULL default '0',
  `np_gender` char(1) default NULL,
  `np_enablegender` smallint(1) NOT NULL default '0',
  `np_linkurl1` varchar(255) default NULL,
  `np_linkurl2` varchar(255) default NULL,
  `np_linkurl3` varchar(255) default NULL,
  `np_linkurl4` varchar(255) default NULL,
  `np_linkurl5` varchar(255) default NULL,
  `np_linktxt1` varchar(100) default NULL,
  `np_linktxt2` varchar(100) default NULL,
  `np_linktxt3` varchar(100) default NULL,
  `np_linktxt4` varchar(100) default NULL,
  `np_linktxt5` varchar(100) default NULL,
  `np_mempic1` varchar(100) default NULL,
  `np_mempic2` varchar(100) default NULL,
  `np_mempic3` varchar(100) default NULL,
  `np_alttag1` varchar(40) default NULL,
  `np_alttag2` varchar(40) default NULL,
  `np_alttag3` varchar(40) default NULL,
  `np_name` smallint(1) NOT NULL default '0',
  `np_viewemail` smallint(1) NOT NULL default '0',
  `np_url` smallint(1) NOT NULL default '0',
  `np_icq` smallint(1) NOT NULL default '0',
  `np_aim` smallint(1) NOT NULL default '0',
  `np_yim` smallint(1) NOT NULL default '0',
  `np_msnm` smallint(1) NOT NULL default '0',
  `np_occ` smallint(1) NOT NULL default '0',
  `np_from` smallint(1) NOT NULL default '0',
  `np_intrest` smallint(1) NOT NULL default '0',
  `np_counter` smallint(1) NOT NULL default '0',
  `np_counterdata` int(11) NOT NULL default '0',
  `np_scolorbg` varchar(20) default NULL,
  `np_scolortxt` varchar(20) default NULL,
  `np_lastedit` date default NULL,
  KEY `np_uname` (`np_uname`)
) TYPE=MyISAM;


Reicht Dir das als Struktur?

Wie sieht es eigentlich mit dem Update auf die neueste Nickpage Modul Version aus. Es ga da ja einige Probs beim Bildupload und desshalb hatte ich auch die alte Version belassen.

Hattest Du da nochmal etwas verändert? Hatte glaube ich hier im Board gelesen, dass es auch bei anderen zu den Problemen gekommen war.
Sorry, wenn ich da jetzt falsch liege  ;)

RiotheRat

Da fehlt der Index auf den Usernamen ... führ das mal mit phpMyAdmin aus:ALTER TABLE `{prefix}_mynp_data` ADD INDEX ( `np_uname` )

Eigentlich dürfte sich phpMyAdmin deswegen zwar nicht "aufhängen", Fakt ist aber dass bei Dir der Index fehlt. Die Uploadroutine ist schon lange geändert, weil es da unter PHP 5 evtl. zu Problemen kommen konnte. Ein Update auf die neueste Version (erscheint diese Woche) kann man nur empfehlen.

Zumal dann einige neue Funktionen hinzukommen. U.a. User-zu-User - Sticker, BigBrother - Funktion und noch einige andere Features. Wer das Photo-Voting / Flirt-On mit einbinden möchte muss eh auf die neueste Version updaten.

RtR

P.S.: Die letzten Zeilen des mySQL-Dumps sollten nach dem setzen des Index so aussehen ...PRIMARY KEY  (`npuid`),
KEY `np_uname` (`np_uname`)
) TYPE=MyISAM;
Unaufgeforderte PNs & Emails werden ignoriert

Erst wenn die letzte Zeile Code verhunzt, der letzte Server gehackt und der letzte Script-Kidde befriedigt ist, erst dann, werdet Ihr feststellen, dass Nuke nicht sicher ist...

taranis

OK.. vielen Dank  :thumbup:
Dann würde ich doch mal sagen, warten wir auf die neueste Version und schauen dann mal weiter....