Threadmarks Pro

Threadmarks Pro [Paid] 2.23.9

No permission to buy ($40.00)
Compatible XF 2.x versions: 2.2

This add-on is not yet compatible, but it should be out soon as I'm just finalising some updates for the next batch of releases
 
This week we rolled out this add-on (xf 2.2), and most of the things went well!

One of the things we had to change was removing all group permissions of the initial category because it would be selected to be used by default on each post a (staff) member (with node/group permissions to use it) made, that id = 1 is hardcoded in the code and could not be disabled/deleted.
In our use-case it is better to opt-in then opt-out to use it (and thus prevent a lot of accidental threadmarks or errors that the label was not filled in).

Another thing that I'm currently cannot find out, when I create a Threadmark Index on a thread with multiple Threadmarks (sometime only one category, sometimes multiple categories), the "threadmark_index_threadmarks_list" does not show most of the time. I have tested on different nodes with different users, but it looks pretty random so I can't see the logic why it works (or not).
When I set some debug info in the template to output $threadmarkAuthors.count() and $threadmarks.count(), it shows 0 on both, even if on the threadmarkListingHeader it shows a number larger then 0 for Threadmarks (and thus also at least one author).
 
Thank you for the feedback!

One of the things we had to change was removing all group permissions of the initial category because it would be selected to be used by default on each post a (staff) member (with node/group permissions to use it) made, that id = 1 is hardcoded in the code and could not be disabled/deleted.
In our use-case it is better to opt-in then opt-out to use it (and thus prevent a lot of accidental threadmarks or errors that the label was not filled in).
It simplifies a bunch of the code to always have a threadmark category that exists, but over time I've migrated to allowing it to be disabled. But it shouldn't get selected if the user can't use it, I guess this is just a rough edge case.

Another thing that I'm currently cannot find out, when I create a Threadmark Index on a thread with multiple Threadmarks (sometime only one category, sometimes multiple categories), the "threadmark_index_threadmarks_list" does not show most of the time. I have tested on different nodes with different users, but it looks pretty random so I can't see the logic why it works (or not).
When I set some debug info in the template to output $threadmarkAuthors.count() and $threadmarks.count(), it shows 0 on both, even if on the threadmarkListingHeader it shows a number larger then 0 for Threadmarks (and thus also at least one author).
Have you checked the approval queue?

There might be some rough edges around caching author counts when you add a thread to a threadmark index. Multiple threads to a threadmark index isn't a heavily used feature so there are very likely bugs lurking in that code.
 
Have you checked the approval queue?
Nothing in the approval queue :(

There might be some rough edges around caching author counts when you add a thread to a threadmark index. Multiple threads to a threadmark index isn't a heavily used feature so there are very likely bugs lurking in that code.
Ah I meant adding TM indexes to existing threads (so one index on one thread) with existing TMs (we did not use the add content feature for the time being). Even a new TM index on a thread without TM's, and adding new TM's to that thread do not add the threadmark_index_threadmarks_list (also not after a while).
 
Xon updated Threadmarks Pro with a new update entry:

2.23.0 - Feature update

  • Add "Sort by content date" button to threadmark sorts page
  • If a non-staff (from Advanced bb-codes pack) threadmark is added to a thread, move the index to an "incomplete" state if in hiatus/dropped.
  • Add "Index progress hiatus cutoff" (default disabled) and "Index progress dropped cutoff" (default disabled) options
    • Automatically expire "incomplete" threadmark indexes based on time.

Read the rest of this update entry...
 
Xon updated Threadmarks Pro with a new update entry:

2.23.3 - Bugfix update

  • Fix new threadmarks widget would not be restricted to expected subforums
  • Fix edge case where the author list's sort-order could be unstable
  • Fix merging users didn't update threadmark ownership records resulting potentially missing author statistic records
    • Threadmarks with bad user ids can be fixed up by running php cmd.php xf-rebuild:content-user-for-threadmark.
  • For threadmark author statistics, attribute posts with no user to 'guest' rather...

Read the rest of this update entry...
 
I want to upgrade from my previous thrademarks but apparently I found error when upgrading..

XF\Db\DuplicateKeyException: xf_sv_threadmark: MySQL query error [1062]: Duplicate entry '1466' for key 'xf_sv_threadmark.content_type_id' in src/XF/Db/AbstractStatement.php at line 230
 
I've only seen that error once when attempting to update from very old XF1.x compatible version.

What version of XF and the addon are you attempting to update from?

You will likely need to open a ticket on my site for additional troubleshooting as this requires manually hard-deleting duplicate threadmark records
 
I've only seen that error once when attempting to update from very old XF1.x compatible version.

What version of XF and the addon are you attempting to update from?

You will likely need to open a ticket on my site for additional troubleshooting as this requires manually hard-deleting duplicate threadmark records
ok thank you..
 
Back
Top Bottom