Beiträge von Putzlowitsch

    "Homepage Basic" klingt nach einem äteren 1&1-Paket. Da könnte es sein, das der PHP-Speicher auf etwas mehr als 30M begrenzt ist. Das aktuell günstigste Paket "Dual Starter" für € 3,99 hat immerhin 60 MByte nutzbaren PHP-Speicher.

    Wenn bereits 26.3 MByte von effektiv nur 30 Mbyte belegt sind, kann es beim Bilderuplaod tatsächlich auch schon bei kleineren Bildern eng werden. Du kannst mal versuchsweise das Plugin "123 Image Resize" testen, ob es das Problem behebt.

    Ansonsten bleibt wohl nur ein Paket- oder Webhosterwechsel als Lösung, was in Anbetracht des alten Paketes ohnehin irgendwann notwendig wird.

    Den wirklich zur Verfügung stehenden Speicher kannst Du übrigens mit dem Plugin WP System Health testen.

    Gruß
    Ingo

    Wordpress muß zwischen Kategorien und anderen Dingen unterscheiden können. Bei Deiner ersten Konfiguration hattest Du festgelegt, das Kategorien mit /blog/ beginnen. Da aber auch die Artikel so anfangen, ist Wordpress davon ausgegangen, daß es sich beim Aufruf eines Artikels um eine Kategorie handelt, die es aber so nicht gibt.

    Die Kategorie-Basis muß nicht unbedingt /kategorie/ heißen, sie muß sich aber vom Anfang der Permalinks der normalen Artikel unterscheiden. Denkbar wäre auch etwas wie /kat/ oder bei Dir dann z.B. /blog/kat/.

    Es gibt auch einen Trick, wie man das ganz wegbekommt, der aber nicht immer funktioniert:
    https://faq.wpde.org/kategoriebasie…-url-entfernen/

    Du kannst ja mal probieren, ob bei Dir /blog/./ als Kategorie-Basis funktioniert.

    Gruß
    Ingo

    Ich habe für mich die Lösung, wie in diesem Thread weiter unten beschrieben, gewählt:
    http://forum.wpde.org/allgemeines/10…e-im-busch.html

    Das funktioniert so richtig aber nur, falls es sich um einen Ein-Mann-Blog handelt bzw. man immer nur über einen oder einige wenige Internet-Provider zugreift. Dann ist diese Variante wirklich sehr effektiv. Bei mir sieht der Eintrag in der .htaccess z.B. so aus:

    Code
    <Files wp-login.php>
    deny from all
    Allow from .superkabel.de
    </Files>

    Einfach, aber wirkungsvoll. Seitdem ist Ruhe mit den Login-Versuchen. :)

    Gruß
    Ingo

    Wenn Kommantare für einen Artikel deaktiviert sind, werden alle Versuche, einen Kommantar zu posten, von WP abgewiesen. Für die Kommentarverarbeitung ist die Datei wp-comments-post.php im WP-Wurzelverzeichnis zuständig. Ab Zeile 34 findet man dort folgenden Code:

    PHP
    if ( !comments_open($comment_post_ID) ) {
        do_action('comment_closed', $comment_post_ID);
        wp_die( __('Sorry, comments are closed for this item.') );


    Die Funktion comments_open fragt für die Post-ID das Feld 'comment_status' ab und gibt nur dann true zurück, wenn dort 'open' steht. Bei einem Artikel, bei dem die Kommentare deaktiviert sind, ist das nicht der Fall und so wird Wordpress an der Stelle mit wp_die beendet.

    So sieht zumidest der normale Ablauf aus.
    Entweder, die vermeintlichen Kommentare sind eigentlich Track-/Pingbacks oder ein Plugin/Theme greift irgendwie in der normalen Ablauf ein.

    Gruß
    Ingo

    Der zuständigen Klasse wurde noch gar kein Style zugeordnet. Probier mal folgende, neue Einträge in der CSS-Datei:

    HTML
    .post-title { font-size:1.75em; color:green; }
    .post-title a { color:green;}
    .post-title a:hover { color:lightgreen;}

    Die Werte sind natürlich nur Beispiele.

    Sofern Du eine neue Version des Firefox verwendest, brauchst Du eigentlich auch kein Firebug mehr. Da gibt es bereits ganz gute Werkzeuge direkt integriert.

    Der Klick mit der rechten Maustaste auf eine Element der Webseite zeigt auch die Option "Element untersuchen" an. Damit gelangt man zum HTML-Baum und sieht rechts die aktuell auf das Element wirkenden Formatierungen.

    Gruß
    Ingo

    Die Optionen "Erlaube Besuchern neue Artikel zu kommentieren" und "Erlaube Link-Benachrichtigungen von anderen Weblogs (Pingbacks und Trackbacks)" bei "Einstellungen › Diskussion" sind nur die Voreinstellung für neue Artikel.

    Du mußt aber tatsächlich bei allen schon bestehenden Artikeln und Seiten die beiden Optionen extra deaktivieren. Das meinte am3 wohl mit den "bulk actions".

    Wenn die Kommentare und Trackbacks/Pingbacks für einen Artikel deaktiviert sind, werden von Wordpress dann tatsächlich keine Kommentare mehr entgegengenommen. Es kann aber immer noch sein, daß sich ein Plugin dort einhängt und die Einstellungen außer Kraft setzt.

    Gruß
    Ingo

    Wobei es bei den Plugins einfacher sein könnte, diese jeweils einzeln zu deaktivieren und dann immer zu prüfen, ob der Fehler noch auftritt. Es könnte ja auch eine in der Datenbank gespeicherte Option sein, deren Inhalt im PHP-Quelltext nicht auftaucht.

    Und wenn ich mich recht entsinne, war das Default ja groß geschrieben, auf das umgeleitet wurde. Wenn Du in den Dateien mit Berücksichtigung der Groß-/Kleinschreibung mach Default suchst, könnte es übersichtlicher sein. Denn default in Kleinschreibung taucht doch recht häufig in Plugin- bzw. Theme-Dateien auf.

    Viel Erfolg :)

    Gruß
    Ingo

    Gut, wenn in der .htaccess nichts zu finden ist, kann es fast nur noch in einem Wordpress-Plugin oder den Dateien des Themes zu finden sein. Du könntest in den entsprechenden Dateien mal nach der Zeichenkette default suchen. Viel mehr fällt mir nun fast wirklich nicht mehr ein.

    Gruß
    Ingo

    Liegt das Wordpress im Wurzelverzeichnis des Webspace oder in einem Unterverzeichnis?
    Falls in einem Unterverzeichnis, dann könnte sich auch Einstellungen in der .htaccess des übergeordneten Verzeichnisses auswirken. Vielleicht die "Reste" der alten Seite oder so.

    Gruß
    Ingo

    Claudia18
    Ja, etwas anderes sagt die Fehlermeldung eigentlich nicht aus:

    Zitat

    "WordPress-Datenbank-Fehler Table 'db11140791-geburt.wp_postmeta' doesn't exist für Abfrage
    SELECT COUNT(meta_id) FROM wp_postmeta WHERE meta_key='_menu_item_menu_item_parent' AND meta_value='114' ..."


    Das muß aber nicht bedeuten, daß die Tabelle an sich fehlt. Vielleicht heißt sie nur anders, z.B. 'wp1_postmeta', falls ein anderes Datenbanktabellen-Präfix (in der wp-config.php) verwendet wird.

    In der Funktion check_for_submenu des Themes wir in der SQL-Abfrage wp_postmeta und nicht wie üblich $wpdb->postmeta verwendet, was zu Problemen bei geändertem Präfix führt.

    Der Parameter [FONT=courier new]max_allowed_packet[/FONT] hat damit nichts zu tun.

    Gruß
    Ingo

    ...
    Nach Studium der Fehlermeldung vermute ich (sehr vage), dass Du [FONT=courier new]max_allowed_packet[/FONT] auf einen höheren Wert setzen solltest.
    ...

    Kannst Du bitte mal kurz erläutern, wie Du auf diese, wenn auch nur sehr vage Vermutung kommst?

    Meiner Meinung nach sagt die Fehlermeldung nur, das die Tabelle 'db11140791-geburt.wp_postmeta' nicht existiert und das bei einer nicht allzu komplexen Abfrage:

    SQL
    SELECT COUNT(meta_id) FROM wp_postmeta WHERE meta_key='_menu_item_menu_item_parent' AND meta_value='114'

    Wie der Fehler zustande kommt, kann ich aber auch nicht sagen.

    Gruß
    Ingo