Jump to content

Trigger 404 "manually"


yellowled
 Share

Recommended Posts

For a chronological news archive, I use url segments to emit news listings per year – …/2012, …/2011 etc. The template creates a list of years for which the site actually has news posts in store, but of course, users might get the idea to edit the url segment manually, i.e. enter something like …/1974 in the browser's address bar. The template covers this by emitting a "no news available" message, but I'd rather it would throw a 404 for future years and years without posts.

The "check if the url segment matches a year which makes sense" part I got down, but how do I trigger a 404 manually? (Please excuse me if this has been covered before, but "url" and "404" make this kind of hard to search for due to the 3-letter search terms. :))

Link to comment
Share on other sites

  • 4 weeks later...

We can actually change the three letter word check - I think it's actually a built-in restriction of mySQL more than anything.

ryan - do you think it's worth making it possible to search for three letter words on the forums? If so I can certainly dig out the solution as I had to implement it elsewhere last year. The only downside is that on very busy sites this can add overhead when people put the word "and" in the middle of a search query and it goes off to find that word, which must appear in most threads which is the reason I think mySQL uses four letters as the minimum by default.

Link to comment
Share on other sites

Well then you have to have a list excluding "the" and so on.

If I find the article with the solution I'll dig it out as I'm fairly sure it lists all the pros and cons as well.

Link to comment
Share on other sites

ryan - do you think it's worth making it possible to search for three letter words on the forums? If so I can certainly dig out the solution as I had to implement it elsewhere last year. The only downside is that on very busy sites this can add overhead when people put the word "and" in the middle of a search query and it goes off to find that word, which must appear in most threads which is the reason I think mySQL uses four letters as the minimum by default.

This is the MySQL ft_min_word_len setting (fulltext minimum word length). It's 4 by default, meaning it won't index words fewer than 4 characters. If we change it to 2 or 3, then it'll index words down to that size. Words like "the" or "and" are considered stop words (among a few hundred others), so they won't get indexed, regardless of what the ft_min_word_len setting is.

I would guess that making IP.Board support fulltext indexing of words fewer than 4 characters would be exactly the same way that you'd do it in ProcessWire. Lets say you want it to index down to 2 characters:

1. Edit /etc/my.cnf and add this to the top:

[mysqld]
ft_min_word_len=3

2. Save and restart MySQL (either from command line or WHM).

3. Open the database in PhpMyAdmin, check the box for all tables (or at least those using fulltext indexes), and click "Repair" in the select box at the bottom.

After that it should work. The only problem here is that ft_min_word_len is a server-wide setting. So if there are other databases on the server using fulltext indexes, they also need to have their indexes re-created (by running the repair, as described above). If the databases are left un-repaired, their indexes will get corrupted and eventually start throwing errors. That is fixed by doing the same repair operation, so might as well do it sooner than later. :)

I will take care of changing this setting and repairing all the relevant databases when we launch the new PW site.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...