Beiträge von Webrocker

    das frontend geht?

    ich würde erstmal per ftp auf den server gehen und innerhalb von wp-content das pluginsverzeichnis umbennenen (zb "_plugins") oder ein neues verzeichnis "plugins_inaktiv" anlegen und alles aus dem plugins verzeichnis dorthin verschieben.

    wenn du dich dann wieder am backend anmelden kannst, kannst du nach und nach die plugins zurückholen und einzeln aktivieren, bis der fehler wieder auftritt, dann weisst du, welches plugin da probleme macht.

    wenn es auch ohne plugins nicht geht, dann müsstest du mal zugriff auf die errorlogs des server bekommen, um zu sehen, was los ist.

    gruss
    tom

    hi,

    du inkludierst eine komplette externe html-seite, mit head,body,html tags, das packst du in deine html-seite - somit ist der htmlcode deiner seite kaputt und der browser rendert die innere seite, die ja in sich wieder ein kompletter html-code ist.
    ich würde das in einen iframe packen, damit dein drumherum der seite erhalten bleibt.

    PHP
    <iframe src="http://wordpress.esoteric-events.eu/newsletterarchiv/" width="" height=""></iframe>

    width und height dann so eintragen, dass es in dein wordpress-layout passt.

    gruss
    tom

    PS: die unterschiedliche darstellung kommt daher, dass die nicht-existente

    "http://wordpress.esoteric-events.eu/newsletterarchi/"

    das 404-error-handling deines blogs auslöst, was offenbar die blogseite ausliefert; wenn man den link direkt aufruft, dann kommt ebenfalls die "richtige" ansicht.

    Hi,

    ich habe einen Post, dem ich 5 Bilder per Dateiupload zugewiesen habe. Diese erscheinen, wenn ich den shortcode

    Code
    [gallery]

    benutze. Ein sechstes Bild ist bereits in der Mediathek und soll ebenfalls in dieser Galerie erscheinen.
    Dafür ist laut Codex

    Code
    [gallery include="x,y,z"]

    geeignet, wobei x,y,z die IDs der gewünschten Attachments sind. Das sechste Bild hat die ID 231.

    Code
    [gallery include="231"]

    zeigt dieses Bild. Sobald ich aber eine oder mehrere IDs der Attachments, die hochgeladen wurden, angebe, werden nur noch diese angezeigt, das "extra"Bild wird ignoriert.

    Code
    [gallery include="231,236,237,238,239,240"]

    - nur die ursprünglichen 5 Bilder sind in der Galerie zu sehen.

    Hat jmd eine Idee, wo ich da nach dem Fehler suchen könnte?

    gruss + danke
    Tom

    Hallo,
    wenn bei Domainfactory-gehosteten WP 2.9.-Installationen beim Bildupload der Fehler "call to undefined function ctype_digit in..." erscheint, dann habt Ihr wahrscheinlich die "light" php-Edition, die DF bereitstellt, aktiviert. Umstellen auf "standard" und der Fehler ist weg.
    Schade, denn die "light" Version funktionierte bislang einwandfrei und verbraucht weniger Serverresourcen.

    Als nächstes versuche ich, statt hart die Datumsformatierung anzugeben, auf die Formatierung, wie sie in den Blog Settings angegeben wurde, zuzugreifen

    haha, Peace Of Cake, quasi :-)

    PHP
    function aktt_digest_title_dateformat( $post_data ){
        global $wpdb;
        $title = get_option('aktt_digest_title');
        $dformat = get_option('date_format');
        $post_data['post_title'] = $wpdb->escape(sprintf($title, date($dformat)));
        return $post_data;
    } 
    add_filter('aktt_digest_post_data','aktt_digest_title_dateformat');

    So gehts

    So, nach einigem Hickhack und try und error habe ich das hier

    PHP
    function aktt_digest_title_dateformat( $post_data ){
        global $wpdb;
        $title = get_option('aktt_digest_title');
        $post_data['post_title'] = $wpdb->escape(sprintf($title, date('d.m.Y')));
        return $post_data;
    } 
    add_filter('aktt_digest_post_data','aktt_digest_title_dateformat');

    in die functions.php meines Themes eingebaut und jetzt werden die Titel der Twitter-Tool Digests endlich auch ohne Eingriff in den Core des Plugins als deutsches Datumsformat angezeigt.
    Als nächstes versuche ich, statt hart die Datumsformatierung anzugeben, auf die Formatierung, wie sie in den Blog Settings angegeben wurde, zuzugreifen. Schaumer ma :-)

    Hast Du mal versucht mit den Query-Häppchen die "lahmleg" Option zu finden?
    Wenn es ein generelles Problem mit der DB oder dem Hoster wäre, müssten die anderen Blogs ja auch lahmen.
    Ein Variante wäre noch, über das Plugin-Verwaltungs Interface die Plugins nicht nur zu deaktivieren, sondern zu löschen. Wenn die Plugins sauber programmiert sind, dann räumen sie ihre Optionen aus der DB.
    Du verlierst aber alle Einstellungen - wenn Du die Plugins wieder installierst, musst Du alles noch mal eingeben...

    Hm... seit dem Update auf WP 2.8.3 werden die externen Feeds im Dashboard nicht mehr angezeigt, ich sehe aber auch keine Fehlermeldung.

    Wenn ich dann auf "konfigurieren" klicke, sehe ich die eingetragenen Feed-Adressen. Diese separat im Browser eingegeben, zeigen auch Ergebnisse.

    Klicke ich nun auf "Speichern", erhalte ich einen 500er Serverfehler und im error.log des Servers steht ...

    ... bei "eingehende Links" geklickt:

    Code
    Premature end of script headers: /[...]/wp-admin/index.php

    ... bei "developer blog" geklickt:

    Code
    Premature end of script headers: /[...]/wp-admin/index-extra.php

    Hat jemand eine Idee, was das sein könnte?

    Hallo,
    die neueste Version des Plugins TwitterTools hat offenbar einige Hooks, an die man mit einem eigenen Plugin andocken kann.
    Was mich bislang störte, die Formatierung des Datums ist hart mit date('Y-m-d') gecoded und ich musste die auf date('d.m.Y') ändern, damit die Digest-Posts ordentlich in meinem Blog erschienen.

    Nun finde ich im entsprechenden Bereich des Plugins folgendes (Zeile 391ff):

    Ich vermute (?), dass man an dieses "aktt_digest_post_data" ran kann, um extern, z.B. in der functions.php des Themes, auf $post_data['post_title'] einzuwirken.

    Wie ist da die richtige Syntax?
    Wäre sowas in der functions.php der richtige Ansatz:

    Code
    function aktt_title_dateformat(){
        $post_data['post_title'] = $wpdb->escape(sprintf($title, date('d.m.Y')));
    }
    add_filter('aktt_digest_post_data','aktt_title_dateformat');

    ^---- ich muss der Funktion doch irgendeinen Parameter übergeben, wäre das $post_data oder was anderes?
    Ist das mit add_filter an der Stelle richtig oder müsste das add_action sein?

    Danke für Hinweise,
    Tom

    hi,
    in diesem Fall wird das nichts bringen, weil Du die (vermutlich) aufgeblähten Options mit in die neue Installation re-importieren würdest.
    Kannst Du über phpMyAdmin mal die Query, die so lange braucht reproduzieren?

    Code
    "SELECT option_name, option_value FROM [hier den namen deiner options tabelle (zb wp_options)] WHERE autoload = 'yes' LIMIT 0,10"

    Das Limit dann verändern,
    LIMIT 9,10
    LIMIT 19,10
    usw...
    mit den 10er häppchen solltest du die gruppe der optionen finden, die so lange braucht, diese kannst Du dann noch feiner "anfragen", bis Du die "schuldige" Option gefunden hast.

    Dies bedeutete (wenn es denn relevant wäre) auch, dass nur Bilder zum Upload mit max 1200px zugelassen würden.


    öhm, nö, das bedeutet, dass keine größeren Bilder auf dem Server geseichert werden, sondern vorher schon auf die Maße verkleinert werden, was Speicher verbraucht.
    Warum nun einmal die image.php und einmal die media.php zuviel Speicher beansprucht, kann ich Dir nicht sagen, aber dass da irgendwas mit Deinen hochgeladenen Bildern serverseitig angestellt wird und dabei mehr Speicher benötigt wird, als php derzeit zugewiesen ist, ist eindeutig.
    Also muss Du versuchen, php mehr Speicher zuzuweisen, das ist in dem oben verlinktem Artikel beschrieben.
    Ich würde mir keinen all zu großen Kopf machen, warum es bei einem Bild klappt und bei einem anderen nicht; Du weisst ja nicht, was im MOment des Uploads und dem Erzeugen der tempDateien zur Kleinrechnung und so alles noch gerade auf dem Server mit php angestellt wird, dh der "Schwellenwert", ab dem zuviel Speicher benötigt wird, schwankt.

    Danke für den Tipp !
    Leider hat dies gar nichts damit zu tun.
    Denn es geht nicht um Dateigröße, sprich: Limit, sondern um eine (scheinbare) Begrenzung der Pixelgröße des upzuloadenden jpgs.


    Hast Du das gegengecheckt? Ein (Dateigröße)mässig gleiches Bild, mit anderen Maßen funktioniert?
    Ich kann bei mir problemlos auch breitere Bilder hochladen/einbinden.
    Die Fehlermeldung deutet darauf hin, dass beim Verarbeiten des Bildes der Speicher zu eng wurde, wobei bei Upload mit gelichzeitigem Kleinrechnen des Bildes mal mindestens die doppelte Bilddateigröße im Speicher verbraucht wird.
    Könnte also sein, dass vielleicht Bilder, die kleiner als 1500px Breite aufgrund einer Voreinstellung in Deinem Blog nicht kleingerechnet werden, und deshalb durchgehen, während 15001px modifiziert werden muss und dafür der Speicher nicht mehr langt, selbst wenn das 1500px Bild eine größere Datei hat...

    Moin,
    Deine Version ist 2.6.3, das siehst Du im Quelltext zb der Startseite[FONT=monospace]
    [/FONT]

    Zitat

    <meta name="generator" content="WordPress 2.6.3" />

    Da der Unterschied zur aktuellen Version 2.8.3 zwei "große" Nummern ist (-> .7 -> .8, hat sich bestimmt auch etwas in der Struktur der Datenbank verändert, deshalb würde ich empfehlen, zwei Updates zu machen, erst auf 2.7.1 und dann auf 2.8.3, und dazwischen mal die wp-admin des Blogs aufzurufen, damit die DB aktualisiert wird.
    Wie man stressfrei (manuell) updaten kann, habe ich in meinem Blog beschrieben.
    Wichtig: Immer vorher ein Backup der Datenbank machen; ein Backup der Dateien, die für die Individualität des Blogs zuständig sind (verwendetes Theme, Plugins, Uploads etc), kann auch nicht schaden.

    die probleme hatte ich doch vorgestern noch nicht, und ich habe gar nichts geändert..


    schwer zu sagen. kannst du über phpMyAdmin oder das backend des providers oder zb mithilfe des wp-db plugins (http://wordpress.org/extend/plugins/wp-dbmanager/) die Tabellen ansehen und ggf optimieren/reparieren?
    Es gibt auch ein Plugin mit dem man die Options Tabelle von verwaisten Einträgen säubern kann (http://wordpress.org/extend/plugins/clean-options/), das habe ich aber noch nicht ausprobiert...

    hi oli,

    Zitat


    wpdb->get_results() -> Query time: 38985.0662 (ms)

    sagt nur, dass irgendeine Query ewig lange in der db rumrödelt.

    in der wp-includes/functions.php (die hat bei mir über 3000 zeilen) auf zeile 455 steht

    Code
    if ( !$alloptions_db = $wpdb->get_results( "SELECT option_name, option_value FROM $wpdb->options WHERE autoload = 'yes'" ) )
                $alloptions_db = $wpdb->get_results( "SELECT option_name, option_value FROM $wpdb->options" );

    ich würde sagen, irgendwas ist in der options tabelle, was Dein blog ausbremst...

    gruss
    Tom

    anscheinend hat Du Deinem Blog noch keinen Namen gegeben, denn in dem oben verlinkten Theme taucht auch im Titel des Browserfensters nichts auf.

    Da wo jetzt der Strich steht und verlinkt ist, müsste wahrscheinlich (ist jetzt nur eine Vermutung) der Blogtitel und evtl Untertitel auftauchen.
    Wenn Du das raus haben willst, musst Du in der header.php des Themes nachschauen.