Script for deleting autodrafts, post revisions and trashed posts from multisite & buddypress

1. Backup database first.

2. Create a file in root wordpress directory, with the  code of
3. Did I say BACKUP database first?
4. Run the file  once.
5. Delete the file in order to avoid accidentally use.


BuddyPress Hashtags LS

I’m in a process of making a hashtag plugin, based on BuddyPress Activity Stream Hashtags.

The Buddypress Hashtags LS plugin:

  • it doesn’t alter the activity contents instead all hashtags are stored in a new db table in order to make lighter queries in activity table
  • it supports unicode ex. Greek language
  • it provides a “Popular terms” widget.
  • it provides a shortcode [ls_bp_hashtags] which accept same arguments as wp_generate_tag_cloud() function.
  • in multisite installation it also includes the tags and categories of each post
  • in multisite installation, if a hashtag is inside the post content it also has link to the related activity.

I have tested with the latest BP 2 RC. The base functionality seems OK.

Things which need fixing are:

  • Unistaller function
  • Popular terms” widget. Add parameters
  • Related Activity listing. Find a way to display activities from private or hidden groups.
  • Create a Activity tab “Terms sitewide”
  • Create a “similar activity” widget for use under a blog post in case of multisite installation.
  • “Trends”. This is a difficult one :-)

It would be great if someone try it or even contribute to it.

The alpha version of “BuddyPress Hashtags LS ” is available at

Keep in mind that it is still alpha version so don’t use it in a production site, cause:

1. The plugin creates a new db table, which is not deleted when the plugin is deactivated.

2. The plugin alters the activity contents by adding a link to each tag, prior inserting into the activity table.  This link don’t change when the plugin is deactivated.


Make poedit work correctly for Buddypress

I tried to create Greek .mo file for Buddypress using PoEdit and it seemed to ignored plural forms for the _n keyword which is used in some places e.x. _n( ‘Viewing group %1$s to %2$s (of %3$s group)’ , ‘Viewing group %1$s to %2$s (of %3$s groups)’ , $total , ‘buddypress’ ) 

Solution on that was simple, and found at

Just go to the Catalog properties and at the tab “Sources keyword” add the keyword

Complete (  Current list of the keyword I use for the wordpres/buddypress translation is:


BP Groups Suggestions plugin

Some time ago I tested the ‘BP Groups Suggest Widget’ (  from  Brajesh Singh, which gave me the idea to extend it, since I needed the groups suggestion to also take into account more user data.

So the result, was BP Groups Suggestions plugin.

The plugin adds “Suggested groups” functionality into Buddypress groups.

By default, it uses the user’s friends’s groups in order to suggest groups of the login user, but this can be extended throught available filters.

It adds a “Suggested group” tab into the Groups Directory page, and also a widget “Suggested groups” is available.


The login user can hide groups from suggestion list, by pressing the “Remove group”, either through the widget, the “Suggested groups” tab or by the group’s homepage. Also the login user can reset the hidden suggestion list. The plugin uses various ‘filters’ so a developer can extend it, for example to include admins specified groups as suggested, or to exclude groups from suggestion list.

 You can download the plugin from

MySql cache tuning

I’m not a db administrator, but the only sure thing I know is that having a  wordpress multisite + buddypress installation with more than 10.000 users is very heavy task for a single database.

Right now we use a plugin (multidb) and have our database spilled in 17  databases spread in 4 database servers.

But, there are still cases, where the mysql is slowing down the site .

So we are always on the search for finding tips on  improving the mysql performance (If you have some tips please share).

Recently we noticed that in the slow_queries.log that the same query was  appearing again and again. This was strange, because the query should be cached on the 1st time.

So, this made us wonder if the MySql Query Cache was misconfigured.

A very usefull presentation of percona about MySql Query Cache helped us to spot what was wrong in our installation.

It turned out that mysql cache was fragmented. In the above presentation a nice “Tuning the Query Cache” helped us to make some configuration decisions.

We ‘ll wait and see if the decisions  were in the right direction.