Beiträge von codestyling

Alle deine Seitenaufrufe laufen durch einen ProxyServer durch und werden nicht von den eigentlichen Server geholt:

DateThu, 23 Sep 2010 12:02:12 GMT
Server Apache/2.0
X-Powered-By PHP/5.2.5
X-Pingback http://ferienwohnung.epilation-becker.de/wp_3_0/xmlrpc.php
Content-Type text/html; charset=UTF-8[COLOR=Red]
X-Cache[/COLOR][COLOR=Red] MISS from proxy2.kontent.com[/COLOR][COLOR=Red]
X-Cache-Lookup[/COLOR][COLOR=Red] MISS from proxy2.kontent.com:80[/COLOR][COLOR=Red]
Via[/COLOR][COLOR=Red]1.0 proxy2.kontent.com (squid/3.0.STABLE8)[/COLOR]
Connection close

Da solltest du deinen Hoster fragen, warum das überhaupt durch den Proxy gehen muß und warum dieser offensichtlich so träge ist, daß er 10sec braucht, um pro Antwort (HTML, Bild oder Javascript) durchzuleiten.

Zitat von oliverberlin79

plugins haben ja den nachteil, dass sie als wichtiger bestandteil der website oftmals versionsprobleme auslösen können.

Den Zusammenhang zu *.po/*.mo Dateien verstehe ich nicht. Wenn du mein Plugin meinen solltest, das ist nur ein Editor for *.po Dateien und stellt dann auf Knopfdruck die *.mo Datei her. Somit kann man sich jederzeit alles so anpassen, wie man es gern hätte. Und vor einem Update bringt man die eigenen Übersetzungen in Deckung (sollte man aber ja eh als Backup schon rumliegen haben), macht das Update, schiebt die Sprachdateien wieder hoch und ergänzt diese dann, falls nötig. Wenn man nicht gerade Übersetzungen modifizieren will, braucht auch mein Plugin nicht aktiv zu sein.

Solltest du das anders gemeint haben, dann erklär es mir bitte.

Zitat von oliverberlin79

Sprachdateien sind natürlich sinnvoll - aber diese könnten auch reine .php Dateien sein, wo man locker drin direkt verändern kann und nichts kompilieren muss.

Ist nicht ganz so einfach, wenn das Theme unter Multi Site Installation freiegegeben ist und jeder User (respektive) Unterblog seine eigene Sprache festlegen kann per Admin Einstellung. Dann muß man die korrekten Sprachdateien laden können, sei es WordPress selbst, Plugins oder Themes.

Der Sinn von Multi Site ist ja auch, mehrere Sprachen über alle Blogs bei 1 x Sourcecode (WP, Theme, Plugin) zu haben und zwar parallel. Mit PHP Dateien, die man erst mal rausfinden muß, welche davon jetzt nötig ist und deren Verbrauch, der höher liegen sollte, als es schon mit der Sprachdatei ist, wird das alles ein vergeudetes Unterfangen.

Und man kann sein Theme/Plugin nicht an ein Translation Team (oder einen bezahlten Übersetzer) geben, denn das Austauschformat *.po kann in deren Translation Systeme mit Translation Memory eingelesen und wieder exportiert werden, deine PHP Datei leider nicht.

Seite WordPress 3.0 sind die Import Module nicht mehr dabei sondern müssen als Plugin nachgerüstet werden. Der WordPress Importer ist hier: http://wordpress.org/extend/plugins/wordpress-importer/ und alle anderen kannst du hier finden: http://wordpress.org/extend/plugins/profile/wordpressdotorg

Es kann sein, daß die automatische Installation des Importers bereits scheitert. Wenn du allerdings schon das Plugin drauf hast und aktiviert, wäre ein Screenshot des Fehler mindestens mal interessant.

Schau dir am Besten Twenty Ten functions.php an und bau das entsprechend deinen Wünschen nach:

function twentyten_widgets_init() {
    // Area 1, located at the top of the sidebar.
    register_sidebar( array(
        'name' => __( 'Primary Widget Area', 'twentyten' ),
        'id' => 'primary-widget-area',
        'description' => __( 'The primary widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );


    // Area 2, located below the Primary Widget Area in the sidebar. Empty by default.
    register_sidebar( array(
        'name' => __( 'Secondary Widget Area', 'twentyten' ),
        'id' => 'secondary-widget-area',
        'description' => __( 'The secondary widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );


    // Area 3, located in the footer. Empty by default.
    register_sidebar( array(
        'name' => __( 'First Footer Widget Area', 'twentyten' ),
        'id' => 'first-footer-widget-area',
        'description' => __( 'The first footer widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );


    // Area 4, located in the footer. Empty by default.
    register_sidebar( array(
        'name' => __( 'Second Footer Widget Area', 'twentyten' ),
        'id' => 'second-footer-widget-area',
        'description' => __( 'The second footer widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );


    // Area 5, located in the footer. Empty by default.
    register_sidebar( array(
        'name' => __( 'Third Footer Widget Area', 'twentyten' ),
        'id' => 'third-footer-widget-area',
        'description' => __( 'The third footer widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );


    // Area 6, located in the footer. Empty by default.
    register_sidebar( array(
        'name' => __( 'Fourth Footer Widget Area', 'twentyten' ),
        'id' => 'fourth-footer-widget-area',
        'description' => __( 'The fourth footer widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) );
}
/** Register sidebars by running twentyten_widgets_init() on the widgets_init hook. */
add_action( 'widgets_init', 'twentyten_widgets_init' );

Dann kannst du im Child Theme auch weitere einzelne Sidebars auf die gleiche Weise dazufügen.
Ich bin davon ausgegangen, das du dein eigenes Basistheme und davon ein Childtheme erzeugt hast.

Ich teste im Moment noch die neue Bugfix-Version meines Plugins zu Ende, hab aber einen Weg gefunden, mit wenig Speicher auszukommen. Das nächste Update (geplant bis zum Wochenende) wird dann unter niedrigen Speicherbedingungen einen alternativen Modus bereitstellen, den man aktivieren kann.

Zu Thema Speicherverbrauch hab ich einen neuen Artikel verfasst, in dem ich versuche zu erklären, warum man öfter in solche Probleme rennt: http://www.code-styling.de/deutsch/memory…angsam-gewaltig

[COLOR=Black]Die Funktionen heißen: [/COLOR][COLOR=#000000][COLOR=#0000bb][COLOR=Black]dynamic_sidebar und [/COLOR][/COLOR][/COLOR][COLOR=#000000]register_sidebar[/COLOR][COLOR=#000000][COLOR=#0000bb][COLOR=Black] also ohne s am Ende und bekommt gesagt, welche sidebare es dort ausgeben soll. So gesehen kann dein Code nicht gehen, denn ich hab meinen Code ja auch ohne s hier geschrieben :wink:.[/COLOR]
[/COLOR][/COLOR]

Dann muß folgendes, angepasst auf dein Beispiel in den Header rein:

<?php if (!function_exists('dynamic_sidebar') || !dynamic_sidebar( 'k1' ) ) : ?>
    
<!-- hierhin das, was im Falle passieren soll, wenn niemand ein Widget reingeworfen hat -->


<?php endif; // end kopfbild widget area ?>

Sagen wir mal, ich baue ein Child Theme von Twenty Ten und möchte noch eine Sidebar zusätzlich haben. Dann sieht meine functions.php im Child Theme komplett so aus:

<?php     register_sidebar( array(
        'name' => __( 'CodeStyling\'s Widget Area', 'twentyten' ),
        'id' => 'codestyling-widget-area',
        'description' => __( 'My private widget area', 'twentyten' ),
        'before_widget' => '<li id="%1$s" class="codestyling-widget-container %2$s">',
        'after_widget' => '</li>',
        'before_title' => '<h3 class="widget-title">',
        'after_title' => '</h3>',
    ) ); ?>

Bei der Verwendung von Child Themes gibt es folgendes in Bezug auf die functions.php zu beachten, wenn das Child Theme aktiv ist:

1. es wird zuerst die functions.php des Child Themes von WordPress geladen
2. es wird anschliessend auch die functions.php des Basis Themes geladen.

Wenn du also eine 1:1 Kopie der functions.php in das Childtheme kopiert hast und dann dort noch die 3. Sidebar ergänzt hast, wird zuviel Code ausgeführt.

Im Child Theme solle man nur die zusätzlichen Sachen machen, die das Basistheme nicht schon mitbringt.

Sieht mir danach aus, als würde dein neuer Server mit

safe_mode = on

laufen und damit FTP erzwingen. Da du nichts weiter zum Server/Hoster geschrieben hast, kann ich nur empfehlen, das über die Hoster Config-Oberfläche abzustellen, wenn es geht.
Anderenfalls hier bitte noch ein paar Daten bereitstellen.

Meine Tests ergaben, dass ich mit 64MB und dem besagten Plugin dieses Plugin auch einlesen konnte. Ich hatte dazu eine WordPress 3.0.1 Installation (Normalbetrieb).

Da ich nicht weis, wie deine aktuelle Installation aussieht, ist es schwer, eine Analyse zu machen. Verwendest du WordPress als Multi Site Installation? Betreibst du zusätzlich BuddyPress oder Foren wie bbPress? Wie viele (und welche) Plugins laufen? Wieviel Speicher steht noch zu Ausführung von Programmcode zur Verfügung (und ich meine damit nicht den Festplattenplatz!)?

Ich würde erstmal untersuchen, ob mehr als 50% der Einträge in der ???_post Tabelle in der Spalte post_type vom Typ: revision sind und diese gandenlos löschen. Das bringt auf den meisten Datenbanken unheimlich viel Luft. Dann würde ich das Erstellen von Revisionen per wp-config.php und den dafür vorgesehenen Konstanten komplett deaktivieren.
Sonst fällt mir nichts weiter zur Verkleinerung ein.

Wenn du es in der Sprachdatei von WordPress nicht finden kannst, ist der Fehler vermutlich in der Sprachdatei des Themes enthalten.
Dann solltest du das dort ändern können.

Ich arbeite an einer Lösung dafür, hab aber noch keine richtige Idee, wie ich mit weniger Speicher auskommen soll. WordPress ist ziemlich fett gewordenund je höher die Anzahl der Plugins wird, umso wahrscheinlicher der Abbruch.
Mir perönlich schmeckt das auch nicht, mit einer WP 2.7 und zig Plugins aktiv kann ich auf einem Server mit nur 40MB bequem scannen, selber Server mit WP 3.0 ohne jedes Plugin = Abbruch.
Wenn ich eine Lösung dafür hab, erstelle ich ein neuen Forumseintrag.

Zitat von dsp77

Also dann Dein Plugin installiert codestyling. Wenn ich dann #wp ändern will, erhalte ich folgende Fehlermeldung:
Ihre Übersetzungdatei (*.po) unterstützt nicht die geforderte Textdomain Erweiterung.
Bitte lesen Sie die entsprechenden Quelltext-Dateien neu ein, um diese Funktionalität bereitzustellen.

Da mein Plugin mit mehr als einer Textdomain arbeiten kann, möchte es die Quelldateien (PHP Dateien) neu einlesen (nach Texten validieren). Das ist der Hinweise dazu. Allerdings benötigt man schon wie bereits als Warnung angezeigt, mindesten 58MB PHP Speicher, um das Einlesen durchführen zu können. Der Einlesen Linke steht in der Übersicht in der Sektion WordPress unter Aktionen. Nach dem Einlesen, sofern das bei dir geht, kannst du dann übersetzen.

Textdomain: Ist eine Angabe, die beschreibt in welchem Zusammenhang ein entsprechender Text übersetzt werden soll. WordPress benutzt beispielsweise "default" und wann immer ein Text aus dieser Domain übersetzt werden soll vom System, weiss das System, daß es aus der Sprachdatei von WordPress kommen muß. Ein Plugin wie BuddyPress benutzt eine Textdomain "buddypress" um zu sagen, daß es nur für solche Übersetzungen zuständig ist. Alle übersetzbaren Themes und Plugins haben jeweils ihre eigene, ganz private Textdomain.

Zitat von Jimi

Also pack ich die ru.mo des russischen Wordpress in meine laufende Version?

Ja, diese und alle weiteren Sprachdateien und Zusätze, die WP 3.0 braucht. Momentan sind das 3 Sprachdateien, eine php Datei für russisch und zusätzliche Stylesheets fürs Admin, wenn das auch russisch sein soll, soweit ich das noch im Kopf habe .

Zitat von Jimi

Es muss also auch eine russische Datei für mein Theme vorhanden sein?

Ja.

Zitat von Jimi

Heisst das, ich kann nur Themes verwenden, die auch eine russische Sprachdatei anbieten?

Genau so ist es, sonst stehen die Texte in english da, wie z.B. "read more".

Wenn du selbst dem Script (jQuery Komponente) die Anweisung gibst, nichts zu tun, wenn man klickt, ist die Frage danach natürlich schon sehr eigenartig:

<script type="text/javascript">
        $(function() {
            $("#navigation").lavaLamp({
                fx: "backout",
                speed: 700,
                [COLOR=Red][B]click: function(event, menuItem) {
                    return false;
                }[/B][/COLOR]
            });
        });
    </script>

Also entweder dann die richtige Aktion durchführen oder die Beschreibung der Javascript Klasse durchlesen, wie man die verwenden sollte.

Teile des Frontend werden aber aus der Sprachdatei von WordPress selbst ausgegeben, sodass diese auch zur Verfügung stehen muß in russisch.
Deshalb mein Hinweise darauf. Selbiges gilt auch für das Theme selbst, da braucht es noch eine russische Twenty Ten, wenn man das beispielsweise einsetzt.
Ohne diese Sprachdateien kann es im Frontend eine Mix aus englisch und Russisch geben, z.B. er "Home" Menü Eintrag kommt aus der WordPress Hauptsprachdatei!

Da würde ich mal die russische Version runterladen und die Sprachdateien von WordPress und Twenty Ten rausholen ;)

ru.wordpress.org

Alternativ kannst du das auch mit meinem Backend Plugin "WP Native Dashboard" runterladen lassen.