Connexion
PHP a publié ce mercredi 21 octobre quatre mises à jour d'urgence qui corrigent deux failles critiques, notées 9,2 sur 10. Ces failles permettent de prendre la main sur un serveur web sans s'identifier. Les appels à mettre à jour se multiplient, sur fond de crainte d'une attaque informatique.
Je sais que c'est à la mode en ce moment de vibecoder des outils qui manipulent des PDF donc c'est pour ça que je relaie cette alerte de Wordfence qui vient de publier le détail d'une faille dans Ghostscript (c'est un programme très connu qui transforme grosso modo les PDF en images).
Argus, l'agent IA de recherche de faille de Wordfence, a donc trouvé cette vuln d'un score CVSS de 9,8 sur 10 référencée sous le code CVE-2026-39919. Elle est assez grave puisqu'un PDF piégé contenant une image JPEG 2000, forgé pour l'occasion, suffit à faire écrire Ghostscript au-delà de sa mémoire et donc à introduire dans la mémoire de la machine du code malveillant.
Côté WordPress pur, le chemin est tordu car pour fabriquer la miniature d'un PDF, Wordpress appelle Imagick, qui appelle ImageMagick, qui lance ensuite Ghostscript. Mais Wordfence a obtenu par ce biais une exécution de code sans authentification sur un site de test monté pour l'occasion, y compris avec le paramétrage de sandbox -dSAFER activé.
Pour être touché, il faut donc 4 choses en même temps :
Comme vous le savez surement, WordPress de base ne laisse pas un anonyme envoyer de PDF dans la médiathèque, donc il faut qu'un plugin, un formulaire ou un compte lui ouvre la porte pour que la première condition soit remplie.
Bien sûr, ça ne s'arrête pas à WordPress puisque tout ce qui est outil de gestion de documents, services d'impression, passerelles mail ou API de conversion peuvent être également exposés à partir du moment où ils donnent des PDF inconnus à un Ghostscript vulnérable.
Maintenant pas de panique parce que ces exploits mis au point par Wordfence exigent quand même d'être forgés spécifiquement pour l'environnement ciblé et aucune exploitation sauvage n'a été constatée pour le moment.
Maintenant si un attaquant connait votre build ou vise un hébergeur dont plusieurs sites partagent la même image, ça fera surement des dégât, donc il vaut mieux patcher ça.
D'après la page de sécurité d'Ubuntu et le suivi de Debian , Ubuntu a corrigé ses 22.04, 24.04 et 26.04, et Debian sa 13, tandis que Debian 12 reste marquée vulnérable. Red Hat a des paquets corrigés pour RHEL 8, 9 et 10, AlmaLinux 10 aussi depuis le 2 octobre, et Wordfence notait au 9 octobre que Fedora 44 et Alpine 3.22 et 3.23 en étaient encore à leurs anciennes révisions.
Et ne vous fiez pas au numéro que renvoie gs --version puisqu'Ubuntu 22.04 greffe son correctif sur un Ghostscript qui continue de se présenter comme une version 9.55.0. C'est surtout la révision du paquet qui tranche. Un dpkg -s ghostscript la donnera sur Debian et Ubuntu et un rpm -q ghostscript vous donnera l'info sur une Red Hat / Fedora.
Et sous Docker, il faudra "pull" une image à jour, reconstruire sans le cache et redéployer tout ça.
Reste une parade si le correctif n'existe pas encore pour votre système qui est expliqué sur
la page de politique de sécurité d'ImageMagick
. Sur cette page, vous trouverez une règle à intégrer dans le fichier policy.xml, qui ne laisse que l'écriture des formats PDF, PS, PS2, PS3 et XPS, et désactive l'aperçu de PDF.
La commande magick identify -list policy permet ensuite de vérifier que le changement est bien pris en compte. Bien sûr, elle ne fonctionne qu'avec ImageMagick et il est possible qu'une autre bibliothèque se glisse entre votre application et Ghostscript, donc soyez vigilant.
Dans tous les cas, si vous avez un doute, le mieux reste encore de demander à votre hébergeur si son Ghostscript dispose du correctif de la CVE-2026-39919.
Source : le billet de Wordfence et l'article de BleepingComputer
Hackers are actively exploiting CVE-2026-87902, a critical WordPress flaw that can lead to remote code execution. Here’s what admins should do.
The post WordPress Flaw Under Active Attack: Hackers Target CVE-2026-87902 for Code Execution appeared first on TechRepublic.
Vous avez un site sous WordPress ? Alors lâchez tout ce que vous faites deux minutes, parce que là c'est du sérieux !!
Cette nouvelle attaque baptisée WP2Shell permet de compromettre une installation Wordpress sans passer par le moindre plugin. Heureusement, un patch est sorti en urgence le 17 juillet !
En temps normal, quand une alerte sécu tombe sur WordPress, le fautif c'est un plugin tiers vérolé , un truc installé un soir de flemme et oublié depuis des lustres. Mais cette fois, rien de tout ça puisque le trou de sécu se trouve dans le cœur de WordPress lui-même.
Dans le détail, WP2Shell enchaîne deux failles. La première,
CVE-2026-63030
, est une confusion de route dans l'API REST batch, sur l'endpoint /wp-json/batch/v1. La seconde,
CVE-2026-60137
, est une injection SQL bien planquée dans le paramètre author__not_in de WP_Query. Chacune dans son coin, c'est déjà vilain, mais mises bout à bout, elles offrent une exécution de code à distance.
Pas de compte, pas de mot de passe, et encore moins de plugin exotique mais simplement quelques requêtes HTTP et hop, c'est plié !
Côté versions, la chaîne complète touche WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Si votre site est dans cette fourchette, vous êtes donc exposé. Les correctifs sont arrivés avec les versions 6.9.5 et 7.0.2. Et si vous vous traînez encore une vieille 6.8.x, sachez que seule l'injection SQL vous concerne potentiellement mais qu'elle a été patchée depuis la version 6.8.6.
Derrière cette trouvaille, on trouve Adam Kues, chercheur chez Assetnote (une branche de Searchlight Cyber), qui a assemblé et documenté toute la chaîne avant de la remonter proprement via le programme HackerOne de WordPress. Les détails techniques les plus croustillants restent sous le coude le temps que la planète patche mais l'équipe a mis en ligne un outil, wp2shell.com , pour vérifier si votre site est vulnérable. Allez-y, ça coûte rien !
Autre signal qui ne trompe pas, WordPress.org a déclenché les mises à jour automatiques forcées sur les sites concernés. Une mesure réservée aux failles vraiment graves, comme à l'époque où la faille critique de Really Simple Security avait exposé des millions de sites. Il y a donc de bonnes chances que votre installation toute pourrie dont vous ne vous occupez pas parce que vous êtes un mauvais webmaster ^^ ait déjà été rustinée toute seule. Vraiment, vous ne méritez pas les équipes sécu de Wordpress ^^
Mais ne pariez pas votre site là-dessus non plus... Car si vous avez désactivé les mises à jour auto (et beaucoup d'hébergeurs et d'admins le font), personne n'aura rien poussé chez vous. Sans oublier qu'un bout de PoC circule déjà sur GitHub (les chercheurs gardent pour eux le dernier maillon vers la RCE, mais ça n'arrêtera pas longtemps les motivés), et les scans automatisés ont commencé.
En attendant de patcher, bloquez surtout donc l'accès anonyme à l'endpoint batch de l'API REST via votre WAF ou votre plugin de sécu. Attention, pas seulement la forme /wp-json/batch/v1 : sa variante ?rest_route=/batch/v1 doit sauter aussi, sinon autant laisser la clé sur la porte. Cloudflare propose d'ailleurs des règles toutes prêtes. Et pour durcir le reste de votre config,
ma vieille série sur le sujet
reste d'actualité.
En tout cas, quand on sait qu'il y a +500 millions de sites actuellement propulsés par Wordpress, même s'ils ne sont pas tous concernés par cette faille, ça reste une surface d'attaque gigantesque !!
Bref, filez vérifier votre version. Sous 6.9.5 ou 7.0.2, vous mettez à jour et vous bloquez le batch en attendant. Deux minutes chrono, et votre site dort tranquille !
Source : Security Affairs
An exposed WP-SHELLSTORM server revealed tools, logs, cloud credentials, and thousands of webshells used in a large website hacking campaign.
The post Exposed Server Reveals 25,000 Compromised WordPress Websites appeared first on TechRepublic.
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.
An all-in-one WordPress hosting platform with performance tools, security layers, and email hosting built in.
The post Host 5 WordPress Sites for Just $80 Instead of Monthly Fees Forever appeared first on TechRepublic.
Matt Mullenweg vient de publier un billet anniversaire des 23 ans de WordPress, et ce qui devait ressembler à une célébration tient plus de l'appel au secours. Et j'avoue qu'à lecture, ça m'a mis un petit coup au moral... Parce que oui, le créateur de WordPress est épuisé à cause de 19 mois de guerre juridique...
Côté chiffres pourtant, le post commence très bien. WordPress 7 est sorti la semaine dernière, et en sept jours, 46% des installations sont déjà passées en 7.0 sans aucune casse. Du Raspberry Pi au site de la Maison Blanche, en passant par Korben.info, pas un wp-config.php à éditer à la main, pas un cron à relancer, pas un fichier .htaccess à toucher, TOUT A FONCTIONNÉ !!
Et surtout, aucune attaque supply chain ni faille de sécurité, en tout cas pour le moment. Matt insiste là-dessus et il a raison d'en être fier ! Mais c'est pas vraiment ce qu'on retient de son article...
En effet, ce qu'il explique c'est que la sortie de WordPress 7 n'a pas été ce qu'il espérait parce que trop de temps a été perdu à cause des attaques de WP Engine. Il a, je cite, "des collègues EN TRAIN DE MOURIR" (les majuscules sont dans le texte) qu'il ne peut pas aller voir parce qu'il est noyé sous les procédures. Son meilleur ami attend une greffe de cœur sur un lit d'hôpital pendant que les avocats de Quinn Emanuel l'interrogent sur tout un tas de conneries sans intérêt...
Mais avant, petit rappel pour ceux qui n'auraient pas suivi... depuis septembre 2024, Matt est en guerre ouverte avec WP Engine, un gros hébergeur WordPress propriété de Silver Lake. J'en parlais déjà à l'époque dans WP Engine vs WordPress, la guerre est déclarée . Et en 19 mois, ça n'a pas refroidi du tout... ça s'est même carrément "judiciarisé" à mort.
Silver Lake pèse plus de 100 milliards de dollars (et vient au passage de récupérer TikTok aux États-Unis), et ils ont lâché Quinn Emanuel sur l'affaire. Matt emploie le terme de "shoggoth paperclip-maximizer" pour le qualifier... En gros, ça veut dire que c'est un gars sans émotion qui exécute les ordres de manière littérale jusqu'à l'absurde.
Bref, il s'attaque à Automattic, à lui personnellement, et essaie maintenant carrément de dissoudre la Fondation WordPress qui je le rappelle est à but non lucratif sans aucun employé, et qui finance entre autres les WordCamps et l'éducation open source à travers le monde. C'est le truc qui fait tourner la communauté...
Et de ce qu'on comprend dans ce récit de Matt Mullenweg, c'est que WP Engine essaie de faire passer Matt pour quelqu'un qui détruit des preuves, parce que wordpress.org fait de la rotation de logs (chose que fait absolument tout serveur sur Terre depuis l'invention de syslog en 1980) et parce qu'il utilise les messages éphémères sur Signal avec ses partenaires amoureuses.
Bref, je comprends que le gars soit fatigué par tout ce merdier et cette mauvaise foi. Et puis vient le passage qui fait vraiment mal quand Matt s'adresse directement à Silver Lake : "Vous avez déjà tout dépecé. Si vous vouliez me faire souffrir pour mes péchés, j'ai souffert, et probablement plus profondément que vous ne le saurez jamais. WordPress et WordPress.org, et oui, même mon leadership imparfait, sont au cœur de ce qui a fait le succès de WP Engine jusqu'ici. Vous avez tellement d'argent et de pouvoir, vous venez d'avoir TikTok, l'administration Trump vous adore, vous n'avez pas besoin de contrôler WordPress aussi. Si vous gagnez, vous le détruisez, et après ?"
Puis il termine sur ces mots : "I submit. Let's move on".
Le mec capitule sur le blog officiel... Je dois avouer que j'avais jamais vu ça.
C'est un humain qui craque mais c'est également une fondation à but non lucratif qui risque de disparaître...
Bref, c'est triste pour Matt et clairement pour tout l'écosystème open source derrière. Force à lui et à WordPress !
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.
See what you missed in Daily Tech Insider from April 13–17.
The post AI Upgrades, Security Breaches, and Industry Shifts Define This Week in Tech appeared first on TechRepublic.
Tags de l’article
More than 30 WordPress plugins were shut down after a supply-chain backdoor compromised thousands of sites through the Essential Plugin portfolio.
The post Malicious WordPress Plugins with Backdoors Compromise Thousands of Websites appeared first on TechRepublic.
Une attaque par la chaîne d'approvisionnement a frappé WordPress début avril. Un individu a racheté une trentaine de plugins via la marketplace Flippa, y a injecté du code malveillant et a attendu huit mois avant de l'activer. WordPress a fermé les 31 plugins concernés le 7 avril, mais la mise à jour officielle ne suffit pas à nettoyer les sites touchés.
L'attaque est redoutable par sa simplicité. Un individu, identifié sous le prénom "Kris", a racheté pour plusieurs centaines de milliers d'euros un catalogue d'une trentaine de plugins WordPress sur Flippa, une marketplace de vente de sites et d'extensions. Ces plugins appartenaient à la société Essential Plugin / WP Online Support. Ils étaient actifs, mis à jour, et installés sur des milliers de sites.
En achetant le catalogue, l'acheteur a récupéré l'accès au dépôt officiel WordPress.org et a pu pousser des mises à jour directement aux utilisateurs. Le code malveillant a été injecté dès août 2025, mais il est resté dormant pendant huit mois. L'activation a eu lieu les 5 et 6 avril 2026.
Côté technique, l'attaque est assez vicieuse. Le module injecté (wpos-analytics) utilise une désérialisation PHP pour communiquer avec un serveur de commande. Et là, le point intéressant : au lieu d'utiliser un domaine classique pour piloter la backdoor, le malware résout l'adresse de son serveur C2 via un smart contract Ethereum, en interrogeant des points d'accès RPC publics. Résultat, couper un nom de domaine ne sert à rien. L'attaquant peut mettre à jour le smart contract à tout moment pour pointer vers un nouveau serveur.
Le payload injecte du code dans le fichier wp-config.php (environ 6 Ko) et crée un fichier wp-comments-posts.php, un nom assez proche des fichiers légitimes pour passer inaperçu. Le tout sert à afficher du spam SEO (liens, redirections, fausses pages) uniquement à Googlebot, ce qui rend l'attaque invisible pour le propriétaire du site.
WordPress.org a fermé les 31 plugins touchés le 7 avril et a poussé une mise à jour forcée le lendemain. Sauf que cette mise à jour ne nettoie pas le fichier wp-config.php, qui est le vrai point de persistance de la backdoor. Si vous avez l'un de ces plugins installé (Countdown Timer Ultimate, Popup Anything on Click, Post Grid and Filter Ultimate, WP Slick Slider, Album and Image Gallery Plus Lightbox, Responsive WP FAQ, entre autres), il faut aller vérifier votre wp-config.php manuellement et chercher un bloc de code d'environ 6 Ko qui n'a rien à y faire. Le fichier wp-comments-posts.php à la racine du site doit aussi être supprimé s'il est présent.
La vraie leçon ici, c'est que la confiance dans un plugin WordPress repose sur son historique, et qu'un changement de propriétaire peut tout remettre en question du jour au lendemain. WordPress.org ne vérifie pas les changements de mains sur les comptes développeurs, et n'a aucun mécanisme d'alerte quand un catalogue entier passe à un nouvel acheteur. Tant que ce trou existe, ce genre d'attaque peut se reproduire. Et le fait que la mise à jour officielle ne nettoie même pas les sites infectés, c'est quand même un problème.
Source : The Next Web
Launch and manage up to 50 WordPress sites with fast, reliable hosting, built-in tools, plus 24/7 support.
The post Build Faster, Launch Smarter: $207 off WordPress Hosting appeared first on TechRepublic.
Cloudflare qui sort un successeur open source à WordPress le 1er avril, je vous avoue que ça sentait le poisson d'avril à plein nez. Sauf que non !! EmDash est bien réel, son code est sur GitHub sous licence MIT, et ça s'installe en une commande toute simple !
L'idée de base pour Cloudflare, c'est de dire que WordPress a plus de 20 ans et bien qu'il alimente 40% du web, son architecture de plugins est un emmental (Le gruyère n'a pas de trou les amis ^^). En effet, 96% des failles de sécurité viennent des extensions et pas du noyau PHP ni des thèmes et en 2025, on a quand même explosé le record de failles dans l'écosystème WP.
Du coup Cloudflare, grand prince (Matthew ^^ Ok, je sors...) a tout repris de zéro en TypeScript et avec l'aide de nombreux agents IA. Et de ce que j'ai compris, le gros morceau de ce projet, visiblement, c'est l'isolation des plugins.
Car sur WordPress, une extension a accès à toute la base de données et au système de fichiers (d'où
l'importance de bien les choisir
). Alors que sur EmDash, chaque plugin tourne dans son propre isolat avec un modèle de capacités déclaratives. En gros, le plugin annonce dans un fichier manifeste JSON ce dont il a besoin, genre read:content ou email:send, et il ne peut rien faire d'autre. S'il veut accéder au réseau, il doit même préciser le hostname exact. Comme ça fini les extensions qui aspirent vos données en douce. Par contre, ça veut aussi dire que vos plugins WordPress actuels ne marcheront pas tels quels...
Côté stack, c'est comme je disais du TypeScript de bout en bout avec Astro 6.0 en frontend (pour les thèmes) et Node.js derrière. L'auth passe également par des passkeys par défaut (enfin, plus de mots de passe !) et y'a même un système de paiement natif via le standard ouvert x402 pour monétiser du contenu.
Et le truc qui va vous rassurer si vous êtes allergique au cloud : c'est auto-hébergeable. En fait, le CMS peut tourner sur Cloudflare Workers, mais aussi sur n'importe quel serveur Node.js avec SQLite. Les abstractions sont portables, avec Kysely pour le SQL et l'API S3 pour le stockage. Du coup vous pouvez brancher PostgreSQL, Turso, AWS S3, ou tout bêtement des fichiers en local. Le bonheur !
Le truc cool pour les bidouilleurs, c'est que chaque instance expose un serveur MCP (Model Context Protocol) et une CLI pour piloter le CMS par script. Y'a aussi des Agent Skills pour que les agents IA puissent créer du contenu, gérer les médias et modifier le schéma sans toucher au dashboard. C'est clairement pensé pour l'ère des agents IA.
Et pour ceux qui veulent migrer depuis leur WordPress, c'est prévu pour vous faciliter la tâche puisqu'il y a le support d'export WXR classique ou via un plugin dédié qui crée un endpoint sécurisé protégé par mot de passe. Que ce soient les médias, les custom post types...etc tout est transférable en quelques minutes. Par contre, attention les shortcodes et les blocs Gutenberg custom ne passeront pas tels quel, faudra faire des ajustements.
Car oui c'est une v0.1.0 preview, donc on peut le dire, une bonne grosse beta qui bave mais je trouve ça super cool car le drama WP Engine vs WordPress a montré que l'écosystème était fragile, et c'est bien de réintroduire un peu de diversité. Par contre, remplacer un CMS qui fait tourner 40% du web, c'est hyper ambitieux et ça se fera pas en un trimestre. Car la vraie force de WordPress, c'est sa communauté, ses milliers de plugins et de thèmes, et ça pour le moment, y'a pas grand chose sur EmDash.
M'enfin, si vous voulez tester c'est npm create emdash@latest et c'est parti mon kiki. Ah et y'a aussi un playground sur
emdashcms.com
pour vous faire une idée sans rien installer. Pour ma part, je testerai ça dès que j'aurais 5 min, mais pour le moment, je ne me vois pas quitter WordPress car EmDash n'a pas (encore) ce petit truc en plus qui me ferait changer... On verra d'ici quelques temps.
A security flaw in the Ally WordPress plugin used on more than 400,000 sites could allow attackers to extract sensitive data without logging in.
The post Security Flaw in WordPress Plugin Puts 400,000 Websites at Risk appeared first on TechRepublic.
So bizarrely, I forgot my WordPress admin password, including my login name. I did not add my login details to my password manager either. The container image that I built lacking outgoing email support (SMTP) too. I got stuck. Fortunately, I have full root access to my MySQL/MariaDB server hosted at AWS EC2, and here is how to reset a forgotten WordPress password using MySQL command-line.
The post How to reset WordPress password using MySQL CLI appeared first on nixCraft.
The intuitive WordPress has become the most popular CMS (Content Management System), both by individuals and by companies. The fact that this platform is used in 25% of the Internet websites certify its undeniable popularity, and at the same time helps to understand why developers not using WordPress are wasting a huge opportunity.
Although there are a lot of causes that explain the success and its acceptation grade, some of the main reasons are the simplicity, flexibility and power that it offers to the developers when they have to create themes or plugins. Because of this, some developers say that despite they work with a CMS, they have the feeling that nothing is impossible to do.
Before starting to develop our theme, I recommend to make a new naked WordPress installation in a remote or local server. This is because in order to test our theme, we need to have it active.
In this post I’ll assume that you know how to install and configure a WordPress site, that you know how to access your server via FTP, and that you know HTML, CSS and have some notions of PHP.
As you may know, WordPress installs all themes in the themes directory, located inside the wp-content folder:
To begin to develop our theme, we can create a new folder with any name we want (don’t use special characters or spaces). However, keep in mind that to add a new directory inside themes doesn’t make WordPress understand that there exists a new theme to use. To offset this problem, we need at least two new files.
At the moment, we have the minimum required files for WordPress to detect a new theme. If we open the Theme Manager in our WordPress installation we’ll see something like this:
Notice that when we see something like this, it’s because WordPress has already detected our new theme.
Next we’ll improve the Theme Manager preview, to make it more attractive to potential users.
Now is the moment to open our style.css file and add, in comment format, some parameters at the top of the document. It’s very important to keep exactly the same structure that we show below, so that WordPress doesn’t have problems in understanding the parameters.
/* Theme Name: My First WordPress Theme Template Theme URI: http://my-website.com/my-first-wordpress-theme Author: Your name here Description: A description about your theme here. Version: 1.0 */
After this action, in the WordPress Theme Manager we’ll see something like this:
In this example only some of the possible parameters are defined (you can find the full set of options here).
Our advice is that you don’t only copy and paste the code: try to write it, change the parameters, put a cool name to your template, test and change the parameters… and check what happens in every situation. Additionally, we encourage you to continue these suggestions in any step we take. Dare to experiment without fear!
In order to complete our theme preview in the Theme Manager, we need to add a screenshot of the theme final look. As our theme consists on a white page, we’ll add a default image to illustrate this step.
This image should be renamed as screenshot, of 800x660px and preferably has to be in .png format (although .jpg, .jpeg or .gif are also valid formats). Moreover, it has to be placed inside the root directory of our theme, at the same level of the index.php and style.css files.
Now, our theme has a better look in the Theme Manager, right?
The next step is to add the rest of the files that we’ll use throughout this tutorial. All these files have their name defined by WordPress:
After creating these files, the directory of our theme must to be like this:
Note that we have just created these files, and are empty. Therefore, they do nothing by themselves. They simply are the files that WordPress will look for depending on each situation. Some of these files, for example the header.php, the footer.php or the sidebar.php, have to be added manually inside other templates.
Great! we already have the needed structure to create a functional theme in WordPress. The last step that we need to do is leave the theme active. It will be a white page, but this way we can start to see all our progresses that we are doing.
You can see the original post in spanish here.
See you at the next post!
When I was fourteen I read a book named “Learning to travel around the Internet”, which had a little HTML introduction in the last two chapters. These twenty-four pages changed my life forever. From that day, I never stopped working and learning about my two vocations, web developing and graphic design. As a front-end developer, I have specialized in Wordpress developing, web architecture and the design at the service of usability.
The post How to create a WordPress theme from scratch (I) appeared first on Marina Mele's site.
To manage this website, I changed from Blogger to WordPress because I wanted to convert my Blog into a Website. I liked the idea to have structured pages where people could navigate through, and at the same time, maintain the Blog in a subfolder.
In this post, I want to share some WordPress plugins I installed for the website, and that helped me obtain the look and feel that I wanted. For example, a plugin for security aspects, like attempts to enter to your admin site, or a plugin for Search Engine Optimization (SEO), which gives you some tips that improve how search engines see your content.
One of the first things you should care about is security. Is anybody trying to access to your WP Admin interface? How can you block them? Is there someone making automated requests to your site?
To manage these issues, you can use a security plugin like iThemes Security, which among other things:
When developing a site, it’s very useful to have a copy in a local environment, e.g. in your computer. This way, you can modify all the files and see the changes automatically, without having to upload them into the server.
Moreover, once you are satisfied with the changes you’ve made, you should upload them into a pre-production environment. This environment should be as similar as possible to the production environment (same server, same kind of database, etc). This way, you can catch some unexpected error before going to production.
One way to move all the WordPress site between your local, pre-production and production environments is to use a plugin like Duplicator. It allows you to duplicate, clone, backup, move and transfer an entire site from one location to another.
If you want to see a detailed description in how you can create a local environment and use Duplicator to move the local WordPress installation into your production environment, check this post.
At some point during the development process, and before the website goes live, you have to work in the production environment (or at least having it active). In these cases, you don’t want that users see the current content of your site, because it’s probably unfinished and with some style issues. However, at the same time you want to inform them that the page is still in working process, using a page with the message Coming Soon or Page under construction.
A similar argument applies when your site is running through some technical issues and you need to stop the user from visiting your site. In this case, you can show him a Maintenance Page to inform about the specific issue, and predict when the site will be active again.
To manage these cases, you can use the plugin Coming Soon Page & Maintenance Mode, which is very easy to implement. Basically, it prevents unregistered users to see the contents of your site by showing them a Coming Soon or a Maintenance page (depending on which you have defined).
At the same time, it allows registered users (like admin, writers, etc) to see both the contents and the admin interface. This way you can still work, develop, and add new content in your site.
Have you heard about SEO? It stands for Search Engine Optimization, and basically it means that you should optimize your posts so that search engines like Google or Bing know what your post talks about. This way, when someone searches for the topic of your post, it will appear amongst the first entries.
This is very, very important. Studies have shown that people clicks on one of the first three results of Google around 60% of the time. And less than 10% of the users clic on a result in the second page of results! So placing your website among the first results can make a difference regarding the amount of traffic to your website!
The WordPress SEO plugin helps you improve the optimization of your posts. It have many functionalities, in particular:
This plugin is a must-have, don’t wait to install it!
The default WordPress Editor lacks from several functionalities that we are used to have in our day-to-day text editor.
The TinyMCE Advanced plugin allows you to add buttons in your editor to control some extra functionalities, like the font family, font size or background color, and at the same time it provides you with buttons to use as a shortcuts of the usual functionalities, like the Formats menu or the horizontal line.
Another useful plugin for your text editor is the Shortcodes Ultimate plugin, which adds a button in your editor to insert a variety of WordPress shortcodes, like spoiler lists, carousel images, audio, etc.
And finally, for those of you who write technical posts like me, I recommend the Crayon Syntax Highlighter plugin.
It adds a small button in your text editor that opens a nice code editor. There, you can select the language of your code (Python, Java, etc) so it will highlight it accordingly. Moreover, there are many options to customize the style of the code snippets, colors, numbered lines, interactivity, etc.
For every post and page of your site, you probably want to add buttons for sharing your content in social media. The Share Buttons plugin lets you do exactly that.
You can choose which social media buttons you want to include, like Google+, Facebook, Twitter or Reddit, and in some cases, even add a share counter.
Moreover, apart from the usual place of the sharing buttons, just after the post title, or at the end of the post, you can have a floating right menu with your buttons. The good thing about this method is that these buttons are visible anytime by the user. To you see them right now on the right of your screen? Sorry for the mobile users, they are hidden for you
Next on the list is the Social Comments plugin. Basically, it allows users to comment and share your posts on any of these social media: Google+, Facebook and Disqus.
For example, if you want to migrate a Blogger Blog into WordPress, I’m sure you would like to maintain your Google+ comments. Yeah, this website is an example for this case too
Finally, in this last section I will talk about the Widget functionality. Widgets are small pieces that customize the look and usability of your site.
Usually, you can place widgets in your sidebar or your footer, but depending on your specific Theme, you may have extra spaces.
WordPress comes with some default widgets to add, like a list of Categories of your posts, a Calendar, or a list of the recent comments. However, you may want to include much more things there!
One plugin I really like is Widget Logic, which as the name suggests, it allows to add some logic into your plugins. For example, you may want to show one widget or another depending on if you’re in a page or in post, or only show a specific widget for a particular post.
Another important widget is the Enhanced Text Widget, which allows you to write HTML, CSS, JavaScript, Flash, Shortcodes or PHP content inside your widget. This might be useful when you want to insert some piece of code in your website, like for example, a MailChimp form.
Next, you can use the Custom Meta Widget to customize the default WordPress Meta Widget. This is the one responsible for showing the login, admin, entry and comment feed. The problem is that in the default Meta Widget you can’t control which links to show, but with this widget you can
And finally, the last widget I will mention here is the BE Subpages Widget. Basically, it allows you to display another menu as a widget. For example, if your theme don’t implement a menu in your sidebar, you can create one and add it using this widget it your sidebar
That’s all!
Do you have other useful widgets that you want to share? Write your comments above!
The post 13 WordPress Plugins to improve your Website appeared first on Marina Mele's site.
