Using PhpStorm

[torvista]

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?

[torvista]

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?

[DrByte]

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.

[carlwhat]

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?

asking for a friend....

[DrByte]

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?

asking for a friend....

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.)
Lots of other settings around using the IDE or its appearance are more personal preference.

[marcopm]

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.

PhpStorm 2021.1 now supports prefixed table names: https://blog.jetbrains.com/phpstorm/...ames_in_sql_wi
However I don't know exactly how to make it work.
I tried making the file .phpstorm.meta.php (the tables have no prefix):

namespace PHPSTORM_META {
  override(
  // Virtual function to indicate that all SQL
  // injections will have the following replacement rules.
    sql_injection_subst(),
    map([
      "DB_PREFIX" => "",
    ])
  );
}

but the errors remain.

However in the article it says:

This works with concatenation as well. See the following example:

<?php
const DB_PREFIX = "mydatabase_"; 
$sql = "SELECT * FROM " . DB_PREFIX . 'table_name';

which means, I guess, that the previous .phpstorm.meta.php is not needed and you need to use const instead??

[torvista]

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.