[ERLEDIGT]Einzelne Domain mit nicht-funktionierendem PHP-Parser RC2

[ShadowJumper]

(10-30-2010 01:48 AM)Lucan Wrote:  Hallo ShadowJumper,

meiner Meinung nach, ist es nicht unser Recht dem Kunden vorzuschreiben, wie er seine Scripte zu schreiben hat, sofern diese nicht die Sicherheit des Servers o.ä. beeinflussen.

Was das Short Tag in meinen Augen definitiv nicht tut.

Unsere Aufgabe als ISP ist es nicht den irgendwelche Standarts durch zu boxen, nur weil sich ein paar PHP Gurus dafür entschieden haben.

Grüße

Da kann ich dir leider nicht recht geben. Es geht hier nicht darum etwas vorzuschreiben, sondern einfach "Altlasten" über Board zu werfen.

Du bist also der Meinung das es ok ist das jemand der "heute" anfängt PHP zu lernen dies damit tut indem er veraltete Techniken lernt?

Zumal es schlussendlich darum geht das in zukünftigen Versionen von PHP viele dieser "Funktionen" nicht mehr vorhanden sein werden. Somit wird es dann also keine Möglichkeit mehr geben "zurück" zu gehen.

Was wiegt dann wohl schwerer: Über Jahre hinweg Stück für Stück die als "veraltet" markierten Funktionen zu deaktivieren und den Anwender schonend zum Umstieg zu "drängen". Oder wenn "über Nacht" im schlimmsten Falle mehrere Dutzend Funktionen nicht mehr vorhanden sind (sich somit also auch nicht mehr aktivieren lassen) und die User evtl dann Wochen brauchen bis alles wieder läuft.

Ich kenne selber dutzende von Projekten die alle "heulen" wie schlimm doch PHP 5.3 sei. Dabei wurde dort nur umgesetzt was im extremsten Falle schon seit über 10 Jahren angekündigt wurde. Nämlich das endgültige entfernen von Funktionen die schon in 3.x / 4.x als deprecated bezeichnet wurden.

Das wäre so als würde man heute z.b. etwas rein in .Net 1.0 Programmieren und sich dann beschweren warum das unter .Net 4.0 nicht mehr läuft (einige Funktionen wurden da schon in 2.0 Ersatzlos gestrichen bzw. ersetzt).

[Lucan]

Quote:Du bist also der Meinung das es ok ist das jemand der "heute" anfängt PHP zu lernen dies damit tut indem er veraltete Techniken lernt?

Gut ist das bestimmt nicht, da stimme ich dir zu.

Allerdings verstehe ich da den zusammenhang zu ispCP nicht.
IspCP ist eine Platform zum bereitstellen von Websites und keine Lernsoftware für php.


Grüße

[ShadowJumper]

(10-31-2010 12:30 AM)Lucan Wrote:  Allerdings verstehe ich da den zusammenhang zu ispCP nicht.
IspCP ist eine Platform zum bereitstellen von Websites und keine Lernsoftware für php.


Grüße

Da gebe ich dir grundsätzlich erst mal recht. Aber die zugrunde liegende Plattform ist eben ein "Linux Unterbau", der bestimmte Möglichkeiten bietet oder eben auch nicht bietet bzw. in Bälde nicht mehr bieten wird/kann.

Demnächst (zumindest hoffen das die meisten) wird z.b. Debian 6.0 erscheinen welches einige "Einschränkungen" mitbringen wird. Zumindest für die Leute, die es in der Vergangenheit nicht geschafft habe z.b. ihre Scripte auf einen vernünftigen Level zu bringen. Da ispCP hauptsächlich auf Debian entwickelt wird ist der Umstieg dort also nur noch eine Formsache. Debian 4.0 wird ab der 1.0.7 nicht mehr Unterstützt. Und das liegt sicherlich nicht alleine daran das Debian selber die Version 4.0 nicht mehr mit Updates versorgt. Wie lange Debian 5.0 überleben wird ist auch keine Frage, das ist schließlich abzusehen wann dort der Support enden wird.

Soll man jetzt also den "Kopf in den Sand" stecken und so tun als würden diese Änderungen einen nicht betreffen und quasi so lange warten bis es zu spät ist?

[Lucan]

Hallo,

nein den Kopf in den Sand stecken ist bestimmt das falsche.

Meiner Meinung nach wäre es angebracht die User hier zu informieren, dass mehrere php Funktionen mit dem Umstieg auf Debian Squeeze bzw. php 5.3 nicht mehr verfügbar sind und man dies bezüglich bitte seine Kunden informiert bzw. seine Scripte anpasst.

Einfach die Funktionen zu deaktivieren ist aber meiner Meinung nach der komplett falsche weg.


Grüße

[ZooL]

hi,

sehe ich auch so, es sind einfach viele DAUS hier im forum die ispcp, als image oder selber installieren und nicht wissen, was es mitbringt oder erledigt und wenn viele hinterher
Scripte einsetzen die <?=$test;?> nutzen oder <? statt <?php ist so viel Rummel.
Und genau diese werden sich hier im Forum melden. Das ist nunmal unnötige Arbeit, die man sparen kann mit Vorabinformationen.

greetz

[RatS]

Wie in diesem Post beschrieben, handelte es sich um eine Änderung, die ich während des Releases nicht bemerkt hatte. In neuen php.ini-Dateien ist "short_open_tags" auf "off" gesetzt, weil diese funktion als "depreciated" markiert ist. Wir unterstützen es jedoch seit Anfang an und sollten es auch weiterhin tun. Wenn es sich nicht um ein Versehen gehandelt hätte, wäre es sicherlich auch angekündigt worden. Ich bitte daher auch hier noch mal um Enschuldigung dafür.
Ganz uninteressant ist die kontroverse Diskussion jedoch nicht. Vielleicht ließe sich hier ansetzen und mit einem Poll die generelle Bereitschaft zur Abschaltung von veralteten Funkionen aufzusetzen.

[ZooL]

Dies kann ich gerne in die wege leiten, ich werde die veralteten Funkionen ausfindig machen und einen Poll dafür starten.
mfg

[ShadowJumper]

(10-31-2010 05:02 AM)Lucan Wrote:  Einfach die Funktionen zu deaktivieren ist aber meiner Meinung nach der komplett falsche weg.

Naja, aber in zukünftigen Versionen von PHP wird es bei einigen Funktionen eben kein On/Off mehr geben, schlicht weil die entsprechenden Funktionen gar nicht mehr vorhanden sind. Und was nicht mehr vorhanden ist kann man dann auch nicht mehr aktivieren

Von daher sollte man sich schon die frage stellen WANN der "richtige" Zeitpunkt ist solche Sachen umzusetzen.

Oder es endet wie folgt: Bei einem Berufskollegen mussten jetzt mehrere Kunden abgemahnt werden weil diese mit "relativ" alten Servern Arbeiten und sich bisher "weigern" auf neuere Systeme umzusteigen. Im Grunde könnte man erst mal sagen das ist ja deren Problem.

Wenn dann aber deren Server gehackt werden (was mehrfach vor kam, daher die Abmahnung) und dann andere Kundensysteme bzw. dritte dadurch beeinträchtigt werden/angegriffen werden kann man darüber eben nicht mehr so einfach wegsehen. Und die Aussage "Unsere Software läuft halt auf den neuen Systemen nicht" kannst du nach der 2. oder 3. Beschwerde von Fremdkunden auch knicken.

Aktuell ist der Stand umsteigen oder die Server werden Ersatzlos abgeschaltet. Und bei anderen Anbietern werden Sie derart "veraltete" Systeme auch nicht bekommen.

Ist im Grunde wie bei der IE6 Diskussion. Solange der "beachtet" wird sehen manche Leute auch keinen Bedarf umzusteigen. Das gleiche gilt dann auch für ispCP. Solange man "krampfhaft" an altem festhält, wird sich da auch nichts ändern.

Dann führen wir die "Hilfe, meine Scripte laufen nicht mehr und ispCP 1.1.x ist 100% daran schuld (davor lief es ja)" dann eben zu einem späteren Zeitpunkt erneut.

[Lucan]

Hallo,

das ist ja genau das was ich gesagt habe -> solange keine Sicherheitsbedenken bestehen soll/kann das ganze weiter laufen.
Wenn dem nicht so ist, dann muss gehandelt werden -> aber auch erst dann.



Grüße

[ShadowJumper]

(10-31-2010 08:48 PM)Lucan Wrote:  Hallo,

das ist ja genau das was ich gesagt habe -> solange keine Sicherheitsbedenken bestehen soll/kann das ganze weiter laufen.
Wenn dem nicht so ist, dann muss gehandelt werden -> aber auch erst dann.

Grüße

Hm, die Funktion ist aber durchaus Sicherheitstechnisch relevant. Nämlich dann wenn deine Distri das ändern wurde bei einem Update/Upgrade (dann wenn On/Off ignoriert wird) und deine Scripte plötzlich im Klartext auf dem Bildschirm stehen. Je nach Inhalt könnte das "gefährlich" sein.

Und das die Funktion nicht mehr verwendet werden soll ist schon seit Jahren bekannt bzw. wie ein Script "richtig" an zu fangen hat.

Die frage ist also: WANN ist der richtige Zeitpunkt etwas das sowieso schon "verboten" ist auch endlich mal einzuführen?

Dann wenn es zu spät ist, sicherlich nicht.........