This is a known bug with those broken blocking programs.

We're keeping it in mind for proposed changes to the image infrastructure but won't change purely for that reason.

dbenbenn wrote:

[[Adblock]], of course, is the most popular extension for Firefox, and is one of
"those broken blocking programs". (I.e., a user of Adblock is not unlikely to
put "*/ad/*" in their filter. Adblock itself is not at all broken.)

Another way to implement this fix is to just change the hashing algorithm so
that when it would normally return /a/ad/, it returns /a/ae/. Then move images
in /a/ad/ to /a/ae/. That's not as elegant as Ilmari's idea, but the benefit is
that most images don't change URL under that scheme.

brianna.laugher wrote:

I really wish there was a chance this might be changed. A few times now I have
been involved with trying to help users figure out why they can't see some vital
image while all others seem fine. After going through the usual suspects we are
left to ponder... until I happen to remember this stupid problem. Undoubtedly
this problem happens for many other users who /don't/ contact us, and
undoubtedly many of the admins they try to contact about this have no idea about
it, because they don't have the problem and it's only one in every 200 (or
whatever).

Basically it would be great if we could avoid randomly refusing access to users
just by disallowing one subdirectory.

PLEASE REPORT THE BUG TO THE MAINTAINER OF THE BROKEN AD
BLOCKER SOFTWARE.

mrbillcollector wrote:

Brion Vibber take a hike.

And it is not Adblock that is broken. It is the most popular filters for it that
is cause it to be broken.

This is called FilterSet.G available at http://www.pierceive.com/

Since just using that has a nice set of regex rules that blocks most users it is
what is causing it. Maybe if you wanted this fixed contact the owner of that and
tell him to fix it in his next update.

Cheers,

• Vikram Mohan

dbenbenn wrote:

(In reply to comment #4)

PLEASE REPORT THE BUG TO THE MAINTAINER OF THE BROKEN AD
BLOCKER SOFTWARE.

Brion, please don't yell, and please try to understand the bug that's being
reported. [[Adblock]] is not broken, the problem is simply that many people
have told their ad blocking programs to filter out /ad/. (For what it's worth,
I use FilterSet.G and it doesn't appear to block /ad/.)

The Commons Picture of the Day for June 3 will not display for many people
unless we fix this simple bug.

Is there any reason why it's necessary to keep that one directory, /ad/ ? Let's
just fix the hashing algorithm, move that one directory, and get on with our
lives. (Or implement Ilmari's earlier suggestion, which is more elegant but
would require a little more work.)

Five years ago all common ad-blockers had an exception for a/ad/. I strongly
recomment reporting this problem to theses no new programms.

robchur wrote:

For the *last time*.

This is not a bug with our software. This is an issue with those users who use
ad-blocking software and don't follow our workarounds for making certain files
available.

It's no different than a user using, say, lynx, complaining that
JavaScript-based preferences aren't working or that images can't be viewed.

We could implement workarounds, indeed. But that *is* a hackish solution to a
problem we didn't cause in the first place, and a tech. more senior than I has
already (correctly so, in my view) vetoed it.

dbenbenn wrote:

(In reply to comment #8)

For the *last time*.

Oh good. I'm glad you won't be reiterating this misconception again.

This is not a bug with our software. This is an issue with those users who use
ad-blocking software and don't follow our workarounds for making certain files
available.

Yes, it's possible to lay the blame on the users. That's true of many bugs.
But it isn't helpful. This issue harms users of MediaWiki, and in that sense it
is a bug. We can continue laying blame on others, or we can pragmatically
accept that we can't possibly fix all routers, firewalls, and ad blocker filter
sets in the world.

It's no different than a user using, say, lynx, complaining that
JavaScript-based preferences aren't working or that images can't be viewed.

Yes, it is. The difference is that there's an easy solution that can be
implemented in MediaWiki. (If we could make a tiny change to MediaWiki that
would allow Javascript to work in Lynx, would you veto that, too, by blaming Lynx?)

We could implement workarounds, indeed. But that *is* a hackish solution to a
problem we didn't cause in the first place, and a tech. more senior than I has
already (correctly so, in my view) vetoed it.

Again, it's easy to blame users, but that doesn't help anyone. Can you provide
any technical argument why it's impossible or undesirable to fix this genuine
problem? If not, it's simply obstructive to refuse to allow us to fix it.
MediaWiki developers could learn something about the open source model from
Wikipedia.

We can continue laying blame on others, or we can pragmatically
accept that we can't possibly fix all routers, firewalls, and ad blocker filter
sets in the world.

Again: Almost all add blockers have an exception for "a/ad". Those few new one
that don't have it, should be changed. Please open a feature-request in their
bug-tracker.

David, we're not blaming users. We're blaming the poorly
configured software hacks known as "ad-blocking software".

Please note that sooner or later we *will* change how uploads
are arranged in the filesystem and what their URLs look like.
And for that future change, we will keep this poorly configured
software in mind. But we're not going to change the existing
system *just* for this. Period.

So please stop wasting your time on this bug. Thanks.

• Bug 6020 has been marked as a duplicate of this bug. ***

The developers apparently don't want to do anything about this on the online software, but I
have patched my personal copy of the Wiki software to move everything in /ad/ to /ae/.

If anyone wants help doing this with their own copy, I'd be willing to help.

• Bug 11765 has been marked as a duplicate of this bug. ***

ssanbeg wrote:

Just my 2 cents: From what I've seen, the developers generally refuse to hack around problems in other software, or to screw over search engines by arbitrarily moving large numbers of URLs. Since this fix asks for both, there wouldn't be much hope for it.