Beiträge von codestyling

Das ist kundenspezifisch und sicher in Handarbeit erstellt worden, wie man am Header sehen kann.

/*
Theme Name: FilmFreunde.tv
Theme URI: http://filmfreunde.tv/
Description: FilmFreunde.tv
Version: 1.0
Author: EINS[23].TV
Tags: fixed width, two columns, widgets
*/

Ich habe getestet, ob 40 MB ausreichen, bereits eingelesene Sprachdateien zu bearbeiten (übersetzen). Dies ist mit 40MB Limit problemlos möglich. Getestet mit einer frisch eingescanten de_DE.po sowie einer vollständig übersetzten de_DE.po Datei.

Es gibt Neuigkeiten zu diesem Thema. Ich hab ein lokales Testsystem aufgesetzt und dem PHP eine memory_limit = 40MB gesetzt. Danach hab ich sowohl einige Plugins/Themes gescannt als auch WordPress selbst.
Während aller Scanprozesse war nur WP 3.0.1, TwentyTen und mein Plugin aktiv, alle anderen Plugins waren deaktiviert.

Ergebnisse:
1.) alle getesteten Plugins ließen sich scannen.
2.) alle getesteten Themes ließen sich scannen.
3.) WordPress blieb wie beschrieben beim Scannen hängen.

Ursache:
Der Scanprozess braucht für WordPress selbst seit Version 3.0 von WordPress offensichtlich mehr Speicher, denn er knallt an das memory_limit.

Untersuchung:
Also hab ich das Limit schrittweise auf meiner Apache Installation erhöht und siehe da, ab [COLOR=Red]58MB[/COLOR] !!! geht das wieder wie gewohnt.

Lösung:
Es wird demnächst Version 1.99.2 meines Plugins geben, die nicht mehr einfriert aber dennoch nur mit einer Fehlermeldung den Scanprozess abbricht, wenn das Limit getroffen wird.
Im Moment habe ich keine Ahnung, warum sich dies so ab WP 3.0 äußert. Ich kann nur empfehlen, zum Scan von WordPress selbst mindestens die 58MB zu haben. In älteren WP Versionen hat dies nie ein Problem dargestellt.

Die Servereinstellungen sollten ausreichend sein. Damit bleibt bei einer Installation, die nur aus WP selbst, gtranslate und meinem Plugin besteht nur eine Unverträglichkeit mit qtranslate übrig.
Von qtranslate weiss ich bereits, das es mit verkürzten Sprachdateikennungen arbeitet, also "de.mo" statt "de_DE.mo". Deshalb sind die Sprachdateien, die mein Plugin erzeugt, auch nicht sofort einsetzbar sondern müssen dann umbenannt werden.
Bleibt mir nix anderes übrig, als ein System aufzusetzen und qtranslate zu aktivieren. Wenn ich das jedoch nicht reproduzieren kann, dann habe ich alle Optionen ausgeschöpft.

... Thread wird nach dem Test fortgesetzt, kann 1 bis 2 Tage dauern.

Ich bräuchte dann mal die Angaben zum PHP Memory, der seitens deines Hosters zur Ausführung von Scripts zur Verfügung steht.
Weiterhin wäre interessent, ob es ohne qtranslate funktioniert und qtranslate somit eine Unverträglichkeit für mein Plugin darstellt.

Wenn der betreffende User bereits eingeloggt ist, dann kannst du dir erstmal den User besorgen mit:

$actual_user = wp_get_current_user();

Dann kannst du auf die gewünschten Informationen des Users zugreifen wie:

echo $actual_user->user_nicename;

oder was du sonst gern da stehen hättest.

Bei deinem Theme müsste es sich um das käuflich zu erwerbende Theme "NewsCast" handeln. Bereits die Live Preview auf der Anbieterseite funktioniert nicht mit dem IE8 und auch nicht im Kompatibilitätsmodus als IE7.
Noch viel schlimmer ist es, daß dieses Theme den IE zum Ansturz bringt bzw. diesen komplett einfriert!!!

Da würde ich dringend deren Support kontaktieren und das reparieren lassen, da kann nur der Theme Anbieter was machen, fürchte ich.

Wenn das Frontend Arabisch aber das Backend aus Administrationsgründen in anderen Sprachen sein soll, dann würde ich in der wp-config.php auf Arabisch stellen und für das Backend mein Plugin WP Native Dashboard benutzen. Damit kannst du auf einfache Weise bestimmen, wie im Backend die Sprache erscheinen soll.
Und wer Arabische Texte schreibt, kann sich ja sein Backend auch auf Arabisch umschalten, siehe die 3 Möglichkeiten, die man dazu hat.

Na ja, der IE hat sich schon gebessert, allerdings immer noch Meilen davon entfernt, was man können sollte. Mit dem IE9 kann man ihn dann auch ernst nehmen, denke ich.
Viele Scripts kommen mit den Korrekturen, die sie für IE <= 7 gemacht haben im 8er nicht zurecht, weshalb Microsoft höchst persönlich dieses "Runterschalten" für IE8 bereitgestellt hat.

Wie man den IE8 in den Kompatibilitätsmodus zwingt, hatte ich schon bei diesem Beitrag geschrieben: http://forum.wordpress-deutschland.org/konfiguration/…html#post340538
Da muß der Besucher nicht nachhelfen, das macht dann der Browser selbst :lol:

Ist ein bekannter Bug bei Windows basierten Systemen und PHP 5.2.1: http://bugs.php.net/bug.php?id=40568
Sollte ab PHP 5.3 behoben sein.

Nur mal am Rande, ein Forensuche hätte das mit Sicherheit schon hervorgeholt oder ?
http://forum.wordpress-deutschland.org/design/74293-t…html#post340369

Unter Win7 mit beiden Patches öffnet sich der IE8 gleich im Kompatibilitätsmodus IE7 im Backend von WP. Mein Editor funktioniert jedoch mit beiden Modi: IE8 und IE7 Emulation.
Hast du mal alle Plugins deaktiviert (sofern das geht) und getestet?

Man kann den IE8 in den Kompatibilitätsmodus für IE7 zwingen, wenn man einen bestimmten META Eintrag im <HEAD> der Seite unterbringt.
Klingt zu technisch? Dann hier ein Beispiel mit der header.php aus dem TwentyTen Theme:

<?php
/**
 * The Header for our theme.
 *
 * Displays all of the <head> section and everything up till <div id="main">
 *
 * @package WordPress
 * @subpackage Twenty_Ten
 * @since Twenty Ten 1.0
 */
?><!DOCTYPE html>
<html <?php language_attributes(); ?>>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"  />
<meta charset="<?php bloginfo( 'charset' ); ?>" />
<title><?php
    /*

Es geht dabei um diese zusätzlich eingefügte Zeile:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"  />

Die muß! unbedingt direkt nach dem <head> in die Datei rein, würde sie später kommen, schaltet IE8 nicht mehr in den 7er Mode zurück.
Solltest du in deinem Theme auch hinzufügen und IE8 ist dann kein Problem mehr.

Soweit zum Frontend. Aber dein Problem ist das Backend. Dann bleibt nur eine Änderung in der /wp-admin/admin-header.php übrig:

<?php
/**
 * WordPress Administration Template Header
 *
 * @package WordPress
 * @subpackage Administration
 */


@header('Content-Type: ' . get_option('html_type') . '; charset=' . get_option('blog_charset'));
if ( ! defined( 'WP_ADMIN' ) )
    require_once( './admin.php' );


get_admin_page_title();
$title = esc_html( strip_tags( $title ) );
wp_user_settings();
wp_menu_unfold();
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" <?php do_action('admin_xml_ns'); ?> <?php language_attributes(); ?>>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"  />
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php echo get_option('blog_charset'); ?>" />
<title><?php echo $title; ?> &lsaquo; <?php bloginfo('name') ?>  — WordPress</title>
<?php

Hier ebenfalls die Zeile einfügen. Dann sollte auch der Editor mit IE8 gehen.

Wenn man mit der [COLOR=black]locale [/COLOR]Einstellung rumspielt, dann sollte man aber auch wissen, welche Pro und Contras es dazu gibt. In diesem Nachtrag werden auch Alternativen angeben, die WordPress mitbringt: http://www.code-styling.de/deutsch/php-fu…mmen-nicht-mehr

Der beste Weg ist, diesen Text in der WordPress Sprachdatei zu ändern. Dies geht am Besten mit meinem Plugin Codestyling Localization unten im Link angegeben.

Angefügt ist ein Screenshot, wie du das in der Sprachdatei finden kannst.
Bitte nur die mit [COLOR=Red]roten Kontext[/COLOR] markierten

• nav menu front page title
• nav menu home label

fürs Admin ändern wenn nötig, "Home" Eintrag selbst ist in TwentyTen angezeigt, in dein gewünschtes "Blog" ändern und die Sprachdatei neu speichern. Fertig ist die Laube.

Bei einem Update der WP Version dann wieder das gleiche Prozedere, wenn du das ohne zusätzlichen Code willst. Oder die Sprachdatei von WP "retten" und weiterbenutzen, wenn keine neuen Texte dazugekommen sind.

Eigene Anpassungen kannst du so leicht selbst vornehmen (sowohl WordPress als auch Plugins/Themes, die das unterstützen)

Schlichtes Design basierend auf TwentyTen. Man merkt deutlich die Fokusierung auf Bild- und Videomaterial bei der Farbwahl. Soweit alles ok.

Nun ein Punkt, der Geschacksfrage ist, aber du wolltest ja Feedback.
Optisch fehlt mir eine deutlich erkennbare Trennung wo ein Artikel aufhört bzw. der nächste anfängt. Außerdem ist zwischen dem Ende des Artikels und dessen Meta-Angaben (wie Komentare etc.) sooo viel Platz, das man meinen könnte, das wäre der Prolog für den nächsten Artikel. Hier sollte die Platzverhältnisse umgekehrt werden.

Zufrieden ?

Wenn duch schon auf meiner Seite warst, dann hättest du auch ein Dokument vom WordCamp 2009 finden können ;-) http://www.code-styling.de/deutsch/wordca…ls-pdf-download

Passt für WP 3.x immer noch, muss nur mal demnächst erweitert werden. Die Erweiterung ist aber für Themes in der Regel nicht relevant.

Wie ich an der angegeben Datei sehe, versuchst du WordPress selbst neu einzulesen. Wenn nur WP 3.0.1 und mein Plugin läuft, es allerdings nach 60 (respektive bis zu 79 Dateien abbricht, dann kann es sein, daß du für ein Einlesen von WordPress selbst zu wenig PHP RAM hast. Wieviel PHP Speicher sichert dir dein Hoster zu 16 / 32 / 40 / 48 / 64 oder mehr MB ?
Unter dieser Konstellation (nur WP und mein Plugin) gibt es keine andere für mich gültige und plausible Erklärung.

Hab im Blog schon die gleiche Anfrage bekommen und genauso beantwortet, wie jetzt hier.
Es wäre hilfreich, zu wissen, ob das System bereits online ist oder nur erstmal eine lokale XAMPP Installation. Und es ist wichtig, zu wissen, welche anderen Plugins noch aktiviert sind, denn meistens sind unsauber geschriebene Plugins die Ursache dieser Probleme. Ich hätte gern die Liste aller aktiven Plugins, auch per Mail möglich.