Beiträge von mastermind

Hast Du Dir das Howto unter http://putzlowitsch.de/123-multihost/ durchgelesen und befolgt? Wenn ja, an welcher Stelle genau hakt es?

Dann gib uns doch bitte man einen Link zu Deiner Website mit einem davon betroffenen Beitrag, so dass man das Problem nachvollziehen kann.

Um ein Plugin im Notfall zu löschen, muss man nicht in die Datenbank gehen. Es reicht aus, das betreffende Plugin aus dem Pluginordner zu entfernen und irgendeine WP-Seite neu zu laden. WP prüft, ob die Plugins existieren und deaktiviert nicht-existente Plugins in der Datenbank. Nachdem man die Seite geladen hat, kann man das Plugin wieder in den Plugin-Ordner setzen, es bleibt dann deaktiviert.

Ich bezweifle stark, dass das Theme und der more-Tag sich nicht vertragen.Ich denke eher, dass Du einen Fehler im HTML hast, was dann den Beitrag zerhaut. (Das ließe sich anhand eines Beispielartikels auf Deiner Seite sicherlich nachvollziehen.)

Es gibt als Alternative zum more-Tag -- zumal Du the_exerpt() schon eingebaut hast, die Möglichkeit, einen frei wählbaren Anrisstext einzustellen. Diesen musst Du im Beitragseditor unten im Feld Optional: Auszug (oder so ähnlich heißt das) einfügen.

Zitat von dr.mabuse

Das versteh ich nicht, wieviel Ignoranz steht den hinter so einem Satz ?!

Jaja, Ignoranz. :roll:

Wenn Du unbedingt einen Schriftartendownload realisieren willst -- auf die Gefahr hin, dass es nur in 40% der Fälle funktioniert und dass Deine Besucher schreiend davonlaufen --: es hat nichts mit Plugins zu tun. Plugins realisieren serverseitige Funktionen, was Du brauchst ist eine clientseitige Lösung. Du musst eben die Schriftart definieren und zum Download bereitstellen, und das war's. Alles eine Sache, die Du einfach in die Templates integrierst.

Lies bitte mal die beiden Links, die ich Dir in dem anderen Thread gegeben habe, dann weißt Du, dass das nix mit Plugins zu tun hat.

Hättest Du in die Links geschaut, hättest Du anders geantwortet. ;-)

Ich würde das eher lassen, da es eher ziemliche Probleme mit sich bringt. Aber als Lektüre kann ich empfehlen:
http://de.selfhtml.org/inter/downloadschriftarten.htm
http://de.selfhtml.org/css/eigenschaften/schrift_datei.htm

Du musst die WordPress-URL auf Deine DynDNS-Url setzen. Das geht auf der Optionen-Seite oder direkt in der Datenbank.

Zitat von Lockslay

Ich habe ein grosses Problem.
Mein altes Wordpress war Version 2.4 jetzt habe ich ausversehen,
das updatePatch der Version 2.5 auf 2.6 genommen.

Wahnsinn! Die Welt wartet gespannt auf WordPress 2.1 und Du hast schon 2.6! Aber vermutlich meinst Du 2.0.6. ;-)

Ansonsten: Alles außer wp-content/ und wp-config.php löschen, neue Dateien hochladen, wp-admin/upgrade.php ausführen.

Sieht gut aus. :-)

Man sollte den Hinweis "Auf eigene Gefahr" vielleicht etwas prominenter platzieren. Besser wäre vielleicht sogar: "Bitte den Code lesen! Erst ausführen, wenn man verstanden hat, was hier passiert." Das Script habe ich zwar getestet und bei mir im Einsatz, aber es kann immer etwas schief gehen. Vor allem wenn man als Root unterwegs ist, kann man nicht vorsichtig genug sein.

Wie sieht es aus, wenn es eine Änderung an dem Script gibt? Da es die neuste Version immer unter http://www.zirona.com/download/wpupgrade.sh.txt gibt, würde eine kurze Nachricht hier reichen, und Ihr könntet dann das FAQ aktualisieren. Ich werde das Script demnächst auch so erweitern, dass es auch nicht-privilegierten Nutzern hilft. Evtl. kann man es sogar so konstruieren, dass man keine Shell mehr braucht (vorausgesetzt, der Server lässt die PHP-Befehle passthru() und Co. zulässt).

Direkt noch einige kleine Korrekturen: Statt "Wenn man dann das obige Script ausführt, werden alle in installations aufgeführten Dateien automatisch aktualisiert." bitte "Wenn man dann das obige Script ausführt, werden alle in installations aufgeführten WordPress-Installationen automatisch aktualisiert."

Der Abschnitt

# WordPress website
WORDPRESS="http://www.wordpress.org/"


# path to latest version
LATEST="latest.tar.gz"

sollte lauten

# WordPress website and path to download package
WORDPRESS="http://www.wordpress.org/"


# download package file name
LATEST="latest.tar.gz"

Ansonsten: Hoffen wir, dass es dem einen oder anderen hilft. :-)

Gern geschehen. Was genau war es denn?

Es kann an der Funktion wpautop liegen, die für das automatische Erzeugen von Absätzen zuständig ist. Kann aber auch am WYSIWYG-Editor liegen. Oder an beiden. Du kannst man testweise die Option "Falsches XHTML korrigieren" sowie den WYSIWYG-Editor deaktivieren. Wenn das auch nicht hilft, testweise an den Anfang der header.php die Zeile

<?php remove_filter('the_content', 'wpautop'); ?>

:mrgreen:

Naja, das hier ist nicht so ganz trivial, und momentan hab ich noch ein paar andere Sachen zu tun. Ich werd mich aber am Wochenende mal dranbegeben.

Jaja, das Problem kenne ich auch. Ich werd mal bei Gelegenheit eine Lösung dafür stricken.

Ich glaube, wir sollten langsam mal ein neues Forum für die "Lieblingsplugin"-Diskussionen aufmachen. :mrgreen:

Zitat von eldelle

also kurz und knapp: mit der globals off in der php ini bin ich fein raus und update dann trotzdem mal wenn ne neue version raus is?

So sieht's aus.

Zitat von spartakus5

frage an die entwickler: wie kann man sich davor schützen ?
wie kann man eine funktion eine funktion einbauen, dass nur ips aus deutschland auf die seite zulässt ??

Man kann sich als normaler Webhosting-Kunde erstmal gar nicht schützen, denn für sinnvolle Schutzmaßnahmen muss man auf Ebenen ansetzen, auf die der Kunde aus gutem Grund keinen Zugriff hat.

Es ist auch nicht einfach so festzustellen, ob ein Besucher aus Deutschland kommt oder nicht. Es gibt zwar Methoden, IP-Blöcke ungefähr Ländern zuzuordnen, aber erstens nur recht vage und zweitens viel zu aufwändig. Auch hier hast Du als normaler Hosting-Kunde nicht wirklich die Mittel, eine solche Lösung zu realisieren.

Das Problem daran ist, dass man dafür die Datenbankabfrage modifizieren müsste. Das ist allein schon aus Sicherheitsgründen nicht ganz trivial.

Tchja, die Wege von Bots sind unergründlich. Es kann die verschiedensten Ursachen haben, die man oft weder im Detail durchschauen noch sich effektiv davor schützen kann. So kann es bspw. sein, dass ein Bot versucht, Formularfelder auf die Möglichkeit des Spamversands zu testen. Oder irgendein Skriptkiddie probiert was aus. Nach einem systematischen Angriff sieht es jedenfalls erstmal nicht aus.