Report 9 (1/18/2019)
Minor grammatical error found on user profiles for accounts which have not yet added anyone to their Buddy list:
Quote:{user} doesn't have add any buddy.
Example:
Potential solution would be rewording the above to the following:
Quote:{user} has not yet added any buddies.
Report 10 (1/18/2018)
Using keyboard shortcuts in the WYSIWYG rich-text editor located by clicking
Preview near the reply field to access text formatting functions does not seem to work correctly. For example:
- I started this unordered list by clicking the unordered list icon in the text editor.
- Right before writing this element, I pressed Ctrl + B on my keyboard to bold the text. The corresponding B icon in the text editor highlighted momentarily, but once I began typing no bold text appeared.
- However, now that I pressed Ctrl + B a second time, the bold seems to take effect.
- After pressing Ctrl + B a third time, the bold correctly disappears. If I press Ctrl + B again and type the bold appeared, but if I erased some text first via backspace and then started typing again, the bold text did not appear.
- Just now I pressed Ctrl + B again and tried to start typing, but the bold text did not appear. This seems to happen intermittently but fairly often, wherein I have to press the associated keyboard shortcut twice instead of once to select or deselect a formatting option.
Lastly, this is a bit more difficult to reproduce but there are instances wherein I press a keyboard shortcut to deselect a formatting option (such as italics) and the associated text editor icon correctly removes its highlight, but once I begin typing the formatting returns and the icon re-highlights itself.
Please note that I'm using a nonstandard browser: Vivaldi. This browser is based on Chromium (just as Google Chrome itself is, among many other derivatives) but is markedly different in many respects. One key downside to the Vivaldi browser is that the paste without formatting shortcut (Ctrl + Shift + V) does not behave correctly, so it's possible this bug could just be a problem on my end, especially if you try reproducing this in a more standard browser (IE, Edge, Chrome, Firefox, Opera, etc) and do not experience the same issue.
Report 11 (1/18/2019)
Ban reasons seem to currently be accessible by any user, including guests. For an example profile, please PM me if needed (wasn't sure if I should provide the link here for privacy reasons), but you should be able to reproduce this by locating any banned account via the admin panel or public member search (the latter denotes banned members by placing a strikethrough on their username and giving them the user title Game Over, not sure if that's supposed to be viewable by non-staff).
The ban reason seems to be located directly beneath the
Members Referred profile field but directly above the
Items field. One example of a ban reason I have seen is the following:
Quote:Spam (Permanent)
Furthermore, ban reasons seem to be visible on forum posts. If you view any forum post by a banned user, you can see a staff-supplied reason for the account's ban regardless of whether the reason is chosen from a preset list or a custom-written reason.
I have confirmed that you can view ban reasons in both of these locations even logged out, as a guest.
Report 12 (1/18/2019)
This regards the Forum Statistics page:
https://sonicblast.org/stats.php
While the
Mobius Statistics section seems to update its data fairly regularly, the
Most Popular... section seems to currently be under a data freeze. For example, it claims that the
SHQ Chat Shack thread has 24,053 views, whereas viewing the thread in its
associated forum section indicates that the thread has 24,600 views (at the time of this writing).
For parity, the refresh rate for the
Most Popular... data could be changed such that it updates at a velocity identical to that of the
Mobius Statistics section.
Report 13 (1/18/2019)
This regards the Blogs:
https://sonicblast.org/mybblog.php
I noticed anomalous activity within the tagging section for the blog entry "
Project: Blue Jumper" as viewed from the main blog listing. Tag sections for every other blog article on the page are wrapped in the following class:
Code:
<td class="tcat">...</td>
However, for this blog entry in particular the tagging section is wrapped in the following class:
Code:
<td class="trow1">...</td>
This seems to result in the tags being center-aligned instead of left-aligned. Furthermore, directly left-adjacent to the tags is a piece of code with malformed content passed as a parameter to an image tag, thereby resulting in a broken image icon displaying:
Code:
<img src="https://...</td>
</tr>
<tr>
<td class=" tcat"="">
To help diagnose the root of the issue, I compared the aforementioned blog article with every other blog article. Through doing so, I noticed that this article was unique in that it was the only one that began with an external image inserted inline with the blog content instead of beginning with plaintext.
To try to reproduce the issue, I created a series of testing blog articles:
For Test Blog I, I began by simply posting "Test" along with a series of tags. The blog post appeared correctly on its page as well as when viewed from the main blog listing. I edited the blog post to center the word "Test," but it continued to display correctly in both locations.
For Test Blog II, I first inserted an externally-hosted image inline with the post content at the beginning of the blog, before writing any plaintext. Then, I added "Test II" at the end of the blog. This initially reproduced the issue with the broken image icon displaying. Lastly, I edited the blog post to center the image and text, and that also anomalously centered the tag data when viewed from the main blog listing.
Similarly to the initially-investigated blog post, my Test Blog II demonstrates the tagging section being wrapped in the trow1 class instead of the tcat class, and displays nearly identical malformed code resulting in the broken image icon:
Code:
<img src="http://s...</td>
</tr>
<tr>
<td class=" tcat"="">
In conclusion, it seems that blog posts that begin with embedded external images are not correctly processed and encapsulated within their proper field, resulting in formatting code spilling outside of its intended boundary and thereby impacting the styling of the
main blog listing.
Report 14 (1/18/2019)
Various notification-related counters can experience a bit of a delay in updating, or do not update unless specific actions are taken. For example, opening up your CluckAlert panel and then closing it will not clear out any notifications -- you have to open up each item mentioned in notifications in order for them to be cleared out, which makes it inefficient for people to clear out any potentially low priority or extraneous notifications and focus on more important ones.
Additionally, I have noticed that clicking
View New Posts in the pane located at the top-right of the homepage, when there are at least 1 or more new posts denoted, does not clear out the new posts counter upon returning to the homepage. This statistic could be treated as a notification, clearing out once the user returns to the homepage regardless of whether they opened up the new posts/threads. This would operate under the assumption that the end user would open up the new posts/threads they wished to read (if any), and so the notification regarding any others can be cleared out since the end user chose not to view them, allowing them to more efficiently be made aware of new posts that they did not yet observe in the new post listing.