We had an issue with strings as config values containing words (white-space separated) that started with two dashes as those were interpreted as additional options (which then were undefined).

This proposed change did levitate the problem on our end.

Example YAML:

some_settings/setting/config_value:
  default:
    0: '-15px'

Trying to import the above results in the following error:

[RuntimeException]               
  The "-1" option does not exist.  

Seems to be the same for any value starting with a minus sign.

to prevent the creation of incorrect database entries we should validate whether a scope-scopeId combination is valid. Otherwise you may have strange side-effects and database entries.

When we added this to the require section of composer.json, we get the following error:

The requested package zookal/harris-street-impex could not be found in any version, there may be a typo in the package name.

It appears the package isn't actually available for composer?

If a configuration value has a single quote, it will be escaped. e.g.

'Our price is lower than the manufacturer\'s "minimum advertised price."  As a result, we cannot show you the price in catalog or the product page. <br /><br /> You have no obligation to purchase the product once you know the price. You can simply remove the item from your cart.'

The import parser for YAML provide an error and doesn't import the content.

By changing from single quote to double quote for text delimitation and escaping those double quote the import has no issue.

"Our price is lower than the manufacturer's \"minimum advertised price.\"  As a result, we cannot show you the price in catalog or the product page. <br /><br /> You have no obligation to purchase the product once you know the price. You can simply remove the item from your cart."

This is counter-intuitive if you want to write to stdout.

For example the following command does not work:

$ n98-magerun.phar hs:ccd:export --include shipping/origin -fphp://stdout

because the following filename becomes created:

Failed to write: php://stdout.yaml

Automatically adding ".yaml" destroys the portability of the switch. I suggest to remove that feature for -f / --filename and add a new switch that brings it back: --prepend-filename-with-dot-yaml-extension.

I'd like to get some feedback on this suggestion before I consider to provide a PR. Thanks.

Hi,

i created an experimental feature to run n98-magerun commands out of a config. I tested it only in yaml files.

The configuration lools like this:

commands/run:
   - cache:flush
   - config:get web/*

What do you think?

symfony/yaml is allready a dependency of n98/magerun package and already included in the phar file. I have some trouble because "*" will try to install the latest dev-master package of symfony/yaml which needs at least PHP 5.5.3. Not all servers have PHP 5.5 installed.

The YAML export escapes single quotes with a \ which is incorrect and causes an error to occur on the import of any such strings.

In YAML, a double quote '' (i.e. 2 singles) is how a single ' quote is escaped.

Suggested resolution in src/HarrisStreet/CoreConfigData/Exporter/Yaml.php change:

return '\'' . addcslashes($value, '\'') . '\'';

to

return sprintf("'%s'", str_replace('\'', '\'\'', $value));

Using YAML export a string like '000000' is exported without quotes. This means upon import it is then treated as a numeric value and is imported as 0. You can see how this can cause problems.

Magento core_config_data treats everything like a string so it makes sense if the export / import does also.

Possible solution: in src/HarrisStreet/CoreConfigData/Exporter/Yaml.php remove the is_numeric test and treat everything like a string.

Like the DNS system uses names instead of numbers to make the system more robust in a distributed environment, I see great use in using store and store-view codes (which are names) instead of IDs (which are numbers) when importing data (same can be applied to exporting, too).

This change would be backwards compatible because it can be clearly differentiated between numeric ID and alpha-numeric store code (if you follow the rule to not start it with a number or you don't only use numbers).

I plan to file a PR as I got positive feedback for this feature already from my peers at work. I'm pretty sure it is much appreciated.

This is counter-intuitive if you want to write to stdout.

For example the following command does not work:

$ n98-magerun.phar hs:ccd:export --include shipping/origin -fphp://stdout

because the following filename becomes created:

Failed to write: php://stdout.yaml

Automatically adding ".yaml" destroys the portability of the switch. I suggest to remove that feature for -f / --filename and add a new switch that brings it back: --prepend-filename-with-dot-yaml-extension.