TIEexpire Automated Post Expiry

There have been occasional reports of the plugin not properly activating its wp-cron job, so nothing gets expired. If you see this happening on your site, deactivate the plugin and reactivate it. That normally solves the problem. If it doesn't, post about it in the WP support forum as usual.

Yes, it is. Nothing new is added, but bugs will be fixed. All new functionality goes into TIEtools.

Absolutely no idea. It was never designed for that, so I'd honestly be surprised if it does.

Because you don't have the other plugins installed: TIEexpire only shows you the options you can use.

At present, TIEexpire works with BAW Post Views Count v.2.19.11 and WTI Like Post v.1.4. Since this plugin is based on the database tables rather than any code used in those plugins, it should work with newer versions unless there's a major restructuring. No guarantees, though.

The basic WTI plugin stores all its data in individual lines in its own table: one for every like for every post for every user. On a popular, fast-moving site, that's a lot of lines of data. In testing on a site with about 5,000 posts and a similar number of likes, TIEexpire locked access for over two minutes while it ran against raw data. The wti_totals view solves the problem by summarising all that WTI data so that it can be accessed quickly to avoid killing your site. It is not used for anything else and is only created if you have the WTI LIke Post plugin installed and active.

From the top to the bottom on the settings page. By age -> by number of retained posts -> by views -> by likes. All tests are run individually and are cumulative, so the age check is completed and old posts expired, then the post limit test is run against all content remaining, and so on.

Only by editing the plugin file: look for the do_TIEexpiry_all function and move things around if you're happy doing that. I'm hoping to add a feature to the options screen for this in future versions.

Yes. Just set a value to zero to switch off a test. In those with two options (views/likes), setting either value to zero switches off the test.

At most once per hour. You can change this in the do_activation function: switch the value 'hourly' to whatever suits you (and will work with wp_cron).

Yes. As of version 1.0.3, you can list categories to include or exclude and switch the filter on or off for each expiry method. I'm hoping to add a pretty interface for this in future versions - for the moment, a comma-separated list of category numbers will have to suffice.

The include/exclude option is a radio button, so it can't be set to "neither". However, you can switch off the category filter for each expiration method. Setting the categories to include (or exclude) to "0" and clicking the radio button efffectively stops all category filtering as well.

The parent category will be taken into account and all sub-categories will be ignored. Yes, this makes entering a dozen sub-cats a long process, but it gives you much finer control over precisely what is included or excluded in the expiry process.

You can go to Posts -> Categories, click a category name and look at the URL, which includes a "tag_ID=xxx" part, showing the category number (xxx). Or you could install and activate the Reveal IDs plugin, which adds a column on the categories page to show the ID number of each one. Much easier. The plugin URL is http://wordpress.org/plugins/reveal-ids-for-wp-admin-25

No, not at the moment. I figured it would be unlikely that anyone would want that level of control, though I guess I could put it in if people ask for it. It'd make the options even more complicated.

No. The plugin only handles categories at the moment.

Yes. You'll have to edit the plugin file, though. Look for the TIEexpire_send_notification function. There's a different email for each recipient, so you can customise to your heart's content.

Of course you can. There's no guarantee it will work, though. Separate addresses with commas and cross your fingers. The plugin does not check the validity of the email address you put in there.

The very first time the queries run, it might. This is especially true if you have a lot of posts and use several of the checks. Notifications are particularly ponderous. In testing, I ran it against a database with around 5,000 posts published across a year and it caused a delay of 10-15 seconds in page serving the first time it ran. After that, I never noticed a delay again, even with a reasonable expiry rate.

You're reading it. However, while I was developing the plugin, I kept notes and wrote several blog posts that follow and explain the process. You can read those on http://setupmyvps.com/tieexpire if you want more info (or want to see how a noob built his first plugin). The plugin code is also heavily commented to help you find your way.