We Removed Old Toolset Support Topics


March 17, 2022

These days, we finished the project for archiving and deleting old Toolset support threads. This was done to remove old topics with out-of-date information. You may notice that some old support topics you find in Google may not be available anymore.

Update: We Reverted The Changes

After receiving a lot of feedback from the Toolset community, we reconsidered and reverted all of the changes. All forum topics, no matter how old they are accessible again.

We want to thank everyone that voiced their opinion and helped us see the whole picture.

Why This Is Necessary

We found that old topics in our Toolset forum often provide out-of-date information. Such topics were also often popular on Google so Toolset users would follow them and use old solutions and outdated workflows.

For example, there are many old threads about designing sites using the Toolset Layouts plugin. However, Layouts is a “legacy plugin” and didn’t receive significant updates in years. Also, there are better solutions for building a site today, like Toolset Blocks. So, in this example, our new way of cleaning up the old topics will make sure that users don’t get confused by an outdated plugin.

In short, most of the old support threads were causing more harm than good.

What We Are Doing

From now on, our support forum will filter topics like this:

  • Threads older than 5 years are deleted – we consider these completely outdated and remove them permanently.
  • Threads older than 2 years are archived – we hide these from the front-end but their author can still access them after logging into their account.

Also, you can easily request us to un-archive threads from the last 5 years that you think are still relevant.

To do this, click the Request Unarchiving button and fill out a short form.

How archived Toolset forum threads look like with an option to request their unarchiving

Thoughts, Feedback?

We are aware that this change might be inconvenient at first, especially until search engines reindex our site and update their results. However, we’re certain that in the long term, this update will make it easier to find helpful, relevant information.

As always, we’ll appreciate your feedback and thoughts.


Comments 51 Responses

  1. Thank you. Good idea – and I wish this was done more often.

    There has been so much good information provided in the Toolset support threads, but the volume of old and no longer applicable information has made it a challenge to find the best answers.

    I’d rather see new questions posted than out of date information shared.

    • Hi, Peter, and thanks! Yes, that was exactly the reason why we did this. Actually, this is how it will work from now on. We automated this process using a daily cron. 🙂

  2. Sounds like a good plan. Nothing worse than spending time using an out of date solution and then finding the correct one.

    Haven’t heard from Toolset in a while. Anything exiting on the horizon?

    In any event hope all’s well with the Toolset team.

    • Hi, Stephen, thanks, yes, that was our finding when analyzing the support tickets in general. All is well, indeed. The team is currently focusing on resolving an important queue of bugs reported by Toolset users. The last I heard, they should be done with it very soon which means a bug fixing release should happen soon/next. When that happens, I will check with the team what’s next and when we can expect it.

    • Hi, Manolo! I’m not sure I understand. Do you mean, to update/archive only forum threads based on how popular/common their topic is?

  3. This is horrible.

    Right now searching in google where is chance to find solutions also on other sources (like stack overflow) is a nightmare with 404 in background.
    Other users on forums also hates this decision, becasue their libraries with some workarounds or tips from topics saved as bookmarks are not available anymore.

    Marking old threads as “May be deprecated” or simply “Deprecated” would do the trick without harming your clients.

    • Hi, Mateusz! I understand your frustration but this inconvenience will go away as soon as search engines reindex these pages which shouldn’t take long. Now, you’ll get a 404 page only for topics older than 5 years. The ones older than 2 years were archived and you can request from us to reinstate them.

      That being said, we already did try marking old threads as “Deprecated” but nobody paid any attention to such messages. Instead, we just kept getting support tickets where users ran into problems because they followed old and outdated threads.

  4. I appreciate this effort as well! However, I’m not sure that archiving/hiding from view posts older than 2 years is appropriate… I have often found useful info in posts of that age. Perhaps there could be a tag applied to them that allows us to filter for archived posts? Or, better yet, just allow us to filter and sort by date?

    • Hi, Nick, thanks for your thoughts on this. One of the problems is that there are thousands upon thousands of topics and it’s really impossible to use any logic/algorithm to sort them and decide which ones are still relevant and which are not. We based our decision on numbers and didn’t choose the threshold of 5 and 2 years randomly. That is the average age we found where most topics usually become outdated and problematic (2 years) or completely outdated and harmful (5 years).

      Also, 99% of users find tickets through Google, so adding any sorting/filtering controls in our forum wouldn’t help much because again, people simply use Google to find answers. 🙂

  5. To clarify, I wasn’t suggesting any manual evaluation of anything. But point taken re: Google not respecting any filtering, thanks for the explanation.

    Yet, still, surely there is some way to remove/block google from indexing old posts? Right now you’ve simply deleted the oldest ones, but how are the “archived” ones un-indexed? Is it that their crawler will no longer find them, or did you add some sort of noindex flag to them? Couldn’t you maintain them in the web-based search, while flagging them as noindex?

    Another idea is to automatically add some sort of banner on the old posts that says something like “Attention: this has been automatically archived. We no longer stand behind what might be contained in this thread. Please open a new one for up-to-date support on this issue”

    Also, filter/sort should surely be implemented regardless of whether the articles are fresh or stale – that’s literally a core feature of Toolset!

    • The threads that are archived show the message about it and provide the button/form to request its unarchiving, however, to Google, it’s returning a 404 code. So, as Google bumps into archived pages a few times, it will drop it from the index.

  6. I am pretty frustrated by this to be honest. I search for older support topics a lot, and am now finding it hard to look up some things from 2-5 years ago that I am sure would still be relevant.

    It is a shame you didn’t keep the 2-5 year old topics online, with a big disclaimer/popup saying that it might be too out of date to work. I know that some solutions from 2-5 years ago WOULD still work (Eg more complex [wpv-conditional] solutions), but now I can’t even find them and decide that for myself. I’ll have to submit a new support ticket instead each time, which will ultimately be more work for your team.

    • Hi, Alex! We’re thinking of a better approach on this one and will share more information with everyone early next week.

  7. Unfortunately, this also means that many legacy tutorials will be phased out. I’ve been really trying to work with the block editor for over 2 years. But the more complex the work becomes, the more confusing, inflexible and slower it will work. At the end I ran into “over processing erros”. I am currently really satisfied with the legacy editor. But there is a great fear that the Legay Editor will fade into the background more and more. I can understand that Toolset relies on the block editor as it is much more accessible especially for new users, but I dare say that anyone who knows both worlds and builds slightly more complex pages will always prefer the legacy editor. I hope that new functions like the announced integration of Open Street Map will also be possible with the legacy editor.

    • Hi, Torsten! There is no plan to remove or “phase out” the legacy part of the documentation. Actually, we even expanded it recently by reintroducing the section about using Toolset Maps with the legacy workflows.

      I’m not sure what “over processing errors” are but if you have a technical issue, it’s best to create a ticket in our support forum.

  8. Well.. this really is a disaster I must say…
    The fact that you are removing from the index is bad in so many ways. As Torsten pointed out, more legacy questions will be removed. Let’s dive inside blocks and Gutenberg (Yikes!).

    1 – I don’t work with Gutenberg, I mean… sure you are plugin developers and have to adapt to new WordPress standards but there is a reason why so many people hate Gutenberg… reviews aren’t getting any better in case you haven’t noticed. The topics you are blocking are mostly related to shortcodes, views, access, content templates, and so on.. which are the core for some (or many) of your customers. And this, of course, does not involve Gutenberg.

    Sure you have training pages.. with Gutenberg (…) and Blocks (…), but honestly, I don’t know the majority of your customers but I do believe that those that work with Gutenberg don’t really know that there are better options to it.

    2 – I quote what was answered above to Mateus:

    “That being said, we already did try marking old threads as “Deprecated” but nobody paid any attention to such messages. Instead, we just kept getting support tickets where users ran into problems because they followed old and outdated threads.”

    I’ve never seen any “deprecated” tag or anything like that (perhaps it’s the thing you mentioned that no one cared? but I didn’t really see it. And building websites for more than 10 years i really think that if I didn’t see it perhaps it wasn’t meant or intended to be seen), in any forum topic, and almost every month I visit Toolset Forum searching for answers.
    Actually, I’ve rarely seen a topic whose solution didn’t help me or pointed me to the correct solution, as long as the goal of that question was similar to mine.

    Don’t take me wrong, but I don’t buy the “deprecated” thing. The fact that you archived and will unblock on request any forum topic leads me to believe that you are forcing users to keep an active Toolset subscription so that they can make that request or the question can be posted in the forum. I mean, you are a business, I understand that.. but in my opinion, there should be more transparency.

    3 – Alex pointed out exactly what I think. Even if the topic mentions a solution that is deprecated, that is always a reference from another user (or/and supporter) to the same problem, which could provide another approach to find the solution.
    I’ve found so many old topics that helped me with shortcodes, functions, etc… and ~90% helped me to reach a solution without the direct help of your support team. This action that you implemented (blocking old content) will lead to reaching out to the support more often, overwhelming your support team but making sure there is an active subscription, while your customers have to wait up until 24h for an answer that could be found in 5 minutes.

    • Hi, Pedro, thanks for the comment. We’re reevaluating how to adjust this. We have the backup of all removed threads, so no worries. We’ll share the new plan early next week and ask for your feedback.

  9. Absolutely counter productive idea. I’m not even heavily developing anymore but tons of my reference material is now 404, today alone I ran into a dozen references which are now gone forever, the source posts of fixed and custom code for production level websites… gone.

    At least let logged in users with valid licenses see these posts. Plenty of people in private have already been complaining, just wait for more details woolen with old toolset forum posts in their snippets saved as problem solving pages realize their problems are no longer solved.

    Put them back. Make a public post about the date in which you’re going to delete all of them, let us save the info we need (desperately need at times), and then phase them out on that date. Quite the rug pull situation here and am absolutely disappointed no internal toolset developers spoke up and said “well we reference all sorts of old posts -on GitHub and Reddit (as examples) on a regular basis so why would we keep OUR clients from doing the same?”

    • Hi, Nicholas! As I’ve added to the top of this announcement, we’ll suggest a better idea that works better for everyone. We also have the backup of everything, so nothing will be permanently lost. I’ll share more on Monday. Thanks for your understanding!

  10. I agree wholeheartedly with the last few posters… this is enormously frustrating. Not only the broken links in Google, but the diminished number of topics available. I understand that many topics may no longer be relevant, but any good troubleshooter knows that even in old or incomplete posts (and even sometimes in incorrect posts) there are hints and insights that get you down the path to success.

    And to have to request that posts be “unarchived” is even more frustrating and inconvenient. Like everyone else, I need an answer when I’m searching for it, not when someone digs it out of an archive. And if it turns out to be incomplete or not what I was looking for then what… I need to ask for another to be unarchived? PLEASE reconsider this decision. There must be a better way to make these older posts more easily available to your customers.

    • Hi, Keith! We’re working on another solution for this and you’ll find out more early next week when we announce it and ask for your feedback.

  11. Count me in on those who feel this is shortsighted, and who have personally already found this policy frustrating.

    Iterate don’t obliterate. The collective wisdom of your users and staff who have solved problems and shared their experiences is being cast out because some people don’t understand that old search results might not be best practices anymore?

    Sometimes it’s useful to search for a snippet of a problem “wpcf_ something” or [types etc] and to see examples beyond just a tutorial. You’re casting hundreds or thousands of those results out in the name of progress but I feel like it will slow down solutions. I had an issue this week and 3 times there was a result cached in google which clearly described an error message and I couldn’t get to the solution because the article on your site was gone. I had to submit a ticket after hours, wait through the weekend to get a result / response that I could have found immediately if you hadn’t made this choice. It was something small – a specific API on a different platform that I needed to tweak, but now it and hundreds of similar solutions are gone, forcing your users to retrace old steps.

    Blocks is wonderful, it’s the future – but sometimes a solution has to be done in Views, or a client needs to have an older site supported. Beyond that, there are ways beyond just tagging a result as Deprecated to handle that – changing default visibility to make it more conspicuous or forcing someone to click through an acknowledgement that ‘this answer is seriously out of date and you probably shouldn’t use the solutions found here’ but for the love of all that is holy, let us still get to it and make that determination on our own.

    ‘Don’t worry, the problem will go away when Google delists these results’ boggles my mind. I can’t fathom that as a viable solution.

    • Hi, George! We’ll announce another idea for handling this issue, early next week. We’ll also ask for your feedback, so this time, we implement something that will work for everyone.

  12. Looks like many others have shared my objections and a lot of reasoning. I’m glad you’ve heard it and look forward to the proposal that you come out with.

    But there are some crucial things that haven’t been mentioned yet.

    You say that the bulk of searches come via Google rather than on-site search. Have you ever stopped to consider the various reasons of why this might be?

    The obvious answer, as someone else mentioned, is that it is just our typical starting point in order to find answers from across the internet. As such, Google should not be blocked/unindexed just because it doesn’t appropriately show that something is old. Instead, you need to have a prominent banner at the top of the thread (like you’ve added to this post to notify us that you will be rethinking this plan).

    But, I strongly suspect that the real reason people search for Toolset support via Google is because your searching mechanism is ABYSMAL. And I’m not just talking about the complete lack of filtering, sorting etc…(which is dumbfounding, given that this is the core feature of Toolset…). The biggest problem is that your search is unbearably slow and shows only a handful of results per page. It also just doesn’t give very good results. It is therefore an enormous exercise in patience to try to navigate your search tool.

    So, I tend to go to Google and type “site:toolset.com [support query]” in order to instantly have a long list of results that tend to be sorted by some meaningful measure of relevance. Moreover (and I’m just guessing here as I write this from my phone) I believe I can use their search tools to filter for when the page was created.

    So, it seems to me that your task is as follows:

    1. Undelete and undeprecate everything. There’s a wealth of info that people still need given the power of legacy vs the limitations of Gutenberg. There’s also other people who just don’t and won’t use Gutenberg.

    2. Add a prominent notice to older posts to suggest that it might be out of date. Though, frankly, that shouldn’t be all that necessary – as others have said, when I go to stack overflow etc…, I can see that something is 7 years old and evaluate it appropriately.

    3. Vastly improve your search performance. If you’re not using your Relevanssi integration, then that would be step 1. If you are and the performance is still slow, either you need better hosting/site optimization, or have to move to a more powerful search tool like elastic or solr. (p.s. Integrating Toolset with a search engine like those would be massively useful for users and, I suspect very commercially profitable for you – it’s not all that hard to set up one of them on a server, but it’s hard to integrate them with WordPress. Being able to do so through your beautiful Blocks interface or even legacy workflow would be a godsend)

    4. Make your search page actually use Toolset Views… It should have filters for tags, categories, dates, users, etc…

    I think all of that would go a very long way to improving our support experience while vastly reducing the load on your support team. I look forward to the proposal that you guys will be sharing and hope that you will be just as receptive to feedback on it as you have been here!

    • Hi, Nick, thank you for a detailed follow-up, I will pass it on to the team.

      Just a note… People use Google because they simply use it for everything. I do the same, no matter what information I’m looking for. The other day, I had an issue with my Deezer app. I didn’t go to their site and search for the solution, I used Google. And this is simply what most (not all) people do.

  13. And a couple more ideas

    Remove any noindex tags that might prevent search engine indexing. It’s a valuable tool for all users.

    Add relevant post excerpts with highlighting to the search results so that we can see at a glance if the item is what we’re looking for. Again, if that’s not immediately possible with Relevanssi, then it is another reason to offer an easier integration mechanism with tools that can do this (Ajax search pro, Search wp and elastic/solr definitely can).

    • Hi again, Nick. it’s an interesting idea, but honestly, we’re not looking to revamp our entire forum search at this time. That really wouldn’t solve the problem at hand where people run into trouble because they follow outdated tickets. We didn’t invent this issue, it’s a real one, and besides complaints about the removal of old tickets, we also got people saying “Great, it was really confusing having such a mixture of outdated and still relevant tickets”.

      But OK, let’s see what we can do that would work for most of the people (it’s usually impossible to please everyone). 🙂

  14. I EMPHATICALLY beg to differ – a better search functionality (speed, filtering, highlighted excerpts), along with notifications that something is perhaps out of date, as well as the ability to click on tags/categories to search relevant topics, and perhaps even an actual listing of possibly relevant topics, would be enormously useful in helping people find what they need. This is all standard procedure in any good support forum, search engine etc…

    Again, it really needs to be made clear – your searching mechanism is absolute trash. It is one of the worst I’ve ever used. This, along with a generally slow website (it takes like 5-10 seconds just to log in!) can only result in redundant support queries, dissatisfied customers, and perhaps even cancellations.

    Moreover, solving these problems for your site would ultimately make Toolset a far more powerful and attractive tool for your current and prospective users. It would also tangibly showcase what Toolset is capable of. And, at the very least, you’d be eating your own cooking by actively using the tools that your clients are using…

    • Hi, Nick! Just to let you know that we’re reversing the changes to the forum. It’ll take a few days. Thanks for your understanding!

  15. As Nick stated, “So, I tend to go to Google and type “site:toolset.com [support query]” in order to instantly have a long list of results that tend to be sorted by some meaningful measure of relevance. Moreover, I believe I can use their search tools to filter for when the page was created.”

    This!! site:toolset.com [support query] is exactly how I have always found threads on Toolset’s forum, and then have bookmarked them in categories in my browser for later reference.

    There’s a wealth of knowledge and custom code in those older threads that I’ve depended on for years. And so much of this is NOT outdated.

    That said, my main use of Toolset is Views legacy. I hand write my frontends to create progressive web apps and legacy Views is the workhorse I depend on.

    The fact that Toolset refers to the original views as “Legacy” scares me. How is providing your users a powerful Views code editor that is tried an true now legacy? Simply because you are trying to push us to Gutenberg/Blocks? Isn’t Views ‘Legacy’ just an alternate approach to development? In the downloads section Views without blocks built in is considered legacy. And your documentation these days I suspect would give users the impression that blocks is the way to do everything, and it is not.

    Blocks/Themes/FSE is of no interest to me and the work I do, but alas I’m sure I am nothing but an edge case.

    I also echo the sentiment regarding your forums search/filtering (or lack of) system. This needs to be addressed undoubtedly.

    That said, I applaud Toolset for listening to their users and considering an ‘about face’ on their decision to simply remove all these older threads. Not every company would do the same.

    • Hi, Jay! Just to let you know that we’re reverting the changes to our forum. I updated the start of this announcement post accordingly.

      We still support the legacy Views workflows and we’ll continue to do so, so of course, use the workflow that best suits your needs.

  16. The difference is those saying “good idea to delete old stuff” weren’t using it or bothered it existed in the first place.

    Like cleaning out someone else’s basement. I’m happy with their basement being cleaned out, I’m sure a few of the family members are too, though weren’t really bothered by the storage room in the first place, nor will use it in the future now that it’s empty.. but the kids who felt their possessions were stored in it are going to be pretty upset.

    That’s me.

    The kid who no longer has his Pokémon card collection, except it’s negatively impacting my ability to develop on your software, immediately impacted my ability to do my job, literally within hours of you rugpulling all the historic data I reference, I was negatively impacted.

    For what?

    So people who weren’t using those resources can continue not using those resources?

    Ask your developers how often they refer to GitHub or use google to solve issues. Then tell them they’re no longer allowed to do that. No GitHub. No google. See how much work gets done.

    • Hi, Nicholas. Just to let you know that we’re reverting the changes to our forum.

  17. I really try to use Toolset Blocks as much as possible but as soon as I do anything with taxonomies or something out of the ordinary, I have to turn on the old legacy stuff because there’s things that are impossible to do in Toolset Blocks that are easy peasy in legacy.

    • Hi, Darryl! I understand what you mean. Legacy workflow is there whenever you need it and is not going away. Whatever you prefer! 🙂

      • I will hold you on that, Dario ! 😉
        The Legacy workflow is the only flow for complex use of toolset.
        Anyone who uses Toolset a bit more than level 1 filtering knows how important that is.

        Thanks for clarifying!

  18. Oh gosh.
    I am happy there is so much feedback illustrating why this is a bad idea.

    I just want to pile on:
    This is a bad idea!

    What’s with all the custom code solutions? They aren’t outdated even if tomorrow WordPress is to invent blocks 2, or whatever bright idea they might have.
    Updating custom data with forms, filtering views, etc etc…

    All those solutions would be (are already?) gone!
    But they aren’t outdated, at all, because the api stays the same!

    Well, there’s always internet archive (way back machines)

    This is really not a well thought through idea

    • Hi, Beda, thanks for the comment! We’re reversing the changes and the forum should be fully back in a few days.

  19. We need to get those files back. They are a very valuable source of information. It’s horrible news. Toolset is great thanks to the development and THANKS to the information contained in the publications, such as filters, own code, js… TOO. Please… we need that topics online again.

  20. An example why this is bad idea


    Custom code to Populate custom field with post title

    function tssupp_set_pp_title ( $post_id, $post, $update ) {
    $field_slug = 'practice-point-title';
    $post_type_slug = 'practice-point';

    // - bail on wrong post type or on pre-publish auto draft title
    $post_type = get_post_type( $post_id );
    $post_title = get_the_title( $post_id );
    if ( ( $post_type !== $post_type_slug ) || ( $post_title == 'Auto Draft') ) {

    update_post_meta( $post_id, 'wpcf-' . $field_slug, get_the_title( $post_id ) );

    add_action( 'save_post', 'tssupp_set_pp_title', 100, 3);

  21. From my point of view, this is really bad for us, and I would say for Toolset support service, too.

    Searching through those old posts helped me find clues on problems or ways to do things without asking for support, and I was able to find solutions on my own. Even if the answer was old or not updated to new versiones, most of the time the info was useful or gave us more clues to keep on the search to the right way, or to ask for help with much more knowledge of the issue. An example of this are the good amount of coding contained in the removed posts. I always work with the classic editor, and those codes have helped me many times to write my own.

    Now, I find lots of posts with the same issues I´m trying to solve, but 99% of those posts lead to 404 or “archived” messages. It´s definitely frustrating.

    Past experiences and past support replies are helpful in many ways, even if they are outdated.

    • Hi, Roberto! Just to let you know that we’re reverting the changes to our forum.

  22. Thank you Dario!

    I can’t imagine this aspect of your job being “the messenger” is a very fun one at times like these.

    Speaking for myself, and hopefully many others, we understand you aren’t the decision maker on things like this – even if it comes across as we are attacking you personally at times.

    Thank you for you listening, relaying our concerns, and keeping us updated!

    • Hi, Jay! Thank you for your comment. No worries, I don’t take it personally. However, like my whole team, I do take it seriously and never dismiss anyone’s comment, even if it gets “heated” at times. As long as the conversation is on a respectful level, we’re good. 🙂

  23. Hello Dario, the comments form here when clicking reply do not work, so I reply in a new comment.

    Thanks for your reply, and for the reversion of the decision, but if the new solution is what I see now – it does not solve the problem.

    Right now, I googled “how to change the default value of an address field in CRED”
    This thread came up

    There was a form on that thread asking me to request unarchiving of the thread.
    I completed it and it stated “the team will review it soon”

    Are you truly wanting me to believe that this is effective?
    1. Assume even only 10% of the toolset users request each one such thread daily
    2. The team reviewing it will have to review some … what is it, 5000 threads daily?!
    3. Further, I as a developer, or user, have to wait until it gets reviewed. And what if it gets rejected?
    4. I have to do that on each thread that MIGHT be the solution. I don’t even yet know if it is the solution
    5. The thread is 101% not related to blocks. How does removing this thread help you promote blocks?

    This is not a solution.

    I respectfully ask to either re-instantiate the previous threads which to many percents are not related to Blocks at all, or to provide us users access to the threads so we can externalise them.
    Me and several other power users of toolset not only rely on these threads, we make a living of it, and we are willing to maintain this on our own. If you would be willing to share the threads in an export with us, of course private replies removed, we could set up our own “legacy” threads server.

    I hope you can rethink this decision once more and put yourself in the shoes of an user that does perhaps not even use Blocks or Views. Are you planning to deprecate CRED, Access, Types? Because it certainly does look like that. It seems you want to make it harder for users, rather than simpler.

    The better idea would be probably to just not show Support Threads anymore to anyone, like it is when someone opens a new thread with the “Chat” feature, those threads are also gone, forever, and that was like that since the begin (also a decision I cannot understand)
    At least this would speak a more clear language.

    Thanks for understanding.

    • Hi, Beda. We’re aware of the issue with replying to comments here, the Systems team is already working on it and it should be fixed soon.

      About the forum issue… I’m not sure if you already got our second newsletter/announcement that I sent out yesterday, or if you saw the big blue update box I added to the top of this post but we need a few days to return the forum to its previous state (bring back the deleted threads and un-archive the archived ones). When this is complete everything will work as before and all threads will be there, no un-archiving needed. The only difference will be a short notice at the top of the old topics warning you that it might be outdated.

  24. Thanks for the reply Dario

    I didn’t receive a newsletter but indeed I saw both blue notice and as well your post in FB, which was what led me to comment here and there again because it looked like the “reverting” was this new form to request unarchiving.

    It’s clear now you just need more time to bring it all back and that form is temporary.

    This is very welcome, part of my life (literally) is based on those threads.

    Thank you kindly for the quick reaction and user oriented solution!