Notices und Warnungen [Archiv] - VMSone Supportforum

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Notices und Warnungen

DasGuru

11.08.2011, 08:45

WaechterMedia

11.08.2011, 09:54

Ja das problem ist ja aber das das Script 10 Jahre alt ist benutz mal die suche dann findest du genug dazu.

DasGuru

11.08.2011, 10:03

Die meisten sachen habe ich schon bei mir gefixxed.
Evtl pack ich das mal zusammen und lass es Euch zukommen

breaker

11.08.2011, 20:24

Hi Leute

ich finde es ja toll, dass ihr das Script gratis anbietet und auch noch support leistet, aber ich möchte trotzdem mal etwas bemängeln

Man entwickelt keine Scripts mit unterdrückten PHP-Meldungen

99% aller VMS laufen mit error_reporting off weil das VMS lauter Notices und Warnings spuckt. ( undefinierte Variablen und ähnliches )
Achja und da wäre noch PHP 5.3
die Deprecated-Warnungen sollten schnell zu beheben sein.

evtl könnte man da demnächst ein Update rausbringen, dann wären auch die Addon-Ersteller gezwungen "sauber" zu proggen.

Evtl könnte ich Euch nächste woche ein Bugfix zukommen nlassen

Sehe ich genauso, da ich das VMS aber nicht nutze und es auch nicht meine Arbeit ist, bzw. es kostenlos ist, habe ich nichts,- oder kaum etwas gesagt :-)
Schlimm ist nur, das ein fehlerhafter Code von den meisten noch fehlerhafter und mit nicht definierten Tags weitergegeben wird und sich so der ohnehin schon alte (und defekte) Code von User zu User verschlimmert, bis der letzte dann gehackt wird und hier hin kommt und laut schreit "Das VMS wäre so unsicher, das es jeder hacken könne".
Das ist zwar noch nicht passiert (so viel ich weiss), aber eigentlich nur noch eine Frage der Zeit

jpwfour

12.08.2011, 20:22

...

evtl könnte man da demnächst ein Update rausbringen, dann wären auch die Addon-Ersteller gezwungen "sauber" zu proggen.
...

Das seh ich noch nicht, wodurch wären dann Addon-Ersteller gezwungen, sauberen Code zu schreiben?

Ein Fix hätte evtl. vor 2 Jahren noch Sinn gemacht, denn: "Updaten" wird wohl kaum jemand, da die meisten Addons etc. alle direkt in die Dateien eingebaut werden. Daher kann man nicht mal eben so auf eine neuere Version umstellen.

Und da es mit den Klammlosen ja scheinbar bergab geht, werden die "Neu-VMS-Webbis" tendenziell auch eher weniger. Aber wenn du dir die Arbeit machen willst, warum nicht :wink:

general2811

12.08.2011, 21:26

allso ich würd mir das update gerne anschauen!

DJschatz27

13.08.2011, 00:19

Wäre auch interessiert an dem Update um zu schauen was man besser machen kann

DasGuru

13.08.2011, 20:47

Das seh ich noch nicht, wodurch wären dann Addon-Ersteller gezwungen, sauberen Code zu schreiben?

Ein Fix hätte evtl. vor 2 Jahren noch Sinn gemacht, denn: "Updaten" wird wohl kaum jemand, da die meisten Addons etc. alle direkt in die Dateien eingebaut werden. Daher kann man nicht mal eben so auf eine neuere Version umstellen.

Und da es mit den Klammlosen ja scheinbar bergab geht, werden die "Neu-VMS-Webbis" tendenziell auch eher weniger. Aber wenn du dir die Arbeit machen willst, warum nicht :wink:

ganz einfach. wenn User das error-reporting anhaben können (was sie sollten) sind Modulersteller "gezwungen" ebenso sauberen Code zu proggen, da sonst ihre Addons fehlermeldungen spucken.

$var['foo'] anstelle von $var[foo]
'foo' ist ein string und gehört eben so markiert.
foo würde eine Konstante definieren, gibt es diese nicht, entstehen Fehlermeldungen

Außerdem gehörten Variablen definiert

Das VSS ist leider auch nicht besser.
Beide stammen eben noch aus PHP4 (aktuell ist PHP5.3)

ich werde mich nächste Woche hinsetzen und eine Anleitung bauen bzw ein Bugfix zusammenpacken mit dem es möglich sein sollte, auch bei bestehenden Addons, das System auf vordermann zu bringen. Ob ich dafür Lose verlangen werde, ist noch nicht beschlossen. Immerhin sollten die Entwickler mitunter tätig werden, damit wenigstens neue Installationen "sauber" sind

Desweiteren sollte geprüft werden, welchen Output handler der Server unterstützt

ob_handler verträgt sich nicht mit zlib_handler

jpwfour

14.08.2011, 13:17

...
Beide stammen eben noch aus PHP4 (aktuell ist PHP5.3)
...

Hat das was damit zu tun, wie der Code geschrieben wurde?

Weitaus effektiver, als NOTICES zu fixen,w as eben auch ein Skript ganz einfach selbst erledigen kann (bspw. PHP selber, macht das ja im VMS schon jedesmal und das auch noch korrekt :wink:), wäre ein OpCode Cache (eAccelerator bspw.).

Den allerdings wieder jeder selber installieren muss.

Versteh mich jetzt nicht falsch, ich bin selber absolut dafür, dass sauberer Code geschrieben wird, man sich an Standards und Protokolle hält.

Nur kam das Thema VMS -> Warnings etc schon mehrmals auf, leider ist es halt nur eine absolut minimale Feinheit. Wird aber häufig so "verkauft", als ob solche Informationsmeldungen des PHP Parsers "ultra-böse" wären, und das Skript ohne diese vieeel besser laufen würde. Das ist meiner Meinung nach nicht so, also das Skript wird durch das Beseitigen dieser Meldungen weder merklich schneller noch "besser" im Sinne von Funktionalität, nur der Code wird "sauber" dadurch.

Lokutos

14.08.2011, 18:15

also das Fehlermeldungen im VMS unterdrückt werden ist vom grunde her eher Positive.

einfach ausgegebene Fehlermeldungen können zu einem sicherheitsrisiko werden.
viel sinvoller ist es da die ganzen fehlermeldungen ev. in einer Textdatei/Datenbank zu loggen und dem Admin im Adminforce aufzulisten.

breaker

18.08.2011, 01:14

ganz einfach. wenn User das error-reporting anhaben können (was sie sollten) sind Modulersteller "gezwungen" ebenso sauberen Code zu proggen, da sonst ihre Addons fehlermeldungen spucken.

Solange es hier "Entwickler" gibt, die statt "<?php" ein "<=" oder ähnlichen Unfug treiben und sowas auch noch kräftig unter die Leute bringen, wird es immer Meldungen im Code geben, die meisten wissen ja nicht mal, was sie mnit einer "3.Hand"-.Anleitung alles anstellen können und haben absolut keinen Durchblick, was sie da verzapfen ;)

also das Fehlermeldungen im VMS unterdrückt werden ist vom grunde her eher Positive.

einfach ausgegebene Fehlermeldungen können zu einem sicherheitsrisiko werden.
viel sinvoller ist es da die ganzen fehlermeldungen ev. in einer Textdatei/Datenbank zu loggen und dem Admin im Adminforce aufzulisten.

Falsch!
Wenn eine solche Meldung im Script auftaucht, wird sie erkannt und hoffentlich nicht an allen erdenklichen Stellen mit einem @ beseitigt, wenn sowas allerdings Unterdrückt wird, weiss kein Mensch davon,- bis sich jemand damit auseinander setzt, eine Lücke findet und diese Ausnutzt, schon haben wir hunderte gehackte Scripte und keiner weiss so recht, wie es gekommen ist

Notice-Meldungen werden auch dann auftauchen, wenn eine Variable nicht deklariert wurde, so kann ein solcher Code:

$db =& db::init();
$db->query("DELETE FROM " . $db->prefix . "_tabelle WHERE date <> " . $date);

mal "etwas" mehr löschen, weil $date nicht deklariert wurde, ich hoffe, du erkennst den Sinn meines Beitrags ;)

Für mich steht deshalb sauberer Code genauso an 1. Stelle, wie alles andere auch (zb. Kommentare und PHP-Docs)

Lokutos

18.08.2011, 02:16

Falsch!
Wenn eine solche Meldung im Script auftaucht, wird sie erkannt und hoffentlich nicht an allen erdenklichen Stellen mit einem @ beseitigt, wenn sowas allerdings Unterdrückt wird, weiss kein Mensch davon,- bis sich jemand damit auseinander setzt, eine Lücke findet und diese Ausnutzt, schon haben wir hunderte gehackte Scripte und keiner weiss so recht, wie es gekommen ist

Hm sehe ich nicht ganz so
ich habe ja nicht gesagt Unterdrücken
nur was ich für falsch halte ist sie genau da auszugeben wo der Fehler passiert. Je nach Konfiguration des Servers z.b. können so Einstellungen etc. mit ausgegeben werden was dann zu Sicherheitslücken / Angriffsflächen führen kann.
das man sie nicht einfach unterdrücken sollte ist klar aber einfach auszugeben ist genauso schlecht.
der ja mein Satz das man sie loggen sollte und im Adminforce anzeigen.
(da sieht sie dan nur der Admin und der wird schon meckern wen da jede sekunde 1000 neue meldungen zukommen.)

breaker

18.08.2011, 09:32

Hm sehe ich nicht ganz so
ich habe ja nicht gesagt Unterdrücken
nur was ich für falsch halte ist sie genau da auszugeben wo der Fehler passiert. Je nach Konfiguration des Servers z.b. können so Einstellungen etc. mit ausgegeben werden was dann zu Sicherheitslücken / Angriffsflächen führen kann.
das man sie nicht einfach unterdrücken sollte ist klar aber einfach auszugeben ist genauso schlecht.
der ja mein Satz das man sie loggen sollte und im Adminforce anzeigen.
(da sieht sie dan nur der Admin und der wird schon meckern wen da jede sekunde 1000 neue meldungen zukommen.)

Natürlich solle das ganze über Adminrechte geschaltet werden, so das der Admin auf Wunsch ein Debug-Modus hat (wie in meinem Script) ;)
Normale User oder Gäste sehen von den Meldungen natürlich nichts, bei einem SQL-Error geht das auch über ein gescheiten SQL-Layer, welcher solche Meldungen abfängt

DasGuru

19.08.2011, 22:28

(bspw. PHP selber, macht das ja im VMS schon jedesmal und das auch noch korrekt :wink:), nur solange keine Konstante mit diesem Namen definiert wurde.
Und durch irgendwelche Addons kann das ganz schnell passieren.

Sicherlich wäre ein anständiges ErrorManagement vorzuziehen ( mein LCS kann das schon :P )

DasGuru

20.08.2011, 11:36

so, das Bugfix ist fertig
Wer möchte kann sich bei mir per PN melden.
Ich denke 50 mio Lose sind angemessen.

Damit sollte das Script auch auf neueren PHP Versionen, ohne Fehler und Warnungen, laufen.

Sam2004

20.08.2011, 12:30

Was wurde denn wo geändert?

Für Betreiber die das vllt updaten wollen, und nicht alles überschreiben wollen, wäre das sicherlich interessant zu wissen ;)

Vllt kannst da kurz noch was schreiben :yes::thumb:

Danke

LG

DasGuru

20.08.2011, 12:38

steht alles in der Anleitung meines BugFix...

wie gesagt, ich bin eigentlich FÜR open source und FreeScripts
Bin deshalb nicht umsonst Admin eines deutschen CMS-Scripts ;)

Aber ich sehe nicht ein, dass die Entwickler nichts-tun und die Arbeit an uns hängen bleibt, weshalb ich die 50 mio verlangen möchte...

ich packe einmal ein komplettes Script und einmal eine Anleitung für bestehende Installationen mit rein.

Desweiteren sind weitere Bugfixes gratis (ich trage den Erwerb in meinen Shop ein, durch erneutes zusenden kann man sich dann den neusten Fix herunterladen)

Sollten also weitere Bugs bekannt werden, werde ich diese Fixen und in meinem Shop aktualisieren.

Das Fix behebt folgendes:

- prüfen ob php-short-Tags erlaubt sind (falls nicht wird per ini_set() versucht dies zu beheben)
- definieren von undefinierten Variablen
- php 5.3 -> deprecated-Warnungen

Hier ist der Fix (http://shop.lose-guru.de/?site=details&id=34)

Sam2004

20.08.2011, 12:47

Umsonst ist der Tod, und wenn das Bugfix ein wenig umfangreich ist, find ich die 50 Mio mehr als angemessen.

Danke für die Infos.

Wo befindet sich denn dein Shop?

LG

DasGuru

20.08.2011, 12:54

der aktuelle Fix bezieht sich auf ein frisches System.

Ein System im Betrieb kann durch Anpassungen und eingegebene Daten weitere Fehler/Warnungen ausspucken, welche ich zur Zeit nicht nachvollziehen konnte.
Dafür sind die Updates dann gratis.

http://lose-guru.de/shop/images/artikelbanner/artikelbanner.php?id=34 (http://Lose-Guru.de/shop/?site=details&id=34)

um keine Probleme mit Designerscripte zu erhalten, wurde vermerkt, dass die Lizenz durch einen Download auf Designerscripte.net erworben werden muss ( im Falle einer Neuinstallation )

*edit*
ich habe den Preis mal gesenkt

jpwfour

20.08.2011, 13:32

- prüfen ob php-short-Tags erlaubt sind (falls nicht wird per ini_set() versucht dies zu beheben)

Und wenn das auch nicht geht?
Siehe auch: Seite zeigt nur Fehler an (http://www.designerscripte.net/showthread.php?t=14206)

Xenon

20.08.2011, 13:56

ich packe einmal ein komplettes Script und einmal eine Anleitung für bestehende Installationen mit rein.

Meinst du das vms als komplettes script, wenn ja -> verboten

DasGuru

20.08.2011, 15:20

falls ini_set() deaktiviert ist ?
Nunja man kann sicherlich nicht jede Möglichkeit ausräumen.
alle <? durch <?php ersetzen ist auch für diesen Preis nicht drin.
Somit sind jedoch 2 von 3 Fällen abgedeckt.

<? ist und bleibt ein epic fail bei öffentlichen Scripts
Ich könnte Euch anbieten, eine Meldung auszugeben, falls dies der Fall ist

*edit*
es wird nun gepprüft ob short open tags an sind und ini_set erlaubt ist, nur dann wird der Fix auch hier greifen, oder eine Meldung ausgeben

DasGuru

20.08.2011, 15:22

Meinst du das vms als komplettes script, wenn ja -> verboten

Es wurde in der Anleitugn angegeben, dass ein Download des originalScripts von Designerscripte.net nötigt ist um eine gültige Lizenz zu betreiben.
sofern dies nicht ausreicht, änder ich das natürlich umgehend.

Lokutos

21.08.2011, 08:23

Es wurde in der Anleitugn angegeben, dass ein Download des originalScripts von Designerscripte.net nötigt ist um eine gültige Lizenz zu betreiben.
sofern dies nicht ausreicht, änder ich das natürlich umgehend.

Reicht grundsätzlich nicht aus.
Setz dich dazu besser erst mal mit gremlin in verbindung

DasGuru

21.08.2011, 08:25

Habe das ganze über die Melde-Funktion im Forum angefragt, bisher jedoch keine Antwort.
Nunja, ich entferne das gesamt-Paket und belasse es bis zur Klärung bei der Step-by-Step Anleitung.

*edit*
laut der vms 1.2 lizenz darf ich das Script auch komplett mit reinpacken, da ich nicht das VMS verkaufe, sondern den Bugfix, welcher auf Basis des vms 1.2 läuft.
Eine offizielle Antwort blieb bisher jedoch aus

140236

22.11.2011, 19:28

Mal eine Frage wie Aktiviere ich den den Befehl

ini_set()

oder gibt es dafür auch eine Zeile die ich dann nur irgendwo in der PHP-Datei setzen muss?

Oder muss ich den Befehl über meinen Server ausführen ,wenn ja welchen genau?

Danke schon mal für eine Antwort
Vielleicht kann mir da ja einer bei Helfen :)

Gruß

EDIT:
Also ich hatte schon einiges gefunden bei PHP selber nur war ich mir nicht sicher ob das so ok ist wenn ich da einfach was in die "functions.lib.php" pflanze.
Von daher wollte ich einfach mal vorher nachfragen.

140236

23.11.2011, 11:02

ParkingClinic

23.11.2011, 11:36

Frag mal deinen Webhosting-Provider oder zuständigen Systemadministrator, der sollte wissen wie PHP bei dir ausgeführt wird und ob du den von dir gewünschten Befehl über ini_set überhaupt verändern darfst/kannst. Unter Umständen muss dieses via php.ini für deinen vHost geändert werden.

140236

23.11.2011, 11:53