I also found, that doing my own plain PHP imports/requires worked better than what WordPress by default wants you to do for example, so I can well imagine, that something similar can happen with Laravel.
Edit: Link that shows only PHP repos: https://github.com/aaviator42?tab=repositories&q=&type=&lang...
iniSettings();
enforceHTTPS();
session_start();
if(isset($_GET["m"]))
There are ... 60 lines of global logic, that is not encapsulated in any function or so?
Some of the functions are quite long. But I think mostly because they render out HTML.
At line 107 with the procedure printHeader starting, what I call PHP nightmare starts:
Switching back and forth between PHP, HTML and HTML with integrated JS (!!!) and CSS. All of course without syntax highlighting, but that is a minor issue. The major issue is treating HTML and JS and CSS as mere strings, instead of structured data, and the very bad readability of having procedures suddenly "end" and spit out some wild HTML, then suddenly continuing again, because some server side logic/decision is required at some place in that stream of unstructured data, whether some part is to be included or not, then the stream continues and then at some point one needs to actually check, that one did not forget to truly end the procedure. This has some of the worst readability. Maybe C code with bit magic is worse.
One can find this kind of approach in many, if not most, Wordpress plugins. What's more is, that this is also terrible for writing tests. The procedures do not return a value to check against. All is a side effect. Perhaps there is some PHP library that manipulates the PHP system, so that one can at least do string comparisons on the side effects. Like mocking, basically. But still terrible for testing.
For a comparison of how it should be done instead, check any templating engine, that at least separates template files from PHP code. Better, checkout SXML libraries, that treat HTML as structured data, a tree that can be traversed and pattern matched against, without pulling out arcane string manipulations or regular expressions. And then consider how one could write tests based on such structured data.
If this "HTML is a string, even on the server side before sending it" kind of approach is how a language treats HTML, then the language is not suitable to be directly used for HTML templating, without any additional library. This alone has caused uncountable security issues in so many projects.
I realize, that this is probably kind of a "one off script" and may not reflect other kinds of PHP code.
I did all of those things myself, years ago. And when I already had moved away from such an approach, I had to maintain a project, that was written this way. It had no tests of course. No fun. It has not that much to do with you personally being a good dev or not. I think it has to do with the ecosystem encouraging you to do these things. Outputting HTML like that should be declared illegal and should be impossible.
https://github.com/aaviator42/StorX/blob/main/StorX.php in comparison looks much better. It seems it does not output things directly. Everything seems wrapped nicely into methods. One obvious footgun seems to be another global state thing, that I really hope is not a thing in PHP itself:
const THROW_EXCEPTIONS = TRUE;
> enforceHTTPS();
> session_start();
> Global state things directly exposed to the user (programmer in this case). The problem here is, that this kind of thing immediately fails, when things start to use concurrency of any kind, because suddenly one has multiple processes concurrently setting global settings, without any kind of mutex in between.
No offense but I take it you don't have much experience with PHP (and that's fine).
Because your complain is exactly one of the beautiful things in PHP.
It's all per request.
It doesn't break.
You don't have to think about mutexes.
That said, I do have some book recommendations and some useful links.
Books:
* PHP & MySQL: Novice to Ninja by Tom Butler
* PHP 8 - Quick Scripting Reference by Mikael Olsson
* PHP 8 Objects, Patterns, and Practice by Matt Zandstra
* Programming PHP (2020) by Kevin Tatroe and Peter MacIntyre
Links:
* https://www.php-fig.org/psr/
* https://web.archive.org/web/20230110234256/https://www.cases...
> The only real difference is that Python will freak out over any small thing, so that developers can be super sure any potential issue or edge-case is caught, whereas PHP will keep on processing unless something extreme happens, at which point it will throw an error and report it.
Wtf. The real difference is, that in the real world people will ignore notices, because they are "merely notices" and because "it works right now", when there surely is a code path, that will rely on the variable being defined and that will catastrophically fail at a later stage or point in time, when the issue is much bigger than right when the undefined variable usage was introduced. How the F is this not an exception. If it can lead to errors and wrong results, which it both very realistically can, it should prevent people from continuing to run it. What happens instead is, that people will obliviously go on with broken code, possibly getting wrong results for years, before someone fixes it. Do not forget the manager people breathing down ones necks when things "work" but one still wants to "improve" things.
The statement is so disconnected from reality, it really makes me doubt the quality of rest of the content. Like a thinly veiled justification saying: "Oh but this is not actually an issue, believe me, all is fine!" when the house is on fire.
PHP is used by so many beginners, but actually due to all the foot guns is more suitable for mature developers, who are very vigilant and strict with themselves, to avoid these foot guns. Basically you cannot let a beginner anywhere near PHP, without a tonne of project setup to safeguard against all of this stuff.
> it really makes me doubt the quality of rest of the content.
I have not read all of it, all I know is that I have found some parts informative, but I have not used this website as my major source. It was mostly the books I have mentioned, especially the first one.