I have tested this item ✅ successfully on 1d0220d

This check can be removed: https://github.com/brianteeman/joomla-cms/blob/1d0220d57f1442654e6d3abd0771b0c36b65e163/administrator/components/com_redirect/views/links/view.html.php#L131

Noooo! Please NOT! Don't remove the archived state.

The archived state is perfect for holding links in the "background". If an archived link is visited again it doesn't occur again in teh list of new (unpublished) links!
All these f*** spam/hacker links etc.

On the other hand the "hits" counter is still rising. That's a good indicator if it's worth to create earlier "killers" e.g. in an htaccess file.

The deleted state then is good for really deleting links that are now handled by htacces or so.

So both states are fine.

For me this would be an extreme B\C break and dozens of pages will get problems.

That is what disabled / unpublished

On 6 Aug 2017 11:54 pm, "ReLater" notifications@github.com wrote:

Noooo! Please NOT! Don't remove the archived state.
The archived state is perfect for holding links in the "background". If an
archived link is visited again it doesn't occur again in teh list of new
(unpublished) links!
All these f*** spam/hacker links etc.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#17417 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8einLZicNLI1RmtDT4Y2aemle0y_ks5sVjYCgaJpZM4OusJ2
.

No, it isn't. Unpublished are newly collected 404 links that you see for workout when you open com_redirect.

Archived are old ones that I have pushed to the archive to not see them again and again when I open com_redirect. And where I want that they are not newly collected every day. And where I want to see how often they are used in the future.

com_redirect is not designed as a 404 analysis tool, it is designed to manage redirecting URLs and part of the way it helps the user with this is through the redirect plugin which automatically logs URLs triggering a 404 error page. So the archived state here really makes no sense with the tool's design; a record should either be published indicating that the URL is being redirected, unpublished indicating that the URL is not being redirected, or trashed/deleted because you don't want it in the table. The unpublished state is your "reviewed but chosen to ignore" state, then you can use the created date as a means for reviewing new records.

I never said that I use it as anlysis tool. That's not more than a positive side effect. Looks like my English is too bad. I explained it.

I'm working seriously with com_redirect for years now. For me it looks like that the most people do not.

Scenario:

• Bigger webpage, was hacked (spam redirects), wrongly configured over years, or relaunch or sth, x00 or x000 URls.

• Google and other search engines with hundreds of URLs collected over years and don't stop to test them again and again.

• Spammers and hackers using every day the same or different URLs, again and again.

• When you start cleaning this fiasco you collect over months every day dozens of new 404s.

• Some will be redirected, others not, maybe later or tomorrow reviewed.

• So, what's wrong with an additional state that helps you to organize the URL overviews more structured instead of ordering x hundreds unpublished URLs by date.

• What if you search for fragments in URLs to redirect them per batch? You have a growing mixture of URLs that you've already seen or not.

• What's technically wrong with a state archived that you can use or not?

• And that helps you to decide later on what you will do with these archived URLs. They are out of the focus at the moment but not forever. What does it help if they are somewhere hidden between unpublished URLs that you can order by date?

• Pure confusion.

And I use this work flow for years now with several webpages. And it's perfect. And I'm not the only one.
What's the problem with this state? Again: Don't use it if you don't want to use it but don't "kill" the efforts of guys that use(d) it.

And I'm still confirmed that this is a B\C break.

This PR removes a feature from com_redirect that's useful.

@mbabker should I close this or do you agree with me and this PR is correct?

Technically it would indeed be a B/C break removing support for a state. So this needs to slide to the 4.0 pile if we want to pursue it.

Thanks @mbabker I will refactor this for J4 soon.

Closed - see #17586 for J4 version