Eric (Créer un compte)

Si le template fournit un module de login et que celui-ci ne fonctionne plus, il y a toujours le formulaire de base de wordpress, atteignable par nom-de-domaine/wp-login qui fournit une option de récupération de mot de passe via un lien. Ce formulaire est facilement reconnaissable par son gros W wordpress.
Si c’ est celui-là qui pose problème, alors je n’ ai pas de réponse.

J’ ai une installation « en double », localhost et en ligne.
Et je n’ ai aucun problème avec les downloads de ma base de données en ligne. Enfin presque. Mais ma procédure n’ est pas la même.

Pour ce faire, il faut d’ abord créer en local une installation de wp vierge. Ensuite y installer le thème et les plugins qui sont en ligne. Ensuite, dans l’ admin, il y a un onglet « outils » qui permettent des exportations et importations. Je vais donc en ligne et depuis cet outil, je récupère toutes, enfin presque toutes les données de la base de données. Ensuite, en local, via le même onglet, j’ active l’ outil uploader dans wordpress ( c’ est un simple plugin qui va s’ installer automatiquement). Je récupère le fichier xml (si mes souvenirs sont bons) et l’ upload. Il me demande à quel utilisateur les articles doivent être attribués et lance la moulinette.
Peu de temps après tu constateras que tes articles en ligne se retrouvent dans ton installation en local, sans avoir le problème d’ adressage que tu as rencontré.

Cette procédure a un gros avantage: celui de travailler « dans le relatif » et donc de ne pas récupérer des adresses absolues. Mais elle a aussi un gros inconvénient: celui de ne pas récupérer l’ entièreté de la base de données. Les tables ajoutées par des plugins ne sont pas récupérées ainsi que d’ autres choses plus basiques, par exemple les attachments.
J’ ai également parfois dû faire des ajustements du côté des menus.

Mais, de mon point de vue, un site en local n’ est en fait qu’ un simulacre permettant de faire des test lorsqu’ on décide de modifier tel ou tel point et, donc se suffirait d’ un simple « lorem ipsum ».

une fois que tu as reçu les infos de ton hébergeur, c’ est-à dire le mot de passe de ta base de donnée, lui ayant donné un nom lors sa création, tu dois lancer le script install.php situé dans wp-admin. En principe, lorsque tu lances wordpress pour la première fois, il ira chercher ce fichier qui te guidera à travers le processus d’ installation et donc la définition des données d’ accès à la base de données. Sinon tu lance l’ adresse: nom-domaine/wp-admin/install.php et tu n’ auras plus qu’ à répondre aux questions.
Je ne conseille pas de recréer un fichier config.php à partir du fichier « sample » existant, à moins d’ être familier avec wordpress.
Si tu n’ es pas sûre de toi, réalise une installation en local, pour voir comment cela marche. Ce qui, devrait être fait de toute manière, ne fût-ce que pour pouvoir tester les modifications avant de les mettre en ligne.

Pour ceux que cela pourrait intéresser, j’ ai repris le codage de zéro en me basant sur le 20-12 et mes problèmes ont disparu comme par enchantement.
Je sais que cela ne consolera pas celui qui a initié le fil, mais c’ est effectivement la preuve qu’ un problème dans le codage du thème peut influer sur l’ admin

Je viens de voir ta question, ta source de problème et la raison pour laquelle le problème a été résolu.
Et cela me semble bien compliqué.
En fait ma solution a été de créer un template de page « maintenance », d’ ajouter via l’ admin une page « maintenance » et d’ ajouter dans le fichier fonctions le code ci-dessous.

function mode_maintenance() {

	if ( !is_user_logged_in() || !current_user_can(‘administrator’))
	{ 
		$location= site_url().’/maintenance’;
		wp_redirect($location);
                exit;
	}

}
//add_action(‘get_header’,’mode_maintenance’);

Et pour initier le mode maintenance, je dé-commente la ligne add_action().
Ce n’ est peut-être pas très élégant, mais cela marche. Et me paraît plus simple que ce qui figure dans le lien.

Désolé, j’ ai été tellement surpris de voir quelqu’ un décrire mon problème que j’ en ai oublié ce « détail ». Mon site n’ utilise pas d’ ajax parce que suis encore à apprendre à m’ en servir.

Par contre, et ceux qui ont déjà eu affaire à moi le savent, j’ ai une très forte tendance à coder « à la sauvage », tant que cela marche c’ est toujours bon. J’ utilise quelques scripts JQuery extrêment mal mis en places dans wordpress puisque je me suis contenté du balisage standard, sans usage du « endqueue ».

Et il me semble que mon collègue a relevé ce problème (?)

Je devais faire une remise en ordre de mon code dans les prochains mois, mais je sens que je vais le faire en urgence, rien que pour vérifier.

Cependant, une question reste: est-ce qu’ un thème mal codé peut influer sur la back-end?, au point de perturber l’ interface d’ upload de photos?