Beiträge von toscho

Lass einen Zähler im Loop mitlaufen:

<?php
// Loop
if ( have_posts() )
{
    $postcounter = 0;
?><ul class="postlist" id="posts"><?php


    while ( have_posts() )
    {
        the_post();
    ?><li class="item-<?php
        if ( 0 === $postcounter )
        {
            print 'first';
        }
        elseif ( 5 > $postcounter )
        {
            print '2-5';
        }
        else
        {
            print '6-10';
        }
    ?>"><?php
// Hier die Ausgabe der Artikel.
        ?></li>
        <?php
        $postcounter++;
    }
?></ul><?php
}

Im Stylesheet sprichst du dann die Klassen an:

.postlist li
{
    float: left;
    width: 50%;
}
/* Hauptartikel */
.item-first 
{
    float: none;
    width: 100%;
}
/* Linke Spalte */
.item-2-5   
{
    clear: left;
}
/* Rechte Spalte */
.item-6-10  
{
    float: right;
    clear: right;
}

Die rechte Spalte hat in deiner Konstellation übrigens einen Artikel mehr als die linke. ;)

Naja, Quickcache könnte früher zuschlagen als dein Plugin. Dann wird deines gar nicht mehr aufgerufen.
Hat Quickcache eigene Einträge in der .htaccess?

Ohne deinen Code kann dir das niemand sagen.

Zitat von csasse

Ich möchte die "SCHROTT APPS" die es dafür gibt nicht benutzen, sondern den original Editor usw.

Dann tritt Apple in den Hintern, die Safari Mobile in eine Schrott-App verwandelt haben, indem sie content-editable sorgfältig ausgebaut haben. Der Editor TinyMCE wird in der nächsten in WordPress zur Verfügung stehenden Version darauf besser Rücksicht nehmen. Siehe Bug 13326. Wenn du mutig bist, kannst du ja jetzt schon die dort abgelegten Patches einspielen.

Man kann auch ohne mod_rewrite ordentliche Permalinks benutzen. Eine .htaccess erstellen mit der einzigen Regel:

ErrorDocument 404 /index.php

Hochladen und Schreibrechte wegnehmen (auf 444 setzen), damit WordPress das nicht mehr anfassen kann. Fertig.

Das klappt nur dann nicht, wenn eigene Fehlerseiten nicht erlaubt sind. Spätestens jetzt aber sollte man über einen anderen Hoster nachdenken.

Packe den Code in ein Plugin und kapsele ihn in eine Funktion. Dann bindest du die Ausführung an eine möglichst zeitige Aktion:

<?php
/*
Plugin Name: Redirect to mobile
*/
// Action auslösen:


add_action('plugins_loaded', 'redirect_to_mobile');




// Dein Code hier:


function redirect_to_mobile()
{
}

Lade das Plugin in dein Pluginverzeichnis und aktiviere es. Das sollte genügen.

Zitat von infected

toscho: Ich berufe mich auch nur auf die Aussagen anderer User.

Du liebe Güte, so viel Desinformation wollte ich heute gar nicht lesen. :)

Zitat

Deswegen habe ich den Threadersteller auch an den Pluginautor verwiesen, sofern er hier keine Antwort bekommt.

Wird wohl das Beste sein. Ich bezweifle sehr, daß die Ursache im Format zu suchen ist. OpenType ist normalerweise rückwärtskompatibel zu TrueType, sofern es kein PostScript-OpenType ist.

Irgend etwas stimmt mit der Gzip-Kompression nicht. Schalte das mal vorübergehend ab, bis du das Problem gefunden hast.

Zitat von infected

In welchem Format liegt die Schrift vor? .otf oder .ttf? Bei .otf hat das Plugin scheinbar Probleme mit den Umlauten.

Die Dateiendung sagt hierzu gar nichts, .ttf kann auch eine Opentype-Schrift sein: OpenType myths explained.

Benutze das Plugin Members, und lege eine Rolle »Fotograf« mit genau zugeschnittenen Rechten an. Der kannst du dann mit ein bißchen Handarbeit auch ein sehr reduziertes Backend einstellen, das jeder leicht versteht.

Du brauchst mindestens die wp-blog-header.php. Einfacher wäre ein spezielles Page-Template.

Suche den Ort, an dem die Fehlermeldung entsteht, und schalte dort die Kontrolle ab.

Zitat von Felria

Kann ich mit HTML eine If-Abfrage machen. Z.B. ob die aktuelle Anzeige-Sprache deutsch oder französisch ist, oder ob die URL auf "lang=fr" endet?

Nein, in HTML gibt es keine if-Abfragen, da mußt du schon PHP verwenden.

Sieh dir mal mein kleines Tutorial »Eigenes Widget schreiben« an, da behandle ich zufällig genau so ein Kategorien-Widget. Da brauchst du nur noch die Sprachkontrolle nachzurüsten; das Markup kannst du frei anpassen.

Wahrscheinlich gehört deine Website jetzt jemand anderem. Mangels URL wirst du wenig weitere Hilfe erhoffen dürfen. ;)

Du kannst doch das Autorenprofil einfach anpassen. Schreib dazu in die functions.php deines Themes:

function musicians_contact_fields($originals)
{
    return array(
        /**
         * Das erste Feld, der Schlüssel, muß immer klein
         * geschrieben werden, und es darf nur die Zeichen
         * a-z, 0-9 und - enthalten.
         * Das zweite Feld enthält die sichtbare Beschreibung.
         */
        'instrument' => 'Instrument/Gesang',
        'myspace'    => 'Myspace',
        'facebook'   => 'Facebook',
        'twitter'    => 'Twitter'
	);
}
add_filter('user_contactmethods', 'musicians_contact_fields');

Die Felder kannst du nach Belieben erweitern.

Im Template rufst du die Daten auf mit the_author_meta() oder get_usermeta().

Hast du das Plugin »Blog Stats« installiert?

Du kannst die Zeichenkette ».ru« unter »Einstellungen/Diskussion« in die Blacklist eintragen. Damit wirst du auch ein paar ungewollte Treffer landen, und russischer Spam bewirbt nicht immer nur russische Webseiten.

Etwas rabiater wäre das Blockieren sämtlicher Zugriffe aus Russland. Dazu holst du dir eine Liste aller IP-Adressen, und die konvertierst du in die CIDR-Notation.

Die resultierende Liste (schon fertig :)) übernimmst du in die .htaccess.
Damit verlierst du natürlich potentiell auch echte Besucher.

Der dritte – und meines Ansicht nach beste – Weg besteht in einem guten Spamschutz. Akismet hat bei mir noch nie einen russischen Kommentar durchgelassen.

Ich habe hier mal eine Methode vorgestellt, die ohne Eingriff in die Sprachdatei auskommt: WordPress-Dashboard: ›Approved‹ nicht ›Genehmigt‹.

Die Sprachdatei wird beim nächsten Update vermutlich überschrieben; deshalb würde ich sie nicht so gerne anfassen.

Wo im Kapitel soll ein Link entstehen, und wie soll WordPress herausfinden, welcher Artikel das ist? So recht verstehe ich dein Problem noch nicht.

Das HTML-Element (nicht Befehl) sieht ganz normal aus:

<a href="PFAD_ZUM_ZIEL">Text</a>

Den kannst du natürlich auch selbst setzen.

Oder meinst du einfach ein automatisches Inhaltsverzeichnis?

Chrome hat ohnehin enorme Probleme mit WordPress. So verschwinden beispielsweise beim Speichern selbst gesetzte lang-Attribute und manch anderes Markup. Ich würde den dafür einfach nicht benutzen und notfalls noch einen Bugreport an die Chrome-Entwickler schicken.
Das ist nun einmal ein Sparbrowser (vom Ressourcenverbrauch mal abgesehen); da weiß jeder Nutzer, daß er ohne Ausweichbrowser nicht auskommt.

fahluk: Ich verstehe beim besten Willen nicht, was das mit Chrome zu tun hat. Hast du dich vielleicht im Fenster geirrt? ;)