5106 sujets

Le Bar du forum

Après une très longue absence je reviens aux sources et redécouvre les joies du codage sous WordPress (sic!), ceci afin de créer à nouveau un thème à partir de zéro (mon dernier thème fonctionne toujours très bien mais commence à dater). Après près de 5 ans d'absence durant lesquelles j'ai découverts avec passion Node.js, j'avais oublié que coder sous WordPress était aussi rebutant...

En effet, WordPress continue d'ajouter de nouvelles fioritures qu'il active par défaut sur une MAJ. De fait je passe des soirées à dénicher ces fonctions, pour chercher ensuite des incantations php glanées ça et là sur internet dans le but de les désactiver (passionnant). Parce que oui, tous ces trucs peuvent être très bien en eux-même, mais le problème est qu'ils sont activés par défaut Smiley fache :

1. Les images attachées à un article ont leur page dédiée Smiley kneu . Comment on désactive déjà ? Ah oui : il faut rajouter un fichier image.php Smiley eek , avec devant quelque chose comme ceci :
// @note Depuis WordPress 3.5 une page est créé par défaut pour chaque média uploadé. Cette option est très discutable...
// @description Supprimer la page du fichier joint
// @link  https://gist.github.com/reficedev/c5d0451124c74f0afc67c127ccaa582f#file-wordpress-supprimer-page-du-fichier-attache
 
global $post;
if ($post AND $post->post_parent) {
	wp_redirect(get_permalink($post->post_parent), 301); // Redirection sur la page de l'article à l'origine de l'upload
} else {
	wp_redirect(home_url('/'), 301); // Sur la page d'accueil le cas échéant
}
exit;

2. Les emojis. Le code source est immonde, tout cela pour mettre une emoji dans un article (enfin peut-être). Une option à passer à false ? Ah bah non ! on a bien plus intuitif Smiley biggol :
function draftDisableEmojis() {
    remove_action('wp_head', 'print_emoji_detection_script', 7);
    remove_action('admin_print_scripts', 'print_emoji_detection_script');
    remove_action('wp_print_styles', 'print_emoji_styles');
    remove_action('admin_print_styles', 'print_emoji_styles');
    remove_filter('the_content_feed', 'wp_staticize_emoji');
    remove_filter('comment_text_rss', 'wp_staticize_emoji');
    remove_filter('wp_mail', 'wp_staticize_emoji_for_email');
    add_filter('tiny_mce_plugins', 'disable_emojis_tinymce');
    //add_filter('wp_resource_hints', 'disable_emojis_remove_dns_prefetch', 10, 2); // chez moi ça bug...
}
add_action('init', 'draftDisableEmojis');

3. Gutenberg, symbole de l'orientation qu'est en train de prendre le CMS. Enfin un truc pas trop dur à désactiver :
  // Désactiver Gutenberg pour le back end
  add_filter('use_block_editor_for_post', '__return_false');

4. Enfin et surtout : l'API REST avec laquelle j'ai le plaisir de voir mes données exposées à mon insu (exemple avec ce site). Si vous êtes encore en versions 4.7.0 ou 4.7.1 n’importe qui peut modifier vos données sans avoir à s’authentifier (il y a eu un patch à partir de 4.7.2). Bravo WordPress. Sur ce point j'ai trouvé des incantations glannées sur internet, mais elles n'ont pas "marché" pour moi. On verra pour une redirection apache au pire, mais c'est dingue où on en arrive pour configurer ce truc. (Edit : une solution ici).

Je n'aime pas du tout le chemin que prends WordPress mais il reste incontournable. Il va falloir que je m'y fasse...
Modifié par Olivier C (22 Aug 2022 - 14:52)
Modérateur
Hello Olivier Smiley smile

Olivier C a écrit :


Je n'aime pas du tout le chemin que prends WordPress mais il reste incontournable. Il va falloir que je m'y fasse...

incontournable ? mouais bof !

Tu as oublié de citer ces problèmes incontournables :
1. le modèle de la database (du n'importe quoi)
2. le système de route
3. les performances (100 requêtes pour afficher un index Smiley biggol )
4. les failles de sécurité

ça fait bien longtemps que je ne regarde plus ce machin. Beaucoup jure par ce cms. Or ce n'est qu'un système de blog au même titre que Dotclear. Tu veux un CMS ? Joomla ou Drupal.

En apprenant CakePHP ou CodeIgniter, tu iras beaucoup plus vite au final et tu auras quelques chose de beaucoup plus véloce et évolutif.
Modifié par niuxe (15 Aug 2022 - 21:02)
Modérateur
Salut !

1/ Merci pour le trick je ne l'avais pas ! Smiley lol

On peut tenter de trouver des excuses:
wpbeginner a écrit :
For example, a photography theme could use the attachment page to display EXIF data. This could show the camera model used, the camera settings, and even the image’s location data.

https://www.wpbeginner.com/wp-tutorials/how-to-disable-image-attachment-pages-in-wordpress/

... mais bon rien de bien convaincant ca aurait effectivement été mieux dans l'autres sens (rajouter un petit bout de code pour l'activer, voir meme un bouton dans l'admin hehehe)

2/ là j'ai même pas d'excuses hahaha

3/ pour le coup je trouve Gutenberg plutôt fluide et bien fait. Surtout à coté de gros tanks comme Elementor et autre que j'ai jamais trouvé très fonctionnels. (et on garde l'éditeur de code sous le coude)

4/ Pour ce qui est sécurité (point 4 de niuxe également) je ne peux pas juger je suis un noob de ce domaine... J'imagine que pour un site/blog les infos ne sont pas particulièrement plus sensible que ça... le plus gros risque étant le squattage mais bon... Peut être y réfléchir a deux fois dans le cadre d'un gros blog avec plein d'utilisateurs inscrit etc.

Pour les points 1 et 2 de Niuxe la encore je ne suis pas un expert, je fais avec.

Pour le point 3 de Niuxe par contre je suis tout à fait d'accord pour la plupart des thèmes ce sont des usines à gaz qui font le café et la vaisselle.

Par contre je m'amuse a recréer des thèmes custom et franchement je peux repartir de 0 et on dirait un site html léger fait à la main sans un milliard de requêtes ou un DOM à vomir. Alors oui, en faisant ça je m'interdis une des puissances du CMS qui réside dans ses plugin mais je m'en accommode plutôt bien. Et quand il faut (contrainte de temps, de budget...), bah j'abandonne et je fais du WP un peu plus classique avec jquery et des plugin. Smiley ohwell

Si ca ne tenait qu'a moi je ne ferais que des sites maison aux petits oignons mais objectivement ce n'est pas faisable pour moi. Les principaux intérêts que je vois à utiliser WP :
- Clé en main. En 2 cliques c'est installé et ça roule
- Toute l'admin est bien chiadée, y'a plein d'option (malgré les quelques ratés comme vu au début ca colle a 99% des usages) c'est hyper simple et le design est vraiment cool
- Les plugin (et les themes existants) ca peut sauver des budgets haha Smiley lol

Alors je trouverais certainement l'équivalent chez Dupral et/ou Joomla et/ou autres mais j'avoue que je m'y suis jamais collé. Et je sais pas y'a un coté branding qui me fait préférer WP inconsciemment. Après avoir passé pas mal de temps sur CMSMS à mes débuts à cracher sur WP, je lui ai donné un chance et il m'a surpris agréablement. Depuis je n'ai pas redonner de chance a un autre CMS, je devrait peut etre... Pour CakePHP etc j'aimerais beaucoup, ca serait un super solution, mais clairement pas le temps.. je pensais regarder le dev de plugin WP custom avant ça...

Mais globalement je suis d'accord, le dev sur WP ca ressemble plus à du débug qu'a du dev Smiley lol

Bonne journée
J'ai utilisé un peu WP 1 lorsque je débutais en créaton de sites. C'était le moteur de blog qu'il n'a jamais cessé d'être. Puis au hasard d'un article, j'ai découvert Typolight devenu depuis Contao (contao.org).

Une vraie gestion de l'arborescence, une gestion simple des images et fichiers (avec une vraie arborescence pour les ranger), Beaucoup moins lourd que Drupal ou Joomla, trés utilisé en Allemagne (où il est développé) et à l'est. Avec une communauté très réactive. Utilise Symphony pour l'installation et la gestion des plugin. Je trouve qu'il propose un plutôt bon équilibre entre point and click et developer hard core.

(Si certains veulent le tester, je veux bien avoir vos retours.)