Beiträge von Johanndrees

So, ich bin umgezogen. Problemlos, dank D4N13Ls Tipp mit dem MySQLDumper. Danke nochmal.

Wunderbare Sache, vor allem für spätere Backups. :mrgreen:

Ich bin jetzt von STRATO zu TOPHOSTER.de gewechselt. Die machen das Ganze zu einem Preis, der nichtmal die Hälfte ist von dem was Strato nimmt. Dazu nur 12 Monate Laufzeit (auf Wunsch auch kürzer) und mit einer besseren Ausstattung.

Zum Problem meines Threads:
Die Performance hat sich nun um Faktor 30 gesteigert. Kein Scherz. Ist eine wahre Wonne jetzt mit WP zu arbeiten. Ich bin sehr zufrieden.

So kann ich also jedem leider nur raten STRATO den Rücken zu kehren, denn da geht's echt nicht.

Ein tolles Tool, das MySqlDumper.

Hab zwar den neuen Provider noch nicht, aber die Backups/Dumps der bestehenden Datenbanken habe ich bereits mit MySqlDumper erstellt.

Macht einen sehr guten Eindruck, daher bin ich zuversichtlich die Daten auf dem neuen Server wieder einspielen zu können.

Danke vielmals! :-P

Hallo.

Ich möchte zu einem anderen Provider umziehen und habe deshalb im phpMyAdmin meines derzeitigen Providers einen SQL-Export meiner Datenbanken gemacht.

Nun stellt sich beim Test eines Imports heraus, das phpMyAdmin dort nur Dateien von maximal 2048 kb Größe zuläßt. Eine meiner SQL-Export-Dateien ist aber mehr als 3 Mb gross.
Selbst nach dem teilweisen Export der Tabellen in zwei SQL-Dateien, ist eine davon noch immer größer als die Maximalvorgabe.

Frage: Wie kann ich das Problem umgehen? Da die SQL-Datei eine ASCII-Datei ist, stellt sich die Frage, ob ich sie mit einem simplen Editor teilen kann?

WordPress 3.0 bietet die Möglichkeit einen XML-Export zu machen. Spiele ich damit tatsächlich die gesamte Datenbank aus und kann ich sie auch durch den Wordpress-Import wieder herstellen?

Und noch ne Frage: myPhpAdmin kann auch XML exportieren. Wie importiere ich ein XML-Format dort?

Danke für Eure Hilfe. :oops:

Hallo.
Ich nutze Wordpress jetzt seit einigen Jahren und seit etlichen Versionen.
Leider stelle ich bei jedem Releasewechsel fest, das die Version danach noch langsamer ist als die Vorhergehende. Jedenfalls kommt es mir so vor.

Mit dem Wechsel auf Version 3.0 ist das Arbeiten mit Wordpress noch unerträglicher geworden als als mit 2.9. So brauche ich jetzt für das Anlegen eines einzigen Postings locker 15 Minuten, von Korrekturen ganz zu schweigen.

Der Aufbau des Blogs im Browser geht eigentlich relativ zügig, aber das Arbeiten auf dem Dashboard geht gar nicht.

Hab bereits Kontakt zu Strato aufgenommen, aber von denen kommt nur die lapidare Antwort, das alles stes optimiert wird und man aus ihrer Sicht nichts ermitteln kann, was diesbezüglich bremsen sollte.

Ich führe zwei Blogs (johanndrees.de/blog mit ca. 750 Postings und lug-erwitte.de/blog mit ca. 48 Postings). Selbst das Kleine Blog ist unerträglich langsam in der Administration.

Hat jemand Abhilfe für mich oder einen Tipp was ich falsch mache? Was kann ich tun um das Arbeiten mit Wordpress zu beschleunigen? :-?

Danke im voraus.

Update

Ich habe den Schuldigen in Form des Plugins "WP Widget Cache" ausgemacht. Das hat wohl Probleme mit der WP-Version 2.8.3 und auf der Seite des Erstellers lesen sich einige Einträge, die darauf hindeuten, das auch andere Leute das Problem haben.

Das Deaktivieren des Plugins behebt das Problem.

Ich habe den Entwickler bereits angeschrieben und hoffe auf ein Plugin-Update.

Widget-Probleme

Ich habe übrigens noch ein zweites Blog, in dem ich ebenfalls das besagte Plugin verwende und auch upgedated habe. Hier funktioniert alles bestens.

Das läßt darauf schließen, daß möglicherweise meine WP-Installation nicht sauber ist. Ich werde das beim Problemblog mal checken.
Trotzdem danke.

Hallo allerseits.
Ich stelle jetzt nach einem Plugin-Update fest, das ich meine Widgets unter 2.8.3 nicht mehr verwalten kann. Zwar kann ich die entsprechende Design-Seite aufrufen, aber weder Widgets hinzufügen oder deaktivieren. Das gesamte Drag&Drop funktioniert nicht.

Kann jemand den Fehler bestätigen oder weiß ggf. einen Workaround?
Vielen Dank im voraus.

Anmerkung: Ich nutze selbstverständlich Firefox 3.5.2 zur Blogverwaltung.

Datenbank-Performance Strato

Das deckt sich leider irgendwie mit meinen Beobachtungen.

Wenn meine Datenbank ein Problem hätte, würden die Probleme länger bestehen bleiben. Das Antwortverhalten der Db ist aber höchst unterschiedlich, könnte heute abend wieder zufriedenstellend sein. Strato hat da wirklich ein Defizit.

Ich habe die Strato-Leute schon angeschrieben und um Stellungsnahme gebeten. Wenn das weiter so geht, werde ich nach einem anderen Provider Ausschau halten. Ist nur immer dumm mit den ganzen Domainwechseln, etc.

Sonst gibt's keine Möglichkeiten den 'Zustand' meiner Datenbank zu checken, oder ggf. zu verbessern? :(

Hallo allerseits.
Ich nutze WordPress 2.7 und eine MySQL-Datenbank bei Strato. Die Datenbank ist ca. 2 Mb gross und enthält zur Zeit 584 Postings normaler Größe.

Nun habe ich mittlerweile zunehmendst Performance-Probleme bei der Administration und beim Posten. So kann nach dem Anklicken des "Publizieren"-Buttons durchaus mal eineinhalb bis zwei Minuten ins Land gehen, bevor sich überhaupt wieder etwas tut. Manchmal, so auch heute, bricht das Publizieren sogar mit der Meldung "Internal Server Error" ab.

Überhaupt ist das Handling im Adminbereich eher zäh als zügig, manchmal fast unbrauchbar, da man Minuten wartet um ein simples Posting zu realisieren oder einen Eintrag zu verwalten. Da ich kein Datenbank-Experte bin, kann ich mir das Verhalten nicht wirklich erklären. Was kann ich tun um die nervigen Antwortzeiten zu verbessern?
Kann man die Datenbank irgendwie aufräumen, komprimieren oder säubern um mehr Geschwindigkeit zu bekommen? Nutz ein Export, Löschen der Db und Import in eine neue, saubere Db?
Was kann die Ursache für die miese Performance von WP 2.7 sein?

Zur Zeit habe ich z.B. folgenden Effekt:
Ich melde mich an um einen bestehenden Artikel zu bearbeiten. WP rödelt einige Zeit, öffnet dann die Bearbeiten-Seite, lädt aber den Editor nicht und meldet nach einer Minute, die Seite sei vollständig geladen. Meinen Text sehe ich nicht und komme auch nicht dran. Die "Verwalten"-Seite wird nach über einer Minute nur mit den letzten drei Postings aufgebaut und meldet dann "Seite geladen". Den Rest meiner 580 Postings sehe ich nicht.

Für jeden Tipp bin ich dankbar. Aber bitte keine "Geh weg von Starto"-Tipps, die helfen mir leider nicht weiter. :-?

Trennerdefinition

Super.
Danke für die Info. Jetzt weiß ich wenigstens wo ich ansetzen muß.
Thanks.

Hallo allerseits.

Zwei Fragen die mich quälen:
1) Wo wird der Trenner definiert, der zwischen den Witdgets (z.B. der Sidebar) angezeigt wird? Kann man den weglassen?

2) Auf meinem Blog
On Air
unten rechts in der Sidebar ist der letzte Widget-Trenner verschoben. Jemand eine Idee wie ich das beheben kann?
Vor dem letzten Update des Plugins "Collapsing Archives", meine ich, war das noch nicht.

Danke im voraus für jeden Tipp :???:

missverstanden?

Zitat von the0bone

Ist das hier nicht wunderbar beschrieben?

Ja, das ist es. Aber das ist nicht das was ich haben will.

Ich habe eine feste Seite in den Einstellungen als Startseite eingetragen. Beim Aufruf zeigt er dies auch wunderbar, nur das ich auf der gleichen Seite anschließend weiter unten die laufenden, aktuellen Artikel sehen möchte.

Meinen (recht umfangreichen) Text der Startseite in den Source-Code zu übernehmen und mich zudem mit Formatierungen, URLs und Links etc. herumzuschlagen, das war nicht wirklich beabsichtigt und wäre auch reichlich dumm gelöst.

Ich weiß, dieser Punkt ist im Forum schon in ähnlicher Form öfters behandelt worden, aber ehrlich gesagt helfen mir die gefundenen Beiträge nicht wirklich weiter, weil sie immer irgendeine Sonderform enthalten.

Um es kurz zu machen:
Ich möchte eine Willkommens-Seite (statisch) immer zu oberst auf meiner Startseite haben, und danach, wie ganz normal die aktuellen Artikel anzeigen.

Die Varianten die ich gefunden habe bezogen sich meist auf Links zu den aktuellen Artikeln, etc., oder andere Abwandlungen.
Wenn ich das richtig verstanden habe, muß ich die home.php modifizieren und den Code für das Anzeigen der aktuellen Artikel hinzufügen. Ist das richtig?

Kann mir jemand mit Details, oder noch besser mit einer anderen Lösung weiter helfen? Würde den Code an Standard-Dateien nur ungern verändern, weil diese ja beim nächsten Update wieder überschrieben werden. Kann man sich zwar merken, aber wer weiß schon wann man welchen Code modifiziert hat. :-|

Nimm ein PlugIn

Zitat von jottlieb

Willst du alle Beiträge schützen, müsste man (evtl. gibt es Plugins! Suche erstmal nach Pluginlösungen) das Theme entsprechend ändern, dass jeweils vor den Beiträgen die Abfrage erscheint. Und auch die Feeds entsprechend ändern...

PlugIns sind der richtige Weg. Ich benutze "Category Access". Ein Top-Tool, das mich in die Lage versetzt für mein Blog exakt zu definieren, welcher User welche Kategorie sehen darf, sofern er angemeldet ist, bzw. wer was sehen darf wenn er NICHT angemeldet ist, die Allgemeinheit also.
Hier der Link zum PlugIn: Category Access
Die Optionen sind allesamt konfigurierbar über die Admin-Seiten von WordPress.

Viel Spaß damit.

Cookie-Prüfung

Mittlerweile habe ich das Problem etwas eingegrenzt.

Beim 'normalen' einloggen über wp-login.php wird zunächst probehalber mit der Funktion 'setcookie' ein Cookie gesetzt um zu sehen, ob der Browser das auch erlaubt.
Später in wp-login.php wird das Ergebnis dieses Tests ausgewertet.

Bei meinem Login-Dialog umgehe ich sozusagen diese Testerstellung, da kein setcookie aufgerufen wird.
Nach dem Abschicken meines Login-Formulars wird wp-login.php aufgerufen und der Status des Cookie-Tests geprüft. Da kein Cookie erzeugt wurde, bricht der Login mit einer Fehlermeldung ab.

Ich habe den Status-Test in der wp-login.php zunächst ausgeblendet, was mein Problem temporär behebt.

Weiß aber jemand wie ich 'setcookie' vor meinem eigenen Login-script aufrufe um wp-login.php unverändert zu übernehmen?
Ich bin da noch überfragt.

Umlaute funktionieren nicht

Schau Dir mal die wp-config.php an.
Bei der Version von WP2.3 stehen zwei neue Zeilen drin. Als da sind:

define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');

Ich hatte ebenfalls ein Problem mit den Umlauten nach dem Upgrade auf WP 2.3. Dann habe ich diese beiden Zeilen auskommentiert und siehe da: Alles wieder bestens.

Versuch mal Dein Glück! :-?

Hallo.
(On Air)
Ich verwende in meiner Sidebar einen Login-Dialog, den ich mal in einem Forum gefunden habe.
Bislang lief das auch alles ohne Probleme.
Seit Upgrade auf WP2.3 meckert WP herum wenn ich mich dort anmelde. Über wp-login.php geht´s ohne Fehlermeldung.

Die genaue Fehlermeldung unter Firefox 2.0.0.7 lautet:
FEHLER: WordPress benötigt Cookies, aber entweder unterstützt Dein Browser keine Cookies oder sie sind deaktiviert.

Natürlich sind die Cookies NICHT deaktiviert, deshalb tippe ich auf ein Problem im PHP-Code. Da ich aber kein Experte für diesen Dialekt bin, hier erstmal der Code-Schnipsel den ich verwende:

<!-- Login-Formular -->

<li><?php
              global $user_ID, $user_identity;
              get_currentuserinfo();
              if (!$user_ID):?>
                <!--  <h2><?php _e('Login'); ?></h2> -->
                <ul>
                  <form name="loginform" id="loginform" action="<?php echo get_settings('siteurl'); ?>/wp-login.php" method="post">
                    <div>
                      <label><?php _e('Benutzername') ?>:
                        <br />
                        <input type="text" name="log" id="log" value="" size="20" tabindex="1" />
                      </label>
                      <br />
                      <label><?php _e('Password') ?>:
                        <br />
                        <input type="password" name="pwd" id="pwd" value="" size="20" tabindex="2" />
                      </label>
                      <br /><br />
                      <input type="submit" name="submit" value="<?php _e('Anmelden'); ?> &raquo;" tabindex="3" />
                      <?php wp_register('', ''); ?>
                      <input type="hidden" name="redirect_to" value="<?php echo $_SERVER['REQUEST_URI']; ?>"/>
                    </div>
                  </form>
                </ul>
              <?php else:?>
                <h2><?php echo $user_identity; ?></h2>
                <ul>
                  <?php wp_register(); ?>
                  <li><a href="<?php echo get_settings('siteurl') . '/wp-login.php?action=logout&amp;redirect_to=' . $_SERVER['REQUEST_URI']; ?>"><?php _e('Logout'); ?></a></li>
                </ul>
              <?php endif;?></li>

<! --- Login-Formular Ende -->

Vielleicht hat ja jemand eine Idee, oder ggf. ein besseres Formular, das ich eventuell einbauen kann.
Für Hilfe bin ich immer sehr dankbar.

Beste Grüße
OJ

Problem gelöst

Ich denke ich habe mein Problem gelöst.

Auf der Admin-Seite, unter "Einstellungen" gibt es zwei Punkte zum Thema URL.
Ich glaube sie heißen "Wordpress-Adresse" und "Blog-Adresse". Blog-Adresse dient als Umleitungsfunktion.

In beiden Feldern hatte ich "http://johanndrees.de/blog" eingetragen.
Das wird den Umleitungsfehler generiert haben.

Jetzt habe ich das Feld "Blog-Adresse" frei gelassen und die Wordpress-Adresse auf "http://www.johanndrees.de/blog" korrigiert.

Zugriff auf das Blog ist jetzt wieder machbar. Der Rest dürfte sich schnell erledigt haben.

Danke für die Anregungen!

Zitat von Putzlowitsch

Hast Du irgendwelche Sachen in der .htaccess stehen, die z.B. eine Umleitung der Domain ohne www auf mit www machen?
Das kann zu Problemen führen, weil Wordpress sowas nun intern macht:
WordPress 2.3: Canonical URLs « Mark on WordPress

Gruß
Ingo

Nein, leider nicht. Ich verwende keine .htaccess-Datei im Blog-Verzeichnis.

Das Problem taucht auch erst nach Upgrade der Datenbank auf. Das alte Blog läuft problemlos. Wordpress 2.3 neu aufgesetzt und mit /wp-admin/install.php eine neue Db angelegt läuft auch problemlos.
Erst wenn ich die 'alte' Db verwende und upgrade taucht diese seltsame Umleitung auf.

Die Eingabe von http://www.johanndrees.de/blog/index.php führt auch zu keinem Ergebnis.
Bin wirklich ratlos zur Zeit ... :confused: