UESPWiki talk:Upgrade History
| Discussions
|
|---|
| Archived discusssions about the Upgrade History |
| Archives |
| Archive 1: Jul 2006 - Jan 2008 |
Protect SectionEdit
I hate to push you when I know you've got better things to do, but could this extension be installed as soon as possible? We've had a couple of examples where it would have been really handy in recent days, and the discussion doesn't seem to have resulted in any negatives. If you only have time to install one of the outstanding requests, the Tidy extension should probably come first as more depends on it, but this one would mean less time required to deal with idiots. Thanks. –Rpeh•T•C•E• 12:27, 16 February 2008 (EST)
- Done...feel free to remind me on my talk page about requests. I sometime miss things, forget about them, or just assume it wasn't important. -- Daveh 20:45, 20 February 2008 (EST)
Page CacheEdit
Yeah, today I figured out that the cache of the Main Page of the squib still wasn't serving the news post from August 2nd. I fixed the problem by purging the cache, but is there a way we can prevent this from happening in the future? --Ratwar 20:22, 12 August 2009 (UTC)
- There have been a few problems lately that seem to suggest that out-of-date copies of pages are being displayed (Oblivion:Easter Eggs, Lore:Daedric Princes). I'm not sure whether the problem is squid1, or whether the problem is that content1 and content2 are maintaining separate page caches (not the memcaches -- the page caches being the ones at /tmp/cache). I'm also not sure why this seems to be a new problem -- unless it's a side-effect of merging the memcaches. --NepheleTalk 20:42, 12 August 2009 (UTC)
- Actually, if possible, next time someone notices one of these problems, could you post the information here, but not purge any pages, or do anything else (such as edit the problem page) that would change the situation. I can then track down where the problem is actually happening; at the moment, all I can do is guess or search randomly through thousands of pages in the hope I might stumble across another example. --NepheleTalk 20:53, 12 August 2009 (UTC)
Well, Nephele, the same problem is presenting itself on the Main Page again, with an increased 'weird' factor. I checked it to make sure the latest newspost was showing up last night for non-logged in users. It was. Now it is failing to show up for non-logged in users. Have fun with this one ;). --Ratwar 20:59, 15 August 2009 (UTC)
- I'm not seeing it this time -- I'm getting the most up-to-date version of the page when logged out. Although it's possible that this edit changed the situation before I had a chance to look. In any case, the fact that problems are still occurring tells me that simply refreshing the cache isn't enough. I really think we need to be using the same page cache on both servers. Unless Daveh has other thoughts/suggestions, I might experiment with some reorganization on Monday. --NepheleTalk 21:29, 15 August 2009 (UTC)
RedirectsEdit
Yeah, I'm not totally sure this is related to recent upgrades or whatever, but it appears that some redirects such as Tes3Mod:Tamriel_Rebuilt/House_Dres aren't functioning properly for non-logged in users. They're simply not redirecting the users to the correct page. The web address http://www.uesp.net/wiki/Tes3Mod:Tamriel_Rebuilt/House_Dres seems to be missing the "&redirect=yes". I have duplicated the problem on Oblivion:Aloe_Vera. If this is a known issue, sorry for rehashing it. --Ratwar 08:00, 14 August 2009 (UTC)
- Confirmed. In fact I just tried a few redirects while logged out and not one of them worked. I don't know when that started happening though. –rpeh•T•C•E• 08:19, 14 August 2009 (UTC)
-
- It looks like a problem that only happened yesterday, so we caught it fairly quickly. I'm also not really sure what triggered it, other than I suspect Daveh must have been running some script on the content servers. What I do know is that in the file caches on both servers are a whole bunch of cached files created by root, all created yesterday (Aug 13, between about 11am EDT and 5pm EDT). That says something unusual created them, because normally all of the cached files are created by apache. Those cached files included cached versions of a whole lot of redirect pages. Normally redirect pages don't have cache entries, because those pages aren't displayed. However, if a cache file exists, it gets displayed for an anonymous user, regardless of whether or not should be displayed. Therefore, anons were seeing redirect pages that they shouldn't.
- I'm going through and forcing both content servers to regenerate all of the root-generated cache files. It's going to take a while (a couple of hours or more -- there are some 10000 files on each server), but once it's done the problem should be fixed.
- (FYI, I do cache purges like this through the API, meaning that I'm going through apache and generating the pages as a standard wiki user -- well, technically as NepheleBot, so NepheleBot isn't really as inactive as I claim. I started doing it that way because I have to -- I don't have permission on the server to change apache's files, so I have to make apache do the work -- but it also means that the wiki processing is being done as "normally" as possible. Also, it means that the squids automatically get updated. I'm guessing Daveh must have been using some server scripts that directly call individual wiki functions, since that's the only way root-created files would end up appearing, and those scripts were bypassing some standard checks, such as whether or not the files were redirects.)
- --NepheleTalk 18:21, 14 August 2009 (UTC)
- OK, having now read what Daveh did yesterday, I'm guessing the problem was caused by the maintenance/rebuildFileCache.php 0 overwrite script Daveh ran. (I'd tried to check that info earlier, but ran into a version of our other unsolved problem, and therefore was only pulling up an August 11 version of the Upgrade History). Also, for future reference, another limitation of that script appears to be that it only regenerates content pages -- the file cache still contains old versions of talk pages, UESPWiki pages, image pages, user pages, etc. Once I've finished redoing what the script did do, I can then go back through again and get the rest of the pages. --NepheleTalk 18:40, 14 August 2009 (UTC)
-
-
-
- Well, I hit a significant setback today. It looks like Daveh changed all of the files in /tmp/cache to be owned by apache -- so now I can't pick out the redirects or otherwise questionable files based on file ownership any more. In other words, instead of having to re-process some 10,000 cache files that were created yesterday, I now have to start over from the beginning and re-process all 30,000+ files that were created yesterday. It's likely to take most of a day to finish getting through all the files. --NepheleTalk 01:03, 15 August 2009 (UTC)
-
-
-
-
-
-
-
- Thanks for the offer, but it's not really any work on my part. I already had the script in place; all I had to do was give it the new range of times for the to-be-regenerated files. It takes a long time just because that's how long it takes the server to do the work (with a 1 second pause between each page). Part of the frustration was that I'd just left it to run all afternoon, knowing it would take at least that long, but then came back in the evening to realize it had stopped after about an hour because the file ownerships had all been changed -- so 8 hours of pre-weekend processing time were lost and now it's probably going to have to compete with the weekend surge in traffic.
- 12,310 files done, which looks like it's about half way.... --NepheleTalk 05:28, 15 August 2009 (UTC)
-
-
-
-
-
-
-
-
- Sorry for reseting the file ownerships...didn't realize what you were doing. Its probably too late but you should also be able to pick out the files by their creation/modification date, or just all content pages. It also should of created far more than 10,000 cache pages...the script finished around with a count of ~73k. I had assumed it was recaching all pages. -- Daveh 22:53, 15 August 2009 (UTC)
-
-
-
New sections aren't HighlightedEdit
I've noticed that new sections to an article are no longer highlighted as a change when comparing versions (see here for an example) but changes to existing sections still are. Is there any way to change this back? The only thing I can think of that would cause this change is the most recent upgrade, so I thought this would be the best place to bring it up. Dlarsh(Talk,Contribs,E-mail) 19:21, 4 October 2009 (UTC)
- Either he's rolled back the update already or it's browser-specific, as I see highlighting for that edit in both IE8 and Firefox. What are you using? —Robin Hood (Talk • E-mail • Contribs) 20:22, 4 October 2009 (UTC)
-
- Do you mean like how some of the changed text with a green background here is either red or black? I'm not sure how it was originally but the installation of wikidiff2 this morning could be the reason if anything has changed. -- Daveh 21:05, 4 October 2009 (UTC)
- That's right, I could have sworn that new sections were red before. Now the only red words are those that were added/removed from an existing line.
- Ah, I see what you mean now. I had indeed only been looking at the green background. For me, I'm pretty sure the text has always been in black, unless wiki's doing its thing where it identifies the first character or word as being the same and then assumes that the entire paragraph is supposed to line up. It works that way on Wikipedia as well...for instance: this diff (picked at random from my Watchlist there). —Robin Hood (Talk • E-mail • Contribs) 22:32, 4 October 2009 (UTC)
- That's right, I could have sworn that new sections were red before. Now the only red words are those that were added/removed from an existing line.
- Do you mean like how some of the changed text with a green background here is either red or black? I'm not sure how it was originally but the installation of wikidiff2 this morning could be the reason if anything has changed. -- Daveh 21:05, 4 October 2009 (UTC)
(Outdent) I'm starting to get the feeling that I was imagining things from before. Elliot and Eshe said something similar in IRC earlier, so I must just be mistaken. Sorry for the confusion. Dlarsh(Talk,Contribs,E-mail) 00:40, 5 October 2009 (UTC)
- No worries. As I said above, the wiki software will use just about any excuse to consider a paragraph similar, so it could well be that you've mostly seen it in red before and just not noticed that occasionally it was black instead. —Robin Hood (Talk • E-mail • Contribs) 01:20, 5 October 2009 (UTC)
Blog DownEdit
It looks like the latest changes have caused a problem with the blog - I get 403 Permission errors whenever I try to access it now. rpeh •T•C•E• 01:09, 20 February 2011 (UTC)
SphinxEdit
We are using Sphinx on the phpbb support forum. It works well for large sites like that, but it is really annoying for the users because their new posts do not show up in search until the engine gets around to its batch update -- several minutes to an hour later. --Brf 00:08, 26 April 2011 (UTC)
- Yes, its one thing to consider, although the incremental index updates are relatively quick (a few seconds) so it can be set to run every 5 minutes if needed. The current MySQL fulltext search has significant performance issues with some searches taking 10-20 seconds which is not desirable from either a client or load view point. -- Daveh 01:40, 26 April 2011 (UTC)
-
- Yeah. And as long as "Recent Changes" is not affected, users would not need to immediately search for their topic anyway, unlike a forum. --Brf 01:51, 26 April 2011 (UTC)
Specific namespaces for Special:Random brokenEdit
Exactly what it says on the title; I rely on the namespace feature of e.g. Special:Random/Online to hop around in Online space looking for things to do, but it seems to be broken now, and will return a page from any namespace. —likelolwhat talk lulzy to me 01:35, 12 February 2019 (UTC)