PHPStorm warnings on placeholders in WordPress plugin queries

I have a WordPress plugin that I am editing in PHPStorm. PHPStorm finds syntax errors on queries like this when the SQL dialect is set to MySQL:

$foo = $wpdb->get_var(
           $wpdb->prepare(
               'SELECT `foo` FROM `some_table` WHERE `id` = %d',
               $bar
           )
       );

Specifically, it sees %d and complains with this message:

Read More
<expression> expected, got '%'

Of course, %d is a perfectly legitimate placeholder in WordPress queries. Is there a way to configure PHPStorm to accept this? Or do I have to disable all checks on SQL statements, as suggested in this answer?

Note that I am using PHPStorm EAP 8 (138.1751), and the same thing happens with other placeholders like %s.

Related posts

Leave a Reply

2 comments

  1. This is now possible in PHPStorm 8, as explained by this post on the official PHPStorm blog:

    Database Language Injection Configuration

    To solve it:

    • Go to Tools > Databases
    • Make sure a regex matching the placeholders in question is in the list of custom parameters. By default, the list includes %w+, which will match %s, %d, etc.
    • Check the box labeled “Use in other language string literals”

    PHPStorm will now correctly recognize placeholders like those used in WordPress.

  2. Nope — %d is not valid syntax from SQL point of view (ANY currently supported dialect). The WI-3672 and WI-2324 tickets are still valid.

    But PhpStorm v8 now supports $var (if you could use it instead of % syntax) — http://youtrack.jetbrains.com/issue/WI-2450


    Since it’s WordPress specific question, it’s hard for me to give you any real suggestion (especially since I’m not using WordPress myself) excluding that one.

    But generally speaking you could use native place holders supported by specific DB engine (check “Examples” section in http://php.net/manual/en/pdo.prepare.php):

    • unnamed ?
    • named :id

    I just not sure if this can be applied to WordPress development.


    P.S.
    Generic is the new Keywords only dialect — fall back to that if using proper SQL dialect shows to many warnings/errors (that are not actual errors).