That doesn't appear to be the case here:
View attachment 114530
When you upgraded did you have any outdated templates or phrases? If so, was one of them related to this particular alert?
It could theoretically be caused by incorrect data being stored with the alert or incorrect data being passed to the template from the alert handler, but really that would only happen if there were files missing/not updated or an add-on was involved.
Please try to replicate the issue on the default XF style (create a new style with no parent to try this properly), and with add-ons disabled. If an add-on is involved, you may need to disable all add-ons and then try to trigger the alert again.
There was an issue with blank alerts a while ago that I think at the time was related to uninstalling Tapatalk. See this thread and how it was fixed (master data reimported) in case it is similar.I think this is related with this bug. I'm receiving alert but nothing is showing..
View attachment 115444
There was an issue with blank alerts a while ago that I think at the time was related to uninstalling Tapatalk. See this thread and how it was fixed (master data reimported) in case it is similar.
XF 1.2 - Blank Alerts
Yeah. Definitely not related to this.
Though it could also be missing or corrupt templates so try in the XF unedited default style and try rebuilding master data.
Ok. We need to ascertain via the db what these alerts are.
Right click on one of the blank alerts, and click Inspect Element. The empty alert should have a container which is an <li> element. That element will have an ID like alert-1234. The numerical part is the alert ID.
Now run this database query:
SELECT * FROM xf_user_alert WHERE alert_id = 1234
(Where 1234 is the actual alert ID).
The important bits of info there are the content_id and action. What are they?
Hi Cris,You'd usually use PhpMyAdmin if available. If not, then you would likely need to execute "mysql" followed by:
USE <db name>;
(Replace <db name> with you XF database name)
The run:
SELECT * FROM xf_user_alert WHERE alert_id = 1234;
(The semi colon is likely required at the end of each query).
If you still have problems or you are unsure, submit a ticket from your customer area with all of he relevant log in details and I'll take a closer look for you.
That is tag_comment. I actually meant to ask you for the content type but I'm pretty sure the content type will be profile_post.
Which means, something weird has happened. I would hazard a guess that one of the files hasn't uploaded correctly or you've had or got an add on that is overriding the behaviour.
In XF 1.5 the correct content type would be profile_post comment and the correct action would be simply tag. (I think).
Could you run a file health check in Admin CP > Tools > File Health Check?
Any problems there?
Potential Problems
library/Waindigo/Listener/TemplatePostRender.php
File does not contain expected contents.
library/WMTech/DoublePost/ControllerPublic/Thread.php
File does not contain expected contents.
library/MinPostLengthEnforcer/DataWriter/DiscussionMessage/Post.php
File does not contain expected contents.
We use essential cookies to make this site work, and optional cookies to enhance your experience.