Wordpress E-Commerce Papierkorb löscht selbstständig?

Die Vorhaltezeit des Papierkorbes wird in der wp-config.php als Konstante definiert:

[COLOR=#333333][FONT=monospace]define( 'EMPTY_TRASH_DAYS', 30 );[/FONT][/COLOR]

In diesem Fall 30 Tage. Wenn Du das komplett deaktivieren möchtest, setz es auf 0. ;)

Der Papierkorb wurde offiziell mit Version 2.8 eingeführt und seit dem gibt es die Variable. Das "Ding" funktioniert auch - habe selber 2 Blogs, in denen ich die "Auto-Löschen"-Funktion deaktivieren musste.

Du kannst sie an beliebiger Stelle in der wp-config.php einsetzen, da die Datei durch wp-settings.php verarbeitet wird. Persönlich setze ich sowas gerne am Ende der Datei ein und stelle (als kleiner Möchtegern-Programmierer) auch einen Kommentar voran, wann und warum diese Änderung erfolgte. :D

Das von Dir beschriebene Verhalten ist bei mir nicht reproduzierbar.

Ich habe in meinem lokalen Testblog einen Artikel in den Papierkorb verschoben. Anschließend habe ich die Konstante für die Deaktivierung des Papierkorbs gemäß Spezifikation in der wp-config.php eingefügt:

/** Absolute path to the WordPress directory.*/
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');


/** Papierkorb deaktivieren */
define('EMPTY_TRASH_DAYS', 0 );     


/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Nach einem Refresh der Artikelansicht ist der im Papierkorb befindliche Artikel immer noch vorhanden:

[ATTACH=CONFIG]7427[/ATTACH]

Im Screenshot ist zu sehen, dass die Papierkorb-Funktion beim Artikel entfernt bzw. durch "Unwiderruflich löschen" ersetzt wurde.

Der Zugriff auf den Papierkorb funktioniert normal, die Artikel können wiederhergestellt werden. Nach einer solchen Wiederherstellung muss man die Übersicht aktualisieren, dann taucht der Artikel wie gewohnt wieder auf.

Weiterhin habe ich das Verhalten bei WooCommerce mit einem Produkt getestet:

[ATTACH=CONFIG]7428[/ATTACH]

Auch hier ist der markierte Papierkorb NACH dem Einfügen der Konstante in der wp-config.php vorhanden und die Produkte können wiederhergestellt werden.

Entweder ist bei Dir etwas schief gelaufen oder Du hast ggf. ein Plugin verwendet, dessen Custom Post Type nicht richtig konfiguriert war. Bei eigenständigen Plugins, die NICHT auf der Wordpress-API absieren oder schlichtweg "krampig" programmiert sind, würde mich das Verhalten wie von Dir beschrieben nicht wundern.

Hast Du in der Datenbank nachgesehen, ob die Produkte tatsächlich gelöscht wurden? Verwendest Du ein Plugin? Oder einen Custom Post Type? Denn das Verhalten ist nicht auf einen Wordpress-Bug zurück zu führen...

Right, Ingo. In der Tat dient diese Konstante lediglich dazu, einen Wert zu definieren. Sobald sie auf 0 gesetzt wird, erfolgt die Änderung im UI von Wordpress. Der interne Scheduler (ist kein Cron) läuft trotzdem weiter und entfernt vorhandene Einträge im Papierkorb nach Ablauf der Zeit.

Ich habe meanwhile ein kurzes Video zur Demonstration des Verhaltens erstellt:

http://www.zeusmedia.de/extern/wptrash/

Vergessen Winamp zu schließen. :)

Ich habe mal in die entsprechenden Klassen und Funktionen geschaut, weil mich das jetzt fuchst.

Wie hasgudl richtig schreibt, sollte man OHNE Programmieraufwand lediglich eine sehr hohe Zahl eintragen. Als Developer reicht mir das nicht, weil es nicht der eigentlich logischen Funktionalität entsprechen sollte. Zudem schützt es nicht wirklich, denn die Zeit läuft trotzdem ab.

Deswegen wäre es an der Stelle ratsam, die zeitlich gesteuerte Löschung zu deaktivieren:

function remove_scheduled_trash_delete() {
    remove_action ('wp_scheduled_delete', 'wp_scheduled_delete' );
}


add_action( 'init', 'remove_scheduled_trash_delete' );

Siehe dazu auch: http://codex.wordpress.org/Function_Refer…cheduled_delete

Zum Testen habe ich jetzt den Beitrag aus meinem Screencast gelöscht. Vorher die Konstante auf 1 Tag gesetzt. Und die obige Funktion als Plugin eingebunden. Ich checke dann in 24 Stunden, ob der Eintrag immer noch im Papierkorb ist.

hasgudl hat ja bestimmt ein Backup angelegt...

Edit:
Hinzufügen möchte ich noch, dass der Papierkorb KEIN Archiv ist. Wenn man Post & Co. Archivieren möchte, sollte man das offensichtlich anders lösen. :)

Die Frage wäre, ob das Verhalten als Bug einzustufen ist? Wenn man sich die Funktion selbst (Zeile 3449 functions.php ff.) anschaut, würde eine Abfrage das vermeintliche Problemchen beheben. EMPTY_TRASH_DAYS == 0 und ab dafür.

Da kann man natürlich jetzt über Sinn und Unsinn diskutieren, aber wenn ich den Papierkorb deaktiviere, sollte auch kein Scheduled Delete auf evtl. zerknülltes Material ausgeführt werden. Oder?

Der Winblöd- oder der Linus-Papierkorb löscht sich ja auch nicht von selber...