Beiträge von codestyling

Nun mal nicht so ungeduldig, hier bekommt niemand Geld für den Support, ist alles freiwillig.

Die Zeilenangaben des Validators beziehen sich immer auf den im Browser angezeigten HTML Quelltext, kannst du dir im Browser aufrufen. im Falle der Zeile 58 mit dem UL ist das dies hier:

<li> 
      <h2> 
        <a href="#" title="Archive" onclick="showhidelayer('subcat3');">Seiten</a>
      </h2>
[COLOR=Red]      <ul id="subcat3" style="display:none; margin:0px; padding:0px;">
              </ul>
[/COLOR]    </li>

Dies ist leer und entspricht nicht der Definition. Den onclick hast du offensichtlich eingebaut, also wirst du das auch finden. Die weiteren Fehlern sucht man auf die gleiche Weise im Quelltext und danach im entsprechenden Template, um sie zu korrigieren.

Der Artikel ist ja noch da: Page 62 - Blogalltag findest du in der Übersicht. Allerdings hat der 1000 Kommentare !
Es kann auch ein Problem mit der Anzahl der Kommentare sein oder ein Spam-Eintrag dabei sein, der das verursacht.

Das sieht nach einer kaputten oder leeren Sprachdatei aus. Kannst du die deutsche Sprachdatei nochmal per FTP im Binär Modus hochladen (Download findest du oben in der Leiste) ?

Siehe meine Antwort hier, liegt am Theme. Habe schon in einigen Themes diese Fehler gefunden: http://forum.wordpress-deutschland.org/plugins-und-wi…html#post222225

Genau diese Art Fehler hab ich auf dem WordCamp in der Session zu Theme Lokalisierung demonstriert.
In den meisten Fällen wird einfach der Text entfernt nicht aber die ganze Übersetzungzeile: Wenn dann so etwas im Theme zurückbleibt, dann gibt das den Header der Sprachdatei aus:

<?php _e(''); ?>

einfach dann den gesammten _e("") oder __("") entfernen statt nur den Text rauszuwerfen.

Das Lighbox-Problem taucht im Firefox nicht auf, dort funktioniert das. Im IE allerdings nicht, das liegt an dem Script selbst. Das ist eine Version des Scripts der Lighbox, die ich schon gepatched hatte. Sollte in einem Anhangs hier im Forum noch existieren.
Wenn ich wieder Zugriff auf meinen Heimrechner habe, kann ich das mal raussuchen, ist ein IE Bug im Script. Hat der Autor etwas so benannt, wie es der IE bereits kennt und und nicht überschreiben lässt und bricht daran ab.

Normalerweise findest du im Hauptorder von WordPress einen .htaccess Datei mit folgenden Inhalt (Standard):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# END WordPress

Die Variante mit der Angabe in der .htaccess Datei wäre dann:

[COLOR=Sienna]php_value memory_limit 64M[/COLOR]


# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


# END WordPress

Die Variante mit dem php Code würde ich in der wp-config.php direkt hinter den Datenbankangaben einbauen.

ini_set('memory_limit', '64M');

Bei der .htaccess Variante könnte der Server sofort einen error 500 liefern, falls der Provider das nicht unterstützt, dann wieder rückgängig machen und per PHP versuchen.

Ergänzung zu manuell hochgeladenen Bildern:
Das Hochladen trägt die URL's der Bilder bzw. Pfade in die Datenbank ein und WordPress zeigt dir später nur die, die auch in der DB verzeichnet sind. Pur hochgeladene Bilder stehen aber nicht in der DB, deshalb zeigt WP die nicht an.

Sieht nach einem Sprachdatei-Problem aus, denn Feeds brauchen hier unbedingt reinen UTF-8 Text. Das sind bestimmt noch Altlasten aus älteren Übersetzungen und gehören geändert.

Leider ist WP ziemlich "dick" geworden. Die Core-Dateien + aktivierte Plugins + Sprachdatei von WP (braucht selbst bis zu 4MB im PHP RAM) summieren sich in der internen Parser-Zerlegung schnell auf diese Größe. Und Nextgen oder ähnliche sind auch einige dieser Brocken, denn diese fordern auch noch die GD Lib an, die sonst nicht (unbedingt) geladen ist.

Dann kommt noch ein Bild daher mit 1024x768px was durch GD intern in voller epischer Breite 1024 x 768 x ( r + g + b + a) = 3145728 bytes Minimum braucht, wenn es geladen wird. Die Konvertierung dessen benötigt dann nochmal Puffer und Bildplatz für das Thumb, was in Summe an diese 3MB nochmals rankommt. -> sind schon 6 von 12 MB weg mit einem Bild in der Konvertierung. Wenn dann noch andere Daten wie der rohe base64 Stream des Bild-Uploads im Speicher hängt (ist ja dicker als das Bild selbst groß ist wegen der Codierung) dann wird's verdammt eng.

Ich erschrecke mich auch immer, wenn die meine lokale XAMPP (Windows) Speicherbenutzung ausgeben lasse (eigene Erweiterung, kann PHP unter Windows sonst nicht) -> 45MB im Ruhezustand!
Unter Unix ist das weniger, denn Windows zählt ja die DLL's usw. mit während unter Linux nur nachgeladen Bibliotheken (wie GD z.b.) einen Einfluss auf den Speicherverbrauch haben.

Eine Erhöhung des Limits würde ich erstmal testen, wenn das nix ändert, mal mit der Provider sprechen. So um 40 - 64 sollten bei Nextgen und Bildern reichen (vorausgesetzt, du willst nicht 50 solche Images am Stück hochladen und thumbnailen, das kann nach hinten losgehen)

Kannst ja mal eine kleine Anfrage im Bundestag machen ... :)

Spass beiseite, nach Angabe deines PHP Speicher limits von 32 MB und einer bereits vorliegenden Auslastung auf der einfachen Seite mit den Optionen von 19,79MB hast du noch 12 MB "Luft" für zusätzlichen PHP code, Sprachdateien und Bilddaten.

Da du keine Angabe zu den Bildgrößen (Originalgröße) und deren Anzahl beim Upload gemacht hast, kann es sein, das du ans Ende deines Speicher Limits stößt.

Hier eine brauchbare Übersicht, wie man das erhöhen könnte: PHP: Memory Limit erhöhen | Julius Beckmann

Zitat von michael.oeser

SELECT wp_prinzposts.* FROM wp_prinzposts WHERE 1=1 AND wp_prinzposts.post_parent = 262 AND (post_mime_type LIKE 'image/%') AND wp_prinzposts.post_type = 'attachment' ORDER BY [COLOR=Red],[/COLOR]wp_prinzposts.ID DESC

Was soll das Komma nach dem ORDER BY ?
Fehlt ein Term oder hast du ein Komma da reingefummelt ?
So weiss die ORDER BY nicht, was sie soll und der SQL Parser meckert dann den Nachfolgenden Term als Bezug an.

Vielleicht hilft dir ja diese Beschreibung von mir weiter aus einem älteren Thread: http://forum.wordpress-deutschland.org/konfiguration/…html#post187277
Ich denke, es ist ein Konfigurationsproblem. Falls du den XAMPP nicht auf Port 80 betreibst, dann brauchst du die Portnummer eben auch noch in der Backend-Einstellung bei der URL zusätzlich (nur als Erweiterung).

Bau mal folgenden Aufruf in deine wp-config.php ein:

[COLOR=#000000][COLOR=#0000CC]set_magic_quotes_runtime[/COLOR][COLOR=#006600]([/COLOR][COLOR=#0000CC]0[/COLOR][COLOR=#006600]);  [/COLOR][/COLOR]

direkt nach den DB Definitionen.

Evtl. gibt s ja in der neuen XAMPP Version (hab selbst eine ältere) das Problem mit den Sprachdateien durch die Standardeinstellung. Auch Foren sind bekannt dafür, o.g. Einstellung anzuschalten.

Zitat von lulula

Ich habe mit Page Columnist versucht zu arbeiten, aber seit heute gibt es Probleme (2.7.1) versuchs mal.

Also ich hab PageColumnist geprüft und ich kann keine Probleme feststellen, kannst du das näher beschreiben ?
Und dieses Plugin ist nur für Seiten aber nicht für Artikel gedacht, deine Blogbeiträge lassen sich damit nicht in Spalten bringen.

Nicht so hastig, ich feile nebenbei noch an meinem WordCamp Vortrag :-D

Also Umleitung von domain/blabla/ nach WordPress 404

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^blabla/(.*)$ /index.php?war_mal=$1 [QSA,L]
</IfModule>

mit dem war_mal im $_GET kannst du ggf. dann noch was veranstalten, wenn du willst. Dieses vor den WP Block reinschreiben.

Den Ordner in wp-includes gab es mal, es sind Altlasten der Versionen WP <= 2.3 ! Ab höheren Versionen wurde das für besseres Backup dort rausgeholt und in wp-content gelegt, damit man den wp-content einfach zippen kann und fertig.
Nichtsdestotrotz enthält der WordPress Core eine "Fallback" Suche im wp-includes, falls es im neuen Sprachdatei Ordner in keine passende Sprachdatei finden kann.

Demzufolge bei einer WP 2.7.x:

1. den language Ordner unter wp-includes löschen (samt Inhalt)
2. den languages Odner unter wp-content anlegen
3. dort hinein die Sprachdatei de_DE.mo (so geschrieben! uploaden)

Dann solltest du deutsch bekommen, wenn in deiner wp-config.php auch WPLANG auf de_DE steht.

Nur nochmal, damit ich das richtig verstanden hab, zusammengefasst:

1. eine externe Seite X verweist auf domain/blabla.html die es nicht mehr gibt
2. eine externe Seite Y verweist auf domain/blablub/ also implizit index.php oder index.html, wobei es den Order an sich noch gibt aber den Inhalt nicht.

Hab ich das so korrekt zusammengefasst ?

Wenn das, auf was verwiesen wird, physisch existent ist, kann man das zwar hart umleiten, dann kannst du das aber nie mehr aufrufen, liegt dann tot rum.

Dann erklär doch mal, was genau von wo nach wo umgeleitet werden soll.
Ist das, wohin umgeleitet werden soll keine Seite von WP ?

Meinst du diesen [COLOR=Red]Redirect[/COLOR] ?

# BEGIN WordPress
<IfModule [URL="http://forum.wordpress-deutschland.org/lexikon/?do=showentry&item=mod_rewrite"]mod_rewrite[/URL].c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
[COLOR=Blue]RewriteRule . /index.php [L][/COLOR]
</IfModule>
 
# END WordPress
 
# Force www
[COLOR=Red][B]RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L][/B][/COLOR]

In der blauen Zeile ist für nicht real existierende Dateien bereits Schluss, denn alles, was nicht physisch vorliegt, wird der index.php vorgeworfen. Diese findet logischerweise auch nix und gibt 404 zurück.

Der rote Block gehört wenn schon vor den WordPress Block.

Also in diesem Thread wurden 2 verschiedene Plugins genannt, es ist im Eingangspost eine andere Download URL als ich hier angegeben hab.
Das von mir vorgeschlagene Plugin wird von einem der Mitentwickler von WordPress gepflegt und arbeitet ziemlich zuverlässig.

Wenn dieses von mir vorgeschlagene Plugin aktiviert ist , solltest du unter "Einstellungen" einen Menüpunkt "TinyMCE Advanced" haben. Dort kannst du den Editor so konfigurieren (per Drag and Drop) wie du die Funktionen in den 4 möglichen Editorleisten gern hättest. Dann bekommst du bei Schreiben auch mehr Buttons und Funktionen ganz nach deinen Wünschen.

Es geht nur mit einem Plugin, sonst müsste man am Core Code rum fummeln. Man könnte es ein schmaleres Plugin schreiben, aber es bleibt das Problem der Buttonverteilung auf die Leisten! Wollte man alle Funktionen in eines Leiste haben, braucht das alles locker mal 4000px Breite, das geht also so nicht.

Seit 2.6 ging der der Flash-Upload mit dem Flashplayer 10 nicht mehr, erst ab WP 2.7 kann man wieder Flash-Uploads benutzen mit dem 10er.
Wenn du selbst hostest, wird die betreffenden Seite "geframed" sprich in einem Frame zum Verstecken der URL geliefert ? Wenn ja, dann ist das Problem die "same origin policy" der Browser, das Uploaden wird dann von Browser bereits unterbunden.
Wenn nicht, dann findet WP u.U. keinen geeigneten Temp-Pfad, in den es die File-Uploads schreiben darf. Dann dürfte allerdings auch ein automatischer Update von Plugins bei dir nicht gehen ?