Wedge

Almost nothing gets cached anyway.

I can't just blindly remove everything because other parts still use it! Do a search on read_tgz and see what you find...

Don't you mean "byte me" in reference to Android icon? :lol: I shouldn't try to be funny after only just having breakfast.

Also, yes, it will all go, I did think of removing the log table last night but saw it had at least two references and couldn't be arsed chasing them down last night.

So, I'm looking at the latest commit, plenty of good stuff, and a couple of things that required my attention:

- error.lock (cool thing BTW) is never created. Why doesn't it go through the same logic as the other lock file..? :geek:

- It's amusing that I never understood the logic in that Subs-Login block, and with your rewrite it's even fuzzier in my mind... :lol:

- The ob_end_clean() function is often called in SMF/Wedge, but never the same way. Sometimes it's just it, other times it's done with a while() on ob_get_level(), and finally my method: a single-line while (@ob_end_clean()); that will delete all buffers and stop at the last (because when none are left, PHP returns false.)
I modified all of the calls that seemed to require deleting all buffers, to do that single-line while() instead. Hopefully everything'll be okay.

- ob_end_clean() is called multiple times in the anti-prefetch code. I'm bothered with that one. First of all, having the same code repeated all over Wedge is a bit ugly, so I moved it to Subs.php in a preventPrefetch() function.
I need opinions on two things here:

- I added a $always parameter to it specifically for the call in MessageIndex, because it also sends a 403 when trying to load a board while the action is attempting to load an attachment. So this becomes basically preventPrefetch($and_also_if_loading_attachment), where $always will bypass the prefetcher test. That seems ugly to me... Isn't it?

- If MessageIndex prevents loading topics to ensure they're not 'read', why not do the same on topic pages..? Prefetching the next page means that if you're on a topic with 10 unread pages, next time you click on the topic from the MessageIndex list, you'll have skipped an entire page because it was marked as read... Instead of preventing prefetching, we could also just check whether the prefetcher is loading the current page, and if yes, skip updating the topic read/page read tables... But that means when we get to reading the actual page, it's loaded from the cache, and thus the tables aren't updated either. It would make more sense if prefetchers also sent an asynchronous extra request to that page to tell it that it's actually been read... But it's unrealistic to expect them to do it.

- At this point, do we want prefetchers at all on Wedge?! If not, then... robots.txt... Disallow Fasterfox. There may be other prefetchers to prevent, too. Or just add a rule to the htaccess file, I dunno.

Woohoo, Opera has just changed my textarea's font to a serif font... WHILE TYPING.?
Good job! And then it crashed on me. At least that serif problem was a good warning. Then I launched Chrome, and it crashed on me before I had time to send this.

It's interesting that back in my Windows XP + 2GB RAM days, I was able to run Opera with up to 900 tabs, albeit very slowly...
Now with Windows 7 + 8GB RAM, I've never been able to get above 200 tabs in Opera without it making my life hell, and Chrome is actually behaving better but after 400 tabs it's also much harder to work with...
Anyway!

Don't worry, it took me a few goes to make sense of it.

It always seemed to me to be clearer to indicate what you're doing and the one-liner, while efficient and compact, is not exactly conducive to its meaning. I'm cool with it, until I forget what it does and have to mentally shift to make sense of it ;)

I don't remember that in the anti-prefetch code. I thought it just caused things to die if it was trying to process a prefetch.

I'm not sure I follow how we get from messageindex to attachment :/ But I've only just got up.

The thing about prefetchers is that most of the time it's done purely with headers which can't always be sifted out so easily. Remember, not everyone uses Apache and not everyone has htaccess files even if using Apache.

Everything related to logging in escapes me, actually.

Guess what is the latest thing my girlfriend asked me..? She wants me to build her a small testcase where I'll supply a form for her to log into a site, and generate a session cookie. I'm okay with the form, but... Oh my, I know the basics of cookies and session communication, but it suddenly seems like I can't do anything about this! Argh.

Oh, I'm sure you'll at least remember this conversation....

The 'particular' piece of code was in Load.php, IIRC, not MessageIndex, sorry about that.
But MI still has a preventPrefetch() call. And Display doesn't, to answer your question.

I don't even know if people still use prefetchers these days... And whether or not Fasterfox is still the only one around!
Also, robots.txt isn't an Apache tech, so it should work on every server. (Provided the file is uploaded at the root of the domain name, if available.......)

Essentially this is about cases where users attempt to log in, fail, and we don't let them log in too many times.

The complexity of the testcase is the key thing here. If it's just about setting a session on validation then logging in, that's about as easy as it gets. Anything more than that really depends on how hardened it has to be against brute forcing.

Probably. Or more likely I'll find it, think WTF, remember that we discussed it, then swear at the search facility for a moment until I find this conversation.

Display.php, lines 86-92...?

robots.txt isn't an Apache tech, no. But not all prefetchers respect it, which brings me back to things in the headers (i.e. like FF used to do, hence the test for the X-Moz header) which can't be sifted out in robots.txt, but can in htaccess - if you're using Apache.

! Did I mention that I love the @language embedding into script files?

Set a default string from index, set it once and never have to explicitly set it again in any of the multiple places it is called (unless you *really* want to).

All this for the 'delete item' help text on the auto suggest... it's the same everywhere, so just embed it in to the suggester as a default! It bugged me, mkay? (all files)

@ And since it's now embedded in the suggest file, it will not only be gzipped and cached, it no longer has to be inlined into all the pages it's in, or declared in those pages where used. I would imagine that's actually a tidy little saving everywhere that uses the auto suggester, all in all. Every little helps.