Hacker News new | past | comments | ask | show | jobs | submit login

Everyone laughing at PHP hasn't tried it for years, I'd bet. It started clumsy, true, but it became a solid and quite elegant way of doing things.

And by things I don't mean just web development.

The current limitations I see in PHP is that there is not an official multi-core coroutines solution.




"Everyone laughing at PHP hasn't tried it for years, I'd bet."

God I wish that was true...

It's not that the language is necessarrily bad. It's the sludge of legacy code I've had to deal with and teams treating it as the hammer for every problem that they think they must treat as a nail.

Efficency be damned.


Elegant is not the word I'd use to describe PHP. Solid, perhaps. Undoubtedly useful. But if there is elegant PHP, I haven't seen it.


Have you looked at any Laravel code? As someone who has worked from small startups to FAANG and inbetween, Javascript to PHP to Python to Go, I haven't found anything more elegant.


I have. Elegant it is not. Actually, it smells like Enterprise Java code, which made me flee from the Java ecosystem. To each his own, but this is not an elegant event listener (copied from the examples page):

  use App\Events\ArtistInformationFetched;
  use App\Services\MediaMetadataService;
  use Throwable;
  
  class DownloadArtistImage
  {
      private MediaMetadataService $mediaMetadataService; 
  
      public function __construct(MediaMetadataService $mediaMetadataService)
      {
          $this->mediaMetadataService = $mediaMetadataService;
      }
  
      public function handle(ArtistInformationFetched $event): void
      {
          $info = $event->getInformation();
          $artist = $event->getArtist();
  
          $image = array_get($info, 'image');
  
          if (!$artist->has_image && $image && ini_get('allow_url_fopen')) {
              try {
                  $this->mediaMetadataService->downloadArtistImage($artist, $image);
              } catch (Throwable $e) {
              }
          }
      }
  }
Source: https://laravelexamples.com/example/koel/events-listeners


It's interesting to me how to show your example you chose something from a 3rd party, non Laravel site (just because it has a laravel in the name doesn't), and chose something which inherently doesn't follow PHP or laravel coding standards (snake_case variables, for instance), when you could easily pull something from the main Laravel website?

https://laravel.com/docs/8.x/container#introduction

Or, if you wanted something perhaps at least use one of their featured partners for real code? https://github.com/tighten/jigsaw/blob/main/src/Jigsaw.php

I also would argue that the majority of code I see in other languages is equally or worse than the example you gave.

You can write terribly in any language, Laravel included.


I think most people outside php have no idea what Laravel is, while anyone working in php is using Laravel so basically our viewpoint is Laravel = php. I don't know what it is about the normal personality that anyone using something you don't understand just be "doing it wrong"


I see php sort of like a trusty hammer. It's a hammer. Doesn't have to be elegant. It's a hammer.

The nails are http requests and PHP is a damn good hammer.


Cue the infamous double-claw hammer meme. I'd agree PHP is quite useful for web work, especially backend. And like a specialty hammer it wouldn't be useful in a lot of situations such as desktop apps or DB procedures.


Hello World in PHP is literally

    Hello World
I know no other language that elegant.


If programing stopped there we wouldn't have an argument, its when you design high performant code that is maintained for over 10 years etc.


From the top of my head, Javascript and Common Lisp will also work with "Hello World" (with quotes).


I can’t speak for Lisp, but JavaScript isn’t going to write that to standard out, it would just be a statement that didn’t do anything.

You would need something like

    import { stdout } from 'process';
    
    stdout.write("Hello World");


Fair enough. On the client (just opening dev tools) it would return the string, but as you say, it depends on what we count as valid (repl, server-side, client). Probably the closest would be

    console.log("Hello World")


Being able to do a trivial hello world doesn't make a language elegant.


The easiest Quine imaginable!


m4


This depends a little on the taste of each person, but personally the most elegant way of doing PHP apps I ever found is with Siler: https://siler.leocavalcante.dev/v/main/ and Create Siler App: https://github.com/leocavalcante/create-siler-app


PHP is elegant and useful. The spread operator is ...$array is elegant. $var ? "not found"; is really elegant.


It’s also about ten years later than everyone else to get those splat and null coalesce operators so it’s not like that elegance is unique or even timely for PHP.


Your post is 10 years too late because we are talking about php today. PHP was elegant in different ways 10 years ago.


I think you meant ?? or ?= ?


One comment I heard at a programming meetup recently was "I hate how frameworks like laravel have brought PHP back in to popularity when we had the chance to finally kill it off".

I do wonder if there really was value in salvaging PHP when we have a wealth of other languages and frameworks that do a perfectly fine job without any of the legacy mistakes sitting around.


There isn't a language that can replace php in 2021. Javascript doesn't have the size of build-in library. Golang is compiled and limited, blank spaces/tabs will kill a Python program. Ruby /rails is slower. All are harder to host. What could you replace php with?

The tales of legacy mistakes holding back php are things with no basis in reality. What legacy mistake holds php back? Method names/parameter ordering?

When I started with php in 2001 those elite programmers at meetups were looking down at php because Java was cool. In 2003 those elite programmers thought php should die because asp took over. PHP kept going along quietly taking over the web until the facebook movie came out making PHP cool for a moment. Those elite programmers decided PHP was too mainstream and the why PHP sucked movement started. The elite guys moved to Ruby On Rails then node/MongoDB, angularjs, React, Nextjs leaving each ecosystem for the next hoping that one day they will strike gold.


Honest question: what are people using if not PHP? Node? Python? The 80% of us who aren’t FAANG and are writing CRUD apps. I’ve tried researching the pros/cons and all I get are low quality listicles.

Nobody can tell me why PHP is “bad” or what Python does that PHP can’t. Inconsistent params are the only argument I’ve heard. Which my IDE solves. What about JavaScript splice vs slice. I look it up every time.


I write PHP for my job almost every day, and have for the past 4 years, and there's some truth to what you say: anything you can write in another language, you can also write in PHP.

Personally, I can't stand writing PHP, because, sure, I can write secure, testable, safe code in any language, including PHP, but, how do I say this, PHP is the only language that feels actively hostile to my attempts to do so. The house style at my current company could be boiled down to "Check 3 times that there are no PHP footguns present in this code. We have been burned before." The developer experience and tooling is far behind comparable languages. I feel like I have to put my sysadmin hat on to fix anything that goes wrong with my environment.

When I write Javascript or Python, I have complaints and issues, but I enjoy writing code. I think PHP, for many programmers, including myself, is just a hostile and unenjoyable experience. If you enjoy writing PHP, I have nothing against you and am certain you will remain employable, there's a lot of PHP out there.

> Honest question: what are people using if not PHP? Node? Python? The 80% of us who aren’t FAANG and are writing CRUD apps.

Python, Node, Java, .NET, Ruby. MVC CRUD apps are pretty similar in all of these (also in PHP). All of those languages (including PHP) power many many many software companies (including FAANG, who use a lot of Java and C++, and Facebook famously was built on PHP).


> When I write Javascript or Python, I have complaints and issues, but I enjoy writing code. I think PHP, for many programmers, including myself, is just a hostile and unenjoyable experience.

Surely JS has at least an equal amount of foot-guns to PHP. I mean, at least PHP (to my knowledge) never had a meta-language written around it that compiles to PHP to make it safer.


Did Hack start that way, or am I misremembering?


IIRC Hack transpiles to C++ with an intermediate build step. So not exactly the same.


What footguns would that be?


When picking server language for web development I think it is more important to look at how the platform works rather than language features.

This is important

  * memory model (shared, per request, etc)
  * request model (by the app or by the web server)
  * compilation/build step
  * deployment 
  * hosting
  * tooling (IDEs, linters, testing, package manager, etc)
  * how to scale
  * available programmers
  * community
This is not important

  * $ in variable names
  * arrows (->) for accessing object members
  * argument order in standard library
  * not elegant enough


Out of date but this is the classic anti-PHP polemic. https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/


Can we _please_ stop posting that link, in 2021? It's very, very outdated.


I warned it was outdated and it has a date. Nevertheless, it's a classic piece and a number of the criticisms are still true. I don't see what makes it any worse than linking to the Unix Hater's Handbook, which is also outdated in many respects and yet still considered a classic for a reason.


It was out of date when it was written.


People are using Node. And they move a lot of the processing to the front end with things like React.

They have trouble grokking that there is a method of dev in which the server is not the language parser, so all other languages feel like a wrong step.

Here on HN someone just asked why anyone would write in anything except JS [1].

Now, Node has it's advantages, and so does PHP. My personal preference is PHP. But in mindset, Node is far ahead of anyhere that Rails or Django ever got in their respective waves.

[1]: https://news.ycombinator.com/item?id=29321426


Golang.

Static typing, concurrency, blazing fast, single binary.


Statistically PHP software has the most vulnerabilities. They are also quite different when compared to other languages. Language has many features which might be used unintentionally by programmer, leading for serious bugs. Not a good language to start with.


What features are used unintentionally leading to serious bugs?


The ease of the "just put it on the filesystem and it can be run!" system also opens up security vulnerabilities when people want to enable file uploads, for instance. I think the proliferation of places you can put configuration for the runtime is also a potential source of issues, as are various forms of string escaping that should be avoided.


Take a look for https://book.hacktricks.xyz/pentesting/pentesting-web/php-tr... for example. (Note also, that is the only programming language specific list, which is one mile long.)


These are older issues. When you see comments like: This bypass was tried apparently on PHP 5.2.5 and I couldn't make it work on PHP 7.3.15) I'm not sure these apply anymore. The loose == vs strict === exists in many languages. You can make the same mistake in Javascript.


> Javascript doesn't have the size of build-in library. Golang is compiled and limited, blank spaces/tabs will kill a Python program. Ruby /rails is slower.

I have once heard an ancient prophecy (I think it's Greek) that says "Debating around PHP online summons the ghost of the dark behind your back" or something like that (I don't speak Greek, sorry).

In the Client/Server world now days, the most of the time you only need one or two languages, one running on the Client side (JavaScript for example) and one running on the server (**, Go, Java, JavaScript etc).

In that setting, JavaScript comes with the hard advantage of both-end compatibility, that gives you something like Server-side Rendering, which no other backend-only language could do, at least not "natively". If you have a foundation this good, people will build the library themselves when the language/runtime don't have it built-in. (the same is true when it comes to Swift/Dart/Kotlin. I bet there is someone/company out there writing both their app and their backend in Swift/Kotlin)

For "backend-only" languages, it's largely down to personal/team preference. Some needs performance, some wants "write-friendly" (contains many factors). But the problem is, the market now days is saturated with better options that also do more things (often in a better way). When you bring all the options on the table, then suddenly that-language-the-name-we-shall-not-say started to look way less attractive.

It's just that, comparison/competition kills things, no elite required.


Server-side rendering is what php and these other backend frameworks do when responding to a request. If the output is html a browser will read and display that. Whether it comes from node or php that hello world h1 tag looks the same to your browser.

The problem with swapping out php on the backend for node is now you have to maintain a node server, manage long running processes. If you make a change to a node file you have to restart the server. Where php is running under apache or nginx and files can be dropped in without taking down the site.

That's why everyone is going serverless.. who wants to manage a node server.


It exist multiple libraries/frameworks that allow you to write modern dynamic applications with server side rendering only, like Hotwire, Livewire, htmx and unpoly, thus the need to write a large amount of JavaScript for the frontend is no longer needed.


> Server-side Rendering, which no other backend-only language could do

Isn't it the definition of a "backend-only language" that it renders server-side?


I think they're referring to server-side rendering of SPA templates, which is something you get basically for free if your backend is written in NodeJS.


I've been working with php since 2001 and that whole time I've been cleaning up bad ruby and nodejs and PHP implementations and knowing JavaScript well enough to code in whatever front end nonsense comes out from PrototypeJS to jQuery to ExtJs to angular to react on and on ad nauseaum. Throughout PHP was my actual workhouse. It's kinda frustrating when I meet someone super into JavaScript as a backend because I still choose PHP even though I have 20 years of JavaScript under my belt and love Es2015+ promisable JavaScript.

I'm not even really sure why python is so popular for DevOps cause I do everything in php and it's unit tested and works well with reproducible results.


> blank spaces/tabs will kill a Python program

That's a lousy dig at Python. Stuff you solve with a free text editor and 15 seconds worth of configuration aren't real problems.


other than Phoenix framework maybe are there any others with as much included as laravel has?

caching, jobs, docker via sail, authentication and authorization, one command to have a full multi team/tenant SaaS app template via jet stream.

even rails doesn't have this, as you need to choose your own implementation for auth and access control, something like sidekick for job queue etc....

plus the ecosystem. I've tried so hard to like other frameworks and some I really do (like remix.run) but the lack of real momentum and community hurts most anything else and just doing everything as serverless micro services isn't always preferred or using micro frameworks.

I'm excited for the new features and with octane you can get more reqs per second than Phoenix framework which should make it easier to scale apps with less resources.


.NET has most of this. Love it.


Which ones would that have been? Perl? Python? Java? JavaScript?

Among that choice set, PHP is definitely the best contender.


I would say that Ruby on Rails is a pretty good candidate to completely replace PHP with.


I think you (and to be fair, many people) are missing a huge part of why PHP is still popular. Saying Ruby can replace PHP sounds to me like saying that Ruby can replace Excel. It's fundamentally misunderstanding _why_ it's popular in the first place.

I have a HTML page. How do I add a hit counter to it with Ruby?

I can do it right now in PHP with zero dependencies and it'll fit in this comment:

    <html><body>
        <p>You are visitor number: 
    <?php
    $count = file_get_contents('hit_count.txt');
    $count = $count + 1;
    file_put_contents('hit_count.txt', $count);
    echo $count;
    ?>
        </p>
    </body></html>
Is it shit? Yep. Does it (mostly) work? Yep.

When you want to do something, you can just copy and paste a handful of lines of PHP into a file and rename it from .html to .php and it'll basically work anywhere. You don't need to worry about frameworks or anything. Routing is handled by the web server. Hosting is handled by someone else. Deploying is just FTP'ing a .php file off to a server somewhere and then requesting it.

But when you are ready to get into "real" programming, that's all there too. PHP has a true learning _curve_. Every bit of complexity is only a small step from the previous. Getting started does not require a ton of background or knowledge. You can start out copying and pasting some code into the middle of some HTML and a year later end up working within once of the nicer, more comprehensive frameworks managing your dependencies with a relatively decent package manager... and still hosting it all on your $3/mo shared hosting.

If every professional developer stopped using PHP tomorrow, we'd still end up back exactly where we are as a bunch of people found PHP as the most accessible and direct solution to the problem they have.


This example seems to be a great demo of why people do not like working with PHP. PHP makes the shit method the massively simpler way and the good method much harder. Now you open yourself up to risks like what happens if we accidentally let some user input change the file opened as well as the content written.

While with rails, to do basically anything, you already have a full db ready and incrementing a counter using the ORM is even easier than opening a text file. So people avoid PHP because it most likely involves dealing with absolute crap code written with no understanding.


I don't find these kinds of what-ifs very useful. I haven't used Rails, but does it somehow prevent you from accepting user input and programming it to go where you say you want it to go? Isn't there an element of "holding it wrong" with any language or framework?


Rails actually does do a good job of treating user input as dangerous and it can often detect when user input is being used in the wrong places like directly in to sql. And with industry standard tools like brakeman, you can have CI alert you of most cases where user input is not safely handled.


That's way too complicated for the person just starting out and wanting to add a counter to his small website. Nobody starting out with programming today will start with Rails. They might start with Javascript, but more than likely they'll start with PHP. It's accessible and SIMPLE.


>PHP makes the shit method the massively simpler way and the good method much harder.

How it makes it harder? Or you compare PHP a language with Rails a framework? Maybe shut up if you have no idea or show us a pure Ruby code that does the same thing. Or install the most popular PHP framework, really learn that and then tell us that PHP made things harder. I don't know Ruby or rails so I can't shit on that like an idiot.


Please refrain from name calling and phrases like "shut up". They don't really add to the conversation.


I apologize and I will try to do better.


This makes my eyes bleed.


Inline PHP reminds me JSX. Everything old is new again.

<? include '../menu.php' ?>


Except in-line JSX runs in the browser and is not very exploitable.


JSX certainly does not run in the browser.


does rails come with a generator to create a teams based multi tenant SaaS app with authorization and authentication and job queues without extra setup? (ie without decide and sidekick?)...

can rails compete with the performance of octane using swoole with 8k reqs per sec?

rails is the first framework I ever learned in 2012 but I kept jumping back and forth until laravel basically started lapping rails in terms of baked in goodies.


I’m not sure why this really matters. You can set all of that up in rails in under an hour. And almost every company uses exactly the same libraries for it all. It’s been so long since I even created a rails app because it’s almost always already created when you start the job.


Doubt there was a chance to “kill it off”, doesn’t it run over 50% of all websites?


It's a CRUD staple. There's no other language so well suited to easily building CRUD services (of which WordPress is one). It's a big cherry on top that the language has gotten better and dramatically faster over the last several years.

There was no chance of it being killed off rapidly as the author was perhaps implying. It might have slowly rotted away, had the maintainers not stepped up with v7 and hit a home run.


PHP powers a couple of the software packages used by over 50% of websites. Mainly being Wordpress. Impossible to know but I would guess that new development of PHP sites is not such an impressive stat.


PHP runs the long tail of the internet. And somewhat accidentally, it also runs Facebook :-D


I used Symfony and it was fine but there are some challenges:

1. The combination associative array/array data type is weird and I feel like the performance is not predictable unless you devote time to learning specifically about it

2. You're still stuck with all the weird legacy stuff, even if you don't use it, because someone else might bring it in

3. The OO stuff is basically like an old version of Java and a bit tedious to write. An IDE is definitely required

4. Many PHP developers formed their ideas about coding in the bad old days and will resist efforts to make code more testable or whatever because it's "too complicated."


> The OO stuff is basically like an old version of Java and a bit tedious to write. An IDE is definitely required

The OO 'stuff' in PHP is far better. Notably, Traits, Statics and Testing.

Java (and JUnit) do not work well with static methods/classes, when it's unironically the most effective way to limit state. In PHP you can create a static class, that has static utility methods. Now you can ensure you have no side effects - unless accessing static properties somewhere, ofc. Then PHPUnit has no trouble helping you test these. It's a huge improvement over the acrobatics of booting up Spring to manage a singleton (which isn't the same thing as a static class) whenever you want access to those real static methods.


I'm not sure what about Java is stopping you from making static classes.


> I'm not sure what about Java is stopping you from making static classes.

I didn't imply that you couldn't make a static class in Java. There are lots of ways to make something like a top level static class (nested static, Spring singletons, et al), which works against the explicitly stated purpose of limiting state involvement.


Those limitations are a little annoying but I'm not sure how they're preventing you from doing what you want to do, and having top-level statics wouldn't limit someone from just sneaking global state in there either.


    @Test
    public void testSomeMethod_FromStatic() {
        StaticWrapper1 staticWrapper = new StaticWrapper1();
        int mockInput = 1;
        RegularClass rc = new RegularClass();
        int expected = 2;

        int ret = staticWrapper.someStaticClass.someMethod(rc, mockInput);

        verify(staticWrapper.someStaticClass, times(1)).someMethod(rc, mockInput);
        assertEquals(expected, ret);
    }


    public class StaticWrapper1 {
        static class StaticClass {
            public int someMethod(RegularClass foo, int val){
                return foo.someAddMethod(val);
                /* it's not practical to chain, eg
                   staticWrapper2.someAddMethod(foo, val);
                   because you end up with circular dependencies or passing large numbers of deps around, which you can't verify in tests anyway */
            }
        }
    }
You cant do this (verify the static call) by default nor anything more complicated than this (with Mockito Static mocking) because JUnit cant track deps through statics for testing. If you have multiple static objects that have static methods, you end up with brittle chains of instances that might need to refer to (either passed in or member instances of wrappers) just to call other static methods. This is inferior to PHPUnit.

Making syntactical boilerplate "just because", which also requires instantiation breaking DI (ostensibly, all you have to do is boot up Spring IoC container and it's there are runtime), is inferior to PHP.

Maybe one day Spring will be baked into Java, but that's a one-ton runtime workaround for a small mistake in the core philosophy, ie you can put a non-static function around a static function and treat it as the static, so it's a JVM problem. Pushing explicit instancing to the code is bad design from a makeshift solution to get Java working on older platforms, quickly. Now java does prechecking of memory anyway, so the way you have to do static implementation is an extraneous legacy limitation.


Right, I mean, if you need to mock it a singleton would be a better choice; that's kind of the point of the pattern. Personally, though, I feel like if you frequently find yourself needing to mock these static classes, then they're not really as effective at avoiding statefulness as you claim -- if they're side effect-free, it should be safe to just use the implementation.


You need to mock them because you are asserting that it is the correct thing to use. Verification testing has nothing to do with state, per se. Having a static instance a wrapper just to use another static is java forcing unnecessary state. Forcing a singleton to instance another singleton at runtime is idiotic, which is why spring proponents avoid it and java is still a syntactical dinosaur. When we see proper modules (including static refs), java will be better fir it.

PHP is better with how it deals with statics today, which bleeds into other areas like testing.


Not intended as a plug but you can even use php for network automation. I cobbled this together:

https://github.com/epiecs/phpmiko for connecting to devices and https://github.com/epiecs/mikodo for inventories and concurrency

The multi core coroutines comment is true but there are ways (to hack) around that.

The way I solved concurrency is just by forking and using sockets: https://github.com/epiecs/mikodo/blob/6bdcebe9fa7f44ffdedd82...

I use it at work atm does what it's supposed to. I also use Python as well but I wanted to know if it could be done in php :D


I’ve been writing PHP since the 3-4.X days (over 20 years). I’ve written tens of thousands of lines of PHP, in several fairly large-scale server systems.

I’ve never learned to like the language, but have gotten pretty proficient with it. I don’t claim to be a PHP maven, though. I know that my style is fairly “primitive.”

I tend to use it for my backend work. It’s quite performant, has huge infrastructure support, and it’s entirely possible to write safe, high-quality, low-level systems in PHP. I’m a good engineer, and do a decent job; regardless of the tool I use.

C++ is the same way. People have been hating on that language for even longer than they have, PHP. C++ is still used for many major infrastructure projects, though; because it’s the best language for that kind of thing.

If you give a kid a chainsaw with the guard removed (as most arborists do), don’t be surprised, when the screaming starts.



Multi core support is an issue I’ve tried conquering with php, but went down a rabbit hole of running JS on a GPU instead.


> It started clumsy, true, but it became a solid and quite elegant way of doing things.

No. Just no. PHP will not be solid and elegant by evolution. It might have become an excellent tool for the area it's supposed to be used in, but the only way it could ever become elegant is if it had its python2=>python3 sort of moment. They would need to break it to fix it.

I don't think they'll do that, since I think they understand that it doesn't matter at all that the language sucks.


I don’t think breaking python2 did a lot to improve python 3.


That's probably because python2 wasn't that broken to begin with. But fixed character encodings was totally worth it. I think the only mistake they made was related to how long they kept supporting python2 -- but I'm sure there were good reasons for doing that.


I used PHP about two years ago and I was not impressed at all with the improvements. Yes, some of the issues had been fixed, but many of them remained. I cannot see any reason for using it over JS, Python or Ruby.


I've used PHP recently to work on Phabricator, and the whole "yes it sucked but now it's good" narrative did not match my experience at all. Sure it might have added modern features but the core is still rotten.

The alternative would have to be TCL levels of bad to make me choose PHP.


Phabricator is not written in "modern PHP", so your experience is not surprising


Can you link something written in modern PHP?


like the sibling comment said, web apps are written in Symfony/Laravel, but the framework abstractions with web apps might not paint you a clear picture of how the core language has improved. it will give you a good idea what it's like to build applications.

my favorite part of modern PHP is how nice writing libraries is. so it might not be what you're looking for, but I remember being pretty impressed with the code quality of the Amp PHP library recently. the v3 branch is 8.x only and (I believe) is targeting the Fibers feature just introduced in 8.1

https://github.com/amphp/amp/tree/v3

one of the best things to come with PHP are the community standardizations around things like interfaces for HTTP requests, logging, DI containers, and even code style standards. it makes for a very consistent experience when developing (at least when you're in the "new world"), since most newer libraries are all written in a similar style using common interfaces


most of projects based on Laravel/Symfony that are < 5 years old


Phabricator, much like WordPress, kind of lives in its own world and hasn't adopted most aspects of modern PHP. Even as someone who works with PHP and enjoys it, I wouldn't want to use Phabricator.


Wordpress has taken great strides to comply with the latest PHP standards so I'd say that's not quite fair to include it here.


I’d disagree, Wordpress is very difficult to work with when you’re used to modern ways of doing things.


I would say some contributors comply with standards - but the stuff coming from Automattic is scary.

I ended up in a position where I've become responsible for a very high volume WooCommerce/Wordpress store and the things that I've seen in _brand new code_ is mind boggling. Their new, branded, in-house paypal plugin/integration is currently at 1.5/5 rating on the wordpress plugin marketplace [0]. It just doesn't work for various reasons for various people. It's 2021, how do you screw up a payment gateway for wordpress when you _are_ wordpress? But wait, there's more. They already had PayPal integration, built into the core and already included in all WooCommerce installs. So what to do? Force disable the already existing, working-properly, integration and recommend their new plugin to be used. [1] This is hostile.

If your woocommerce webhook delivery fails 3 times in a row, woocommerce will just turn off that webhook/stop delivering them. Silently. No option for any sort of alert to be sent/logged, no way to store/replay the missed webhooks. Just off. This is irresponsible.

Our installation happens to have a lot of details that go into each line item on an order - which, in turn, turns into many rows of meta data. Woocommerce doesn't rely on dedicated tables for orders or related metadata, it's all stuffed into 'posts' and 'post_meta'. It doesn't scale well, terrible really. It's a large enough problem that LiquidWeb starting working on a fix for high volume sites that end up getting crushed with database/performance issues related to these tables/the way the order data is stored. [2][3] This was supposed to merged into the WooCommerce core but that seems to have stalled/fizzled.

I was able to reduce response time on an API request to get_order() from 3-5s to 0.25s by adding an index to the meta table mentioned above. (The query wasn't using any index) This likely isn't the case for the vast majority of installations, or it doesn't matter because the databases are small enough. But things like this indicate to me that the test suite/benchmarking is seriously flawed - or they're not doing things like testing and benchmarking against real-world databases.

Taking a look at various release notes the types of bugs seem to indicate to me there's not a lot of automated testing going on or that things are so convoluted/messy that it's become too complex.

All in all, for the people behind the PHP workhorse (the hero we deserve...) it's all pretty scary. The code quality, quality control and just about everything leaves a poor taste in my mouth. I'm not a big "Team PHP" guy - I like the idea of using the right tool for the job and the scary thing is that Wordpress is the right tool for the job for a lot of people. (WooCommerce, these days, is basically never the right tool)

This is a terrible look for PHP.

Laravel/Symfony on the other hand... take my money. It's a pleasure. LiveWire, tailwind, oh my.

There's still a place for Wordpress - it's not going anywhere... but it's got a long way to go before I'd say it's anywhere near ok. Let alone approaching latest standards (even despite it's supporting older versions of the language). Can we get first-party/first-option composer support? Why, again, is it another company driving Wordpress forward? [4]

[0] https://wordpress.org/support/plugin/woocommerce-paypal-paym...

[1] https://developer.woocommerce.com/2021/07/12/developer-advis...

[2] https://github.com/liquidweb/woocommerce-custom-orders-table

[3] https://stevegrunwell.com/speaking/woosesh-2019/

[4] https://roots.io/


> Woocommerce doesn't rely on dedicated tables for orders or related metadata, it's all stuffed into 'posts' and 'post_meta'.

While I agree this is an antipattern it appeared to be the recommended way when I first got into WP plugin development. IIRC because one cannot guarantee hosting will backup all tables of the DB, and some DBs mix other non-WP stuff.


Ok, going to say you reminded me and I agree now. I was thinking solely of WP core, but if you are to include all of the official plugins and Woocommerce, then yeah I can see the issue.


i just helped my father with a wordpress site, and it sure doesn't use modern php. It runs on modern php, but it does not seem to actually USE it.


PHP at its core is the best part. A whole bunch of optimized and well tested C functions that are typical of backend functionality.

If you can do as little as possible in PHP and rely on the low level functions to stitch together what you need, deserialize and render data in the front end, use front-end templating, then PHP is insanely fast, practical language.

The issues with PHP are usually when people build out giant frameworks in PHP, rather than using PHP as a higher level glue language for the built-in fast C functions.


I've worked on _many_ PHP projects. Unless it's a small single-purpose script, if you tell me it doesn't use one of the standard frameworks, I'm going to assume it's an absolute unholy mess of spaghetti.

Laravel and Symfony are both extremely good, and the only reason people don't use them tends to be out of misplaced arrogance. Unsurprisingly, they end up building their own awful framework, and at some point the project either dies or someone says "Erm, we should put this in Laravel".

There are some people who've built great projects without these frameworks, and there are many projects in these frameworks that are terrible. But in terms of probabilities, you've got a much better chance of a project being well-built if it's in Symfony or Laravel.


I have seen plenty of PHP projects without any frameworks used. Big ones as well. One of these projects is automation for a complete manufacturer factory. Robot controllers, Serial hardware drivers written in PHP, Realtime application with PHP instances running for multiple years. No frameworks used at all. There is more than only webapps.


I’m sceptical that’s a large proportion of PHP projects, and thus comes under my caveat of _some_ projects.


To be honest, I quite like modern PHP. On the other hand, I tend to stay away from it, exactly because of the big prevalence of spaghetti code projects.

There just is so much legacy in the PHP world that separating the wheat from the chaff in itself becomes tedious. And don't understand me wrong: legacy in itself is not a problem. It's the combination of PHP being easy to pick up, lots of outsourcing, people writing procedural code without any notion of code readability, lack of tests, use of global state, etc that usually just make me cry and move on. For me the percentage of worthwhile PHP projects to chase is too low in comparison with many other technologies.

Even though PHP was what got me into programming in the first place, I nowadays thus chose to pick other battles. But every once in a while I still nostalgiously float back in time to my childhood days, enjoying every line of the almighty 4MB imagemagick monstrosity scripts I conspired. And then I'm happy that you nor I have to solve these enigma puzzles.


I started with Ruby, and I imagine my code there was just as bad. But I totally agree about the prevalence of bad PHP projects. My theory is that it’s the dominant language and so there are just more projects, and (like the opposite of survivorship bias) shit codebases are often looking for good developers to save them which is why you see so many of them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: