Connexion
Si vous tournez sous WordPress avec Jetpack, vous avez sûrement vu débarquer l'AI Assistant d'Automattic sans rien demander à personne. Un bouton IA qui se pointe dans l'éditeur, des suggestions générées un peu partout, un machin pour générer des vidéos à partir d'articles et le tout activé d'office, même sur les comptes gratuits.
Le pire, c'est que ça reste à moitié verrouillé derrière un abonnement payant qu'on vous colle sous le nez, avec seulement 20 malheureuses requêtes gratuites avant de devoir sortir la carte bleue. Donc autant dire qu'on peut rien tester que c'est déjà plié. Du coup, ça encombre l'interface pour rien comme ici :
Et pour le virer proprement depuis les réglages... bah y'a pas, forcement.
Vous pouvez toujours aller bidouiller dans les modules Jetpack un par un, l'assistant IA, lui, reste accroché comme une moule à son rocher. Croyez-moi, j'ai tout exploré et la seule vraie solution tient en une seule ligne. Vous l'ajoutez via un plugin comme Code Snippets, ou directement dans un fichier mu-plugins ou functions.php de votre thème si vous êtes à l'aise avec le code :
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) add_filter( 'jetpack_ai_enabled', '__return_false' );
Et hop, toutes les fonctionnalités IA de Jetpack dégagent d'un coup, y compris la fameuse bulle de chat dans l'éditeur. C'est le hook officiel, documenté chez Jetpack depuis la version 11.8, donc rien de bricolé là-dedans. C'est juste que vous coupez le robinet à conneries à la source.
Maintenant, si toucher au PHP vous file de l'urticaire, sachez qu'il existe aussi un petit plugin baptisé Turn Off AI Features qui fait exactement le même boulot avec un simple interrupteur. C'est un peu la même chose que quand on débranche l'IA imposée de Windows 11 , afin de reprendre la main sur sa propre machine.
Quand on voit que Firefox a réussi à mettre un seul bouton pour tout couper, on se dit qu'Automattic pourrait faire un effort.
Si comme moi, vous bloguez encore à l'ancienne, c'est à dire depuis l'interface web de WordPress.com, sachez qu'Automattic vient de balancer une app pour Mac qui s'est donné pour mission de vraiment bousculer votre façon d'écrire.
WordPress Workspace est donc un éditeur de site, un agent IA, un outil de prise de note... Bref, un outil fourre-tout qui est en réalité un agent IA branché sur votre contenu et capable aussi d'uploader des médias vers la médiathèque de votre site. Ça se présente donc comme un chat auquel on peut demander tout et n'importe quoi, du style "Voici mon article [TEXTE]. Publie le" ou encore "J'ai la flemme, écris moi un article sur ça : [SUJET]".
Vous pouvez aussi l'utiliser pour interroger votre site web, corriger des trucs, mettre à jour des articles...etc.
Le DMG se télécharge en direct depuis le GitHub d'Automattic , et c'est entièrement gratuit avec n'importe quel plan WordPress.com durant la bêta. Et ça fonctionne aussi avec les sites auto-hébergés comme le mien, pour peu que vous l'ayez lié avec Jetpack.
Ce qui est cool avec cet outil c'est surtout que c'est un agent qui connaît déjà votre site WordPress, son contenu, ses médias, ses guidelines et les permissions liées à votre compte. Donc ça va vite...
Au menu des fonctionnalités, vous aurez de la dictée vocale qui s'alignera sur le ton du site, l'envoi de captures d'écran que vous balancez directement dans l'outil, et un raccourci clavier global qui invoque l'agent depuis n'importe quelle app Mac où vous écrivez, même hors WordPress.
Côté multi-sites, vous pouvez aussi naviguer entre plusieurs sites, où chacun devient son propre workspace avec ses propres réglages et ses propres "guidelines" comme on dit, déjà mémorisées.
Sur la roadmap, Automattic prépare une fonctionnalité Guidelines dans le cœur de WordPress, plus des Memories (apprentissage continu de l'agent), des Skills (capacités partageables en équipe) et des Artifacts (stockage de contenu en cours). L'objectif est donc plutôt clair : Ils veulent transformer WordPress en couche de contexte permanente pour les outils IA, et plus simplement en CMS où on dépose des articles.
Donc à tester si vous publiez régulièrement sur WordPress.
This year DjangoCon Europe happened in Copenhagen, Denmark, at a very creative and special place AFUK - Academy for Untamed Creativity. Surrounded by artistic souls, we learned more about web technologies, got to know each other at ecologic reusable disposable cups of coffee, enjoyed delicious authentic food, and socialized with Django-branded beverages. As always, there was also a party with people drinking IPA (not to be confused with API). And at the weekend Django developers were solving bugs for Django and related open-source software at the coding sprints.
Here I would like to present you with the top 5 talks that I liked most of all.
Adam Johnson (@AdamChainz) was talking about special response headers that tell browsers to treat data of the website more securely and which Django settings are responsible for those headers.
Mikey Ariel (@ThatDocsLady) was talking about the necessity of documentation and what to write there.
Sigurd Ljødal (@sigurdlj) was talking about advanced Django ORM use cases.
Markus Holtermann (@m_holtermann) was talking about logging structured data to log files instead of the traditional plain text messages.
Joachim Jablon (@Ewjoachim) and Stéphane Angel (@twidi) were talking about the best practices developing large-scale Django projects.
You can see all talk descriptions, video records and some slides at the official conference website.
Amazing conference photos were taken by Bartek Pawlik.
I was also really astonished how effective were the talk summaries written by rixx almost in real time.
Cover photo by Bartek Pawlik.
Every Django website needs some automatic background tasks to execute regularly. The outdated sessions need to be cleaned up, search index needs to be updated, some data needs to be imported from RSS feeds or APIs, backups need to be created, you name it. Usually, if not all the time, those regular tasks are being set as cron jobs. However, when some task is run in the background, by default, you don't get any feedback whether it was successfully completed, or whether it crashed on the way. In this post I will show you how I handle the results of cron jobs.
In a Django project, all those tasks are usually implemented as management commands. For each such command I write a short bash script, that will call the management command with specific parameters and will print the verbose output to a log file.
Let's say my project structure is like this on a remote server:
/home/myproject
├── bin
├── include
├── lib
├── public_html
├── backups
├── project
│ └── myproject
├── scripts
└── logs
A virtual environment is created in the home directory of myproject linux user. The Django project itself is kept under project directory. The scripts directory is for my bash scripts. And the logs directory is for the verbose output of the bash scripts.
For example, for the default clearsessions command that removes outdated sessions, I would create scripts/cleanup.sh bash script as follows:
#!/usr/bin/env bash
SECONDS=0
PROJECT_PATH=/home/myproject
CRON_LOG_FILE=${PROJECT_PATH}/logs/cleanup.log
echo "Cleaning up the database" > ${CRON_LOG_FILE}
date >> ${CRON_LOG_FILE}
cd ${PROJECT_PATH}
source bin/activate
cd project/myproject
python manage.py clearsessions --verbosity=2 --traceback >> ${CRON_LOG_FILE} 2>&1
echo "Finished." >> ${CRON_LOG_FILE}
duration=$SECONDS
echo "$(($duration / 60)) minutes and $(($duration % 60)) seconds elapsed." >> ${CRON_LOG_FILE}
To run this command every night at 1 AM, you could create a file myproject_crontab with the following content:
MAILTO=""
00 01 * * * /home/myproject/scripts/cleanup.sh
Then register the cron jobs with:
$ crontab myproject_crontab
By such a bash script, I can track:
In addition, this gives me information whether the crontab was registered and whether the cron service was running at all. As I get the total time of execution in minutes and seconds, I can decide how often I can call the cron job regularly so that it doesn't clash with another cron job.
When you have multiple Django management commands, you can group them thematically into single bash script, or you can wrap them into individual bash scripts. After putting them into the crontab, the only thing left is manually checking the logs from time to time.
If you have any suggestions how I could even improve this setup, I would be glad to hear your opinion in the comments.
Here is the Gist of the scripts in this post. To see some examples of custom Django management commands, you can check Chapter 9, Data Import and Export in my book Web Development with Django Cookbook - Second Edition.
Cover photo by Redd Angelo
