Sean Coates has posted a reminder for PHP developers (and really anyone executing command-line scripts) to use "env" instead of hard-coding the path to the PHP interpreter.

These [support] scripts often run PHP in Gimme Bar land, and we make extensive use of the shebang syntax that uses common Unix practice of putting #!/path/to/interpreter at the beginning of our command-line code. Clearly, this is nothing special -lots of people do exactly this same thing with PHP scripts. One thing I have noticed, though, is that many developers of PHP scripts are not aware of the common Unix(y) environment helper, env.

The "env" alias makes use of your currently defined include path to track down a PHP binary to use to execute the script. Since there's only a "best practices" approach to places to put PHP on a server, the "env" usage makes your script more portable and it's one less thing to remember to change.

If you distribute a PHP application that has command-line scripts and shebang lines, I encourage you to adopt the practice of making your shebang line "#!/usr/bin/env php". Note that this doesn't just apply to PHP of course, but I've seen a definite lack of env in the PHP world.

Henrik Bjørnskov has a quick new post with a security tip for those using the Symfony2 framework in its configuration.

Earlier when playing around with the Security component and SecurityBundle i found that for all paths you can specify a route name and the component will match it when check for the request paths.

Setting this up in your configuration gives you more control over the paths that are matched as well as more flexibility in defining them. He includes a note about a change you might have to make to the SecurityBundle's code to get the "check_path" part working correctly. You can find out more about the SecurityBundle's integration in this blog post from Pablo Bandin.

In a follow up to his previous post on using Neo4j with PHP, Josh Adell looks in a bit more detail about how to find paths in the data via a REST interface to the database.

The thing that makes graphing databases useful is the ability to find relationship paths from one node to another. There are many algorithms for finding paths efficiently, depending on the use case.

He includes some code showing the REST request (made via this client) to fetch these street-based relationships. He then creates a little sample script that provides driving directions from one intersection to another with a "findPathsTo" call. He modifies it a bit later on to use the Dijkstra algorithm.

On DZone.com's PHP on Windows section today Krzysztof Kotowicz has a new post talking about a file path injection exploit in PHP versions lower than 5.3.6.

Since the thing went public before new PHP version has been released, I present full details of the latest PHP vulnerability I reported - together with some sweet demo exploit. The issue was found with fuzzing being part of my recent file upload research. And I still have some more to show in the future :)

The issue, described in more detail here on bugs.php.net (as of the time of this post, unfortunately unavailable) and his code to reproduce the issue is here. Due to a bug in the code that should strip down the upload to just the filename, certain kinds of file paths can make it through. The real problem comes in when an application blindly uses this filename to write to, possibly overwriting important files. You can see a screenshot of it in action here.

Josh Adell has written up a new post for his blog showing some of his experience connecting PHP to Neo4j, a graph database (and open source project). It helps to solve a problem of related datasets and the difficulties that traditional RDBMS have with them.

Lately, I've been playing around with the graph database Neo4j and its application to certain classes of problems. Graph databases are meant to solve problems in domains where data relationships can be multiple levels deep. [...] As you continue to add degrees, the query becomes increasingly unwieldy, harder to maintain, and less performant.

Graph databases, like Neo4j, handle these sorts of needs perfectly. There wasn't an official PHP interface for it, so he decided to create his own that worked with the REST interface the database provides. He includes a few code snippets showing how to connect and make a few requests - setting properties on objects, relating objects to one another and making queries that follow the paths from user to user and return them as a simple array.

On PHPRiot.com there's a new tutorial showing you how to use the Douglas-Peucker algorithm to make the pathing on your map the simplest possible (the fewer points the better) having serious benefits a wide range of users, most notably those on mobile devices.

When drawing a path on a map (for instance, the directions from point A to point B) it is important to consider the limitations of the device you're drawing the path on. In this article, I will show you how to reduce the number of points in a path so the path can be displayed with minimal loss of quality on devices such as iPhone or Android-powered devices that may struggle with an extremely large set of points.

Using the GTFS service's data, he's been creating maps for an iPhone application. Naturally, a path with 700 points would take a lot of resources to render. Using the Douglas-Peucker algorithm he can reduce it down to a much more manageable 70 points. He explains the algorithm briefly and hows how to implement it in PHP with three classes - ShapePoint, Shape and ShapeReducer. The resulting reduced dataset is then passed directly over to a Google Maps for plotting.

From the HashBangCode.com site today there's a new post that revisits filtering with the filter_var function included with the language. The focus in this article is specifically in validating URLs with the FILTER_VALIDATE_URL flag.

Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.

Paul Reinheimer has posted something to think about for both developers and those planning out projects and features - the paths the users will take through the application, not just the features they'll have available.

There's a popular turn of phrase "pave the cow paths", which was introduced to me by my friend Chris Shiflett in one of his talks. The essence (as I understand it) of paving the cow paths is that it's easier to positively encourage users to act they way they already want to, than to have them change their behaviour.

[...] You can't hope to guess all the ways users will want to interact with your products. [...] You can however release your core feature with some flexibility and mind, then watch.

He suggests four ways that you can try to figure out these paths in your applications: by logging routes not just hits, give them somewhere to talk about their experiences with the app, open it up to outside interface (like APIs) and try to open it up for multiple kinds of use, not just what trends in statistical results.

Derick Rethans has been working on some updates to a tool he's developed, VLD, to make it more helpful and effecting in optimizing the opcodes in your scripts and find the dead opcodes and paths. He talks about these updates in this recent post.

Recently I've been working on some new functionality to visualise all the code paths that make up each function. These new routines sit on top of the routines that do dead code analysis. These new routines sit on top of the routines that do dead code analysis. Every branch instruction (such as if, but also for and foreach) is analysed and a list of branches is created. [...] Once all the branches and their links are found, another algorithm runs to figure out which paths can be created out of all the branches.

He illustrates with a few examples, showing both the command that was executed and the resulting output with the new path information of a simple test file using a "for" loop and an "if/else" conditional.

DevShed continues their validation series today with this new tutorial, a look at validating URLs, host and paths with the filter extension bundled with PHP.

Validation process performed on URLs [in the previous part of the series] was pretty simplistic. Thus, in this sixth episode of the series I'm going to dig deeper into the usage of the FILTER_VALIDATE_URL filter to show you how to validate different portions of a URL, including its protocol, host and eventual paths.

They enforce the filtering by adding in the FILTER_FLAG_SCHEME_REQUIRED or FILTER_FLAG_HOST_REQUIRED flags to the filters to ensure the information is valid too (not just in the right format).