profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/majermi4/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

majermi4/FriendlyConfig 2

Provides a friendlier way to define Symfony configuration using plain old PHP objects.

majermi4/alice 0

Expressive fixtures generator

majermi4/daniela-slack-bot 0

A slack bot that preserves the legacy of our former colleague.

majermi4/FOSElasticaBundle 0

Elasticsearch PHP integration for your Symfony2 project using Elastica

majermi4/mongodb-odm 0

Doctrine MongoDB Object Document Mapper (ODM)

majermi4/MyBudget 0

A hobby App for keeping track of household expenses.

majermi4/nohec 0

Personal app for tracking expenses of our sports club

push eventmajermi4/FriendlyConfig

Michal Majer

commit sha df05c77dff574d7f3e9acab234740452f1ff2cc7

Fix condition to determine whether parameter has an attribute.

view details

push time in 12 days

push eventmajermi4/FriendlyConfig

Michal Majer

commit sha b5b615bbab867661c10270d33037ccb46bcac5ca

Add "ArrayKeyName" attribute that can be used to specify name of an array key.

view details

push time in 12 days

issue openedPHPOffice/PhpSpreadsheet

PPMT() function should not asserts that rate is a positive number

This is:

- [x] a bug report

What is the expected behavior?

In an native excel, the =PPMT (rate, per, nper, pv, [fv], [type]) function allows rate parameter to be a negative value.

Screenshot 2021-06-15 at 18 34 17

What is the current behavior?

The changes added in this commit/line now trigger error when calculating value of the PPMT function when negative rate value is given to it.

I have to admit that I'm not an expert on what the PPMT function does and how it is meant to be used but we have a lot of excel files from experts in the financial industry and they seem to use a negative rate value in this function which now causes our app to crash.

My proposed solution is to simply remove that one line of validation which will make PHPOffice/PhpSpreadsheet behave consistently with native excel.

Which versions of PhpSpreadsheet and PHP are affected?

Effected PhpSpreadsheet version: 1.18.0 and higher

created time in a month

issue commentPHPOffice/PhpSpreadsheet

HLookup::hLookupSearch(..) sends wrong arguments to LookupBase::checkMatch(..).

This is still and issue for us so I created a test excel sheet to demonstrate the problem.

Running this code:

$spreadsheet = IOFactory::load('./hlookup-test.xlsx');
$sheet = $spreadsheet->getSheet(0);
$cellVal = $sheet->getCell('H8')->getCalculatedValue();

On this excel spreadsheet: hlookup-test.xlsx

Screenshot 2021-06-14 at 16 49 22

Results in:

TypeError {#3754
  #message: "Argument 4 passed to PhpOffice\PhpSpreadsheet\Calculation\LookupRef\LookupBase::checkMatch() must be of the type int, string given, called in xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php on line 74"
  #code: 0
  #file: "./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/LookupBase.php"
  #line: 25
  trace: {
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/LookupBase.php:25 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:74 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:45 { …}
    PhpOffice\PhpSpreadsheet\Calculation\LookupRef\HLookup::lookup() {}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:4846 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3539 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3332 { …}
    ./vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Cell/Cell.php:259 { …}
    ./src/MyNamespace/Command/TestExcel.php:30 {
      MyNamespace\Command\TestExcel->execute(InputInterface $input, OutputInterface $output): void
      › $sheet = $spreadsheet->getSheet(0);
      › $cellVal = $sheet->getCell('H8')->getCalculatedValue();
      › 
    }

ping @MarkBaker let me know if I should provide any more information ;-)

majermi4

comment created time in a month

push eventmajermi4/FriendlyConfig

Michal Majer

commit sha b751429b3fc198ef20a0aee10c1b7858d9c6e9e4

Improve documentation.

view details

push time in a month

release majermi4/FriendlyConfig

v1.1.0

released time in 2 months

created tagmajermi4/FriendlyConfig

tagv1.1.0

Provides a friendlier way to define Symfony configuration using plain old PHP objects.

created time in 2 months

push eventmajermi4/FriendlyConfig

Michal Majer

commit sha 6310e1d515c1721fe8e826b95330423fcb0fa9a3

Add support for "mixed" type that maps to "variable" configuration builder node.

view details

push time in 2 months

release majermi4/FriendlyConfig

v1.0.1

released time in 2 months

created tagmajermi4/FriendlyConfig

tagv1.0.1

Provides a friendlier way to define Symfony configuration using plain old PHP objects.

created time in 2 months

push eventmajermi4/FriendlyConfig

Michal Majer

commit sha 6467d929d8f5098b5fe4a895bb0dd84e352dff53

Do not attempt to process doc comment comment when its value is an empty string.

view details

push time in 2 months

issue openedPHPOffice/PhpSpreadsheet

HLookup::hLookupSearch(..) sends wrong arguments to LookupBase::checkMatch(..).

This is:

- [X] a bug report

What is the expected behavior?

Calling $cell->getCalculatedValue() ($cell is instance of PhpOffice\PhpSpreadsheet\Cell) should work but it fails with the latest master.

What is the current behavior?

After $cell->getCalculatedValue() is called, the program fails with following error:

TypeError : PhpOffice\PhpSpreadsheet\Calculation\LookupRef\LookupBase::checkMatch(): Argument #4 ($rowKey) must be of type int, string given, called in 
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php on line 74
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/LookupBase.php:25
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:74
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/LookupRef/HLookup.php:45
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:4776
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3469
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3262
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Cell/Cell.php:259
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:5192
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:4669
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3469
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Calculation/Calculation.php:3262
 xxx/vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Cell/Cell.php:259

Here is the $cell variable value before $cell->getCalculatedValue() is called:

Screenshot 2021-05-27 at 17 25 14

And here are the values from a breakpoint right before the error is triggered at HLookup.php:73, PhpOffice\PhpSpreadsheet\Calculation\LookupRef\HLookup::hLookupSearch()

Screenshot 2021-05-27 at 17 30 04

What are the steps to reproduce?

Unfortunately, I cannot simply share the the excel file that fails because it is from one of our customers but let me know if any more information is needed apart from what was shared above. ;-)

Which versions of PhpSpreadsheet and PHP are affected?

Tested on current master branch with PHP 8.0 and 7.4.

created time in 2 months

issue commentsymfony/symfony

PoEditor translation provider pulls wrong translation keys

unless @majermi4 wants to open a PR 😉

@welcoMattic: I can have a look on the weekend and see if I can figure something out :) but can't promise anything

it looks like we have to handle language creation from the Provider, like it's done in Lokalise provider.

I'm not sure I get what you mean and how this is related 🤔 The main problem is that the keys pulled from PoEditor provider are indexed by the english (or whatever the main language is) translation instead of the keys that were pushed to PoEditor.

majermi4

comment created time in 2 months

issue openedsymfony/symfony

PoEditor translation provider pulls wrong translation keys

Symfony version(s) affected: 5.3.0-RC1

Description <!-- A clear and concise description of the problem. --> The translation keys pushed to PoEditor translation provider with bin/console translation:push poeditor are not the same as the ones pulled back using bin/console translation:pull poeditor --format yml.

How to reproduce <!-- Code and/or config needed to reproduce the problem. If it's a complex bug, create a "bug reproducer" as explained in: https://symfony.com/doc/current/contributing/code/reproducer.html -->

Create a Symfony project and install symfony/translation with symfony/po-editor-translation-provider.

Configure a poeditor provider and create 2 translation files for locales en and cs in the messages domain.

Screenshot 2021-05-21 at 23 36 16

Run bin/console translation:push poeditor which pushes the translations to Po Editor as it should.

Screenshot 2021-05-21 at 23 37 05

Run bin/console translation:pull poeditor --format yml. The local translation file was updated:

Screenshot 2021-05-21 at 23 45 29

I would expect that nothing should have happened because nothing was changed in Po Editor. Instead, it seems that the pull command uses the english translation as key when it reads data exported from Po Editor.

Possible Solution <!--- Optional: only if you have suggestions on a fix/reason for the bug --> I was able to fix the problem when I replaced this line: $source = isset($attributes['resname']) && $attributes['resname'] ? $attributes['resname'] : $translation->source; with: $source = $attributes['id'];

Additional context <!-- Optional: any other context about the problem: log messages, screenshots, etc. --> In the Po Editor project settings, I have set English as the Default Reference Language.

Screenshot 2021-05-21 at 23 53 44

I'm not sure if it's related to the issue but before I did that, the pull command would respond with these errors:

Screenshot 2021-05-21 at 23 55 02

created time in 2 months