Alert Improvements by Xon

Alert Improvements by Xon 2.10.13

No permission to download

Xon

Well-known member
Xon submitted a new resource:

Alert Improvements by Xon - A collection of improvements to the XenForo Alerts system.

A collection of improvements to the XenForo Alerts system.

This add-on requires php 5.6 or newer

Features
  • For threads/conversation/profile pages, automatically marks alerts as read from content on a given page when viewed.
  • Mark unread link for individual alerts on the Alerts page.
  • Supports the following add-ons:
    • Content Ratings
  • Global Optional, Alert summerization by selected content type or user
  • User Option to prevent...

Read more about this resource...
 
I don't have a copy of that add-on so it makes it challenging. You could request that ThemeHouse adds support since it wouldn't be that hard for them.
 
Adds an extra column to xf_alert.
Code:
alter table xf_user_alert summerize_id add int(10) unsigned DEFAULT NULL

@Xon
we do not need to run manually above code after installing addon?
 
@Xon
we do not need to run manually above code after installing addon?
Nope, the installer will add it. It is just on a large forum it can take upto 1-2 minutes to add that column.

Being picky buy you have a typo, summarization with an a.
Amusingly, this add-on (XF1 and now XF2 version) have had that functionality with that spelling for years, and this is the first time someone pointed it out.
 
About to install, then read the ReadMe...

Do not use MySQL statement-based replication with this add-on


I have no idea what my MySql is up to at any moment, leaving that to my excellent hosts. Maybe that warning should be on the Overview page ?


Thanks though.
 
Getting this error during uninstall.

Code:
XF\Db\Exception: MySQL statement prepare error [1054]: Unknown column 'Array' in 'where clause' in src/XF/Db/AbstractStatement.php at line 212
XF\Db\AbstractStatement->getException() in src/XF/Db/Mysqli/Statement.php at line 196
XF\Db\Mysqli\Statement->getException() in src/XF/Db/Mysqli/Statement.php at line 39
XF\Db\Mysqli\Statement->prepare() in src/XF/Db/Mysqli/Statement.php at line 54
XF\Db\Mysqli\Statement->execute() in src/XF/Db/AbstractAdapter.php at line 79
XF\Db\AbstractAdapter->query() in src/XF/Db/AbstractAdapter.php at line 217
XF\Db\AbstractAdapter->delete() in src/addons/SV/AlertImprovements/Setup.php at line 104
SV\AlertImprovements\Setup->uninstallStep2() in src/XF/AddOn/StepRunnerUninstallTrait.php at line 59
SV\AlertImprovements\Setup->uninstallStepRunner() in src/XF/AddOn/StepRunnerUninstallTrait.php at line 26
SV\AlertImprovements\Setup->uninstall() in src/XF/Admin/Controller/AddOn.php at line 504
XF\Admin\Controller\AddOn->actionUninstall() in src/XF/Mvc/Dispatcher.php at line 249
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 88
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 41
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 1894
XF\App->run() in src/XF.php at line 328
XF::runApp() in admin.php at line 13
 
So this means this addon won't work on a master/slave setup?
If you use row or mixed replication it is safe.

You should not be using statement-based replication for a master-slave setup, it is hilariously unsafe and can silently break without warning if the wrong sort of SQL is executed.
 
@Xon can you please explain the summarizing option when you get a chance?

View attachment 174921
The summarizing option is mostly designed for when dealing with firehose of likes for content. Ie getting +20-100 likes for one post in a short period of time (or one person). It crushes them into a single entry to hopefully avoid obscuring useful alerts while still giving users that feel of +1 Likes.

The summarize threshold is how many unread alerts by either the one user or one piece of content should be reduced to reduced to a summary alert. The summarization process only kicks in when >25 unread alerts or the unread count for an account is 2 times the summarization threshold.
 
The summarizing option is mostly designed for when dealing with firehose of likes for content. Ie getting +20-100 likes for one post in a short period of time (or one person). It crushes them into a single entry to hopefully avoid obscuring useful alerts while still giving users that feel of +1 Likes.

The summarize threshold is how many unread alerts by either the one user or one piece of content should be reduced to reduced to a summary alert. The summarization process only kicks in when >25 unread alerts or the unread count for an account is 2 times the summarization threshold.
thanks for the explanation.
 
@Joe Link you've got something duplicating <!--[XF:content_links:bottom]--> in your account_visitor_menu template. This will likely conflict with other add-ons.
 
I do have a question.
One problem with XF is that when you receive alerts, and then you open the alerts tab on top of the right corner, the alerts are marked as viewed.
Now the problem is while they look viewed, actually the alerts' links are not viewed.

For example when I receive an alert for a watched thread and I open the alerts tab, the alert disappers. But as I didn't visit the thread I got the alert from, I will no longer receive alerts from that thread, as I have to visit it.

So the problem is that it is ambigious. You think you will receive new alerts as you viewed your alerts from the tab, but you won't receive any for watched threads for example. You have to visit the thread.

I thought that
User Option to prevent marking as read when accessing /accounts/alerts page.
will solve this issue as the alerts would only disappear if we actually visit those linked threads. But it doesn't, right?
 
I do have a question.
One problem with XF is that when you receive alerts, and then you open the alerts tab on top of the right corner, the alerts are marked as viewed.
Now the problem is while they look viewed, actually the alerts' links are not viewed.

For example when I receive an alert for a watched thread and I open the alerts tab, the alert disappers. But as I didn't visit the thread I got the alert from, I will no longer receive alerts from that thread, as I have to visit it.

So the problem is that it is ambigious. You think you will receive new alerts as you viewed your alerts from the tab, but you won't receive any for watched threads for example. You have to visit the thread.
That functionality is part of my XF1 "Persistent Alerts" add-on which I am planning on porting to XF2

I thought that

will solve this issue as the alerts would only disappear if we actually visit those linked threads. But it doesn't, right?
Correct. I've got another add-on (which I need to port to XF2) which changes this.
 
Top Bottom