En fait, c'est bien la liste de produits que je veux afficher selon le critère de tri : date_fileupd (comme cela existe avec date_add, date_upd).
J'ai donc overridé :

• AdminPPreferencesController en modifiant la ligne "sales" qui ne semble pas servir :

 array('id' => '8', 'name' => $this->l('Product file update'))

• product_sort.tpl :

<option value="date_fileupd:asc"{if $orderby eq 'date_fileupd' AND $orderway eq 'asc'} selected="selected"{/if}>{l s='File Update Date: Oldest first'}</option>
			<option value="date_fileupd:desc"{if $orderby eq 'date_fileupd' AND $orderway eq 'desc'} selected="selected"{/if}>{l s='File Update Date: Newest first'}</option>

• Category.php avec ajout d'un orderby avant la requête sql

if($order_by == 'date_fileupd') {
            $order_by_prefix = 'pd';
            $order_by = 'date_fileupd';
        } 

et dans le sql ajouté :

LEFT JOIN `'._DB_PREFIX_.'product_download` pd
                ON(pd.`id_product` = p.`id_product`)

• Tools.php, dans $list ajout du champ

8 => 'date_fileupd'

et dans if prefix

	elseif($value == 'date_fileupd') {
                        $order_by_prefix = 'pd.';
                      }

Et je crois que c'est tout.
Dans Préférences > Produits > Pagination : le nouveau choix est bien affiché.
En front, ce nouveau choix apparaît dans la sélection de tri.
Mais ... que ce soit en le mettant comme tri par défaut dans l'admin, ou en le sélectionnant sur la page produit, et même si me tri apparaît bien dans l'url, c'est l'ordre par défaut (par nom) qui est appliqué.
Et pourtant, au début, dans AminPPreferencesController, j'avais mis comme id 8 et là, en front, il affichait "sales" dans la liste de tri.
Je vide le cache (suppression de index.php dans cache/classes à chaque modif).
Si vous avez un semblant de tuyau à me donner, je reprends courage :-)

Merci d'avance !

{EDIT] c'est dfans Tools.php que j'ai remplacé "sales" par "date_fileupd" pour l'id 8. Dans AdminPPreferencesController, il n'y était pas, je l'ai rajouté)

Merci Eolia. Mais le module productcomments n'a pas de fonction de tri sur tel ou tel paramètre ou j'ai pas compris quelque chose ?

Bonsoir,
En fait, j'ai pas mal avancé sur ce module qui ajoute un champ date_fileupd à la table product_download vu que j'avais déjà commencé précédemment (avant de me rendre compte que date_upd changeait à chaque fermeture de page).
J'ai configuré le bazar pour qu'on remplisse à la main le champ, exactement comme le champ date_expiration. Un hook permettra ensuite d'ajouter un onglet "Dernières mises à jour" sur la home, et cette date sera affichée sur la fiche du produit, et, si tout se passe bien comme prévu, s'adapter à la déclinaison choisie.
Mais il y a une dernière chose que je souhaite ajouter avant de tester le module, c'est la possibilité d'ajouter un tri par défaut sur ce champ dans les Préférences > Produit > Pagination.
J'ai trouvé le fichier qui affiche le choix dans l'admin, c'est AdminPPreferencesController.php. Mais quel est le fichier qui gère les requêtes pour ces tris ?? Serait-ce bien la fonction public function getProducts($id_lang, $p, $n, $order_by = null, $order_way = null, $get_total = false, ... à la ligne 844 de Category.php ?
Je voudrais juste savoir si c'est bien cela.

Merci d'avance

Finalement, je pense avoir trouvé. Il fallait juste garder

$longdescription = Tools::getValue('longdescription');
$longdescription = pSQL($longdescription, true);

Maintenant tout est fonctionnel (en tout cas, à première vue). Je peux créer une nouvelle catégorie avec une description longue en bas de page, la mettre à jour. Si je supprime le texte, la ligne est effacée de la base de données (pour éviter de l'alourdir). Idem si la catégorie est supprimée.
Si jamais ça intéresse quelqu'un, je le mets à dispo de qui veut :-) Compatible 1.6 et Phenix uniquement.

Eolia, tout à fait par hasard, est-ce que la v33 prévoit un second champ de texte avec éditeur pour les pages de catégories afin de pouvoir améliorer son SEO ?
Juste pour savoir si j'essaie de régler le problème du HTML. Je me suis basée sur des tutos trouvés à gauche et à droite, j'ai bien mon nouveau champ avec l'éditeur. Mais je ne peux pas mettre de code comme des class="" car les doubles guillemets provoquent une erreur sql. Alors que je peux le faire dans le champ Description. J'ai essayé différentes choses. Avec pSQL, plus de balises, le texte est au simple format texte. J'ai bien trouvé une parade, le html est correctement affiché en BO et en FO, mais dans la base de données cela donne ceci

<div class="test">
<h2>Titre</h2>
<p>Test html</p>
<p>Seconde ligne</p>
<p>Troisième ligne</p>
</div>

Cela serait sans doute plus simple de faire des overrides mais j'ai essayé avec des hooks. Tout fonctionne bien sauf ça. Du coup, j'ai dû mettre html_entity_decode dans le tpl pour qu'il n'affiche pas en clair le html.
Voici par exemple le code de la fonction qui met à jour le champ longdescription

public function updateLongDescription($params)
{
    // Récupérer l'ID de la catégorie
    $id_category = (int)Tools::getValue('id_category');

    // Vérifier si l'ID est valide
    if ($id_category <= 0) {
        return; // Si l'ID est invalide, on quitte la fonction
    }

    // Récupérer l'objet catégorie
    $category = new Category($id_category);

    // Vérifier si l'objet catégorie est valide
    if (!Validate::isLoadedObject($category)) {
        return; // Si l'objet catégorie n'est pas valide, ne pas procéder
    }

    // Récupérer la langue actuelle
    $id_lang = (int)$this->context->language->id;

    // Récupérer la valeur du champ longdescription depuis la requête
    $longdescription = Tools::getValue('longdescription');

    // Si le champ est vide, supprimer la ligne dans la table
    if (empty($longdescription)) {
        // Supprimer l'enregistrement correspondant dans la table category_long_description_lang
        $sql = 'DELETE FROM `' . _DB_PREFIX_ . 'category_long_description_lang`
                WHERE `id_category` = ' . $id_category . ' 
                AND `id_lang` = ' . $id_lang;
        Db::getInstance()->execute($sql);
        return; // Sortir de la fonction après suppression
    }
  
    // Sécuriser la valeur avec htmlentities pour éviter les problèmes de collation et d'injection SQL
    // $longdescription = strip_tags($longdescription, '<h1><h2><h3><h4><div><p><b><i><u><a><br><ul><ol><li>'); 
       $longdescription = Tools::getValue('longdescription');
// $allowed_html_tags = '<h1><h2><h3><h4><div><p><b><i><u><a><br><ul><ol><li><img>';
// $longdescription = strip_tags($longdescription, $allowed_html_tags);
$longdescription = htmlentities($longdescription);
$longdescription = pSQL($longdescription, true);
    // Vérifier si un enregistrement existe déjà pour cette catégorie et cette langue
    $sql = 'SELECT `id_category` 
            FROM `' . _DB_PREFIX_ . 'category_long_description_lang`
            WHERE `id_category` = ' . $id_category . ' 
            AND `id_lang` = ' . $id_lang;
    $existing = Db::getInstance()->getValue($sql);

    if ($existing) {
        // Si un enregistrement existe déjà, mettre à jour le contenu
        $sql = 'UPDATE `' . _DB_PREFIX_ . 'category_long_description_lang`
                SET `longdescription` = "' . $longdescription . '"
                WHERE `id_category` = ' . $id_category . ' 
                AND `id_lang` = ' . $id_lang;
    } else {
        // Sinon, insérer un nouvel enregistrement
        $sql = 'INSERT INTO `' . _DB_PREFIX_ . 'category_long_description_lang` 
                (`id_category`, `id_lang`, `longdescription`) 
                VALUES (' . $id_category . ', ' . $id_lang . ', "' . $longdescription . '")';
    }

    // Exécuter la requête
    Db::getInstance()->execute($sql);
}

J'ai laissé certaines choses en les commentant pour les tests.
Si quelqu'un a 2 minutes pour y jeter un oeil et me dire comment envoyer cela correctement à la bdd et ne pas avoir à utiliser html_entity_decode, ce serait vraiment hyper sympa !

Merci d'avance

Bien sûr ! Franchement, j'admire ! Tout ça + répondre au forum ! Et les journées ne font que 24h ...
En attendant, j'essaie de créer un champ date à remplir manuellement quand on upload un nouveau fichier afin d'afficher cette date dans la fiche produit. Vu que je ne suis pas rapide pour ce genre de choses, la maj sera peut-être dispo avant, pas grave, j'apprends :-)

Ah :-) j'attends cette v33 avec impatience ! Vous auriez une idée de quand elle sera dispo ? Sans vouloir vous presser bien sûr, c'est énorme ce que vous faites !

ok merci. Je retiens pour d'autres modifs, pour celle-ci, le module est quasiment fonctionnel à 100%, j'ai encore un petit bug sur le HTML à l'enregistrement mais il crée sa table et n'utilise aucun override, juste les hooks.

De fait, j'aurais dû commencer par ce test ! Effectivement, sur la version vierge, cela ne le fait pas. J'ai donc cherché, j'ai désactivé les overrides, les modules non Prestashop, le module que j'ai créé pour récupérer la date_upd afin de l'afficher. J'ai activé le debug et toutes ses options pour voir ce qui était appelé. Pas de changement. La différence avec l'installation vierge est que les produits sont des produits dématérialisés. J'en ai donc créé un sur le Phenix vierge. Bingo, là, chaque fois que j'ouvre la fiche du produit et la referme, date_upd change même si je quitte la page en cliquant sur un des menus de la colonne de gauche.
J'ai alors testé l'inverse sur mon site de dev, en créant un produit standard. Mais là, la date_upd est aussi modifiée chaque fois que je quitte la page. Il n'y a aucun onglet supplémentaire.

Bonjour,
Prestashop 1.6 ne prévoyait pas de champ texte supplémentaire pour créer du contenu SEO en bas de page de catégorie. Sur le Net, j'ai trouvé des tutos pour y remédier, mais en modifiant la table category_lang par ajout d'un champ + overrides. Cela fonctionne mais quid lors de la prochaine mise à jour de Phenix Suite ? Alors, j'essaie de créer un module qui ajoute une nouvelle table. Tout fonctionne, sauf lorsque j'essaie de sauvegarder mon texte : il cherche le champ dans category_lang et bien sûr ne le trouve pas. J'ai cherché sans succès comment lui indiquer la bonne table. Alors que fais-je ? Je reviens au champ ajouté dans la table via le module ? Il n'y a pas de risque qu'il soit supprimé lors de la (très attendue) prochaine mise à jour ?

Merci d'avance