Zitat von [netcup] Felix;23729Würden wir jetzt auf einen Schlag PHP 5.3 heraus bringen, hätten wir viele unzufriedene Kunden und der Support würde zusammenbrechen.
Warum sollte dies so sein? PHP 5.3 ist wie die Versionen davor vollkommen abwärtskompatibel.
(ich glaube da hakt mir der nächste den Kopf ab ^^)
Zitat von ice-breaker;23731Warum sollte dies so sein? PHP 5.3 ist wie die Versionen davor vollkommen abwärtskompatibel.
Das stimmt so nicht. Eine menge Funktionen sind deprecated und einige andere haben andere Parameter. Ich hab schon vor einiger Zeit auf meinen Servern auf 5.3 upgedated und noch immer ist nicht die gesamte Software die ich nutze auf PHP 5.3 angepasst. Ich war z.B. wochenlang damit beschäftigt einige Komponenten für Joomla 1.5 anzupassen. Die deprecated Fehlermeldungen lassen sich zwar auslebenden, aber manche Scripte funktionieren trotzdem nicht richtig mit den alten Funktionen. Einige Programme aus dem Debian Repository haben auch nicht mehr richtig funktioniert, z.B. ldapadmin.
Das viele Funktionen geändert wurden war beabsichtigt, weil PHP 5.3 mehr eine Vorbereitung auf PHP 6 sein soll wo ja viele Altlasten abgeworfen werden sollen. So können die Programmierer schon anfangen ihre Scripte anzupassen.
Es gab glaub ich sogar einen Upgrade Guide auf php.net mit einer Übersicht über neue und geänderte Funktionen.
Zitat von ice-breaker;23731Warum sollte dies so sein? PHP 5.3 ist wie die Versionen davor vollkommen abwärtskompatibel.
(ich glaube da hakt mir der nächste den Kopf ab ^^)
Leider ist das nicht so. Ich denke das ist auch der Grund, warum PHP 5.3 noch nicht für Debian Lenny freigegeben wurde. Wir fahren mit Debian sehr gut, was die Softwareversionen an geht.
Man mag es kaum glauben, aber wir haben sogar einige Anfragen nach PHP4. Dieses bieten wir allerdings nicht mehr an, da es nicht mehr weiterentwickelt wird.
Zitat von stachi;23732Das stimmt so nicht.
gut, es war falsch ausgedrückt, 100% inkompatibel ist es nie, aber die inkompatiblen Änderungen sind wieder nur Verfeinerungen der API, eben Dinge die eigentlich nicht gehen sollten (Parameter an __toString usw)
Zitat von stachi;23732Eine menge Funktionen sind deprecated
da gebe ich dir Recht, aber diese lassen sich immernoch nutzen.
Auch ist der E_STRICT-Level per Default nicht aktiv und auch nicht in E_ALL enthalten, weshalb dies nicht auffallen wird.
Zitat von stachi;23732und einige andere haben andere Parameter.
Belege? Den soetwas wird vor PHP 6 nicht passieren. Die einzigen inkompatiblen Änderungen verbieten eher das "Misshandeln" von Funktionen und sind weitere eher unwichtige Eigenschaften.
Zitat von stachi;23732Die deprecated Fehlermeldungen lassen sich zwar auslebenden, aber manche Scripte funktionieren trotzdem nicht richtig mit den alten Funktionen. Einige Programme aus dem Debian Repository haben auch nicht mehr richtig funktioniert, z.B. ldapadmin.
laut dem Migration Guide hat sich aber an PHP 5.3 nichts getan, was diese Auswirkungen haben sollte, hast du Beispiele?
Zitat von stachi;23732Das viele Funktionen geändert wurden war beabsichtigt, weil PHP 5.3 mehr eine Vorbereitung auf PHP 6 sein soll wo ja viele Altlasten abgeworfen werden sollen. So können die Programmierer schon anfangen ihre Scripte anzupassen.
Auch wieder da hätte ich gerne Belege, denn PHP 5.3 ist keine wirkliche Vorbereitung auf PHP 6. Einzig die Deprecated-Meldungen und die Default-Abschaltung von safe_mode usw sind Vorbereitungen, die API und der ganze Rest sollte sich aber noch genauso verhalten wie vorher.
Zitat von stachi;23732Es gab glaub ich sogar einen Upgrade Guide auf php.net mit einer Übersicht über neue und geänderte Funktionen.
Migrating from PHP 5.2.x to PHP 5.3.x
und man sieht, dass die inkompatiblen Änderungen eher unbedeutend sind.
Gut, das einzige was ich als Kritik geltend machen würde, wären die neuen Keywords goto und namespace, denn die sind wirklich inkompatibel.
Trotzdem wäre es eine feine Sache wenigstens optional PHP 5.3 anzubieten, von mir aus gerne, dass man sich beim Support melden muss, damit man auf einen solchen Server umziehen kann.
ZitatTrotzdem wäre es eine feine Sache wenigstens optional PHP 5.3 anzubieten, von mir aus gerne, dass man sich beim Support melden muss, damit man auf einen solchen Server umziehen kann.
Dieses ist wie oben geschrieben möglich, allerdings nicht zum Preis eines Massenwebhostings.
Na gut, aktuelle Scripte sollten die paar geänderten Funktionen nicht stören weil nur ziemlich alte Sachen geändert wurden, aber es gibt noch Scripte die mysql_connect noch mit dem alten Passwort-Format nutzen und das geht z.B. nicht mehr.
Und ich wurde mit deprecated Meldungen in der Default Einstellung E_ALL überrannt.
Mittlerweile sind die meisten Programme auch auf PHP 5.3 angepasst, grade bei CMS und diverses Forensystemen gab es ja extra für PHP 5.3 einige Updates.
Aber im Endeffekt bleibt PHP 5.3 für mich nur ein Lückenfüller wie z.B. Windows Vista und ich finde es nicht schlimm das es nicht die Verbreitung findet. Das wird PHP 6 alles wieder weg machen.
Zitat von [netcup] Felix;23735Dieses ist wie oben geschrieben möglich, allerdings nicht zum Preis eines Massenwebhostings.
dann kann ich gleich selbst alles auf nem (v)Server installieren und managen.
Zitat von stachi;23736aber es gibt noch Scripte die mysql_connect noch mit dem alten Passwort-Format nutzen und das geht z.B. nicht mehr.
was hat sich denn da geändert? Das habe ich gar nicht mitbekommen.
Ich weiß zwar, dass sich im MySQL-Binärprotokoll das Password geändert hat, aber das ist ja schon im ganzen 5er tree drinne, oder was meinst du?
Zitat von stachi;23736Und ich wurde mit deprecated Meldungen in der Default Einstellung E_ALL überrannt.
Jup, mitlerweile ist E_DEPRECATED in E_ALL aktiv, habe es extra nochmal nachgesehen.
Zitat von stachi;23736Aber im Endeffekt bleibt PHP 5.3 für mich nur ein Lückenfüller wie z.B. Windows Vista und ich finde es nicht schlimm das es nicht die Verbreitung findet. Das wird PHP 6 alles wieder weg machen.
ich garantiere dir, dass PHP 6 die miserabelste Verbreitung ever haben wird 
inkompatible Änderungen, schlechtere Performance, du wirst auch Jahre nach Erscheinen noch dafür Betteln müssen.
K, ganz so kompatibel, wie es erst dokumentiert ist, ist es nicht, aber als optionales Feature wäre es trotzdem toll.
Zitat von ice-breaker;23725PHP 5.3 ist mittlerweile 13 Monate draussen, und noch immer bekommt man es nirgends, weil alle zu faul sind, es selbst zu kompilieren.
Ich kenne einige Hoster, die es bereits anbieten. Aber nicht als Default, sondern nur über FGCI - so kann man es über eine .htaccess schnell umschalten. Die Performance ist dann aber leider oft futsch, da dort normalerweise immer mod_php für PHP <= 5.2.x genutzt wird/wurde.
Mit PHP 5.3 hat sich außerdem trotzdem einiges geändert. Dazu zählen einige Dinge für den Kunden und seine Scripte, aber genauso wie Änderungen an der Zend API, wodurch einige Dinge angepasst werden müssen. Ich weiß ja nicht was netcup alles auf den Servern einsetzt, aber auf meinem Squeeze Testsystem (dort ist PHP 5.3 bereits enthalten) ist es ein täglicher Kampf und ich muss auf einiges verzichten. Das ist auch der Grund, warum ich PHP 5.3 auf einem Produktivsystem noch nicht einsetzen würde. Es wird einfach noch zu wenig unterstützt. Zugegeben, meine eigene Software unterstützt es auch noch nicht komplett
Zitat von ice-breaker;23739ich garantiere dir, dass PHP 6 die miserabelste Verbreitung ever haben wird
Glaube ich langsam auch, wenn man sich nur mal die Unstimmigkeiten im Team ansieht.
Aber da erscheint vorher noch eher PHP 5.5 - bis zur 6. Version dauert es noch ewig 
MfG Christian
Zitatch garantiere dir, dass PHP 6 die miserabelste Verbreitung ever haben wird inkompatible Änderungen, schlechtere Performance, du wirst auch Jahre nach Erscheinen noch dafür Betteln müssen.
Auch wenn man mich dafür töten wir - es ist nichts neues.
PHP zeichnet sich dadurch aus, dass jeder Vollidiot damit irgendwie umgehen kann.
Es gibt deutlich bessere Scriptsprachen oder allgemein bessere Möglichkeiten eine Homepage zu errichten.
Z.B. Ruby, Python, Perl, etc.
Und gibts davon eine in den Webspace angeboten?
Zitat von Michael;23818PHP zeichnet sich dadurch aus, dass jeder Vollidiot damit irgendwie umgehen kann.
Es gibt deutlich bessere Scriptsprachen oder allgemein bessere Möglichkeiten eine Homepage zu errichten.
Z.B. Ruby, Python, Perl, etc.
und was hat das mit meiner Aussage zu tun, dass sich PHP 6 bei Webhostern so gut wie nicht verbreiten wird?
Ausser einen Sprachen-Flamewar?
Safe_Mode ist so sicher, dass bei einer Installation aus dem Software-Center von Confixx bei netcup direkt nach der Installation z.B. folgende Fehler auftreten:
Warning: set_time_limit() [function.set-time-limit]: Cannot set time limit in safe mode in /var/www/webxxx/html/ATutor/mods/_standard/patcher/index_admin.php on line 21
Warning: Cannot modify header information – headers already sent by (output started at /var/www/webxxx/html/ATutor/mods/_standard/patcher/index_admin.php:21) in /var/www/webxxx/html/ATutor/include/classes/Language/Language.class.php on line 123Also wenn unbedingt Safe_Mode, dann wenigstens nur kompatible Scripte im Software-Center. Alles andere hat nicht viel Sinn...
Das Problem des Safe-Modes wurde ja nun durch die neuen Angebote und die Anpassung der bestehenden Angebote gelöst. Das obige Problem ist jedoch ein Fehler der Software und nicht zwangsweise auf die Einstellung zurückzuführen.
Bestandskunden können sich die neuen Features auf Anfrage beim Support freischalten lassen.
Gilt das eigentlich auch für Abstauber (Studentenspace) ?
Btw: Den Business 512 gibt es nicht mehr.
Ähnliche Frage wie Artimis: Gilt das auch für Sponsored Hosting? Hoffe ich doch mal
Zitat von Artimis;23914Gilt das eigentlich auch für Abstauber (Studentenspace) ?
Btw: Den Business 512 gibt es nicht mehr.
Den Business 5120 gibt es schon seit der Umstellung auf Business 10 G / Business 100 G nicht mehr
Zitat von TheReaper;23915Ähnliche Frage wie Artimis: Gilt das auch für Sponsored Hosting? Hoffe ich doch mal
Hierzu bitte, wie alle anderen Bestandskunden ebenfalls, per E-Mail an den Support wenden und dies beantragen. Inwiefern dies dann möglich ist, hängt vom jeweiligen Vertrag ab.
Also bei mir ging das innerhalb kürzester Zeit und problemlos. Einfach per CCP an den Support geschrieben und sehr schnell die Antwort bekommen, dass es freigeschaltet ist.
Weiß jemand, wie hoch das Memory Limit bei dem Sommer Spezial war? Ich dachte es wären 32 Mb gewesen. Oder war das schon immer 64 Mb?
Zumindest gut, dass man jetzt die Auswahl hat, obwohl ich sowohl den safe_mode als auch register_globals auf off gelassen habe.
Aber ich finde es super, dass NetCup hier schnell reagiert hat und den Usern auf Grund dieses Foreumthreads und vermutlich auch der Beschwerde per E-Mail die Möglichkeit gibt, frei auszuwählen.
Die Umstellung hatte für mich noch was Gutes: Ich habe schon Jahre nicht mehr in PHP programmiert und wollte vor ein paar Monaten ein kleines Script schreiben. Das ging dann aber vorne und hinten nicht, weil ich register_globals noch nicht kannte -.-
Zitat von eXeler0n;23934Weiß jemand, wie hoch das Memory Limit bei dem Sommer Spezial war?
http://www.netcup.de/bestellen/produkt.php?produkt=151 
Zitat von eXeler0n;23934Das ging dann aber vorne und hinten nicht, weil ich register_globals noch nicht kannte -.-
register_globals sollte man übrigens NICHT verwenden, da es bei schlecht geschriebenem Code (uninitialisierte Variablen usw.) ein sehr großes Sicherheitsleck darstellen kann. Man braucht es auch normalerweise nicht, da man auf alle Daten über die Superglobals Zugriff hat: http://www.php.net/manual/de/l…ariables.superglobals.php
MfG Christian
Ja, das habe ich jetzt gelernt und werde es auch auf off lassen. Das macht doch keinen Sinn, das einzuschalten. Und sollte glaub auch nicht erlaubt werden.
Danke für den Link Hat sich für mich also das Limit verdoppelt. Wenns jetzt noch für jede Domain eine Datenbank geben würde, dann wäre ich glücklich
Da hätte ich einfach mal noch ne Frage: Macht das so ein Unterschied, ob ich für fünf Seiten fünf Datenbanken benutze oder ob ich die Tabellen alle in eine (oder zwei) Datenbanken haue nur mit Präfixen und so?
Zitat von eXeler0n;23941Macht das so ein Unterschied, ob ich für fünf Seiten fünf Datenbanken benutze oder ob ich die Tabellen alle in eine (oder zwei) Datenbanken haue nur mit Präfixen und so?
Kommt auf die Größe der DB bzw. Tabellen an, das könnte schon etwas ausmachen
Ansonsten wäre bei mir die Sicherheit ein Hauptthema, da ich z.B. Script A nicht erlauben würde die Tabellen von Script B zu sehen. Und da bleibt einem beim Webspace nur die Möglichkeit von verschiedenen DB's. Aber das muss jeder für sich entscheiden.
MfG Christian
Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.
Die letzte Antwort auf dieses Thema liegt mehr als 365 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.
