askvortsov found it, thanks!!
Stickiest
a month later
I don't know if it would be more logical inside this extension, or inside the simple "sticky" one (I don't find a topic for it), but I wonder if it would be possible, or a good thing, to make "sticky" work like a tag in a way, or at least to make it clickable in the topics headers. For instance:
... to be able to click on the red button here, to access to all the sticky topics.
As the sticky topics are often specific tutorials, it would be an easy way to have access to all the forum tutorials at once.
4 days later
- Edited
Kylo Should tag stickies stick to top in "All Discussions" list when they have unread replies or behave like a regular discussion?
I come back to this, because i just experienced a problem: someone answered to me without quoting me in a tag-sticky topic, and I missed it... So yes, the "behave like a regular discussion" in "all discussion tab" would definitely be the best option.
12 days later
- Edited
@Kylo A problem on the update which allows to put a tag in "all tags" mode (I don't know if it's the exact sentence, as I use the extension in french: the mode that makes the sticky topic act like any other one in "all discussion" tab).
It works when you're online, but not when you're offline (in that case, they all appear at the top):
And it's the same as long as you have not read them: they stay at the top, above other more recent topics.
Also, another little problem : I can not directly "de-stycky" a topic which is "tag-sticked". When I do it, it sure loses some attached CSS (for instance i asked to bold the sticky posts, and there it goes back to a normal font-weight), but it stays invisible in "all discussions" and keeps its sticky badge. Here is an exemple, with the second post which has been "de-stycked" from "tag-sticky":
For it to work, I have to first go back to "average sticky" (not "tag sticky"), then to de-stycky it. Then, and only then, the topic loses its sticky badge and comes back in "all discussions".
24 days later
- Edited
TB54 ... to be able to click on the red button here, to access to all the sticky topics.
Actually we've gambits (is:sticky, is:stickiest, is:tagSticky) for that purpose. See https://discuss.flarum.org/d/28333-flarum-search-tips-and-tricks
TB54 So yes, the "behave like a regular discussion" in "all discussion tab" would definitely be the best option.
Done! Check the settings after upgrading to 3.0.0
TB54 It works when you're online, but not when you're offline (in that case, they all appear at the top):
If I understand you correctly; that's not an issue, it's a default sticky behaviour of Flarum. When you switch to the "All Sticky" mode, it'll act like you're using the bundled flarum/sticky extension.
TB54 I can not directly "de-stycky" a topic which is "tag-sticked".
This isn't an issue anymore with 3.0.0!
3.0.0
Requires Flarum v1.2.0+ & flarum/tags & flarum/sticky
- Add new modal component (replaces discussion control items).
- Add new option for displaying tag-stickied discussions in the "All Discussions" list.
- Add new label for super-tag-stickied discussions. (+ new
Stickiest-tagStickiestItemclass for discussion list items.) - Update js dependencies and imports.
Also fixes some mistakes on order logic.
!! Breaking change: Your current tag-sticky configurations will be lost. They magically will stay as just-sticky.
Don't forget to run migrations if you're upgrading from 2.0.x
composer require the-turk/flarum-stickiest:^3.0.0
php flarum migrate
php flarum cache:clearIf you ever see an error like General error: 1824 Failed to open the referenced table 'tags' ... while activating this version, check if the engine for the tags table is InnoDB or not. If not, try switching that to the InnoDB then run and try activating again:
-- make sure you have that db backup.
DELETE FROM `migrations` WHERE `migration` = '2021_07_04_000003_set_default_settings' AND `extension` = 'the-turk-stickiest';php flarum migrate:reset --extension the-turk-stickiestDROP TABLE `discussion_sticky_tag`;php flarum migrate
Kylo needs to be translate to turkish or others.
Hi, I got this error when updating the extension to V3.0.0 but it seems everything goes smoothly as expected. I just wonder if it's causing any problems that I'm not aware of?
murdocklawless you would need to post such requests in the turkish flarum translation posting: https://discuss.flarum.org/d/21356-flarum-turkish-experience-pack
Cactus1805 have you checked what @Kylo wrote unter "breaking change" in his announcement post? https://discuss.flarum.org/d/27888-stickiest/48
GreXXL Thank you, I didn't change the engine of the tags table as the error notification quite different. After change the engine, it worked like charm.
- Edited
Cactus1805 It surprisingly says can't create table... but I believe the table is there, created without tag_id foreign key. Your forum would be broken without that table & this extension activated (unless you don't have tag-stickies). If you remove a tag which has tag stickies in it, that error might cause some issues. Foreign keys are there for data integrity and I suggest having them for consistency.
Cactus1805 did you re-run the migrations after doing that? I'm asking this because It occured to me that you might have an another error (something like Migration file should contain an array with up/down.) while rolling back the migrations (after updating from 2.0.x to 3.0.x and running the php flarum migrate:reset --extension the-turk-stickiest command). Because there was a deprecated migration method (named addSettings) on 2.0.x and I removed that migration file completely with this new release. You'll see that migration (2021_07_04_000003_set_default_settings) in your migrations table if you're coming from the version 2.0.x. So you probably will need to remove that entry before rolling back migrations.
In sum, a more generic & proper solution after having that "foreign key error" is to run these codes carefully:
-- make sure you have that db backup.
DELETE FROM `migrations` WHERE `migration` = '2021_07_04_000003_set_default_settings' AND `extension` = 'the-turk-stickiest';php flarum migrate:reset --extension the-turk-stickiestDROP TABLE `discussion_sticky_tag`;php flarum migrateI'm sorry if this sounds too much to you but I can't see any other way of doing this. tags table should've been InnoDB from the very first. I'm going to suggest everyone here to update their tags table engine to the InnoDB @luceos, are there any consequences of changing while the forum is running in production?
Kylo Thank you for your detailed reply. And yes, I got the error Migration file should contain an array with up/down. while rolling back the migrations with php flarum migrate:reset --extension the-turk-stickiest command.
Your solution really help to solve this problem, many thanks for your help.
- Edited
Thanks for the update!
I will check all that as soon as it's updated on freeflarum.
TB54 It works when you're online, but not when you're offline (in that case, they all appear at the top):
If I understand you correctly; that's not an issue, it's a default sticky behaviour of Flarum. When you switch to the "All Sticky" mode, it'll act like you're using the bundled flarum/sticky extension.
Mmm ok, but in that case, an option to be able to avoid that (to make it behave offline the same way it does online) would be cool, of it's not too difficult to code. Because otherwise, it recreates the very same problem for what we use "stickiest": it puts a dozen of sticky threads on top of the homepage, which is problematic.
- Edited
Kylo It's updated in freeflarum and it works great, much more easy to configure and use with this little menu, congrats!
For future updates, I wonder if this behavior (= a sticky-tag thread works like any other thread in the all discussion tab) should not be also the behavior of the sticky-tag threads have when they appear in their parent tag.
For instance:
- Let's say I have a "ARTS" tag, and inside it I have sub-tags for each art ("PAINTING", "MOVIES", "LITERATURE", etc.).
- I put a sticky-tag thread in the "LITERATURE" tag only (for instance: "where to find books online").
- With the recent update, I can then check the "LITERATURE" box only (the thread will appear first in the "LITERATURE" tag, hidden in "ARTS" tag", and working like any other thread in "ALL DISCUSSION" tab)
- Or i can check the two boxes (it will then appear first in the "LITERATURE" tag, first in the "ARTS" tag", and working like any other thread in "ALL DISCUSSION" tab).
Maybe it would be more logical than, in the parent tag (here the "ART" tag), the thread would also appear, but working like any other thread (like it does currently in "ALL DISCUSSION" tab). The result will be, when checking only the "LITERATURE" box : the thread appears first in the "LITERATURE" tag, works like any other thread in the "ARTS" tag", and works like any other thread in "ALL DISCUSSION" tab).
It's more a question than a suggestion, because I'm not sure what option in the best.
I'm having a problem when I try to enable the extension it turns on and off and wont stay activated.
- Edited
TB54 summing up -- you're suggesting that secondary tag stickies should also be listed in primary tags as "regular discussions". Well this can be arranged, I might add this feature on 3.0.1 
But I need to think about how should I implement this though, feels like maintaining this extension getting complicated on every other release 
typ1k it's probably the foreign key issue.
Kylo check if the engine for the tags table is InnoDB or not. If not, try switching that to the InnoDB then run and try activating again:
-- make sure you have that db backup.
DELETE FROM `migrations` WHERE `migration` = '2021_07_04_000003_set_default_settings' AND `extension` = 'the-turk-stickiest';php flarum migrate:reset --extension the-turk-stickiestDROP TABLE `discussion_sticky_tag`;php flarum migrate