404 page enhancements about govpress

[devinsays]

I think the idea behind no sidebar is that someone lands on this page by mistake- so you want to get them as quickly to their correct destination as possible. Some people jam a lot of slow loadings ads or widgets in their sidebar- which you wouldn't necessarily want to show. I put it back for now, but would lean towards no sidebar. (I'm not sure why the sidebar is displayed left on the link you sent. Is that a customization?)

I updated the styling for the search box.

I like Yoast's suggestion here of checking if they made spelling mistakes and offering suggestions:
https://yoast.com/404-error-pages-wordpress/

Leaving ticket open to work on this some more.

[lukefretwell]

No sidebar is fine with me. More than anything the extraneous info below is
confusing.

Like the Yoast approach especially the site map reference.

On Saturday, February 22, 2014, Devin Price wrote:

I think the idea behind no sidebar is that someone lands on this page by
mistake- so you want to get them as quickly to their correct destination as
possible. Some people jam a lot of slow loadings ads or widgets in their
sidebar- which you wouldn't necessarily want to show. I put it back for
now, but would lean towards no sidebar. (I'm not sure why the sidebar is
displayed left on the link you sent. Is that a customization?)

I updated the styling for the search box.

I like Yoast's suggestion here of checking if they made spelling mistakes
and offering suggestions:
https://yoast.com/404-error-pages-wordpress/

Leaving ticket open to work on this some more.

Reply to this email directly or view it on GitHubhttps://github.com//issues/34#issuecomment-35819570
.

Luke Fretwell
415.722.8678
[email protected]
http://lukefretwell.com

[ethanteague]

@lukefretwell , @devinsays , I've created a pull request here: #58 that does the following when a 404 page is hit.

1. Uses similar_text() function set to a tolerance of 40%, so posts and pages that are entered after the base url that are 40% similar (according to the function algorithm) will be returned on the page with a "Are you looking for a page/post like this?" message, followed by matches - we can increase or decrease the tolerance......this would be a good candidate for an adminable plugin if you guys ever wanted to package up a suite of plugins / turnkey kind of thing for govfresh.
2. Prints all categories below the results (with links).
3. I've removed the search box from the main content area - it's in the sidebar, at present.

I felt like printing out a full fledged site map seemed a little heavy duty, but if you want to do this, @lukefretwell , it's easy to implement.
Also, this could be used for search results, as well, kind of like a poor man's apache solr, returning near matches to what the user entered if 0 exact matches are returned.

[devinsays]

Hi @ethanteague. Thanks for getting involved with this!

Awesome idea, but I'm concerned that this functionality might be a little rough on servers. Have you done any performance testing? Let's say a site has 10,000 posts and pages. That's a big call to the database, and then similar_text is run over each of them.

Even if it did function fine- let's say a number of posts start to 404 for some reason on a high traffic site. Then you have dynamic searches happening for thousands of concurrent users.

[ethanteague]

Hey @devinsays - thanks for allowing me to play! I really dig what you guys are doing.
You are right on with your concerns, and I didn't think too much about really content deep sites, because similar_text() is pretty fast. Sooooooo.......I changed up the logic a bit (pushed and reflected in pull request) to cap the maximum number of posts that can be queried (newest to oldest) at 1000. I generated 3000 posts, and 3000 pages (6000 pieces total), and tested multiple ways:

1. No limit on #of results returned: result time = 3.36 seconds
2. 3000 results: result time = 2.60 seconds
3. 1000 results: result time = 1.32 seconds

Running mysql performance monitoring tool "MyTop" never went below 70% efficiency ratio in my testing, and at 1000 results (imo, the ideal #), was running at 86.4% efficiency.

So, I think setting the max results @ 1000 might be a solution to keep server performance where we need it to be, when considering the potential for multiple users concurrently hitting 404's.

[ethanteague]

Added an additional safeguard = getrusage() check to determine whether or not to invoke the "Are you looking for...." piece of the script. If a server response takes longer than 100000 ms, this piece is not executed, so if server load starts to increase such that response times are suffering, we don't do the heavy stuff and just deliver a list of categories. Thinking this makes 404.php bulletproof.

[devinsays]

Anything with dynamic results is going to be uncacheable and could cause issues if it was targeted or suddenly received a ton of traffic. It's a neat idea but I think it's safer to let this one go.