fact-finder-web-components / oxid-eshop-module Goto Github PK

Extend the asn.tpl and add the missing slots, so that we can translate these labels in the module

hello

is this a beta release for factfinder?

please use the metadata modul version: https://github.com/FACT-Finder-Web-Components/oxid-eshop-module/blob/master/src/metadata.php#L20

normally the same as release version ...

thanks

Stack trace:
#0 [internal function]: Omikron\FactFinder\Oxid\Export\Field\FilterAttributes->Omikron\FactFinder\Oxid\Export\Field\{closure}()
#1 /var/www/integration/20210708T125103/vendor/omikron/oxid-factfinder/src/Export/Field/FilterAttributes.php(42): array_map()
#2 /var/www/integration/20210708T125103/vendor/omikron/oxid-factfinder/src/Export/Field/FilterAttributes.php(31): Omikron\FactFinder\Oxid\Export\Field\FilterAttributes->getVariantValues()
#3 /var/www/integration/20210708T125103/vendor/omikron/oxid-factfinder/src/Export/Entity/ArticleEntity.php(42): Omikron\FactFinder\Oxid\Export\Field\FilterAttributes->getValue()
#4 [internal function]: Omikron\FactFinder\Oxid\Export\Entity\ArticleEntity->Omikron\FactFinder in /var/www/integration/20210708T125103/vendor/omikron/oxid-factfinder/src/Export/Field/FilterAttributes.php on line 38

Admittedly this is due to corrupted data, but since this can seriously impact a shop as it will completely stop the FACT-Finder export from working, you should not rely on external code and data like this.

Remember, the getFieldData method of the OXID shop currently looks like this:

/**
 * Gets field data
 *
 * @param string $fieldName name (eg. 'oxtitle') of a data field to get
 *
 * @return mixed value of a data field
 */
public function getFieldData($fieldName)
{
    $longFieldName = $this->_getFieldLongName($fieldName);
    return ($this->$longFieldName instanceof Field) ? $this->$longFieldName->value : null;
}

So it can return anything. Including null

My proposal (even though it will degrade performance a little) is to either check those values and throw an error on null and continue with not impacted data rows, force them to be '' on null or change your code to allow for null in other ways.

oxid enterprise 6.2

source/modules/ff/ffwebcomponents/bin/feed-upload.php -s 2

always exports the same data, no matter which shop id is used. already talked with @fmarangi about this problem ...

I think this should also changed to from page/factfinder/result.tpl to ff/page/result.tpl to be more consistens. Or is it works as intended?
It is just a bit confusing.

On the search result page, the search event is triggered twice when a search query is submitted using the <enter> key.

As for now the module is generating custom SID, base on real session id. This could be problematic to track continuity of customer actions when he logs in and his real session id is changed.

Customer had an attribute with Title Shopattribute "New"
When open module setting page section feed settings, adding a new attribute is not possible and stored attributes are not displayed.
Quotation marks in titles destroy json structure.
Steps to reproduce:

• Create an attribute with Quotation marks in Title
• Open settings page for oxid module

The feature of advisor campaigns is not available on the search result page of OXID eShops using this module

We need this line for the module to correctly talk to our shiny new FACT-Finder backend. Else the links within a landing page do not work and the DevConsole of the browser will only show an error message from the web components JavaScript that tracking campaigns does not work (BTW: It is good to throw an error in the console, but it is not good to prevent the links from functioning if the data-redirect-target is _self ... )

So please, can we have a new release soon? :)

The module allows to export feeds for specific languages via CLI command using lang parameter, however Oxid doesn't offer possibility to set configuration value for specific language. It means that all languages for given shop will be using the same FACT-Finder channel

Imagine an article "MyFavouriteCar" available in two variants for motor power having 100 HP (= horse power) and 150 HP respectivly. Database would contain three records as follows: parent_mycar, child_100hp, child_150hp).OXVARNAME and OXVARSELECT are set accordingly for the 100HP and 150HP

Imagine attribute "Fuel Consumption" exists in the shop. Value assignments would be like:

• child_100hp: "6 l/100km"
• child_150hp: "10 l/100km"
  (it's obvious, that the stronger powered car has a higher fuel consumption)

You could also imagine an attribute called "Energy label"

• child_100hp: "A++"
• child_150hp: "A+"

Even if these attributes are enlisted as "filter attributes" in module settings, its values are not contained in the article feed.

Root cause can be found in FilterAttributes.php:29-33
in short: if $article is not parent, only the corresponding variant value is collected. Attributes assigned to the child are ignored.

General remark:
attributes value atttached to child articles usually show a direct functional dependence to the corresponding variant value. Here: fuelconsumption = f(horsepower) or energy_label = f(horse_power). Customer must have the possibility to filter for these values.

Not all parameters from https://web-components.fact-finder.de/api/4.x/ff-communication#tab=api that make sense are configurable via the module settings.
Either those should be added or at least be added to the
protected $mergeableParams = ['add-params', 'add-tracking-params', 'keep-url-params', 'parameter-whitelist'];

so they can be configured via the "Additional Parameters" field.

Hello :)

I wanted to warn you about the change you did in scripts.tpl in commit 6786323
(In the meantime you even added some more usages on top)
The oConfig variable used here is available in any eShop in default configuration, but it depends on the performance setting to load languages to be active.
If this is not active, the variable does not exist and several shop pages cease to function.

I can mitigate that in our project and I would also question this dependency towards our development department, but nonetheless I wanted to warn you about it.

As a store admin, I want to be able to define which custom attributes should be added to the product feed. Attributes can be stored in dedicated fields, or in a Multi-Attributes field (i.e. for filterable values).

hi guys,

this is not the way to extend an oxid class ;-) https://github.com/FACT-Finder-Web-Components/oxid-eshop-module/blob/master/src/Export/Data/ExportArticle.php

please see oxid docu for more information: https://docs.oxid-esales.com/developer/en/6.0/modules/good_practices/extend_shop_class.html

this extension doesn´t work if a function from an other oxid module is used, eg.:

Function 'sxGetAttributeValue' does not exist or is not accessible! (Omikron\FactFinder\Oxid\Export\Data\ExportArticle)

regards

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

Module was implemented in OXID EE 6.4.1 with PHP 7.1
Customizations are made in an own Module. Bugs appear also in default/vanilla configuration without the own written module.

Session Issues
Search as a registered customer: The Session terminates and the customer is logged out.
Click path: Log in as Customer -> back to startpage -> search in header search field
Session Handling is working as long as the customer stays on the searchResultPage. After changing to another page e.g product detail page, the next search will cause a log out because of the lost Session.

URL-Parameter issues:
The Url parameter of the controller is not always passed.
Click path: Do multiple searches on the result page. After a couple of searches the URL-Parameter of the controller ist missing.
Instead of https://myshop.com/index.php?cl=search_result&query=test
it's
https://myshop.com/index.phpt&query=test
which does not allow to reload the page without getting redirected to the start page.

Thanks in advance and kind regards