While migrating pastium over to MongoDB (from CouchDB), I found [a] snippet in the routes.php file [that makes it so] when the user enters the application via the root url (/), he instantly gets redirected to /pastes/add (or a different URL if you have custom routes configured). This may seem ok at first, but there's a problem. It doesn't take URLs into account that don't live directly under the document root.

The snippet he references and others showing how to correct the issue are included - replacing the location array controller/action information with the static class information for the route in a match() call. For more information on the routing in Lithium, see these manual pages.

We recently devised a system to redirect old URLs in PHP so that you could avoid "page not found" errors (I suggest you read it before venturing further). In this article, we'll create a similar system for WordPress, the popular PHP CMS. [...] There's probably no need to worry about redirecting old URLs if you've been using WordPress since day one. The system is reasonably good at finding the right page, even if you change your permalink structure.

They show a simple way to update your theme to catch the "not found" pages and redirect them to another script for handling. This new script takes the request and looks through an array of options to see if there's a match, then redirects if there is (via a 301 HTTP status response).

It's often necessary to reorganize your site and change the URL structure but, assuming you have similar content, users should rarely encounter a "page not found" error. Producing unnecessary 404 pages is one of my top 10 development mistakes. In this article, we'll create an automated PHP redirection system that converts old URLs to a new address. It's not production code, but it will illustrate the basics so that you can adapt it for your own website.

They walk you through the creation of a 404 error handling PHP page, configuring your server to use it and making the mapping of new URL to old URL. There's even a bit to include if there's not a mapping for a requested page - returning a 301 HTTP header.

If you are a web developer and you've ever worked with PHP you have probably come across the PHP header() function in the past. You most likely used it to implement a hard redirect; but you may not have understood exactly what was happening behind the scenes every time you call this handy function. Let's take a look at what the header() function does and find some uses for it other than its most common use-redirects.

They look at what the header function is for, what HTTP headers are (and some examples) as well as a few examples of use outside of redirects including defining content types, response codes and cache control.

When trying to maintain a secure protocol on an Apache-based website, you can expect to deal with certain issues, especially if you're also trying to rank well in the search engines. [...] This article provides tips and solutions to help any web developer effectively manage the two most difficult problems in maintaining the secure protocol side of any website. These are the: Duplicate content and 301 redirection from the non-https to http version.

They recommend two things to handle the duplicate content issues: placing a meta tag on the https pages to keep them from being indexed (keeping the search engines from seeing the http and htttps as two different resources, thus two different sites to index) and using a canonical value in a link tag.

As far as the 301 redirects go, they include some PHP code that, if placed at the top of your pages, can detect if the protocol is https or not. If its not, it uses header to perform the 301 redirect.

If you need to follow redirects within your php code using Curl and the open_basedir is set you came into some trouble. If you disable this directive all your directories with a 777 permission are not safe (if one or more website on the same server has some security issues). If you don't have additional protections you should NEVER disable the open_basedir directive (at least if you're using 3rd party applications).

He writes up a simple cURL-based link checker to see which of the URLs in question would throw an error. He modifies it so that it checked the HTTP response code from the server and, if its a 200/302/301, you know things are okay and a shell_exec can be called to execute the file from that location.

They talk (briefly) about how the call to the page is passed off to the controller's action and how you can get more information into it via POSTed values.

There's also a look at redirection, from action to action in a controller (or even to another one) and a look at a very handy method of sharing functions between the child controllers - a "master" parent controller (in their case, AppController).

At the end, they throw in a bit about components - module and reusable bits of functionality that can be passed around from controller to controller, action to action.

This series of articles are excerpts from the Packt book CakePHP Application Development.

This post is about the consistency of frameworks. Consistency is key to a low learning curve. [...] Yesterday, my brother asked me how he could capture 404 errors in Cognifty, as he was building an app that relied on dealing with random URL patterns. [...] After talking for a bit, we decided that handing off the request to a standard service (or controller) was the best way to handle this type of "error". He started searching to see if other frameworks had a consistent, or at least documented, way of dealing with missing controllers.

In his research he found one framework - the Zend Framework - that handed them by default as an error and passed them off to that handler. Mark notes that, depending on your frame of reference, this may or may not be considered a true error.

His Cognifty framework handles things a bit differently. It allows you to change the presentation handler to redirect to another url if an error like a 404 is thrown - a technically "more correct" way of handling things.

When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content.

He points out two different ways to handle the problem - either manually append the message to the URL you're redirecting to or (a bit better method) store it in a session variable and remove it once its done. Several frameworks call this a "flash message". He gives examples of how to set this in two popular frameworks - Zend Framework and CakePHP.

More than half a million websites have been compromised in a new round of attacks that hacked domains in order to infect unsuspecting users' PCs with a variety of trojans. This ongoing campaign includes new malware hosting domains and new trojans variations. All of the sites are running older or misconfigured versions of "phpBB," an open-source message forum manager. Open-source popular applications like phpBB tend to be often targeted by mass scanning and exploiting tools.

The hack redirected visitors through several steps ultimately ending up on a page that tried to take advantage of errors in older Internet Explorer and RealPlayer versions. The article talks about exactly which viruses could have caused the problems and the wide range of sites (both in topic and location) that were effected.

The best way to protect you and your PHPBB install from something like this happening is to get the latest version of the software and learn how to configure it correctly.