Si vous gérez plusieurs sites WordPress, vous avez sans doute déplacé leur page de connexion : WPS Hide Login, SecuPress, Perfmatters… Bonne idée pour la sécurité, moins bonne pour la mémoire. Chaque site a son adresse, et il faut la retrouver à chaque fois qu’on veut corriger une virgule. **2xShift** règle ça : sur n’importe quel site WordPress, deux appuis sur Shift vous emmènent à sa page de connexion, même déplacée. Une règle par site, mémorisée une fois pour toutes. ## La petite histoire J’ai développé la première version de cette extension en 2024 et l’utilise pour mes propre besoin. Je l’avais soumise au Chrome Web Store à l’époque, puis, n’ayant jamais reçu de mail, j’avais conclu qu’elle n’était pas passée et j’avais continué à l’utiliser en local, dans mon coin. En voulant la retoucher récemment, surprise : elle était publiée depuis novembre 2024, avec une poignée d’utilisateurs que je ne connais pas. J’en ai profité pour la refaire proprement avec Claude Code : plus robuste, plus légère, et surtout plus agréable à régler. Je me suis dit qu’elle pouvait servir à d’autres que moi. ## Comment ça marche La première fois que vous faites un double Shift sur un site, un petit panneau vous demande où se trouve sa page de connexion : `/wp-admin/`, votre chemin habituel, un chemin personnalisé, ou « ne jamais rediriger ici ». Le choix est mémorisé pour ce site. Au premier double Shift, le site est mémorisé. Les fois suivantes : double Shift, vous êtes sur la page de connexion, puis renvoyé sur la page où vous étiez une fois identifié. Deux détails qui font toute la différence à l’usage : * **Déjà connecté ? Il ne se passe rien.** En tapant du texte, on appuie souvent deux fois sur Shift sans le vouloir. L’extension vérifie la présence du cookie de connexion WordPress avant d’agir, sans jamais le lire ni le transmettre. * **Site non WordPress ? Il ne se passe rien non plus.** La détection n’a lieu qu’au moment du double Shift, l’extension ne fait rien au chargement des pages. ## Un popup pour le site courant, une page pour tout le reste Un clic sur l’icône de l’extension ouvre un petit panneau pour le site sur lequel vous êtes : définir ou modifier son chemin, y aller tout de suite, ou l’oublier. Le popup, pour régler le site courant sans quitter la page. La page de réglages liste tous les sites mémorisés, avec votre chemin habituel proposé par défaut sur les nouveaux sites. Les règles sont synchronisées avec votre compte Chrome, comme vos favoris. Les réglages : proposition par défaut et sites mémorisés. À l’installation, un assistant très sobre vous demande simplement votre adresse de connexion habituelle. Le reste se fait au cas par cas, site après site. L’assistant d’installation : une question, et c’est réglé. ## Vie privée Aucune donnée ne quitte votre navigateur. Pas de compte, pas de statistiques, pas de serveur. Le code est ouvert, vous pouvez le lire, le forker ou me signaler un site qui ne se laisse pas détecter. ## Où la trouver * 2xShift sur le Chrome Web Store (Chrome, Brave, Edge, Arc et tout navigateur compatible) Si vous utilisiez déjà la première version, la mise à jour est automatique et vos sites enregistrés sont conservés. Et si elle vous fait gagner quelques secondes par jour, un café est toujours le bienvenu. Si la demande est présente, j’envisagerai un portage vers Firefox.

With the 3.9 version, we’re making multilingual site management more visual, more convenient, and easier to automate. The new release brings a redesigned Language Switcher, better tools for keeping track of your translations, new REST API capabilities, and improved visibility into DeepL usage. The 3.9 version of Polylang Pro also simplifies license management for Business Pack users. In this article, we’ll give you a quick overview of the main new features included in Polylang 3.9 and Polylang Pro 3.9. We’ll cover each of them in more detail in dedicated articles, with examples and further explanations. ## A redesigned Language Switcher and optimized SVG flags Polylang Polylang Pro Polylang Business Pack The Language Switcher has been completely redesigned with new customization options and layouts. You can now control how language labels and flags are displayed, customize options such as flag size, border radius, alignment, and spacing. For example, the new Flags settings let you choose how flags are displayed, including a round shape, as shown in the screenshot below. The Flags settings panel with the round flag option enabled. The release also introduces a new set of lightweight SVG flags, replacing the default PNG flags to allow more customization while keeping performance in mind. ## Improved content management Polylang Polylang Pro Polylang Business Pack The 3.9 version makes it easier to monitor your multilingual content directly from the WordPress posts list. A new filter lets you find posts that have not yet been translated into a selected language. Filter posts by their translation status directly from the WordPress posts list. Persistent language views also display the number of posts available in each language and can be combined with WordPress status views such as Published and Draft. Language views show the number of posts available in each language and can be combined with WordPress status views. ## New REST API capabilities Polylang Pro Polylang Business Pack Polylang Pro 3.9 allows developers to manage active languages and fallback languages through the REST API. Languages can be activated or deactivated and fallback languages can be configured programmatically. This makes it easier to automate multilingual configurations, especially when deploying or configuring multiple sites. ## Track your DeepL usage Polylang Pro Polylang Business Pack When using DeepL, Polylang Pro 3.9 now lets you see the number of billed characters directly in the translation interface. The character count is displayed as soon as the translation is completed, before you save or publish the content. This information was already available in **Languages > Settings > Machine Translation**. With 3.9, the usage is also displayed directly in the translation interface, making it easier to keep track of your consumption while translating without having to leave the page. DeepL character usage displayed in the translation interface ## Simpler Business Pack license management Polylang Business Pack Polylang Pro 3.9 simplifies license management for Business Pack users by consolidating the license inputs into a single field. Your existing Business Pack license will be automatically preserved and pre-filled after updating. The new system also prepares the Business Pack for future add-ons, which will be automatically covered by the main bundle license. Polylang 3.9 and Polylang Pro 3.9 are available as beta releases this week. ## Get the beta versions For **Polylang** , go to the Advanced View on WordPress.org, scroll to the bottom of the page, and select **“Development version”**. For **Polylang Pro** , go to your**Account > Downloads **menu and download the beta version from the **“Beta versions”** section. Before testing the update, **back up your site or use a local environment**! If you encounter issues or have questions, please open a support ticket. Your feedback is invaluable in ensuring the stable version is polished and ready for all users. Thank you so much for helping us shape Polylang and happy testing!

Man (onbekend) viel in 2023 neer in Amsterdam en kan door afasie zijn identiteit niet onthullen. Politie deelt beelden. Mogelijk Canadees of Amerikaan. Herken jij hem?

First introduced in April as the WordPress Core Dev Environment Toolkit, the **WordPress Contributor Toolkit** is an experimental desktop app that guides first-time contributors through setting up a full `wordpress-develop` environment. GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/, Node.js, and npm are still involved under the hood, but the app provides and runs them for you. You do not have to install Git, Node.js, npm, or Docker on your machine. WordPress Contributor Toolkit 1.0 is now available for Windows, macOS (Apple Silicon) and Linux. The first releases concentrated on getting a newcomer from a fresh computer to a running WordPress development siteDevelopment Site You can keep a copy of your live site in a separate environment. Maintaining a development site is a good practice that can let you make any changes and test them without affecting the live/production environment.. Version 1.0 carries that work through the contribution itself: link a TRACTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. and see its details, pull requests, and patches; apply existing work and test it on the running site; create a diff or open a pull request directly from the app; and keep that first site current with the latest trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., fetching only what changed instead of repeating a full clone and install. ## A first CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contribution, from start to finish Here is what the workflow looks like now. ### 1. Create the development environment Click **Create WordPress Core site** and choose a folder. The app clones `wordpress-develop`, installs the dependencies, and runs the first build as one continuous setup. When setup finishes, click **Start dev server and finish the wizard** to complete the WordPress installation wizard that opens in your browser, and you are ready to start contributing. The interface draws attention to the next action with a yellow outline, and completed actions produce an accessible confirmation. ### 2. Link the site to a Trac ticket You can link a Trac ticket when creating the site or at any time afterwards. Enter its ticket number or paste its Core Trac URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to bring its details, related pull requests, and attached patches into the Toolkit. The app reads the ticket’s details: summary, status and resolution, type, milestone, component, keywords, and age. These details help you understand the ticket before you start working: how long ago it was opened, whether it is still open or has already been resolved, and which part of WordPress Core it belongs to. If you do not have a ticket yet, the app links to the good first bugs report on Trac. ### 3. Check the work that already exists A linked ticket shows the work that already exists: * Pull requests on `WordPress/wordpress-develop` that reference the ticket, including their open, closed, or merged state. * Patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a **diff**. A patch can be _applied_ to a codebase for testing. files attached directly to Trac. The newest work is marked **Latest** , based on the date of the newest commit. You can preview and apply a pull request or Trac patch from the same screen. ### 4. Apply and test an existing patch Before applying a patch or a PR, the Toolkit previews the files a patch will touch, warns about collisions with your edits, identifies binary files it cannot apply, and checks whether a dependency install will be needed. “Apply and rebuild” then adds the changes and runs any required install or rebuild steps. If a patch cannot be applied, the app leaves the checkout unchanged and explains what failed so you can decide what to do next. Applied work keeps the patch or pull request’s identity attached to it. You can make your own changes on top and later remove that layer, but the app will not let you submit somebody else’s patch as if you wrote it. ### 5. Edit and debug the change The site can be opened in a detected editor, another application of your choice, or the system file manager. The build watcher now has its own control, status, and log. Starting the development server starts the watcher too, but stopping the server leaves compile-on-save running if you still need it. The Toolkit also exposes the parts of a development environment that are useful in Core testing and development: * A direct link to `wp-admin` beside the site URL. * A live `debug.log` tab with PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher notices, warnings, deprecations, stack traces, and fatal errors. * An embedded terminal for the supported install, build, test, watch, and Grunt commands, using the Node.js runtime bundled with the app. * Adminer for inspecting the site’s SQLite database while the development server is running. The development server can remain up while a patch is applied or trunk is updated. The app pauses and resumes the build watcher only when an operation needs exclusive access to the build or dependencies. ### 6. Review and send the contribution Click **Review & submit changes** to inspect the complete diff, then choose who will send it: * **Open a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ pull request.** The app uses GitHub’s device sign-in, creates the fork, commit, and pull request through the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., and forgets the token when the app quits. No push credential is written to disk. The pull request form asks for a title and optional notes for reviewers: what the change does and why, how to see it working, and anything you are unsure about. The app adds the Trac ticket and your WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ username to the description, then points you back to Trac because Core pull requests are not monitored on GitHub alone. * **Attach a patch to Trac.** The app saves the patch locally and opens the attachment page for the site’s linked ticket. From there, you’ll need to sign in and upload the saved file to the TRAC ticket yourself. * **Hand the patch to a mentor.** This path needs no GitHub or Trac account. The saved patch carries the contributor’s WordPress.org handle, event, ticket, base revision, and date so the authorship can follow the work when a mentor submits it. The diff comes first on this screen. The destinations sit beside it, grouped by whether you or a mentor will do the sending. ## One site can hold work for many tickets Creating a site is the expensive part: cloning `wordpress-develop`, installing its dependencies, and running the first build. Starting another ticket should not repeat all of that. In 1.0, every linked ticket gets its own branch inside the site. Unlinking a ticket parks its changes, and linking another swaps the files in seconds. The site shows the tickets that have work stored in it, so returning to one does not depend on remembering its number. Each ticket contains only that ticket’s changes. ## Keep the environment without keeping an old copy of trunk A site no longer has to stay on the snapshot of trunk it cloned. **Update to latest trunk** fetches current Core code, installs dependencies only if they changed, and rebuilds the site. Sites more than 14 days old show a warning that patches created from them may no longer apply cleanly. The Toolkit uses its own built-in Git implementation, so Git does not need to be installed on your computer. To keep the initial download small, it creates a depth-one shallow clone. If you do have Git installed and run it inside the site folder, history-based commands will be limited: `git log` sees only the current snapshot, while `git blame` and `git bisect` cannot work normally. Updating trunk does not silently rebase ticket work. The app parks the active ticket, updates the site, and returns to it on its original base. If trunk has moved since that ticket started, the Toolkit says so and explains the safe path to recreate the ticket on a fresh base. ## Made for Contributor Days Version 1.0 is available just in time for WordCamp US Contributor Day on August 16. If you are a first-time contributor planning to work with the Core team, the Test team, or another Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/ team working in `wordpress-develop`, download the app and create your first site before Sunday if you can. The Toolkit can help you find the pull requests and patches linked to a ticket, apply them, and test the result on a running site, even if you are not writing the fix yourself. The installer is self-contained, but the initial clone and dependency installation still need an internet connection and some time. For Contributor Day facilitators, the Toolkit is a simpler way to introduce people to Core contributions without spending the session on environment setup. Newcomers and testers can get straight to a ticket, try existing work, and contribute feedback with experienced contributors nearby. Downloads are available for: * macOS on Apple Silicon * Windows x64 * Linux x64 as an AppImage Download WordPress Contributor Toolkit 1.0, then follow the getting started guide for installation and a first contribution walkthrough. ## Your feedback shapes the next update The app has no telemetry. Bug reports, release downloads, and direct feedback are the only signals about where it helps and where contributors still get stuck. You can share feedback through this form, open an issue in the repository, use the feedback button in the app, comment on this post, or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” `@JuanMa` in the `#core` channel on WordPress Slack. Feedback from WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Contributor Days is particularly helpful, especially on whether the Toolkit enabled you to complete a contribution independently, where you still needed a facilitator, and what could have made the process easier. ## Resources * Download WordPress Contributor Toolkit v1.0 * Follow the Toolkit getting started guide (Docs) * WordPress Contributor Toolkit GitHub Repo * Read the v1.0 release notes * Learn how to contribute code to WordPress Core * Browse good first bugs on Core Trac * Read the FAQ for new Core contributors _Props to @greenshady,@bph and @softglaze for review and feedback_ ### Share this: * Share on Threads (Opens in new window) Threads * Share on Mastodon (Opens in new window) Mastodon * Share on Bluesky (Opens in new window) Bluesky * Share on X (Opens in new window) X * Share on Facebook (Opens in new window) Facebook * Share on LinkedIn (Opens in new window) LinkedIn * * Login to Reply

NOTRE FORÊT BRÛLE. IL FAUDRA ENSUITE LUI LAISSER LE TEMPS DE VIVRE. Après cette journée et cette nuit épouvantables, l’heure est évidemment encore à la lutte contre les incendies, à la protection des habitants, des animaux et de celles et ceux qui combattent les flammes. Mais très vite viendra le temps des décisions. Et nous refusons que, une fois les fumées dissipées et l’émotion retombée, tout reprenne simplement comme avant. Nous demandons au préfet de Seine-et-Marne de prendre la mesure de ce qui est en train de se produire dans notre massif forestier et de reconnaître l’ampleur exceptionnelle de cette catastrophe écologique. 🔥 Des centaines d’hectares parcourus par les flammes. 🔥 Des habitats détruits ou profondément bouleversés. 🔥 Une faune sauvage tuée, blessée, déplacée ou privée de refuge et de nourriture. 🔥 Des zones épargnées qui vont devenir essentielles à la survie des animaux ayant fui les secteurs incendiés. 🔥 Un écosystème entier qui aura besoin de temps, de calme et d’espace pour se reconstruire. La forêt qui n’a pas brûlé n’est pas devenue moins importante. Elle est devenue encore plus précieuse. Les animaux survivants vont devoir se déplacer, trouver de nouveaux territoires, de nouvelles zones de repos, de reproduction et d’alimentation. La pression sur les secteurs épargnés va nécessairement augmenter. C’est pourquoi nous demandons des mesures exceptionnelles à la hauteur d’une situation exceptionnelle. Nous demandons que le massif bénéficie, pour la saison à venir, d’une véritable période de répit. Nous demandons notamment : ➡️ la suspension de la chasse dans les secteurs touchés et dans les zones refuges indispensables à la faune déplacée, avec une réévaluation scientifique avant toute reprise ; ➡️ la suspension des coupes forestières non indispensables, afin de ne pas ajouter de nouvelles perturbations à un massif déjà profondément fragilisé ; ➡️ la mise en place d’un véritable plan de suivi écologique, permettant d’évaluer les conséquences des incendies sur la faune, la flore, les sols et les continuités écologiques ; ➡️ la protection renforcée des zones refuges, qui vont accueillir une partie de la biodiversité chassée des secteurs incendiés. Il ne s’agit pas de céder à l’émotion. Il s’agit au contraire d’en tirer les conséquences. On ne peut pas constater une catastrophe écologique d’une telle ampleur puis, quelques semaines plus tard, remettre les animaux survivants sous la pression des battues, du dérangement et des coupes forestières comme si rien ne s’était passé. Après le feu, la forêt a besoin de silence. Après la fuite, les animaux ont besoin de refuges. Après la catastrophe, notre responsabilité est de leur laisser du temps. ✍️ Nous appelons donc toutes celles et ceux qui aiment et défendent ce massif à signer et partager massivement cette pétition. Plus nous serons nombreux, plus notre demande pèsera face aux décisions qui seront prises pour la saison prochaine. Cette forêt vient de subir l’une des épreuves les plus violentes de son histoire récente. La moindre des choses est maintenant de lui accorder un répit. Pour la La Foret de Fontainebleau et ses habitants Signez. Partagez. Mobilisez-vous. Pour que l’après-incendie ne soit pas simplement un retour à « comme avant ».