Nur so als Frage am Rande: Warum den PHP Interpreter zusätzliche Arbeitszyklen (php an|aus|an|aus|an|aus) aufpressen, wenn gar kein pures HTML im Spiel ist ?
Wie wär's mit:
Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenNur so als Frage am Rande: Warum den PHP Interpreter zusätzliche Arbeitszyklen (php an|aus|an|aus|an|aus) aufpressen, wenn gar kein pures HTML im Spiel ist ?
Wie wär's mit:
Das verursacht eines deiner Plugins und nicht WordPress oder ein Theme, denn es ist ja auch in deiner Anmeldung drin und da wird keine Theme benutzt.
Als 2. Möglichkeit kommt noch im Betracht, das du versehentlich selbst w ein am Anfang oder Ende deine wp-config.php eingetippt hast. Das wird ebenfalls ausgegeben.
Deaktiviere mal alle Plugins und schau dir die config an.
Das ist ein Problem des SAFEMODE, wie schon ausgeben wurde.
Der Server lässt PHP nur im Safemode laufen, daher können PHP Files nur auf PHP Files zugreifen mit include oder dergleichen, wenn das zu includende File dem gleichen USER gehört (Owner) wie das aktuell laufende und nachfragende.
Es sieht danach aus, das einige Files dem User owned by uid [COLOR=Blue]1976[/COLOR] gehören, die wp_config.php aber dem User uid is [COLOR=Blue]1411[/COLOR] .
Somit kann die wp-config.php , die dann die wp-settings.php lädt, die ihrerseits wiederum irgendwann die wp-includes/compat.php laden will, diese nicht laden darf aus Sicherheitsgründen, die nur im SAFEMODE gelten.
Stelle sicher, dass alle PHP Dateien einem User gehören oder frag den Provider, ob es auch ohne SAFEMODE geht (er den abschalten kann).
Siehe auch "Was ist Safe Mode Artikel" im Joomla Tutorial -> [url=http://www.joomla-tutorials.de/index.php/topic,18.0.html]Was ist Safe Mode bzw. Open Basedir[/url]
Ist hier schon mal beantwortet worden. http://forum.wordpress-deutschland.org/konfiguration/…html#post169756
Der Feed enthält Daten bzw. eine Anordnung, die von WordPress nicht interpretiert werden (können).
Und übrigens: Es gibt Feed Anbieter, die Feedabfragen "totlegen" wenn pro Zeiteinheit zu viele Abrufe von einer IP Adresse kommen. Bei serverseitigen Feedimports ist das u.U. auch ein Problem.
Leider bringt die Oberfläche die Option nicht einstellbar mit, obwohl man das sehr wohl konfigurieren kann oder könnte.
WordPress liest die Sprache während der Feed Erstellung in 2 Dateien jeweils aus der Datenbank:
Du kannst in deiner Datenbank in der Tabelle wp_options (falls du ein anderes Tabellen Präfix hast [COLOR=Red]präfix_[/COLOR]options) den Wert des Eintrags, wo der [COLOR=Blue]option_name[/COLOR] gleich "rss_language" ist, von "en" auf "de" ändern.
Dann werden die Feeds mit de deklariert.
Entweder in die style.css deines Themes oder in die css Datei, die von der Gallery benutzt wird.
Hallo, habe das selbe Problem und wir sind echt am verzweifeln
Wieder Kategorie Javascript Probleme, ähnlich wie hier: http://forum.wordpress-deutschland.org/konfiguration/…html#post169755
Bei SprungFreun.de wird jQuery von 2 verschiedenen Plugins in 2 Versionen geladen:
<script type='text/javascript' src='http://www.sprungfreun.de/wp-content/plugins/nextgen-gallery/admin/js/jquery.js?ver=1.2.2'>
<script language="JavaScript" type="text/javascript" src="http://www.sprungfreun.de/wp-content/plugins/wp-shopping-cart/js/jquery.js">
Somit muß es Probleme mit Bildern geben.
Stelle sicher, das beide Plugins mit der gleichen Datei Version laufen können und lass nur eines der Plugins das Script laden.
[COLOR=Red]@alle mitlesenden Pluginschreiber:[/COLOR] Wann endlich wird es unterlassen, irgendwelche veralteten Javascript Bibliotheks Versionen mit den Plugins auszuliefern ?
WP bringt pro Version jeweils jQuery und/oder Prototype kompatibel zueinander mit, es ist nicht nötig, inkompatible Bibliotheken in Plugins zu legen, man kann immer sehr wohl "out of the box" Scripte von WP benutzen !
Probleme machen z.B. Spiegel Netzwelten und Hartware.net[url=http://www.spiegel.de/schlagzeilen/rss/0,5291,23,00.xml]SPIEGEL ONLINE - Netzwelt[/url]
Hartware.net News
Hab die beide auch mal noch angesehen:
Weiß wer eine Lösung?
Nicht unbedingt aber einen Ansatz, wonach man suchen kann.
Zitat
Byte-Order Mark found in UTF-8 File. The Unicode Byte-Order Mark (BOM) in UTF-8 encoded files is known to cause problems for some text editors and older browsers. You may want to consider avoiding its use until it is better supported.
Das sagt der Validator als Erstes zu deiner Seite. Dein Server liefert UTF-8 aus und mindestens eine Datei (vermutlich Theme Header) ist UTF-8 mit BOM gespeichert. Das solltest du abstellen.
Der Feed (U2Tour), den du einlesen lassen willst, validiert wie folgt:
Zitat
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
Your feed appears to be encoded as "ISO-8859-1", but your server is reporting "US-ASCII" .
Das Feed Widget kommt vermutlich mit den widersprüchlichen Angaben des Feeds (US-ASCII ist nicht ISO-8859-1 encoding !) einerseits und der Transformation in dein Zielencoding UTF-8 andererseits nicht zurecht.
Da solltest du den Betreiber des Feeds fragen, ob der UTF-8 direkt anbietet oder selbst nicht ganz trivialen Korrekturcode im Feed-Widget einbauen.
Für die anderen o.g. Fälle kann es auch genau andersrum sein, Blog läuft in ISO und Feed kommt UTF-8.
Hast du evtl. seit einigen Tagen ein neues Plugin installiert wie z.B. LightBox der ähnliches, das selbst javascript Dateien mitbringt ?
Es gibt immer wieder Probleme mit Plugins, die "veraltete" Versionen von Javascript Bibliotheken mitbringen, die dann mit denen kollidieren, die WP selbst mitbringt.
Bestes Bespiel ist nun mal Lightbox, denn das hat prototype.js im Gepäck nur eben in Version 1.4 oder 1.5. WordPress selbst bringt aber 1.6 mit und der visuelle Editor beruht auf prototype.js Version 1.6.
Da das Lightbox Plugin (in mehreren Versionen) auch nicht davor zurückschreckt, im Admin Interface die "alte" Bibliothek mit laden zu lassen, kann das den visuellen Editor schwer beschädigen in seiner Funktion.
Es muß auch nicht Lightbox sein, es kann ein beliebiges, neu installiertes Plugin sein, das eine "veraltete" JavaScript Bibliothek prototype.js benutzt.
Alternativ gibt es das Problem auch mit jQuery.js, da hat auch WP eine neuere Version an Board und Plugins versuchen, eine alte mitgebrachte Version zusätzlich zu laden.
Check mal deine Plugins als Erstes.
Wenn du mehr horizontalen Platz hast also 980px, dann kannst du in der
/wp-admin/css/global.css
folgendes ändern:
.wrap, .updated, .error {
margin: 0;
margin-left: 15px;
margin-right: 15px;
padding: 0;
[COLOR=Red][B]max-width: 980px;[/B][/COLOR]
}
Nimm die rote Zeile raus, dann steht die volle Breite zur Verfügung.
Ansonsten noch nach einem Update von Advanced Plugin sehen (auf der Autorpage).
Nach Response Header ist der Server ein Apache/2.2 mit PHP/5.2.6.
Ist die WordPress Version schon auf 2.5.1 geupdated ?
Kannst du raus finden, ob das ein 64Bit System ist und wenn ja welches ?
Zeile 85 ist in WP2.5.1 nur Kommentar und kein Code enthalten.
Ich denke mal diese Funktion schlägt fehl (Zeile 85+3)
function readintarray($count) {
if ($this->BYTEORDER == 0) {
// low endian
return unpack('V'.$count, $this->STREAM->read(4 * $count));
} else {
// big endian
return unpack('N'.$count, $this->STREAM->read(4 * $count));
}
}
Wenn der Server z.B. eine Itanium Büchse ist, dann wäre big endian angesagt, aber der Fehler sagt ja, dass es bei
ZitatWarning: unpack() [function.unpack]: [COLOR=Blue]Type V[/COLOR]
knallt.
Ich denke mal, dass es am Server liegt und WordPress mit der falschen BYTEORDER initialisiert wurde, weil der Server nicht richtig erkannt wurde.
Sowas müsste man auf genau diesem Server mal testen und könnte dann einen BugTrack Eintrag machen. Aber ohne so einen Server kann ich das nur vermuten und empirisch beurteilen.
Also die Ladezeit-Timings der Startseite sind ja interessant (Durchschnitt):
Total: ........................................................ 20.9 s
[COLOR=Red]nggallery.css ........................................................ 0.59 s[/COLOR]
effects.js ....................................................... 0.23 s
calendar.css ....................................................... 0.25 s
[COLOR=Blue]prototype.js ........................................................ 0.38 s[/COLOR]
[COLOR=Red] index.php?ak_action=wp_grins_js ............................... 0.97 s[/COLOR]
style.css ........................................................ 0.28 s
[COLOR=Red]5x flicker a'la 2370883713_25724c926b_s.jpg ............... 2.25 s (je 0.45s)[/COLOR]
[COLOR=Red]1x flicker ............................................................... 0.98 s[/COLOR]
youtube ................................................................ 0.38 s
[COLOR=Red]getScrobblerContent.php .......................................... 1.3 s[/COLOR]
gravatar image ....................................................... 0.35 s
[COLOR=Red]footerart.jpg .......................................................... 1.19 s[/COLOR]
[COLOR=Red]3 x avatar ............................................................. 1.5 s (je 0.5s)[/COLOR]
[COLOR=Red] topnews.gif ........................................................... 1.97 s
footerback.jpg ....................................................... 1.55 s[/COLOR]
[COLOR=Red]getScrobblerContent.php ........................................ 14.2 s
[/COLOR]
nur ein Auszug aller geladenen Sachen, bei 8000 - 16000kbit geladen !
Und da machst du dir Sorgen um [COLOR=Blue]prototype.js[/COLOR] wenn der Rest der Seite nicht aus dem Knick kommt ?
... IE hat ja keine vernünftigen Entwicklerwerkzeuge...
So ganz richtig ist das nicht. Es gibt zumindest für den IE 7 die Internet Explorer Developer Toolbar, die ansatzweise das beherrscht, was FireBug für Mozilla kann (kein Debugger, aber immerhin Inspektion und Online Style Patching).
Ist zumindest besser, als gar nix.
Die Beschreibung mit vergleichbarem Screenshot gabs schon mal hier: http://forum.wordpress-deutschland.org/allgemeines/34…html#post166035
Schon damals war mir nicht gelungen, das zu reproduzieren.
Allerdings hab ich nun noch eine Idee:
Wenn du also von WP 2.3 auf WP 2.5 rauf bist, einen hohe Bildschirmauflösung >= 1280px Breite vorher benutzt hast, dann kann es sein, das der Cookie des Editors die Breite der alten Version noch gespeichert hat. Da die Editorbox aber auf 980px Breite limitiert wurde bei WP2.5 kann es so zu dem Problem evtl. kommen. (Hab selbst 1600px Platz, welche Verschwendung).
Test: Lösch mal alle die Cookies, die zu deiner Domain gehören.
...Wenn jemand in den Whois-Ergebnissen suchen kann, wird er wohl auch ein grafisches Impressum sehen.
Ist leider falsch. Probier dieses Whois: Who.is: Universal Whois Lookup
Ist als Suchbegriff "whois" bei google.de als 2ter Anzeigeneintrag (ganz oben) gelistet.
Da kommt ein textuales Whois Ergebnis raus, leicht zu parsen, und aus die Maus ....
... und nun ?
Einer ist noch....;)
Hmm, wie bereits oben gesagt, bleibt dieser auch. HTML4 erlaubt das, die CForms2 Standard berücksichtigen es bereits aber eben XHTML nicht. Obwohl auch Banken (Online Banking) oder Versicherungen das bräuchten und einsetzen.
Ich könnte das mit Javascript machen oder ganz weglassen und dann validert es, aber warum bloß, wenn der Rest ok ist ?
PS: ... über die 79 XHTML Fehler in deine Tuning Seite hab ich mal schlicht hinweg gesehen ... :)
Weil über das whois lässt sich ja nur den Vertragspartner mit dem Hoster ausfindig machen - so wie ich das zumindest kenne.
Na dann viele Grüsse nach Bremen und wenn du willst, schick ich dir den Whois Auszug auf deinen web.de Account. :mrgreen:
Spass Beiseite, aber es stehen nun mal alle Daten im Whois für deutsche Provider drin.
Grüsse