Trash emptier wordpress plugin

The trash was introduced in wordpress version 2.9, and the operations of deleting posts (all types of post types) and comments was replaced by sending them to the trash. Actual deletion from the DB is done through trash management which is separate for each post type and comments. In addition an automatic process empties everyday all trashed items which where in the trash from more then 30 day. read more about the trash feature in the codex.

The plugin has two function

  • Provides a way to conctol the maximal amount of time an item will be kept in the trash before being deleted as an alternative to defining the EMPTY_TRASH_DAYS constant in your wp-config.php file. You can have the automatic trash empty performed faster, or set such a riciculously long interval that essently makes emptying the trash a puerly manuall operation.
  • Manually empty item from the trash based the time they been there.

Installation

  1. Download it from the repository
  2. Using your favourit FTP software upload the emptytrash folder into your site /wp-content/plugins directory
  3. go to the plugin management page and activate.

Usage

  • To Manually empty the trash go to the “Tools” >> “Trash emptier” menu
  • To configure the automatic emptying interval go to “Options” >> “Trash emptier”  menu

If you find this plugin usefull, don’t forget to donate

I will be very surprised if I will receive enough donations to cover the cost of the effort in designing, coding testing and supporting this plugin.but it is a nice sign of appreciation for my work.

Localizing/Translating wordpress plugins and themes names and descriptions

Cool small localization feature that WordPress has is the ability to localize/translate the meta data of a plugins and theme. If plugin and theme authors will actually use it, it will enable localizers to provide a totally localized experience to the users even on the plugin and theme management pages.

This feature is very easy to activate, you should just add two lines into your plugin or theme header block

Text Domain: mytextdomain
Domain Path: lang_folder

where “Text domain” (mytextdomain in this example) is the text domain you used for your plugin/theme localization in the __e() and __() calls, and “Domain path” (here it is lang_folder) is the directory under your plugin/theme root directory in which the *.mo file resides.

For plugins, you can localize Name, PluginURI, Description, Author, AuthorURI, Version. For themes, you can localize Name, Description, Author, Version, ThemeURI, AuthorURI, Status.

While localizing Author info is probably not very moral, and localizing version probably not very smart, it is possible to localize the PluginURI and ThemeURI so they will point to a support/info URL relevant for that local. In other words, a plugin/theme developer can set up support page in english and another one in spanish, and use localization to point the spanish users to the spanish support page instead of the english one.

The only problem left is how to put those strings into your *.pot/*.po file.

For the plugin header below

Name: Plugin name
Description: Plugin description
Author: me
Version: 1.0
PluginURI: http://example.com/plugin
Text domain: mytextdomain
Domain Path: /lang

you can add the following code which enables the localization of only the name and description of the plugin. The location of this snippet in your code is not important as long as poedit can parse the file and conclude that ‘Plugin name’ and ‘Plugin description’ are translatable strings

_plagin_header_local = array(
__('Plugin name','mytextdomain'),
__('Plugin description','mytextdomain')
);

There are also other methods to achieve the same effect.

Relevant reading: Jacob Santos and Viper007Bond wrote on this feature.

Should you optimize your wordpress MYSQL tables? (probably no)

While it looks like a no brainer (you only need press one button  to optimize. so why not), the consensus between the mysql experts tend to discard the usefulness of optimizing as a way to improve your wordpress performance.

The real question here is not if optimizing is good or bad, but whether you should dedicate in advance time to perform it. And since while the table optimization is done the site should be offline, does the benefits are high enough to justify it.

What the optimization does it to defrag the files used for the table and rebuild the index. defraging might save some space on your harddisk, but will not impact your site’s performance. The index rebuild potentially can improve performance but in practice it rarely does so, especially for the small sites which is probably 99.9% of the stand alone wordpress sites in the world.

For people managing wordpress networks it might be more complicated as the defrag benefits might accumulate to something substantial, but I have a feeling that whatever the benefit will be, the time and effort needed to communicate to your users that their sites will be down will outweigh them.

Maybe this is something that you should do only when you are already performing site maintenance for other reason like version upgrade.

 

The subtle differences between get_alloptions, wp_load_alloptions and get_option

WordPress code had been very bad and made me waste several hours because of lack of proper documentation :(. All I was trying to do was to write a script that will do a simple search and replace on the text part of a text widget and each time I  would run the script the widget will stop being displayed.

My code was very simple

$opts = get_alloptions();
foreach ($opts  as $k=>$ogt) {
  if it is a text widget {
    $opt = searchandreplace($opt);
    update_option($ov,$opt);
  }
}

Turns out get_alloptions is deprecated  in favour of wp_load_options (i.e. the codex entry for it is wrong) therefor it does cache the options,but the array it returns is raw values which might be seialized while get_option return unserialized data. That was the source for my problem as I was assuming that get_alloptions is just a sytax sugar for calling get_option for each option at once.

The working code looks like

$opts = wp_load_options();
foreach ($opts  as $ov=>$opt) {
  if it is a text widget {
    $opt=get_option($ov); // already cached so no extra DB access
    $opt = searchandreplace($opt);
    update_option($ov,$opt);
  }
}

And then it gets even worse as suddenly I discover that wp_load_options returns only the autoloaded options but I want my code to be generic enough to work on not autoloaded as well so there is basically no alternative but to do a direct DB access

$opts = $wpdb->get_results( "SELECT option_name FROM $wpdb->options");
foreach ( (array) $opts  as $ov) {
  if it is a text widget {
    $opt=get_option($ov); // already cached so no extra DB access
    $opt = searchandreplace($opt);
    update_option($ov,$opt);
  }
}