Comments (39)
Thanks @szepeviktor and @herndlm... sorry for causing trouble, I'll be a little more careful next time :-)
from wordpress-stubs.
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
from wordpress-stubs.
sed -i -e 's#^.*@param string \+\$query \+Query statement.*$#&\n * @phpstan-param literal-string $query#' wordpress-stubs.php
from wordpress-stubs.
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;
from wordpress-stubs.
No problem!
I do not support the generator on MacOS.
It needs to run only on Debian-based linux systems.
from wordpress-stubs.
Implemented in bab860b
from wordpress-stubs.
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).
from wordpress-stubs.
You're welcome.
from wordpress-stubs.
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?
from wordpress-stubs.
Hello Martin!
wordpress-stubs
cannot fit all. And I have a mental limitation :) Please ask me 1 question. I'll try to answer.
from wordpress-stubs.
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 :)
from wordpress-stubs.
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.
from wordpress-stubs.
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).
from wordpress-stubs.
If you can somehow tell PHPStan that this is a literal string, everything should be good.
/** @var literal-string $table_prefix */
from wordpress-stubs.
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.
from wordpress-stubs.
Bring warm clothes and wait for 25th October :)
$query1 = $this->db->prepare('SELECT foo FROM %i', $this->db->prefix.'_bar');
from wordpress-stubs.
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.
from wordpress-stubs.
See https://github.com/berlindb/core , soon there will be a break-trough release.
from wordpress-stubs.
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.
from wordpress-stubs.
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...
-
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). -
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 haswpdb->allow_unsafe_unquoted_parameters
as a property, and we will be looking at how to set it to false). -
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.
from wordpress-stubs.
would it be ok to revert
How should I do that? What would be the new tag?
from wordpress-stubs.
dev-no-literal-string-query
??
https://github.com/php-stubs/wordpress-stubs/tree/no-literal-string-query
from wordpress-stubs.
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?
from wordpress-stubs.
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
from wordpress-stubs.
If you remove this line for now:
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).
from wordpress-stubs.
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
from wordpress-stubs.
I assume everyone uses the master
branch at the moment?
from wordpress-stubs.
I thought people are using stable tagged releases only.
from wordpress-stubs.
I'm not sure, maybe this change needs to be merged into master
, and a new tag created?
from wordpress-stubs.
I can only create a new tag when WordPress core is released.
~0 people are using dev-master
:)
from wordpress-stubs.
@craigfrancis Is it okay for you to issue composer require --dev php-stubs/wordpress-stubs:dev-no-literal-string-query
?
from wordpress-stubs.
@johnbillion, do you have any thoughts? I'm not familiar with this part of the process, maybe a v6.0.0a
?
from wordpress-stubs.
1 person needs dev-no-literal-string-query
4500 need tagged versions
What to do now? 🤔
from wordpress-stubs.
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.
from wordpress-stubs.
Please understand I'm not willing to release a non-official WordPress version.
from wordpress-stubs.
Which is why I said to wait for WordPress 6.0.1 and not release anything right now.
from wordpress-stubs.
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.
from wordpress-stubs.
Thank you both of you too!
from wordpress-stubs.
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
from wordpress-stubs.
Related Issues (20)
- Include `wp-includes/compat.php` HOT 10
- `wp_is_development_mode()` is missing from the stubs HOT 5
- wp_insert_attachment doesn't show WP_Error as possible return value HOT 5
- 6.4 new see tag HOT 9
- Tests for functionMap.php HOT 1
- Widget::widget() has never return type HOT 1
- stubs for wpdb::get_row() and wpdb::get_results() are wrong HOT 10
- Thanks HOT 1
- Fix page link types HOT 2
- Incorrect stubs since >5.9.3 + mismatch between packagist.org and GitHub HOT 17
- DocblockTypeContradiction with get_settings_errors() HOT 4
- Does anyone know when Request v2 will be part of core? HOT 2
- Test with new nikic/php-parser HOT 2
- Why globals are not included? HOT 5
- Improve types for `WP_REST_Request` HOT 3
- Check if function exists in wordpress-stubs.php HOT 7
- WordPress 6.2 in WordPress any more HOT 7
- functionMap.php wrong HOT 4
- `WP_Filesystem_Base::dirlist` returns an array<array> HOT 6
- Ondřej says: It doesn't make sense to combine void with something else in a union type. HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wordpress-stubs.