Jump to content

xpatval

Hubmaster
  • Content Count

    1372
  • Joined

  • Last visited

Everything posted by xpatval

  1. Merci de ta réponse. Rien à ajouter concernant l'autorisation d'utiliser une photo (une oeuvre), tu as entièrement raison. Celle-ci (la photo) a été copié sur GG, et est toujours visible agrémentant des sites de grosses sociétés d'information (je suppose donc qu'ils ont payé une licence). La société suisse travaille au nom de l'AFP (mandatée, donc). Pour l'entête, je n'ai qu'un transfert de mail, puis-je malgré tout voir quelque chose de particulier? Non, le client 'a rien payé du tout (sur conseil de son avocat), car il n'y a pas condamnation pour le moment. Seuls 2 mails, à quelques mois d'écart, ont été émis par la boîte suisse puis maintenant une lettre en AR d'un cabinet d'avocats, basé en France. Quant au dossier, il n'y en a pas à proprement parlé pour le moment, seuls existent ces mails, des captures d'écran,, en attendant de savoir comment réagir face à ce problème... Je continue de me renseigner sur cette société suisse, et sur leurs méthodes...(D'ailleurs, j'ai un gros doute, ce pourrait fort bien être une belle arnaque...)
  2. Bonjour, Une société (cliente) m'a fréquemment demandé d'ajouter/remplacer certaines photos de son site, en me les fournissant. La plupart de celles-ci sont achetées donc utilisables sans souci, sauf une, dégotée je ne sais où, et qui a posé problème. En effet, ce client a reçu d'une société suisse apparemment mandatée (par l'AFP, notamment) un mail réclamant d'office la modique somme de 1200 euros, pour utilisation sans autorisation d'un cliché, et enjoignant son retrait, ce qui a été fait. La société cliente vient maintenant de recevoir un courrier en A/R d'un cabinet d'avocats français, afin qu'elle règle le montant demandée. Avez-vous été déjà confrontés à pareille situation ? Merci de vos retours
  3. Bon, il semblerait que l'extension .dev soit aussi la raison de mon problème post migration D7-D8 de mon site mulitilingue. Après avoir recommencé avec une extension commune (.fr), et indiqué seulement une url (pour le moment) dans le trusted_host_patterns, puis modifié l'url des différentes langues dans l'admin, je n'ai pour le moment plus le problème tel que cité dans mon premier post. Alléluia.... ?
  4. Heu...Comment dire, suis-je vraiment c.. ? Ah oui. C'est un site multilingue (ce que je n'avais pas précisé). Les urls relatives aux différentes langues sont en dur, dans la table language. Suffit d'y penser, ce qui m'a pris 3 jours. Puis suffit de les modifier, et ça roule. Merci à vous
  5. Merci de ta réponse. (j'indiquais default uniquement pour énoncer l'ensemble de mes manips pour la duplication) $base_url est déjà renseigné, pas de changement. dans file-system, je n'ai qu'un chemin vers les fichiers publics: sites/default/files Les caches sont invariablement vidés après chaque tentative de résolution de ce problème. En fait, les liens corrects sont ceux des contenus de pages toutes simples, 'codés' en url relative. Ceux qui dirigent vers site1 sont les liens de menu (superfish), et de contenus utilisés dans des vues/blocks.
  6. Ne fait-il pas être sous linux pour cela ? Ce qui n'est pas mon cas
  7. Salut Dan, Non, pas de possibilité de modifier l'url 'générique' dans l'admin. Je penche plus pour une donnée importée lors de la restore de la base de données, mais quelle table...? Je fouille....
  8. Bonjour, Je m'explique: pour différents test, j'ai copié un site local D7 (site1.com) sur un autre D7 (site2.com) (versions identiques, 7.58). Après install à nu de site2, j'ai copié les fichiers de site/all et site/default (sans le setting.php) de site1 vers site2, puis sauvegarde de la base site1 et restore sur site2, avec les fichiers cache et sessions vides. Le blème, c'est qu'un paquet de liens internes de site2 pointent vers site1 ! Or, je ne trouve rien dans les .htaccess redirigeant vers site1, et setting.php est bien configuré pour taper dans la base de site2. Qu'ai-je oublié, ou où et que dois-je modifier pour retrouver mes petits ? Merci de vos réponses
  9. Comme j'ai eu une bonne déconvenue concernant quelques projets, en local, parce que le leur collais l'extension .dev (problème posté dans le salon, et résolu, merci Dan...), et comme cette migration D7 vers D8 concernait des .dev, je retenterai plus tard avec une extension acceptée par wamp, et vous dirai si ce problème de trusted_host _patterns venait de là...
  10. Naaaaaaaaaaaaaaaaan ! Pfff Effectivement, tu as entièrement raison ! Je viens de modifier l'extension, et cela fonctionne de nouveau. Un grand merci à toi, car là, j'aurais continué de galérer pendant...longtemps. Par contre, pourquoi le .dev (avec wamp) sur IE et safari ne bascule pas en https...?
  11. Rien de précisé spécifiquement dans l'admin Drupal, la page d'accueil par défaut est bien en http... J'ai vidé cache & cookies dans les navigateurs incriminés, rien à faire ! Dans la barre d'adresse, si je tape http://monsite.dev, il passe automatiquement en https://monsite.dev
  12. Alors, effectivement, lorsque je dis le PC plante, j'aurais du dire "puis le PC a planté", je l'ai donc redémarré. Et depuis, j'ai ce problème. Par contre, par back-office du navigateur, tu entends "paramétrage" ? Comment puis-je voir l'url par ce biais ?
  13. Il y a une condition concernant le https, mais que je n'utilise pas. En fait, je n'ai absolument pas modifié le htaccess, il est tel que depuis l'install de drupal, il y a déjà quelques semaines. J'ai, aussi, installé (migré) une nouvelle version de wamp hier, sans et avec changement de port. Nada ! J'ai vérifié dans la paramètres des navigateurs concernés si, par un grand hasard, et du au plantage PC, un proxy avait été initié. Non plus. Bref, je ne vois pas.
  14. (A déplacer dans le bon sous-forum si besoin...) Bonjour, Le problème: en local, je bosse sur un site en développement (drupal sous wamp). Mon PC plante. Depuis, je ne peux plus l'ouvrir sous FF, sous Opera ni sous Chrome. Seuls IE et Safari le font. Le détail qui tue, c'est que les navigateurs incriminés tentent d'ouvrir ce site en mode sécurisé, alors qu'il n'est pas du tout défini comme tel (https au lieu de http), d'où une connexion refusée. Que dois-je modifier, et où pour résoudre cela, sachant que c'est du virtualhost, et que je ne passe pas par proxy ? Merci de vos réponses.
  15. Bon, j'ai essayé cela, dans le setting.php (où j'ai gardé le code donné en exemple dans ce même fichier, et non repris pleinement le tien): $settings['trusted_host_patterns'] = array( '^th\.dev$'); Quand bien même c'est un tableau à 1 seule entrée, je ne vois pas le souci, mais je peux me tromper. th.dev étant l'url en local, D7. Le résultat est; The provided host name is not valid for this server. Voici l'un des liens dans drupal.org qui justifierait la "résoluton"....; https://www.drupal.org/project/domain/issues/2863184 En tout cas, merci de ta réaction/réponse xpatval
  16. Bonjour, Comme indiqué dans le titre, la migration de D7 vers D8 s'est déroulée correctement, à ceci près: tous les liens internes du site en D8 pointent vers le site en D7, et ce message d'erreur apparaît (le site est multilangues): Bien que documentée sur Drupal.org, je ne pige pas vraiment quelle modif est à effectuer pour palier à cette erreur (l’ajout d'un bout de code dans le setting.php ne l'élimine pas). Un adepte de Drupal peut-il m'aider ? Je précise que le tout est en local, fort heureusement. Merci de vos réponses
  17. Merci de ta réponse. Je suis un peu étonné du résultat: à l'origine, j'avais dans le container parent un background-color: #333; suivi d'un opacity:0.8; . Le container fils était lui aussi opacifié (ce que je ne voulais pas, d'où ma question ici). Le simple fait de changer le #333 en rgba(51,51,51,0.8) me permet d'arriver au résultat escompté ! Pourquoi ?
  18. Bonjour, Bon, titre bizarre... En fait, mon problème est le suivant: j'ai un container, avec une opacité (css) de 0.8. Celui-ci contient d'autres containers, pour lesquels je ne veux pas d'opacité (des images, notamment). Or, malgré un test avec opacity à 1 (toujours css, et dans ces "sous-containers"), je n'obtiens rien de plus. Comment dois-je m'y prendre ? Dois-je jouer avec des z-index ? Merci de vos réponses
  19. Bonjour, Comme dit dans le titre, c'est le problème que je rencontre, en local sous wamp, sur une table innoDb d'une base Drupal. Le pourquoi de la corruption de cette table m'est inconnue. En fait, depuis quelques jours, le service mysql stoppe, avec ce message dans le fichier log: " Error: tablespace id is 312 in the data dictionary but in file .\xxx\cache_admin_menu.ibd it is 310! Assertion failure in thread 8184 in file fil0fil.cc line 796." Lorsque je tente de visualiser la table en question qui est bien listée dans phpmyadmin,, un message d'erreur m'indique que celle-ci n'existe pas ! C'est une table de cache du back-end. j'ai supprimé celle-ci, mais ne peut la recréer (la restaurer en fait) car je dois supprimer aussi le tablespace (DROP TABLESPACE 'matable';). Tentant la chose, je me retrouve avec une erreur mysql 1478 ( Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP' ). Et là, je suis dans le flou quand aux possibles solutions. Vous est-il un jour arrivé ce genre de problème, et si oui, comment l'avez-vous résolu ? je suis sous wamp 2.5, mysql 5.6.17
  20. Ok, merci. Donc, la simple manip est d'ajouter une redirection, dans l'administration de son hébergeur, du nouveau ndd vers le ndd du site voulu, si je comprends bien ?
  21. Bonjour, Telle est la question d'un client. Acheter plusieurs noms de domaines au titre évocateur, et les rediriger vers celui pour lequel le site est présent est-il pertinent, de nos jours, ou au contraire discriminant pour une meilleure indexation dans les moteurs de recherches ? J'avoue ne plus être trop au courant concernant ces méthodes... Merci de vos réponses, xpatval
  22. Pfff....Ma mémoire, ma mémoire... Un grand merci à toi.
×
×
  • Create New...