Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Detect unreachable Target URLs #28

Open
raamdev opened this issue Feb 19, 2015 · 7 comments
Open

Feature Request: Detect unreachable Target URLs #28

raamdev opened this issue Feb 19, 2015 · 7 comments

Comments

@raamdev
Copy link
Owner

raamdev commented Feb 19, 2015

It would be nice if WP Redirects could attempt to reach Target URLs when saving a redirect and notify the site owner when a 404 or some other error is returned.

It might also be nice to have an option that lets WP Redirects occasionally poll each Target URL to confirm the URL is still reachable and if it becomes unreachable to notify the site owner in some way, either via a dismissable Dashboard message, by a graphical indicator in the redirect row when viewing all redirects.

It would also be useful to have another column called "Target Status" that reports either "OK" or "Error"; that way a site owner with many redirects could easily sort the list by all redirects that have an error.

@jaswrks
Copy link

jaswrks commented Feb 23, 2015

👍 Love that idea. It would be really helpful. I'm about to bring a lot of Redirects from an old site into a new site. When I do, having the ability to check the status of each would be awesome.

@raamdev
Copy link
Owner Author

raamdev commented Feb 23, 2015

I'm about to bring a lot of Redirects from an old site into a new site. When I do, having the ability to check the status of each would be awesome.

@jaswsinc Ah, good to know! I'll make this a higher priority in that case. Thanks for the heads up! Any idea (even a rough one) when you'll be doing that, so that I can better plan when I need to have this feature added by?

@raamdev raamdev added this to the Next Release milestone Feb 23, 2015
@jaswrks
Copy link

jaswrks commented Feb 23, 2015

Approx. March 4th :-)

@raamdev
Copy link
Owner Author

raamdev commented Feb 23, 2015

@jaswsinc Thank you. I'm setting the WP-Redirects Next Release target date for Feb 27th, to include this feature.

@jaswrks
Copy link

jaswrks commented Feb 23, 2015

It might be cool (perhaps later) to also add an automatic screen grab to this feature. So in addition to checking the status code, we could provide a thumbnail of the source URL also.

See: http://www.websharks-inc.com/thumbshot/generator.php
~ click link at the top to reveal details about our API.

Why? Sometimes the status will be as expected, but the underlying resource might have changed. Scanning through a list of statuses, together with thumbnails, might make it easier to spot problems.

I'm imagining a config. option that would allow you to set a URL that could be used to configure the thumbnail API you want to use. In our case, we could use our own utility for this (URL above). However, it might default to one of many free services available for this.

@raamdev
Copy link
Owner Author

raamdev commented Feb 23, 2015

It might be cool (perhaps later) to also add an automatic screen grab to this feature. So in addition to checking the status code, we could provide a thumbnail of the source URL also.

Interesting idea! I assume such thumbnails would need to be cached/stored somewhere, right? To avoid having to re-fetch them unnecessarily? Or would you want them to always be re-fetched (when they're not cached in the browser) so as to ensure you're seeing the most up-to-date thumbnail?

@jaswrks
Copy link

jaswrks commented Feb 23, 2015

I assume such thumbnails would need to be cached/stored somewhere, right?

Yes. Most of the APIs will cache the images for you automatically. However, depending on the way you integrate it, it could require a cache be built by WP Redirects. Some of the APIs use a simple REST approach, while others will come with a PHP SDK and deliver raw binary data.

In either case, I think a cache of 7 days or less would be fine. Ideally, a cache time for this specific use case might be around 48 hours. The tool that I built has a default cache expiration time of 30 days. We'd probably want to change that for this use case.

@raamdev raamdev modified the milestones: Next Release, Future Release Jul 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants