Hola @natalia_lab,
Los compañeros @mariobici y @inma_9689 han tocado el punto clave. Para que un campo personalizado como zalando_ref se guarde correctamente al editar un producto en el back office de PrestaShop 1.7.2.2, necesitas dos cosas:
- Declarar el campo en la definición del objeto
Product: Esto se hace en un override de Product.php para que PrestaShop sepa que ese campo existe y debe mapearse a la base de datos.
- Manejar el guardado en
AdminProductsController: Tu postProcess debe capturar el valor del formulario y asignarlo al objeto Product en el momento adecuado.
Tu código actual llama a parent::postProcess() pero luego intenta un update() que podría ser redundante o incorrecto si el campo ya fue manejado (o no) por el padre. Una forma más robusta en tu AdminProductsController sería la siguiente, siempre y cuando hayas añadido zalando_ref a la definición de Product:
class AdminProductsController extends AdminProductsControllerCore
{
public function postProcess()
{
// Asegúrate de que el campo exista en $_POST
if (Tools::isSubmit('submitAddproductAndStay') || Tools::isSubmit('submitAddproduct')) {
$id_product = (int)Tools::getValue('id_product');
if ($id_product) {
$product = new Product($id_product);
if (Validate::isLoadedObject($product)) {
Este snippet asume que ya tienes el campo zalando_ref añadido en la definición de Product.php (en /override/classes/Product.php). Si no, debes añadir algo como esto en la definición $definition['fields']:
'zalando_ref' => ['type' => self::TYPE_STRING, 'validate' => 'isGenericName', 'size' => 255],
Ten en cuenta que hacer overrides de esta manera, aunque funciona, puede ser propenso a errores y difícil de mantener con futuras actualizaciones de PrestaShop. Para una integración compleja como la de Zalando FCI, donde probablemente necesites importar muchos datos, sincronización y mapeo avanzado, es más seguro y eficiente usar esta extensión oficial. Un módulo dedicado gestiona estas complejidades de forma robusta y sin romper la compatibilidad con el core.