Gasp. We're not perfect. There are a lot of items that need work, and a lot of different things that are broken in minute ways. They are the growing pains of a publicly developed website. We are in a constant state of beta, but hey, it keeps things exciting. We'd like you to report any problems that you're having, because we, the caretakers and floorwashers, like this to be a generally pleasant experience for you.

Although we're working on a ticketing system, for the moment it is not complete, so please for now just tell us here where we messed up, and hopefully it will work out.

Things that probably are NOT bugs:

• One-shot Server Error!s (which really only mean I or someone else forgot a ";" and it took him or her a second to find it)
• Oh man, you're right. We spelled sumbit wrong. Thanks....

Please report the following things if they seem relevant:

• Page the error occured on
• A screenshot if it's hard to describe. Post them in Picpaste.
• Your theme (it'll be obvious by above)
• Your browser (not so obvious)
• The time it occured, down to about a half an hour block. We don't need a stopwatch and second, just about when. We'll do the rest.

Hopefully with all of your eyes and ears out there, we'll keep this place running smooth as um, an active website.

Thanks

There is a problem with softlinking and the Last Node function which I thought was mine alone, but others have confirmed seeing also. Essentially, every once in a while on my Safari browser, a node I've visited will get 'stuck' in the 'Last Node' value, being inserted into the search box in every node I go to, and softlinking every node I navigate to to it. This survives cache clears, reloading the browser, etc. etc. I suspect it is a malf involving cookie-based softlinking, but don't know enough about code to prove this.

As per the link above, WaldemarExkul has seen this with iCab, and Simulacron3 and I have seen it using Safari. It's really, really annoying, since I usually don't want to link every node I visit to A Polymer Wang: My Police Record and Me.

Well, okay, maybe I do want to link that, but it should be my choice, y'know? CAN'T A GUY HAVE ANY PRIVACY OVER WHAT NODES HE VISITS? /sobs

Update: Waldemar says that even if he turns off user-agent masquerading in iCab, it continues. I'm suspecting, then, that this is a Mac OS X thing rather than a Safari thing...?

NEW BUG REPORT:

Apparently there is an issue with handling orphaned brackets in Cream of the Cool. Recently, Aneurin's writeup MPs' Expenses and the Freedom of Information Act found its way to the top o the CoTC - and this caused problems. This was because in the first paragraph of the writeup there was an orphaned left bracket (where the White Paper link is now - the closing bracket was missing). As a result, when UpdateNodelet.pl (I think) ran to generate CoTC, it cut off the CoTC section just *before* that link, where the orphaned bracket was, and stuffed the whole rest of CoTC into the link for the News for Noders section title. As a result, the Nodelets bar (on the right side in many Zen themes) ended up stuffed at the bottom of the page, following the center column text, likely because the tags for the css got hosed.

I added a closing bracket to the White Paper link and things got shipshape again once the nodelet update ran.

Note: Is it possible that the single quote in the writeup title was a contributing factor?

Cheers.

Alright, I've got more bugs/feature requests than I can keep safely in my head without losing one or two, so I'm putting them here, but plan on submitting patches for each of them personally.

1. Writeups over the last year include maintenance writeups (my MfD broken nodes and edit these e2 titles writeups appear to be counting towards my total right now (my total on my homenode should be 0 but it's 2)

   writeupssincelastyear (patch) submitted.

2. See also links produced in usercheck should do checks for permission to view collaborations and usergroup discussions. These checks are done elsewhere (displaydebatecomment, collaboration display page), so we should make the check an htmlcode, if possible, and that way we won't have to edit these checks in multiple places.
3. Once call's node_forward hg patch is applied, add in parameter passing so that the original node title is displayed on the final page (very wp redirect, I know, but it's a good design to make it clear what just happened). This will require adding a call to an htmlcode at the top of superdoc and document display pages -- maybe usergroup display pages too? -- Maybe containers should just get it, if we can get a good place. Will check with DonJaime with his redesign. Probably don't want it on the front page for things like the node linked to all others which redirect there. fullpages won't get this treatment, since they're, you know, fullpages.
4. squawkbox should be changed to respect drags, so normal users would be safe using it again. If possible, it should use showchatter so it gets improvements to that along with chatterlight/chatterbox, if at all possible. The downside of showchatter is it will have to be done on a room-by-room basis, so the text of individual rooms will be separated, rather than all messages from all rooms in one list, sorted by time. This could be seen as an improvement in usability or a loss thereof, depending on users' preferences.
5. bookmark lists on homenodes sorts by title ASCIIbetically, so capital letters come before lowercase letters. This would probably be more intuitive case-insensitive. It also would be neat to add an up/down arrow which switches when the sort order is changed.

6. On homenode edit page, when there are fewer than two bookmarks, remove the "check all bookmarks" button, as it's confusing.

   Patched classic user edit page Use Javascript to count the bookmarks, hide paragraph containing the button as necessary.

7. Allow trailing spaces in direct links. This will require an ecore patch.
8. Make showchatter suppress display of repeated messages caused by reloading. Doesn't even require any clever client-side coding or DB cleverness. Why hasn't this occurred to me before?
9. Since the recent downtime (2009 July 10-2009 July 12), reps are drifting a lot. This is almost certainly a result of DB requests getting dropped on the floor, since we update the vote table first, then the node's rep, then the users's GP. An example query to demonstrate a node affected by the problem:

   SELECT * FROM vote WHERE vote_id=1992146 ORDER BY votetime LIMIT 50
   SELECT reputation FROM node WHERE node_id=1992146

   When things are closer to normal speed, we might want to manually recalculate the rep on all recently-voted-upon nodes. This is a problem for nodes which were restored from node-heaven for which the rep was maintained.
10. From the catbox just now: <OldMiner> Hmmmph. If we don't have something that regularly keeps track of database load/apparent user lag, we should add something. If nothing else, it'll provide a reassuring "Is the site slow or is it just me?" indicator to you guys.
11. Send a notification to members of edev and/or ecoders whenever a new addition is made to E2 Bugs or Suggestions for E2 to drum up interest in changing things.
12. Make blab links go directly to the specific writeup (e.g. You said re E2 Bugs: Less like this, more like coding.)
13. Put in a separate displaytype for nodelets that evaluates nlcode right now, instead of just displaying nltext, so that we can test things that normally would require rerunning the caching scripts.

I seem to have an extra C! to spend. I spent my one C! for the day but the epicenter still claims I have 1 C! to spend and the link at the bottom of writeups is still active.

June 14, 2009

---

Also, the writeups hints section needs to be updated to take into account direct linking. It says "It looks like you forgot to close a link, since you tried to link to a node with [ in the title." It gave me this message because the first half of the pipe link to a specific WU is [Node Title [By Author]|Link]

June 29, 2009

(Patched by DonJaime)

---

The Search Full Text feature seems to be broken. Whenever it's checked, it redirects the page to the Google Search Beta nodeshell. I would suspect that deleting the nodeshell will fix the issue.

August 16, 2009

(Fixed when the nodeshell was deleted)

---

Some writeups don't seem to show the node creator. More specifically When an octopus becomes upset, it may eat itself.

August 16, 2009

Now that quickvoting has been turned on for me, I notice that it doesn't actually work a signficant portion of the time. I'm not sure if it's just me and my spotty connection, but it just says "Voting..." forever. How am I supposed to pass judgement on the work of others like this?!

Already mentioned in the catbox to OldMiner:
I did not receive a message from Cool Man Eddie or a note in my notifications nodelet when krenseby C!ed violence comes to me like a second nature. However, I did receive the 20 XP.

om adds:

With the switch to different hardware and InnoDB, we've seen a fair number of queries that are dying mid-update. I suspect tentative's not getting notified was caused by a query timeout, but couldn't find a relevant server error generated by krenseby on neither tcwest nor web6. However, this does point to a larger issue. Take a look at cool. We make inserts or updates to:

1. Write the cooler erself back to the database (updateNode())
2. Adjust the coolee's XP (updateNode())
3. Update the coolwriteups table (sqlInsert())
4. Update the cooled writeup itself (updateNode())
5. Potentially update the achieved table if a new achievement has been recorded¹ (sqlInsert())
6. Potentially update the notified table if a new achievement is displayed via AJAX cleverness (sqlInsert())
7. Potentially send a message via Cool Man Eddie (sqlInsert())

If any of these steps fails, the remainder never get run. This happens because something has set the DBI::RaiseError flag, so a die call is thrown when a sqlInsert(), for instance, times out, deadlocks, or fails due to the server being mid-shutdown. This seems like a minor issue for such things as hit counters not being updated or rep drifting slightly from real vote totals. However, it's clear that this can cause some weird circumstances if we have the cool opcode die in the middle of its normal sequence.

We can not ignore deadlocks, as they will happen occasionally with even the best-designed database layout under any properly locking database. We need to change the way we do updates and inserts to tolerate this problem, either by automatically retrying, when appropriate, or by recording the errors and taking remedial action automatically later.

I think we should discuss resolutions to this. The naive solution is to add an eval/retry loop inside of sqlUpdate and sqlInsert so that failures are less likely. We might also want to look into utilizing transactions, now that we have them, to commit related changes all at once. That would at least make it easier on us so we avoid having to write an error handler for every place we call updateNode or sqlInsert.

¹: Hey, Swap, guess what, I didn't even think about this with the slow cool achievements we fixed! Fixing the achievements made cooling itself far faster too. Good stuff.

Rootbeer277 has rearranged the cool opcode so that the eddie message now comes before the achievement update. This should reduce the number of failed eddie messages at the expense of extra achievement update failures.

1. Write the cooler erself back to the database (updateNode())
2. Adjust the coolee's XP (updateNode())
3. Update the coolwriteups table (sqlInsert())
4. Update the cooled writeup itself (updateNode())
5. Potentially send a message via Cool Man Eddie (sqlInsert())
6. Potentially update the achieved table if a new achievement has been recorded¹ (sqlInsert())
7. Potentially update the notified table if a new achievement is displayed via AJAX cleverness (sqlInsert())

Node backup is an awesome feature, thank you for providing it. However, one of my writeups contains a colon in the title. This causes node backup to generate a file with what Windows regards as an invalid filename; colons are not allowed.

The following characters are considered invalid by Windows:

\ / : * ? " < > |

My understanding is that this is a superset of the characters forbidden by Mac OSX and Linux.

Additionally, OSX has the restriction that a file may not begin with a "." character.

1. The "post" button in the scratch pads appears to be not working. Click, nothing happens. Such is life.
2. The homenode suspensions button is currently not working for me, either.

   om sez: This actually works, but just takes four minutes to run. (Please, avoid visiting this page unless you have to until I fix it. It's quite the DB hit.) Suspension Info is the culprit in this case, and it's displaying the same issue we were seeing before with writeups by type -- a select with a WHERE clause and an "ORDER BY title" clause, and the DB engine is using the title index resulting in a table scan. Will fix by doing the sort in Perl, as before.

   Fixed this with a patch.

3. I'm certain there was once a way to remove node_forwards. Not any more. Please someone, tell me how to do it!

   om sez: The pain-in-the-ass-way right now is to just make a URL string out of it: http://everything2.org/node/node_forward/the+node+linked+to+all+others?op=delete Only you god types can do this -- the poor editors are left out. A more intuitive way is in the list of things to do.

New Writeups Atom Feed seems to be truncating its output to about 65486 bytes which is suspiciously close to 65536. (it does getNode() on New Writeups Atom Source to get the actual data)

i bothered OM about it and he sleuthed: "getNode returns a tied hashref with data coming directly out of the DBI module. So there are multiple possible places for silent truncation: The SELECT from MySQL itself on the first query, the DBI module translation, Perl itself potentially having a limit on scalar length, and then it all happens again in the caching layer -- it's possible it isn't truncated onthe first pull, but then the SELECT from cachestore *does* truncate. So the maximum column length in MySQL for a varchar column is 65,535 characters. So odds are the truncation is happening in the cachestore, and the first serving of the page is not truncated. We store the hash of all of the node data in a database column, I believe. So the few bits missing from 65,535 are for the other columns, the column names, and the encoding overhead. What this really means is we should be more intelligent about how we cache so that too-long items either don't get cached or get cached in multiple entries to prevent this from happening. But this is all guessing. Should force this to happen on the dev server and test."

2009-Nov-10 om sez: My above statements were erroneous. Checked on web2 and the cache_store table (in the cache_store database -- watch out, someone made one in the everything database on db2) has the 'page' column as mediumtext -- and is automatically updated to have that column by a script on a regular basis. I updated the devel server to match, but that rules out my original theory. Also, we don't actually cache a hash of the node, like I thought, but just the actual generated HTML of the node (including container), as viewed by Guest User.

Visiting this node:

Once every thousand years a little bird comes to this rock to sharpen its beak

Causes this to happen:

http://picpaste.com/e2bug.jpg

I'm using Carbonated with a large style defacer; RedOmega reported the same thing in the catbox when I mentioned it. I'm running Firefox 2 v2.0.0.20. Just noticed it at 1:51 PM Pacific time.

Comment from in10se: The writeup source contains a comment block (<!-- ... -->). All the HTML tags within the comment block had their closing angle bracket set to "**" (example: if the tag was <em>, it said <em**). I changed all the **'s to >'s. This does not fix the bug, but it does fix the page display. It also unhides everything within the comment tag (which is probably a bad thing).

NOTE: Everything worked fine in IE8 (even with the **'s), but was broken in Firefox.

---

We have Everything's Most Wanted, which is the main page, and then two nodelets to go with it, Most Wanted and Everything Most Wanted. I hit both of the nodelets before I actually got to the main page, which is what I was looking for. Is it possible to make this less confusing?

In addition: I attempted to post a bounty on Leo Tolstoy before I noticed that GlowingFish had done the same already. It told me that it wasn't a valid node or nodeshell, and to select a new one. It seems to me that this should be a more specific error message.

---

I attempted to remove and then add a user to my list of Favorites in order to force an update on the Favorite Noders nodelet, and it appears that checking a username and then hitting submit doesn't actually do anything.

Actually, I take that back: It reset the other user settings on that page but didn't actually remove the user I had selected. I had to go to that user's page, hit "unfavorite", and then hit "favorite" to achieve the same effect.

And it appears that the Favorite Noders nodelet still didn't update with the most recent writeups. If it's a user-specific issue, the user in question was civilwaractionfigure; no one else on my fav noder list has posted recently enough to be on the list for me.

I have prole's enhancements and Everything2 Ajax enabled. I was able to vote on a writeup and not use up a vote by hitting the C! link. While the page was loading, I hit the upvote button. When the page finished loading, it showed a reputation that didn't match the vote count. The next page load had a correct count, but I still was not down a vote for the day.

om sez: This is the same as the infinite ching bug. I have an idea how to fix this, but I'm not sure how much of a database hit it might be. Since we have row-level locking under InnoDB, though, it might be viable.