Enpi: Wie wurde das Update durchgeführt? Über die automatische Aktualisierung oder manuell per FTP Tool? Wenn automatisch, probiere es mal bitte mit der manuellen Variante.
Beiträge von mfitzen
-
-
Ein Downgrade auf 3.4.x zurück, ist natürlich eine vorübergehende Lösung. Aber wenn der Theme-/Plugin-Autor kein Update rausbringt, um es mit WP3.5 kompatible zu machen, bleibt ihr immer auf dem Stand von WP3.4.
...und macht dann einen neuen Thread auf weil euer Blog gehacked wurde, und schiebt es dann wieder WP in die Schuhe... Alles schon erlebt und (leider) vorhersehbar.
Aber wie schon oben erwähnt kann es auch am Hoster/Server liegen. Bin mal gespannt, ob ich diesmal eine Antwort bekomme. Die Antwort auf meine erste Frage steht ja auch noch aus.

-
blöd nur daß der Blog darauf angewiesen ist.
Ich kann nach wie vor nicht nachvollziehen, wie man seinen Blog von Plugins abhängig machen kann...Ja, danke, aber ich bin genau auf das Theme angewiesen. Plugins waren aus.
Und wie siehts mit folgenden Fragen aus:
Wurden bereits alle Plugins deaktiviert und der Browsercache geleert?
Bringt ein Wechsel auf´s Standardtheme und das anschließende Löschen des Browsercaches Besserung?
Wo wird die Seite gehostet?
Wie lautet die URL zum Problem-Blog?
Wie hoch ist das memory_limit des Servers?
Erfüllt der Server alle übrigen Anforderungen (PHP+MySQL)
Wie wurde das Update durchgeführt?
Wenn automatisch übers Backend: Gab´s beim Updaten irgendwelche Fehler (PHP Fehler, weiße Seite etc.)?
Wenn manuell per FTP: Gab es irgendwelche Übertragungsfehler und welcher Übertragungsmodus wurde gewählt? -
Das kann verschiedene Ursachen haben:
Wurden bereits alle Plugins deaktiviert und der Browsercache geleert?
Bringt ein Wechsel auf´s Standardtheme und das anschließende Löschen des Browsercaches Besserung?
Wo wird die Seite gehostet?
Wie hoch ist das memory_limit des Servers?
Erfüllt der Server alle übrigen Anforderungen (PHP+MySQL)
Wie wurde das Update durchgeführt?
Wenn automatisch übers Backend: Gab´s beim Updaten irgendwelche Fehler (PHP Fehler, weiße Seite etc.)?
Wenn manuell per FTP: Gab es irgendwelche Übertragungsfehler und welcher Übertragungsmodus wurde gewählt? -
Gibt es einen einfachen Weg die obere Navigation zu entfernen? Gesamt oder einzelne Seiten?
Komplett entfernen über die header.php? Entferne dazu:PHP<nav id="site-navigation" class="main-navigation" role="navigation"> <h3 class="menu-toggle"><?php _e( 'Menu', 'twentytwelve' ); ?></h3> <div class="skip-link assistive-text"><a href="#content" title="<?php esc_attr_e( 'Skip to content', 'twentytwelve' ); ?>"><?php _e( 'Skip to content', 'twentytwelve' ); ?></a></div> <?php wp_nav_menu( array( 'theme_location' => 'primary', 'menu_class' => 'nav-menu' ) ); ?> </nav> -
Könnte aber auch am Server liegen. Stichwort CONCATENATE_SCRIPTS
-
Das mit dem nicht funktionierendem Wechsel zwischen HTML und Visuell trat in der Vergangenheit auch gerne beim Freehoster funpic auf. Dort konnte man sich mit einem Eintrag in die wp-config.php behelfen.
-
Toll... Statt hier irgendwelche Links zu uninteressanten Blogs zu posten, hättest Du mal lieber die Lösung bereitstellen sollen...
-
Ich hatte hier noch was gefunden, was in die Richtung gehen könnte: http://wordpress.stackexchange.com/questions/5091…in-a-new-window
-
Aaaaaargh... MEA CULPA! Hab da was vertauscht. :oops:
-
hansbob: Mach das mal bei 19000 Entwürfen...

-
Warum willst Du die Core-Dateien ändern für eine Funktion die es doch bereits schon gibt?! Zumal das Ändern der Core-Dateien sowieso nicht empfehlenswert ist, da die Änderungen beim nächsten Update wieder überschrieben werden...
In den erweiterten Bildeinstellungen kannst Du festlegen, dass das entsprechende Bild in einem neuen Fenster geöffnet werden soll.
[attach='6444.vB'][/attach]
-
Laut php info sind memory 32M - aber sind 32M echt schon zu wenig, um allein die basis Wordpress Version ohne jegliche Plugins zu laden? Das kann doch net sein, oder?
Jain. Es hat auch etwas mit der Serverumgebung bzw. dem verwendeten OS zu tun. Eine Basisinstallation auf einem 32Bit Betriebssystem verbraucht deutlich weniger Speicher, als die gleiche Installation auf einem 64Bit System. Habe eine Installation bei 1&1 auf einem 32Bit System, die mit wenigen Plugins bei ca 28 MB steht. Mein eigener Blog läuft auf einem 64Bit System, ebenfalls mit einer Hand voll Plugins, verbraucht jedoch schon 48MB!
-
Warum sollte es nach dem Wechsel nicht mehr funktionieren, wenn es doch aktuell auch noch läuft? Beim Wechsel werden die Dateien doch nicht bearbeitet.
-
Arbeite mit Childthemes, dann bleiben die Änderungen auch erhalten.
-
[size=8]Bei mir im Übrigen auch ;-)[/SIZE]
-
Die Datei footer.php des Themes einfach bearbeiten

-
-
Zitat
Danke, aber nachdem ich weiter recherchiert habe, war klar, dass es schlichtweg an WP 3.5 liegt!!! Diese Version scheint völlig buggy zu sein! Unglaublich!
Kannst Du das irgendwie belegen?
-
eine idee wie ich wieder zurück zur vorigen WP version komme?
Tja, dazu sollte man vor dem Update ein Backup der Datenbank u. des Servers angelegt haben...