Combien de temps cela prend-il de téléchargement ftp pour qu'elle présente http?
Petite question; j'ai remplacé un .fichier css qui j'étais référencer en html/php qui a une adresse absolue de : http:/www.[mon idiot de domaine].com/css/div_image_container.css.
Quand j'y accéder directement, il me donne une version antérieure d'un fichier que j'ai téléchargé sur le ftp de la structure.
Cependant, dans ma page principale, à l'aide d'une relative en fonction du répertoire, par exemple:
<?php
if (condition true){
print("<link rel=\"stylesheet\" type=\"text/css\"
href=\"/css/div_image_container.css\"
MEDIA=screen />");
}
Il 'magie' utilise le bon, mis à jour le script. Qu'est-ce que cela? Est-il un peu de retard entre le moment où j'upload via ftp et quand ma page est "servie " correctement"?
Je suis à l'aide de fatcow, et ils l'utilisation de sftp, qui ne compte pas.
Je suis juste confus. Quand j'ai accès au fichier par ftp, c'est la bonne.
Attendez une minute, laissez-moi réfléchir. FZ a une url de la copie chose. Quand je copie l'url, ça donne quelque chose dans la forme de
ftp://[nom de domaine]@ftp.[nom de domaine].com/css/div_image_container.css
Quand je référence les choses en html sans un http://, c'est en quelque sorte toujours de l'exécution d'un ftp? Mais chaque utilisateur sur la planète et au-delà besoin des informations d'identification, ou à tout le moins de privilèges de lecture.
Toute façon ça fait+ de 30 minutes et l'adresse http://pour que le fichier css contient toujours le mauvais code.
Il y a clairement une sorte de séparation entre ftp, http, évidente dans le nom, mais c'est la première fois que mon hypothèse selon laquelle un upload via ftp est reflété dans le temps, presque de manière équivalente dans "récupération" par le biais de http a été ébranlée.
- Je vais supposer que vous avez essayé de vider votre cache navigateur.. êtes-vous sûr que vous avez télécharger au bon endroit sur le serveur, ou même le bon serveur?
- Oui Ben, haha, mais je vais revérifier juste pour vous. Je suppose que l'erreur humaine et l'hypothèse est d'autant plus probable ici.
Vous devez vous connecter pour publier un commentaire.
il doit être immédiate.
ajouter une chaîne de requête par exemple
http://example.com/?345678
et il va empêcher la mise en cache,
vérifiez que vous téléchargez à la bonne place,
à défaut de parler à votre fournisseur de
Vous êtes très probablement en cours d'exécution dans un problème de mise en cache. Il est typique pour les ressources pour être mis en cache et servi de cache pour une certaine période de temps avant d'être récupérés à nouveau à partir de la source originale. Ceci est fait dans le but de réduire l'utilisateur final de latence (si il est mis en cache localement, il est beaucoup plus rapide que de passer par une série de sauts, et si il est mis en cache à un saut loin, c'est encore plus rapide que de sortir trois sauts pour l'obtenir).
C'est effectivement une bonne chose en termes d'accélération des applications web, et si vous n'avez jamais modifier un fichier, vous pouvez même définir l'expiration de la mémoire cache à jamais, de sorte qu'il sera toujours servi de cache. Afin de forcer la ressource à récupérer, vous pouvez définir la politique de mise en cache pour ne jamais mettre en cache le fichier (ou une très petite quantité); cependant, qui ont un temps de latence de l'impact sur les utilisateurs. Une alternative, ce qui vous donne le meilleur des deux mondes, et de ne jamais modifier la ressource à tous, définir la stratégie de cache à cache indéfiniment, ajouter une signature unique sur le nom de votre ressource que vous utilisez pour la gestion des versions, télécharger votre nouveau fichier CSS avec une signature différente, et ensuite modifier votre fichier PHP pour pointer vers le fichier CSS avec la nouvelle signature. Le changement dans le nom de la ressource force de la ressource extraite (puisque le nom diffère de celui qui a été mis en cache), mais le cache "pour toujours" de la politique fera suite à la rapidité de chargement.
D'accord avec la mise en cache de problème.
Un rapide et sale solution est de supprimer l'appel de script php (et parfois liés à des fichiers), l'appel de l'url de votre navigateur (en forçant un erreur 404), puis re-télécharger le fichier de script. Il devrait alors être frais.
Je suis aussi convaincu que c'est un problème de mise en cache. Une méthode simple pour empêcher la mise en cache est d'ajouter un paramètre unique sur votre CSS nom de fichier à chaque fois. Vous pouvez faire une base prévisible et unique paramètre comme ceci:
Cela aura pour effet d'ajouter un timestamp Unix pour le CSS nom de fichier en paramètre, en donnant un nouveau paramètre à chaque seconde. Tant que vous ne charge pas la page plus souvent que cela, votre navigateur n'est pas de frapper la cache quand il charge la feuille de style.
Je sais que c'est un vieux thread, mais je suis tombé sur ça quand j'étais confronté à un problème similaire et pensais que mon info peut aider quelqu'un d'autre:
De mon fatcow ticket de support:
"Merci de nous contacter.
Il semble être d'un problème avec le vernis se cache depuis que nous utilisons des Vernis technologie de mise en Cache sur notre serveur. La valeur par défaut de Vernis Cache le temps limite est de la configuration que 4 heures sur nos serveurs. Ainsi, votre site web ne peut pas afficher les changements immédiatement. Pour la meilleure performance, j'ai désactivé le cache à: https://www.fatcow.com/controlpanel/cachecontrol/ . "
Je tiens à ajouter que j'ai juste eu la même expérience et il était clairement dû au serveur de mise en cache.
J'ai édité un attribut sur ma feuille de style manuellement via FileZilla, puis enregistré. Quand je suis allé à la réalité de vivre la page, rien n'a changé. Même quand j'ai rafraîchi la connexion FTP et regardé le dossier, confirmant l'attribut a été de 100% là, la page a été rendu à l'ancien fichier de sortie. Il vient de n'était pas qui se reflète sur le site en direct.
Ensuite: Trois heures plus tard, je suis revenu sur le site, et voilà, l'élément de la page, j'ai ajouté l'attribut a changé.
Je ne suis pas un professionnel (encore), donc je ne peux pas donner beaucoup de détails dans ma réponse. Cependant, ma source est le spécialiste qui est de la formation m'a/m'aider à régler notre site web. Il a noté plus tôt dans le processus que notre fournisseur d'hébergement semble avoir très agressif de la mise en cache. Je ne peux que supposer que c'est la réponse pour le retard dans la mise à jour de mon fichier.