Problème (NOUVEAU) d'affichage de la carte sous WordPress

**Duriv73** · 18/09/2014, 19h16

Bonjour à tous,

J'avais réalisé il y a 6 mois environ un brouillon d'article sur mon blog Wordpress où j'avais mis une carte en utilisant l'API Géoportail (en utilisant le plugin "Raw html").
Bon, c'était le bonheur ! J'avais ce que je voulais : Une carte dynamique parfaite.

Je reviens récemment sur mon brouillon, en vue d'intégrer le code dans un article à publier, cette fois. Et oh surprise ! L'affichage ne se fait plus correctement : La carte apparait striée de larges bandes blanches verticales, tandis qu'entre ces bandes blanches, la carte apparait comme "compressée" sur l'axe des X.

Bon, du coup, j'engage un minimum de travail personnel : J'essaie avec un code simplifié à l'extrème, qui a fait ses preuves "hors wordpress" --> même résultat !

J'ai aussi essayé sur un autre article "brouillon" d'en revenir à l'utilisation (abandonnée pour insuffisance de possibilités de "customisation") du plugin "Geoportail Shortcode" : Même résultat : Toujours les mêmes bandes blanches verticales !

Ce n'est donc pas un problème de code html ni de javascript ... Je précise aussi que mon Wordpress a assez de mémoire : Mémoire utilisée 42.95 MB, Mémoire limite : 128 MB. Le problème n'est pas non plus lié au thème : Un changement de thème ne donne pas de meilleur résultat.

Qu'est-ce qui a changé depuis que tout cela fonctionnait normalement ? Je ne voyais rien d'autre que la dernière mise à jour de Wordpress ...
Et bien non, ça n'a rien à voir ! Depuis, j'ai pu refaire un essai avec une ancienne version de WordPress 3.5.1.
Et bien même défaut d'affichage, que ce soit avec le plugin Géoportail Shortcode ou avec du Javascript "classique" (avec plugin Raw Html).

Ne reste donc plus que l'évolution ... de l'API lui même.
Y a-t-il un moyen de faire appel à une version un peu plus ancienne (6 mois environ) de l'API ?

D'autres utilisateurs de l'API Géoportail sous Wordpress ont-ils le même problème ? Quelqu'un aurait-il une idée ? une solution ?

Voiçi le code (le plus simple !) qui fonctionnait AVANT (et qui fonctionne toujours "hors WordPress" en localhost) et qui donne maintenant l'image ci-dessus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
[raw]

<!DOCTYPE html>
<html>
<head>
<title>Essai 02</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
div#viewerContainer {
width:600px;
height:400px
}
h1 {
font-size:25px;
font-weight:bold;
font-family: sans-serif;
}
/*]]>*/--></style>
</head>
<body>
<h1 id="title">Essai 02</h1>
<div id="viewerContainer"></div>
<script type="text/javascript"><!--//--><![CDATA[//><!--
/**
* Property: iViewer
* {<Geoportal.InterfaceViewer>} The Geoportal API viewer interface.
*/
iViewer= null;

/**
* Function: init
* Load the map. Called when "onload" event is fired.
*/
function init() {
iViewer= Geoportal.load(
// map's div id - identifiant de la div de la carte :
"viewerContainer",
// API's keys - clefs API :
["ma clé A JOUR de license gratuite pour l'API Geoportail"],
{
// center in WGS84G - centre en WGS84G
lon:6.800681349904434,
lat:45.521178078454874
},
// zoom level (0-20) - niveau de zooms (0 à 20) :
14,
{ // various options :
loadTheme: function() {
Geoportal.Util.setTheme("geoportal3");
Geoportal.Util.loadCSS("http://api.ign.fr/geoportail/api/js/2.0.3/theme/geoportal3/style.css","__GeoportalBlackCss__","");
if (OpenLayers.Util.alphaHack()) {
Geoportal.Util.loadCSS("http://api.ign.fr/geoportail/api/js/2.0.3/theme/geoportal3/ie6-style.css","__IE6GeoportalBlackCss__","");
}
},
// viewer default controls options overloads :
componentsOptions:{},
// Geoportal's layers to load (when none, all contracts' layers are loaded) :
layers:["GEOGRAPHICALGRIDSYSTEMS.MAPS:WMTS","CADASTRALPARCELS.PARCELS:WMTS","ORTHOIMAGERY.ORTHOPHOTOS:WMTS"],
// Geoportal's layers options :
layersOptions:{"GEOGRAPHICALGRIDSYSTEMS.MAPS:WMTS":{"opacity":0.3,"visibility":true},"CADASTRALPARCELS.PARCELS:WMTS":{"opacity":1,"visibility":false},"ORTHOIMAGERY.ORTHOPHOTOS:WMTS":{"opacity":1,"visibility":true}},
overlays:{},
// callback to use before returning (after centering) :
onView:function() {viewer=iViewer.getViewer();


//Ajout du contrôle d'impression
var nv= viewer.getMap().getControlsByClass("Geoportal.Control.NavToolbar")[0];
nv.addControls([new Geoportal.Control.PrintMap()]);

var measurebar= new Geoportal.Control.MeasureToolbar({
div: OpenLayers.Util.getElement(tbx.id+"_measure"),
displaySystemviewer.getMap().getProjection().getProjName()=="longlat"?"geographic":"metric"),
targetElement: OpenLayers.Util.getElement(tbx.id+"_meares")
});
viewer.getMap().addControl(measurebar);

viewer.getMap().getControlsByClass("Geoportal.Control.MeasureToolbar")[0].controls[2].deactivate;
viewer.getMap().getControlsByClass("Geoportal.Control.MeasureToolbar")[0].controls[2].div.style.display="none";

},
// class of viewer to use :
viewerClass:"Geoportal.Viewer.Default"
}
);
}


window.onload= init;
//--><!]]></script>
<script type="text/javascript" charset="utf-8" src="http://api.ign.fr/geoportail/api/js/latest/GeoportalExtended.js"><!--//--><![CDATA[//><!--
//--><!]]></script>
</body>
</html>

[/raw]

**mga_geo** · 19/09/2014, 07h00

Cela serait beaucoup plus simple pour faire le diagnostic !
Sinon, il faut essayer Mme Irma

**gcebelieu** · 19/09/2014, 08h24

il y a eu une évolution de version de l'API ces derniers mois. Et le code transmis fait appel à :

http://api.ign.fr/geoportail/api/js/latest/GeoportalExtended.js

l'alias "latest" fait automatiquement le changement de version.
Si vous voulez rester sur l'ancienne version, il faut appeler :

http://api.ign.fr/geoportail/api/js/2.0.3/GeoportalExtended.js

**Duriv73** · 19/09/2014, 17h42

Merci 10 millions de fois à Gcebelieu ! J'ai testé un article en modifiant selon ses indications le script d'appel à l'API (v. 2.0.3)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<script type="text/javascript" charset="utf-8" src="http://api.ign.fr/geoportail/api/js/2.0.3/GeoportalExtended.js"><!--//--><![CDATA[//><!--
//--><!]]></script>

... et BINGO ! Çà refonctionne !

CONCLUSION : Jusqu'à la version 2.0.3 de l'API Géoportail, il n'y a pas de pb à l'utiliser sous WordPress.
Avec la nouvelle version de l'API, problèmes de bandes blanches, quelle que soit la méthode que l'on utilise (code Javascript avec lez plugin "Raw-html, ou shortcode avec le plugin "Shortcode Géoportail)

Comme le soulignait mga-geo avec beaucoup de pertinence

, il ne serait pas inutile que je permette aux visiteurs de ce fil d'accéder à des exemples. ET BIEN LES VOICI :
Allez sur mon blog WordPress d'essais divers : http://yvesdurivault.webatu.com/,
puis, DANS LE MENU (et sans vous laisser distraire par le message de la page d'acceuil), sur "Liste complète des articles".
Vous y trouverez les différents essais (avec les fameuses bandes blanches), ainsi que l'essai corrigé qui REFONCTIONNE !

Maintenant, le problème serait : Est-il possible de corriger qq chose pour que la dernière version de l'API Géoportail puisse AUSSI fonctionner sous WordPress ???
Et là, si qq un peut m'aider ... DONC, ATTENTION, les modérateurs : le sujet n'est pas clos !!!

ET UN GRAND MERCI A TOUS CEUX (TOUTES CELLES) QUI ONT PRIS LE TEMPS DE S’INTÉRESSER A CE FIL !

**gcebelieu** · 20/09/2014, 08h44

Maintenant, le problème serait : Est-il possible de corriger qq chose pour que la dernière version de l'API Géoportail puisse AUSSI fonctionner sous WordPress ???

En fait, il faudrait peut-être faire quelque chose pour que le plugin Wordpress puisse AUSSI fonctionner avec la version 2.1 de l'API Géoportail

Ce plugin a été développé par un tiers. Je pense qu'il faudrait continuer cette discussion ici :

http://geo.wp.cephee.fr/forums/forum...ail-shortcode/

**gcebelieu** · 20/09/2014, 08h50

Voilà :

http://geo.wp.cephee.fr/forums/topic...oportail-v2-1/

**mga_geo** · 20/09/2014, 08h50

Sous Firefox 23.0.1 , sur le premier essai, j'ai bien eu les bandes blanches, puis une carte qui fonctionne.
Cependant Firebug trouvait des erreurs différentes.
En essayant d'investiguer plus rien ne fonctionne ...

Sous Chrome, je n'arrive pas à avoir la page qui ne fonctionne pas (http://yvesdurivault.webatu.com/2014...ugin-raw-html/ ) après celle qui fonctionne (http://yvesdurivault.webatu.com/2014...api-ca-marche/).
Sauf si je suis patient ...

Quand ça marche (2.0.3), il y a un échec http 404 sur http://api.ign.fr/geoportail/api/js/...ramedCloud.css

En latest (http://yvesdurivault.webatu.com/2014...ugin-raw-html/ ) , il y a plusieurs erreurs dont
- Resource interpreted as Image but transferred with MIME type test/html: "http://api.ign.fr/geoportail/api/js/2.0.3/theme/geoportal3/img/roam.cur".
- Uncaught ReferenceError: tbx is not defined

**Duriv73** · 20/09/2014, 10h19

1) Pour répondre à gcebelieu :

J'avais bien eu l'idée d'intervenir sur le forum que tu indique (merci au passage pour la contribution que tu y a déposé), mais vu la réactivité qui existe sur ce forum ... (voir les dates des interventions).

Ce serait bien que ce plugin "Shortcode géoportail" re-fonctionne en effet (car il est donc actuellement inopérant depuis la v. 2.1 de l'API comme on le voit dans mon article "Essai 03 ...").
Cela dit, ce plugin n'est pas sans défauts. Pour exemple, si on peut paramétrer l'opacité des couches dans le shortcode, en revanche il n'est pas possible de modifier cette opacité en consultation.

Pour ce qui me concerne, je préfère nettement la solution consistant à coder en javascript (grâce au plugin "Raw-html"), car là on n'est plus limité par les possibilités du plugin. Les possibilités de personnalisation sont énormes (merci au développeurs de l'API Géoportail, à leurs tutoriels, à leurs exemples de code, au générateur de code !). J'avais d'ailleurs développé une petite personnalisation (voir mon article "Essai 02 ...") avec un bouton rouge permettant de réinitialiser la carte à son état initial à l'ouverture de la page (incluant positionnement, niveau de zoom). Ça m'avait demandé pas mal de travail car ma maitrise du javascript est très primaire ; manquant de bases, je procède largement par essais-erreurs en utilisant les ressources offertes par le site de l'API Géoportail. Mais je suis quand même arrivé à mes fins !

En tous cas, il me semble que le but ultime, pour permettre l'utilisation de l'API Géoportail aux utilisateurs de l'univers WordPress, serait de régler le problème à un niveau en amont de celui du plugin "Shortcode Géoportail", pour permettre les 2 possibilités. Cela d'autant plus qu'il me semble bien qu'il s'agit du MEME PROBLEME !

Merci à toi pour tes contributions.

2) Pour répondre à mga_geo :

Tout d'abord, un grand merci pour tes contributions. Pour ma part, j'utilise Firefox. Comme tu l'as sans doute compris, je suis béotien en développement. Je ne m'y colle que pour répondre à un pb particulier (en occurrence, l'inclusion d'une carte personnalisée du Géoportail dans un article de mon blog). Firebug, je m'en suis (un peu) servi pour déboguer du code, régler qq problèmes de CSS, mais bon, ça reste un grand mystère pour moi !

Il faut que je te précise que même du temps d'avant la v. 2.1 de l'API, quand "ça marchait" pour "Essai 02 ..." (ou du moins quand j'avais cette impression

), à l'ouverture de la page, la carte était toute blanche. Il fallait faire un petit "Pan" sur la carte pour la faire apparaitre immédiatement. Après, plus de problèmes. N'ayant pu résoudre ce pb, je m'en étais accommodé bon gré mal gré, en rédigeant un petit mode d'emploi à l'intention des utilisateurs. Pas très élégant, mais bon ... Ce problème est toujours un peu récurrent sur l'Essai 02 ... rendu fonctionnel par l'appel à la v. 2.0.3 de l'API. Plus globalement, je vois bien que tout ça est un peu aléatoire ...

Pour le reste :

Quand ça marche (2.0.3), il y a un échec http 404 sur http://api.ign.fr/geoportail/api/js/...ramedCloud.css

En latest (http://yvesdurivault.webatu.com/2014...ugin-raw-html/ ) , il y a plusieurs erreurs dont
- Resource interpreted as Image but transferred with MIME type test/html: "http://api.ign.fr/geoportail/api/js/2.0.3/theme/geoportal3/img/roam.cur".
- Uncaught ReferenceError: tbx is not defined

... je suis désolé mais je ne peux que prendre acte, incompétent pour en faire quelque chose ! Mais j'espère que d'autre pourront s'en saisir

J'ai quand même l'impression qu'on cerne maintenant assez bien le problème ... qui me dépasse !

**gcebelieu** · 22/09/2014, 09h45

Je viens de jeter un oeil aux pages indiquées (avec Firefox 32) :

la page Essai1 incriminée ne "marche pas" avec le message suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
TypeError: OpenLayers.Protocol.Script.registry.regId1 is not a function
http://wxs.ign.fr/s3kta5imktjaifd1r9kuj2is/autoconf/?output=json&callback=OpenLayers.Protocol.Script.registry.regId1
Line 1

ce qui me laisse penser que les scripts de l'API n'ont pas fini d'être chargés lorsque la carte essaye de s'afficher.

Au passage, j'ai la même erreur sur la page Essai2 qui est sensée marcher.

En regardant le code source de la page généré par Wordpress et le plugin raw HTML, le html est assez peu orthodoxe car on trouve l'intégralité de la page html de l'api (avec ses balises html, body, head) à l'intérieur des mêmes balises (html body head) de la page complète. Je pense qu'il faudrait essayer de ne copier du code de la page API que ce qui est utile (balises scripts, css, div ...) dans l'article, ce qui mettrait plus de chances de ton côté.

Sinon, en extrayant uniquement le code de la page API dans une page vierge, celle-ci s'affiche très bien. Ce qui laisse penser que le problème vient bien de l'intégration de cette page avec le plugin raw html.

En espérant que ça t'aide...

**Duriv73** · 23/09/2014, 19h41

A l'attention de gcbelieu :

Encore tous mes remerciements ! Tu m'as stimulé pour nettoyer mon code. Effectivement, il ne faut pas avoir de <html>, <head> ou autres <style> dans un article sous Wordpress, puisque le contenu de l'article est déjà dans <body>

Je viens donc de corriger mon article "Essai 01 : Simple carte de l’API Géoportail en javascript (plugin Raw-html) – VERSION 2.0.3 de l’API – Ca marche !". Tout propre ! Le CSS dans le fichier CSS de mon thème, plus de <head>, etc ... Ah, ça fait du bien de faire un travail propre ! On est content de soi, après !

Bon, cela dit, l'affichage déconnait pareillement. Pour avoir l'affichage OK, il a fallu que je fasse encore appel à la version 2.0.3 de l'API Géoportail.

N'écoutant que mon courage, j'ai aussi nettoyé de la même façon "Essai 02 avec carte IGN Géoportail (javascript) en Thickbox (plugin Raw-html)", mais dans celui-ci, je conserve l'appel à la dernière version de l'API afin que tout un chacun puisse bien constater ce problème de bandes blanches. (Si la carte ne s'affiche pas, faire un petit "glisser/déplacer" et ça vient tout de suite) ...

Voili, voilou. On n'en sort pas. Le problème de fond est bien un problème entre la version 2.1 de l'API et Wordpress (qq soit sa version).

Et ce problème se pose de la même façon, que l'on code en html + javascript ou que l'on fasse usage du plugin "Shortcode Géoportail" (qui n'est plus opérant tant qu'il ne sera pas corrigé au niveau de l'appel qu'il fait à la dernière version de l'API).

Le monde des utilisateurs de Wordpress n'étant sans doute pas négligeable, il ne serait sans doute pas inutile que les développeurs de l'API Géoportail se soucient de cette NOUVELLE incompatibilité.

Dans l'attente d'une suite ...

**mga_geo** · 23/09/2014, 22h18

http://api.ign.fr/geoportail/api/js/...talExtended.js => http 404
C'est en ligne 257 de http://yvesdurivault.webatu.com/2013...ugin-raw-html/

Il y a peut-être encore du nettoyage à faire ?

**Duriv73** · 23/09/2014, 23h17

J'ai corrigé 1 erreur (" en excédent dans la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<div style="color:white; font-size:12pt; text-align:center">

Bon, il y en a peut-être d'autres ... Moi je ne maitrise pas très bien Firebug ... Je ne prétends pas non plus que mon code soit un exemple de pureté ! (je serais un peu gonflé

)

Par contre, pour le problème des bandes blanches, n'est-ce-pas ...

**mga_geo** · 24/09/2014, 12h39

La poursuite du nettoyage est un préalable ...

**Duriv73** · 25/09/2014, 20h25

... sinon, je me tire une balle !

Bon, sérieusement : Je viens de retirer de mon site d'essais les exemples insatisfaisant (bugs ...) pour ne publier plus que 2 exemples :
- Essai 01 API Géoportail - Appel à dernière version de l'API
- Essai 02 API Géoportail - Appel à l'AVANT-dernière version de l'API (2.0.3)

Dans les 2 exemples, il s'agit de MEME code, celui du projet "Quickstart" proposé par le site de l'API, pour lequel le javascript a été réintégré dans le "body" de la page (sous Wordpress : corps de l'article).

Quelques fonctionnalités supplémentaires ont été ajoutées : Entre autres, le bouton rouge qui réinitialise la carte à son état à l'ouverture de la page (centrage et zoom, mais aussi état des couches : Visibilité et opacité), et le bouton jaune qui centre la carte sur Sartène (Corse).

Comme on le voit, mis à part quelques défauts de CSS (... uniquement sous Wordpress, d'ailleurs, car le code en page html en localhost donne un aspect nickel), le fonctionnement ET L'AFFICHAGE de la carte sont corrects dès lors que l'on fait appel à la version 2.0.3 de l'API

MAIS ... L'AFFICHAGE de la carte est défectueux (bandes blanches et bandes de carte comprimées horizontalement) dès lors que l'on fait appel à la dernière version (2.1) de l'API.

J'ai quand même laissé l'Essai 03 - Simple carte de l'API Géoportail (avec le plugin "Shortcode Géoportail"), article Wordpress dans lequel le code (contenu de "body") se résume à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[geoportail]

... c'est à dire à un Shortcode minimaliste. Donc dans cet exemple, je n'ai pas écrit une seule ligne de code, qu'on se le dise ! C'est du "prêt à porter".
Evidemment, l'affichage de la carte y est lui aussi défectueux, ce qui a du sens au regard du fait que le plugin fait lui aussi appel à la dernière version de l'API (normal, d'ailleurs ...) comme on peut le vérifier en consultant le code source de la page.

Voili voilou ! J'espère que cela permettra à chacun de pouvoir chercher une solution à ce problème. . Ce serait quand même dommage que la communauté des utilisateurs de Wordpress ne puisse pas bénéficier des dernières évolutions de l'API (ainsi que des futures), non ????
(du vert pour l'espoir !

)

Pour ma part, suite aux remarques qui m'ont été faites, j'ai fait le MAXIMUM pour vous offrir un problème "propre" à étudier ! Je vous le dits tout net : Je n'ai pas les compétences pour faire plus !

**gcebelieu** · 26/09/2014, 09h25

Envoyé par Duriv73

Bon, sérieusement : Je viens de retirer de mon site d'essais les exemples insatisfaisant (bugs ...) pour ne publier plus que 2 exemples :
- Essai 01 API Géoportail - Appel à dernière version de l'API
- Essai 02 API Géoportail - Appel à l'AVANT-dernière version de l'API (2.0.3)

...

Pour ma part, suite aux remarques qui m'ont été faites, j'ai fait le MAXIMUM pour vous offrir un problème "propre" à étudier ! Je vous le dits tout net : Je n'ai pas les compétences pour faire plus !

Super boulot : ça permet d'y voir plus clair :

Avec mon firebug, je vois que les tuiles déformées ont une taille exprimée en % (width:256% et height:256%) au lieu de pixels (256px), du coup, la taille n'est plus fixe, mais dépend de la taille des autres éléments de la page, ce qui peut expliquer le pb constaté.

Les versions 2.0 et 2.1 de l'API affichent différemment les tuiles : l'ancienne version mettait une balise <div> qui contenait une balise <img> pour chaque tuile. La nouvelle utilise directement une balise <img> et il peut donc y avoir un changement de comportement si il y a des css extérieures à l'API qui redéfinissent certaines propriétés.

Du coup, si je prends la CSS suivante appliquée à ta page :

http://yvesdurivault.webatu.com/wp-c...asic/style.css

il y a la définition de style suivante pour les images :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
img {
    height: auto;
    max-width: 100%;
}

Je ne sais pas à quoi elle sert et d'où elle vient, mais si j'enlève la propriété max-width: 100%, alors les tuiles s'affichent correctement.

Du coup, si ça n'a pas d'impact sur ton site autrement, tu peux enlever cette propriété des css de ton site pour résoudre le problème. De notre côté, on regardera, comment empêcher cette propriété d'agir sur le comportement de l'API.

Gilles

**jrenard** · 26/09/2014, 10h30

Bonjour,

Suite à la réponse de Gilles, le problème a bien été ciblé. La propriété max-width sur les images provenant des fichiers CSS générées par WordPress sera désormais surchargée et réinitialisée par les fichiers CSS relatifs à l'API Géoportail via le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
img {
    max-width: initial !important;
}

Cette optimisation autorisera l'utilisation de la dernière version de l'API sous WordPress sans aucun problème d'affichage des tuiles. Elle sera intégrée à la prochaine livraison des codes-sources de l'API, dans les prochaines semaines.

Merci pour la remontée d'infos et le travail de débroussaillage qui nous a permis d'identifier et de résoudre rapidement l'anomalie.

**Duriv73** · 28/09/2014, 11h00

Tout d'abord, merci et bravo à Jérémy Renard et Gilles Cébélieu. C'est un bonheur d'avoir affaire et des gens comme vous, messieurs ! En voici une nouvelle confirmation.

Dans le cadre du règlement de l'affaire qui nous occupe, il me faut vous briefer un peu sur la logique de WordPress, et ses conséquences. Là dedans il y aura probablement des choses que vous savez déjà.
Lorsque l'on utilise Wordpress, on lui associe un thème, càd une présentation préconfigurée (quoique largement personnalisable) de son site. Le choix du thème que l'on utilise est susceptible de changer la présentation dans des proportions considérables.
Les concepteurs de thèmes font donc largement appel au CSS pour réaliser ceux-ci, évidement. Pour chaque thème, il y a un fichier CSS dans lequel l'utilisateur peut ajouter ses propres personalisations (il est d'ailleurs préférable pour cela d'utiliser la méthode du "thème-child", qui constitue en quelque sorte une surcouche du "thème-parent", surcouche que l'on va "customiser" sans modifier le thème-parent).

Bon, tout ça pour expliquer à Gilles Cébélieu :

Envoyé par gcebelieu

...
Du coup, si je prends la CSS suivante appliquée à ta page :

http://yvesdurivault.webatu.com/wp-c...asic/style.css

il y a la définition de style suivante pour les images :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
img {
    height: auto;
    max-width: 100%;
}

Je ne sais pas à quoi elle sert et d'où elle vient, mais si j'enlève la propriété max-width: 100%, alors les tuiles s'affichent correctement.

Du coup, si ça n'a pas d'impact sur ton site autrement, tu peux enlever cette propriété des css de ton site pour résoudre le problème. De notre côté, on regardera, comment empêcher cette propriété d'agir sur le comportement de l'API.

Gilles

... que le fichier "style.css" qu'il évoque est celui de mon thème (Basic de Themify), et que le CSS pour l'image vient de là. Basic est un thème "responsive", càd permettant une adaptation de la présentation au (re)dimensionnement de la fenêtre du navigateur. Pratique et élégant, mais cela rend la gestion de la présentation complexe. D'où, j'imagine, cette très large utilisation de la propriété "max-width: 100%;".

Effectivement, en supprimant cette propriété, les tuiles s'affichent correctement !

Maintenant, cette suppression doit logiquement créer quelques soucis sur le comportement de mon WordPress ... certainement la "responsivité" (néologisme de mon crû !), pas encore identifié ... mon site d'essai étant très pauvre en diversité de contenu.

Comme vous pouvez le voir sur le rendu suivant ...

Nom : Sous_Basic.jpg
Affichages : 722
Taille : 188,1 Ko

Nom : Sous_Basic.jpg
Affichages : 722
Taille : 188,1 Ko

... les tuiles s'affichent correctement mais il y a quelques problèmes de CSS, concernant mes bouton rouge et jaune et certains des contrôles de la barre d'information. Voilà encore une conséquence bien gênantes du contenu CSS de mon thème !

Une preuve ? Voici une autre restitution de mon MÊME ARTICLE, en configurant mon site sous le thème "Twenty-eleven" (moins sophistiqué) :

Nom : Sous_Twenty-Eleven.jpg
Affichages : 744
Taille : 114,4 Ko

Nom : Sous_Twenty-Eleven.jpg
Affichages : 744
Taille : 114,4 Ko

Cette fois, mis à part l'affichage des tuiles (pour la même raison : Fichier CSS du thème Twenty-eleven), l'affichage de la carte est quasi impeccable, presque conforme au code et CSS que j'avais développé "hors WordPress" : Les boutons rouge et jaune sont conformes, la barre d'info ... presque (sauf aussi les couleurs des coordonnées du curseur). Le fichier CSS du thème "Twenty-eleven" ne "fout pas trop le b....." cette fois (sauf pour l'affichage des dalles !!!)

Il y a donc un problème assez général lié à la surcharge de CSS par les thèmes employés sous WordPress.

Retour au thème "Basic". En regardant de plus près se qui se passe avec Firebug, on constate que certains contrôles de la carte (par exemple les coordonnées curseur .gpLong, .gpLat, .gpZone) héritent de propriétés imprévues (venant du fichier CSS du thème) comme "background-color", "border-radius", "width", "max-width" ou "padding" venant de CSS du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
input[type="text"], input[type="search"] {
    max-width: 90%;
    width: 240px;
}

... qui mettent un bazar pas possible dans l'affichage.

Il serait donc souhaitables que les objets img ou les controles(là, je ne sais pas si je maitrise assez bien le langage, voire le concept, mais vous comprendrez bien ce que je veux dire ...) employés dans l'API soient dotés d'une caractéristique propre faisant en sorte que les styles qui leurs sont associés ne puissent être surchargés pour des projets n'ayant pas à voir avec la carte (thèmes WordPress ou autres). En d'autres termes, associer à l'objet "img" (par exemple) employé par l'API une identité propre, empêchant la confusion (/l'association) avec tout objet "img" pouvant exister hors de ce contexte ...

Bon, je ne sais même pas si c'est possible, ça, c'est peut-être du délire ! ... et si oui, ça emmène peut-être un peu loin, je le redoute

Donc, dans mon article "Essai 01 PAI Géoportail - Appel à la dernière version de l'API", j'ai réussi à retrouver un affichage correct à grand coup de surcharge des surcharges dans le fichier CSS de mon "Basic-child" ... Ça donne ça (extraits) : (En rouge, les principales surcharges)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
/* ======================================================================== */
/*                     CSS pour l'API Géoportail (début)                    */
/* ======================================================================== */	

    h1 {
        text-align:center;
        font-size:0.75em;
        font-style: italic;
        width:800px;
    }
    div#example_explain {
        margin:0px 0px 10px 0px;
        border: thin solid #595E61;
        width:800px;
        position:relative;
        left:0px;
        top:0px;
        text-align:justify;
        font-size: 0.75em;
        font-style: italic;
        color: #595E61;
    }
    form#gpLangChange {
        border:0px;
        margin:0px;
        padding:0px;
    }
    div#viewerDiv {
        width:800px;
        height:600px;
        background-color:white;
        background-image:url(http://api.ign.fr/geoportail/api/js/2.0.0/theme/geoportal/img/loading.gif);
        background-position:center center;
        background-repeat:no-repeat;
    }
    div#footer {
        font-size:x-small;
        text-align:center;
        width:800px;
    }
    div#footer a, div#footer a:link, div#footer a:visited, div#footer a:hover {
        text-decoration:none;
        color:black;
    }
    div#code a, div#code a:link, div#code a:visited, div#code a:hover {
        text-decoration:none;
        color: #ffffff;
    }
     
    div#code {
        margin:0px 0px 10px 0px;
        width:800px;
        position:relative;
        left:0px;
        top:0px;
        text-align:justify;
        font-size: 0.75em;
        font-style: italic;    
    }

/* ======================================================================== */	

	/* Style pour le bouton de réinitialisation de la carte */

	.olControlZoomOrigItemInactive {
		display: block;
		float: left;
		left: 0px;
		position: relative;
		top: 0;
		background: red;
		border: 1px solid white;
		border-radius: 4px;
		width: 21px !important;
		height: 21px !important;
		padding: 0 0 !important;
	}
	
	/* Style pour le bouton de centrage de la carte sur Sartène */

	.olControlZoomSarteneItemInactive {
		display: block;
		float: left;
		left: 2px;
		position: relative;
		top: 0;
		background: yellow;		
		border: 1px solid white;
		border-radius: 4px;
		width: 21px !important;
		height: 21px !important;
		padding: 0 0 !important;
	}


	/* Style pour régler la largeur du contrôle "Gestionnaire de couches" */
	.gpControlLayerSwitcher.olControlNoSelect.gpMainDivClass {
		width: 200px !important;
	}

		
	/* Style pour régler la hauteur maxi du contrôle "Gestionnaire de couches" */
	.gpGroupDivClass {
		max-height: 270px !important;
	}

	
	/* Style pour supprimer l'affichage de la poubelle dans le gestionnaire de couches (DEBUT) */
		
	.gpControlRemoveLayerItemInactive {
		/* background-image: url("img/picto_layerDrop_off.gif"); */
		background-repeat: no-repeat;
		/* cursor: pointer; */
		position: relative;
		float: left;
		left: 0%;
		top: 0%;
		width: 0px !important; /* Modification de la valeur */
		height: 23px;
		display: none !important; /* Ajout */
	}

	.gpControlLayerOpacityItemInactive {
		background-color: transparent;
		float: left;
		position: relative;
		top: 0%;
		left: 0%;
		width: 75px;
		height: 20px;
		margin-left: 23px !important; /*Ajout*/
	}

	.gpControlRemoveLayerNoneItemInactive {
		cursor: default;
		display: none !important;
		float: left;
		height: 23px;
		left: 0;
		position: relative;
		top: 0;
		width: 0px !important; /* Modification de la valeur */
	}

	/* Style pour supprimer l'affichage de la poubelle dans le gestionnaire de couches (FIN) */
	
	/* ==================================================================== */
	/*       Personnalisation du "skin" de la carte Géoportail (début)      */
	/* ==================================================================== */
	
	/* Panneau inférieur : Texte du contrôle "Echelle graphique" */
	.gpControlGraphicScale {
	    font-family: Verdana,Arial,Helvetica !important;
		color: #a8a8a8 !important;
	}
	
	/* Panneau inférieur : Position du texte de droite du contrôle "Echelle graphique" */	
	.gpControlGraphicScaleText2 {
	    font-family: Verdana,Arial,Helvetica !important;
		float: right !important;
		margin-right: -20px !important;
	}	
	

 



	
	/* Panneau inférieur : Zone déroulante "Type de projection" */	
	.gpSelectProjections {
	    font-family: Verdana,Arial,Helvetica !important;
		background-color: #373737 !important;
		border: thin solid #282828 !important;
		color: #e1e1e1 !important;
		float: left !important;
		font-size: 1.1em !important;
		left: 0 !important;
		margin: 5 !important;
		overflow: hidden !important;
		padding: 0.2em 0.5em !important;
		position: relative !important;
		top: 0 !important;
		width: auto !important;
	}
	
	/* Panneau inférieur : Etiquette "Coordonnées du curseur" */		
	.gpControlMousePosition {
	    font-family: Verdana,Arial,Helvetica !important;
		color: #ffffff !important;
		font-family: sans-serif,"Courier New",Courier,monospace !important;
		font-size: 0.7em !important;
		white-space: nowrap !important;
	}
	
	/* Panneau inférieur : Zones-textes "Coordonnées du curseur" */	
	.gpLong, .gpLat, .gpZone {
	    font-family: Verdana,Arial,Helvetica !important;
		background-color: #373737 !important;
		border: 0 none !important;
		color: #969696 !important;
		font-size: 1em !important;
		font-weight: normal !important;
		margin: 0 0 !important;
		padding: 0.2em 0.5em !important;
		text-align: right !important;
		max-width: none !important;
		width: auto !important;
		border-radius : 0 !important; 
	}
	
	/* Panneau inférieur : Zone déroulante "Unité des coordonnées du curseur" */	
	.gpSelectUnits {
	    font-family: Verdana,Arial,Helvetica !important;
		background-color: #373737 !important;
		border: thin solid #282828 !important;
		color: #e1e1e1 !important;
		font-size: 1em !important;
		left: 2% !important;
		margin: 0 !important;
		overflow: hidden !important;
		padding: 0.2em 0.5em !important;
		position: relative !important;
		top: 0 !important;
	}
	
	
	/* Panneau inférieur : "Copyright IGN" */			
	.gpControlCopyright {
	    font-family: Verdana,Arial,Helvetica !important;
		font-size: 0.8em !important;
		color: #a8a8a8 !important;
	}	

	/* Gestionnaire de couches : Etiquette droite du "Curseur d'opacité de couche" */
	.gpControlLayerOpacityOpacityClass {
	    font-family: Verdana,Arial,Helvetica !important;
		float: left !important;	
		font-size: 1em !important;	
		left: 75% !important;	
		position: absolute !important;	
		top: 0% !important;	
		width: auto !important;	
		color: #a8a8a8 !important;		
	}
	
	/* ==================================================================== */
	/*        Personnalisation du "skin" de la carte Géoportail (fin)       */
	/* ==================================================================== */
	
	
	/* Corrections d'aspect de la fenêtre flottante "Mesure d'azimut" */
	.gpControlFloating {
		background-color: #373737 !important;
		border: 2px solid #2d2d2d !important;
		cursor: default !important;
		float: left !important;
		font-family: Arial,Helvetica,sans-serif !important;
		font-size: 0.8em !important;
		left: 10% !important;
		position: absolute !important;
		top: 10% !important;
		width: auto !important;
	}

	.gpControlFloating .gpControlFloatingBody label, .gpControlFloating .gpControlFloatingBody input, .gpControlFloating .gpControlFloatingBody textarea, .gpControlFloating .gpControlFloatingBody select {
		font-size: 1em !important;
		padding-left: 0.5em !important;
		white-space: nowrap !important;
	}
	
	.gpControlMeasureAzimuthAzimuthInput {
	    background-color: darkgrey !important;
		border: none !important;
		border-radius: 0 !important;
		color: #000000 !important;
		width: 100px !important;
		margin-left: 0.5em !important;
		padding: 0.1em 0 !important;
	}

	span.gpFormSmall {
		font-size: 0.85em !important;
		font-style: italic !important;	
		padding-left: 2em !important;
	}

	img {
    max-width: initial !important;
	}		
/* ======================================================================== */
/*                      CSS pour l'API Géoportail (fin)                     */
/* ======================================================================== */

C'est quand même lourd, tout ça.

Bon, saouler à ce point de braves gens comme vous, ça devrait être passible de prison ! Je plaide donc COUPABLE

, en souhaitant toutefois une EXCELLENTE SEMAINE à TOUS !

Très cordialement.

**jrenard** · 30/09/2014, 09h22

Bonjour,

Pour répondre à cette question :

Il serait donc souhaitables que les objets img ou les controles (là, je ne sais pas si je maitrise assez bien le langage, voire le concept, mais vous comprendrez bien ce que je veux dire ...) employés dans l'API soient dotés d'une caractéristique propre faisant en sorte que les styles qui leurs sont associés ne puissent être surchargés pour des projets n'ayant pas à voir avec la carte (thèmes WordPress ou autres). En d'autres termes, associer à l'objet "img" (par exemple) employé par l'API une identité propre, empêchant la confusion (/l'association) avec tout objet "img" pouvant exister hors de ce contexte ...

Ce n'est en pratique pas possible, puisque pour une image (par exemple) de l'API, on aura beau lui mettre des id ou des class pour la spécifier, elle n'en restera pas moins une image et sa mise en forme CSS sera donc automatiquement surchargée par les propriétés attribuées aux balises img par les CSS de WordPress. On est donc parfois contraints pour les images et contrôles de l'API de resurcharger la surcharge (!) pour attribuer la mise en forme souhaitée, en se basant sur les id et les class des éléments ciblés, et en utilisant le tag !important sur les propriétés CSS qui le nécessitent. C'est d'ailleurs ce que tu as parfaitement fait, et si j'en crois le résultat sur la page http://yvesdurivault.webatu.com/?p=1887, l'affichage est parfait tout en se basant sur la dernière version de l'API

C'est donc bien cette façon de faire qu'il faut utiliser.

Du coup, le sujet peut-il être marqué comme

?

**Duriv73** · 01/10/2014, 09h02

OK, je comprends ! Enfin, je crois avoir compris ...

Si j'ai bien compris, en fait, ce sont les développeurs du thème WordPress qui auraient dû affecter des id ou des class aux objets utilisés dans le thème afin que le CSS prévu pour le thème n'affecte QUE ces objets précis, et NON PAS l'ensemble des objets "parents". Ainsi, par exemple, le CSS du thème affecterait les balises img du thème et non pas TOUTES les balises img et donc pas les balises img de l'API Géoportail.

Par contre, ce que je ne comprends pas dans la réponse de Jérémy Renard :

Envoyé par jrenard

Bonjour,

Suite à la réponse de Gilles, le problème a bien été ciblé. La propriété max-width sur les images provenant des fichiers CSS générées par WordPress sera désormais surchargée et réinitialisée par les fichiers CSS relatifs à l'API Géoportail via le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
img {
    max-width: initial !important;
}

Cette optimisation autorisera l'utilisation de la dernière version de l'API sous WordPress sans aucun problème d'affichage des tuiles. Elle sera intégrée à la prochaine livraison des codes-sources de l'API, dans les prochaines semaines.

Merci pour la remontée d'infos et le travail de débroussaillage qui nous a permis d'identifier et de résoudre rapidement l'anomalie.

... c'est pourquoi les développeurs de l'API ne mettent pas une id ou class sur la balise img employée dans l'API ... (celle qui pose problème en l'occurence).

Mais bon, ce n'est pas parce que je ne comprends pas, n'est-ce-pas, que ce n'est pas OK !

Bon, en tous cas, merci mille fois à Gilles Cébélieu et à Jérémy Renard !

PS : Dès que vous me répondez ez sur ces 2 derniers points, je mets "Résolu" !

**jrenard** · 01/10/2014, 13h07

Bonjour,

Envoyé par Duriv73

Si j'ai bien compris, en fait, ce sont les développeurs du thème WordPress qui auraient dû affecter des id ou des class aux objets utilisés dans le thème afin que le CSS prévu pour le thème n'affecte QUE ces objets précis, et NON PAS l'ensemble des objets "parents". Ainsi, par exemple, le CSS du thème affecterait les balises img du thème et non pas TOUTES les balises img et donc pas les balises img de l'API Géoportail.

C'est une façon de voir les choses, mais je pense que la philosophie qui dicte les CSS de WordPress est de prendre en compte tous les objets sans exception pour assurer une mise en forme générale cohérente, et notamment l'aspect Responsive (=adaptation des pages à toute dimension de terminal) des pages. Ce n'est pas une mauvaise idée, cela garantit l'unité des CSS sur la page, après si des cas particuliers apparaissent comme c'est le cas ici pour l'API, à charge aux utilisateurs de re-surcharger les CSS qui vont bien. Donc sur le coup, WordPress n'est pas plus à blâmer que le code l'API, ils ne peuvent pas anticiper tous les cas particuliers qui se rencontreront au chargement d'outils externes.

Envoyé par Duriv73

... c'est pourquoi les développeurs de l'API ne mettent pas une id ou class sur la balise img employée dans l'API ... (celle qui pose problème en l'occurence).

La plupart des images (ou autres objets) construits par l'API ont bien des id ou des noms de classe, ils peuvent être attaqués directement. Par exemple les tuiles cartographiques de l'API sont des img de class olTileImage. Mais la largeur attribuée à ces images résulte d'un calcul effectué à un niveau plus haut, donc chercher à modifier directement les largeur de cette classe d'image pour résoudre le problème initial ne menait à rien. En revanche, si on veut cibler toutes les images employées dans l'API sans influer sur les autres images existant sur la page en-dehors de l'API, une bonne solution peut être d'utiliser une imbrication de balise en pointant le fait que tout ce qui est créé par l'API se trouve dans un bloc dont l'id est viewerDiv :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part