In this new post to her blog Lorna Mitchell starts off a new series (based on popular demand) looking at building an RESTful server in PHP. Back to basics - no framework, just PHP.

In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved.

Her "basics" include:

• the routing to send everything to the main index file (a "front controller" of sorts) with the .htaccess settings included
• Handling the incoming request with a "Request" class
• Parsing the incoming parameters from the "php://input" stream

On his blog Martin Sikora shares a solution that many a Symfony developer out there might find handy for running their application in a shared hosting environment:

Some time ago (actually when I was making this blog) I posted on stackoveflow.com a question on how to configure Symfony to run on shared webservers where you can't change your website's document root. I solved it but forgot that I was asking and left it without any answer.

The main problem is that the DOCUMENT_ROOT for the hosting service can't be changed by the users of the shared host. To solve this he modified his routing rules (sfPatternRouting class) and changed his .htaccess file to rewrite things over from just "/page" to "/web/page" instead. A simple solution, but it might be evasive if you've never configured it before.

On his blog Brandon Beasley has a new tutorial for CodeIgniter users out there on how to create "vanity URLs" that are correctly handled by the framework's routing system.

Recently I worked on a CodeIgniter project that needed the ability to use vanity URLs and display stats about the user represented by the URL. For instance, suppose you want to pull all public data on a user from Twitter and display it within your web application on a customized URL such as http://mytwitterapp.com/brandonbeasley . The difficulty arose when the AUTO setting for URI protocols seemingly failed to handle the PATH_INFO protocol needed for Twitter callbacks and the REQUEST_URI protocol needed for vanity URLs.

His solution combines custom routing on the framework side and a bit of a change to the .htaccess to make the APP_PATH functionality work correctly. Then a simple controller can be created (in his case "User") and the username can be pulled in via the URI helper's segment() function. There's other ways to make this happen with the custom routing CodeIgniter offers, but this method allows for a more fine-grained approach.

Chris Jones has a new post to his Oracle blog today about a situation he found himself in with his recent Zend Framework application. The issue popped up when he tried to use more than just the basic controller.

I've been using NetBeans with Frameworks recently. I had no problem when doing a single controller example in Zend Framework, so I knew everything was installed OK and mod_rewrite was "working" fine. But I would click a URL that should be routed to a second controller and see an error [about the requested URL not being found].

His solution was to add a new line to his .htaccess file so Apache knew where to start the rewrite from (instead of it being relative) - a RewriteBase path.

On his PHP Genious blog Timir Shah has written up a new post looking at how you can configure URL rewriting (much like mod_rewrite) in an IIS7 web server running PHP applications.

Few days ago, I faced a URL rewriting problem on windows server. After checking the server configuration, I found that there is an II7 installed. After long research about this, I found that II7 is not support .HTACCESS. If youwant to male your site SEO URL friendly, then you have to use web.config file for URL rewriting instead of .HTACCESS. Now the question is how to make web.config file from .HTACCESS?

He compares the two formats, showing how different directives from the .htaccess file can be translated over. He starts with an example of default documents on either side - the .htaccess defining several "php_value" settings and the web.config setting some default routing and rewrite rules. He shows how to set up a few things on each side - error page redirects and setting up some custom URL rewrite rules for both sides (with examples).

Rakshit Patel has posted a tip to the Programming Facts blog that those out there wanting to upload larger files through your application - change your settings via one of three ways to tell PHP it's okay.

I have seen many developers who find difficulties when working with larger files upload in php. When files which are too large in size [...] If you are uploading file which is larger than 2MB size than here i am showing you the way to upload larger files using PHP.

The method's pretty much the same in each of the three methods. You can either have the settings in your httpd.conf (if you have access to it), in the php.ini or in a .htaccess file in the directory your PHP script is in.

From the ImproveSpeed.info blog there's a recent post about a quick way you can speed up your WordPress site (especially one that gets a higher load) by making some modifications to your .htaccess file.

It is known the importance of the page loading speed over the traffic of your blog. Recently there were a lot of discussions and probably the page loading speed will become an important SEO factor for google and other search engines. The main problem with the existing .htaccess file is that the RewriteCond directives checks the existence of a file on disk when it is not really required. Each access to disk increase the page loading time.

They show how to take the stock .htaccess configuration and modify it (still using mod_rewrite rules) to get a bit more fine-grained in the filtering of how requests are handled, things like having the index.php requests are forwarded automatically on or not caring about images or CSS.

NETTTUS.com has a new tutorial that talks about "pretty URLs" and how you can make them happen on your site by combining a bit of htaccess/mod_rewrite magic with PHP.

While some claim pretty URLs help in search engine rankings, the debate here is fierce, we can all agree that pretty URLs make things easier for our users and adds a level of professionalism and polish to any web application.

To illustrate how it works, they create a simple URL shortening site, showing the difference between the two different methods (htaccess in Apache and PHP's URL handling) along the way. The application's pretty simple - store a URL in a MySQL database to be accessed via a special hash coming from the URL.

Stefan Koopmanschap has a recent post to his blog about a small oversight (and gotcha other symfony developers should watch for) that he's made a few times when trying to work with a subdomain of his main symfony-powered website:

Quite often have I been staring at my virtualhost setup for the admin subdomain of this application, wondering why the hell it kept serving the frontend. I'd set the DirectoryIndex to backend.php, so why did it keep serving the frontend?

The culprit was something that's usually one of the first things set up when you load a new framework - the mod_rewrite rules in an .htaccess. Of course, since they were the default, things would get routed back to "index.php" instead of his "backend.php" as he wanted. To fix it, he moved these options out of the .htaccess and into the virtualhost configuration.

Brandon Savage has posted the next article in his "Scaling Up" series, a look at reducing the amount of "drag" your application makes through its processing path and some tips to help increase its "lift" out of some common problems.

The intuitive will note that many if not most of these suggestions are performance enhancements, not scaling techniques. Why then are they in an series about scaling? Scaling is about more than just adding hardware. It's also about making sure your system runs better. You can add lots and lots of hardware but you will someday be unable to compensate for bad queries and poor optimization.

Some of his suggestions include taking care of any sort of errors or notices (anything that could slow the script down by writing to a log), defining virtual hosts instead of making excessive use of .htaccess files and installing caching software to maximize code and information reuse.