Leute, die Content von anderen klauen, machen das nicht aus Unwissenheit und auch nicht, um ihren Lesern Informationen zu bieten. Und wenn sie von dem einen einen "netten Hinweis" bekommen, dann nehmen sie halt den nächsten. Ich finde das Androhen juristischer Maßnahmen sehr wohl angemessen; ich hätte auch nichts dagegen, wenn mein Anwalt eine Abmahnung raushauen würde.
Beiträge von mastermind
-
-
Wozu man es braucht, weiß ich auch nicht.
Es ist das erste Plugin für WordPress, und Entwickler können daran Aufbau und Funktionsweise eines Plugins studieren. Für Endanwender ist es in etwa so nützlich wie der Blinddarm-Appendix.
-
Ich glaube nicht, dass das ein Plugin ist. Die Signaturen werden von Hand gepflegt, und einige Leute aktualisieren sie gerne mal.
-
Alles anzeigen
Gut, meine Aussage "ist kein offizieller Syntax" nehme ich auch gerne zurück. Ich habe in der Doku weder etwas dafür noch dagegen gefunden.
Die Diskussion ist aber auch müßig, denn das ist nicht das Problem. ;)
Ohne meine Änderung von oben schreibt das Script pro Datensatz 2 unnötige Leerzeichen in das Backup, die rein gar nichts bewirken und einfach nur Speicherplatz verbrauchen. Bei 50.000 Datensätzen sind das schon 100.000 überflüssige Leerzeichen, die letzlich die Größe des Backupfiles unnötig vergrößern. Das verbietet sich eigentlich von alleine.
Abgesehen davon schreibt kein anderes Backupprogramm ein Leerzeichen zwischen die schließende Klammer der Insert-Anweisung und dem abschließenden Semikolon - auch das Konsolen-mysqldump nicht. Es macht schlichtweg keinen Sinn.
Und bitte - ich habe die Stelle gern gefunden und verbessert. Im Posting davor wurde ja danach gefragt.:wink:Jau, da gebe ich Dir völlig recht. Aber vllt. könnte man doch mit einer kleinen Regex doch sicherstellen, dass bei dieser seltsamen, aber anscheinend korrekten Syntax das Einlesen der Daten doch funktioniert.
Bzgl. Speicher sparen: Dann könnte man auch die (meisten) physikalischen Zeilenumbrüche weglassen. ;)
Hab mir übrigens den Dumper mal angeschaut, hat einen guten ersten Eindruck hinterlassen. Allerdings musste ich die erzeugte Datei zweimal entpacken.
Ach ja, a propos Timeout: Man kann den PHP-Timeout auch beliebig erhöhen (wenn PHP nicht im Safe Mode läuft): PHP: set_time_limit - Manual
-
Kann es sein, dass der Server bzw. Dein Blog nicht in Deiner lokalen Zeitzone sind? Siehst Du mittlerweile die Beiträge von vorhin?
-
Jep, dieser besch... Safe Mode wird ab der nächsten Version nicht mehr unterstützt.
ZitatEine Frage aber mal nebenbei; bei der Prüfung vor dem Lauf empfiehlst Du "0777" als Modus für alles; sollte das nicht für Dateien "0666" sein?
Der Unterschied zwischen 0666 und 0777 ist, dass die Dateien bei 0777 zusätzlich ausführbar gemacht werden. Das ist bei PHP-Zeuchs und anderen Webinhalten völlig irrelevant, da die sowieso nicht als einzelne Dateien ausgeführt werden können. Abgesehen davon werden sowieso nach dem ersten Upgrade-Durchlauf (den man ja sofort nach der Installation machen soll) die Dateirechte vom Server neu gesetzt.
-
Vielleicht solltest Du wirklich mal kurz bei Deinem Hoster anfragen, vielleicht wissen die mehr oder können Dir zumindest bei der Log-Recherche helfen.
(Danke übrigens für Deine PN, hab Dir ne Mail geschrieben.)
-
Äh, ok. Wo finde ich die Log-Files?
Da müsstest Du Deinen Hoster fragen, das ist überall anders.
Und ähem, da ich immer mal wieder Probleme habe und nicht so der Experte bin - wo finde ich denn jemand, der mir Design, Programmierung usw. meines Blogs macht? Ist zwar ne Charity-Veranstaltung, aber etwas bezahlen kann ich schon dafür.
Wenn Du magst, kannst Du mir eine PN nebst Deiner E-Mail-Adresse schicken, und wir können das außerhalb des Forums besprechen.
-
Dann solltest Du mal in Deine Log-Files schauen, ob vielleicht jemand anderes diesen Beitrag für Dich geschrieben hat. Schau nach, wann der Beitrag veröffentlicht wurde und suche in den Logs nach dem Wörtchen POST im betreffenden Zeitraum.
Oder frag Deinen Hoster bzw. Dienstleister Deines Vertrauens.
-
Darf man fragen, was eigentlich der Anlass für diese "Wartungsmodus"-Beitrag war?
-
Was ist Dein neuester Beitrag? Wieviele Beiträge pro Seite sind bei Dir eingestellt?
P.S. Warum bekommt man unter http:// olemax.com/about Deinen Blog zu sehen? Vielleicht solltest Du uns etwas genauer schildern, was Du gemacht hast seitdem das Blog zuletzt funktionierte.
-
Wenn man mit einem WP-Blog umzieht, muss man die Optionen home und siteurl ändern. Das Dilemma: Diese Werte stehen in der Datenbank, man kann sie nicht ändern, bevor man eingeloggt ist -- und wenn man sich einloggen möchte, wird man auf die alte URL umgeleitet.
Bislang dachten wir alle, man müsse die Datenbank selbst bearbeiten, um diese Parameter zu ändern. Aber es gibt auch eine einfachere Methode, die sogar noch mit alten Versionen von WP 1.5.x funktioniert:
Nachdem man die Dateien auf den neuen Server geschoben hat und die Datenbank wieder eingespielt hat, öffnet man die Datei wp-config.php mit einem Texteditor und fügt irgendwo die Zeile
ein. Danach öffnet man im Browser die Login-Seite (wp-login.php) des frisch umgezogenen Blogs. Es werden dann automatisch die URLs auf die aktuellen Werte geändert. Danach kann man die eingefügte Zeile wieder aus der wp-config.php entfernen. Kein Gefummel mehr in der Datenbank nötig!
Hoffe, das hilft dem einen oder anderen. Vielleicht könnte man das auch ins FAQ schreiben.
-
War es bei Dir auch der Safe Mode? Oder etwas anderes?
ZitatWobei so ein Serverumzug mit WP ja richtig Sch... ist - da sind die ganzen Pfade/URLs in der Datenbank, statt nur relative - ich mußte das Dump nachbearbeiten ohne Ende.
(und trotzdem funzt vieles nicht [mehr])Nun ja, das ist ja kein Problem des Upgrade-Plugins. Außerdem gibt es Lösungen, mit denen man eine Suchen-/Ersetzen-Operation auf die Datenbank anwenden kann.
-
Nein, das Problem ist, dass das WordPressPlugin ein Leerzeichen zwischen die schließende Klammer und das Semikolon schreibt.
Das ist kein offizieller Syntax [...]Das wage ich zu bezweifeln. Wenn dem so wäre, müsste man bei folgender Eingabe ja einen Syntaxfehler bekommen:
Das Leerzeichen ist ein "Internal Field Separator" (IFS), d.h. ein Zeichen, dass Syntax-Elemente voneinander trennt, und der darf normalerweise überall stehen. Das Semikolon zeigt das logische Zeilenende an und darf auch durch einen IFS abgetrennt sein.
Oder gibt es eine Stelle in der MySQL-Dokumentation, die etwas anderes behauptet?
-
Dann stimmt aber auf Deinem Server etwas nicht. Entweder es ist Safe Mode an, dann können aber keine Dateien gelöscht werden. Oder der Safe Mode ist aus, und es können Dateien kopiert werden.
Ich werde am besten eine Sperre für den Safe Mode einbauen. Safe Mode und Dateioperationen sind immer kritisch, dann kann man das Tool eben nicht mit Safe Mode benutzen.
Mal sehen, vielleicht fällt mir für eine spätere Version was besseres ein, aber momentan muss ich wohl erstmal Schadensbegrenzung betreiben.
-
Hm, das ist seltsam. Eigentlich prüft das Script vorher, ob die Dateien schreibbar sind.
Welche Konsequenzen hatte das Problem für Dich? Kannst Du evtl. die Log-Meldungen des Upgrade-Vorgangs hier posten?
-
gilt das von allen versionen auf alle versionen ?
Prinzipiell ja, soweit dem nicht generell etwas entgegensteht (vgl. Upgrading WordPress « WordPress Codex.
was ist mit plugins ?
Was soll mit denen sein?
-
Wenn Du bestimmte Plugins, verwendest, solltest Du das auch in der Problembeschreibung angeben.
Warum es Probleme mit dem Plugin gibt/gab, weiß ich nicht; anscheinend ist es mies programmiert. Oder aber Du hast die Installationsanleitung nicht beachtet. Oder Du hast eine Datenbank mit einem unzulänglichen Tool migriert.
-
-
SELFHTML: Stylesheets / CSS-Eigenschaften / Pseudoelemente und Pseudoklassen
Wenn der Validator :last-child als Fehler wertet, dann ist es entweder falsch verwendet, oder der Validator arbeitet fehlerhaft.