Closed CristobalDolz closed 1 year ago
This issue is blocked by the development of that other issue. In order to set the search criterias correctly, we needed to store the website id in the datasources before. But now, we need the store_id in order to set the new search criterias and it wouldn't make sense to store it in the datasources anymore, taking into account the proximity of this development. What do you think about it?
@CristobalDolz this should be reanalyzed
Lo escribo en cristiano. Se ha hecho la consulta a experto de esta tarea con @carlosescri y se han sacado las siguientes conclusiones con respecto a las acciones a realizar para el correcto desarrollo de esta tarea:
Queda por documentar de forma más explicita las acciones a realizar en caso de que un cliente con una versión posterior tuviese los problemas relativos a los que pretende resolver esta issue, cuya solución pasaría por almacenar en cada una de las opciones del datasource correspondiente el id de la store_view a la que está representando en Magento.
Con la salida de la nueva versión de Magento 2.4.6, han habido determinados cambios e incompatibilidades que han afectado a nuestro plugin. Además de deprecar alguna clase que se estaba empleando, ahora no se soportan versiones de php inferiores a la 8.0.
Currently we use the magento website as a doofinder store and the magento storeview as an SE, which can potentially lead to collisions between SEs that have the same installation.
To avoid this it is recommended to use magento stores conceptually as doofinder stores, so that different magento storeviews can have the same language and currency without colliding (by belonging to different doofinder layer installations).
Both the possible programmatic approaches for this and the consequences for customers working with the current structure should be studied.