Using `literal-string` for `wpdb::prepare()` about wordpress-stubs

[craigfrancis]

Thanks @szepeviktor and @herndlm... sorry for causing trouble, I'll be a little more careful next time :-)

[szepeviktor]

would it be ok

Hello Craig! 👋
Thank you for your first issue.

This is an automatically generated stubs repository.
Would it be a single change? I could offer you adding sed to our generate.sh to change a single line!
https://github.com/WordPress/WordPress/blob/5.9.3/wp-includes/wp-db.php#L1386

[szepeviktor]

sed -i -e 's#^.*@param string \+\$query \+Query statement.*$#&\n         * @phpstan-param literal-string $query#' wordpress-stubs.php

[craigfrancis]

Hi Viktor, and thanks for the quick suggestion.

tbh it was @johnbillion who suggested adding it to this project, where I'd like to see what feedback you get (ideally none, as I'm hoping that everyone using your project is using wpdb::prepare() in a safe way).

Not sure if you intend to run it on MacOS with the default sed, but I think the -i flag needs to have the extension explicitly set (e.g. -i ''), and I'm fairly sure + doesen't work... just as a quick hack job before leaving for the day, I got this to work:

sed -i '' -e 's#^.*@param string  *\$query  *Query statement.*$#&\n         * @phpstan-param literal-string $query#' wordpress-stubs.php;

[szepeviktor]

No problem!
I do not support the generator on MacOS.
It needs to run only on Debian-based linux systems.

[szepeviktor]

Implemented in bab860b

[craigfrancis]

Thank you Viktor, I’ll try to keep an eye out for any issues (if any crop up, it would be good to see what they are).

[szepeviktor]

You're welcome.

[herndlm]

Hi both of you, thx for this adaption, I think it makes sense security-wise!

Just one question: apparently in WP a common way of accessing tables is using some public props of wpdb, a common one being wpdb::$prefix, but there are also some for internal tables, see e.g. example from https://developer.wordpress.org/reference/classes/wpdb/#examples-10

Since wpdb::prepare now enforces literal-string those constructions are not possible any more of course. They should still work fine if placeholders are used. But I was just wondering if it makes sense to take a further look and try to mark some of them with literal-string too? I did not take a closer look yet, but I think they are basically constructed with the help of some super globals like $table_prefix from wp-config.php which should be a literal-string. In the end it could be anything though I guess, which feels like we can't make them literal-string? Do you advice just to use placeholders for everything?

UPDATE: oh wait, I saw (too late) that your examples in the WP tickets include such cases. Am I assuming right that this will start working because of your WP core changes soon or at least change in behaviour again? Is this a good argument to wait for it maybe with the changes here?

[szepeviktor]

Hello Martin!
wordpress-stubs cannot fit all. And I have a mental limitation :) Please ask me 1 question. I'll try to answer.

[herndlm]

No worries Viktor, this was more meant for Craig anyways, sorry. Since he did the adaptions in WP core. I think I just did not fully grasp yet where this exactly is going. And I wanted to make sure I use it correctly :)

[johnbillion]

I think the reason table names aren't literal strings is because of the $table_prefix global. If you can somehow tell PHPStan that this is a literal string, everything should be good.

[craigfrancis]

Hi @herndlm, if you want to email me directly (address shown on my profile page when logged in), we can discuss off-list (as this isn't really related to the php-stubs project).

If you have an example, that would be good.

I think it depends on what you're testing, as the $table_prefix is usually defined as a literal-string in wp-config.php, and this is simply concatenated with wpdb::tables property (which is an array of literals) via the wpdb::tables() method, and concatenation of literal-string values is allowed.

As an aside, I might have been a bit too quick for this change, as the %i placeholder has been merged for WordPress 6.1 (assuming all goes well, the general release is planned for 25th October).

[szepeviktor]

If you can somehow tell PHPStan that this is a literal string, everything should be good.

/** @var literal-string $table_prefix */

[herndlm]

Sorry, I should have started with examples from the beginning. I currently have this

final class LiteralTest
{
    private wpdb $db;

    public function __construct(wpdb $db)
    {
        $this->db = $db;
    }

    public function test1(): void
    {
        \PHPStan\dumpType($this->db); // wpdb
        \PHPStan\dumpType($this->db->prefix); // string
        \PHPStan\dumpType($this->db->posts); // string
        $query1 = $this->db->prepare("SELECT foo FROM {$this->db->prefix}_bar"); // Parameter #1 $query of method wpdb::prepare() expects literal-string, non-empty-string given.
        $query2 = $this->db->prepare("SELECT * FROM {$this->db->posts}"); // Parameter #1 $query of method wpdb::prepare() expects literal-string, non-empty-string given.
    }
}

which makes sense I guess since those are public props that are somehow set very dynamically.

[szepeviktor]

Bring warm clothes and wait for 25th October :)

$query1 = $this->db->prepare('SELECT foo FROM %i', $this->db->prefix.'_bar');

[herndlm]

Bring warm clothes and wait for 25th October :)

$query1 = $this->db->prepare('SELECT foo FROM %i_bar', $this->db->prefix);

I know, we do it like this (UPDATE: without the %i but some other trickery obviously :D) now. But I wanted to verify if all of this was really intended like that or if it was maybe too early / missing something. At least the "normal" WP way is not working now anymore.
"Do it like that instead for security / complexity reasons" is an answer I'm fine with. But I basically wanted to avoid that I a) misuse it and b) x other people will come with the same problem.

[szepeviktor]

See https://github.com/berlindb/core , soon there will be a break-trough release.

[herndlm]

Had a thought about this again, I'd be fine with using the %i feature, that makes total sense. I saw that my colleagues tried to fix the newly reported errors using smth like

$this->db->prepare('SELECT foo FROM %s_bar WHERE baz = %d', $this->db->prefix, $someOtherValue);

Then they noticed that this messes up the table name because of quotes and modified it to

$this->db->prepare('SELECT foo FROM %1$s_bar WHERE baz = %2$d', $this->db->prefix, $someOtherValue);

which avoids the quotes for BC apparently according to https://developer.wordpress.org/reference%2Fclasses%2Fwpdb%2Fprepare%2F/#description

Anyways, I don't like that either and I also don't want to ignore those errors.

Is there a chance we can revert this for now and wait for WordPress 6.1? WDYT @craigfrancis
Also I can't resist to quote yourself Viktor when I tried to imrove something in a related repo

To be honest I do not know what will happen by this PR.
Thousands use WP core stubs!

Isn't that a good reason to be careful here too? At least as long as we don't have a clean way of using this security measure combined with the wpdb public props.

[craigfrancis]

Hi @herndlm, I think you're right, I wanted to spend a bit more time thinking of the options, but I suspect I've been a bit too eager.

Sorry @szepeviktor, would it be ok to revert or comment out this change for now, and I can ask for it to be re-added when WordPress 6.1 is out, probably in October?

---

Side notes...

1. We could look at setting wpdb->prefix, wpdb->base_prefix, wpdb->tables, etc as literal-strings, and in most cases that would work... but I suspect multi-site will not, and there would be quite a few properties that will need updating (where I'd rather keep this simple, and not add a load of modifications).

2. Everyone could use %1$s, but this is an old WordPress "feature" that does partial escaping, and I'd rather no-one use it, simply because it's risky (in this case, it would be using string escaping, for variables that need identifier escaping, which is a Bad Idea™). And as an aside, I am working to find a way to remove/disable this feature (it's why 6.1 has wpdb->allow_unsafe_unquoted_parameters as a property, and we will be looking at how to set it to false).

3. Everyone affected by this, where their static analysis level has been set high enough, could ignore this error, but they would need to remove that when 6.1 was released.

[szepeviktor]

would it be ok to revert

How should I do that? What would be the new tag?

[szepeviktor]

dev-no-literal-string-query ??
https://github.com/php-stubs/wordpress-stubs/tree/no-literal-string-query

[herndlm]

not sure if you're joking or not, you're Viktor after all :D
6.0.1, no? and it can come back in with 6.1.0?

[szepeviktor]

6.0.1

I can't release a non-WordPress release.
So should I wait for that?

For now there is dev-no-literal-string-query

[craigfrancis]

If you remove this line for now:

bab860b

I'll add a note in my calendar, to ask for it to be re-added when WordPress 6.1 is out (sorry for messing you around).

[szepeviktor]

In which branch/tag??

It is already removed in https://github.com/php-stubs/wordpress-stubs/commits/no-literal-string-query
composer require --dev php-stubs/wordpress-stubs:dev-no-literal-string-query

[craigfrancis]

I assume everyone uses the master branch at the moment?

[szepeviktor]

I thought people are using stable tagged releases only.

[craigfrancis]

I'm not sure, maybe this change needs to be merged into master, and a new tag created?

[szepeviktor]

I can only create a new tag when WordPress core is released.

~0 people are using dev-master :)

[szepeviktor]

@craigfrancis Is it okay for you to issue composer require --dev php-stubs/wordpress-stubs:dev-no-literal-string-query ?

[craigfrancis]

@johnbillion, do you have any thoughts? I'm not familiar with this part of the process, maybe a v6.0.0a?

[szepeviktor]

1 person needs dev-no-literal-string-query
4500 need tagged versions

What to do now? 🤔

[herndlm]

ah I see, I wasn't aware that the version is a 100% in sync with WP itself. We have the latest installed, because an update of szepeviktor/phpstan-wordpress updates this package as well. See also

composer why php-stubs/wordpress-stubs
php-stubs/wordpress-stubs      v6.0.0  replaces  giacocorsiglia/wordpress-stubs (*)
szepeviktor/phpstan-wordpress  v1.1.2  requires  php-stubs/wordpress-stubs (^4.7 || ^5.0 || ^6.0)

You could just leave it like this and then release it together with WP 6.0.1? Not sure if composer allows even versions like 6.0.1-1 or 6.0.1-a hmm.
in the mean time using master would fix it yeah. a dedicated tag just for this is weird, I agree.

[szepeviktor]

Please understand I'm not willing to release a non-official WordPress version.

[herndlm]

Which is why I said to wait for WordPress 6.0.1 and not release anything right now.

[szepeviktor]

Now this change is in dev-master.

My paying clients do not user WP stubs. This is a big hobby project for me. And I do not write code daily.

[herndlm]

Thank you both of you too!

[szepeviktor]

Actually I have problem with non-existent database handling in WordPress.
It allows and forces developers to input SQL queries and concatenate strings.

I'm strugggling hard to support this nonsense 😬
Everyone please consider using https://github.com/berlindb/core 👀 and the coming v.2.1.0