Is your code portable to subfolders?

Have been dealing with a couple of PHP projects recently which have been a far bigger pain in the backside than I anticipated, and both had some of the same stumbling blocks.

In both cases, and in other projects I’ve seen, there’s a huge assumption that the code will be run from the root of a domain, and all url and routing management have this assumption baked in to everything they touch. What’s the answer? “Just make a new vhost!” typically. Quite a pain, and seems to be a real shortcoming of all(?) major frameworks I’ve looked at of late. I remember being a bit surprised at Zend Framework as far back as 2006(!) having this be the recommended way of building with the framework.

I’ve gotten more used to Java web stuff (or, at least Spring) which respects whatever pathing your app is deployed to.

redirect(uri:"/foo")

will redirect to bar.com/ if the code is deployed to bar.com, but it will redirect to bar.com/subbar/ if the code is deployed to bar.com/subbar

I recently hit this snag in a PHP project I picked up which uses Slim framework. There are dozens and dozens of URL and route references in multiple files, like

$app->get('/sample-url-path(/)', function() use ($app) {
and
$app->redirect("/");

and there’s no way to just have the code work normally under something like “http://localhost/slimdev/”. I *have* to create a new hostname and vhost just to get this to run. Am I missing a simple global config option someplace that wouldn’t require me to rewrite dozens of lines of code?

Are there any PHP frameworks that can work relatively from a non-root-domain URL invocation?

Perhaps I just need to roll with things, but it makes working with anyone else’s code (even based on a framework) that much harder.

Maybe try grabbing your own code sometime and reinstalling it in a ‘non-traditional’ way, and see how many assumptions you’ve baked in are really necessary, vs just using defaults.

Similar Posts

  • Laravel down migrations

    I get an email newsletter from Martin Joo every week or so. The newsletters generally have some useful tips around the Laravel framework or sometimes just general development tips. I’ve learned a couple of neat tricks here and there, and will continue to receive. This morning I received an email with a Laravel ‘tip’ regarding…

  • Bad I9 PDF form

    Have been needing to programmatically fill out an I9 PDF, retrieved from gov site. Should be fairly straightforward, right? Well… the field names are… a mess. Field names like topmostSubform[0].Page1[0].U\.S\._Social_Security_Number__Last_4_numbers_[0]topmostSubform[0].Page1[0].expiration_date__if_applicable__mm_dd_yyyy[0] topmostSubform[0].Page2[0].Employers_Business_or_Organization_Address_Street_Number_and_Name[0] and so on make it pretty… not straightforward to create a usable key/value combination to search and replace. But… today, I noticed it got…

  • laravel bulk imports

    Small note, mostly for myself, as a reminder that when doing large imports of data, you may not need each block to be processed as an Eloquent model. That code above would generally be faster as Obviously there are even faster ways – preparing your data in some text format, and using your DB cli…

  • Importance of backups

    Well… here we are.  10 years later, and … no backups.  Or… none of the data that’s important. Recently had a drive crash in my main server where this blog is hosted.  Had it happen 2 years ago, but the data was recovered, and I put everything on automatic backups.  Using virtualmin, a great control…

Leave a Reply

Your email address will not be published. Required fields are marked *