Changes between Version 3 and Version 4 of Ticket #41925, comment 3
- Timestamp:
- 09/20/2017 10:29:19 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #41925, comment 3
v3 v4 1 1 It wasn't, but it worked even when the docs said it wasn't supported. And seeing that 1.2 million lines of code made use of this unofficial feature I think it's a good idea to bring it back. Right now WordPress is generating invalid SQL code for 1.2 million usages. Fatal errors. I don't think this is good back-compatibility policy. Yes, all of us have failed to stick to the official documentation, but the unofficial way worked. So this is just a feature request to start supporting it seeing it's vast usage in the wild. 2 3 However, to bring it back (or reimplement it) in a safe way we have to first understand what the security issue with it was. Until that's disclosed a patch cannot be worked on.4 5 Again, this is a matter of patching 1 line in WordPress vs. patching 1.2 million lines in the wild.6 2 7 3 This ticket is a feature request for 1.2 million lines of code out there. They just don't know they need it yet, but by the end of the month you'll be seeing all hell break loose in support departments and forums and oh the poor developers! Who are they going to blame? wpdb->prepare and WordPress. 8 4 9 Let's bring this back and support it officially and safely, shall we? Let's be back compatible, even if 1.2 million "bad" decisions were made, let's make it right as soon as possible. 5 Let's bring this back and support it officially and safely, shall we? Let's be back compatible, even if 1.2 million "bad" decisions were made, let's make it right as soon as possible. Again, this is a matter of patching 1 line in WordPress vs. patching 1.2 million lines in the wild. 6 7 However, to bring it back (or reimplement it) in a safe way we have to first understand what the security issue with it was. Until that's disclosed a patch cannot be worked on.