Printable View
The inspections in PhpStorm flag up constants that it cannot find, such as those in the database, as errors.
As far as I can tell, the only way to stop these errors is to have the database constants (configuration_keys) duplicated in a file that PhpStorm CAN find/index.
So I did a script that generates a suitable file:
https://github.com/torvista/zen-cart...tion-constants
Constructive criticism welcome!
Great idea.
As for naming convention, I have both my .gitignore and my FTP app set to ignore all "dev-*.php" files, so that they aren't committed to VCS nor uploaded to servers.
Alternatively, other utility tools often use underscore prefixes, for example one of them is: _ide_helper.php
(I avoid using dot-prefixed files for semi-sensitive things like this, just in case I accidentally ignore them because they're hidden-by-default.)
Is there any way to get these sql inspections to work, instead of switching them off?
Attachment 18434
I haven't tried it in a while, but supposedly if a connection to a database was made, then those type of notifications would go away. I found this related to making that connection: https://www.jetbrains.com/help/phpst...-database.htmlQuote:
Originally Posted by torvista
Last time I tried to do this a couple of years ago I ran into some sort of issue that I'm sure was my fault or doing.
The problem is not the database connection (that is working ok), but that PhpStorm cannot read/substitute the database constants in those queries for the constant definitions in
includes/database_tables.php with the DB_PREFIX.
So, this does not work:
define('TABLE_PRODUCTS', DB_PREFIX . 'products');
but this does work (clears the error)
define('TABLE_PRODUCTS', 'products');
web searches indicate this is not possible, I was just wondering if anyone had found a way to make it work without changing includes/database_tables.php.
There is a PHP inspection plugin for Phpstorm called EA Extended: another world of php nitpicking to spend endless hours with, but the principal things it spits out are
recommending strict comparisons when possible.
ie.
if ($action == 'edit')...
to
if ($action === 'edit')...
and using single quotes around sql text chunks
As there are so many of them to initially correct, it's hard to see any real issues (can't see the wood for the trees).
For ongoing code/PR submissions, should I "correct" these things or ignore them?
Quote:
Originally Posted by torvista
Did you ever find a workaround? I have modified includes/database_tables on my local install to avoid the issue.
I'll have to install that, thanks for pointing it out. I think it's important moving forward to future-proof so think making the changes as the code is being worked on would be the best way. That's what I've been doing, and the amount of warnings when the log all errors mod is on is steadily shrinking.Quote:
Originally Posted by torvista
No. I did the same.Quote:
Did you ever find a workaround?
To prevent php inspection flagging up multiple errors as "undefined variables" for uses of messagestack and zco_notifier, you can add this to the start of the file you are working on, temporarily:
Quote:
/**
* @var messageStack $messageStack
* @var zcObserverLogEventListener $zco_notifier
*/
inspection error "undefined constant" when constants are in arrays.
Currently ZC156, constants are in files and phpStorm can find them.
In the ZC157 Installer, the constants are in an array, main.php and phpStorm cannot find them/flags all of their uses as undefined.
Since I believe this method of defining constants is the plan for the future, a method to correct this inspection would be of use.
Apart from using a separate script to create a file with a static list as done for the db constants it cannot find either (https://github.com/torvista/zen-cart...tion-constants),
anyone have a solution?
Regarding consistent coding standards, there is an .editorconfig file in the zencart GitHub repository.
I note the composer file specifies the php levels but I don't see anything else specific to the editor (like PSR-2).
Is there anything else that will indicate to IDEs how code should be laid out etc. or we should just set PSR-2 manually and there is nothing else to do?
Unfortunately .editorconfig doesn't enforce language-specific coding standards, just small things like spacing and line-endings.
To implement PSR-2 in PhpStorm, in your Editor->Code Style settings, go to PHP and click the "set from..." link, choose "PSR2."
Then, press CTRL+ALT+L to reformat your code ... either for a highlighted selection of code or for the entire current file.
You can set PhpStorm's settings to apply per-project or for all projects.
so there is no real way to export a settings file from phpstorm that has all of the ZC codings standard already encapsulated in it?Quote:
Originally Posted by DrByte
asking for a friend.... :smile:
As far as a settings file for code-formatting, PSR-2 (or PSR-12 is probably fine too, although a lot of ZC code doesn't use things it addresses) is about all you need for code such as the v158 branch. (Or, at least, in this moment that's all that comes to mind.)Quote:
Originally Posted by carlwhat
Lots of other settings around using the IDE or its appearance are more personal preference.
PhpStorm 2021.1 now supports prefixed table names: https://blog.jetbrains.com/phpstorm/...ames_in_sql_wiQuote:
Originally Posted by torvista
However I don't know exactly how to make it work.
I tried making the file .phpstorm.meta.php (the tables have no prefix):
but the errors remain.Code:namespace PHPSTORM_META {
override(
// Virtual function to indicate that all SQL
// injections will have the following replacement rules.
sql_injection_subst(),
map([
"DB_PREFIX" => "",
])
);
}
However in the article it says:
which means, I guess, that the previous .phpstorm.meta.php is not needed and you need to use const instead?? :huh:Quote:
This works with concatenation as well. See the following example:
Code:<?php
const DB_PREFIX = "mydatabase_";
$sql = "SELECT * FROM " . DB_PREFIX . 'table_name';
Yes I saw that, but I find that phpStorm now finds the table definition with the prefix, without having done anything: there is no error, with SQL all inspections enabled...so I don't know how that happened, but it's no longer flagging an error for me.