it looks like there's some erroneous entries in your trophy table. Possibly your foreign keys are no longer created. In order to have a closer look at the problem, it would be nice if you could open a ticket for me. Then I'll take a quick look at it.
The problem with deleting the trophies, is organization issues that are brought on by it. We have 100 trophies, and the categories are sorted by their ID numbers, that would have given me trophy 101, in a slot that belonged to trophy 9. I know that users, dont see it, but when managing that many trophies, the ids to me are important.
I have some good news for you! In the upcoming major version (WoltLab Suite Core 5.2) there will be the possibility to sort trophies in addition to the above mentioned trophy withdrawal.
Also, why does the trophy counter not check for that, and remove the trophy if the conditions are reverted?
In a future version, it will be possible to withdraw trophies again if the conditions are no longer met. Unfortunately this is not possible at the moment.
Never mind figured it out, for anyone else that needs to do so, I did it in the database.
Please do not edit anything in the database. This can have some negative consequences. For example, that the counters are not updated. Here you could have simply deleted the trophy from the ACP and re-created it. This would have updated the counters for the users. Anyways the horse has already left the barn, so let's fix that. You can execute the User Rebuild Data Worker to recalculate the trophy points for all users. This should fix the issue.
there is trophies for filling out the "Personal Details" and it states contains, anyway to make it contain anything? Or does it have to contain certain things?
Unfortunately, there is currently no possibility to use the condition "filled in". It must always match concretely. However, we will look into this for the coming version, whether we can not integrate such a condition there, because it is quite a meaningful proposal.
Also just checking, I have been making these Trophies under the assumption greater than means greater than, IE, a 250 post trophy should be Greater than 249, correct?
Yes, that's correct. For example, if a user is to be rewarded for at least 250 contributions, the field must contain 249.
I expect user-friendly products to be consistent. For that claim, I expect there to be a PHP-Classinput field, so I can handle more advanced examples (like implemented in various other options).
Being user-friendly does not mean that the user can do everything simply via the GUI. Being user-friendly means that every user can get used to it right away. That wasn't the case back then with my plugin. The current implementation does give that away.
Very few users use their own PHP class. If you use your own class, you have to be able to program anyway or at least copy the class somewhere. This is not very user-friendly and confusing for inexperienced users. Of course, we've been thinking about how third parties can add their own input fields, which with the current implementation is also possible via a simple eventlistener.
To be consistent, the form is the same that you have for the contact form among other things. So the user already knows the form.
Throwholics No, the whole thing is implemented in a much more user-friendly way. But since pictures say more than a thousand words, I will add some screenshots.
(Just create your field when you edit or create a forum.)
(The fields will displayed when you create a thread.)
(And so it is displayed in the thread.)
can you send me a link to your sitemap?
By default, only a certain period of time is included in the sitemap. If you want to include all threads in the sitemap, have a look at option Time frame of indexing.
I increased the font size, but why does it look different than yours?
You can imagine that Emojis is nothing more than a letter on the keyboard. If you now use this letter, each operating system interprets this letter "differently". The actual emoji remains the same, but the display depends on the operating system. For example, they look different under macOS than under Windows, whereby the statement behind the emoji always remains the same.
1. No mod notification is sent when a member's thread title is changed, or when text of their thread is edited.
There are only mod notifications for the following actions: close a thread, enable a thread, move a thread, trash a thread, adding/removing/changing a label, as well as closing a post, enable a post, trash a post and move a post. For other actions the author will not be notificated.
By clicking on "This post has previous versions that are saved." the moderator's name is shown to the member.
The privacy option has no effect on the edit history. This works as intended.
If you go to my forum as a guest, you can see that the mod's name is revealed in this thread:
That works not as intended. It will fixed with the next version. Thank you for reporting it!
Thanks. It is fixed with the upcoming beta version.
no, the timestamp for the last modification date is fetched individual for each object in a sitemap.
The "rebuild time" is the time how often the sitemap should be rebuilded. So if the time is one week, the sitemap will be rebuilt each week (if the time is three days, the sitemap will be rebuilt every three days).
Since version 3.1, WoltLab Suite Core ships a trophy system, which allows you to reward users with trophies. The concept behind this is gamification, a proven way to increase positive activity within your community. For example, you can motivate users to write more posts by adding a trophy that will be rewarded once a user reaches a configured number of posts, or you can create a competition where the price for the top ranking members are individual trophies.
You can easily create unique trophies with the built-in Trophy Badge Designer or upload your own images. The former allows you to create a trophy based off one of more than 500 distinct icons. This combination allows to create trophies that fit into the theme of your community.
(The built-in trophy designer)
Automatically Reward Trophies
We've touched the topic in the introduction above: Some trophies might be awarded for achievements that can be automatically detected by WoltLab Suite. You can use the powerful condition system, already known from the user notices and advertising system, to create trophies that are awarded once a user passes a threshold.
Put on Display
Naturally, users want to show off their hard earned trophies. They can select a so-called subset of “Special Trophies” that will be put on display at notable places, like the message sidebar and their personal user profile. You can decide how many trophies a member can mark as special with a group permissions (up to 5 trophies). To ensure that your users don't miss their new trophies a notification will be sent out when awarding one.
There might be cases where members do not want to show their trophies: The included privacy feature allow users to choose who can see their trophies.
(The user settings to select special trophies)
(The special trophies in the user profile)
(The special trophies in the message sidebar)
The next version of our WoltLab Suite is capable of automatically creating a sitemap for search engines. Sitemaps serve to improve search engine coverage of your community, by listing URLs in an easily accessible document you can submit to Google, Yahoo and others.
Which Pages will be Indexed
The sitemap automatically contains all pages you create with the page editor integrated in WoltLab Suite Core, as well as all static pages and forms which are provided by third party plugins. Non-static pages are included as well, if the plugin ships with a sitemap integration (adding this integration is easy, checkout the Advanced Usage section here). It goes without saying that all of our products include this integration: WoltLab Suite Forum, for example, ships with a board and a thread sitemap, WoltLab Suite Core offers article categories, articles and users in the sitemap.
Secure and Efficient
Adding broken links to the sitemap would harm the purpose, so the system detects automatically whether a link is visible and indexable for a search engine, avoiding inaccessible links being included in the sitemap. Possible reasons for omission are pages that are not accessible for guests, or pages that do not have the “Allow search spiders to index this page“ flag enabled. To prevent a sitemap from growing without bounds you can also define a time frame for inclusion of pages. Content that is older than this time frame is excluded, because it is assumed that search engines already know about it.
Some content changes more often that others: While new threads are created all the time you might only write a new article every few days. In order to not waste resources each type of sitemap has a custom rebuild interval. You can configure this interval as explained below.
Each community is unique. To adapt the sitemaps to your community you can configure a several settings for each type of sitemap. The most interesting one is the priority. The priority allows you to communicate to the search engine how relevant a single page is compared to other pages on your site. If you want to put a focus on articles, you can simple increase the value to a higher value to indicate that articles should be visited with a priority. Another setting is the change frequency. It is an indicator for search engines how often is a single page is changed.
For huge boards, with many sitemap URLs, you can use the CLI integration to rebuild the whole sitemap.
Developers can easily integrate sitemaps for non static sites in their plugin. More informations are available in our documentation: https://docs.woltlab.com/php_api_sitemaps.html