it-swarm.com.de

Wordpress Custom Post Type Admin-Seite sehr langsam

(Ich habe dies auf dem normalen Stapelaustausch gepostet, aber es wurde vorgeschlagen, es auch hier abzulegen. Ich bin froh zu wissen, dass dieser Ort existiert ... :))

Also habe ich im ganzen Internet versucht, herauszufinden, was mit ein paar Websites, die ich besitze, vor sich geht, und ich glaube, ich habe es endlich geschafft, es aufzuspüren ...

ABER

Ich möchte zuerst sicherstellen, dass ich alles richtig mache, bevor ich zu Wordpress gehe und vorschlage, dass es einen kleinen Fehler gibt, der mich und möglicherweise ein Bündel anderer nervt.

Der Kern des Problems ist, dass ich mehrere Wordpress-Sites (WP 3.5.1) besitze, auf denen benutzerdefinierte Artikel vom Typ "Produkte" enthalten sind. Ich habe den benutzerdefinierten Beitragstyp wie folgt definiert:

/* Create custom Products taxonomy */
function create_custom_products_taxonomies() {
register_post_type( 'products',
    array(
        'labels' => array(
            'name' => __( 'Products' ),
            'singular_name' => __( 'Product' ),
            'add_new' => __( 'Add New' ),
            'add_new_item' => __( 'Add New Product' ),
            'edit' => __( 'Edit' ),
            'edit_item' => __( 'Edit Product' ),
            'new_item' => __( 'New Product' ),
            'view' => __( 'View Product' ),
            'view_item' => __( 'View Product' ),
            'search_items' => __( 'Search Products' ),
            'not_found' => __( 'No products found' ),
            'not_found_in_trash' => __( 'No products found in Trash' ),
            'parent' => __( 'Parent Product' )
        ),
        'public' => true,
        'hierarchical' => true,
        'menu_position' => 20,
        'publicly_queryable' => true,
        'query_var' => true,
        'rewrite' => array("slug" => "/products", "with_front" => false),
        'supports' => array('title', 'author', 'thumbnail', 'editor', 'excerpt', 'comments', 'page-attributes', 'common', 'custom-fields', 'revisions'),
        'register_meta_box_cb' => 'products_meta_box',
        'taxonomies' => array('products')
    )
);
register_taxonomy(
    'products',
    'products',
    array(
        'hierarchical' => true,
        'label' => __(ucfirst('products')),
        'show_in_nav_menus' => true,
        'rewrite' => array('slug' => 'categories')
    )
);
}
add_action('init', 'create_custom_products_taxonomies'); // Create the necessary custom taxonomies for products

Das Problem tritt auf, wenn ich versuche, auf die Listenseite für diesen benutzerdefinierten Beitragstyp zuzugreifen. Die analoge Seite für Posts ist "Posts" in der Admin-Seitenleiste auf der linken Seite einer Admin-Seite. Der Name der Seite, die ich für meine benutzerdefinierte Beitragstypauflistung habe, lautet entsprechend "Produkte". Wenn Sie auf diese Seite zugreifen, wird ein buchstäbliches ALTER benötigt, um geladen zu werden. Okay, es sind also wirklich ungefähr 8-12 Sekunden von Laden zu Laden, wobei jede andere Seite auf der Admin-Seite in ungefähr 1-2 Sekunden geladen wird. Darüber hinaus tritt auf der Seite häufig eine Zeitüberschreitung auf, und der allgemeine Fehler "Dienst ist vorübergehend nicht verfügbar" wird ausgegeben. (Nicht sicher, woher dieser Fehler kommt. Apache, Wordpress, etc)

Dieses abweichende Verhalten veranlasste mich, die Administratorseite meiner Website zu testen und zu debuggen. Ich habe die Plugins "Debug Bar" und "Debug Bar Extender" gefunden. Wenn ich diese Plugins gleichzeitig verwende und die entsprechende Seite geladen habe, kann ich die Abfrage für diese Seite anzeigen, aber die Abfrageargumente sind in diesem Fall der wichtigere Vergleich:

- für die Posts Listing Seite -

post_type = post & posts_per_page = 400


- für die Produktlistenseite -

order = asc & orderby = menu_order + title & post_type = products & posts_per_page = -1 & posts_per_archive_page = -1


In diesem Fall ist die Anzahl der Posts, die auf der Seite "Posts" (auf der Registerkarte "Bildschirmoptionen" oben auf der Seite) angezeigt werden sollen, auf 400 festgelegt. Sieht gut aus.

Die Anzahl der anzuzeigenden Produkte (auf dieselbe Weise festgelegt, jedoch auf der Seite "Produkte") wurde auf 25 festgelegt. Unabhängig davon wird das posts_per_page-Abfrageargument für die Seite "Produkte" (siehe oben) auf -1 festgelegt Dies bedeutet, dass Wordpress ALLE Beiträge mit meinem benutzerdefinierten Beitragstyp "Produkte" abruft, dann aber nur die erforderlichen 25 anzeigt. Dies geschieht auf identische Weise für die mehreren Seiten (Paginierung), die mit meiner Produktliste verknüpft sind.

Das scheint mir ein Schwindel zu sein. Also meine Frage: Habe ich den benutzerdefinierten Beitragstyp falsch eingestellt (registriert)? Ich sehe dasselbe Verhalten, wenn ich alle anderen Plugins auf meiner Site deaktiviere und nur die Funktion register_post_type verwende, um diesen benutzerdefinierten Beitragstyp einzurichten. Wenn hier etwas nicht stimmt (wie es mir scheint), melde ich es Wordpress. Wenn nicht, aber ... ich wollte sie nicht unnötig "nerven". :)

Ich habe dieses Verhalten auf mehreren Websites gesehen, aber der Grund dafür, dass mir die Ladezeit der Admin-Seite auf dieser Website aufgefallen ist, ist, dass ich über 3.000 Posts mit diesem benutzerdefinierten Post-Typ verfüge, wohingegen auf anderen Websites der Registrierungscode für meinen benutzerdefinierten Post-Typ verwendet wird haben nur ~ 300-400 Produkte auf ihnen.

Vielen Dank an alle, die helfen und/oder kommentieren möchten.

4
Programmer Dan

Das Entfernen des Parameters hierarchical aus dem Funktionsaufruf register_post_type hat den Trick ausgeführt, wie vom Vancoder vorgeschlagen. Wenn ich mir im Hintergrund ansehe, was die hierarchische Option bewirkt (setze den neuen Beitragstyp so, dass er sich wie der page-Beitragstyp verhält), sehe ich, dass er wahrscheinlich nicht an erster Stelle hätte gesetzt werden sollen.

5
Programmer Dan