[Nicolas]

C’est pas très bon en effet.

• Mise à jour récente à WordPress 5.8 (hier soir)
• Version actuelle de BuddyBoss Platform : 1.6.2
  • Mise à jour planifiée dans 6 heures à la version 1.7.3 (!)

Il y a plusieurs problèmes critiques reportés depuis quelques heures sur le GitHub de BuddyBoss Platform.

Je vais lancer la mise à jour manuelle de BBP pour voir si les choses s’améliorent.

[Nicolas]

Et voilà ! C’est réglé !

[Nicolas]

Comme il se trouve que les règles CSS affectent également la vue « Ajouter une entrée », on peut dorénavant se débarrasser du snippet (dans functions.php) qui règle les colonnes à 4 au lieu de 3 dans cette vue.

Aussi, j’ai rajusté les points de rupture pour les aligner sur ceux du thèmes :

• Affichage 2 colonnes (max-width=47.99em) : correspond exactement au moment où le texte du menu « Mon compte » et « Ajouter une entrée » est escamoté, ne laissant que les icônes.
• Affichage 4 colonnes (min-width=75em) : correspond exactement au passage du menu « hamburger » au menu déployé.

[Nicolas]

La seule référence pertinente concernant le nombre de colonnes dans l’affichage des sous-catégories d’une catégorie trouvée sur les forums de HivePress est celle-ci : https://hivepress.io/support/topic/changing-listing-categories-column-amounts/

Le code CSS qu’y donne @ihor (développeur de HivePress) consiste à forcer l’affichage sur 1 colonne :

.hp-listing-categories .hp-grid__item {
    flex-basis: 100%;
    max-width: 100%;
}

Partons de cet exemple pour forcer l’affichage sur 4 colonnes, mais seulement à partir d’une certaine largeur de la zone d’affichage.

Vue « Sous-catégories » : règles CSS progressives

Les règles CSS contrôlant d’affichage en colonnes sont définies dans /wp-content/plugins/hivepress/assets/css/grid.min.css. Par défaut, l’affichage en colonnes est réduit à une seule colonne lorsque la largeur de l’écran est de 48em et moins. Cela est contrôlé par une règle @media. grid.min.css définit 3 points de rupture : 48em, 64em et 75em.

Nous allons donc définir une règle pour afficher les sous-catégories sur 4 colonnes (au lieu de 3) à partir de 64em, et on en profitera pour créer un affichage intermédiaire sur deux colonnes, entre 32em et 48em :

/* Catégories 4 colonnes */
@media only screen and (min-width:64em) {
  .hp-listing-categories .hp-grid__item {
    flex-basis: 25%;
    max-width: 25%;
  }
}
/* Catégories 2 colonnes */
@media only screen and (min-width:32em) and (max-width:48em) {
  .hp-listing-categories .hp-grid__item {
    flex-basis: 50%;
    max-width: 50%;
  }
}

C’est aussi simple que ça !

[Nicolas]

Je confirme que le panneau « Extrait » apparaît lors de l’édition d’une page sur Québec blogues (clone de l’actuel Québec connexion qui utilise le thème d’origine, Chaplin). Cela tend à confirmer que le problème est spécifique au thème BuddyX.

[Nicolas]

Je dis ça, et je réalise qu’en réalité ce problème pose une difficulté supplémentaire : qu’arrive-t-il à 1 h du matin vendredi lorsque l’établissement ferme à 2 h du matin le jeudi ? La condition ne dépend pas alors de l’heure de fermeture du jour actuel, mais de celle de la veille.

La logique de la requête (qui doit certainement se traduire en une requête SQL) reste à éclaircir […]

Si on a :

veille.ouverture = heure d'ouverture du jour de la veille (hier)
veille.fermeture = heure de fermeture du jour de la veille (hier)
auj.ouverture = heure d'ouverture du jour actuel
auj.fermeture = heure de fermeture du jour actuel
heure = heure actuelle
ouvert = état actuel d'ouverture à déterminer

Alors on peut définir la condition d’ouverture actuelle du commerce ainsi :

SI (
  ( veille.fermeture < veille.ouverture ) // fermeture la veille après minuit
  ET ( heure < veille.fermeture ) // commerce encore ouvert
) OU (
  ( heure >= auj.ouverture ) // commerce déjà ouvert
  ET (
    ( auj.fermeture < auj.ouverture ) // fermeture aujourd'hui après minuit
    OU ( heure < auj.fermeture ) // commerce encore ouvert
  )
)
ALORS ouvert = VRAI // le commerce est actuellement ouvert

Cas limite : certains cas limite (quoique extrêmement improbables) pourraient ne pas être représentés, eg. un commerce qui ouvrirait à 2h du matin (le mardi) et fermerait ensuite à 4h du matin (soit le lendemain matin) pour ré-ouvrir plus tard (le mercredi) est dans l’impossibilité de représenter cela dans la structure de données actuelle de HivePress Opening Hours.

[Nicolas]

La version gratuite de LuckyWP Glossary impose une limite de 30 termes ! Dammit !

[Nicolas]

Le cas limite heure de fermeture = 0:00 a été reporté il y a plus d’un mois ici :
https://hivepress.io/support/topic/open-now-nothing-found/#post-12989

@GoParkPlay (1 month, 2 weeks ago)

When I set the hours from 5am-12am and I select “open now” nothing shows up. However, when I set the hours from 5am – 1159pm, the listing appears. This appears to be a bug. Thoughts?

@ihor (1 month, 2 weeks ago) developer

Thanks for reporting – added this to the bug tracker, will be fixed in the next Opening Hours update. If it’s urgent please send temporary WP access to support@hivepress.io

[Nicolas]

Voir également : Extensions multisite essentielles (réseau Québec.tk / Québec blogues)

[Nicolas]

On a résolu le problème avec l’extension bbp Markdown qui remplace l’éditeur bbPress/bbPlatform par un éditeur Markdown !

Voir la discussion : https://web.québec.tk/forums/discussion/support-de-la-syntaxe-markdown-dans-les-forums-bbpress-buddyboss-platform/#post-298

Résultat : RÉSOLU.

[Nicolas]

La réponse de @ihor a été assez rapide (~12 heures) :

Thanks for reporting this issue, I added it to the bug tracker. If you have the Opening Hours extension. The current condition is:

if($current_time>$opening_time and $current_time<$closing_time)

So this may require some extra logic to detect the time after midnight.

Ça ressemble à une demande formelle de lui proposer un patch ! J’ai donc fouillé dans le code du plugin pour retrouver la logique de filtrage. Il s’agit, effectivement, d’une requête MySQL contrôlée par un objet WP_Query auquel la méthode Opening_Hours::set_search_query( $query ) ajoute une clause meta.

La classe Opening_Hours est définie dans hivepress-opening-hours/includes/components/class-opening-hours.php. À la ligne 143 :

        // Get day and time.
        $day  = strtolower( current_time( 'l' ) );
        $time = current_time( 'G' ) * 60 + (int) current_time( 'i' );

        // Get meta query.
        $meta_query = array_filter( (array) $query->get( 'meta_query' ) );

        // Add meta clause.
        $meta_query[] = [
            'relation' => 'AND',

            [
                'key'     => hp\prefix( $day . '_from' ),
                'value'   => $time,
                'compare' => '<',
                'type'    => 'NUMERIC',
            ],
            [
                'key'     => hp\prefix( $day . '_to' ),
                'value'   => $time,
                'compare' => '>',
                'type'    => 'NUMERIC',
            ],
        ];

        // Set meta query.
        $query->set( 'meta_query', $meta_query );

Il suffit de modifier $meta_query[] pour prendre en compte la logique proposée ci-haut. Mais la class WP_Query permet-elle des conditionnelles imbriquées ? Apparemment, cela est possible depuis WordPress 3.1 ! (Voir cet exemple).

Il nous faut d’abord obtenir le jour de la semaine correspondant à la veille en plus du jour actuel. On obtient celui-ci avec : $day = strtolower( current_time( 'l' ) );. La source de la fonction current_time (définie par WordPress) nous permettrait de paraphraser l’expression par : $day = strtolower( (new DateTime( 'now', wp_timezone() ))->format( 'l' ) );.

On se servira donc de l’objet DateTime pour obtenir également le jour de semaine de la veille :

        $timezone = wp_timezone();
        $date = new DateTime( 'now', $timezone );
        $today = strtolower( $date->format( 'l' ) );
        $date->sub( new DateInterval('P1D') );
        $yesterday = strtolower( $date->format( 'l' ) );

Ne reste qu’à ré-écrire notre méta-requête imbriquée…

Et c’est ici qu’on frappe un nœud :

Effectivement, WP_Meta_Query ne permet pas de comparer deux méta-variables entre elles ! Ainsi il est impossible de vérifier les conditions de type <jour>.fermeture < <jour>.ouverture dans une seule requête. Ce serait définitivement possible en SQL, mais cela impliquerait une refonte en profondeur de l’extension.

Voie de contournement

S’il nous est impossible de vérifier les conditions de type <jour>.fermeture < <jour>.ouverture avec une seule méta-requête au moment de la requête, il nous est cependant possible de la vérifier en avance, c’est à dire au moment où les heures sont enregistrées dans la base de données. Si on ajoutait une métadonnée, eg. hp\prefix( $day . '_night' ) qui contiendrait le résultat de la précondition (1 si <jour>.fermeture < <jour>.ouverture, 0 sinon; ou — encore mieux — ne serait définie que si la condition est vérifiée), alors on sera en mesure de construire la méta-requête ainsi :

        $meta_query[] = [
            'relation' => 'OR',
            [
                'relation' => 'AND',
                [
                    'key'     => hp\prefix( $yesterday . '_night' ),
                    'compare' => 'EXISTS',
                ],
                [
                    'key'     => hp\prefix( $yesterday . '_to' ),
                    'value'   => $time,
                    'compare' => '>',
                    'type'    => 'NUMERIC',
                ],
            ],
            [
                'relation' => 'AND',
                [
                    'key'     => hp\prefix( $today . '_from' ),
                    'value'   => $time,
                    'compare' => '<=',
                    'type'    => 'NUMERIC',
                ],
                [
                    'relation' => 'OR',
                    [
                        'key'     => hp\prefix( $today . '_night' ),
                        'compare' => 'EXISTS',
                    ],
                    [
                        'key'     => hp\prefix( $today . '_to' ),
                        'value'   => $time,
                        'compare' => '>',
                        'type'    => 'NUMERIC',
                    ]
                ]
            ]
        ];

Reste à trouver :

À quel moment au sein de l’extension peut-on définir cette métadonnée <hp_prefix>-<jour>-night en fonction de la pré-condition <jour>.fermeture < <jour>.ouverture ?

Références :

• Méta-requêtes imbriquées depuis WP 3.1 : https://wordpress.stackexchange.com/a/181700/152860
• Exemple de méta-requête imbriquée : https://developer.wordpress.org/reference/classes/wp_meta_query/#comment-1989
• Fonction current_time : https://developer.wordpress.org/reference/functions/current_time/
• Obtenir la date d’hier en PHP (1) : https://stackoverflow.com/questions/16009152/how-to-get-date-of-yesterday-using-php
• Obtenir la date d’hier en PHP (2) : https://stackoverflow.com/questions/6796866/php-date-yesterday
• Sur l’impossibilité de comparer deux champs méta avec WP_Query : https://stackoverflow.com/questions/36979162/wp-query-filter-posts-by-comparing-two-meta-keys
• Vilain hack pour néanmoins y parvenir : https://wordpress.stackexchange.com/questions/164032/how-to-compare-two-meta-fields

[Nicolas]

J’ai proposé l’algorithme ci-haut exposé sur le forum HivePress.io : https://hivepress.io/support/topic/open-now-nothing-found/#post-16004

Si une mise à jour n’est pas proposée par l’auteur relativement rapidement, je plongerai dans le code de l’extension pour en déterminer la logique et suggérer un patch.

[Nicolas]

Reste à voir si on arrivera à traduire l’extension avec Loco Translate.

L’extension étant correctement internationalisée, la création de la traduction en franco-canadien (fr-CA) avec Loco Translate fut un jeu d’enfant !

[Nicolas]

Oups ! Me serais-je réjoui trop vite ?

Les onglets de bbP Markdown ne fonctionnent pas comme prévu des les discussions des groupes de BuddyBoss Platform (les forums qui sont associés à des groupes et s’affichent au sein de l’interface de groupe).

Voir capture d’écran attachée…

Pas critique pour l’instant (bbP Markdown n’étant activé que sur Québec Web, pas sur Québec Connexion), mais va falloir trouver un fix. Je crois qu’une fourchette pour ce vieux fromage sera éventuellement inévitable…

[Nicolas]

‘Gor donc ça ! L’auteur de la bibliothèque PHP Markdown utilisée par l’extension bbP Markdown est Michel Fortin, un gars de Lévis, au Québec ! C’est juste l’autre bord du fleuve Saint-Laurent, ça !

Comme dirait l’autre :

Le monde est p’tit !

[Auteur]

Réponses