Which query need to be escaped

Hi ace0930 — I don’t think those two are the only ones. As a general rule, if you’re passing a SQL query as an arg, as we would with $wpdb->get_var(), then the SQL should be prepared. $wpdb->update() does not take any SQL as an arg, so there’s nothing to prepare. update() and similar methods will prepare its own SQL that it generated internally.

Unlike my suggestion for your other question about output escaping, it’s not that simple to simply test a string we know needs escaping to see if it was escaped or not. I believe the above general rule is always applicable, but I’ve not verified with every possible method. If you really want to be sure, you’d need to read through the source code to see if prepare() is used or not.

@bcworkz Hi, why not just use the PHP prepared statement “link“, but use $wpdb -> prepare?

Sorry for running out a bit of topic, from the last question regarding esc_url, you mentioned that I could have put in some data into the function and check if it need to be escaped with esc_url. If I pass something like get_site_url ( null, test test ) and it returns https://test.com/test test, is that mean I need to use esc_url in this case since the space is not escaped? BUT is that a possibility that the function only escapes for the base URL part but not the $path parameter? ( wish it sounds not complicated to you…LOL )

Back to the topic, do you mean unlike testing the URL as I have done above, I have to look at the source code for the query this time yaa?

Why do we use wpdb class over mysqli for anything DB related? ˉ\_(ツ)_/ˉ
It seems that WP likes to insulate us from raw PHP for many things.

I don’t think get_site_url() escapes anything for us.

It’s more complicated to test $wpdb methods. You’d need to find where your passed unprepared test SQL is just about to be executed with $wpdb->query() and dump out the SQL for inspection, then die before actual execution. Then revert the code you had to modify to do so. IMO it’s simpler to read through the related source code to see if any sort of preparation occurs.

I’m fairly sure my general rule holds true, I just cannot say with 100% certainty.

@bcworkz It doesn’t make sense for me to escape the $path parameter of get_site_url because it’s me who wrote it and I know it’s safe. I was asking how to test the main/base_url part because I cannot add any data to it.

For example, get_site_url ( 'apple' ) would return https://example.com/apple
So the apple is definitely safe because I hardcode/manually type it. But how do I test the main/base_url part https://example.com/ because I cannot put any data into it fro testing purposes…

For the query part, I understand now and I agree with you, thank you so much!

Correct, static strings needn’t be escaped. It’s variable data from the DB or users that is suspect. The ‘apple’ part is fine, it’s the root URL which comes from the DB that could be suspect. There’s no harm in escaping the ‘apple’ part along with the rest of the URL, provided it hadn’t manually been “pre-escaped” or something like that. Specific to ‘apple’, there’s nothing to escape. But if you appended '?foo=apple%20core', you wouldn’t want to URL encode that once more.