Wie wäre es mit diesem Plugin hier: http://wordpress.org/extend/plugins/wp-mail-smtp/
Ist zwar nur bis WP 2.7 angegeben, müsste man also testen, ob 2.8 damit auch zurecht kommt. Allerdings "biegt" das die WordPress Funktion, die Mails senden kann per mail() um auf SMTP Mail Versand.
Beiträge von codestyling
-
-
-
In der Zwischenzeit gibt es jetzt eine Beta 2 zu Download, die auch 64bit Server korrekt behandeln sollte (deutsch statt englisch).
PHP 4 Verträglichkeit wurde von schnurpsel bereits getestet und arbeite auch wieder.
Link: http://www.code-styling.de/deutsch/wordpr…auch-minimierenEbenfalls sehr lesenswert ist die vorläufige Analyse, die ich anhand der Rückmeldungen erstellt hab. Nicht nur WordPress selbst verschwendet Speicher, ein Blick in die PHP Bugliste spricht Bände!
Link: http://www.code-styling.de/deutsch/wordpr…-erste-analysen -
Danke, das ist egal wo, nur irgendwie muß es ja mal voran gehen, deswegen sammel ich.
Welche PHP Version ist da am Laufen 5.2.9 ?
...und leere Pluralformen sind nie gut, danke für den Hinweis :) -
Mein Beitrag samt Betatest-Download ist jetzt freigeschalten und hier zu finden http://www.code-styling.de/deutsch/wordpr…auch-minimieren
-
Wie kann ich das Problem lösen, um die Regelungen von Wordpress zu umgehen. Hab Google und hier auch die SuFu benutzt aber nichts gefunden, dass funktioniert :(Du must schon sagen, daß das die letzte Regel ist und der Rest nicht mehr ausgeführt werden soll:
Apache Configuration
Alles anzeigen<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_URI} !^video/(.*).html$ [NC] RewriteRule ^video/(.*)\.html$ /?page_id=1&videotitel=$1 [COLOR=Red][B][L][/B][/COLOR] </IfModule> # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> -
-
-
Zitat
Ich habe vor einiger Zeit Thomas Urban von http://www.toxa.de kontaktiert, weil er einen Performance Patch für das Lesen der Sprachdatei in den WP Trac eingebracht hat.
WP Core Member haben dafür kein Interesse gehabt, aber ich hab mir das angesehen. Nach mehreren Tests und mit meinen Hinweisen haben wir eine neue Version der Datei geschrieben, die Sprachdateien einliest. Diese bringt mein Windows System von 4 MB Verbrauch für die de_DE.mo auf 2 MB runter und ist deutlich flotter.
Diese ist eine Modifikation in Beta Status jedoch schon genügend oft getestet. Wer diese ebenfalls (ohne Gewähr) testen möchte, kann sich bei mir melden. Ich betone nochmal den Betastand, damit keine Mißverständnisse auftauchen.(auch im Blog Artikel kommentiert, ein öffentlicher Betatest sozusagen, wer will)
-
Lass mich raten, du benutzt Anti-Spam-Bee von Sergej ?
Diese erzeugt eine 2. versteckte Eingabe, die vermutlich dein Plugin nun zeigt und mit dem Tiny aufwertet. -
Das ist XHTML 2.0 ARIA Role Module W3C: http://www.w3.org/TR/xhtml-role/
Das kennt der Validator (noch) nicht, alles was mit ARIA zu tun hat, wird angemeckert. -
Kannst du mal xdebug deaktivieren und alle debuggin Sachen ?
Ich glaube, der "merkt" sich zu viel Stacktrace, da die neuen mopo Klassen, die Nikolays geschrieben hat, 3300 Instanzen einer Klasse anlegt und die füllt (sehr komische Programmierung, ist in WP < 2.8 ganz anders). -
Das ist ja 8MB Unterschied. In meinem Windows System unter PHP 5.3 braucht die Sprachdatei die bekannten ~4MB. Dann müssten deine Plugins also die restlichen 4MB aufbringen ?
Und Hinweis für PHP 5.3: hab ich getestet. WP 2.8.x läuft drauf, alle WP Versionen darunter jedoch in keinem Fall! Da kommst du aus Warnings und Errors gar nicht mehr raus.
-
Das Problem liegt auch teilweise beim Verständnis des Providers. Wenn man 64Bit läuft und die Speicherverwaltung des System nun mit doppelt so großen Adressen, Zahlen und Strukturen hantiert, dann sollte man auch so schlau sein und das PHP Limit entsprechend anzupassen, wenn PHP ebenfalls 64Bit ist.
Aber das ist bei einigen Providern noch im Lernprozess begriffen. -
Ein Text (String) verdoppelt sich natürlich nicht, der Inhalt ist auch bei 64bit genau gleich lang. Aber die Verwaltung, wo genau der im Speicher liegt (Pointer) war 4 Byte und ist nun 8 Byte. Auch ist unter 64Bit die Speicherverwaltung sehr viel großzügiger mit Anforderungen von Speicherblöcken (Granularität) die von 4kB Seiten schon mal auf 8kB oder 64kB Seiten gestellt sein kann. Stell dir vor, du willst was mit der Größe von 30 Byte in den Speicher legen, dann landet das bei 32bit in einem 4kB Block unter 64Bit aber u.U. in einem 64kB Block. Auch wenn dann nix mehr in dem Speicher soll, hast du den gerade verbraucht. Dieser Overhead ist dann das eigentliche Problem, aber eben auch OS abhängig.
Somit wird das nie genau x2 sein aber deutlich in die Richtung gehen.Genug techy Zeugs jetzt ... :mrgreen:
-
Vorsicht, jetzt wird es techisch.
Da sich laut den oben genannten Aussagen der Speicherverbrauch quasi verdoppelt hat, mal die ketzerische Frage, ob der alte Server 32Bit und der neue Server 64bit ist ?
Aus meiner täglichen Erfahrung im Bereich C++ im Enterprise Entwicklungbereich kann ich sagen, das der Speicherverbrauch für ein und dasselbe Programm nur einmal 32bit und einmal 64bit compiled nahezu mit Faktor 2 zu Laufzeit eingeht, wenn man nicht nur Strings "hortet".
PHP intern ist in C geschrieben und unterliegt somit ebenfalls einem Größenzuwachs beim Schritt von 32 zu 64 bit für Datentypen wie Zahlen, Strukturen, Arrays oder Pointer. Und davon gibts haufenweise intern bei der Ausführung eines (oder mehrerer) PHP Scripte.Dies würde sehr passend die Verdopplung erklären. Kannst du dies bestätigen, das du von 32 auf 64 bit Platform umziehst ?
-
Zu dem Problem von Tine68 hatte ich bereits hier Setllung genommen, das muß angepasst werden!
Thema: http://forum.wordpress-deutschland.org/sprachdatei/55…html#post262289Das zweite Problem ein Message Context Problem seitens des Codes, wenn man das so scannen lässt. Das können wir zwar beheben, aber ein re-scan aller PHP Dateien von WP produziert das wieder.
Ich werde Robert nochmal informieren, sollte kurzfristig lösbar sein.
-
Ich verstehe es auch nicht, so viel hat mein Blog noch nie verbraucht! Ohne deutsche Sprachdatei läuft es derzeit (laut memory overview) mit 17,25 MB Usage.
Sobald ich die de_DE in die config.php einfüge, geht es immer bis an Speicherlimit - mit besagter Fehlermeldung. Komischerweise stieß ich schon bei 44 MB um ein paar KB an die Grenzen, und jetzt sogar bei 50 MB???
Mit Wp2.8.1 lief es übrigens noch einwandfrei... *grübel*
Wie genau hast du die deutsche Sprachdatei da hinbekommen ?Erst kürzlich hatten wir hier das Problem, das jemand Bilder per FTP (PNG's) hochgeladen hatte, die das FTP Programm fälschlicherweise als Text! erkannt hat und Korrekturen an Zeilenumbrüchen gemacht hat.
Wenn sowas mit der de_DE.mo Datei beim Upload passiert (Datei danach beschädigt!), dann lädt die endlos den Speicher zu bis der Provider Stop sagt.
Kannst du die Sprachdatei von WP nochmal per FTP im Transfer Modus Binär hochladen ?
(Es könnte aber auch die Sprachdateien von Plugins erwischt haben).Weitere mögliche Gründe sind Fehleinstellungen beim Provider. Bespielsweise ist eine PHP Einstellung zend.ze1_compatibility_mode = On für ein benutztes PHP >= 5.0 tödlich und crashed je nach Provider umgehend das Dashboard.
Auch ist eine andere Einstellung als mbstring.func_overload = 0 sehr bedenklich und hat u.U. den gleichen Effekt auf die Sprachdateien für WP Versionen 2.8.0 / 2.8.1 wie oben beschrieben.
-
Wo wird was falsch angezeigt ?
Eine Aussage im Stile "Es ist ein Fehler aufgetreten!" kann man leider gar nicht behandeln, da fehlt einfach Info. -
Ausgehend von WP 2.7.x Versionen ist dies:
Code
Alles anzeigen#: wp-includes/locale.php:181 msgid "number_format_decimals|$decimals argument for http://php.net/number_format, default is 0" msgstr "number_format_decimals|$decimals-Angabe für http://de.php.net/number_format, Standard ist 0" #: wp-includes/locale.php:184 msgid "number_format_decimal_point|$dec_point argument for http://php.net/number_format, default is ." msgstr "number_format_decimal_point|$dec_point-Angabe für http://de.php.net/number_format, Standard ist ." #: wp-includes/locale.php:187 msgid "number_format_thousands_sep|$thousands_sep argument for http://php.net/number_format, default is ," msgstr "number_format_thousands_sep|$thousands_sep-Angabe für http://de.php.net/number_format, Standard ist ,"nicht korrekt für dies hier:
PHP$trans = _c('number_format_decimals|$decimals argument for http://php.net/number_format, default is 0'); $this->number_format['decimals'] = ('number_format_decimals' == $trans) ? 0 : $trans; $trans = _c('number_format_decimal_point|$dec_point argument for http://php.net/number_format, default is .'); $this->number_format['decimal_point'] = ('number_format_decimal_point' == $trans) ? '.' : $trans; $trans = _c('number_format_thousands_sep|$thousands_sep argument for http://php.net/number_format, default is ,'); $this->number_format['thousands_sep'] = ('number_format_thousands_sep' == $trans) ? ',' : $trans;In Version ab 2.8.0 sieht das so aus:
PHP
Alles anzeigen/* translators: $decimals argument for http://php.net/number_format, default is 0 */ $trans = __('number_format_decimals'); $this->number_format['decimals'] = ('number_format_decimals' == $trans) ? 0 : $trans; /* translators: $dec_point argument for http://php.net/number_format, default is . */ $trans = __('number_format_decimal_point'); $this->number_format['decimal_point'] = ('number_format_decimal_point' == $trans) ? '.' : $trans; /* translators: $thousands_sep argument for http://php.net/number_format, default is , */ $trans = __('number_format_thousands_sep'); $this->number_format['thousands_sep'] = ('number_format_thousands_sep' == $trans) ? ',' : $trans;Die korrekte Übersetzung wäre dann:
Code
Alles anzeigen#: wp-includes/locale.php:182 msgid "number_format_decimals" msgstr "0" #: wp-includes/locale.php:186 msgid "number_format_decimal_point" msgstr "." #: wp-includes/locale.php:190 msgid "number_format_thousands_sep" msgstr ","wobei man das auch einfach leer lassen kann, was zum Standard führt.
Allerdings ist der Dezimal Separator im Deutschen eigentlich ',' statt '.' und der Tausender-Separator '.' statt ',' wenn man sich an die Standards halten würde. Nur führt das bei Berechnungen u.U. zu Problemen denn folgender deutsch formatierter Wert ist für PHP bei Umwandlung in eine Zahl was anderes:
wird dann in PHP als Fließkomma Zahl:
denn PHP läuft in den meisten Fällen auf US locale.