Missing logging capabilities

Recently, the http article-feed was found to have no response. Closer inspection offered the cause in poor data quality an not related to ff-module, but debugging the module offered some issues that are worth to note here:

1.) ArticleFeedController.php capsules all export funtionallity in a single try-finally-block, leaving exceptions to evaporate into open sky. Dev has no chance to find any initial hint what's going on. Time consuming line debugging is required. Please catch exception and log $e->message() to oxideshop.log appropriately.

2.) Structure of the module offers surprises: all code is copied to source/module/ff but php-code is executed below vendor/ exclusivly. Any break point set in source/modules is never met. For js the situation is vice versa.

3.) Pls consider changing the export strategy: any exception related to a single article causes the breakdown of the overall stream. Isn't it better behaviour if this exception is logged an this particular article is removed from stream? Doing so, would be a much more ruggedized approach.

tnx

Again in a hassle to find the root cause for a broken article feed.

Attached for the public is a patch for ArticleFeedController that can be used in conjunction with "cweagans/composer-patches". Having applied this patch, any errors and exceptions breaking the Feed are logged to oxideshop.log.

I have strong opinions about code using try-finally-blocks and not logging exceptions to disc...

---

--- src/Controller/ArticleFeedController.php	2022-04-19 10:48:49.000000000 +0200
+++ src/Controller/ArticleFeedController.php.mod	2022-06-03 14:08:21.387662500 +0200
@@ -39,6 +39,8 @@
             $oUtils->setHeader('Content-Disposition: attachment; filename=' . $feed->getFileName());
             $oUtils->setHeader('Content-Type: text/csv; charset=utf-8');
             fpassthru($handle);
+        } catch (\Throwable $e) {
+            Registry::getLogger()->error($e->getMessage());
         } finally {
             fclose($handle);
             $oUtils->showMessageAndExit('');

[a-laurowski]

hi @m-schiewi
Errors are logged by the http server.
what will be the benefit of logging them using proposed method? Does Registry::getLogger()->error($e->getMessage()); write the output somewhere else than in disc?

Those Errors are NOT logged in apache's error log. Furthermore, oxideshop.log is the usual place to log to, when dealing with Oxid-eShop, so any Oxid-Module should do so.

[a-laurowski]

Hi @m-schiewi and thanks for feedback.
I don't mind adding your code to the module but do you know what exactly is the reason that those errors are not logged in apache/nginx error log?

I guess these cases are considered as "already handled" since there is this try-finally-construction, no matter the catch-phrase is left out.

It needs a deep dive into literature, since the try-finally-nocatch-costruct is rarely described.

[a-laurowski]

hi @m-schiewi
Regarding

all code is copied to source/module/ff but php-code is executed below vendor/ exclusivly

what should we need to change in a module structure to make it execute always in one place directory. I also find this problematic, especially during debugging. I didn't recall such situations in older version of oxid though.
Module has been created yet for version 6.0 and we were using https://docs.oxid-esales.com/developer/en/6.0/modules/skeleton/structure.html#module-structure-in-oxid-eshop
fof reference

Try leaving out "source-directory" in composer.json. Most modules I know of lack this field.

[a-laurowski]

hi @m-schiewi
thanks for the hint. We will try to change that, although i'm not sure if this won't make the module not compatible with the older Oxid versions like 6.1. AFAIR source-directory section was explicitly listed in developer documentation as something that must exist in module composer.json file.

In the meantime, we created a PR that adds additional logging to the module, and also offers a way to continue the export on failures, and each exception during that process is logged to a file