• Download the archive
• Open includes/af-extended-live-archive.js.php and includes/af-ela.php in your favorite editor
• Replace in both files

  require('../../../../wp-blog-header.php');

  with

  require_once('../../../../wp-config.php'); 		
  $wp_did_header = true;
  $wp->init();

  and you’re good to go.

If anyone has a better idea, please write a comment.

Share This

Es ist so zum kotzen, dass es Programmiersprachen wie PHP den Leuten so leicht machen, hübsche Sachen zu programmieren, die auseinander fallen, wenn man sie mal schief anschaut.

“Hübsche Gui” und “Ich weiß, was ich da gerade in die Datenbank schreibe” sind zwei Paar Schuhe.

Wie kann man eigentlich eine Checksum Routine so implementieren, dass sie auf unterschiedlichen Architekturen unterschiedliche Ergebnisse liefert? Braucht es da mehr als einen mittelmässig begabten Affen, zu erkennen, dass das eine scheiß Idee ist? Und noch spannender ist es natürlich dann, diese Funktion auch zu nutzen.

Boah echt ey.

Leute, lasst die Finger von PHPs crc32() Implementierung oder benutzt sie richtig.

Share This

But wp-cache comes with a security flaw. It requires the webserver to have write access on $WP_HOME/wp-content/cache and $WP_HOME/wp-content. The first part is perfectly reasonable, the second not.

wp-cache creates it’s wp-cache-config.php in that place and edits this file consequently while being configured.

wp-cache comes with a sample config you can put in place. After that, chmod this file to 660 or something else that allows your webserver to edit it. Please don’t give your webserver write access to $WP_HOME/wp-content, especially not facing the current attacks on wordpress bloggers as described here.

I assume you know what your doing in the next step. All recommendations are tested and working with wp-cache 2.1.2. Open the file file wp-cache.php in your favorite editor, navigate to line 471 in function wp_cache_verify_config_file and change the following code

if ( !is_writable($dir)) {
    echo "<b>Error:</b> wp-content directory (<b>$dir</b>) is not writable by the Web server.<br />Check its permissions.";
    return false;
}

to

/*
if ( !is_writable($dir)) {
    echo "<b>Error:</b> wp-content directory (<b>$dir</b>) is not writable by the Web server.<br />Check its permissions.";
    return false;
}
*/

Alternatively, you can use the file i prepared: wp-cache.php. Rename it from *.php.txt to *.php and replace the old file with it.

Read more about the attack on wp blogs here. It’s shown that the attackers create a subfolder in your wp-contents. So it’s essential to chmod this folder to 0755 or even better to 0555 if you’re paranoid and only change it if you upload updates.

Share This

As danger is my second name, i didn’t backup or anything especially for upgrading (ok, honestly i have a nightly cron’ed backup) and run the patch with

patch -p2  diff-from-tags_2.2.3-r6166-to-tags_2.3-r6166.diff.txt

from my install dir and boom, i had 2.3 (get the patch file at the wordpress trac (for upgrading 2.2.3 to 2.3)).

Things, that didn’t work but didn’t break the blog either were: Ultimate Tag Warrior. It’s still there and still working. Things that didn’t work were my theme and the Extended Live Archives by Sons Of Skadi.

For testing purpose, i completely disabled wp-cache.

Luckily, someone had already patched ELA, you can download a modified version here, see it in action here. Be aware, you also need the original release from above. Before this thingy works, you need to clean it’s cache. Otherwise you’ll get some weird error messages.

Things i need to fix in my theme were UTW related. I imported my tags into the new taxonomic scheme and finally, dumped the warrior. The import worked well, but it killed the blanks in tags and replaced them with underscores. Thanks for that :/

I did the following replacement in my theme:

UTW_ShowCurrentTagSet

single_tag_title('');

UTW_ShowTagsForCurrentPost("commalist")

the_tags('',', ');

UTW_ShowWeightedTagSet("sizedtagcloud")

wp_tag_cloud('smallest=70&largest=130&unit=%&orderby=count&order=DESC');

The arguments to the functions corresponds with my former UTW settings. Speaking of which: WordPress 2.3 tagging system is completely naked. There are no settings and what is worse, there is no such thing as a dropdown thingy while writing, just a plain text field. As a first solution, i’ve tried the Advanced Tag Entry WordPress Plugin. Seems to work fine, but not as comfortable like UTW.

All other plugins i use, seem to work fine:

In the meantime, i have the impression that 2.3 is somewhat slower than 2.2.3, but i can be wrong.

I’m in doubt about upgrading my other blog planet-punk.de. I like and do use tags a lot, but for the time being, the greatest db scheme doesn’t help a somewhat unusable ui. Don’t get me wrong, i really like the changes in the scheme going on, but for now, i see little benefit.

Another nice post with the same title as mine has some suggestions for people who ran into problems: read it at the Weblog Tools Collection.

Share This

Zum einen die zur Zeiterfassung Mite gehörende Diplomarbeit, die hier zum Download angeboten wird.
Zum anderen einen Aufsatz von Thomas Bachem, einem der Macher von sevenload.de

Ich finde beide Dokumentationen hochgradig interessant zu lesen, nichts desto habe ich einige Anmerkungen und Gedanken dazu:

Mite ist ein Projekt mit Ruby on Rails. Die Macher hatten am Anfang Lastprobleme, konnten das aber durch einen Umzug auf einen performanteren Server lösen.

Sevenload ist ein PHP Projekt. Leider nutze ich es nicht so häufig wie Youtube, daher kann ich keine definitive Aussage zur Geschwindigkeit treffen. Dennoch frage ich mich, ob es wirklich nötig ist, in einem Grundlagenartikel direkt mit kontrollierten Redundanzen für die einfachsten Sachen wie “durchschnittliche Bewertung eines Bildes” loszulegen? Ich meine, bin ich der einzige, der so etwas für Überflüssig hält? Letzten Endes ist es ein Einzeiler in SQL, der mit korrekter Indexerstellung kein DBMS in die Knie zwingen sollte:

SELECT avg(rating)/COUNT(*), rateable_id FROM ratings GROUP BY rateable_id ORDER BY 1 ASC;

Das dann noch mit einem inner join über die zu bewertenden Dinger verknüpft und gut.

Welcher Ansatz würde ich wählen? Ich selber würde jederzeit Standards vorziehen, im obigen Fall auf ein sauberes ER <->Objekt Mapping und auf Normalisierung in der DB (witzigerweise erwähnt Thomas Bachem das im nächsten Absatz bzgl. Tagging Schema) setzen. In anderen Worten: Lieber den Railsweg gehen und sauberes Design erhalten und dann im Zweifelsfall etwas mehr Hardware hinter her werfen.

Tatsächlich redundate Informationen zu speichern würde ich generell nicht ausschliessen, in diesem Fall allerdings schon. Ich denke, wenn man soweit unten bereits diesen Bedarf hat, wird es eng mit Optimierungen, wenn die Luft unter Last dünner wird.

Share This

If anyone else has this problem, add

$typelimitsql = "(post_status = 'publish' OR post_status = 'static')";  // From previous version of utw

in ultimate-tag-warrior-core.php right before the class definition. It’s taken from the previous UTW Version.

Edit:
Upgrading to WP 2.1.x changed the table structure… A little hint would have been nice in the utw changelog.

Share This

Ich habe mich ein bisschen schlau gemacht, wie man der Welt im allgemeinen und Suchmaschinen im speziellen am besten mitteilt, dass sich eine URL geändert hat.

Der goldene Weg ist der entsprechende HTTP Header: 301, permanently moved. Das ist mit wenigen Zeilen PHP schnell erledigt:

<?php
	header("HTTP/1.1 301 Moved Permanently");
	header("Location: http://info.michael-simons.eu");
	exit();
?>

Diese Methode ist auf jedenfall einem Refresh über Meta Tags vorzuziehen, da die Bots der Suchmaschinen so ihre Indizes aktualisieren.

In dem Zusammen stieß ich auf folgenden Artikel: Redirects using HTTP 301 headers. Dort wird anschaulich dagelegt, dass es für das Suchmaschinen Ranking einer Seite nicht gut ist, wenn z.B. www.michael-simons.eu auf www.michael-simons.eu zeigt, michael-simons.eu auf michael-simons.eu. Suchmaschinenbetreiber stufen dadurch teilweise beide Seiten schlechter ein, weil identischer Content über unterschiedliche Domains zu erreichen sind.

Das kann vermieden werden, indem entweder beide Domains auf michael-simons.eu verweisen oder beide auf www.michael-simons.eu. Beispiel: Wird www.michael-simons.eu als Zieladresse in den Browser eingegeben, landet man genauso auf michael-simons.eu, als wenn man es direkt eingibt. Umgekehrt ist es genauso in Ordnung.

Das Problem lässt sich durch einen Eintrag in die .htaccess Datei mit aktivierten mod_rewrite leicht lösen:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.michael-simons\.eu [nc]
RewriteRule (.*) http://michael-simons.eu/$1 [R=301,L]

Share This