Beiträge von codestyling

Ich habe in WordPress 2.8 mehrere Stellen gefunden, die nur unter PHP5 sauber arbeiten unter PHP4 aber unvorhersehbare Resultate haben. Die WP Jungs haben an einigen Umstrukturierungen keine Rücksicht auf PHP4 Befindlichkeiten genommen, das führt nun zu Problemen.

Ich kann nur empfehlen WP 2.8 derzeit mit PHP5 auszuführen, alles andere führt zu meisten schwer nachvollziehbaren Folgefehlern, die nicht immer was mit der Stelle zu tun haben müssen, an der sie angezeigt werden.

Beispiel: file_get_contents

Die Funktion ist wie folgt vorhanden: PHP 4 >= 4.3.0, PHP 5

Ich hatte noch irgendwo Server laufen, die PHP 4.2.irgendwas waren, damit geht WordPress 2.8 nicht mehr, denn die Funktion wird jetzt massenweise verwendet!

Ich würde mal genau die lima-city Bedingungen lesen, nur mal als Beispiel:

Zitat

Auf dem Webspace sind nicht alle Dateiformate erlaubt, wohingegen dir der Download-Server zur Verfügung steht, auf dem du alle Dateiformate speichern darfst. Auf den Webspace-Servern sind folgende Dateiformate verboten:
*.bmp, *.avi, *.midi, *.mpeg, *.mpg, *.mp3, *.wav, *.wmv, *.wma, *.mov, *.rar, *.zip, *.ace, *.tar, *.exe, *.lzh, *.tar.gz, *.tar.bz2, *.gz, *.bz2, *.jar, *.psd, *.cab, *.mid, *.zi0, *.torrent, *.dem, *.w3g, *.w3x, *.wmf, *.dll, *.ogg, *.bin, *.psp, *.tgz, *.ram, *.rmvb, *.7z.
Ebenso sind auf dem Webspace alle nicht aufgeführten Archivformate sowie sämtliche Methoden, um Dateien zu tarnen, verschlüsseln oder ähnliche Aktionen, um den Dateiinhalt oder das Dateiformat zu verschleiern ohne vorherige Zustimmung eines Knights oder eines Administrators verboten! Des Weiteren sind auf dem Webspace alle multimedialen Dateitypen (Dateien, welche Bild, Ton, Ton + Bild = Video beinhalten) nicht erlaubt, Ausnahmen sind natürlich *.png, *.gif, *.jpg, *.jpeg, *.ico und *.swf Dateien. Jedoch gibt es eine Ausnahme, was den Upload von *.zip Dateien betrifft. *.zip Dateien können temporär hochgeladen werden, wenn diese nach dem Upload über den Filemanager mit der entsprechenden Option ("Nach dem Hochladen entpacken") entpackt werden und sofern in dem Archiv nur erlaubte Dateien vorhanden sind. Dies dient dazu, um Traffic zu vermeiden, andererseits ist es somit möglich, mehrere Dateien auf einmal hochzuladen.

Damit fallen Pluginupdates, Theme-Update oder WP selbst flach, den *.zip Dateien werden nur durch den Uploader des Providers temporär geduldet und gleich wieder entfernt.
Dort wo er "baden" geht, will er die Sprachdatei laden. Ich weiss nicht, was dieser Provider noch alles nicht erlaubt, aber gesund liest sich das nicht, was in den Geschäftsbedingungen steht.
Auch wenn das kostenlos ist, das ist viel zu restriktiv, ich würde mich nach einem anderen Provider umsehen!

$event_ids = $wpdb->get_results($query_string1);
    /* if there are ID's, the array $event_list gets filled */
    if (!empty($event_ids)) 
    {
        foreach ($event_ids as $event_id) {
            $event_ids_array[count($event_ids_array)-1] .= $event_id->id;
        }    
        [B]$postid_clause = "( post.ID=".implode(' OR post.ID = ', [/B]$event_ids_array)." ) ";
        $query_string2 = "
        SELECT DISTINCT
            post.post_title as `title`,
            post.post_content as `fulltext`, 
            post.ID as `id`,
            post.post_excerpt as `excerpt`
        FROM 
            {$wpdb->postmeta} as meta, 
            {$wpdb->posts} as post,
            {$wpdb->term_relationships} as cats
        WHERE
            {$postid_clause}
        AND
            meta.post_id = post.ID
        AND (
                meta.meta_key = 'rs_event'
            OR
                meta.meta_key = '_rs_event_start'
            )
        ORDER BY 
            meta.meta_value {$sort_order}";


        $event_list = $wpdb->get_results($query_string2);
    }

Wenn man da 'zig ID's mit oder zusammenpappt, dann kann die Abfrage performace-technisch nur in die Hose gehen.
Und die nachfolgende Schleifenbehandlung der Ergebnisse benutzt massenweise array preg_exp, die man auch messen müsste.
Ohne die Eckdaten der Datenbank (Postanzahl, Kalendereinträge usw.) die hier eine Rolle spielen, kann man sich kein Bild machen. Beide Plugins sind aber von der Art und Weise der Datenabfrage und Aufbereitung her optimierungsbedürftig.

Es gibt mindestens 2 Kandidaten für Performance Verlust:

1. Der Query selbst
2. Die loop über die Ergebnismenge (max. 50)

Query

"SELECT DISTINCT 
       p.id AS id, 
       post_title, 
       start, 
       u.$ec3->wp_user_nicename AS author, 
       allday 
     FROM $ec3->schedule s 
     LEFT JOIN $wpdb->posts p ON s.post_id=p.id 
     LEFT JOIN $wpdb->users u ON p.post_author = u.id 
     WHERE p.post_status='publish' 
       AND end>='$ec3->today' $and_before 
     ORDER BY start $limit_numposts"

Ein typischer LEFT JOIN über 3 Tabellen. Dabei fällt auf, dass es essentiell ist, das sowohl die Spalten p.post_status (WordPress posts Tabelle) als auch s.end (Calendar Tabelle) einen Vollindex benötigen, damit das schnell gemacht werden kann. Die beiden JOIN's provozieren aber auch einen full table scan und sind deshalb performancetechnisch gesehen suboptimal.

Man müsste mit der Datenbank von funkytown mal einen Test machen und die Zeit für den query stoppen und ausgeben lassen. Die Datenmenge and Posts, Usern und Kalendareinträgen sind hier essentielle Größen, da das ein kubische Komplexität O(n^3) hat!

die loop
Es werden alle gefunden Ergebnisse mittels einer Funktion, die ich nicht kenne, pro Zeile und pro Element der Zeile mittels Templates formatiert und ausgegeben. Was genau da passiert, kann ich nicht sehen, könnte je nach Implementierung (regexp Ersetzungen) bei 50 Eintragen und 5 Elementen auch etwas brauchen.

Um das zu beschleunigen, kommt man um die Originaldatenbank nicht drumrum, denn die Tests sind notwendig. Die oben angegebenen Indizierungen in der DB nachzurüsten, kann aber nicht schaden und könnte das Problem schon deutlich mindern.

Musst nicht gleich die fette Schrift rausholen, nur weil dich jemand was fragt.
Da weder Codeschnipsel noch irgend welche hinreichenden Informationen bereitgestellt wurden, versuch ich's mal mit raten:

Alle regular Expression Ausdrücke haben ein Rekursionslimit (Teilausdruckslimit), wenn man mit Bezügen oder Teiltermen im Ausdruck arbeitet. Das ist normal bei 16 kann jedoch auch bis zu 21 sein. D.h. Subausdrücke können nur von begrenzter Menge beachtet werden. Deshalb krachen auch regulars weg, wenn zu viele Teilausdrücke drin sind.

Den Code muß man umstellen, denn bereingt bekommt man das nur, wenn die PHP und PerlReg Biblitheken des Server auf ein höheres Limit gepatched und neu kompilert werden und der Server geupdated wird.

Mit ein wenig mehr Input könnte ich auch besser was vorschlagen, so kann ich nur Hintergrund-Infos liefern.

Das einzige, was hier richtig viel Zeit kosten kann ist das hier:

<?php ec3_get_events(50); ?>

Ich nehme mal an, das man damit 50 Termine abholen kann. Wenn das zugrunde liegende Plugin "schlecht" im Sinne von Performance geschrieben ist, dann macht es dazu 50 Abfragen in die Datenbank, was deine Zeit problemlos erklären würde.
Ich würde den Code durchsehen, der dabei ausgeführt wird und/oder den Autor befragen, wie das schneller zu machen ist.

Das Audioplayer Script hat einen Fehler:

I.width is undefined
var AudioPlayer=function(){var F=[];var ....1 <http://code.google.com/p/swfobject/>

und stürzt ab. Da es gepackt ist, kann man es nicht untersuchen, dazu wäre eine entpackte Developer Version nötig.
Meine Vermutung ist, dass das Script in der Seite "hardcore" ein bestimmtes Element sucht, das es nicht mehr finden kann in diesem Theme.
Diese Struktur und Klassen/ID Vergabe weicht vom mir geläufigen Standard ab:

<div id="subpage">
    <div class="post-180">
    <div class="singlepost">
....

Aber wie gesagt, nur eine Vermutung, da ein Aufruf von I.width nicht geht, was nahelegt, dass die Breite eines Containers abgefragt werden soll, den es nicht gibt.

... und nach welcher Anleitung bist du vorgegangen (Link) ?

Läuft dein Server auch unter MacOS oder hast du einen Provider ?

Beim Provider kannst du ja eine "htaccess" hochladen und mit dem FTP Programm auf dem Webspace dann in ".htaccess" umbenennen.

Bei MacOS kenn ich mich mit den Tools nicht so aus. Unter Windows gibt's das gleiche Problem. Dort erstelle ich die Datei ohne Punkt im Editor und speicher sie. Danach öffne ich eine Konsole (cmd.exe) und nenne sie durch

[FONT=Lucida Console]C:\my_web_dir>ren htaccess .htaccess [/FONT]

um. Vergleichbares sollte es auch unter MacOS geben.

Bitte schön:

<div style="text-align:center;">
<?php posts_nav_link(' · ', 'previous page', 'next page'); ?>
</div>

Direkt von hier: Template Tags/posts nav link WordPress Codex

Zitat von newbie08

Rein zufällig habe ich das Osterei ja schon entdeckt ...

Das Osterei gibt es schon seit WP 2.7, ist also keiner Neuerung von WP 2.8, also nicht aus der "ist neu" Kiste

Ich kann dir nur zum Thema Plugin weiterhelfen, beim Thema CSS müsste ich eine BP Installation haben, die ich derzeit nicht besitze

Wenn du den Code des Plugin in die functions.php der Themes auslagerst, wird er nicht mehr funktionieren, denn:

Der Hook "plugins_loaded" wird ausgeführt bevor die functions.php des Themes auch nur geladen wird!

Deshalb wird schlicht gar nix passieren (BP bleibt ungeändert und nichts ist customized), dir bleibt bei Verwendung von "plugins_loaded" nix anderes übrig, als selbst ein Plugin zu sein.

Das wird daran liegen, dass WordPress die .htaccess Datei nicht findet und vermutlich auch nicht anlegen kann. Ebenfalls könnte es sein, das dein Provider gar keine .htaccess Dateien unterstützt/erlaubt und das pure Vorhandensein dieser Datei einen 500'er auslöst (hatte ich schon bei einigen Providern!)

Die Datei sollte im Grundpfad deiner WordPress Installation liegen (Root Verzeichnis, aus dem ausgeliefert wird. Der Name ist ".htaccess" der Punkt am Anfang ist zwingend.

Du kannst eine leere Datei diesen Names anlegen. Wenn du eine funktionierende Version laufen hast, leg sie einfach an. Wenn allein dadurch der Server mit 500'er reagiert, solltest du das mit dem Provider klären oder wechseln.

Wenn dann immer noch der Blog mit der funktionierenden Version läuft, liegt es an den Berechtigungen für diese Datei. WordPress kann sie ggf. nicht ändern. Stelle die Berechtigungen per FTP Programm für diese Datei dann auf mindestens 644.

Das nennt sich "easter egg" und ist in so ziemlich jeder Software enthalten. Selbst im MS Office Packet gibt es eine 3D Engine, die einen Raum mit Entwicklerfotos zeigt

Bei WordPress kommt das "Osterei" immer dann zum Vorschein, wenn beide Radio Buttons nebeneinander stehen, also du die Version mit sich selbst vergleichen willst.

Kann ich leider nicht nachvollziehen. Wenn deine Admin Oberfläche sonst deutsch ist nur dort nicht, dann hab ich dafür leider keine Erklärung.

Zitat von h-u-g-o

Mir ist gerade noch Folgendes aufgefallen:

Wenn ich beim Erstellen eines Artikels bei "Sichtbarkeit: Öffentlich" auf "Bearbeiten" klicke, dort "Privat" auswähle und "OK" anklicke, stimmt bei diesem Vorgang etwas mit der Übersetzung nicht. Da wird dann, zum Beispiel, "Public", "Privately Published", "Update Post" und "Save Draft" anstatt der deutschen Begriffe angezeigt. :confused:

Welche Sprachdatei verwendest du ? Die von wordpress-deutschland.org oder die von wordpress.org ?
Und welche WP Version ist im Einsatz ?

Ich werd' es mal einfangen gehen
Das mit den Leerzeichen ist eine philosophische Frage, dafür gibt es Vor- und Nachteile, Befürworter und Gegner. Ich persönlich nehme lieber Tabulatoren, denn zum Beispiel bei Javascript Dateien (ohne Komprimierung) macht eine Einrückung mit einem Tab 1 Byte, 4 Leerzeichen aber eben 4 Byte = 3 Byte mehr.
Das Ganze mal 300 Zeilen Quelltest und im Mittel 3 stufige Einrückung, dann sind das 2700 Byte mehr als nötig. Beim Transfer zählen aber die Dateigrößen schon etwas, egal ob man "heisse" Luft transportiert oder nicht
Für die Scriptsprachen Parser gilt gleiches, wenn auch nicht so gravierend.

Zitat von h-u-g-o

War auch nicht so gemeint.

Das heißt, wenn ich in irgendwelchen php-Dateien von Plugins oder so auf Entitäten ( ä ö ü ß ) stoße, kann ich die getrost durch reguläre Umlaute beziehungsweise die Eszett-Ligatur ersetzen?

So einfach nun auch wieder nicht. Die PHP Datei sollte dann mit einem entsprechenden Texteditor im Format UTF-8 (ohne BOM) abgespeichert und hochgeladen werden.
Byte Order Mark ? Wikipedia
.:: NOTEPAD++ ::.
(nur als Vorschläge)

Ich war die letzten Wochen etwas sehr beschäftigt (deutlich ausgelastet) und bin erst seit ein paar Tagen wieder am Bloggen und WordPress Deutschlanden
Normal sollte seit WP 2.5.1 WordPress standardmäßig mit UTF-8 laufen. Deshalb besteht auch keine Notwendigkeit, Entitäten zu benutzen. Nur wenn man mit externen Programmen arbeitet wie Windows Live Writer bekommt man solchen "Schmu" in's Blog. Aber das kann man ja geziehlt behandeln (lassen).

Es gibt mehrere Gründe, warum sie nicht mehr geladen wird:
1.) Übertragungsfehler beim FTP upload (nicht im binär Modus hochgeladen -> Datei kaputt)
2.) Sie liegt nicht im Theme Hauptordner, denn so wie die Textdomain geladen wird, muß sie in diesen speziellen Theme im Hauptorder und nicht in einem seiner Unterpfade liegen.
3.) Du benutzt eines der vielen Mehrsprachigkeitsplugins, welches nur 2 stellige Sprachdateinamen versteht (de.mo statt de_DE.mo)
4.) in deiner wp-config.php steht unter WPLANG nicht 'de_DE'.

soviel erstmal dazu, kannst du das prüfen ?