Arantor

Powerful is extremely relative. There are things that are pretty effortless to do in Node that are... less than ideal in PHP - and completely vice versa. For example, long-running processes that wait for things to happen, especially long-running processes that multiplex connections (think websockets, chat servers), these are things PHP was never designed for and simply isn't good at. Python needs help doing it (Twisted used to be the go-to here, no idea if it still is), while Node is pretty much geared to this sort of use case from the off. That said, Node has other deficiencies (there is a reason Typescript exists as a language, and it's to mitigate things that Node itself won't do by default in terms of sanity in the codebase) and the 'you can share code between the front and backend' is still mostly a myth in practice. I think the best thing to do is give it a go and see how you find it. Some languages just click with people, especially if it's already similar to something you know (Node.js is, after all, JavaScript - though you probably won't use jQuery for anything and anything that hangs off window or document is implicitly a no-go because there's no DOM in a server) It's always worth exploring other languages and tools because it gives you more choices in the arsenal for solving problems, and if you spend enough time in a language it will absolutely broaden your horizons by giving you a different perspective. For example: professionally I build in PHP with JS when it makes sense. But professionally I've also done things with (in no particular order), Java, Swift, Go, Python and C#, and as a hobbyist I've also played with Rust, Ruby and myriad other languages that are highly situational (e.g. Inform 7). I stick with PHP because it's where the applications I use live, and because it's very familiar and convenient, and it pays the bills. But the knowledge of the other languages means I know when I'm chasing something that I shouldn't be doing in PHP and switch to something more useful. Practical example: not that long ago I had to do some stuff with GeoJSON - think about a 150MB JSON file that represents latitude/longitude boundaries of land regions, and I wanted to know 'given I am in this region, and I am looking at that region, are they neighbours'. So I want to turn this monster JSON file into a list of 'for this region, these are its neighbours'. Could I have written this in PHP? Eventually, sure. I'd probably have to do a lot of the underlying stuff purely by hand because the main geospatial library for PHP is a bear to get set up properly on any environment unless I'm compiling it myself from scratch (which I never want to do if I can help it), but I know this is far easier to do in Python - so I fire up Python, I include a couple of libraries through pip and I write maybe 25 lines of code to take in the monster GeoJSON data and flip it into something that will spit out the relevant JSON files I will use. I was done in about an hour. Meanwhile, spending time in Rust teaches me the value of what PHP gives me and what I don't have to think about when I'm writing PHP. Being reminded of that never hurts. And writing some of the stuff I am for the ZX Spectrum Next just teaches me that in some fields I am not a master but a padawan, with much still to learn.

That's actually not the reason, not really. I used to freelance but I found that a) I spent a disproportionate amount of time doing admin/sales/chasing clients which is all stuff I don't enjoy and aren't particularly good at and b) that I ended up working far too many hours, frequently into 80+ hour weeks without even realising it. Eh, I was younger then, it was a decade ago that I did that. I'm happier with a more reasonable work-life balance.

I don't do freelancing any more, it's not worth the hassle. But I'm slowly trying to set up an XF forum so I can launch it and there isn't really a plugin to do quite what I want so I'm building it myself. (Wouldn't be the first time I've built plugins for platforms to build sites; every WordPress I build gets a custom theme often with custom plugin-like dev, and previous SMF sites I did much the same for)

Huh, not that surprising. There were similar claims made over .org a few years back.

Been rewatching Lucifer lately, good show, though not in my all time favourites.

Films: The Court Jester, The Princess Bride, Kind Hearts & Coronets, The Jokers, the six Star Wars films, Clue, Smokey and the Bandit, Indiana Jones and the Last Crusade, The Italian Job, Labyrinth, The Neverending Story TV: Babylon 5, Star Trek (all), The Blacklist (only until about season 6 though), Doctor Who, Burn Notice, The Mentalist

A lot of it is simply different rather than good or bad. It's not like SMF is my only experience of writing code, I spend a lot of time in Laravel which is completely different again (and I've built stuff on Laminas which influenced XF in its history) Though it would really help if it weren't so cold in here. I live in an old building, it's a bit drafty and despite having the heating on, sat on the sofa with 2 jumpers on and a blanket, I'm still cold which isn't doing much for my motivation. I am loathe to move my fun laptop to my study because that's where the work laptop is and I'd rather keep them separate. (Not that my desk has enough room for another laptop)

XF plugin dev is an interesting journey after so many years of writing SMF mods.

I don't think staff-to-member ratio makes sense unless posting activity is also similarly proportional. I can think of a site, for example, with 14 proper team members, several moderators that only moderate individual boards, but the site as a whole has 456k members. This isn't a drama because despite having a total of 3.9 million posts, that team is easily capable of keeping on top of the posting given that so far in November the peak posting rate was 76 posts in a day, and on one day this month it only got 2 posts. Staff to posting rate (i.e. the stuff that needs moderating) is probably a better metric, and you don't really need 14+ staff to moderate 30-40 posts on a typical day, though I will add some of these aren't English (but still, copy/paste to Google Translate isn't exactly a huge job)

Speaking of smells, there is a word for the condition of not being able to smell anything (like me), and it is anosmia. I am anosmic.

This just got absolutely wild. https://wordpress.org/plugins/secure-custom-fields/ - this is ACF Pro (remember, owned by WPE), rebranded and put on the plugin site by WordPress.org itself. And it is the pro version - it has features only the pro version has, but without the licence key requirement, and with the most minimal rebranding possible being done. They didn't even bother find/replace on ACF to SCF, and by removing the official copyright they also violate the GPL in so doing. Good going, Matt, good going. WPE's lawyers are going to love you for this, as is the rest of the ecosystem that builds premium plugins/themes.

Not hugely because the real pain is the fact that they’re part of WP’s media library.

You’d think but they were adamant they’d done the right thing. Trouble is, after the guy bought it, not only did he migrate to Woltlab, he also gutted the content from 90 million posts to barely 2 million. People do not appreciate it when “their creative work” is gone like that. (The objective merits of such content are highly debatable, but from the writers’ point of view, practically passion projects.)

I have a couple of customers who run stores on it as their primary income. I think this really depends on your scale - when you're at 16GB VPS territory and you have 55GB of product images, with 112k post items (and multiple millions of postmeta), this is a little more terrifying to work with! At one point between WC and their plugin stack, the one customer was producing 7000 queries per page, every page, and average page load times were 30 to 60 seconds. I was asked to fix it ahead of Black Friday 2022, turns out 2022 was the first year the site stayed up on Black Friday... You absolutely can do wonderful things with WC but the more you try to do, the more fragile the house of cards becomes.

I think in all honesty it was the time I was asked to help out on what was then warriorcatsrpg.com (before it rebranded to feralfront.com and before it was sold to 'a developer' who converted the site from SMF to Woltlab and shut it down shortly after) WCRPG was, at the time, the largest SMF installation ever as far as we know. At its peak, 90 million posts - doing 90k posts a day (some were 1 liners, though). And it had a bunch of custom code and janky add-ons from various places. You must understand that all of these custom things were "essential". Everything was "essential". Even if literally only one person asked once, this would become "but my members will all leave if they don't get this". I don't believe it was ever true but Wynette was, shall we say, highly strung. It was a definite clash of personalities, but the site was struggling to cope with the traffic and I was asked to see if I could make it run faster. It turns out I did - I found an actual performance hole in SMF 2.x (this was long before 2.1 was out) where a query would be run every topic view even if the result wouldn't be used (which was about 90% of cases), and stuff like that. It took a little while but we wrestled with some of the janky custom plugins that were never designed for that scale and made it run pretty good all things considered. I suspect running the same code today on a current gen server with current gen PHP and MySQL would be less scary, but this was 2012 or so, we didn't have the massive speed-up of PHP 7 yet. And of course, it wasn't my site so I was legit terrified of breaking anything because there was a lot of janky stuff in there that I didn't necessarily know about. But it all worked out in the end, at least at the time.

Conversely if someone does want all the things in one go, it’s that much more expensive and is a collaborative approach from multiple reviewers.

I try to be helpful, because I’ve long been a believer that this stuff isn’t magic and that if people want to learn, I’ll try to share what I know - I am just mindful my communication and explanation style don’t always translate well.

You probably can’t implode them. If I did this in Laravel (or any other equivalently modern OO-first environment), my array internally isn’t a list of names. It’s an array of author objects. (It might even be something resembling Laravel’s Collection helper which definitely is not an array) You cannot just implode a list of objects unless you’ve gone out of your way to seediness specific methods to say to PHP “if someone tries to use this object as a string, do this with it” But this is really more a case combined with the first thing: you probably have a book object with its array of author objects and you might want to let other parts of the code have access to the real array, but they can have a pre-made digest format. Really it’s about making it easier to define ways to get at the data an object already has. You’re thinking about my example solely in the context of that example, when that’s really not the intent of the feature. OK, better example: I have a system that handles money. Everything is done in fixed precision for accuracy. I have an object that represents the product with its price, in home currency. What I also will need from time to time is the price of that product in Stripe terms. For those not familiar with Stripe’s API, a product that is USD 149.99 is not sent to Stripe as $149.99 - rather it’s sent as 14999 US cents. Since I know I’m going to need the price for Stripe on various things, I define a new property in the current longhand way that says “get me the current actual price, then convert it to what Stripe wants” meaning that I have my product and can ask for $product->price_regular and get its price for normal purposes as well as ask for $product->price_stripe and get it ready formatted for Stripe without having to duplicate the logic everywhere I would otherwise need to do the conversion. I also never want to allow anything to override this value. Similarly I can define $product->tax_amount as a property where the rest of the system can just trust that the product knows how much of its own price is taxable and therefore how much tax is liable. What we’re really saying here is that in the pre 8.4 world we can define properties that are either read/write or not accessible (with no easy gated update method) and any additional behaviour is much more longhand, and that in 8.4 we can very easily define any type of attribute we like and make it very easy to define “if you get asked for this, here is what you do and if you get asked to update it, here is what you do” including “you can look but you can’t touch” attributes and entirely derived or computed attributes that are made from something else.

In the design thinking for this, the book object would be holding an array of author objects internally and this would be a nice way of additionally getting the names, pre formatted into a standard string format, without having to manually remember to get the array and iterate over the array in the place you need it. You’re not changing what’s actually held, just making a convenient access to it. You’d still be able to get the originally array if you needed something else (assuming the array was made as a public or otherwise exposed property, this won’t always be the case)

I think I’d recommend MyBB at this point in time but I’m not as familiar with its ecosystem so I’m not sure what stores exist for it (though, I’m sure at least one does)

For me, I spent much of the last year on a project where several of these would have been really handy and I ended up doing the longhand for many of them.

It's always either for the members to bolster an existing community or as ad-space, and it pains me how often it ends up going poorly. I can't imagine many forum owners have ever ended up with a better community off the back of an acquisition. I think Cedric might be one of the rarer exceptions where it wasn't a total disaster for all concerned.

I'd actually be much more in favour of people being selective in what they're requesting rather than 'I want a review of all the things' because people will want different things at different stages of the site's lifecycle.

OK to understand this, I need to drop a bit of background. Modern PHP is what we call 'object orientated'. This means we create objects that represent something in our system, e.g. a user, a forum post, you get the idea. These objects have two kinds of things, methods and properties. A method is a thing you can do with it - for the user object you might define a 'change password' method - the rest of the code doesn't have to care how changing a user's password works or what's involved, it just says 'user object, this is your new password, you deal with the actual mechanics of changing it' (like this might be a change in the database or a call to a third party system, the whole point is the object knows how to do stuff and the rest of the world trusts the object to get it done) Meanwhile we have properties, these are things about an object. For example, for a user, one property would be the email address. All users have one, and the rest of a system can say 'hey, user object, what's your email address' - the object doesn't care why, or what it'll be used for. 1. Asymmetric Visibility When you define properties in objects before 8.4, they're either public, protected or private. If I have a user object that has a public email address, any other piece of code given that user object will be able to just request the email address from it - and update it. (Whether that item will save is a different question. Think of it as when you get the user object you write down all the details on a piece of paper, and you carry that piece of paper with you, and literally anyone who can see the piece of paper can read what's on it but also write on it) In other words: a public property is one that an object has that the rest of the code can both read and edit. Protected and private properties, by contrast, are not visible or editable to anything outside the object itself. For example, your user object might say the password is protected - nothing else can just ask the user object for it and arbitrarily be given it. But there is a space for properties that you might want to be easily readable but not easily changeable - you can do this today but you have to mess around writing helper functions to do it, and this newer method is much tidier. 2. Array Helper Functions Arrays are lists of things, and it's very common to need to find things in the lists. What that usually means is having to write a bunch of boilerplate when you need to do that, and to write code to go through every item in the list and make a new list of the ones that match the criteria you're looking for. These are tidy ways to do that fairly common set of things. 3. Improved String Handling PHP's always been a bit flaky around certain things with text where you're handling non-English text. For example, there's been a function called ucfirst() for years - uppercase the first character, so 'hello world' would become 'Hello world'. But if that first letter were accented, ucfirst() doesn't work and you have to go off and do a bunch of manual work to figure out if it's accented and then to do the conversion yourself. PHP's library for handling this stuff just got a bunch of extra tools (like a version of ucfirst() that can handle accented letters better) 5. Lazy Object Initialization So earlier we talked about objects, with all their properties - but to actually make an object you have to go through some hoops. This is a way of skipping the hoops until you actually need to do them, which for a lot of cases will make things faster (since you might get a collection of objects but only actually need the first one) 6. Exit and Die as Functions This is just tidying up the language; most things in PHP are either objects (so, code that represents a thing and remembers something about what state it is in) or is a function (a block of code that you feed some information into and get an answer out of). exit and die, though, were special cases that sort of acted like that (you put a thing in and you get an outcome out, namely the end of the script run) but they also behaved as not-functions for certain other cases. Better to just consistently be functions. 7. Bcrypt Security Update Bcrypt is a modern way of hashing a password (it's not encryption because you can't undo it to get the original password back) and one of the things this does is 'put the password in, run the same operation on it over and over and over'. The more times you run the encryption, the harder it is to break, and they've upgraded it from 'do this 10 times over' to 'do this 12 times over' for more secure password storage by default. 8. Implicit Nullable Types Deprecated PHP features the concept of 'null', a thing that you don't know what it is yet. The idea being that you logically have 'well I should have this value but I don't know what it is' separate to 'I know what this value is, and it is nothing'. E.g. second line of address for many people is blank - but there's a key difference between 'do I have a second line of address' and 'I know I do not have a second line of address'. This extends to functions, where a function says 'I need these pieces of information' and you say what types of information they are, and you can say 'if you aren't given this piece, here's what you can do instead'. Now, you can also say as part of this 'you might get this information, you might not, we might not know it yet' and legacy code would say '$variable = null' for this to say 'we might not know it yet, and if that's the case, use this magic value null as a placeholder'. But this is only an inference, and if you're going to the trouble of saying something like 'string $variable = null', you're saying it should be a string but null is acceptable... which really is saying 'actually I accept a string or null' not 'I accept a string only', so this is a thing about making it more strict and clearer what a function expects to be given, and what it would refuse as 'you didn't give me what I needed, something went wrong' 10. Hooks in Interfaces This is a really sexy one for a lot of complex stuff. We talked earlier about properties, but sometimes when you have properties, they're not simple bits of information about your object. Sometimes you'll have a property and when other people ask for it from you, you want to give them a more useful format. You could always do this, for the record, but it was always hella tedious to roll your own getters and setters to mimic this behaviour. e.g. I have a book object, the book object internally knows which authors wrote it, but I might want to be able to define a 'credits' property where I can just conveniently ask for 'the names of all the authors, as a simple string in the format of "name, name, name"' - now I can do that in a very short piece of code. Basically all of these are things are either strictness (making it easier to write good code because PHP will be better able to warn you that something isn't right), or convenience where you could always have done it but this lets you do it quicker and easier and usually faster to run too.

Pineapple is tasty, including on a pizza. Anchovies however are not ever welcome, pizza or not.