The center for all Wikitravel images!

Tech:Cache not clearing after editing

From Wikitravel Shared
Jump to: navigation, search

Wikitravel was moved to new servers in September 2008, here we shall discuss and fix any bugs that resulted...

Please start a new section below for each bug that is encountered.

Cache not clearing when editing a page[edit]

So far, every page I edit (including talk pages) doesn't reflect the changes I make to it unless I manually clear the cache afterwards. Editing a page should automatically clear the cache for that page, as it used to do – cacahuate talk 15:01, 25 September 2008 (EDT)

I misunderstood the one rather cryptic line on a Mediawiki config parameter so the urls being sent to Squid to be purged were wrong. That should be now fixed (I would have sworn I checked that was working at some point). KevinSours 16:59, 25 September 2008 (EDT)
I'm still getting something very similar today...? Jpatokal 11:47, 28 September 2008 (EDT)
This seems to go beyond just clearing the cache now, pages which I viewed the current version of yesterday are sometimes showing older versions today, like en:Mandarmoni, which I was the last to edit, and viewed the current version of yesterday. I purged cache again and can now see newest version, but strange that it would jump back again – cacahuate talk 16:29, 29 September 2008 (EDT)
en:Mandarmoni is a redirect to en:Mandarmani. The cache is handled by url so each of those urls has its own Squid cache entry. Unless mediawiki does something special to handle redirects, then editing en:Mandarmani will not clear the entry for en:Mandarmoni. I'll need to find some time to look into how mediawiki handles squid purges -- I was working on the assumption that MW would do the right thing.
As for the jump back and forth behavior. There are two webservers each of which has a cache. Trying to provide a common cache for multiple webservers is what doomed the initial attempt to load balance back in January. In theory every edit/change should trigger a purge request to both webservers, but if that doesn't happen it possible for the caches to get out of sync and show the behavior that you describe. Squid also requests the no-cache pragma (control-refresh on most browsers), but that will only clear the cache that you are currently hitting. A purge action should clear all caches, but I haven't totally verified that against the code yet. KevinSours 16:20, 30 September 2008 (EDT)

Saint Petersburg is invisible[edit]

Despite showing a robust 106,599 bytes in the history, the Saint Petersburg article in Russian no longer displays anything. All versions in the history also do not display anything. Purging the cache does not help. It's one of the best articles on the Russian version, so this is a significant problem. Do others have the same problem? --Peter Talk 12:43, 29 September 2008 (EDT)

I see only TOC of article, without any content. The server reply is strange. It started with:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" xml:lang="ru" lang="ru" dir="ltr">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <meta name="description" content="Санкт-Петербург находится на северо-западе России.
<br clear="all"/>
<br clear="both"/>
{{Инфо|width=auto|«Что было — то и будет»<br/>(слова Б.&nbsp;Ахмадулиной<br/>на&nbsp;музыку Е.&nbsp;Крылатова)|
Не знаю я, известно ль вам,<br/>
Что я певец прекрасных дам,<br/>
Но с ними я изнемогал от скуки...<br/>
А этот город мной любим,<br/>
За то, что мне не скучно с ним.<br/>
Не дай мне Бог, не дай мне Бог,<br/>
Не дай мне Бог разлуки...<br/><br/>

Не знаю я, известно ль вам,<br/>
Что я бродил по городам,<br/>
И не имел пристанища и крова...<br/>
Но возвращался, как домой,<br/>
В простор меж небом и Невой.<br/>
Не дай мне Бог, не дай мне Бог,<br/>
Не дай мне Бог иного...<br/><br/>

Не знаю я, известно ль вам,<br/>
Что я в беде не унывал,<br/>
Но иногда мои влажнели веки,<br/>
Я этим городом храним,<br/>
И провиниться перед ним<br/>
Не дай мне Бог, не дай мне Бог,<br/>
Не дай мне Бог вовеки...}}" />
		<meta name="keywords" lang="ru" content="Армения,Архангельск,Архангельская область,
Белоруссия,Берлин,Болгария,Ленинград,Ленинградская область,Петербург,Петроград,Питер,Россия,
Санкт-Петербург,Северо-запад России,вики,википутешествие,
гостиницы,путеводитель,путешествие,путешетсвие,рестораны,туризм" />
The trimmed article's content is in meta "description"!?. Here is place for article content:
          <!-- start content -->
          <script type='text/javascript'>
messages= new cListingMessages({'tag-eat':'Еда', 
'tag-drink':'Ночная жизнь', 
'tag-do':'Чем заняться', 
'tag-sleep':'Где остановиться', 
'attr-alt':'альтернативное наименование', 
'attr-directions':'дополнительные указания', 
'attr-email':'электронная почта', 
'attr-tollfree':'toll free', 
'attr-hours':'часы работы', 
Pre-expand include size: 113346 bytes
Post-expand include size: 21906 bytes
Template argument size: 11997 bytes
Maximum: 2097152 bytes
Last page's change is 09:52, 22 September 2008 (this is before server hardware upgrade). -- Sergey kudryavtsev 13:49, 29 September 2008 (EDT)
Another fact, i can see one of previous version [1] (12:23, 17 April 2008, 79 353 bytes). Is this question of amount bytes? -- Sergey kudryavtsev 13:58, 29 September 2008 (EDT)

It appears to be back. If I had to hazard a guess its related to the shell memory limit I bumped up earlier. Let me know if it continues to be a problem KevinSours 17:24, 29 September 2008 (EDT)

For now а text content appeared, but there is new bug: All embedded images now appeared as image link (at shared too). E.g. see:

Church of the Saviour on the Blood at Night, St. Petersburg, Russia.jpg

At image pages appeared a thick black rectangle, quasi image is missing. It's possible this is related with a situation reported in "Thumbnail shows up as gray box" our pub's section. -- Sergey kudryavtsev 01:49, 30 September 2008 (EDT)

The bug comes back[edit]

Today ru:Санкт-Петербург is invisible again. :-(( -- Sergey kudryavtsev 04:58, 1 October 2008 (EDT)

This is also happening at en:Talk:Turkey. These bugs are way out of hand. --Peter Talk 11:16, 3 October 2008 (EDT)
Okay this is a result of the upgrade to Php 5.2. By default the re engine is set to have some particularly restrictive limits (details are messy, the interested can look at [[2]]). The particular part that hit the limit was a function in the listing editor code that renumbers the auto numbered links. I upped the limits to something more reasonable and I changed the listing editor code to return original text instead of the empty replacement text when the renumber regular expression fails. This should prevent the failure of the page over what is really a minor issue. KevinSours 15:40, 3 October 2008 (EDT)


Wikitravel is slow as molasses today, especially when saving changes. What's going on? It was fine (well, speedwise) yesterday. Jpatokal 02:36, 3 October 2008 (EDT)

I spent time profiling the site today with speedy results. Let me know if this problem persists. Cheers! Khoerling 19:58, 16 October 2008 (EDT)

Anonymous users IPs changing[edit]

Has anyone else noticed this? The IP address recorded on edits on :En seems to be incorrect and jumps to a new IP for a while before the proper one is finally recorded. Seems to be just since the server change. --OldPine 13:16, 26 September 2008 (EDT)

Determining the user IP is actually a fairly tricky thing to get right -- its almost certainly related to the new servers. However, I'm not clear on what behavior you are observing when you say "seems to be incorrect and jumps to a new IP for a while". I looked at the recent changes on en. While its impossible to tell if the IP addresses are right, they didn't appear to be any of the "wrong" ones that I'd expect (they're all valid ip addresses outside of our network). A specific example of a wrong IP address would be very helpful KevinSours 13:33, 26 September 2008 (EDT)

See this history: [3]]. The last 7 edits (after 12:46) were all made by me from the same computer, probably It's a stable IP connection. I am also seeing anon users today clearly having the IP jump around. It's obvious on the recent changes log. OldPine 13:54, 26 September 2008 (EDT)

Not sure if this is related, but I did notice when patrolling yesterday that there were an unusual amount of what appeared to be dynamic ip's... see Lahore for an example. Normally when I see dynamic ips it's just the last couple #'s that change, but this seems to be assigning entirely new ones with each edit... is there anyway that this would be happening through our servers and not their isp? – cacahuate talk 14:06, 26 September 2008 (EDT)
Something is not right with the X-FORWARDED-FOR header. Unfortunately there could be a lot of places where this is getting messed up. This is going to take a while to troubleshoot. KevinSours 15:06, 26 September 2008 (EDT)
I also observed strange edit history in ja. [4] All of the anon edits here seem to be done by the same user (because edit interval is so short), but the IP addresses vary so much. An IP address of a Japanese company (probably the user's real IP address) and other various IP addresses (USA, Ireland, Switzerland, Malaysia, India...) appear almost alternately. --Episteme 15:43, 26 September 2008 (EDT)

Configuration problem with the load balancer. Should be resolved KevinSours 20:13, 26 September 2008 (EDT)

Peter can't access shared after trying to access Multilingual Statistics[edit]

For some strange reason, Peter cannot access Shared at all for the last 24 hours, but can access En fine... any thoughts on this? – cacahuate talk 16:50, 27 September 2008 (EDT)

Hmm, I can access it in Internet Explorer, but not in Firefox. I tried clearing my browser cache, but that did not help. --Peter Talk 18:09, 27 September 2008 (EDT)
I take that back, as soon as I logged in and submitted that edit, I became again unable to access Shared. The only thing that works is clearing all Wikitravel cookies. So have I been blocked from using Shared? --Peter 23:01, 27 September 2008 (EDT)
Currently, I can access Shared except for Multilingual statistics. Is anyone else having trouble viewing that page? -- 05:21, 28 September 2008 (EDT)

I just got this same mystery disease as well. Can't see or do anything on shared from my Windows box, but anon from Linux works... 11:52, 28 September 2008 (EDT) (Jpatokal)

Now it happens each time I try to access Multilingual statistics, and I can "fix" it by deleting my Wikitravel cookie. But I hate throwing out cookies, and I want to check the multilingual statistics—:ru should have surpassed :pl in number of articles, and I wanted to gloat over that. --Peter Talk 13:47, 28 September 2008 (EDT)
Yep, me too... all is fine until trying to load MS, and then nothing works until cookies are deleted – cacahuate talk 21:03, 28 September 2008 (EDT)

I use IE 6.0 under Windows 2000. Currently, i can't access Multilingual statistics. But i can access a page history of Multilingual statistics. -- Sergey kudryavtsev 04:16, 29 September 2008 (EDT)

This may be a solution for Multilingual statistics: 1) export with history into XML-file, 2) delete article 3) reimport from saved XML-file. Try? -- Sergey kudryavtsev 04:22, 29 September 2008 (EDT)
I cannot access to some of the parts of Shared for the last couple of days, too (especially when I try to access the multilingual statistics and new image gallery). My browser (IE6) is always hanging up...--Shoestring 08:38, 29 September 2008 (EDT) (from ja:)

Something really weird is going on. I'm going to try to troubleshoot KevinSours 12:58, 29 September 2008 (EDT)

Okay. There appears to be a bug in our version of mediawiki (I confirmed by comparing against some later versions) that caused some file (especially image) metadata to be improperly cached). I fixed that and the mulilanguage stuff comes up for me now. I'm no longer seeing the other hang behavior that happens after you try to hit Multilingual statistics so I'm guessing, knock on wood, that this is a symtom of the overall problem. I have no idea why this suddenly bit us, we've been running this version for a while (and on the new servers a couple of days before anybody noticed this). Let me know if its still happening. KevinSours 16:02, 29 September 2008 (EDT)

Old versions of articles[edit]

After the server move, I've been getting old versions of articles quite often. For example, if I look at the Pub on en: right now, I get this version, while when editing I get the actual latest version (this one at time of writing).

Anybody else getting this? Could this be related to server time and/or caching? Eg. the LtPowers edit above was timestamped as 19:33, 27 September 2008 (California time?), but the history shows it as 23:37, 27 September 2008 (UTC?), and the edits I don't see fall within this four-hour window. Jpatokal 23:54, 27 September 2008 (EDT)

Sounds similar to what I reported here - Cacahuate (who is now having similar issues to Peter with using Shared, despite having used it all day just fine).

Anonymous uses IP[edit]

I saw something strange on nl wikitravel today:

  • 03:57 (CEST) . . (-8) . . (Overleg) (YKYAdceqtcbXTg)
  • 03:40 (CEST) . . (+5) . . (Overleg) (PjKYIrTHUdkprCl)
  • N  ! 03:23 (CEST) . . (+42) . . (Overleg) (rrDVtnDIVMRAlnAluDZ)

A false header or came it from the server intern? --Rein N. 04:09, 30 September 2008 (EDT)

I saw the same IP on en:. [5] -- Tatata 04:38, 30 September 2008 (EDT)
On en they look like edits from somebody not logged in. Those [6] are useless edits. The text in the summery lines are random chars. On Commons I have seen that IP also, followed by the signature corrected by somebody in charge at the server.--Rein N. 05:19, 30 September 2008 (EDT)

As I said before, determining the exact ip of a request is more of an art than a science. As far as mediawiki is concerned the requesting IP is because the request comes in from the Squid cache running on the same box. There are some headers that let you figure out the actual client IP, but those require some configuration not just in mediawiki but up the chain. That configuration hasn't changed any since late Friday afternoon so I don't think that's at issue. Since these are all junk edits appearing in a fairly narrow time window with no recent changes to the config, I'm inclined to call it some kind of spoofing and wait to see if it becomes a serious problem. As far as I can tell most edits are being reported with the correct ip. Also, as Rein N noted, if I set my system to hit one of the web servers directly and log out then the system will report my IP as KevinSours 10:49, 30 September 2008 (EDT)

Thumbnails show up as gray box[edit]


I uploaded a version of Image:Helsinki-Overview.png, realized that it was the wrong one and aborted, then uploaded the correct version. But now the thumbnail shows up as a gray box, even though the full res link works fine. Problem in my cache, or do others see the same? Jpatokal 10:26, 29 September 2008 (EDT)

I see it too, and purging the cache doesn't help. --Peter Talk 12:40, 29 September 2008 (EDT)
I'm having a similar problem with all images on Copenhagen/Østerbro, i tried purging all the images, and now they show when you click the link, but still not in the article :-/ 15:27, 29 September 2008 (EDT)
I'm having the same problem with every image I've uploaded to the Pensacola article; I can't see any of the images, although other people I've asked can see them just fine. It started about an hour ago, when I uploaded Image:Pensacola-Evenings-Olde-Seville.jpg. --Tally 16:17, 29 September 2008 (EDT)
There seems to be a thumbnail rendering issue across the board, I'm seeing that on images I upload too. Also check out how the license box appears, it lists the link to the image rather than rendering the image. And on this page, I'm trying to add two example issues, but it won't show the pics within article, just shows links to them. On another note, Jani some of the text looks strange on Helsinki, not sure if this is related to site issues or something on your end? – cacahuate talk 16:38, 29 September 2008 (EDT)

Looks like the new version of ImageMagick (the app that creates the thumbnails) on the new servers requires a bit more memory than the older version and was bumping up against the default mediawiki limits for shell processes. I bumped the limit and it appears to be working again. You can force the thumbnails to regenerate by purging the image page. KevinSours 16:56, 29 September 2008 (EDT)

No, it's still not working, Check Copenhagen/Østerbro article - I tried purging both the images and the article 17:36, 29 September 2008 (EDT)
I tried purging the image page but it worked only when purged, and the image disappeared again after I came back from other pages. Is this related to the problem? -- Tatata 01:04, 30 September 2008 (EDT)
BTW. That wasn't the problem, but thanks for the link it was useful information KevinSours 14:56, 30 September 2008 (EDT)

I see that all embedded images now appeared as image link at ru and shared. -- Sergey kudryavtsev 01:53, 30 September 2008 (EDT)

It's happening also to the arrow traffic sign on disambiguation pages (Jnich99) 04:49, 30 September 2008 (EDT)
Thank you very much for fixing up the Multilingual statistics. Speaking of it now I can access to that page as usual, but..., it seems that we still have some problem(s) when it comes to the thumbnail system (as some members have already pointed out above).
When I access to the new image gallery, it displays like "gallery of black frames", with all the images are "white out" (can you imagine what I'm trying to explain?). Also, all the ja: pages which call their image(s) from shared does not display their image(s) normally (just only the linked file titles are displayed, except the ones on the main page).
In addition, when I try to display category pages on Shared, some of the images in the specific pages are not displayed. For example, click each category pages from the main page to the next along with the geographical hierarchy (such as Asia -> East Asia -> Japan -> Tokyo) and check if their thumbnail images works. For example, it displays on my PC (IE 6.) like this:
North America (works) -> United States (not works) -> Idaho (partially works).--Shoestring 09:08, 30 September 2008 (EDT)

I fixed the image generation problem. However it looks like the system isn't correctly defaulting to shared when an image isn't found locally. Its treating shared images as missing local images, hence the links. More confusingly, it seems to be picking up something for the local image page from somewhere so it will actually show content (though if you look at the tabs they have the red "no content" highlights). If you click on the image link and change the url to shared and purge, the grey box goes away, but that doesn't help much. I haven't had a chance to look at why the shared links suddenly stopped working -- I'll try to carve out time to look at that today. KevinSours 10:53, 30 September 2008 (EDT)

In addition to not correctly pulling image information from cache (the multi language problem above), the load from cache code incorrectly stores the information back to the image object. The result is that the mime type for the image is incorrectly set and MW can't process it. It never showed up before because we never used the information from cache. I've patched that and images appear to be working with one remaining problem. There is a permission problems that can cause "Error creating thumbnail: convert: unable to open image 'image path': Permission denied." errors. I have an idea what the problem for that is, but I need to talk to some people here about a fix. KevinSours 14:06, 30 September 2008 (EDT)

Yes, i see such error at top of ru:Санкт-Петербург/Васильевский остров. -- Sergey kudryavtsev 14:46, 30 September 2008 (EDT)
I join the club. Had the same kind of errors when I uploaded images to Category:Paris a few days ago. The upload worked normally, but when I looked at the page some 15 minutes later, I couldn't see any pictures. Some of the pictures others had uploaded to that page earlier were also "invisible". Then, later, it worked again, and I linked from fi:Pariisi to some of those pictures and I had precisely the same problem, error creating thumbnail etc. The strangest thing is that one of those pictures (Palais Royal) did show up there as it was supposed to. Ypsilonatshared 07:55, 2 October 2008 (EDT)

Umm..., the shared images which we have already been used on ja: are normally displayed right now, but I still can not use any images when I want to make a new edit on ja: and call some images from shared. For your reference, I pick up the error message as follows:

サムネイルの作成中にエラーが発生しました: convert: unable to open image `/var/www/wikitravel/upload/shared//7/74/Bus_terminal,_Mahbourg,_Mauritius.JPG': No such file or directory. convert: missing an image filename `/var/www/wikitravel/upload/shared//thumb/7/74/Bus_terminal,_Mahbourg,_Mauritius.JPG/160px-Bus_terminal,_Mahbourg,_Mauritius.JPG'.

--Shoestring 09:17, 2 October 2008 (EDT)

Hmm... The problem causing that should have been fixed late Tuesday. There may be a few lingering permissions problems, however I checked the files in question and I didn't see anything wrong. If this is still happening, can you please point me to the page or give a list of steps you took when you encountered the problem? 12:01, 2 October 2008 (EDT)
CopenhagenBicycles.jpg in the Copenhagen article [7] and Recife_-_Boa_viagem.jpg in the Recife [8] article are just two examples, they are everywhere. Sertmann 17:03, 2 October 2008 (EDT)
And here's another example from ja:[9].--Shoestring 13:05, 3 October 2008 (EDT)

The [:en:Copenhagen] and [:en:Recife] are the result of some total garbage in memcache. That can be cleared by clicking on the little link to the image that shows up in the error box (tiny icon in lower right corner) and adding "?action=purge" to the end of the url. Note that link will not go to shared but rather the local language version even though the image is in shared. I cleaned up all the ones I saw but there may be others. I did a test upload to shared and did not seen any problems with putting a link to the image on my sandbox page on en.

The ja example appears to be a problem with non ascii characters in the title. In some cases there are getting changed when translating to a filename in others they aren't causing the file to not be found. I need to look into this further KevinSours 18:34, 3 October 2008 (EDT)

I'm still getting broken thumbnails for en:Taiwan -- it doesn't appear to realize that the image is available on Shared.

[10] [11]

And FWIW, here's Google's list of broken thumbnails: [12] Jpatokal 13:30, 5 October 2008 (EDT)
I didn't see anything at the Tawain link. I was looking for grey boxes so I may have missed something. There are a couple of things going on here. Wikitravel keeps a cache of meta data associated with an image in memcache. It keeps this cache whether or not the image is found (otherwise if an image was on shared it would have to do the full lookup on en every time the page was loaded). For most images its appearing that this "not found" cache entry is being corrupted making it look like there is an cached image information with for an invalid image. This is fixable via the purge instructions I listed above (if you purge the en/ru/ja/etc version of the image it will purge the invalid memcache information). I'm hoping this is a result of the previous problems, but it keeps happening we'll need to investigate futher (and hopefully a clearer pattern will develop). I've gone ahead and purged all of the images I found in the google results that you posted.
A similar situation will occur of MW can't find the image in either the local language version or shared. It will assume that the missing image belongs in the local language version and post the link. This is the case in the ja image where the character issues are causing it to not find the image file. The error noted at Tech:Error_creating_thumbnail,_Invalid_thumbnail_parameters seems similar, but I don't yet know the cause. KevinSours 13:27, 6 October 2008 (EDT)
Hi. I'm having the same problem for several of the images on the Miami wikitravel article. Can someone please regenerate the cache for this image, or give me some pointers to solve this? Thanks! --MarinaK 15:24, 6 October 2008 (EDT)MarinaK.
That's also going to require some investigation. KevinSours 15:41, 6 October 2008 (EDT)
On sv:, we have the same problem, as described above, on our main page: Ett fel uppstod när minibilden skulle skapas: convert: unable to open image/var/www/html/': No such file or directory. convert: missing an image filename/var/www/html/'.
Also, when not logged in, the red MWI dot flashes.
The image is accessed via a js generated link. If you aren't logged in it attempts to get your IP address and generate the link as if the IP was your username. The IP is generated via some apache hacks (this was part of the orginal system) rather than in php code. As far as apache is concerned, all client IPs are It looks like there in fact was a new message for User: My question here is, is this feature really used -- that is do unregistered users actually maintain user and user talk pages using their IP address instead of registering with a username? KevinSours 13:56, 8 October 2008 (EDT)
Hey Kevin, regarding ip's, the issue is more that we can't track their contributions as easily... we often have to block anon ips for vandalism or spam, but if they aren't showing up correctly, it can cause major problems for us – cacahuate talk 12:32, 11 October 2008 (EDT)
And as of today (?), all links are suddenly underlined instead of just being plain. What on earth is happening?? Riggwelter 12:52, 8 October 2008 (EDT)
Can you give me an example? I looked over the site and didn't see anything amiss. I recently enabled site specific css as requested, but I looked and didn't see anything unusual in the sv css text. Unsigned comment by KevinSours (talkcontribs) .

This is STILL not working properly, many images on :en are not rendering when the image is hosted on shared... we've got to fix this soon, it makes the articles look terrible... I'm not even able to fix it by purging the cache on the image and the article.... the image will finally show up on its page, but not within the article. see lead image at en:Pinswangcacahuate talk 12:28, 11 October 2008 (EDT)

Cacahuate, have you been refreshing your browser window after purging the image cache? That worked fine for me on Pinswang. But agreed, this is a serious bug and an embarrassment for our site. It's very sad that we have such a top-notch wiki, but lack the technical support to keep things in order—the latest server move created a ridiculous deluge of bugs, which are going unfixed. --Peter Talk 14:30, 11 October 2008 (EDT)
I was, I think... but yes, I see it now... but we shouldn't have to do this all day long with each individual image across the site, can't the entire site cache be purged or whatever to fix this? As you say, an embarrassment to the whole site when new users don't know what the hell is going on – cacahuate talk 15:46, 11 October 2008 (EDT)
Odd, I thought this problem was resolved, as both the thumbs and full-res shots display for me. I'm looking into it now :) Khoerling 20:50, 13 October 2008 (EDT)
Nope... there are plenty that show up, but still plenty that don't.... en:Karachi for instance, and fwiw that lead image isn't even on Shared, it's a local image to :en. We can fix them individually, yes... but that's tedious and shouldn't be necessary... is there a way to just purge the cache for all images on the site, or whatever else needs doing to fix it? – cacahuate talk 02:15, 14 October 2008 (EDT)
Whenever an image is not found, I added logic to check for existence on shared. If the image exists there, it gets republished in its appropriate language. This fixed the above issue with Karachi and hopefully many others, too. Please let me know if you spot more broken images. Cheers! Khoerling 19:55, 16 October 2008 (EDT)
This thumbnail issue is still occurring with certain articles such as Bahamas "Error creating thumbnail: convert: unable to open image `/var/www/html/': No such file or directory. convert: missing an image filename `/var/www/html/'." --Elronaldo 23:15, 16 October 2008 (EDT)
Thank you, Khoerling. Some thumbnails on ja: were fixed, and I could see the thumbnail in en:Bahamas#Sleep by purging cache. But ja: has still thumbnail issue of this image in ja:マエブール#着く, that is reported by Shoestring above (09:17, 2 October 2008 (EDT) ). -- Tatata 03:31, 17 October 2008 (EDT)
Both of those links appear to have working images. Was the cache was purged? Perhaps I can purge the cache site-wide. What do you think? Khoerling 12:48, 17 October 2008 (EDT)
I purged cache of :ja:画像:Bus terminal, Mahébourg, Mauritius.JPG and ja:マエブール, but it didn't help. So, I'm not sure whether the site-wide cache purge will be a help or not.
By the way, the filename includes an accented letter, but it doesn't appear in the thumbnail error message on the article.
サムネイルの作成中にエラーが発生しました: convert: unable to open image `/var/www/wikitravel/upload/shared//7/74/Bus_terminal,_Mahbourg,_Mauritius.JPG': No such file or directory.
convert: missing an image filename `/var/www/wikitravel/upload/shared//thumb/7/74/Bus_terminal,_Mahbourg,_Mauritius.JPG/160px-Bus_terminal,_Mahbourg,_Mauritius.JPG'.
Is this, missing an accented letter, a cause of "No such file or directory" and "missing an image filename" ? Other images including "Mahébourg" in their filename are working fine, though. -- Tatata 05:19, 18 October 2008 (EDT)

Probably this error is mainly coming from the non ascii characters problem which KevinSours has already pointed out above.

Look at the broken thumbnail in the current Gallery of new files. The part of the title of that file is incorrectly converted from "Düsseldorf" to "Dsseldorf", i.e. the letter "ü" is missing. So is Mahébourg's "é". In that situation solutions such as cache purge or file re-upload etc. are totally helpless.

FYI, if I want to edit on ja and add the other files which includes the "Mahébourg" letters (such as Image:Auberge Aquarella, Mahébourg, Mauritius.JPG) , it causes the same error, although each file itself is correctly displayed on Shared.--Shoestring 12:34, 18 October 2008 (EDT)

Logged in status acting up[edit]

Since yesterday, I've been having major problems staying logged in to Wikitravel, it's kicked me out three-four times already within 24h. Also, even when I'm logged in, I get "My page - My talk messages -- Log in / create account", instead of the correct "Jpatokal -- Log out" at the top, and I don't get registered-user tabs like "Move" when I edit articles.

This applies only to en, shared seems to be working normally (except for that underlined links bit, which I'm getting too). But here the caching is still screwed up, with days-old versions of the Pub shown... Jpatokal 01:24, 9 October 2008 (EDT)

It happens to me too these days in most language versions. --Episteme 16:08, 9 October 2008 (EDT)
No problems staying logged in, but on :en my tabs display as if I were not (e.g., article, discussion, edit, history, my page - login/create account). So to move, delete, or watch pages, I'm having to write that in directly to the url. --Peter Talk 13:53, 10 October 2008 (EDT)
Any update on this issue? On en: the "remember" functionality isn't working for me, the admin tabs are missing, and I never see the correct user menu in the top right. -- Ryan 16:42, 12 October 2008 (EDT)
Same here – cacahuate talk 21:08, 12 October 2008 (EDT)
This is yet another ridiculous problem. I'm not even sure how to move pages anymore. --Peter Talk 13:53, 13 October 2008 (EDT)
Oh, I read that too fast... I'm only having the constantly logged out problem, but when logged in everything is working fine... are you admin tabs really missing? – cacahuate talk 18:56, 13 October 2008 (EDT)
All of the admin & user tabs are gone - "Move", "Watch", "Delete", etc. My user menu in the top right also always shows me in a logged-out state, and I see image ads in the right rail (which logged in users aren't supposed to see). -- Ryan 21:50, 13 October 2008 (EDT)
Same problem here. Admin tabs missing and upper right menu shows not to be logged in, though if I click log-in it shows that I was actually logged in. On pt: and es: I still get my admin tabs but otherwise it shows not to be logged in. Texugo 00:09, 14 October 2008 (EDT)
Not sure whether this helps, but when I access the English-language Wikitravel (and Shared) from my "work" computer, using a rather old version of Internet Explorer, I don't have this problem -- while from "home," with an up-to-date Firefox, I have the same issue as everyone else. What browsers are people using when this happens to them? -- Bill-on-the-Hill 12:53, 14 October 2008 (EDT)
I'm on the latest version of Firefox, and I can't seem to stay logged in to :en. LtPowers 16:23, 14 October 2008 (EDT)
I think you're on to something, Bill. I'm on the latest version of Firefox too, and I'm having the same problem. But when I use my outdated IE browser on my home computer, everything is fine. PerryPlanet 18:07, 14 October 2008 (EDT)
I'm in Safari, and only have the issue of being logged out daily, but once i log back in I see my admin buttons – cacahuate talk 21:00, 14 October 2008 (EDT)
Are your admin buttons working when you log back in with Firefox, John? Mine aren't coming back, and it's a problem, because there are deletions to do on en:. Incidentally, my "new" IE on the home computer seems to work fine too, on the same machine where Firefox isn't working. -- Bill-on-the-Hill 18:11, 17 October 2008 (EDT)
And the repercussions continue... – cacahuate talk 04:23, 21 October 2008 (EDT)
SAD! anyway, just affirming the above... IE6 on work, and FF3.03 at home - and the problem is ... dam dam dam ... at home. I really think this, and the images issues, should be resolved quickly - as i suspect consequences like the one above, will mainly be from the most valued users :o/
/EDIT also, both Shared and Swedish WT are working just fine in FF Sertmann 17:05, 21 October 2008 (EDT)

Okay, I made some changes and can no longer reproduce the problem. Looks like I didn't quite merge some of the custom code between 10 and 11 correctly. However, none of what's happening makes any sense. English and shared run exactly the same code base so one should affect the other. Moreover, the code that appears to be at fault has been with us for a while and there doesn't appear to be any explanation for why its gotten bad now. I'll try to monitor this and if it keeps acting up I'll take another look. KevinSours 14:13, 22 October 2008 (EDT)

It's not a "keeps acting up" problem; it's constant and unchanging. User tabs and sysop tabs simply do not display in Firefox on the English language version. This means that basically no one can move pages, and that it's a lot harder for admins to keep the site free of spam. This is a huge and unacceptable problem. --Peter Talk 16:02, 22 October 2008 (EDT)
I can't see it and I haven't been able to reproduce it on the other machines here that I've checked (I though I saw it initially, but now I'm not sure -- there is a brief pause before the "logged in" display comes up and that might have fooled me). Until this starts making sense I'm going to be grabbing straws until something breaks loose. There isn't much else I can do.
I'm running FF 3.0.3. I assume that matches what other people are running. Is anybody getting javascript errors when the page loads? KevinSours 17:41, 22 October 2008 (EDT)
I just checked several pages in Firefox, and all seemed fine, I see all my buttons, no errors. I'm on a Mac however, and I think most or all of those commenting on this issue above are on pc's – cacahuate talk 18:21, 22 October 2008 (EDT)
My tabs are back now. --Peter Talk 19:02, 22 October 2008 (EDT)
Mine too Sertmann 20:53, 22 October 2008 (EDT)

I still have no idea why this broke when it did since the bad code predates the server move by a fair while and its the same code that runs on all of the sites. I'm going to tentatively call this fixed. I'm not totally thrilled by that, but I don't have much to go with to actually nail this down. If it happens again, please record as much detail as you can about how it happened. KevinSours 12:17, 23 October 2008 (EDT)

Thanks for taking a look, Kevin. Seems to be working for me now, too. LtPowers 14:04, 23 October 2008 (EDT)
I'm just a regular user, not an admin, and I can't stay logged in. It's a hassle to have to log back into the website with every visit. For me, it started after the server move, when I updated to the latest version of Firefox, and the problem is still constant. -- 18:10, 29 October 2008 (EDT)
And speak of the devil, I apparently wasn't logged in when I made that comment. :-p --Tally 13:02, 30 October 2008 (EDT)

Okay, I've been digging through the Firefox support forums, and finally found something that fixes the problem for me. It's a corrupt file called cookies.sqlite, in your Mozilla Firefox profile, that causes the log in issues. To fix it, first turn off Firefox all the way, then go to Start>Run, type in %APPDATA% and then navigate to Mozilla>Firefox>Profiles, and find the cookies.sqlite file. Rename it to cookies.sqlite.old. Restart Firefox, problem gone. Apparently, this has been happening to a lot of people who've upgraded to the latest Firefox, on quite a few different sites. --Tally 13:54, 30 October 2008 (EDT)
Cool, thanks for the update! – cacahuate talk 19:34, 30 October 2008 (EDT)
Tally, if this works, I owe you big time. LtPowers 16:23, 1 November 2008 (EDT)

Caching still not working[edit]

Caching is still not working properly -- virtually none of the edits I've made this morning (to eg. en:Johor Bahru) have shown up after I hit Save. This is really annoying for experienced users, and is probably putting off a lot of newbies who just see their work "disappear". Jpatokal 22:03, 4 January 2009 (EST)

Thank you for reporting the issue! I haven't been able to replicate the problem, yet. Since this seems to be a frequently occurring problem for you, I am hoping you might be able to pinpoint a series of steps to recreate the bug, or anything else you've noted about the issue.

Cheers, Khoerling 18:53, 8 January 2009 (EST)

I just went to my userpage on en, and it was showing the last version of it rather than the current one. When I made the change, back in Belize, it showed the newest version after saving. So why it reverts today makes no sense. If it were showing the last version I viewed on this computer, it would make sense. But not the case – cacahuate talk 13:12, 12 January 2009 (EST)
Here is why this might be the case. We run wikitravel off of two webservers, each of which is fronted by a squid cache. On top of that we have the load balancer configured with "sticky sessions". This means that once you go have loaded a page from wikitravel you will be directed to the same webserver until the session expires on the load balancer. If the server you are on is updated, but the other isn't you won't notice it until your session expires (and then only if you happen to be directed to the other server). Mediawiki is supposed to keep the two caches in sync, but that apparently isn't happening quite correctly.

KevinSours 11:58, 15 January 2009 (EST)

It seems to be happening more rarely now than before, although I still can't replicate it reliably. LtPowers 15:58, 12 January 2009 (EST)

I'm having a problem right now where edits don't show up in the browser I made them in, but other browsers work fine. I've cleared my primary browser's cache multiple times with no effect on these results. Additionally, after I added a section, the section edit links below it are all off by one. 22:37, 3 June 2012 (EDT)

Fixed now?[edit]

This doesn't seem to be happening anymore. Other opinions? Jpatokal 10:01, 2 July 2009 (EDT)

Images have the problem, as always, but I haven't seen this happen to a page in quite a while. I'd say it's fixed. --Peter Talk 16:30, 2 July 2009 (EDT)
I'm still having to refresh pages like the Travelers Pub on :en to see the latest post. LtPowers 22:49, 4 July 2009 (EDT)
Getting it a lot again over the last couple weeks. Perhaps this problem was fixed by Mediawiki in a recent update? We aren't running the latest version though – cacahuate talk 17:10, 6 July 2009 (EDT)
Very much still an issue I am afraid and I think it is one which could scare away new editors who will think their work is lost (that thought crossed my mind). If it helps in pinning the issue, it is particularly apparent to me when reading article versions logged in and then logged out (current version when logged in, a previous version when logged out). --Burmesedays 09:31, 29 July 2009 (EDT)
hey guys, I have been told that squid cache is a weird beast to deal with and we'll be attempting to fix this when we upgrade media wiki. While we realize squid doesn't work perfectly, we rather look at this AFTER the media wiki upgrade as the problem may fix itself when through the upgrade. We'll keep you posted on the ETA of the upgrade. Sorry for the frequent use of the word ' upgrade' in this messaging!( I think it may be time to go home now ..  :-) )--Ibsteph 5:32 pm , 18 February, 2010 (EDT)
Still waiting on an ETA, Steph. The caching problem seems to be getting worse, and it's starting to seriously affect new users. We get frequent duplicate entries (because the first try doesn't show up for them) and seem to be getting more questions and complaints. LtPowers 21:36, 29 July 2010 (EDT)
Ironically, the answer Stephanie gave (18 months ago...) is still the correct one. The bright side is that the MW upgrade is actually moving forward now. The squid cache will be upgraded if MW doesn't resolve the cacheing issue; if that fails to resolve it, we can change our cacheing method altogether. In any event, we're looking at October on this.--IBobi 19:46, 12 September 2011 (EDT)

Is this still a problem? I have not experienced it. Nurg (talk) 01:48, 3 September 2016 (EDT)

Possible cause?[edit]

Is it at all possible that the solution to Tech:Editing MediaWiki files causes Wikitravel to suck caused the caching problem we're seeing now? LtPowers 09:28, 3 August 2010 (EDT)

See also[edit]

Possibly related bugs[edit]