The TutsPlus.com site has posted the first part of a series wanting to help you secure your WordPress installation even more effectively. In part one of the series they cover some of the basics of securing the installation itself and the environment it lives in.

Do you think WordPress is secure? It's OK if you don't, because many people think WordPress is an insecure content management system, yet it's very far from the truth... at least today. [...] I'm sorry if you think the other way, but it doesn't. Frequent patches don't necessarily mean that a piece of software is poorly coded against security threats.

[...] The important thing here is to be responsive and preemptive, and that's something that WordPress excels at. [...] Yet, nothing is a hundred percent secure. We're living in times in which scientists are about to crack the code in our brains! Nothing is impenetrable, including our brains apparently, and WordPress is no exception. But the impossibility of 100% security doesn't mean we shouldn't go for 99.999%.

The remainder of the post is broken down into two different tips with the code/configuration changes and descriptions for what you need to update:

• Securing the .htaccess File
• Security Tricks for the wp-config.php File and Its Contents

The second item on that list also gets into some of the constant definitions and some advice on generating good "salt keys" for the configuration.

The ProDevTips.com site has a tutorial posted showing you how to proxy requests with PHP on Ubuntu using Apache 2.4 and PHP version 5.4 or later.

I’ve just had to evade a Russian block of one of my employer’s sites, let’s call it CasinoX. Presumably they had blocked both www.casinox.com and www.casinox.com’s IP address (which is a Cloud Flare IP btw).

Simply pointing ru.casinox.com to the real IP address of www.casinox.com’s server was a not a viable solution though as that would expose the real IP publicly which is a no-go in the online casino business as it is basically an invitation to be DDoS’ed.

The solution they came up with was to set up a server that operates as a proxy and sends all traffic to the actual web server, save the assets (images, Javascript files, etc). They include the changes you'll need to the .htaccess configuration on the proxy server to forward the requests. Then they show the updated version of your virtual hosts configuration to match these changes. From there the rest of the handling lives in PHP. They include the code for the index.php proxy handling, a Proxy class that makes curl requests to the actual web server and an ip_in_range function to get the actual IP of the user/client making the request.

Kevin Schroeder has posted the results of some research he did around using the "AllowOverride" setting in Apache. He found some interesting differences when it was set to "all".

Commonly known as .htaccess, AllowOverride is a neat little feature that allows you to tweak the server’s behavior without modifying the configuration file or restarting the server. [...] Beyond the obvious security problems of allowing configuration modifications in a public document root there is also a performance impact. What happens with AllowOverride is that Apache will do an open() call on each parent directory from the requested file onward.

He includes the output from a strace call in the post - first showing the function calls with it set to "none" then the same request with the setting on "all". More "open" calls are being made in the second run, increasing the execution time by a decent amount.

In this new post to his site Kevin Schroeder takes a look at the performance difference between Apache+mod_php and Nginx+FastCGI and why the second is noticeably faster than the second.

I was originally going to write a blog post about why NginX with FastCGI was faster than Apache with mod_php. I had heard a while ago that NginX running PHP via FastCGI was faster than Apache with mod_php and have heard people swear up and down that it was true. I did a quick test on it a while back and found some corresponding evidence. Today I wanted to examine it more in depth and see if I could get some good numbers on why this was the case. The problem was that I couldn’t.

He uses a "hello world" script as a baseline to do some testing and the ab to run the numbers. His results show a pretty significant difference between the two setups and an "strace" on Apache showed a clear "winner" as to why it's slower (reading the .htaccess file). Once he turned this off, though, Apache jumped up and started performing better than Nginx.

This all makes sense. mod_php has PHP embedded in Apache and so it should be faster. If you're running only PHP on a web server then Apache still seems to be your best bet for performance. And if you are seeing a significant performance difference then you should check if AllowOverride is turned on. If it is, try moving that into httpd.conf and try again.

Hasin Hayder has a quick post to his blog today about how you can configure an AppFog instance to be able to run Zend Framework-based projects on them.

AppFog is quite a popular polyglot PaaS (Platform as a Service) provider and it comes with a generous free plan for the developers. [...] Recently, I was looking for a solution on how to host a Zend Framework based application in AppFog. The main problem was that the url must point to the /public folder inside the app and from there it is initialized. After searching for some time, I found the clue in AppFog's doumentation which is you'll have to redirect all the traffic from the parent domain to the /public/index.php file using the URL rewrite rules.

The rewrite rules are included in the post for easy cut-and-pasting. With the recently announced closing of their phpFog service (in favor of just supporting AppFog) I'm sure this tip could come in handy for a lot of developers out there.

In this new post to his blog Gaurish Patil shows users of the Yii framework how they can update their configuration settings to hide the "index.php" in their requests and make cleaner URLs.

Finally we figure out the basics of Yii. While working on basic of Yii, I want to rewrite the url to SEO friendly. So I started to search on google, forum got useful information here http://www.yiiframework.com/doc/guide/1.1/en/topics.url To hide the index.php from url I did changes in config/main.php [...] and I created new .htaccess file in the same directory as my index.php file.

The changes are pretty simple - it's mostly a change to the "urlManager" setting to provide some rules for mapping controller and actions to the right place. The .htaccess file uses Apache's mod_rewrite functionality to grab the requested URL and remap it back to lay on top of the "index.php" front controller for the request.

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.