foreach ($items_to_del as $item) {
PLG_itemDeleted($item, 'forum');
}
Expensive, but should be a fairly rare occurrence, done only by admins, and would keep the searcher and other plugins from having to know too much about each other.
The parent ID moves, but that doesn't appear to be used. I really need to figure out what that was for... is getiteminfo() for comments fairly new?
OK. And I see that 1.7.0 was released in Oct, and that's the first version supported by Searcher. So that makes sense.
Not sure it was actually needed by Searcher, but I'm sure I was adding / tweaking all the other getItemInfo() hooks and figured comments needed one too...
You're right, comments get indexed as entered via plugin_itemsaved_searcher(). There's a plugin_IndexAll_comment() in searcher that gets called when reindexing content items the have comments.
The second-cleanest way I can think of to delete a "tree" of items is to alter PLG_itemDeleted with a 3rd param for the parent ID, default = NULL. Searcher could use that with the ID value to delete all items with that parent_id instead of item_id. But I still think that looping through the items would be good enough.
OK - had some time to think about this a little - I wonder if trying something completely different might work....Instead of trying to figure out what to pass to Searcher to handle mass deletes - maybe we reverse it and have plugins call a new PLG API to retrieve info from Searcher - not sure what to call the API, but my thought is - when a plugin is doing a mass delete of stuff - it can call PLG_getMassDeleteInfo() and it would return an array of 3 things - table, itemid, and type - like this:
```
return array('table' => 'searcher_index', 'itemid' => 'item_id', 'type' => 'type') this is the search table name, the search table item_id column name and the searcher column for type -
```
return array('table' => 'searcher_index', 'itemid' => 'item_id', 'type' => 'type') this is the search table name, the search table item_id column name and the searcher column for type -
Then - the plugin (i.e; forum, media gallery, whatever) can call the appropriate delete SQL to remove its items from searcher's index.
I know - this is a little crazy...
Forum could build a comma separated list of all topic ids in a forum and pass that to 1 sql to remove all the items from searcher - assuming MySQL can take a really, really long query (I could see where there might be thousands of topic_ids in a forum being deleted). If it can't, then forum could chunk it. Better than calling PLG_deleteItem() a thousand times...
Right. Searcher would do that, everything else would just ignore it.
I ran into a similar problem the other day when looking at PLG APIs. With PHP v7.2 (possibly all v7 releases), it balks if you send the wrong number of arguments to a function...I wonder if there is a way around this?
Some plugins may not support the NULL 3rd argument.
Ah - too few throws the exception, too many - no issue
Think this will work?
function ff_deleteForum($id) {
global $_TABLES;
// pull all topic ids for the forum being deleted.
DB_query("SET group_concat_max_len = 8196");
$ids = DB_getItem($_TABLES['ff_topic'],'GROUP_CONCAT(id SEPARATOR \',\')', 'forum='.(int) $id);
// Delete the likes. This must be done first as it relies on the topics
// still existing in the table
Forum\Like::deleteForum($id);
DB_query("DELETE FROM {$_TABLES['ff_forums']} WHERE forum_id=".(int) $id);
DB_query("DELETE FROM {$_TABLES['ff_topic']} WHERE forum=".(int) $id);
DB_query("DELETE FROM {$_TABLES['ff_moderators']} WHERE mod_forum=".(int) $id);
DB_query("DELETE FROM {$_TABLES['subscriptions']} WHERE type='forum' AND category=".(int)$id);
PLG_itemDeleted($id, 'forum', $ids);
return true;
}
I've committed the updates to lib-plugins.php and the forum to pass the children in a comma separated string - I think the only thing I see that we need to be sure and account for in the Searcher side is to ensure the query isn't too big. Looks like the default size limit on a query is 1mb - which should be big enough, but may a check in size of the query and split it if over. You can use
SHOW VARIABLES LIKE 'max_allowed_packet'; to see the local size limit.
I have a mod staged for Indexer::RemoveDoc() to handle an array as an id, and changed the itemdeleted function to this:
function plugin_itemdeleted_searcher($id, $type, $children='')
{
if (!empty($children)) {
$id = explode(',', $children);
}
\Searcher\Indexer::RemoveDoc($type, $id);
}
Now I have something completely different I want to do - As handy as Gitter is - it is also a huge resource hog on my system - even when I run in the browser. Lately it has been 'refreshing' on me often, sometimes when I'm in the middle of a post or pasting code. Anyway - I've been using Discord to collaborate on some other open source projects. It has a pretty lean / mean UI for the desktop (and browser / phone, etc). Would it cause you much grief if we were to switch?
Here is the link to the glFusion 'server' I've setup to test it - https://discord.gg/aESFqh6 - you'll probably want to create a discord account so I can assign roles to your user.
It offers more than just a channel - they call it a server and you can create as many channels as you need - each with different permissions - so I have an Announcement Channel which is readonly for the general public, a support channel and a dev channel.