Beiträge von codestyling

Zitat von Frank2000

Kannst du dir das erklären? Kann es sein, dass über das mediathek- upload ein Eintrag in die wp- Datenbank kommt, damit wp den Link findet?

Genau, jeder Upload über die Mediathek wird in der Datenbank festgehalten und auch nur dann in der Übersicht angezeigt. Wenn du Bilder pur per FTP hoch lädst, dann erscheinen die nicht in der Mediathek. Deshalb gibt es ja auch Plugins, die die Mediathek quasi ersetzen.

Dazu brauchst du phpMyAdmin Zugang zur Datenbank und änderst direkt in der Tabelle wp_posts in der Spalte post_type von 'page' in 'post' und umgekehrt bei den entsprechenden Einträgen.

Es gibt tatsächlich ein übles Problem mit der Verwendung von Sprachdateien. Dies geht auf einen Fehler zurück, der offensichtlich in PHP selbst in Kombination mit dem Apache zu suchen ist und WordPress sporadisch oder aber komplett daran hindert, mit Sprachdateien sinnvoll zu arbeiten.

Ich hab das analysiert, einen Bugfix an WP Trac gegeben und einen vorab Download bereitgestellt. Siehe dazu: http://forum.wordpress-deutschland.org/installation/3…html#post173301

error in gettext.php gelöst

Ich hab heute den Fehler und die Lösung an WordPress Trac weitergegeben, vielen Dank nochmal an infected für die Unterstützung bei der Suche nach dem Fehler und dessen Lösung.

Für die Eiligen unter euch hab ich das nochmal erklärt und einen Patch Download bereitgestellt, solange das nicht offiziell zu haben ist:
Code Styling Project » WordPress Sprachdateien erzeugen Fehler in gettext.php

Feedback und Kritik gleichermaßen erwünscht.

siehe dein anderer Thread: http://forum.wordpress-deutschland.org/konfiguration/…html#post173209

viel hilft nicht viel, einmal posten reicht :-D

Zitat von eLmoh

oh mist. Mit einmal, ohne weitere Veränderungen kann die Sidebar im Blog nicht mehr gesehen werden. Also es werden nur noch die reinen Blogartikel angezeigt. Es fehlt die Seitenanzeige, Kategorien und so weiter. Was kann passiert sein ? Und vor allem, wie bekomme ich das alles wieder zum laufen ??

Dein <div class="SR"> liegt innerhalb von <div class="SC">, deshalb liegt die Sidebar auch unten drunter. Da fehlt sicher ein </div> im Content.

Das ist eine Frage, die normalerweise an den Autor gerichtet werden sollte. Anyway, das hier ist die Funktionsbeschreibung: PHP: html_entity_decode - Manual

Und das hier steht dort dran:

Zitat

ChangeLog

Version Beschreibung
5.0.0 Die Unterstützung für Multibyte-Zeichensätze wurde hinzugefügt.

Da er bei dir mit Multibyte-Zeichensatz (MBCS = Multi Byte Character String) rummeckert, nehme ich an, das du PHP 4 benutzt. Stell auf PHP 5 um oder frag den Autor nach PHP 4 Kompatibilität, denn das muß nicht die einzige Stelle sein, die dann nicht will.

Also dieses hier

// get the shortened month name; strftime() should localize
        for($currentMonth = 1; $currentMonth <= 12; $currentMonth++) $shortMonths[$currentMonth] = ucfirst(strftime("%b", strtotime("$currentMonth"."$bogusDate")));

ersetzen durch:

$shortMonths[1] = 'Jan';
$shortMonths[2] = 'Feb';
$shortMonths[3] = 'Mrz';
$shortMonths[4] = 'Apr';
$shortMonths[5] = 'Mai';
$shortMonths[6] = 'Jun';
$shortMonths[7] = 'Jul';
$shortMonths[8] = 'Aug';
$shortMonths[9] = 'Sep';
$shortMonths[10] = 'Okt';
$shortMonths[11] = 'Nov';
$shortMonths[12] = 'Dez';

Und dieses hier

// get the month name; strftime() should localize
        for($currentMonth = 1; $currentMonth <= 12; $currentMonth++) $monthNames[$currentMonth] = ucfirst(strftime("%B", strtotime("$currentMonth"."$bogusDate")));

ersetzen mit

$monthNames[1] = 'Januar';
$monthNames[2] = 'Februar';
$monthNames[3] = 'März';
$monthNames[4] = 'April';
$monthNames[5] = 'Mai';
$monthNames[6] = 'Juni';
$monthNames[7] = 'Juli';
$monthNames[8] = 'August';
$monthNames[9] = 'September';
$monthNames[10] = 'Oktober';
$monthNames[11] = 'November';
$monthNames[12] = 'Dezember';

Man kann das auch anders aufschreiben aber ich hab es so gemacht, damit du erkennst, was ich meine. Aber du solltest den Autor des Plugin anschreiben und darauf hinweisen, das man dafür auch eine Übersetzungsdatei bereitstellen sollte.

Zitat von Waldelfe

Oder würde es sogar irgendwie mit [FONT=monospace]

PHP

setlocale(LC_ALL,WPLANG); // set localization language

gehen?[/FONT]

Das würde gehen, aber wenn du das unter einem Apache Server machst und PHP bei dir als Module läuft, dann schaltest du in einem Shared Hosted Server alle darin laufenden Domains auf deutsch um, denn dieser Aufruf gilt für den gesamten Apache Prozess.
Solltest du nur als Alternative in Betracht ziehen, wenn bei deinem Hoster PHP als cgi läuft.

Wenn das wirklich so dasteht, und register_globals angeschaltet ist auf deinem Server, dann kann jeder auf diese Weise irgendeine Seite aus timbuktu bei dir ausführen lassen!
Das ist ein Sicherheitsrisiko hoch 3, Nutzereingaben direkt ausführen zu lassen. Ich hoffe für dich, das die Variablen

[COLOR=#000000][COLOR=#CC0000]$sec
$subsec
$content
[/COLOR][/COLOR]

alle vorher abgesichert und geprüft und nicht 1:1 benutzt werden, wie sie reinkommen! Wenn doch, solltest du schleunigst was dran ändern bzw. ändern lassen, sonst wird deine Domain leichte Beute! Da du das hier jetzt veröffentlicht hast, ist deine Domain in Gefahr!

<?php
require_once( dirname(__FILE__) . '/wp-config.php');
wp();
wp_loginout();
?>

Der Pfad müsste noch ggf. angepasst werden. Da ich annehme, dass dein Blog im Unterverzeichnis läuft, könnte es sein, das es den Cookie auch nur für dieses ausstellt. Wenn also der o.g. Code kein Abmelden anzeigt (was ich mit puren nicht zu WP gehörenden Seiten getestet hab, die im gleichen Pfad wie WP liegen), dann müsste man noch was an der Ausstellung der Cookies machen.
Ansonsten zeigt das im eingeloggten Zustand in meiner Test.php den Abmelden Link.

Der Content ist schlicht zu breit definiert (style.css - Zeile 136ff):

#content {
background:transparent url(pics/back_content1.jpg) repeat scroll 0%;
float:left;
padding-left:10px;
position:relative;
width:[COLOR=Red][B]560px;[/B][/COLOR]
}

570px wie es bei dir aktuell steht, ist 10px zu breit für das Theme.

Nur für diejenigen, die hier mitlesen und Hilfe suchen. Ein Patch ist in Kooperationsarbeit mit infected im Test und wird veröffentlicht, wenn er so funktioniert, wie er soll. Dann ist der Speed immer wie im Originalzustand nur der Fehler tritt dann nicht mehr auf.
Sobald das durchgetestet ist und Bestand hat, werde ich das veröffentlichen und bei WordPress einen Patch einreichen.
Anmerkung: Der Fehler ist nicht die Schuld von WordPress , so wie es derzeit aussieht, ist das ein PHP/Apache Fehler.

So kommst du da dran:

<?php
preg_match_all('/^(\d{4})(\d{2})(\d{2})/', $_GET['m'], $hits);
echo 'alle Termine für den: '.$hits[3][0].'.'.$hits[2][0].'.'.$hits[1][0];
?>

Die regular expression ermittelt aus dem Übergabeparameter ein Array, dass eigentlich so aussieht:

Array
(
    [0] => Array
        (
            [0] => 20080628
        )


    [1] => Array
        (
            [0] => 2008
        )


    [2] => Array
        (
            [0] => 06
        )


    [3] => Array
        (
            [0] => 28
        )


)

Das wolltest du doch so ?

Zitat von Putzlowitsch

Einfach aber wirkungsvoll, Plugin- und Cacheverzeichnis umbenennen und diese in der wp-config.php definieren:

PHP

define('PLUGINDIR', 'wp-content/s634trwe'); 
define('CACHE_PATH', dirname(__FILE__).'/wp-content/re536reb/');

Gruß
Ingo

Ich hab ja kein Problem damit, weil ich den Cache nicht aktiviert hab. Nur leider sind die Bots klüger geworden und ein Test mit dem PLUGINDIR zeigt, das sie erst eine Seite abholen, darin nach bekannten Plugins per RegExp suchen und wieder den passenden Plugin Pfad haben und dann mit diesem erneut ankommen. Für den Cache könnte es helfen, für die Plugins zunehmend nicht mehr. Im Moment sind nur wenig "intelligentere" Bots aktiv aber das wird zunehmen.

Zitat von Saphod

Mit dem bisherigen Log und einem deny in der .htaccess konnte ich durchaus bereits einen großen Teil ausfindig machen. Ich wollte mir einfach den ständigen Eingriff in die .htaccess und das Auswerten der Logs etwas vereinfachen, indem ich den Großteil über ein Plugin abfange.

Es sollte auf keinen Fall zu einer der müßigen Debatten über den Sinn und Unsinn von Antispam-Maßnahmen bei Blogs ausarten... :-)

Mir ist klar, das du das vereinfachen willst. Die Lösungen, die ich auf meiner TODO Liste liegen hab, sehen etwa so aus:

1. Absolut alle Zugriffe werden durch eine PHP geleitet, selbst für die auf Platte befindlichen echten Dateien (Bilder etc.)
2. Die Standard .htaccess lässt dann keinen direkten Zugriff auf irgendeine Datei mehr zu sondern nur der Controller entscheidet, ob er das per Filetyp ausgibt (Bilder/Javascripts etc.)
3. Bei Installation dieses Wächter-Plugins wird eine whitelist der Files erstellt, die per require reingenommen werden dürfen (falls eine PHP direkt angefragt wurde).
4. Die Plugin Installationsseite wird erweitert und bekommt einen Wächter, der die whitelist anpasst, wenn man ein neues Plugin installiert oder eines deinstalliert wird.
5. Die Themeseite wird erweitert und bekommt ein Wächter, der Themes überwacht.

So in etwa (Prosa) stelle ich mir das vor. Das ist ne Menge Arbeit aber machbar. Einzig die Zeit dazu fehlt mir. Alles andere ist virtuelle Sicherheit.

PS: Seit heute morgen 9:00 läuft wieder eine Angriffswelle auf /wp-content/cache/ und eine PHP soll nachgeladen werden, die den Domain Account und den freien Plattenplatz zurückmelden soll. Falls zu finden auch noch den WP Benutzernamen und Passwort, falls der Cache kompromitiert werden kann.
Die Aufrufe kommen immer mit ständig wechselnder IP von Australien, Niederlanden, UK usw. Diesmal scheint ein verteiltes Netz beteiligt zu sein. Bei so was hast du zu tun, das zu sperren.

Zitat von Saphod

Das Plugin soll SO FRÜH WIE MÖGLICH (also via "init" Hook) die Zugriffe auf das Blog loggen. So kann ich erkennen, ob z.B. auf die wp-pass.php zugegriffen wurde, um einen Exploit auzunutzen.

Ok, verstanden. Dann drück ich es auch mal simpel aus:

www. domain . de/wp-content/plugins/google-sitemap-generator/sitemap.php

Wenn ich das direkt aufrufen lasse (geht bei jedem Plugin), dann wird die ganze WP init Show umgangen, denn wenn die direkt angesprochene PHP Datei die wp-config.php bzw. wp-settings.php nicht selbst lädt (warum auch), dann kannst du das auch so nicht monitoren!
Und Exploits richten sich nur teilweise gegen den normalen Aufrufsweg, es gibt viele, die direkte PHP Aufrufe ausnutzen. Diese bekommst du gar nicht mit!

Was du versuchst, kann bestenfalls einen Bruchteil der Zugriffe abweisen, 100% bekommst du nur mit .htaccess und Auswertung der Apache Logs hin.

Ich verstehe das Problem nicht. Wenn du öffentliche Blog Url's monitoren und sperren willst, geht das doch einfach:

add_action('template_redirect', 'my_template_redirect');


function my_template_redirect() {
    global $post;
    if(is_single() && ($post->comment_status == 'open')) {
        //... hier werden die Kommentarscripts bei mir vorbereitet, im Beispiel mit prototype.js
        wp_enqueue_script('prototype');    
    }
}

Du brauchts doch nur den Zugriff auf den bereits ermittelten Post. Ich weise WP hier an, für Einzelseiten, auf denen Kommentare erlaubt sind, zusätzliche Javascripts mit auszuliefern.
Genauso kannst du an dieser Stelle die $post->post_ID besorgen und anhand der IP machen, was du willst. Für Bilder, die direkt ausgeliefert werden, hast du so keine Chance und im Admin Bereich gibts keine post ID.

Ich selbst benutze FileZilla 3.0.11 (Windows), habe aber über Transfer->Transfertyp immer binär eingeschaltet.
Die Anmeldedaten verlierst du nicht nur solltest du die Datenbankeinstellungen, die ja schon in der wp-config.php stehen auch wieder so wie sie jetzt sind in der hochzuladenden Datei stehen haben.

Das sieht nach einer kaputten Übersetzungsdatei aus. Kannst du bitte die Datei: de_DE.mo im Verzeichnis /wp-content/languages nochmal neu hochladen und dabei dein FTP Programm anweisen, dies im Binärmodus zu machen ?

Zitat von Putzlowitsch

Nette Grafik, nur ist mir immer noch nicht klar, was die mit 2000% besagen will.
Ich bin der Meinung, ein Server kann mit maximal 100% ausgelastet werden, sei es nun CPU, Speicher oder sonstwas. Mehr gibt die Hardware halt nicht her.
Es geht aber nicht um die bei Dir unten verlinkte Seite, oder?

Gruß
Ingo

Na ja, 20 fache Belastung kann man sich errechnen, wenn man ein 32 Prozessoren System hat, auf dem 20 Prozessoren Volllast laufen. Aber wie du schon sagst, ist das eine Sache des Standpunkts und wie das allinkl handhabt, weis ich auch nicht.

Und die verlinkte Seite ist mir auch schon "negativ" aufgefallen, da muß es ja zu Überlast kommen bei diesen Keywords.