Beiträge von mastermind

Öhm, irgendwie kann ich zwischen den jeweiligen Schnipseln keinen Unterschied erkennen.

Zitat von SuMu

da frage ich mich, ob es sich denn lohnt unter Umständen sein Theme anzupassen und wie groß der Aufwand wäre...

Ich habe das Upgrade mit einer Seite getestet, auf der ich viele Plugins und ein recht diffiziles Theme im Einsatz habe. Das Aktualisieren hat dabei absolut reibungsfrei geklappt. Es gibt allerdings einige Plugins, die auf ältere APIs bauen und mit Sicherheit Probleme beim Aktualisieren machen werden. Damit man dann nach erfolgtem Upgrade nicht mit runtergelassenen Hosen dasteht, sollte man lieber testen. Auf Themes bezieht sich das sowieso nur, soweit sie mit Hacks und Features arbeiten, die ohnehin eher in Plugins gehören.

Man muss aber das Rad nicht neu erfinden: Es gibt Übersichten über die Kompatibilität von Plugins mit WP 2.1, z.B. im WP-Codex oder via Google und Co.

Es gibt eine erste beta-Version für WordPress 2.1 zum Download:
http://wordpress.org/beta/wordpress-2.1-beta1.zip

Da es mit 2.1 einige grundlegende Veränderungen geben wird (unter anderem DB-Struktur und Linkverwaltung), kann es für den einen oder anderen interessant sein, diese Vorabversion zu testen, um auf den Wechsel im Produktivbetrieb vorbereitet zu sein. Das Upgrade ist unproblematisch, was den WordPress-Kern angeht, doch es ist gut möglich, dass es Probleme mit Plugins oder Themes gibt.

Wichtig: Beta-Versionen sind für den Produktivbetrieb nur bedingt geeignet. Sie sollten nur in Testumgebungen (z.B. zuhause mit XAMPP) auf Basis einer Backup-Version eingesetzt werden. Beta-Versionen werden in den Foren von WP-DE.org nicht unterstützt. (Natürlich darf man sie diskutieren, aber Troubleshooting für Newbies findet nicht statt.) Wer betas in Produktivumgebungen einsetzt, der zieht sich auch die Hosen mit der Kneifzange an.

Wer Fehler findet, darf sie in diesem Fall leider nicht behalten, sondern meldet sie an die WP-Entwickler. Man sollte vorher jedoch einen Blick auf bereits gemeldete Fehler sowie auf die Mailinlisten wp-testers und wp-hackers werfen. Je mehr und ausgiebiger getestet und gemeldet wird, desto besser wird dann die finiale Version 2.1 sein.

Eine zweite Beta wird in den kommenden Tagen verfügbar sein. Natürlich gibt es auch SVN; aber wer das macht, der weiß auch, wie er da rankommt.

Die Auslastung hängt bei Plugins auch in hohem Maße von der Effizienz der Programmierung ab. So benutzen viele Plugins völlig unnötigerweise Reguläre Ausdrücke, wo es ein einfaches strpos() oder str_replace() tun würde. Durch das Laden der Regex-Engine wird unnötig Speicher- und Rechenleistung verbraten, was sich durch verlängerte Ladezeit und sogar wie in diesem Fall durch Fehlermeldungen bemerkbar macht.

Ergo: Es gibt kein zahlenmäßiges Limit für Plugins, aber der Einsatz muss sich an der (jeweils verfügbaren) Serverleistung orientieren. Doch bevor man einen Profi heranzieht, der den Plogin-Code analysiert oder gar umschreibt, wechselt man im Heim- und Homeoffice-Bereich lieber zu einem vernünftigen Hoster.

Das gleiche Problem habe ich auch schon festgestellt. Anscheinend hat sich da was an den Schnittstellen geändert.

Ich darf Dir -- zumindest übergangsweise -- mein Plugin Advanced Search empfehlen, das funktioniert nach wie vor. Es ist zwar kein direkter Ersatz für Search Pages bzw. Search Everything, aber es vermittelt zumindest die Möglichkeit, in Seiten und Kommentaren zu suchen.

Die Sache mit Search Pages schaue ich mir bei Gelegenheit mal an, denn das brauche ich parallel zur Erweiterten Suche auch.

Um ehrlich zu sein -- ich bin mir grad selbst nicht sicher, wie es standardmäßig ist (benutze normalerweise keine Unterkategorien).

Wie sieht denn Deine sidebar.php aus?

Das ist doch standardmäßig schon so, oder bei Dir nicht?

Wenn Du damit den eigentlichen Blog, also die Startseite meinst: die index.php. Die kann aber -- je nach Themeaufbau auch für andere Sachen wie statische Seiten, Archive oder Einzelansicht zuständig sein.

Willkommen erstmal bei WordPress. Ich habe auch diverse Sachen mit s9y gemacht, aber es hat mich auch nie so recht überzeugen können, wenngleich die Entwickler sehr gute Ideen haben. Für mich ist WP momentan das Nonplusultra; aber mal schaun, vielleicht komme ich nochmal in das Vergnügen einer s9y-Installation.

Zu Deinem Problem: Es scheint tatsächlich so zu sein, dass cforms Deine Umlaute verhaut, denn normalerweise gibt es damit keine Probleme. Vielleicht hilft Dir das Plugin Clean Umlauts weiter; allerdings ist die Website des Autors just in diesem Moment unten.

Ich habe übrigens gute Neuigkeiten. Habe dem Autor mal eine Frage bzgl. der Lizenz ins Stammbuch geschrieben -- die Antwort lässt hoffen.

Zitat

Question From Alex:
Hello Vaam, you've got such a nice FAQ plugin there. Why do you distribute it under such a restrictive license? See, many people work with OpenSource software and everybody benefits from the freedoms to distribute and modify it. You yourself will have to admit that you benefit from a permissive licensing (with the modified Rin theme and parts taken from mozilla.org). And if somebody would be out to steal your code, they don't care about the license anyway. Besides, if you start to distribute this plugin with WordPress (e.g. you install it for a customer), you violate WordPress' very own license terms. Lots of people would love to improve the plugin and share it (I'm actually dropping from a forum where this is discussed right now). Would it be asked to much that you publish your plugin under an OpenSource license?

Answer:
There once was a time when ALL my plugins were licensed under the GPL. My memory is crappy and it's been so long so I don't remember specifics, but basically there was a backlash to the release of my "Donations" plugin only available to donors of the site. I got disenchanted with the GPL and the people who were only the day before praising my other plugins.
One day I'll release the plugins under the GPL; because I believe it's the right thing to do... just not today.

Vgl. http://rane.hasitsown.com/blog/index.php?page_id=32#q_232

Zitat von Ragnaroek

wie schwer wäre das den? Also ich habe keine Probleme damit ein kleines Blog mit php und MySQL (aber wirklich klein, also mit Textfeld und HTML-Tags) zu programieren...mjit den ersten 3 Normalformen kenne ich mich auch recht gut aus...reicht das aus? :mrgreen:

Je nach Struktur und Umfang der DB kann ich Euch ein Importmodul programmieren, das habe ich für andere Kunden auch schon gemacht. Bei Interesse schreib mir bitte eine PN, dann kann ich Dir ein paar Details nennen.

Ändere den Namen Deiner single.php in hokuspokus.php und staune.

Naja, es scheint ja an sich ganz gut zu funktionieren. Insofern spricht ja nichts gegen eine Verwendung (der Originalversion).

Nur ich als OpenSource-Purist bekomme bei solchen Sachen immer das kalte Ihrwisstschonwas... und ich frage mich, warum man die paar Zeilen Code wie ein Schießhund bewachen muss. Letztendlich profitiert man gerade bei solchen Sachen von einer offenen Lizenz.

Probier mal einen traceroute auf Deinen und andere Server (unter Windows geht das im cmd-Fenster mit dem Befehl tracert).

Ansonsten ruf mal ein paar Webseiten mit einem HTTP-Grabber ab (weiß leider nicht, was es da unter Windows gibt), dann siehst Du, wie lange der Seitenabruf ohne Rendering dauert.

Wenn beides schnell geht, könntest Du Deinen Rechner aufrüsten -- obwohl Deine Specs nicht so schlecht sind. Kannst Dir ja mal ein vernünftiges Betriebssystem draufpacken: http://distrowatch.org :mrgreen:

Die RewriteBase ist relativ zum DocumentRoot, insofern ist / schon korrekt und /var/www usw. falsch. Den HTTP 500 bekommst Du, weil Du vermutlich keine Rechte hast, die DirectoryIndex-Direktive zu nutzen; hat also mit dem eigentlichen Problem nix zu tun.

Alles in allem sieht mir das nach einem mies konfigurierten Server aus. Ich würde mich mal an direkt den Provider wenden und fragen, warum das mod_rewrite nicht korrekt funktioniert.

Zitat von milko

SuMo

*lol*

So dick ist unsere Susi dann doch nicht...

Zitat von olafson

laut:
http://trac.wordpress.org/changeset/4665

muss man eigentlich nur ein
wp_specialchars( .. )
einfügen.

Das habe ich auch gedacht (s.o.), allerdings habe ich übersehen, dass es noch eine weitere Sicherheitslücke gibt, siehe http://www.heise.de/security/news/meldung/83280

Du kannst ruhig direkt auf 2.0.6 aktualisieren: Alle WP-Inhalte außer wp-content/ und wp-config.php löschen, neue Dateien hochladen, /wp-admin/upgrade.php ausführen -- fertig.

Zitat von Putzlowitsch

Wer hat schon einen eigenen Server? :-

Ich :mrgreen:

Aber ja, Thema Suchanfragen loggen:

Ich habe da mal einen kleinen (und sehr schmutzigen) Hack entwickelt, der als WordPress-Plugin funktioniert. Man legt zunächst eine die Datei wp-content/qd_searchstats.txt an und macht sie für den Server schreibbar. Danach speichert man folgenden Code als php-Datei unter wp-content/plugins und aktiviert es im Admin-Panel:

<?php
/* Plugin Name: qd_searchstats
Plugin URI: http://www.zirona.com/
Description: Quick'n'dirty search stats in a text file
Author: Alex G&uuml;nsche
Version: 0.1
Author URI: http://www.zirona.com/ */


// This code may be considered as being in the Public Domain.


function statsfilter() {
	if ( !empty($_GET['s']) ) {
		$myfile = @fopen(ABSPATH.'/wp-content/qd_searchstats.txt', 'w');
		$mydata = date('d.m.Y H:i')." {$_GET['s']}";
		@fwrite($myfile, $mydata);
		@fclose($myfile);
	}
}
add_action('init', 'statsfilter');
?>

Et voilà, mit jeder Suchanfrage werden nun Datum und Suchbegriff protokolliert.

Wie gesagt, das ist keine besonders schöne Lösung, sondern soll nur die Funktionsweise verdeutlichen.

Das wird vermutlich daran liegen, dass der Text Bücher vorher als UTF-8 vorlag und dann als ISO-8859 gespeichert wurde. Da UTF-8 ein Multibyte-Zeichensatz ist, hat es wohl das UTF-8-Zeichen ü in zwei ISO-8859-Zeichen zerhauen. Diese wiederum konvertiert WordPress in HTML-eigene Zeichen.

Möglicherweise liegt es an einem Plugin, das auf seltsame Weise eine Zeichensatzkonvertierung probiert, oder aber Du hast etwas an Deiner Datenbank geändert.