14 ms·

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated

Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. PHP files can be deployed independently, swapped out or updated live. No building/compiling of the php files needed. A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed. Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.

enz 8y ago
Plain PHP files work that way. But what if you use a framework (even an in-house one)? Does this holds true?
- jszymborski 8y ago
  Yup :) You very much just `git clone` a Laravel project, point Apache/NGINX (with PHP-FPM configured) to the `public` folder and all you need to do is run database migrations (for the majority of basic deployments).
  - hnzix 8y ago
    I inherited a Symfony2 app and it was a bitch to deploy. It definitely had an asset pipeline. php app/console cache:clear --env=prod --no-debug php app/console assetic:dump php app/console cache:warmup --env=prod --no-debug chown -R apache:apache . # fix owner chmod -R u=rwx,g=rwx,o=rx app/cache # fix cache perms apachectl restart # bounce Apache, otherwise it can throw segfaults
    - 0x0 8y ago
      That chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.
      - daledavies 8y ago
        This is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.
        deckiedan 8y ago
        How I've been running multiple wordpress installs for years: user: $sitename - the 'owner' of the whole hosted dir. rwX user: $sitename-PHP - the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files. user: nginx - can read all files except the wp-config.php file, which is limited to only the $sitename group reading it. then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them). Works pretty well for me.
      - gdfasfklshg4 8y ago
        The chmod is pretty suspect as well.
        y4mi 8y ago
        its really not... cache is the equivalent to /tmp check permissions there sometimes.
        8y ago
- mikl 8y ago
  Generally, no. Almost any framework has build steps these days, at least `composer install` to get all the dependencies, and usually also special web server configuration, so you don't expose all your PHP files to the web, only the index.php entry point.
- msie 8y ago
  Hmmm Symfony uses routes declared in a file...
combatentropy 8y ago
Apache MultiViews makes pretty URLs easy. www.example.com/widgets.php can be reached at: www.example.com/widgets But here's the kicker: www.examples.com/widgets/123 will also route to widgets.php, with "/123" in the $_SERVER['PATH_INFO']. No mod_rewrite needed. www.example.com/widgets/you/can/have/multi-segment/paths goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't usually go that far. Usually the script name roughly corresponds to the name of a table (or database view), and the PATH_INFO corresponds to the primary key.
- sebcat 8y ago
  Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this. [1] https://www.vdoo.com/blog/vdoo-discovers-significant-vulnerabilities-in-axis-cameras/ https://www.vdoo.com/blog/vdoo-discovers-significant-vulnera...
  - combatentropy 8y ago
    If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't. 1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists. 2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661. 3. The attack then depended on a bug in dbus, CVE-2018-10662 4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection. So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.
    - sebcat 8y ago
      > It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket. a.srv ended up in PATH_INFO because index.html existed. The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.
flukus 8y ago
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. > Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed. This isn't really php specific, with cgi you can do that in any language, even compiled ones like c. > Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. Agreed. I must admit I'm guilty of this myself, there is a tendency to start with a framework when there are much simpler and quicker ways to get started, something the world seems to have largely forgotten.
viraptor 8y ago
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Which becomes a security issue due to accidental endpoints or uploads becoming endpoints. Or becomes a mess of imports. Either way, PHP frameworks often end up with a central router anyway. > PHP files can be deployed independently, swapped out or updated live. Which means some people try to do that the naive way and end up breaking a few requests that happen during the deployment. > Can be as easy as editing a php file in notepad and dropping it on a ftp server. Which causes https://stackoverflow.com/search?q=headers+already+sent+bom&mixed=1 https://stackoverflow.com/search?q=headers+already+sent+bom&... because people don't realise they had an invisible character before all the code. I really don't think any of those are a good thing.
- trixie_ 8y ago
  You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework. PHP is much less complex than most.
  - agumonkey 8y ago
    no, seriously, the old dynamic script as program requiring a web server needed to be configured properly to avoid leaks of a thousand faces .. thanks but no thanks I'll be flask-ing
    - KerryJones 8y ago
      Just use Laravel and its eco-system, it's just as easy or easier to setup than Flask and easily production ready. This is an old-take on PHP and no longer true in 2019.
      - agumonkey 8y ago
        I know about laravel, but that above comment mentioned LAMP era as golden .. you know
  - viraptor 8y ago
AmericanChopper 8y ago
>Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. This doesn’t seem to be a language choice problem, it seems to be a monolith problem, where PHP simply managed to avoid some of the traditional monolith issues by design. Your CD pipelines in any micro service architecture should solve these problems, whether it’s using FaaS or containers, or whether it’s using a compiled language or an interpreted one.
- heavenlyblue 8y ago
  >> PHP simply managed to avoid some of the traditional monolith issues by design No - it didn't. PHP up to this day is a spaghetti mess it had always been.
  - venj 8y ago
    I really don't see what makes php a spaghetti mess. Spaghetti code is a skill issue, not a language issue
    - heavenlyblue 8y ago
      No, I am speaking about the ecosystem. Large, industry-grade projects developed in this language. What standards did Wordpress set a few years ago? Huge, disjoint sets of files spread throughout the themes folders. How much time does it take me to understand which of these files is causing the error? Do you still upload your code via FTP directly to the web server? Do you still reset the code cache for the PHP in order for that new code to become live? Well, I am going to be happy when your skill set is made redundant, because you are getting paid to know all of these quirks and they are not making the industry any better. You can write good code in _anything_. You could even write it on paper and then expense that to a person working for $0.01/hour to execute it. The question is whether the liability of your methods is lower than the liability of other methods. PHP is essentially the dinosaur from the times when SEO consultants made loads of money. They are still using PHP because they never knew anything better and the scale of the industry is enormous, so it's slow to change.
zepolen 8y ago
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Except in reality once you want to use non /whatever/file.php as urls - you're back to implementing a router > PHP files can be deployed independently, swapped out or updated live. Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed. Except in reality, you don't want to deploy directly after editing a file since it's like deploying to production, you're gonna have a bad time. > A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Except in reality, that just leads to a bunch of spaghetti code with no separation of concerns and impossible to maintain. > Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Except in reality, this only works with php apps that have an integrated package manager and even then it leads to problems when a version is incompatible both in php or plugin dependency. > Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. Except in reality, serverless lambda is a terrible idea: 1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work 2. when functions change you run into function incompatibility chaos and no smart way to handle that mess 3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't 4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement > Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP. Except in reality, you are notified of a bunch of potential bugs right there and then, instead of "maybe" finding out about them at runtime especially since PHP will by default consider a non defined variable just an empty string and display it as such on the page, and it's not until Joe User notices it that you'd ever find out.
- icebraining 8y ago
  Regarding (4) Lambda and friends are not actually stateless between requests; the process is initialized once and then potentially reused many times for hours, so you can cache between requests, both in memory or in the filesystem (AWS Lambda provides 512MB in /tmp).
vhakulinen 8y ago
> For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) I'm quite sure you can achieve this in golang with plugins[1]. That not as flexable as PHP, mainly because it involves a static type system and a compile phase (and more work in general). 1: https://golang.org/pkg/plugin/ https://golang.org/pkg/plugin/
- weberc2 8y ago
  Yeah, running plugins is not a difficult problem in most languages; it isn’t widely practiced outside of the PHP community because most folks don’t want to be the reason their users were hacked.
masklinn 8y ago
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. I mean that's just how CGI works, most every HTTP server still supports CGI, nothing stops you from deploying that way. Unless you're using Java or the like of course, then it's not very convenient.
- YawningAngel 8y ago
  You can absolutely do this in Java if you want to. I mean, it's insane and you shouldn't, but it's eminently possible.
  - masklinn 8y ago
    I'm not saying it's not possible I'm saying it really isn't convenient.
    - YawningAngel 8y ago
      But the reason why it isn't convenient is because the consensus amongst Java programmers is that it's a bad idea. It wouldn't be difficult to build tooling around if one wished to - I think in this case, the fact that almost every language has migrated away from CGI-style routing is probably telling.
      - masklinn 8y ago
        > But the reason why it isn't convenient is because the consensus amongst Java programmers is that it's a bad idea. It wouldn't be difficult to build tooling around if one wished to That's part of the inconvenience though, one of the advantages of CGI was the low tooling requirements. > I think in this case, the fact that almost every language has migrated away from CGI-style routing is probably telling. I mean sure, but beyond not being a very good protocol CGI needs to execute the handler script on every connection, Java is not known for that being cheap.
EmpirePhoenix 8y ago
-> What other web platforms can do this? Kinda all Java Webstuff is capable of doing this (Eg. installing Plugins in Atlassian products)
slezyr 8y ago
Deployment of Go services is much easier. Try to deploy any self-hosted service like nextcloud, gitea. It was a nightmare to deploy nextcloud. Also it turned to be too slow for ONE USER.
- Aeolun 8y ago
  Nextcloud is just a bad product :/ it’s hard to pin the blame on PHP.
  - slezyr 8y ago
    Still, it took quite long time for me to deploy PHP services. Didn't managed to get seafile(python) working at all. And it was relatively easy to deploy pair of Go services.
mikl 8y ago
This is pretty much a laundry list of anti-patterns for modern web development. Non-atomic deployments? Not using Composer to manage dependencies? No separation of concerns? Editing files directly on the production environment? I get that it's nice for beginners, but they're not benefits for professionals. We have better ways of doing things than Notepad and FTP.
- andai 8y ago
  vim and scp?
realharo 8y ago
>Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. The vast majority of PHP frameworks, even micro-frameworks, don't work that way. They route all traffic (except static assets) to an `index.php`, which then forwards it to a regular router.
- kalmi10 8y ago
  .. so you can live swap routes and endpoints even with dynamic routing (without performing any hot-reload dance in your own code), which actually sounds like a neat feature at first.
nkg 8y ago
Wordpress can instantly extend itself and its extensions can instantly self-f*ck the whole thing up. (Sorry for the WP hate, I forgot to take my pills)
eeeeeeeeeeeee 8y ago
You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress. Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”
- euph0ria 8y ago
  I really don't see how Wordpress is a valid argument here. We run several business systems in PHP serving hundreds of thousands of users. Last time I used Wordpress was over 10 years ago for my personal blog. Haven't used it for anything else. PHP is great for us, regardless of how Wordpress performs.
  - eeeeeeeeeeeee 8y ago
    I was primarily responding to the OP that used WordPress as an example of how easily you can add plugins (third-party PHP code). I see that as an anti-pattern, because it encourages non-developers to add PHP code into the system, much of it poorly written and insecure (or not performant). But that plugin system also is one of WordPress' greatest assets. And you can add PHP code to any part of a "theme" too. If you turned off the ability for themes and plugins to be "added live" then I don't think WordPress would be nearly as successful as it has become.
- x0hm 8y ago
  Wordpress is written in PHP. Wordpress is not PHP.
  - eeeeeeeeeeeee 8y ago
    Did I say that? Please don't twist my words. I was responding to the OP who was talking about the WordPress plugin system, which allows just about anyone to add third-party PHP code into the system. And those plugins have access to everything in the WordPress stack (and the file system for that user). And I think you can definitely argue that a low barrier to entry means that it gives beginners a lot of power they don't quite understand. Which is why I think most people steer towards common web frameworks, because not many people can know all the ways you can create security issues. Then you get into the complexities of various common web frameworks (Zend, etc) and you have to really wonder if the original OPs argument about simplicity and ease-of-use are worth that trade-off from using something else.
michaelper22 8y ago
> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Java: Use a classloader to load a JAR and instantiate one of its classes: https://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime https://stackoverflow.com/questions/60764/how-should-i-load-... .Net - use an AppDomain (or other methods): https://stackoverflow.com/questions/1137781/correct-way-to-load-assembly-find-class-and-call-run-method https://stackoverflow.com/questions/1137781/correct-way-to-l...
hrktb 8y ago
As other commenters point out, most PHP written today goes through a framework that negates most of these points (single entry point, modern architecture, code is precompiles/cached and optimised, simple and intuitive goes through the window) On the more general point, I am not sure scripting languages lend themselves better to lamdbas, as dependencies are usually external to the system. For instance PHP often relies on system json/xml libraries. Database access also needs to be precompiled and installed on the system, as would be crypto or internalionalization routines. Compared to that, I'd expect compiled runtimes can have one single "fat" binary that has most of the risky dependencies and only rely on the bare minimum provided by the system.
vorpalhex 8y ago
Routing is a feature because you can express more complex semantics. Most php apps depend on Apache specific .htaccess files to handle redirects and other routing, and it becomes a mess quickly. PHP files can be swapped out live because many CGI wrappers don't cache anything in memory, which means at high strain you start dealing with disk load, file locks, etc. There are many other languages which also don't require compilation, often at the trade off of less performance. Some really clever languages let compilation be an optional step. A single layer means your frontend logic, data models, and database access all run the risk of being one giant mess. Sure other languages run that risk too, but it's especially prevalent in PHP. PHP can extend itself - it can also be used to download attack vectors and execute them directly on the server with no concept of code signing. Other languages offer powerful facilities for remote updates if they're desired, but that's usually not the best approach for Web. You can edit other languages with notepad too. Being able to deploy a single endpoint to a live server and hoping it doesn't cause problems sounds like terror.
sephoric 8y ago
> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Since it's basically just doing eval(loadFile(...)), any language with eval() can do this, for better or worse. Which is like most of them. Perl, Python, Ruby, and Lua, to name the most common.
stcredzero 8y ago
I'm currently developing a facility to do live updating of processes with running game loops in Go. If one were to add in dynamically loadable libraries (working in Linux, last I checked) one could have the same facility for changing a single endpoint in Go. (It could also be implemented with small executables and reverse proxies.) I think what this demonstrates is that Go isn't a better PHP. Rather, we're at the point where Go could be used to build a better PHP. The most likely paths for this, are to somehow come up with a big group of developers with a penchant for doing this, and/or have some big company fund this.
ratling 8y ago
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Not if you're using... literally any modern framework and deploying it properly. This hasn't been the case in years except for common legacy stuff like Wordpress.
sandov 8y ago
The PHP workflow is definitely great for a lot of uses cases, but the language itself is horrible.

enz 8y ago

Plain PHP files work that way. But what if you use a framework (even an in-house one)? Does this holds true?

jszymborski 8y ago
Yup :) You very much just `git clone` a Laravel project, point Apache/NGINX (with PHP-FPM configured) to the `public` folder and all you need to do is run database migrations (for the majority of basic deployments).
- hnzix 8y ago
  I inherited a Symfony2 app and it was a bitch to deploy. It definitely had an asset pipeline. php app/console cache:clear --env=prod --no-debug php app/console assetic:dump php app/console cache:warmup --env=prod --no-debug chown -R apache:apache . # fix owner chmod -R u=rwx,g=rwx,o=rx app/cache # fix cache perms apachectl restart # bounce Apache, otherwise it can throw segfaults
  - 0x0 8y ago
    That chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.
    - daledavies 8y ago
      This is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.
      - deckiedan 8y ago
        How I've been running multiple wordpress installs for years: user: $sitename - the 'owner' of the whole hosted dir. rwX user: $sitename-PHP - the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files. user: nginx - can read all files except the wp-config.php file, which is limited to only the $sitename group reading it. then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them). Works pretty well for me.
    - gdfasfklshg4 8y ago
      The chmod is pretty suspect as well.
      - y4mi 8y ago
        its really not... cache is the equivalent to /tmp check permissions there sometimes.
        8y ago
mikl 8y ago
Generally, no. Almost any framework has build steps these days, at least `composer install` to get all the dependencies, and usually also special web server configuration, so you don't expose all your PHP files to the web, only the index.php entry point.
msie 8y ago
Hmmm Symfony uses routes declared in a file...

combatentropy 8y ago

Apache MultiViews makes pretty URLs easy. www.example.com/widgets.php can be reached at: www.example.com/widgets But here's the kicker: www.examples.com/widgets/123 will also route to widgets.php, with "/123" in the $_SERVER['PATH_INFO']. No mod_rewrite needed. www.example.com/widgets/you/can/have/multi-segment/paths goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't usually go that far. Usually the script name roughly corresponds to the name of a table (or database view), and the PATH_INFO corresponds to the primary key.

sebcat 8y ago
Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this. [1] https://www.vdoo.com/blog/vdoo-discovers-significant-vulnerabilities-in-axis-cameras/ https://www.vdoo.com/blog/vdoo-discovers-significant-vulnera...
- combatentropy 8y ago
  If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't. 1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists. 2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661. 3. The attack then depended on a bug in dbus, CVE-2018-10662 4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection. So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.
  - sebcat 8y ago
    > It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket. a.srv ended up in PATH_INFO because index.html existed. The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.

flukus 8y ago

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. > Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed. This isn't really php specific, with cgi you can do that in any language, even compiled ones like c. > Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. Agreed. I must admit I'm guilty of this myself, there is a tendency to start with a framework when there are much simpler and quicker ways to get started, something the world seems to have largely forgotten.

viraptor 8y ago

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Which becomes a security issue due to accidental endpoints or uploads becoming endpoints. Or becomes a mess of imports. Either way, PHP frameworks often end up with a central router anyway. > PHP files can be deployed independently, swapped out or updated live. Which means some people try to do that the naive way and end up breaking a few requests that happen during the deployment. > Can be as easy as editing a php file in notepad and dropping it on a ftp server. Which causes https://stackoverflow.com/search?q=headers+already+sent+bom&mixed=1 https://stackoverflow.com/search?q=headers+already+sent+bom&... because people don't realise they had an invisible character before all the code. I really don't think any of those are a good thing.

trixie_ 8y ago
You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework. PHP is much less complex than most.
- agumonkey 8y ago
  no, seriously, the old dynamic script as program requiring a web server needed to be configured properly to avoid leaks of a thousand faces .. thanks but no thanks I'll be flask-ing
  - KerryJones 8y ago
    Just use Laravel and its eco-system, it's just as easy or easier to setup than Flask and easily production ready. This is an old-take on PHP and no longer true in 2019.
    - agumonkey 8y ago
      I know about laravel, but that above comment mentioned LAMP era as golden .. you know
- viraptor 8y ago

AmericanChopper 8y ago

>Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. This doesn’t seem to be a language choice problem, it seems to be a monolith problem, where PHP simply managed to avoid some of the traditional monolith issues by design. Your CD pipelines in any micro service architecture should solve these problems, whether it’s using FaaS or containers, or whether it’s using a compiled language or an interpreted one.

heavenlyblue 8y ago
>> PHP simply managed to avoid some of the traditional monolith issues by design No - it didn't. PHP up to this day is a spaghetti mess it had always been.
- venj 8y ago
  I really don't see what makes php a spaghetti mess. Spaghetti code is a skill issue, not a language issue
  - heavenlyblue 8y ago
    No, I am speaking about the ecosystem. Large, industry-grade projects developed in this language. What standards did Wordpress set a few years ago? Huge, disjoint sets of files spread throughout the themes folders. How much time does it take me to understand which of these files is causing the error? Do you still upload your code via FTP directly to the web server? Do you still reset the code cache for the PHP in order for that new code to become live? Well, I am going to be happy when your skill set is made redundant, because you are getting paid to know all of these quirks and they are not making the industry any better. You can write good code in _anything_. You could even write it on paper and then expense that to a person working for $0.01/hour to execute it. The question is whether the liability of your methods is lower than the liability of other methods. PHP is essentially the dinosaur from the times when SEO consultants made loads of money. They are still using PHP because they never knew anything better and the scale of the industry is enormous, so it's slow to change.

zepolen 8y ago

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Except in reality once you want to use non /whatever/file.php as urls - you're back to implementing a router > PHP files can be deployed independently, swapped out or updated live. Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed. Except in reality, you don't want to deploy directly after editing a file since it's like deploying to production, you're gonna have a bad time. > A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers. Except in reality, that just leads to a bunch of spaghetti code with no separation of concerns and impossible to maintain. > Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Except in reality, this only works with php apps that have an integrated package manager and even then it leads to problems when a version is incompatible both in php or plugin dependency. > Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again. Except in reality, serverless lambda is a terrible idea: 1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work 2. when functions change you run into function incompatibility chaos and no smart way to handle that mess 3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't 4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement > Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP. Except in reality, you are notified of a bunch of potential bugs right there and then, instead of "maybe" finding out about them at runtime especially since PHP will by default consider a non defined variable just an empty string and display it as such on the page, and it's not until Joe User notices it that you'd ever find out.

icebraining 8y ago
Regarding (4) Lambda and friends are not actually stateless between requests; the process is initialized once and then potentially reused many times for hours, so you can cache between requests, both in memory or in the filesystem (AWS Lambda provides 512MB in /tmp).

vhakulinen 8y ago

> For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) I'm quite sure you can achieve this in golang with plugins[1]. That not as flexable as PHP, mainly because it involves a static type system and a compile phase (and more work in general). 1: https://golang.org/pkg/plugin/ https://golang.org/pkg/plugin/

weberc2 8y ago
Yeah, running plugins is not a difficult problem in most languages; it isn’t widely practiced outside of the PHP community because most folks don’t want to be the reason their users were hacked.

masklinn 8y ago

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. I mean that's just how CGI works, most every HTTP server still supports CGI, nothing stops you from deploying that way. Unless you're using Java or the like of course, then it's not very convenient.

YawningAngel 8y ago
You can absolutely do this in Java if you want to. I mean, it's insane and you shouldn't, but it's eminently possible.
- masklinn 8y ago
  I'm not saying it's not possible I'm saying it really isn't convenient.
  - YawningAngel 8y ago
    But the reason why it isn't convenient is because the consensus amongst Java programmers is that it's a bad idea. It wouldn't be difficult to build tooling around if one wished to - I think in this case, the fact that almost every language has migrated away from CGI-style routing is probably telling.
    - masklinn 8y ago
      > But the reason why it isn't convenient is because the consensus amongst Java programmers is that it's a bad idea. It wouldn't be difficult to build tooling around if one wished to That's part of the inconvenience though, one of the advantages of CGI was the low tooling requirements. > I think in this case, the fact that almost every language has migrated away from CGI-style routing is probably telling. I mean sure, but beyond not being a very good protocol CGI needs to execute the handler script on every connection, Java is not known for that being cheap.

EmpirePhoenix 8y ago

-> What other web platforms can do this? Kinda all Java Webstuff is capable of doing this (Eg. installing Plugins in Atlassian products)

slezyr 8y ago

Deployment of Go services is much easier. Try to deploy any self-hosted service like nextcloud, gitea. It was a nightmare to deploy nextcloud. Also it turned to be too slow for ONE USER.

Aeolun 8y ago
Nextcloud is just a bad product :/ it’s hard to pin the blame on PHP.
- slezyr 8y ago
  Still, it took quite long time for me to deploy PHP services. Didn't managed to get seafile(python) working at all. And it was relatively easy to deploy pair of Go services.

mikl 8y ago

This is pretty much a laundry list of anti-patterns for modern web development. Non-atomic deployments? Not using Composer to manage dependencies? No separation of concerns? Editing files directly on the production environment? I get that it's nice for beginners, but they're not benefits for professionals. We have better ways of doing things than Notepad and FTP.

andai 8y ago
vim and scp?

realharo 8y ago

>Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. The vast majority of PHP frameworks, even micro-frameworks, don't work that way. They route all traffic (except static assets) to an `index.php`, which then forwards it to a regular router.

kalmi10 8y ago
.. so you can live swap routes and endpoints even with dynamic routing (without performing any hot-reload dance in your own code), which actually sounds like a neat feature at first.

nkg 8y ago

Wordpress can instantly extend itself and its extensions can instantly self-f*ck the whole thing up. (Sorry for the WP hate, I forgot to take my pills)

eeeeeeeeeeeee 8y ago

You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress. Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”

euph0ria 8y ago
I really don't see how Wordpress is a valid argument here. We run several business systems in PHP serving hundreds of thousands of users. Last time I used Wordpress was over 10 years ago for my personal blog. Haven't used it for anything else. PHP is great for us, regardless of how Wordpress performs.
- eeeeeeeeeeeee 8y ago
  I was primarily responding to the OP that used WordPress as an example of how easily you can add plugins (third-party PHP code). I see that as an anti-pattern, because it encourages non-developers to add PHP code into the system, much of it poorly written and insecure (or not performant). But that plugin system also is one of WordPress' greatest assets. And you can add PHP code to any part of a "theme" too. If you turned off the ability for themes and plugins to be "added live" then I don't think WordPress would be nearly as successful as it has become.
x0hm 8y ago
Wordpress is written in PHP. Wordpress is not PHP.
- eeeeeeeeeeeee 8y ago
  Did I say that? Please don't twist my words. I was responding to the OP who was talking about the WordPress plugin system, which allows just about anyone to add third-party PHP code into the system. And those plugins have access to everything in the WordPress stack (and the file system for that user). And I think you can definitely argue that a low barrier to entry means that it gives beginners a lot of power they don't quite understand. Which is why I think most people steer towards common web frameworks, because not many people can know all the ways you can create security issues. Then you get into the complexities of various common web frameworks (Zend, etc) and you have to really wonder if the original OPs argument about simplicity and ease-of-use are worth that trade-off from using something else.

michaelper22 8y ago

> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Java: Use a classloader to load a JAR and instantiate one of its classes: https://stackoverflow.com/questions/60764/how-should-i-load-jars-dynamically-at-runtime https://stackoverflow.com/questions/60764/how-should-i-load-... .Net - use an AppDomain (or other methods): https://stackoverflow.com/questions/1137781/correct-way-to-load-assembly-find-class-and-call-run-method https://stackoverflow.com/questions/1137781/correct-way-to-l...

hrktb 8y ago

As other commenters point out, most PHP written today goes through a framework that negates most of these points (single entry point, modern architecture, code is precompiles/cached and optimised, simple and intuitive goes through the window) On the more general point, I am not sure scripting languages lend themselves better to lamdbas, as dependencies are usually external to the system. For instance PHP often relies on system json/xml libraries. Database access also needs to be precompiled and installed on the system, as would be crypto or internalionalization routines. Compared to that, I'd expect compiled runtimes can have one single "fat" binary that has most of the risky dependencies and only rely on the bare minimum provided by the system.

vorpalhex 8y ago

Routing is a feature because you can express more complex semantics. Most php apps depend on Apache specific .htaccess files to handle redirects and other routing, and it becomes a mess quickly. PHP files can be swapped out live because many CGI wrappers don't cache anything in memory, which means at high strain you start dealing with disk load, file locks, etc. There are many other languages which also don't require compilation, often at the trade off of less performance. Some really clever languages let compilation be an optional step. A single layer means your frontend logic, data models, and database access all run the risk of being one giant mess. Sure other languages run that risk too, but it's especially prevalent in PHP. PHP can extend itself - it can also be used to download attack vectors and execute them directly on the server with no concept of code signing. Other languages offer powerful facilities for remote updates if they're desired, but that's usually not the best approach for Web. You can edit other languages with notepad too. Being able to deploy a single endpoint to a live server and hoping it doesn't cause problems sounds like terror.

sephoric 8y ago

> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?) Since it's basically just doing eval(loadFile(...)), any language with eval() can do this, for better or worse. Which is like most of them. Perl, Python, Ruby, and Lua, to name the most common.

stcredzero 8y ago

I'm currently developing a facility to do live updating of processes with running game loops in Go. If one were to add in dynamically loadable libraries (working in Linux, last I checked) one could have the same facility for changing a single endpoint in Go. (It could also be implemented with small executables and reverse proxies.) I think what this demonstrates is that Go isn't a better PHP. Rather, we're at the point where Go could be used to build a better PHP. The most likely paths for this, are to somehow come up with a big group of developers with a penchant for doing this, and/or have some big company fund this.

ratling 8y ago

> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing. Not if you're using... literally any modern framework and deploying it properly. This hasn't been the case in years except for common legacy stuff like Wordpress.

sandov 8y ago

The PHP workflow is definitely great for a lot of uses cases, but the language itself is horrible.