[Nicolas]

bbp-markdown (obsolète) n’est pas compatible avec PHP 7.4+

Ce message d’erreur nous oblige à exécuter méta.fiatlux.tk en PHP 7.3 !

2021-12-08 00:56:31.696679 [NOTICE] [39465] [104.37.80.211:64062-Q:C83CB50A12C4A0B8-36#meta.fiatlux.tk] [STDERR] PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported in /<caviardé>/wp-content/plugins/bbp-markdown/lib/Markdown.php on line 948

(réalisé ça hier suite à la migration du réseau fiatlux.tk vers un nouveau serveur)

À faire (éventuellement) : Une belle fourchette de bbp-markdown !

(faudrait bien que je me lance dans le DevOps !)

---

Attends minute… comment ça se fait que bbp-markdown marche sur Web Québec (aka : ici) ?! Est-ce que le site roule en PHP 7.3 ??? Pourtant non… Il utilise PHP 7.4.26… Ha, tiens tiens, c’était une  [NOTICE], pas une [FATAL ERROR]… C’est donc autre chose qui provoquait une erreur critique sur meta.fiatlux.tk…

[Nicolas]

Problème de confidentialité avec l’extension bbPress Voting

Chaque activité de bbPress Voting crée une entrée dans le flux d’activités public de BuddyPress, révélant le titre de la conversation même si celle-ci est dans un forum privé. Ceci a pour effet de révéler publiquement des informations qui devraient demeurer privées.

Problème reporté à l’instant ici : https://wordpress.org/support/topic/privacy-issue-with-private-forums-in-buddypress/

[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]

La suite viendra demain ! Oui, la date reste à déterminer, mais je compte bien caller une nouvelle réunion assez vite.

[Nicolas]

Réponse à Stefan : création et circulation des locos (en 2 parties)

Partie 1 : la circulation des locos

Laisse-moi d’abord rappeler la fonction du loco, à titre d’instrument d’échange. Examinons d’abord, du point de vue théorique, le problème de la circulation, avant d’aborder le problème de la création — bien que cela puisse sembler contre-intuitif.

a) Troc

Dans l’échange simple (le troc), deux personnes échangent entre elles quelque chose que chacun détient et qui a une certaine valeur d’usage (que ce soit un produit, disons un pantalon, ou un service, disons une coupe de cheveux). En concluant l’échange, chacune d’elles accomplit à la fois un acte de vente, en léguant à l’autre partie la propriété du produit qu’elle détient (le pantalon) ou en accomplissant pour le compte de l’autre partie le service qu’elle offre (la coupe de cheveux). Réciproquement, chaque personne accomplit au même moment un acte d’achat : la personne qui donne le pantalon obtient en échange une coupe de cheveux, et celle qui donne la coupe de cheveux obtient en échange le pantalon tant désiré. Dans l’échange simple (troc), l’acte d’achat et l’acte de vente sont toujours simultanés — et réciproques entre deux échangistes.

b) Monnaie

L’instrument d’échange (la monnaie) complique un peu l’affaire, mais il ouvre des possibilités : il me permet de vendre ce que j’ai à offrir d’utile (une valeur d’usage) à une autre personne en échange d’une certaine quantité de monnaie, pour pouvoir acheter, plus tard et ailleurs, à une tierce personne, ce dont j’ai besoin (une autre valeur d’usage) en échange d’une certaine quantité de cette monnaie. Il y a effectivement au moment de chaque échange en monnaie, achat et vente simultanés, mais ceux-ci ne sont plus réciproques : le vendeur n’achète pas, et l’acheteur ne vend pas. Du moins, pas immédiatement. Donc, du point de vue de l’échangiste, l’échange monétaire sépare l’acte de vente de l’acte d’achat — dans le temps comme dans l’espace. Son échange ne sera réellement résolu que lorsqu’il aura obtenu, dans le cadre d’un autre ou de plusieurs autres achats, une ou des valeurs d’usage dont la valeur est à peu près équivalente à celle de la valeur d’usage qu’il a légué à autrui au moment de la vente.

c) Circulation

En servant d’intermédiaire, la monnaie (représentation de la valeur d’échange) permet de mettre en mouvement les valeurs d’usage échangées au-delà de deux échangistes. Chaque échange en implique nécessairement un autre, pour que l’échange soit résolu de mon point de vue. Cette médiation permet aux valeurs d’usage (produits et services réels) de circuler, sur des distances plus ou moins longues, dans toutes sortes de directions imprévisibles, en échange de quantités variables de valeur d’échange (représentée par la monnaie), qui quand à elle se déplace sur les mêmes trajets, mais toujours en direction opposée.

C’est cette propriété de la monnaie que le loco reprend pour lui-même, permettant la circulation des échanges au-delà de deux personnes.

Quel éclairage cela apporte-t-il par rapport à ta question ?

1. Pour qu’un membre puisse obtenir une valeur d’usage (produit ou un service) en échange de locos, il doit déjà détenir des locos (valeur d’échange représentée), ce qui implique qu’il ait déjà lui-même échangé une certaine valeur d’usage (produit ou service) contre des locos. Cela règle ton problème : ton service rendu est déjà, pour la personne à qui tu le rends, une résolution d’un échange qu’elle a déjà entamé. Elle te règlera en locos sonnants, obtenant en échange de ceux-ci une valeur d’usage tangible en contrepartie d’un effort qu’elle a déjà effectué pour autrui dans le passé.

2. Par conséquent, si tu offres tes services à 5 membres en échange de locos, ceux-ci auront nécessairement quelque chose à offrir, puisque cela implique qu’ils détiennent les locos avec lesquels tu envisages d’être rétribué pour tes services. Plus il y a de gens qui participent, plus les chances augmentent qu’une personne puisse t’offrir des services qui te seront utiles en échange des locos que tu auras obtenus.

3. En règle générale, tu devrais d’abord t’assurer de pouvoir éventuellement obtenir des autres membres ce dont tu as besoin en échange de locos avant de t’engager à offrir tes services en loco.

Mais pour que tout cela soit possible, il doit déjà y avoir des locos en circulation !
Dans la 2e partie, j’aborderai l’épineux conundrum de la création des locos ! 🤠

[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 !

[Auteur]

Réponses