Beiträge von codestyling

Zitat von borusse

1. Tab im Blog eingeloggt, 2. Tab den Blog aufrufen um ihn als Besucher anzuschauen. Im 1. Tab Änderungen vornehmen und im 2. Tab dann mit F5 aktualisieren.

Wie soll das gehen? Der Browser speichert die Anmeldungs-Cookies gemäß Domain und nicht Tab-spezifisch. Deswegen nutzt auch ein neuer Tab gar nix.
In ein und demselben Browser kann man nicht sowohl eingeloggt als auch ausgeloggt sein.
Einzige Ausnahme, die möglich ist:
1. Tab => HTTPS für den ganzen Blog (Front und Admin) mit Login.
2. Tab => HTTP zur Kontrolle.
Da Login-Cookies nur fürs Protokoll gelten und somit nur für HTTPS aufrufe, ist der Tab mit HTTP nicht eingeloggt.

Ansonsten blieben tatschlich nur 2 Browser.

Du benutzt w3totalcache (sieht man am Source Code). Aber er bekommt immer eine 200 statt 302 bzw. scheint er die Seite permanent neu zu cachen und dann zu liefern. Ich würde dort anfangen und auf Inkompatibilitäten suchen.

Hast du einen Link zur Seite, damit man sich das von Außen mal ansehen und ggf. Hinweise bereithalten kann?

Das Theme ist inkompatibel mit WP 3.5 und noch dazu sehr unsauber programmiert:

Backend - Aktivierung:

Notice: Undefined variable: ad_default_300 in D:\xampp\htdocs\development\wp-content\themes\zincious\includes\defaults.php on line 82
Notice: wp_enqueue_script wurde fehlerhaft aufgerufen. Skripte und Styles sollten nicht vor den Hooks wp_enqueue_scripts, admin_enqueue_scripts oder init registriert oder eingebunden werden. Schau Dir Debugging in WordPress an, um mehr darüber zu erfahren. (Diese Meldung wurde in Version 3.3 hinzugefügt.) in D:\xampp\htdocs\development\wp-includes\functions.php on line 2944
Notice: Undefined index: page in D:\xampp\htdocs\development\wp-content\themes\zincious\includes\administration\options-functions.php on line 167

Hauptseite (auch als Admin):

Fatal error: Call to undefined function get_mostpopular() in D:\xampp\htdocs\development\wp-content\themes\zincious\footer.php on line 28

Spätestens die Fatal error führen zum Abbruch der Seitenausgabe, eigentlich ist das Theme ein Kandidat für die "weisse Seite des Todes" und muß total überarbeitet werden. Ich würde dir raten, nicht weiter mit diesem Theme zu arbeiten oder aber eine an WP 3.5 angepasste Variante vom Autor zu verlangen.

Sieht mir ein bischen so aus, als würde ein Feed Plugin periodisch Feeds von Seiten per WP Cron Job abrufen:

87.984.501.403 - - [04/Jan/2013:08:00:54 +0100] "GET /blog/?feed=rss2&p=835&page=blog HTTP/1.0" 302 339 "-" "-"

87.984.501.403 - - [04/Jan/2013:07:58:53 +0100] "GET  /index.php?page=blog&feed=rss2&p=835&page=blog HTTP/1.0" 200  5875

87.984.501.403 - - [04/Jan/2013:07:58:54 +0100] "GET  /index.php?page=blog&feed=rss2&p=835&page=blog HTTP/1.0" 200  5875 "-" "-"

Erst werden die Pages über die Index für den Feed 2x abgerufen, exakt 2 Minuten später der Feed selbst über PermaLink.

Hast du irgend ein Plugin laufen, das was besonderes mit Feeds anstellt?
Laufen WP Cron Jobs?

Zitat von Farlif

Beim Eintrag all der Daten in die config.php fühle ich mich tatsächlich unwohl.

Versteh ich nicht. Denn erstens sind dort die Daten für den Datenbankzugriff drin und es ist zweitens die Datei, deren Code als erstes ausgeführt wird.
Wenn also jemand Zugriff auf diese Datei erhält, kann er alles machen, selbst wenn er nur Lese-Rechte hätte. Denn über die Datenbank kann man einfach Einträge ändern und dann per Seitenaufruf den Rest manipulieren. Da spielen dann die zusätzlichen FTP Daten in dieser Datei eine untergeordnete Rolle meiner Meinung nach, denn die beschleunigen dann nur das Unvermeidliche.

Deshalb immer wp-config.php schützen.

1.) Keines dieser Plugins ruft die Funktion remove_menu_page auf.
2.) Was bei dir Zeile 1286 ist, ist in der aktuellen WordPress 3.5 Version Zeile 1290! Woher kommt der Unterschied von 4 Zeilen?
3.) Bleibt maximal noch das Theme selbst übrig, das o.g. Funktion aufruft und den Fehler verursacht.

Zu klären ist also, ob das Update wirklich alles korrekt ersetzt hat und ob ggf. nicht das Theme Urheber ist. Das kann mit Twenty Ten/Eleven/Twelfe sehr schnell überprüft werden.

Ja, das kann man in MB Schritten testen.
Ein Plugin von mir (sorry, aber 2 Jahre nix dran gemacht, weil nix zu tun war) ist zwar nicht für WP 3.5 ausgewiesen, läuft aber damit problemlos. Es hat einen Memory Limit Tester, der im MB Schritten testet, wieviel Speicher er konsumieren kann, bis der Abbruch durch das Limit kommt.

http://wordpress.org/extend/plugins…alth/changelog/

Werde dieses Plugin demnächst einem Update unterziehen und einen 100% Check mit WP 3.5 machen.

Das ist doch nicht die ganze Liste der Plugins (2) oder ?
Probleme kann jedes einzelne verursachen nach einem WordPress Update, deswegen die Frage nach der Liste.

Nur nochmal zu Sicherheit als Nachfrage(n):

1.) Können wir davon ausgehen, das beide Versionen, die du vergleichst auf "Werkszustand" sind (ohne Plugins und mit Twenty Ten beide) ?
2.) Hast du vorher sämtliche Browsercaches geleert und jeweils den Browser neu gestartet (damit gecachte Javascripts der TinyMCE mit iframe Support auch wirklich nicht mehr benutzt werden)?
3.) Hast du in beiden Versionen den visuelle Editor komplett im Backend abgeschaltet (um nur noch HTML zu machen) ?

Sobald der visuelle Editor aktiv ist in "Werkseinstellungen" ist mir ebenfalls bekannt, dass sich am Markup vergriffen wird, sobald da iframes drin sind.

Welche Plugins sind bei dir aktiv? Es sieht danach aus, als ob ein Plugin das Backend Menü während eines Ajax calls modifizieren will. Dort gibts das aber nicht und der Aufruf bringt dann diese Warnung.

Pro Ausgangsbild wird der Speicher natürlich recycled. Aber wenn Bild 1 in X Größen bereitgestellt werden muß, dann ist das Bild 1 im Speicher und gleichzeitig das Zielbild mit Zielgröße bevor es auf Platte gespeichert werden kann.
Die Anweisung zu geben, 96MB zu nutzen, hat noch lange nix damit zu tun, wieviel Speicher dir dein Provider zubilligt. Wenn dein Packet nur 64M seitens Provider hat, dann kannst du sooft sagen, ich will 96M, da ist bei 64M Schluss. Und wenn du schon bei 51 bist, ist bis 64M nicht mehr viel Luft.
Bei 1und1 wird ja in einigen Packeten behauptet, man hätte 96M aber tatsächlich sind es mittlerweile ca. 70M (früher war sogar bei 32M Schluss). Du solltest deinen Provider befragen, welches Limit er dir vorschreibt.

Zitat von Ralf70

Hallo Codystyling,
Hallo Uwe

der Tipp mit dem IMPORTANT hat leider gar nichts gebracht.

Du hattest es ja geändert und die Schrift in der Sidebar war im Firefox auch kleiner geworden. Selbiges hab ich auch mit Firebug vorher ermittelt und gepatched. Kann nicht verstehen, was daran nicht ging. Sämtliche Links waren dadurch in der Sidebar wesentlich kleiner.
Vielleicht versteh ich dich auch falsch ...

Welcher Fehler kommt denn genau?
Hast du nur die Domain und sonst nix?
Kann es sein, das du noch nicht mal PHP ausführen darfst?

.widget-area .widget p, .widget-area .widget li, .widget-area .widget .textwidget {
    [COLOR=#ff0000][B]font-size: 0.8em !important;[/B][/COLOR]


    line-height: 1.84615;




}

... in der Datei style.css Zeile 627 ff.

Die Links und Texte sind nun reduziert damit. Die !important Angabe setzt sich über andere, dominierende Anweisungen hinweg.

Dabei kann man mit den gegebenen Informationen noch nicht wirklich helfen. Ich habe sowohl die WP 3.5 Sprachdateien von pt_PT als auf pt_BR getestet im Rahmen meines Übersetzungsplugins und keinerlei Nebenwirkungen feststellen können.
Kann es sein, dass du entweder eine ältere WP Version hast oder aber WP auf 3.5 geupdated hast aber nun dein Theme nicht mehr 100% kompatibel ist?

Ich fürchte, mit Ferndiagnose wird man hier nicht sehr weit kommen können, um dir zu helfen.

Dieser Teil hier scheint vom WPML Plugin zu sein oder generiert zu werden.
Dabei werden zu viel DIV geschlossen laut Quelltextanalyse:

<script type='text/javascript'> <!-- wpml_more_html['50e568e74bfcd']="<div class=\'wpml_commentbox\'><div class=\'wpml_nav\' id=\'buttonl-50e568e74bfcd\' onclick=\'wpml_toggle_smilies(\"50e568e74bfcd\");\'>weniger...</div></div><div style=\"clear:both;display:none\">&nbsp;</div>";  //--> </script>  <div id='smiley1-50e568e74bfcd' ><div class='wpml_nav' id='buttonm-50e568e74bfcd' onclick='wpml_more_smilies("50e568e74bfcd");wpml_toggle_smilies("50e568e74bfcd");'>mehr...</div></div> <div style="clear:both;">&nbsp;</div> </div>

Wenn möglich, teste mal mit deaktiviertem WPML Plugin.

Doch, weil das Login-Cookie ggf. an die falsche Domain gebunden ist und somit nicht für die 2. gilt :-)

Ich würde sagen, es ist erstmal viel wichtiger, zu verstehen, warum die Seite eine "gespaltene Persönlichkeit" ist!
Denn einerseits gibst du als Link und Domain: nimmsmithumor.de an, andererseits will der Seiteninhalt z.B. die für Kommentare wichtigen WordPress eigenen Scripte von dieser Domain laden: torstenbuchheit.de

Kannst du bitte erstmal klarstellen und erklären, warum es so einen Domain-Mischmach bei dir gibt?

Ich würde sagen, du hast eine Seite mit dem slug "weiterbildung" und parallel dazu auch eine Kategorie mit dem slug "weiterbildung". Und in der Permalink Einstellungen sicher keine Kategorie-Basis. Dann ist das ein Konflikt innerhalb von WordPress Rewrite, den du damit erzeugt hast.

Hier der Body deiner "Weiterbildung"-Seite:

<body class="archive category category-weiterbildungen category-17 custom-background"

Und hier der Body der Seite "AFOMA – Kurse Seminare" als Unterseite von "Weiterbildung":

<body class="page page-id-87 page-child parent-pageid-822 page-template-default custom-background"

Wie du sehen kannst, ist die kaputte Seite von WP als Kategorie eingestuft worden, die Unterseite als reguläre Seite.

Wenn du die Kategorie Weiterbildung löschst, dann in die Permalinks gehst und nochmal speicherst, sollte die Seite funktionieren. Gleiche Slugs für verschiedene Sachen gehen in WP nicht.