4 ms·

Most plugins for WP should not be installed at all, period. Most have weird silly bugs or security issues, that are either due to handling user input improperly

Most plugins for WP should not be installed at all, period. Most have weird silly bugs or security issues, that are either due to handling user input improperly, or are just silly bugs, that one would think people would not build i to their code. But in WP land anything goes. And it has been that way for a long time. It feels like WP plugins are attracting lots of beginner developers, who would rather use a regex than a stored procedure to check for an SQL injection. That kind of level. Even the usual guideline for how to write themes favors concattenation over composition, starting an element in one file and ending it in another, so that it really only can be used in one place, and cannot be reused. wtf. And most themes are blindly following this convention. It feels like almost intentionally encouraging shoddy work.

9dev 3y ago
The mere fact that anyone would have to check for SQL injections by anything other than using prepared statements at all is very descriptive of the WordPress ecosystem and the kind of engineering conventions it enables. It’s a sad state of affairs that this terrible insecure mess is the base of so many websites. „Well it may be terrible but everyone uses WordPress, so I can’t be that bad, eh?“ - wrong. WP was in the right place at the right time, everything else is momentum. Anyone without any qualification sells themes and plugins, and it shows. In the construction industry, there’s a lot of codes and safety regulations to prevent that and ensure proper practices; it’s a shame the software industry doesn’t.
- racked 3y ago
  Wordpress actually provides a database wrapper (I wouldn't call it an ORM) called WPDB, which can use prepared statements. In practice though, I have found myself on more than one occasion just using PDO in my plugins. WPDB is slower, and its API is weird, like a lot of APIs in Wordpress land are.
ljm 3y ago
I wonder how much of this is because of PHP's legacy. For a long, long time, most articles and tutorials on PHP contained glaring examples of SQL injection, not to mention the whole thing with `mysql_string` and `mysql_real_escape_string`, among others, and embedding your DB credentials in the same file that is served to the client. Wordpress still uses and encourages patterns that weren't even considered unusual back in the late 00s. Same deal with phpBB if you want to modify that. I can only imagine that a lot of developers see the coding part of a plugin as a means to an end. You certainly won't see much of that in, say, Laravel.

9dev 3y ago

The mere fact that anyone would have to check for SQL injections by anything other than using prepared statements at all is very descriptive of the WordPress ecosystem and the kind of engineering conventions it enables. It’s a sad state of affairs that this terrible insecure mess is the base of so many websites. „Well it may be terrible but everyone uses WordPress, so I can’t be that bad, eh?“ - wrong. WP was in the right place at the right time, everything else is momentum. Anyone without any qualification sells themes and plugins, and it shows. In the construction industry, there’s a lot of codes and safety regulations to prevent that and ensure proper practices; it’s a shame the software industry doesn’t.

racked 3y ago
Wordpress actually provides a database wrapper (I wouldn't call it an ORM) called WPDB, which can use prepared statements. In practice though, I have found myself on more than one occasion just using PDO in my plugins. WPDB is slower, and its API is weird, like a lot of APIs in Wordpress land are.

ljm 3y ago

I wonder how much of this is because of PHP's legacy. For a long, long time, most articles and tutorials on PHP contained glaring examples of SQL injection, not to mention the whole thing with `mysql_string` and `mysql_real_escape_string`, among others, and embedding your DB credentials in the same file that is served to the client. Wordpress still uses and encourages patterns that weren't even considered unusual back in the late 00s. Same deal with phpBB if you want to modify that. I can only imagine that a lot of developers see the coding part of a plugin as a means to an end. You certainly won't see much of that in, say, Laravel.