WordPress Francophone

Bonjour,

Même si ta réponse ne me satisfait pas, je te remercie ; d'autant plus que tu as été le seul à essayer de m'aider (alors que la solution est simple).
Les propos qui suivent ne vont pas toujours être très... diplomates, n'y voit aucune animosité; tout au plus de l'agacement par rapport à ce problème à cause duquel j'ai perdu 5 heures.
(pas vraiment perdu puisque ça m'a donné l'occasion d'explorer les entrailles de WP)

viwiv a écrit:

Pour répondre à ta question quasi-philosophique,

Rien de philosophique là-dedans. Je migre un site WordPress d'un endroit à un autre et je remplace donc toutes les occurrences de l'ancienne adresse par la nouvelle.
Faire cela plante le site alors que c'est une opération de maintenance des plus banale.
Je m'interroge donc sur la stabilité de l'outil; rien de philosophique là-dedans (la philosophie s'occupe de questions beaucoup plus importantes).

viwiv a écrit:

il existe plusieurs milliers d'extensions pour WordPress et (presque) autant de développeurs, plus ou moins doués ou scrupuleux, sachant que le code d'origine dans WordPress n'est pas merveilleux non plus, parfois.

J'ai étudié le code de l'extension qui semble poser problème... et je n'y vois rien de sale, elle fait bien appelle aux routines de l'API.

viwiv a écrit:

Autrement posé, l'usage d'un plugin s'effectue aux risques et périls de l'utilisateur.

L'usage de WordPress aussi semble-t-il :-)

viwiv a écrit:

Je pense qu'il vaut mieux éviter le extensions en se posant les questions comment puis-je faire différemment ?

Au risque de réinventer la roue et de perdre en ergonomie ?
Pour le coup, oui je vais faire autrement car le site est pour moi.
Mais pour un client qui demande ce genre de fonctionnalité, j'aurai des scrupules à lui vendre une solution qui posera problème le jour où il changera de domaine.

viwiv a écrit:

est-ce important ?.

Oui, toujours !
L'outil est à mon service, non le contraire.

viwiv a écrit:

Pour en revenir à ta question précise, plutôt que tenter des modifications massives avec une commande radicale, modifie un champ à la main, et regarde si ça fonctionne. Tu gagneras du temps.

1. le commande est radicale car elle doit l'être; lors d'un changement de domaine je ne vois pas pourquoi il devrait rester des traces de l'ancien nom de domaine.
2. je voulais m'éviter de faire du débogage sur une table, wp_options en l'occurrence, qui mélange les options du moteur avec celles des extensions sur plusieurs centaines d'enregistrement en utilisant comme identifiant un varchar(64) (le champ option_id semble alors distinguer les options de même nom).

Mais finalement, je l'ai fait et j'ai trouvé d'où vient le problème.
MyCategoryOrder utilise le champ widget_mycategoryorder pour enregistrer les options de ses widgets.
Sur mon serveur distant la valeur de option_value pour  l'id widget_mycategoryorder est

a:10:{s:5:"count";b:1;s:12:"hierarchical";b:1;s:8:"dropdown";b:0;s:6:"update";b:0;s:10:"hide_empty";b:1;s:8:"feedtext";s:0:"";s:9:"feedimage";s:48:"http://www.piprime.fr/wp-includes/images/rss.png";s:5:"title";s:11:"Catégories";s:7:"include";s:33:"1,231,243,242,241,238,240,239,246";s:7:"exclude";s:0:"";}

il suffit de changer www.piprime.fr en localhost/wordpress pour que le widgets perde la configuration.
C'est évident... les options des « widgets » sont sérialisées et,du coup, il ne faut pas y toucher sans désérialiser.
Malheureusement, Mycategoryorder offre la possibilité de mettre une image personnalisée pour les flus rss, mais cette image doit être adressée de façon absolue. D'où le problème en cas de changement de domaine.

Je vais en parler sur le blog du développeur de Mycategoryorder mais je trouve quand même dommage que la fonction « built-in » start_el(&$output, $category, $depth, $args) définie dans le fichier wp-includes/classes.php à la ligne 1325, contiennent cette ligne de code $link .= "<img src='$feed_image'$alt$title" . ' />';
il serait peut-être judicieux d'effectuer un test pour savoir si $feed_image est relative ou absolue... (allo la lune, ici la base)

viwiv a écrit:

Cordialement,

Tout autant !

Bienvenue dans le code WP

Salut,

piekes a écrit:

Du coup, le développement se fait sous la même adresse que la production, et je n'ai plus qu'à copier le site WP terminé sans aucune manip' supplémentaire. Et normalement, même les vilains plugins ne devraient y voir que du feu.

Attention: les "attachments" contiennent le chemin complet du fichier sur le serveur
(avec le DOCUMENT_ROOT )

Si le DOCUMENT_ROOT change avec le serveur, il faut aussi remplacer toutes ces valeurs pour faire une migration propre...

Apparemment WP2.9 devrait intégrer des nouvelles types de données autres que "post" "page" ou "attachment", peut-être qu'il sera possible d'utiliser cette nouvelle fonctionnalité pour stocker les paramètres des plugins/thèmes ? Ca permettra à l'import/export en WXR d'être plus complet et de ne plus faire ce genre de manip ?

piekes a écrit:

Non, non et RE-NON ! Le but de la solution utilisant une redirection d'adresse sur le serveur local, c'est justement d'avoir strictement les même URL et donc les mêmes chemins complets sur le serveur de développement et sur le serveur de production.

Je ne parle pas des URLs mais des chemins des fichiers uploadés, comme les photos et autres medias.
Pour que WP puisse les supprimer si l'utilisateur veut les supprimer, il faut bien garder un bout de chemin pour le trouver sur le serveur. Mais WP écrit tout le chemin absolu, y inclus le DOCUMENT_ROOT. Et il change souvent d'un serveur à un autre.

Have Fun!

EDIT:
piekes avait raison!
Je viens de retester avec WP2.8.4 et il semble que le chemin soit relatif (au dossier WP_CONTENT ?).
Ca simplifie plus les migrations.

Pour les liens en absolu dans les articles, c'est surement parce que c'est plus simple de les enlever que de les ajouter...
Par exemple, pour faire une newsletter en HTML, on peut intégrer le contenu de l'article tel quel dans le mail et les images s'afficheront correctement.

Dernière modification par LH (17-10-2009 20:11:52)

piekes a écrit:

Jamais eu le moindre problème avec ça. Mais il faut dire que, bien évidemment, je clone la structure du serveur de production sur mon localhost. Comme tout le monde, j'imagine…

Tant mieux pour toi si tu n'as connu les anciennes versions de WP où le chemin absolu était codé
Pour ma part, j'utilise en local Wampserver sur un PC et les chemins étaient donc avec un D:/wamp/blbala...
Alors que le serveur est sous linux... /var/www/blabla ... pas du tout pareil...

Have Fun

piekes a écrit:

Depuis peu, j'utilise une méthode que je trouve nettement plus élégante.
Modification du fichier .hosts sous Windows pour faire pointer l'adresse finale du Wordpress de production sur ma machine locale
Rajout d'une entrée vhost dans le fichier de configuration de mon Apache local

Excellent ! J'adopte ! (en adaptant à Linux).

piekes a écrit:

Pour ma part, j'utilise en local Wampserver sur un PC et les chemins étaient donc avec un D:/wamp/blbala...
Alors que le serveur est sous linux... /var/www/blabla ... pas du tout pareil...

J'ai récemment chercher dans le dump de la base un chemin absolu... j'en ai trouvé deux...
Je ne peux pas en dire plus car ils étaient perdus au milieu de cinq cent milles caractères et j'ai eu la flemme d'approfondir.
C'est pour cela que dans la conf de syncsite pour WordPress il y a un

pre_process_dump_shell_script="sed -i \"s§${remote_baseurl}§${local_baseurl}§g;\
s§${remote_root_dir}§${local_root_dir}§g\""

piekes a écrit:

J'ai lu l'autre jour un article sympa où l'auteur développe ses sites WP avec un Ubuntu server virtualisé sur son poste Windows. Solution élégante que j'ai bien envie d'essayer. Il faudra d'abord que je retrouve la page…

C'est drôle comme idée ça ;-)
Je suis sous Dedian et le Windows virtualisé ne me sers que pour faire des testes de compatibilité...

Salut,

Maintenant, j'utilise pour le serveur de PROD un serveur virtuel en "Front-End" qui fait Cache+Proxy.
Le site de dev est directement sur un serveur "Back-End" et la mise en prod consiste simplement à lier le nom de domaine final à l'URL du site de dev
...Aucune migration de BDD de dev à PROD

C'est effectivement une solution que de faire déterminer le chemin "à la volée" par PHP. Ceci dit, c'est tellement simple de mettre les constantes qui vont bien dans wp-config…

Pour la discussion sur The Gimp… Il reste encore très, très loin de Photoshop, n'en déplaise aux afficionados du Pingouin. Au moins pour un travail de type "pro", les produits Adobe, sous MAC ou Windows, tiennent encore le devant de la scène. Et avec un Wine ou un VirtualBox, les performances ne sont pas vraiment au rendez-vous pour ces softs très, très gourmands en ressources.