PHP equivalent of a web.config



  • I normally do .NET for a living and I normally use PHP for smaller web apps and web services that doesn't require all the extras that .NET provides.

    I am building a larger app in PHP and I've done some googling and I wanted to see if there was an equivalent of a web.config or app.config configuration variables, nothing stood out in a few google searches. In the past I made a config directory and used define for global vars, which works fine, but I wanted to know if there was a recommended way of doing it?



  • That's pretty much it actually.

    The other aspect to web.config is folder-specific configuration that applies to how PHP will be run, which on Apache is handled via .htaccess files, nginx does its own thing differently. (You can, for example, override the standard system memory limit for PHP with such things)

    But yeah in general that's your only real option. One thing you can do is have said configuration file outside of the web-root and include it that way but that's about it.

    Depending on server you're using, you might want to lock down config if it's inside the web-root.



  • I was hoping something nicer existed, I will make sure it is outside the web root.



  • Yeah, there's a reason PHP is often TRWTF.



  • @lucas said:

    I was hoping something nicer existed, I will make sure it is outside the web root.

    If you're using a framework, it will have a specific location for application config files.



  • I am using FlightPHP, is is mostly a DIY framework.



  • @lucas said:

    FlightPHP

    I've never heard of that one. I haven't used a microframework, but surely they have some guidelines on where to place specific types of files?



  • http://flightphp.com/learn#variables They have this but I wanted something more like the web.config app settings.



  • Is this more like what you expect?

    Are you stuck with that framework or would you be able to change to a different one?



  • HAHAHAHA no you're in shit creek.

    php.ini applies to every PHP application run anywhere. There is only one php.ini file, and it applies globally; if you’re on a shared server and need to change it, or if you run two applications that need different settings, you’re out of luck; you have to apply the union of all necessary settings and pare them down from inside the apps themselves using ini_set or in Apache’s configuration file or in .htaccess. If you can. Also wow that is a lot of places you need to check to figure out how a setting is getting its value.



  • I call BS on two separate levels.

    There are hosts which allow for multiple php.ini files, one for master and one for per-site use.

    Additionally, Apache .htaccess can pass some configuration options to PHP to override the master php.ini file.

    But I guess actual reality is a barrier to bile.


  • Java Dev

    Then again, I've ran into a situation where I had 2 apache servers, from different binary directories (don't ask), where the system installation on port 80, which I expected to use the default /etc/php.ini, was actually using an alternative php.ini configured in a different apache installation running as an unpriviledged user on a higher port.

    I didn't bother to try and find out why.



  • That's not the point.

    The point is you can't create a "patch" php.ini file that only implements the settings required for your application to work, and distribute it with the application.

    Which means if you have the scenario you mention, say there's 40 sites on a server and each one has its own php.ini. Oops, it turns out we set something wrong in the php.ini which might lead to a security issue, we'll just fix it-- oh wait we can't. We have to fix all 40 sites individually. And ensure their source is fixed so next time they get deployed they won't undo the fix for themselves.

    Hey look, you're in shit creek. Exactly like Blakeyrat said.


    The problem isn't that PHP was built the way it was; it's obvious that it's a system that's built by globbing together other shit by inexperienced designers. The problem is that ASP.net showed them a better way and they still haven't patched PHP to use the better way. They're still doing things the shit way.



  • This doesn't really help me solve my problem.



  • Correct.

    Your only real option is to create a PHP file full of ini_set and execute it first from all your scripts.



  • @blakeyrat said:

    The point is you can't create a "patch" php.ini file that only implements the settings required for your application to work, and distribute it with the application.

    Which means if you have the scenario you mention, say there's 40 sites on a server and each one has its own php.ini. Oops, it turns out we set something wrong in the php.ini which might lead to a security issue, we'll just fix it-- oh wait we can't. We have to fix all 40 sites individually. And ensure their source is fixed so next time they get deployed they won't undo the fix for themselves.

    Yes you can, that's what @Arantor said.

    I recently set up a new site on our virtualmin server. Each user/site gets their own php.ini-s (one master, one for website and one for cli, I think) that override parts of global ini-s. So, it's probably some terrible hodgepodge behind the scenes, but the end result is comparable to IIS/ASP.NET.



  • And of course hosts don't disable ini_set or anything. Oh wait, yes they do.

    You're not entirely wrong. PHP is a clusterfuck in a distribution context simply because most people want to use cheap-ass hosting that's so locked down and restricted it isn't funny.

    But as for 'ASP.NET showing them a better way'... that's debatable, but the reality of the matter is that it's PHP that powers a metric fuckton of the internet, not ASP.NET and to adopt your beloved would require breaking a very, very large percentage of the net. But none of that matters because @blakeyrat doesn't like it, of course.

    Am I saying I like things as they are? Fuck no. But I'm not blind to the challenges PHP has to face to rid itself of its sins. And I doubt @blakeyrat would actually know any of this since I doubt he's ever actually written PHP for production sites or actually dealt with these challenges.



  • @Arantor said:

    But as for 'ASP.NET showing them a better way'... that's debatable,

    ... not really, no.

    @Arantor said:

    but the reality of the matter is that it's PHP that powers a metric fuckton of the internet, not ASP.NET

    Popular == Good has always been a shitty argument, no matter what you're talking about. By that logic, McDonalds serves the best food ever.

    @Arantor said:

    and to adopt your beloved would require breaking a very, very large percentage of the net.

    Well a normal platform developer would be able to improve the situation without breaking all their old sites. But, considering the utter incompetence of the PHP team, you're probably correct on this one.

    @Arantor said:

    And I doubt @blakeyrat would actually know any of this since I doubt he's ever actually written PHP for production sites or actually dealt with these challenges.

    I have a PHP site, I wrote from scratch, in production right now this instant. Not an important one, true, but.


    BONUS Discourse bug: hitting "quote" somehow prevents "Undo" from working in the textbox. Or more specifically:

    1. Hitting "quote" can't be undone
    2. Hitting "quote" wipes out the undo history of the textbox

  • :belt_onion:

    @blakeyrat said:

    BONUS Discourse bug: hitting "quote" somehow prevents "Undo" from working in the textbox. Or more specifically:

    good luck if you ever try to CTRL+H to find+replace....
    fortunately for everyone, dicsourse has overwritten that as "INSERT HEADER, KILL UNDO HISTORY"



  • For me, that opens chrome://history/.



  • @blakeyrat said:

    Popular == Good has always been a shitty argument, no matter what you're talking about. By that logic, McDonalds serves the best food ever.

    If only that were the point I'm making.

    The point that flew over your head is not that it's better. It's that it's fucked over by that, meaning that it can't make significant changes in a short time without breaking all that compatibility. But I guess reality is a new idea for you.

    @blakeyrat said:

    Well a normal platform developer would be able to improve the situation without breaking all their old sites. But, considering the utter incompetence of the PHP team, you're probably correct on this one.

    The scale of the problem is far larger than your little mind can comprehend.


  • ♿ (Parody)

    @Arantor said:

    It's that it's fucked over by that, meaning that it can't make significant changes in a short time without breaking all that compatibility.

    This is only a legitimate blakeypoint when it's MS's backwards compatibility we're talking about.



  • Of course he's using MS as a poster child for b/c. And it's one of the things they generally get right.

    But PHP is not unaware of the situation it is in, and the discussions about going forward do often raise the discussions about b/c. It's certainly one of the huge discussions about PHP 7 in terms of how far it is acceptable to go in breaking b/c.



  • @lucas said:

    I am building a larger app in PHP

    And you are using a very light-weight, unknown* framework?

    Do yourself a favour. Choose a decent, well supported MVC framework. Modern frameworks remove at least 65% of the shit of dealing with PHP.

    Yes, they are all a bit shit in their own special ways, but Laravel, Yii or Symfony2 are going to be 1000000% better than some light-weight shit you found floating around on the web.

    Laravel is my choice - simply because of the relative ease of implementing unit tests.

    * unknown to me, which is not saying much. But I have been tech lead at a PHP dev house for the last year... so I do know some things about the fuck-up-fest that is PHP.



  • Bonus fun fact: Laravel uses Symfony2 components anyway. Wouldn't disagree on the rest though.

    Also, don't recommend Zend Framework.



  • @Arantor said:

    don't recommend Zend Framework

    Haha, ja. Don't go there.

    I left that off the list on purpose.



  • @scudsucker said:

    Haha, ja. Don't go there.

    I left that off the list on purpose.

    You know ZF2 is even worse, right?



  • @Arantor said:

    ZF2

    Can it be? Jesus wept.



  • Oh yes. The amount of boilerplate in their skeleton app is scary.

    At least ZF1 had some not-entirely-shabby components that could be decoupled and used on their own without being terrible.



  • I started using silex. Google use it in some of their demo apps. It has twig view engine, which looks like a php version on jinja.



  • Bonus fun fact: Twig is looked after by some of the people who look after Symfony and unsurprisingly Symfony recommends Twig as a template engine.



  • When installing it using composer it seemed to have pulled in symfony.



  • And this is why I tend to avoid Composer. In my case the stuff I do is usually stuff for systems where Composer is a distant dream of being able to play with.



  • Well it looks like silex is built on symphony ... It seems to work decently.


  • :belt_onion:

    @ben_lubar said:

    For me, that opens chrome://history/.

    From inside a text edit box? Doubtful. ## Heading ## More likely ## Heading ##


Log in to reply