Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 02 2018 18:17

    mark0263 on develop

    cache namespace support tag / k… (compare)

  • Feb 01 2018 21:13

    mark0263 on develop

    Removed depreciated functions M… (compare)

  • Feb 01 2018 18:06

    mark0263 on develop

    Support dbResult method in pdo … (compare)

  • Feb 01 2018 01:59

    mark0263 on develop

    fall back support for fetchAll PDO driver Support for PDO driver and 5 more (compare)

  • Jan 31 2018 11:53

    mark0263 on glfusion_1.7_lts

    German Update (#328) German Up… (compare)

  • Jan 31 2018 11:48

    mark0263 on develop

    German Update (#328) German Up… (compare)

  • Jan 31 2018 11:48
    mark0263 closed #328
  • Jan 31 2018 11:48
    mark0263 commented #328
  • Jan 31 2018 11:47
    matrox66 opened #328
  • Jan 31 2018 03:01

    mark0263 on develop

    Simplify count (compare)

  • Jan 31 2018 01:35

    mark0263 on glfusion_1.7_lts

    Set version to 1.7.3 (compare)

  • Jan 31 2018 01:09

    mark0263 on develop

    3rd time is the charm - do not … (compare)

  • Jan 31 2018 01:03

    mark0263 on develop

    Set proper version number (compare)

  • Jan 31 2018 01:01

    mark0263 on develop

    Fixed check (compare)

  • Jan 31 2018 00:58

    mark0263 on develop

    dvlpupdate can be run multiple … (compare)

  • Jan 31 2018 00:57

    mark0263 on glfusion_1.7_lts

    dvlpupdate for 173 (compare)

  • Jan 31 2018 00:51

    mark0263 on glfusion_1.7_lts

    Change CSS badges to use colors… (compare)

  • Jan 31 2018 00:48

    mark0263 on develop

    Change CSS badges to use colors… (compare)

  • Jan 31 2018 00:48
    mark0263 closed #327
  • Jan 30 2018 22:16
    leegarner opened #327
Lee Garner
@leegarner
I'm pretty sure I'm remembering why we did this with the parent_id, to get the story url instead of the comment. But I see there's a getiteminfo_comment() function, I'm going to revisit and see why I didn't use that.
Lee Garner
@leegarner
So, it's looking to me like parent_id isn't used. plugin_getiteminfo_comment() returns the parent item's URL anyway. So I think setting the parent forum id would simplify that. Next need to check how MG figures the URL.
Lee Garner
@leegarner
I think maybe PLG_itemDeleted() isn't quite flexible enough for the plugins to know the difference. I'm not crazy about having it called for every topic, image, etc. under the parent being deleted, but wonder how often that really happens.
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.
Mark R. Evans
@mark0263
That might be the best approach - expensive but rarely used. Huge rabbit hole here - now I need to go see what the Forum plugin does (and Media Gallery too) when a post is moved, merged, etc....
Lee Garner
@leegarner
I did think of the forum, when a post is moved it keeps it's topic ID so that should be fine.
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?
Mark R. Evans
@mark0263
I think I did getItemInfo() for comments to support searcher - I'll put this cool deep DeepScan git tool I have to work and see if I can find when / why it was put in there.
Lee Garner
@leegarner
Looks like it was added about 6 months ago, which predates searcher's release but not it's development. So it wasn't in 1.6 and maybe not 1.7.0
Mark R. Evans
@mark0263
Based on my notes - added it on 8/1/2017 to support Searcher.
Lee Garner
@leegarner
The only place parent_id is really used is in Indexer::RemoveComments().
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.
Mark R. Evans
@mark0263
That makes sense - since I don't think we call anything directly for comments, Searcher actually does the comment calls, it would need the parent id.
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...
Lee Garner
@leegarner
It's actually good, it keeps the interface consistent for getItemInfo.
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.
Lee Garner
@leegarner
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.
Lee Garner
@leegarner
Now that I think of it, that's the best way. My change to accept an array of item IDs to delete isn't consistent with the reset of the plugin_itemdeleted functions which expect a string (or at least single) ID.
Mark R. Evans
@mark0263
probably not - but we could add an optional array parameter that if set, it does something different.
Mark R. Evans
@mark0263
I'm obviously doing too many things at once right now and not thinking this through well - let me wrap up some work related items so I can actually focus on the problem better :)
Lee Garner
@leegarner
OK, no problem.
Mark R. Evans
@mark0263
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 -
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...
Lee Garner
@leegarner
I still like the idea of keeping it self-contained in searcher so plugins don't have to know anything about its schema. What about back to having a 3rd argument to PLG_itemDeleted:
function PLG_itemDeleted($id, $type, $children=NULL)
Mark R. Evans
@mark0263
that would work - so if $id == null and $children == array() - process the array instead?
Lee Garner
@leegarner
$children can be an array of ids to be deleted, $id is still the main ID. I was thinking about overloading $id for this purpose but maybe, just maybe, some plugin might want to act when forum #3 is deleted...
Right. Searcher would do that, everything else would just ignore it.
Mark R. Evans
@mark0263
I think that would work!!
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.
Mark R. Evans
@mark0263
or not - just wrote a quick test and it seems to be fine passing an extra argument - now I have to think back about what was causing me issues earlier....
Ah - too few throws the exception, too many - no issue
Mark R. Evans
@mark0263
$ids = DB_getItem($_TABLES['ff_topic'],'GROUP_CONCAT(id SEPARATOR \',\')', 'forum='.(int) $id); Returns a comma separated list of all ids in the forum - so should $children be an array or a comma separated list?
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;
}
Lee Garner
@leegarner
Sorry, had to step out for dinner. Husbandly duties, you know.... I like that approach. I'll add it to searcher.
Mark R. Evans
@mark0263
No problem - completely understand - that was pretty much my day yesterday :)
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.
Mark R. Evans
@mark0263
Media Gallery actually calls PLG_itemDeleted() for every media item it deletes as it loops through the album.
Lee Garner
@leegarner
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);
}
Mark R. Evans
@mark0263
Perfect - go ahead and commit the change needed to make it an array.
Lee Garner
@leegarner
So if one doc is deleted, it works normally. If children are given, it passes them as an array, the removedoc function does the sanitizing.
Mark R. Evans
@mark0263
excellent!
Mark R. Evans
@mark0263
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?
Lee Garner
@leegarner
Probably not, I could give it a try.
Mark R. Evans
@mark0263
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.
Mark R. Evans
@mark0263
glFusion support and discussions have moved to Discord - https://discord.gg/aESFqh6