FANDOM


  • This post aims to give you some more context on why Fandom is introducing file page redirects for anonymous users (announced in today’s Tech Update). Our goal is to make search engine improvements for the content you create across Fandom and to give logged-out readers a more straightforward, satisfying experience.

    As you probably know, Google not only pays attention to what is on a page, but also to how it’s presented. It looks for user-friendly pages that are easy to navigate on mobile and tends to rank these higher. The vast majority of traffic to your wikis comes from Google searches, so Fandom’s team is constantly working on making sure the great content you create is valued by Google and not falsely categorized as “low quality” for structural reasons. Late last year, we made an update to how category pages look for that same reason.

    File pages (those with URLs ending in …fandom.com/wiki/File:) are vital elements of a wiki community, used frequently by editors and play an important role on the wiki. For casual readers, however - and those make up the vast majority of people visiting your wiki - they are confusing. Visitors who land on a file page often end their visit right there because they find little information that’s meaningful to them. That’s why Google thinks file pages are “low quality” pages and doesn’t like to show them in search results. To make matters worse, this can have a negative effect of Google’s evaluation of a wiki’s content as a whole, and result in article pages being ranked lower as well.

    We figured, redirecting anonymous users (which includes Google bots) from file pages to the corresponding article pages, where they can see files in context, might help solve both of these problems. We ran multiple tests to confirm this hypothesis. In the spring of this year, we tested file page redirects for several weeks on ten larger communities such as the Harry Potter Wiki and the Pokémon Wiki and indeed found that it increased the wikis’ visibility on Google overall. As we found no negative consequences, we expanded our test in September to 100 communities on many different topics, and were once again satisfied by the results.

    An important point about changes we make for the sake of search engine optimization is that they’re not always about directly boosting traffic. Often, they’re about fortifying ourselves against future Google algorithm changes and making sure search engines continue to view our wikis as high-quality content sites.

    That’s why we will be redirecting logged-out users on all Fandom communities to the first article page a file was used on instead of showing them the file page itself, starting tomorrow. That way, they will see context and additional information, and have a better opportunity to discover more of the great content you created. At the same time, it ensures that Google’s bots don’t get hung up on what they perceive to be “low quality” file pages.

    Logged-in users are not affected by this change. The vast majority of traffic even from logged-out users falls on content pages, not file pages, so even among anonymous users, few should notice anything changed.

      Loading editor
    • As mentioned in the TU, the "first page" is the first/oldest still existing page the image was added to, not (necessarily) the page at the top of the list of uses on the file page.

      I've got another question - does using images in maintenance notices negatively impact this part of search engine algorythms?

        Loading editor
    • Can you be more specific about what the “first” page a file is used on is considered to be? It is literally the very first page a given image was ever added to, the first Wiki that appears alphabetically in Special:WhatLinksHere as a file link, or the most high-traffic page a given file is used on?

      3fast Tupka xD

        Loading editor
    • Just to clarify (since I personally found Tupka217's wording a bit confusing), it is the first page the image was added to; not the oldest page the image was added two. The difference being that one criteria is concerned with when the image was added and the other is concerned with when the page was created. At least, that is my understanding from what was said in the other thread.

      Here are my questions:

      What about pages that use to have the image? I am assuming they are ignored like deleted pages but that has yet to actually be stated.

      I am assuming images in infoboxes count. Working with that assumption, if the image is not the first tab in an infobox image gallery, will the tab be auto-selected when the redirect occurs or will users have to find the correct tab themselves?

      Is there a way for anons to override the redirect behavior? For the wiki I admin, a lot of our images show up in Google's image search. If a user is following the link from an image search, I would imagine they are indeed interested in the image itself. On a related note, how would this change impact Google's indexing of the images themselves?

        Loading editor
    • Andrewds1021 wrote:

      (since I personally found Tupka217's wording a bit confusing)
      

      That's what happens when you add caveats later for completeness' sake. New attempt: the first page it is added to. If that's been deleted, the next page it's been added to. If the image is unused, it redirects to main page.

      The list of page uses on a file page, as well as the list in WhatLinksHere, is based on the order of page creation, not image addition, so that's not relevant.

        Loading editor
    • Exactly, thanks, Tupka.

      @Andrewds1021: If pages used to have an image, but don't have one now, they're not relevant in this particular case. A file page won't redirect to a page that doesn't actually have that image on it - unless the image isn't on any pages, in which case it redirects to the main page.

      To your question about images used on an infobox tab: That's a good one, I don't actually know. Let me ask the devs and get back to you!

        Loading editor
    • Similarly, what happens if an image is included in an infoboxe's section tag or tabber? So, I guess my previous question could be amended to ask about tabs in general, not just infobox image galleries.

        Loading editor
    • will registered users be able 2 specify that in their preferences?

        Loading editor
    • F039A6C4 wrote: will registered users be able 2 specify that in their preferences?

      This won't apply at all to registered users.

        Loading editor
    • Andrewds1021 wrote: Similarly, what happens if an image is included in an infoboxe's section tag or tabber? So, I guess my previous question could be amended to ask about tabs in general, not just infobox image galleries.

      Ok, so for tabs in general, the correct tab won't be selected when an anon user gets redirected. They get redirected to the page URL, by the page loads its default setup (first tab showing). There's no alternate URL for specific tabs, so that's the best we can do. The few anon users who will go through this use case will have to find the image on the page by looking for it.

        Loading editor
    • Okay, thanks for the answer. That being said, I know for a fact that it could be done for top-level Tabber tabs. I don't recall when it was but I remember you guys turning the Tabber tags into anchors some while ago; and it appears to still be the case. Of course, it may not be worth the effort to put that in as I am pretty sure it only works for Tabber and only top-level tabs (i.e. won't work with nested tabs).

        Loading editor
    • It could probably be done, yes - but it's not worth the extra effort, given what a small number of people would be impacted.

        Loading editor
    • So this new behavior seems to violate the spirit of some licensing (not being able to see info about the source, the license, and any additional credits), if not exactly the exact wording. I don't think you can see any licensing info in the lightbox.

        Loading editor
    • I hadn't even thought of that. Here are two observations that I don't think have been mentioned yet.

      1. The image name displayed by the lightbox becomes regular text instead of a link to the file page.
      2. Clicking the info icon in the lower right of the image (which links to the file page) seems to always take you to the lightbox on the homepage even if the image is used on a page.

      To answer my own question, it doesn't look like there is a way for anons by bypass the redirect. At least, there is nothing obvious and the "?redirect=no" that MediaWiki uses for redirect pages also doesn't work. Anons can still, however, access the image on vignette via the same links registered users would.

        Loading editor
    • The image on vignette has no licensing info or credits... so maybe licenses are actually being directly violated, not just in spirit.

        Loading editor
    • 452

      Ah, I had been wondering why people were complaining of downloaded images being broken.

      Exactly how are anon users supposed to be able to download the original version of the file?

      If they click "See full size image", they aren't taken to "&format=original", they are taken to your shitty webp version, which saves as a .jpg or .png, and they are told it is corrupt if they try to open it on their computer.

      Here's an idea: when you display an image recompressed as a webp, simply don't LIE about what type of file it is. It you're going to convert it to webp, then show .webp instead of .jpg!


      Mira Laime wrote:

      [...]we tested file page redirects for several weeks[...]

      [...]we found no negative consequences[...]

      Several weeks? In less than 1 week, someone told me an image they downloaded was corrupted.

      Now that I know what is going on, I've thought about this for several minutes, and come up with a list of negative consequences.

      • Anon users have no convenient way to download a usable image.
      • Anon users have no convenient way to download the original image.
      • Anon users have no convenient way to see the page history.
      • Anon users have no convenient way to see the file upload history.
      • Anon users cannot see previous file versions at all.
      • Anon users have no convenient way to see where else a file is used.
      • Anon users have no convenient way to access the file talk page.
      • Anon users have no convenient way to add a delete template to a file page.
      • When redirected to an article after clicking a used file, there is no indication that a redirect has taken place, no "redirected from file". An anon user will have no idea why they were taken to that page, and will think they clicked the wrong link.
      • When redirected to an article after clicking a used image, there is no lightbox displayed, and the user has to hunt through the page to find the image they were looking for.
      • If an image is formatted in the article as [[File:Image.jpg|link=File:Image.jpg]], (EDIT: and is only used in that 1 article) then clicking that link just refreshes the article, and does not show the lightbox, so the anon user has no convenient way to see a larger version of the image. (Edit: if the image linked that way is used in multiple articles, then it will take them directly to the other article instead of opening the lightbox)

      This may be the first time I've agreed with something Andrewds1021 has said, but simply allowing "?redirect=no", and using it in a "see file page" link in the lightbox, would fix the majority of these. (And if you don't want Google to index the "?redirect=no" File page, there's "noindex, nofollow" to do that.)

      The other 2 can be fixed by ALWAYS showing the lightbox popup when redirected, and not only for unused images.


      edit: And exactly how the FLYING EXPLETIVE are anon users supposed to view/download PDFs now?

      Or did you forget AGAIN that other files exist which are not images?


      Edit: Also: File:Anon_users_CAN_see_the_image_licence.png


      edit:

      I think I've figured out what is going on, and why Wikia Staff are making this change, which is fundamentally against the principles of wikis.

      This is step 1 in their "path to Lucy".

      First, they are going to desensitise anons - the silent majority - into the concept that they do not have access to page history and large images.

      A later step will probably involve a complete shift to the kind of images used in Discussions: No file pages, no history, nothing.

      Experiments like Venus and Lucy show us exactly what Wikia WANT.

      Everyone was vocally against Venus, and they scrapped it, but then slowly added in multiple elements over time. They were less public with Lucy, but people were still vocally against it. But why wouldn't they follow the same pattern with Lucy and implement it piece by piece?

        Loading editor
    • Well, if they don't have a way to get the licensing, perhaps it is a good thing they can't (easily) get usable images. That being said, I think making it impossible for them to see the file page is going a bit too far.

        Loading editor
    • To add on to 452's list of oversights: If a wiki has made any effort to organize its images, say by categorizing them according to their subject or origin, then that organization becomes largely useless to readers who aren't logged in. See for instance the convenient link provided at w:c:harrypotter:Harry_Potter#Appearances, which sends readers to a category of 2,898 images of the Harry Potter character. How are readers supposed to take advantage of this? As of last November, the thumbnails within the category are so small as to be worthless, and now readers potentially need to scour the dozens of articles that they're redirected to just to see what the tiny thumbnails are supposed to be of. It's actually the images that aren't used in any articles that are the easiest to access, because those are at least opened in a lightbox on the main page (example).

      Some way of overriding the redirection would be appreciated, or if not that then force all image redirects to open in a lightbox, even those displayed in content pages.

        Loading editor
    • Tupka217 wrote:

      F039A6C4 wrote: will registered users be able 2 specify that in their preferences?

      This won't apply at all to registered users.

      why

        Loading editor
    • F039A6C4 wrote:

      Tupka217 wrote:

      F039A6C4 wrote: will registered users be able 2 specify that in their preferences?

      This won't apply at all to registered users.

      why

      Why would you want to set this behavior for you the same as for anonymous users? It seems to be worse in every way and is only implemented as a necessary evil.

        Loading editor
    • Evil, yes... necessary... debatable.

        Loading editor
    • Please disable IP's being revealed for anonymous users.

        Loading editor
    • PigLoverGoComics wrote:

      Please disable IP's being revealed for anonymous users.

      This is the wrong place for this request. Try "Contact us".

        Loading editor
    • For anyone who cares about this IP thing, see this separate thread.

        Loading editor
    • Andrewds1021 wrote: To answer my own question, it doesn't look like there is a way for anons by bypass the redirect. At least, there is nothing obvious and the "?redirect=no" that MediaWiki uses for redirect pages also doesn't work. Anons can still, however, access the image on vignette via the same links registered users would.

      For those very rare anons that really do want to see the file page, for whatever reason, they can log in. Someone who knows what a file page is and why they need to see it is likely savvy enough to figure that out (and indeed we've not had complaints during the months that we tested this). There is still going to be the odd user who is negatively impacted, by this, yes. That's a price we decided is worth paying in order to get the SEO improvements.

      It's entirely possible that there are still bugs to iron out, and the issue with downloaded files that you can't open sounds like one. We'll have to look into this.

        Loading editor
    • Heh, I am a Content Moderator(tropico.fandom) and no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off. Must be one of those glitches to iron out, but I'll probable just find another means until the gamepedia merger is finished in 2022, shrug.

        Loading editor
    • Jade Emperor wrote: Heh, I am a Content Moderator(tropico.fandom) and no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off. Must be one of those glitches to iron out, but I'll probable just find another means until the gamepedia merger is finished in 2022, shrug.

      If you're logged in, that sounds like a bug, have you tried to contact Fandom Staff about it? (since there's no preference, it just shouldn't redirect you from the file page if you're logged in.)

        Loading editor
    • Sophiedp wrote:

      Jade Emperor wrote: Heh, I am a Content Moderator(tropico.fandom) and no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off. Must be one of those glitches to iron out, but I'll probable just find another means until the gamepedia merger is finished in 2022, shrug.

      If you're logged in, that sounds like a bug, have you tried to contact Fandom Staff about it? (since there's no preference, it just shouldn't redirect you from the file page if you're logged in.)

      I am sure they tested the changes and it works exactly as they intended; so authorities in this thread states. Not wasting my time filing in a form when I just reported my issue to the authorities in #25.

        Loading editor
    • Jade Emperor wrote:

      Sophiedp wrote:

      Jade Emperor wrote: Heh, I am a Content Moderator(tropico.fandom) and no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off. Must be one of those glitches to iron out, but I'll probable just find another means until the gamepedia merger is finished in 2022, shrug.

      If you're logged in, that sounds like a bug, have you tried to contact Fandom Staff about it? (since there's no preference, it just shouldn't redirect you from the file page if you're logged in.)

      I am sure they tested the changes and it works exactly as they intended; so authorities in this thread states. Not wasting my time filing in a form when I just reported my issue to the authorities in #25.

      Mira also says that "It's entirely possible that there are still bugs to iron out" in the reply right above yours.

        Loading editor
    • Sophiedp wrote:

      Jade Emperor wrote:

      Sophiedp wrote:

      Jade Emperor wrote: Heh, I am a Content Moderator(tropico.fandom) and no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off. Must be one of those glitches to iron out, but I'll probable just find another means until the gamepedia merger is finished in 2022, shrug.

      If you're logged in, that sounds like a bug, have you tried to contact Fandom Staff about it? (since there's no preference, it just shouldn't redirect you from the file page if you're logged in.)

      I am sure they tested the changes and it works exactly as they intended; so authorities in this thread states. Not wasting my time filing in a form when I just reported my issue to the authorities in #25.

      Mira also says that "It's entirely possible that there are still bugs to iron out" in the reply right above yours.

      lol, Its their server time and bandwidth to waste on an extra page serve. Interim solution seems to be left click and select the 'File:' page from there using right click> new tab.

      imo, Only real justification for this change was Google Bot page hit count. Unregistered permissions can handle any vandalism issues. Still, no way of curbing image theft until they implement no right clicking for the UU which is just 'kids-at-play' easy to circumnavigate. Yep, Fandom needs to make the service pay-to-play private; Im deaf so shout as much as you like, it is mostly a joke too.

        Loading editor
    • 452

      Mira Laime wrote:

      [...]we found no negative consequences[...]

      Mira Laime wrote:

      There is still going to be the odd user who is negatively impacted, by this, yes.
        Loading editor
    • For the sake of SEO I think this change will outweigh the negatives considering tech savvy anons (such as myself) know how to manipulate the URL i.e. add ?redirect=no to see the file. Anons coming in from Google who don't know what URL queries are, never mind MediaWiki ones, should be fine. Although I do agree with 452's suggestion with noindexing a file link with the ?redirect=no

        Loading editor
    • Mira Laime wrote: For those very rare anons that really do want to see the file page, for whatever reason, they can log in. Someone who knows what a file page is and why they need to see it is likely savvy enough to figure that out (and indeed we've not had complaints during the months that we tested this). There is still going to be the odd user who is negatively impacted, by this, yes. That's a price we decided is worth paying in order to get the SEO improvements.

      It's entirely possible that there are still bugs to iron out, and the issue with downloaded files that you can't open sounds like one. We'll have to look into this.

      Perhaps, this was already thought about. Indeed, most anonymous users would primarily be readers and not dig so far to know these savvy stuff. It should be kept in mind, though, that anonymous users can still be prolific editors. Not every wiki has anonymous editing disabled, so it's entirely possible for users to become savvy enough to be contributors without identity.

      They could sign up, but it would not be too wise to force users to create an account. Some users likely didn't create an account for a reason, whether it's from necessity or personal reasons. I don't think the choice should be swept away to regain important permissions like viewing the file pages. That's my opinion, at least.

      452 wrote:
      If an image is formatted in the article as [[File:Image.jpg|link=File:Image.jpg]], then clicking that link just refreshes the article, and does not show the lightbox, so the anon user has no convenient way to see a larger version of the image.

      I tested this with a non-existent image. I'm taken to the wiki's home page, but the lightbox (not sure that's the name) displays. Supposedly, the lightbox will only appear if an image link is non-existent. Perhaps, an image linking to a page should then be viewable at a bigger size if the redirect will lead to the current destination. Good catch.

      Fandyllic wrote: So this new behavior seems to violate the spirit of some licensing (not being able to see info about the source, the license, and any additional credits), if not exactly the exact wording. I don't think you can see any licensing info in the lightbox.

      You can. See this image as an anonymous user and hover over the file title to display the licensing info.

      Anonymous users will basically see the image as described on the file page. You can add more info to tell anonymous users more, like on this Steven Universe image. The biggest question is how to make it look prettier to anons. Hmm.

        Loading editor
    • Cheeseskates;

      Have you tried to copy and paste relevant info for a complete citation from the overlay popup? I'm thinking the net effect is going to increase frustration for Image gallery surfers, who are simply looking for something to put on their 'website'. Frustration means more likely to not properly cite the images used.

      Just takes a 'right click > open in new tab' to get the full sized image, then the frustration start for the ethically minded individual.

        Loading editor
    • Jade Emperor wrote: ... no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off.

      I sort of understand this problem. There are two scenarios:

      1. A file page for the image does not exist. Left-clicking the image would do nothing.
      2. A file page does exist, but you're clicking "open image in a new tab" instead of "open link in a new tab", which is what leads to the file page than the image page. An alternative is hovering over the image and clicking the (i) symbol, which takes you to the file page.

      Hope this helps!


      Have you tried to copy and paste relevant info for a complete citation from the overlay popup?

      > I'm not sure what you mean here. You can copy-paste the text displayed in the overlay.

      I'm thinking the net effect is going to increase frustration for Image gallery surfers, who are simply looking for something to put on their 'website'.

      > I would personally use sites like Imgur or Shutterstock.

      Frustration means more likely to not properly cite the images used.

      > Indeed, it's good not to frustrate users too much. In my experience, the mere requirement to always search for licenses for images has convinced me to only use sites with free licensing, which itself was difficult to find. Though biased from experience, I think image gallery surfers who are concerned about citation or licensing would take the extra care to cite their sources properly. Since my above link is of images under CC-BY-SA and Fair use respectively ordered, all the surfer has to do is give the same proper attribution.

      Just takes a 'right click > open in new tab' to get the full sized image, then the frustration start for the ethically minded individual.

      I'm not sure what you mean. You can right-click and open the image in a new tab. You save the image, and you go to the origin tab to copy-paste the overlay details/licensing for citation. You could also copy the details first and then save the image without frustrations amounting moreso than if you weren't an anonymous user. If I misunderstood, let me know.

      As of now, though, I'm not seeing much issues with the experience received by image gallery surfers searching things for their own website. It's difficult and tedious to comply with licensing and citation on any website, so complying people would already understand the work needed. Even then, the solution is simple or can be replicated better by sites like Imgur or Shutterstock, which intend to be image hosts. Fandom does have things that could be improved or are misguided, but they have done many things right that are yet to be considered so.

        Loading editor
    • From fandom.com/licensing page, "Non-text media on FANDOM should not be assumed to be available under the same license as the text. Please view the media description page for details about the license of any specific media file."

      Do you now see the greater issue, fandom is requiring registering to view the licensing. Sure there is some info on that overlay, but not the entire media description page.

        Loading editor
    • 452

      You do NOT have to register to view the licensing information:

      I do not understand why everyone is acting as if the image license is unavailable for anons.

      It's right there.

      There are many other valid problems, but everyone seems hung up on this one thing which is a non-issue.

        Loading editor
    • Hmm, can mediawiki take legal action and prevent Fandom from using their software if found that they are violating the spirit of the software license?

        Loading editor
    • Mediawiki is free and open source... "spirit" is not a concept defined in any legal or, well, any, way.

        Loading editor
    • I don't click on images often, so I could be mistaken. However, this doesn't seem like new behavior to me. You should still be able to get to teh file page by hovering over the image and clicking the info icon that appears in the lower-right corner of the image.


      I had some comments for the Jade Emperor-452-Cheeseskates discussion but they all seem to have been mentioned eventually somewhere in the long exchange.

        Loading editor
    • Tupka217 wrote: Mediawiki is free and open source... "spirit" is not a concept defined in any legal or, well, any, way.

      Mediawiki license [1] includes this clause "No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits. "

        Loading editor
    • Fandom's forked MediaWiki is on GitHub. The relevant parts have a similar license to the original, I think. So they don't apply legal terms or technological measures that legally restrict others from doing anything the license permits. That sentence does not mean what you think it means.

      Mediawiki has innate features that restrict editing and restrict reading for logged out users. Anons not being able to view an image license except through an extra step... how?!

      Also, fix your link.

        Loading editor
    • Cheeseskates wrote:

      You can. See this image as an anonymous user and hover over the file title to display the licensing info.

      Anonymous users will basically see the image as described on the file page. You can add more info to tell anonymous users more, like on this Steven Universe image. The biggest question is how to make it look prettier to anons. Hmm.

      Well, this is a good thing, but still there should be a better way for anons to see licensing info... like a (?) button or something.

        Loading editor
    • Oh the right click behaviors have changed for me as a registered user with Content Moderator privaleges so I gather they are working on the issues.

      Thanks to whomever is fixing it. -may be a while before it filters down to other wiki, I'll check back tomorrow.

        Loading editor
    • Vengir wrote:

      F039A6C4 wrote:

      Tupka217 wrote:

      F039A6C4 wrote: will registered users be able 2 specify that in their preferences?

      This won't apply at all to registered users.

      why

      Why would you want to set this behavior for you the same as for anonymous users? It seems to be worse in every way and is only implemented as a necessary evil.

      why, u ask? well just 2 try it out since i HATE logging out of fandom

        Loading editor
    • That seems like a rather frivolous reason to add a user preference.

        Loading editor
    • Andrewds1021 wrote:

      ...You should still be able to get to teh file page by hovering over the image and clicking the info icon that appears in the lower-right corner of the image...

      How exactly are mobile users supposed to hover and right click an image again? Remember, the community isn’t only desktop users. If I’m watching TV, and someone sends me a message about something on a wiki I regularly edit... I need to be able to look it up quickly, I don’t necessarily want to bother with turning on a desktop/laptop and logging in to read, edit, or upload something on a file page.

        Loading editor
    • Well, you can do it the same way you use the local navigation submenus. I would imagine it depends on the browser but for Safari on iOS, you tap the image once to put it in a hover state. That displays the info icon which you can then click.

        Loading editor
    • The "Mobile Main Page" allows admins to set up several items as "Featured Content", which are shown in a slideshow near the top of the mobile main page on mobile devices. When I put a video file as one of those items, tapping onto it, redirects me to the mobile main page (instead of the video). What's the best way to fix this?

      Also, is there a way to deactive the mobile main page for a wiki? 

      EDIT: As a temporary solution, I'm now only featuring a single page with links to all the featured content. This is actually not too bad because it means that I no longer have to use that silly "Edit mobile main page" dialog.

        Loading editor
    • With regards to your second question: no.

        Loading editor
    • Ummm... did we get way, way off topic?

        Loading editor
    • Fandyllic wrote:
      Ummm... did we get way, way off topic?

      Errr ... I think the problem of broken links when using video files as "Featured Content" on the "Mobile Main Page" is directly related to the change that was announced by the original posting.

        Loading editor
    • Hi. I'd like to start by stating that I have used this site for years. Thank you so very much for finally forcing me to create a gorram account. I shouldn't have had to. This update was an absolute nightmare for me, a former anonymous user. This has seriously undermined my enjoyment of this site, and I hope that it one day may come back. But that does not change my opinion of this "update".

        Loading editor
    • I gotta say, that is one royally messed up change you guys at Fandom have made. I can understand not allowing hotlinking, and to re-direct incoming visitors to articles with more informaion, but to, essentially "disable" images when you're ALREADY BROWSING THE WIKI ITSELF because you didn't sign up and log in, is wrong on SO many levels.

      I say this from personal experience with browsing the site on a new tablet I just bought. You see, I'm a co-admin at the Ghostbusters Wiki (https://ghostbusters.fandom.com), and in the past I've always been permanently logged in on all of my devices. Being that I just set up the new tablet a week ago, of course, I wasn't originally logged in. I didn't even notice that I wasn't logged in because I was not doing any editing; just browsing.

      What happened with me, is that whenever I clicked on a thumbnail to view an image on the Ghostbusters Wiki from the Gallery section of an article, or the Recent Wiki Activity page, it would go to the article the image is "linked" to instead of the image.

      To put it another way... Due to your change, you DISABLED IMAGES ON ALL WIKIS FOR USERS ALREADY BROWSING THE WIKI(S) just because they're not logged in. These visitors are not coming in from Google, they are ALREADY ON FANDOM. You might as well have put a blockage on each Wiki page saying, "If you want to view this Wiki properly, you need to sign up and log in." - because that's what your change has done for all Wikis.

      -- Paul R.

        Loading editor
    • I have run into that annoyance as well. However, that is not the main reason why I am not a fan of having no workaround for anons. As registered users, it really isn't that hard to just sign-in. The issue I have is that there may be anons who don't want to (or can't) create an account. Honestly, that is the way I felt when I first came across FANDOM (then Wikia). I just contributed anonymously to my wiki of choice because I wasn't to sure how long I was going to hang around. It was only after getting a better sense that I would be around for a while that I decided to go ahead and register.

        Loading editor
    • Ironically, I’ll now log OUT more often to check what my contributions look like for anonymous users.

        Loading editor
    • I don't log out, I just open an incognito window.

        Loading editor
    • Wikia have made a lot of wikis registered only to edit in the past few years. I believe they are slowly phasing out anonymous editing experience as a whole and gradually forcing them to join with an account. A shame because freedom of anonymous editing was what gave Wikia an edge over some of its competitors.

        Loading editor
    • 90.253.123.68 wrote: Wikia have made a lot of wikis registered only to edit in the past few years. I believe they are slowly phasing out anonymous editing experience as a whole and gradually forcing them to join with an account. A shame because freedom of anonymous editing was what gave Wikia an edge over some of its competitors.

      For those wikis that are targeted at younger viewers, the deciding factor was COPPA. For most others, it was the community itself that decided it.

        Loading editor
    • I know I'm way late to the party, but I thought I'd throw in my voice of disapproval as well. Chucking content unsavory to web crawlers onto the deep web is bad practice and highly ill-conceived, in my opinion. There are legitimate tools put in place to accomplish this, it's as simple as listing noindex, nofollow in robots.txt or a meta tag.

      Wikis are supposed to encourage anonymous editors to create accounts and contribute. I totally get that hiding how the sausage is made provides a more cohesive and less confusing experience, but it's contradictory to the spirit of what a wiki is.

      At my wiki, we address this by requiring that every single file uploaded provides a description, the original source, the author/artist, the license, and a category for the image (or other file), neatly presented in a file infobox. The template is even preloaded in the upload form for convenience. Here's a recent example.

      I understand that not every wiki does or can do this, but to me the aforementioned data should be requisite information that must be provided for a file to be uploaded. I imagine if these requirements were put into place it'd also ensure a certain level of quality of file uploads, instead of the current image spam found on almost every other wiki.

      Point is, this kinda sucks for wikis like mine where we put in the work to make file pages presentable and of invaluable utility. In fact, PDF scans are some of our most popular files according to recent analytics, and they're used in citations as sources. Implementing this would be a non-negligible blow to our viewership and resourcefulness, which is frustrating considering there's a way better and more popular alternative solution to the SEO problem.

        Loading editor
    • I am a bit confused. Your first paragraph sounds like it is in favor of the change but the rest of your reply is against it. With regards to noindex and nofollow, they do not stop crawlers from indexing the content/follow the link. The tags are simply requests that crawlers don't index the content/follow the link. A crawler is perfectly free to ignore those tags if it wants. I assume that this change in behavior mitigates that issue to some extent if not entirely.

        Loading editor
    • I am in favor of hiding file pages from search engine crawlers, but not redirecting anonymous users to articles. And while it's true noindex, nofollow are merely requests, Google honors them if put in a meta tag. And before anyone gives the cynical "as far as we know" response, Google open-sourced this part of their software and it's easily verifiable (see above link).

        Loading editor
    • Tupka217 wrote:

      90.253.123.68 wrote: Wikia have made a lot of wikis registered only to edit in the past few years. I believe they are slowly phasing out anonymous editing experience as a whole and gradually forcing them to join with an account. A shame because freedom of anonymous editing was what gave Wikia an edge over some of its competitors.

      For those wikis that are targeted at younger viewers, the deciding factor was COPPA. For most others, it was the community itself that decided it.

      Fandom has no intention to phase out anonymous editing. Tupka is right: Where anon editing is disabled, that's either because the wiki's topic is aimed at children and we want to reduce the chance of harmful vandalism and spam, or because the community themselves have requested it.

        Loading editor
    • I hate this change since besides the licensing and image categories issues already mentioned, it also breaks links to the images from outside sites. You should definitely make it so anons can view the file page by adding "?redirect=no".

        Loading editor
    • Know what I hate? One of my friends who I believe is still an anon can still access images from fandomwikis, while I can't, so this isn't even affecting every anon. If he clicks an image, he gets the full sized thing. I click one, I get sent back to the top of the page the image is from.

        Loading editor
    • There are still ways anons can get to the full image; they just can't get to the wiki's file page for that image. Why don't you ask your friend how he does it?

        Loading editor
    • 68.69.226.213 wrote:
      If he clicks an image, he gets the full sized thing. I click one, I get sent back to the top of the page the image is from.

      ^

        Loading editor
    • "clicks and image" can mean more than one thing. Did he left click or right click? Did he click the picture itself, the name, the caption, the little icon that shows in the corner when you hover, ect.? Does he have any browser settings or ad block software that allows him to do this by bypassing the script that refreshed the page?

        Loading editor
    • other anons simply left click an image and bam, image opens up, meanwhile like I said, I just get redirected to the page itself, and thus booted back to the top. I don't believe he has any software that helps him bypass this.

        Loading editor
    • Have you tried using the same images as him? When an anon left clicks an image on a page and the image has not been linked to another page, the lightbox is supposed to open. Are either of you getting that? Perhaps that is what he means by "full size"?

        Loading editor
    • Yes I've tried all the same images as them, we've both tried on the same wikis, they get the lightbox, I don't. They were even able to link me to the full sized image with right clicking and copying the image adress afterwards. Meanwhile, I click on an image, I don't get the lightbox, I just get booted to the page the image came from, so basically booted back to the top of the page.

        Loading editor
    • If you go to a file page, like File:Example.jpg, its supposed to take you to the first page where the file is used, and open the image in a lightbox, also if you click on an image on a page, its supposed to open a lightbox. If it doesn't do that, have you tried checking your console for any errors/disabling browser extensions/trying a different browser/disabling your AV or etc (if you have it)? Also what device and browser are you using to view the wiki?

        Loading editor
    • device is a windows 10 computer, current browser is google chrome, though I may be changing that latter bit.

        Loading editor
    • 452

      Sophiedp wrote:

      If you go to a file page, like File:Example.jpg, its supposed to take you to the first page where the file is used, and open the image in a lightbox

      This statement is false, and has never been claimed in this thread.

        Loading editor
    • 452 wrote:

      Sophiedp wrote:

      If you go to a file page, like File:Example.jpg, its supposed to take you to the first page where the file is used, and open the image in a lightbox

      This statement is false, and has never been claimed in this thread.

      Uh, its literally mentioned at the very start of this thread?

      Mira Laime wrote: That’s why we will be redirecting logged-out users on all Fandom communities to the first article page a file was used on instead of showing them the file page itself

        Loading editor
    • 452

      That says absolutely nothing about opening the lightbox.

      My comment enumerating the issues explicitly mentions the fact that the lightbox is NOT opened, and explicitly lists "always opening the lightbox when redirected" as a remedy.

      So it if was "supposed to" "open the image in a lightbox" after redirecting, why didn't anyone mention that after my comment?

      edit:

      On the contrary, Snapper2 responded to what I said, confirming and agreeing.

        Loading editor
    • 452 wrote: That says absolutely nothing about opening the lightbox.

      My comment enumerating the issues explicitly mentions the fact that the lightbox is NOT opened, and explicitly lists "always opening the lightbox when redirected" as a remedy.

      So it if was "supposed to" "open the image in a lightbox" after redirecting, why didn't anyone mention that after my comment?

      oh I thought you were talking about something else. Also, have you checked your console/used a different browser/tried disabling your extensions/etc? Because when I go to http://su.wikia.com/File:Steven.png I get redirected to https://steven-universe.fandom.com/wiki/Steven_Universe_Wiki?file=Steven.png

        Loading editor
    • 452
      Sophiedp wrote:
      oh I thought you were talking about something else.
      I quoted up to and including your words "and open the image in a lightbox".

      I did not do that by mistake.

      The purpose of quoting is to specify the context of the reply.

      The quote in my comment clearly specifies that the context of my reply is your statement about used images being redirected and displaying the lightbox.

      Quoting the entirety of the comment immediately preceding yours is pointless, and is a common mistake amongst new users. From your entire-quoting and failure to recognise context from my clipped quote, I can only assume that you are a new user, so welcome to the wiki!

      Sophiedp wrote:
      Also, have you checked your console/used a different browser/tried disabling your extensions/etc?
      No, and I have also not tried turning it off and then back on again.

      There is no reason for me to try pointless troubleshooting steps, because I am not the one having trouble.

      That image is NOT used in an article, as clearly demonstrated by the fact that it redirects to the main page, and not an article in which it is used.

      Again: the context of my reply was your statement about used images being redirected and displaying the lightbox.

      So linking to an unused image is irrelevant and pointless.

      I already mentioned my first comment in this thread, but you clearly did not scroll up and read it. If you had bothered to read what I said about used images and lightboxes, as well as the reply from Snapper2, then perhaps you wouldn't be confused about when the lightbox is and isn't shown.

      My point stands:

      No-one has ever claimed that used images are "supposed" to show a lightbox when being redirected to the article they are used in.

        Loading editor
    • 452 and Sophiedp, you guys are arguing over a point that is irrelevant to the current question. The anon is not trying to navigate to the file page, they are clicking the in-article image.

      Just for the record though, based on my testing, I have to side with 452 on this. When I go to a file page as an anon, I just get the page, not the lightbox. The exception to that is when the image is not used. In that case, I get taken to the main page and the image is displayed in the lightbox.

        Loading editor
    • There is one thing I didn't mention. I made it to this particular thread because of an email from me doing a "bug report". They asked if I had an account and after I said no, they sent me to this thread, so I assume they did that because they knew the thread was telling me why I'm having the problem. In the email they also said: "This is an innovation from our engineers. They are sure that it will help with SEO." 

        Loading editor
    • That doesn't add much. It could have just been a stock reply. Are you running any ad blockers, pop-up blockers, web security plugins, etc.? Such features can sometimes block things like the lightbox.

        Loading editor
    • I am, but I did also try turning it off, which didn't help at all, not to mention this didn't affect my ability to view full sized images in the past, and isn't affecting the other anons I've had help me look into this. And hey what a coincidence too, this all started just a little after the turn of the year, around when this thread was started, so I'm kinda putting my bets in it being something on fandom's end, ie the stuff they made this article to describe.

        Loading editor
    • If the other anons aren't having issues, then it is definitely not an issue on Wikia's end of things. Are you able to get the lightbox when you follow the link in #83?

        Loading editor
    • Oh yes it is, because I got an account and suddenly, I'm not having the problem

      Now when I click on an image, it brings me to the image's page, where I can then click the image again to get the isolated image, which is what it used to do for me.

        Loading editor
    • I am 99.9% sure it isn't. I have tested using an unsupported browser and it even works with that.

        Loading editor
    • Well if it wasn't something on fandom's end, why did I stop having the problem the literal moment I created an account? It's not like any of my settings from before I had this problem were changed. They even said in the original post that "few should notice anything changed." clearly I just so happened to be randomly picked to be one of those "few". Furthermore, if it WAS something on my end, creating an account with Fandom would not have been the fix. Yet it was.

        Loading editor
    • I am fairly certain Wikia did not put code into their modifications that randomly chooses IPs to deny access to. When something doesn't word for "a few", that typically means that the few have something configured on their end that is not compatible with Wikia's changes; not that Wiki has decide to single them out.

        Loading editor
    • Them doing that is what this article is about! Them doing that is why the email sent me here before I created the account! And again, I didn't change any of my settings, all I did was create an account, and now I'm not having the issue. None of my software, none of my addons, none of my settings had been changed from before I started having the problem. Not only that but I started having the problem around the time the start of the article said the changes were going to be put into place.

        Loading editor
    • Screenshots would help understand what is going on... descriptions of visual events are usually lacking.

        Loading editor
    • If by Wikia's end, you mean that it isn't working for you because they changed something; you are correct. However, that is not typically what is meant when referring to issues on Wikia's end. Wikia, just like any other web programmer, has made certain assumptions about a user's settings, browser version, resources, etc. They have made something that works given those assumptions. Whether or not your actual set-up has those settings, browser version, resources, etc. is your issue; not Wikia's. Yes, Wikia should try to make things compatible with as many set-ups as possible. However, it is impossible for them to make things compatible with every set-up (even if I personally would want it that way). It just happens to be the case that this particular change impacts your set-up; whatever it is. You can try to see if they are willing to track down and fix the issue, but you cannot force them to. If you want them to trace down the issue, it would help if you actually provided detailed information about your set-up other than just Chrome on Windows 10 with no recent settings changes. Even if you haven't change your settings, that doesn't mean they are standard.

        Loading editor
    • ...So that's why I've been stumbling over new idiotic unremovable redirect when I download pictures from wikia. Well, thanx, devs, you've literally shitted in my life, you almost ruined my wikia experience.

      So how do I remove this disgusting redirect and get to file: pages when I open pictures in new tabs? Without your useless accounts of course.

        Loading editor
    • You don't. Accounts are not as useless as you think; for one, they would actually solve your issue. That's a use.

        Loading editor
    • Tupka217 wrote: You don't. Accounts are not as useless as you think; for one, they would actually solve your issue. That's a use.

      Agreed. Unless you are underage or you've been globally banned from using this site, I can't think of a reason to not have an account.

        Loading editor
    • Maybe it's time for Tupka217 to tell the story of how that username was chosen...

        Loading editor
    • You should still be able to access the full images. You just can't access the file page.

        Loading editor
    • Tupka217 wrote:
      You don't. Accounts are not as useless as you think; for one, they would actually solve your issue. That's a use.

      I've visited many wikias and enjoyed them without any negative experience or problems. Without (useless) account. Now devs are literally forcing me to have their (useless) account just to remove bug they've created. For features? No. For communication? No! Just to get back usability they took from me. What a hypocricy.

        Loading editor
    • Thank you so much for making images completely unusable for browsers without javascript! And the reason for breaking important existing functionality? Scoring higher on Google searches. Gotta maximize those sweet, sweet adbux! Well screw you too!

        Loading editor
    • It isn't a bug; the change was intentional. As explained in earlier posts, the change was made to improve the ranking of wikis in search engine (primarily Google) results. Because Google is such a large search engine, their decisions on how to rank sites can drive massive trends in website design. This is what is happening. Another example is the trend towards mobile-friendly (potentially desktop-unfriendly) websites.

        Loading editor
    • 185.220.100.243 wrote: Thank you so much for making images completely unusable for browsers without javascript! And the reason for breaking important existing functionality? Scoring higher on Google searches. Gotta maximize those sweet, sweet adbux! Well screw you too!

      Well, are you willing to cover FANDOM's cost of operations?

        Loading editor
    • 46.39.53.26 wrote:

      Tupka217 wrote:
      You don't. Accounts are not as useless as you think; for one, they would actually solve your issue. That's a use.

      I've visited many wikias and enjoyed them without any negative experience or problems. Without (useless) account. Now devs are literally forcing me to have their (useless) account just to remove bug they've created. For features? No. For communication? No! Just to get back usability they took from me. What a hypocricy.

      You can't spell it, and you have no idea what it means.

        Loading editor
    • C.Syde65 wrote:

      Tupka217 wrote: You don't. Accounts are not as useless as you think; for one, they would actually solve your issue. That's a use.

      Agreed. Unless you are underage or you've been globally banned from using this site, I can't think of a reason to not have an account.

      Why shouldn't I lie about my date of birth if I'm underage? Simple and obvious pass through youth discrimination on any site.

      Why shouldn't I use proxy if I'm banned? Or have another account right after the first was banned. Again, it's simple and obvious solution.

      As I said in my previous post, I've visited many wikias and lack of account didn't bother me. It was unnecessary for using wikia. And then idiotic redirect came up. Are they forcing me to get that unnecessary and otherwise useless account or suffer for the sake of SEO?

        Loading editor
    • Because doing so will only get you banned again. Despite what you may think, you are not entitled to use others' services. If you cause issues for them, especially issues for which they can face legal consequences, they reserve the right to refuse you service. This goes for almost everything not just websites.

        Loading editor
    • Andrewds1021 wrote:
      You should still be able to access the full images. You just can't access the file page.

      Yep. It's just takes more time and requires more clicking.

        Loading editor
    • SEO is more important than anons who think the world should revolve around them.

        Loading editor
    • Andrewds1021 wrote:
      It isn't a bug; the change was intentional. As explained in earlier posts, the change was made to improve the ranking of wikis in search engine (primarily Google) results. Because Google is such a large search engine, their decisions on how to rank sites can drive massive trends in website design. This is what is happening. Another example is the trend towards mobile-friendly (potentially desktop-unfriendly) websites.

      And if you brainlessly follow that trends you just drive users away from your websites because nobody wants to deal with negative changes and decreasing user experience quality. If you don't understand it now - I wish you'll be forced to understand it later when devs of your beloved site start treating you as a scum.

        Loading editor
    • Tupka217 wrote:
      SEO is more important than anons who think the world should revolve around them.

      Wrong.

        Loading editor
    • 46.39.53.83 wrote:

      Andrewds1021 wrote:
      It isn't a bug; the change was intentional. As explained in earlier posts, the change was made to improve the ranking of wikis in search engine (primarily Google) results. Because Google is such a large search engine, their decisions on how to rank sites can drive massive trends in website design. This is what is happening. Another example is the trend towards mobile-friendly (potentially desktop-unfriendly) websites.

      And if you brainlessly follow that trends you just drive users away from your websites because nobody wants to deal with negative changes and decreasing user experience quality. If you don't understand it now - I wish you'll be forced to understand it later when devs of your beloved site start treating you as a scum.

      Where will they go? I would bet most people decide on sites based on what Google suggests to them.

        Loading editor
    • Andrewds1021 wrote:

      46.39.53.83 wrote:

      Andrewds1021 wrote:
      It isn't a bug; the change was intentional. As explained in earlier posts, the change was made to improve the ranking of wikis in search engine (primarily Google) results. Because Google is such a large search engine, their decisions on how to rank sites can drive massive trends in website design. This is what is happening. Another example is the trend towards mobile-friendly (potentially desktop-unfriendly) websites.
      And if you brainlessly follow that trends you just drive users away from your websites because nobody wants to deal with negative changes and decreasing user experience quality. If you don't understand it now - I wish you'll be forced to understand it later when devs of your beloved site start treating you as a scum.
      Where will they go? I would bet most people decide on sites based on what Google suggests to them.

      To any other site with better usability.

      I suppose it's only 50% correct. If you are talking about random visitors - then yes, google suggestions are a big deal: "I wanna know about character or term from movie/game/book. *searches* Oh, there's whole encyclopedia about it!"

      But if you are talking about people who visit one site many and many times - they don't need to google it and rely on rankings and stuff.

      And back to the topic: Okay, devs wanna redirect search engine bots from file pages to content pages. But why living people who intentionally try to load file pages should be thrown somewhere they didn't want to or just back to the previous page?

        Loading editor
    • 46.39.53.83 wrote: But if you are talking about people who visit one site many and many times - they don't need to google it and rely on rankings and stuff.

      These people are more likely to make an account.

        Loading editor
    • 46.39.53.83, it can be hard separate bot anons from human anons based on IP alone. That is why all anons get this "feature". From what you have said so far, I am guessing you feel that FANDOM should make a way out for anons "in the know" because there can be reasons one wouldn't want to create an account. If that is what you think, I am with you. The issue is that we are in the minority for thinking so.

        Loading editor
    • This was a cruel and unnecessary thing to do. I was trying to open images to get the full size file to look at them and I get getting redirected to the page and I was so upset that this started happening. 

        Loading editor
    • 104.162.13.127 wrote: This was a cruel and unnecessary thing to do. I was trying to open images to get the full size file to look at them and I get getting redirected to the page and I was so upset that this started happening. 

      But if it’s to help the wiki be better then I guess it is no so bad. It’s nice to know why it happened in the first place. I suspected that.

        Loading editor
    • Okay, but what if an average person wants to look at some images and swings by wiki and they get redirected, how are they supposed to know ‘you need to make an account’

        Loading editor
    • Who says they are? There a a bunch of features registered accounts have that anons do not. Unless they have experienced otherwise (which is actually the case this time), however it works is just how it is supposed to work. Remember, you should still be able to get to a larger image; it just takes a few more clicks.

        Loading editor
    • It can be disappointing to have your favorite being taken away from you, being locked behind a registration or upgrade wall or being removed altogether. But we also need to understand the other side. Maintaining any feature has a cost, whether it's a man-hour cost, or (like in this case) "lost opportunity" cost.

      When this feature is only used by a very small number of people, the devs sometimes come to the conclusion that maintaining it is too costly in relation to its popularity. Unfortunately, there is very little that can be done about such situations than to somehow adapt to it.

      An average unregistered person will not notice much difference. They may need maybe one or two images from a specific page, but might not be intimately familiar with a standard MW wiki. The least tech-savvy people are likely to just download a tiny thumbnail. Moderately capable will open a popup window first, then download a larger version. And the most observant will notice the link to the fullsize version in that popup.

      Yes, I know some day I might be the one who gets the short end of the stick. All I can say is: that's how it works.

        Loading editor
    • But then if they do want to get that full-sized version, they don't get the original image - they get a crappy compressed webp file that they can't use anywhere else instead, because it thinks it's a jpg/png instead.

      As others have mentioned, there are plenty of ways to effect this change purely for web crawlers without disrupting the anonymous experience. At the wiki I'm most active on, editors have spent a considerable amount of time building up a large repertoire of photos. Now getting to these photos is a nightmare. We used file pages to help boost the SEO of these images on their own - now all that work has just been thrown down the drain. Not to mention image categories, which are absolutely impossible to access now without links in the main namespace.

      In anything, what should have been done is just improving the file pages themselves. Make them more appealing to crawlers. Encourage editors to complete file descriptions. I'm all for SEO and trying to improve it, but is making things better by just throwing out the bad bits really the right move? Or should those weak spots be improved or strengthened?

        Loading editor
    • But then if they do want to get that full-sized version, they don't get the original image - they get a crappy compressed webp file that they can't use anywhere else instead, because it thinks it's a jpg/png instead.

      I couldn't replicate this bug today. I went on Chrome to an article on my wiki, downloaded a couple of files to my computer (using various methods available to anonymous users), and reuploaded to my test wiki. Absolutely no issues. Both the default Windows 10 image viewer and Open Office Draw were able to open them, too. I'm not an expert enough to verify the level of compression, unfortunately.

      As others have mentioned, there are plenty of ways to effect this change purely for web crawlers without disrupting the anonymous experience.

      And you all might be right. I'm not a SEO expert though, and so I am unable to verify whether those solutions would indeed work. My post was about the phenomenon of limiting some features to certain users or completely removing them. Note that this is not the first time in the history of this platform that cost/popularity ratio was the deciding factor. Notable example: Monobook.

      At the wiki I'm most active on, editors have spent a considerable amount of time building up a large repertoire of photos. Now getting to these photos is a nightmare. We used file pages to help boost the SEO of these images on their own - now all that work has just been thrown down the drain. Not to mention image categories, which are absolutely impossible to access now without links in the main namespace.

      I admire the dedication of your community. Unfortunately, the thing I've noticed a while ago is that Fandom wikis are not built to act as Web 2.0 image repositories. They are fine for illustrations of articles maybe. A booru might be a better option.

      In anything, what should have been done is just improving the file pages themselves. Make them more appealing to crawlers. Encourage editors to complete file descriptions. I'm all for SEO and trying to improve it, but is making things better by just throwing out the bad bits really the right move? Or should those weak spots be improved or strengthened?

      Not every wiki community, even if we only include those about popular topics, is able to do something that. Their resources might already be stretched thin.

        Loading editor
    • 452

      Vengir wrote:

      Absolutely no issues.

      Well that settles it. One person downloaded a few files and couldn't replicate it, therefore there is no problem and anyone who does see the problem is wrong.

      Edit: I just downloaded the last 10 images uploaded to Community Central AND FIVE OF THEM ARE EXPLETIVE WEBP EXPLETIVE FILES WITH EXPLETIVE JPG AND PNG EXPLETIVE EXTENSIONS. (Which means Window doesn't display a thumbnail, you can't open them in Windows Photo Viewer or mspaint, and you can't upload them to Wikia because the "File extension ".jpg" does not match the detected MIME type of the file (image/webp).")

      So EXPLETIVE me (and my ability to assume the person reporting the bug is telling the truth and my ability to conduct a random sampling, and to test a large enough sample in order to replicate the bug instead of just giving up after "a couple") I guess.

      edit: Since I primarily use Chrome, I just checked what happens in Firefox: If you right click on "see full size image" and "save link as", then the Save As prompt says jpg or png, but if you click through to the "full size image" first, then the Save As prompt says WEBP - and even the page title says .webp - because Firefox is actually looking at the mime type of the image it is displaying and not trusting the web server to be honest.

      For the record, I was expecting 1 in 4, so it's just hilarious that literally half of the last 10 files uploaded here demonstrated it.

        Loading editor
    • I never said the bug doesn't exist. It seems like it affects only some files. If I had a specific example I could understand the issue better.

        Loading editor
    • This bug has been around for quite a while and, if I recall correctly, FANDOM has tried to fix it on several occasions. The issue is browser specific; in some cases, browser version specific.

      Guyus24, if an anon is so involved with a wiki that they need to download images, I would expect that they are knowledgeable enough to either already know or use once taught the easy solution to the webp issue. Just add "format=original" to the image's URL's query string and it should download correctly.

        Loading editor
    • 452

      Why are you both trying to frame the image server serving webp files as a bug?

      ...do you think the software is just accidentally converting some images to webp?

      That is what it is designed to do.

      Browser specific my ear. As usual, you have no idea what you're talking about.

        Loading editor
    • Serving webp files would be by design, yes. But it causing downloaded files to be completely unusable would be the bug.

        Loading editor
    • 452

      Serving webp files when the url says .jpg and .png is by design. AND IS THE PROBLEM.

      It's not a "bug", it was a design decision to intentionally allow the image server to be able to serve an image with a mime type which does not match the file extension.

      Edit: Well I just wasted 30 minutes of my life wading through Wikia's spaghetti code on github to try to locate exactly where the thumbnails are generated. I suspect - but am happy to be disproven - that the source for Vignette (and "Thumblr", the thumbnail generator) is not public.

      Edit: Yep, located at https://github.com/Wikia/vignette/ rather than https://github.com/Wikia/app/ where everything else is.

      The thumbnailer is https://github.com/Wikia/vignette/blob/master/src/vignette/util/thumbnail.clj and while there are clearly parts mentioning webp, I still can't tell how it decides whether to use a webp thumnail. Obviously "photos" are more commonly being served as webp than "graphics", so it probably has something to do with comprehensibility, but I can't see where the choice is made.

        Loading editor
    • Tupka217 wrote:

      46.39.53.83 wrote: But if you are talking about people who visit one site many and many times - they don't need to google it and rely on rankings and stuff.

      These people are more likely to make an account.

      Wrong.

      You have many posts in this topic that say completely the opposite but you keep repeating that "get an account" noise.

        Loading editor
    • 452 wrote: ...

      Edit: Well I just wasted 30 minutes of my life wading through Wikia's spaghetti code on github to try to locate exactly where the thumbnails are generated. I suspect - but am happy to be disproven - that the source for Vignette (and "Thumblr", the thumbnail generator) is not public.

      So it isn't in here?

        Loading editor
    • Andrewds1021 wrote: Guyus24, if an anon is so involved with a wiki that they need to download images, I would expect that they are knowledgeable enough to either already know or use once taught the easy solution to the webp issue. Just add "format=original" to the image's URL's query string and it should download correctly.

      Are you for real here? You expect your average internet user to magically know how to add an extension to an image to fix it? The amount of mental gymnastics you are going through to try and justify this change is astounding. It's a broken system, stop trying to defend it.

      People who visit my wiki are in no way versed or experienced with mediawiki. They're looking for an image for whatever reason. Downloading images is a bare requirement, not something you should need in-depth knowledge about. Heck, I've been editing for 5+ years and wouldn't really know to do that. They're either going to get a tiny thumbnail that's no good for anything, attempt to save the image from the lightbox and get blocked, or get a webp image with no major support off browsers, and if they're using Chrome it's semi-corrupted anyway.

        Loading editor
    • You didn't read my comment closely. I said if an anon is already involved enough to need to download images, I would expect them to be capable of implementing this simple fix. However, I do not expect that the typical anon will need to download the images in the first place.

        Loading editor
    • 452

      What you expect is irrelevant, in practice I first became aware of this change - within 4 days - because of a regular wiki-reading-only non-editing anon complaining about a downloaded image being "corrupt".

      People from a variety of "fandoms" like to download images, for the purpose of making memes, for example. People who specifically read video game wikis are highly likely to download maps or other instructional images. They don't have to be Wikia editors to want to do that.

      However, I do not expect that the typical anon will bother to contact the wiki to let them know the image they tried to download is corrupt - the only reason I learned about it was that they complained off-wiki and someone else reported it to me.

      But all of this is irrelevant, because Wikia Staff have already made it very clear that they simply do not care about anons who want to download images:

      Mira Laime wrote:

      There is still going to be the odd user who is negatively impacted, by this, yes.
        Loading editor
    • There are ways to get around the WEBP issue when saving images. Usually removing "revision/latest?cb=randomrevisionnumber" will allow you to save the image under the desired file type, but there is the odd occasion where it doesn't. It is a massive pain in the butt though, and I hope that is addressed as soon as possible.

        Loading editor
    • Let's be clear about one thing. The webp issue is separate from the change that is the topic of this thread. The webp issue has been an issue for specific browser versions before the change to how anons access images was a thing.

        Loading editor
    • 452

      Let's be clear about one thing: Your comment has not added anything to the conversation, and you yet again just appear to be commenting for the sake of commenting.

      Stop trying to move the goalposts.

      The inability for anons to access the original file was the very first in a long list of issues I mentioned in my first post in this thread: Thread:1774401

      Claiming it is a separate topic is disingenuous.

      The change that is the topic of this thread causes anons to not be able to access to the "(original file)‎" link on the file page. Instead, anons are only presented with a "See full size image" link, which in many cases serves an WEBP image instead of the original filetype.

      As demonstrated here by the most recent image uploaded to Community Central, which serves a webp instead of jpg for Chrome, Firefox, Opera - and Chrome on Android. Please name a browser it doesn't serve a webp for, or stop claiming it only effects "specific browser versions" without evidence.

        Loading editor
      1. Where did I move the goalpost?
      2. You are not permitted to post on that board. Expect to see the thread moved.
      3. You can't expect users on this thread to have read your separate thread; especially since your last post is the first time you have linked to it in a relevant discussion.
      4. If you want to discuss how difficult it is for anons to get the full image, fine. But don't go around manipulating phrasing because it won't work. As has already been said multiple times, the webp issue only occurs for certain browsers. Even for those using such browsers, it is still possible to get the full image. They are not "inaccessible" as you repeatedly claim.
      5. It works perfectly fine on Internet Explorer 11 even as an anon. I downloaded the image as an anon and, as you can see, was able to reupload it without any issues.
      6. Having some wikis where anons download images is not the same as having most wikis with anons downloading images. Your extrapolation from your own experience to the broader wiki community is as baseless as mine is.

      Edit:

      For anyone else who gets confused, 452's link is just to the thread representation of #16.

        Loading editor
    • This is madness. Why would we support this?

        Loading editor
    • Well, uhm, I have slightly altered my bad opinion of these changes.

      First, 'registered user' changes have lessened the impact from my initial experiences.

      Second, I came across https://community.fandom.com/wiki/Help:Image_lightbox#Further_help_and_feedback which explain lightboxes and there purpose and uses.

        Loading editor
    • Hm. However, I believe it can negatively affect Image rankings. I think that google bot browses fandom as a anon, so if it tries to index a file page, it won't be able to, and wiki images won't be able to show up in the image section of google searches.

        Loading editor
    • That is what I was wondering about when this announcement was first made. Never got an answer. The wiki I admin is not very active anymore but a lot of our images show in the top Google Image search results.


      Edit:

      Well, used to at least. Not anymore apparently; for whatever reason.

        Loading editor
    • RealKnockout wrote: Hm. However, I believe it can negatively affect Image rankings. I think that google bot browses fandom as a anon, so if it tries to index a file page, it won't be able to, and wiki images won't be able to show up in the image section of google searches.

      Yes. This is another big issue. Now the only images google can crawl are the tiny 200x200 or so thumbnails the new compression algorithm produces. That's why file pages are important, and why something should have been done to fix them rather than chuck them out entirely.

        Loading editor
    • Maybe they can keep this redirect system while treating our friend google differently. However is that discrimination?

        Loading editor
    • The whole reason they are doing this is because of "our friend" Google.

        Loading editor
    • Guyus24 wrote:

      RealKnockout wrote: Hm. However, I believe it can negatively affect Image rankings. I think that google bot browses fandom as a anon, so if it tries to index a file page, it won't be able to, and wiki images won't be able to show up in the image section of google searches.

      Yes. This is another big issue. Now the only images google can crawl are the tiny 200x200 or so thumbnails the new compression algorithm produces. That's why file pages are important, and why something should have been done to fix them rather than chuck them out entirely.

      Well, image rankings are improtant too.

        Loading editor
    • A note on why this change doesn't, in fact, negatively affect image rankings:

      Image search does not index based on the file page URL; it indexes the image file (.jpg .png, etc.) So if the image is reachable (and it is), it will be discovered and indexed. Ranking is based on the page content. The article page is a significant improvement over a file page in the ranking value for our images because they give context. Google can't "read" images and thus relies on the context around the image as well as file names and meta data. The vast majority of file pages on Fandom do not give that context, while the article pages where images are embedded generally do much better at this.

        Loading editor
    • 452 wrote:

      As demonstrated here by the most recent image uploaded to Community Central, which serves a webp instead of jpg for Chrome, Firefox, Opera - and Chrome on Android. Please name a browser it doesn't serve a webp for, or stop claiming it only effects "specific browser versions" without evidence.

      Vivaldi 2.6.1566.49 downloads the jpg (or at least file extension says so), as well as an outdated version of Firefox (didn't check the exact number, though). The updated Firefox 73.0.1 downloads the same file with the webp extension. All of the three downloaded files have the exact same file size, so all of them might actually be webp, and the two jpgs are incorrect extensions or vice versa.

      Nevertheless, MS Paint (Windows 10) did not have any issue opening them. The test wiki accepted the two "jpg" files without any issue, the webp was accepted after I replaced the file extension on my computer. No resaving in image editor was necessary.

      Intriguing, the browser version does seem to have influence, but there seems to be another puzzle piece missing.

        Loading editor
    • If you go to the image page and:

      1. Right-click to save the image then you will ge the webp extension.
      2. Choose "Original file" and then right-click to save the image then you will get the .png, .jpg, whatever the original image format is.

      I am using Firefox 74.b6 (64-bit)

        Loading editor
    • Mira Laime wrote:
      A note on why this change doesn't, in fact, negatively affect image rankings:

      Image search does not index based on the file page URL; it indexes the image file (.jpg .png, etc.) So if the image is reachable (and it is), it will be discovered and indexed. Ranking is based on the page content. The article page is a significant improvement over a file page in the ranking value for our images because they give context. Google can't "read" images and thus relies on the context around the image as well as file names and meta data. The vast majority of file pages on Fandom do not give that context, while the article pages where images are embedded generally do much better at this.

      First of all, google has a images section. How is it supposed to show images if it keeps getting redirected? Second, Google is very good at reading images now (as demonstrated by its serach with image feature).

        Loading editor
    • i thought this was already over

        Loading editor
    • Mira Laime, thanks for clarifying the situation. If that is how it is done, then I am not sure I like how Google is ranking images. Not much we can do about it though.

      *Mumbles a few more pointless complaints

        Loading editor
    • Not sure how Google gets the full image. Only tiny, scaled down files are available on article pages, and when I tested this a few months ago those tiny scaled down thumbnails are the ones that show up on Google - not the original hi-res ones.

        Loading editor
    • Was "a few months ago" before or after this change got made?

        Loading editor
    • This update did not change the way the thumbnailer works so it's hardly relevant.

        Loading editor
    • As has been previously stated, it is still possible for anons to get full-res versions; it is just a lot harder now than before. Whether or not that impacts Google's crawlers, I don't know. Mira Laime is suggesting it doesn't.

        Loading editor
    • Guyus24 wrote: This update did not change the way the thumbnailer works so it's hardly relevant.

      If it has been before this change, then this proves that file pages never positively affected the search result. Google just never considered them in the search results, because those file pages were ranked low. Thus, the argument that after this change people will not see decently-sized images in the search results is not relevant; they never could.

        Loading editor
    • I am not sure, but I think the argument would be that the file pages still provided a larger version of the image. The only way to know with some level of certainty would be to know what Google's algorithms are. Honestly, even Google probably doesn't know at this point considering all the AI stuff they have been using.

        Loading editor
    • Andrewds1021 wrote:
      The only way to know with some level of certainty would be to know what Google's algorithms are. Honestly, even Google probably doesn't know at this point considering all the AI stuff they have been using.

      Lol. I think the are the authors of their AI, so they should know.

        Loading editor
    • Not necessarily. Even in simpler machine learning applications the "authors" do not necessarily know what the algorithm is learning. Yes, they know the rules by which they told it to learn but what has been learned is not necessarily known.

        Loading editor
    •   Loading editor
    • Well, you'e guaranteed less traffic from me, half of why I bother with this site is to grab pics on mobile, and signing in here on mobile never works for me.

        Loading editor
    • Sigh, I wish they would change it back

        Loading editor
    • C76.85.65.155 wrote:
      Well, you'e guaranteed less traffic from me, half of why I bother with this site is to grab pics on mobile, and signing in here on mobile never works for me.

      That's definitely a bug, because logging in on mobile should work just like it does on desktop, and no issues are known here currently. What happens when you try to sign in on mobile? If you don't want to share a bunch of details about your browser, etc. you could send a bug report via Special:Contact, where your message is confidential.

        Loading editor
    • It certainly makes it difficult to determine what the licensing status of an image is or who to credit for an image. Just because an image is uploaded by a particular user, does not mean that they own the copyright for that image (if we that was the case, most wikis would be without any images whatsoever). Just because an image is on a wiki does not mean that the image has had it's rights released.

      For example --

      An article about wookies may include an image of Chewbacca. However, Disney currently owns the rights to the character. And, without getting additional permission from them, it can only be used under the fair use doctrine... not the more lenient copyleft agreements common among the various wiki platforms.

        Loading editor
    • I believe the relevent reply to this was said in #33.

        Loading editor
    • how can change where anon redirects to

        Loading editor
    • As mentioned in previous posts, you cannot.

        Loading editor
    • Andrewds1021 wrote: I believe the relevent reply to this was said in #33.

      You can't hover on mobile.

        Loading editor
    • I work with a category of promotional card images and added a "draw a random card" link with this code:

      [[Special:RandomInCategory/{{PAGENAME}}|Draw a random card]]

      Now that link goes to the article page, and there can be multiple cards on an article page. How are you going to fix this?

        Loading editor
    • Is it a gimmick or vital to the wiki? If the former, you're going to have to come up with your own solution.

      If the latter, same.

        Loading editor
    • (Still getting notifications from this, ugh.) No matter how you slice this, there are so many use cases for normal file pages. If the cost-benefit calculation is in favor of doing it this way, what's particularly annoying is that there's technologically a way better way to accomplish it that doesn't sacrifice surfacing the file pages to normal users. It's as simple as a robots meta tag instructing crawlers not to index the pages. Which is the more industry standard way to accomplish this anyway.

      I continue to be confused and frustrated with this decision all these days later after it was first announced. There's a better way to do it, and it's yet another example of Fandom shafting the wiki experience in favor of looking more like a social media site (not showing the average user "how the sausage is made" despite that quite literally being the point of a wiki).

      And before anyone responds saying I'm not "being helpful", this comment is intended to be constructive. Fandom has reversed course on a few things after sufficient backlash; hopefully this can be one of those instances, because this really really sucks.

        Loading editor
    • Renncast wrote: I work with a category of promotional card images and added a "draw a random card" link with this code:

      [[Special:RandomInCategory/{{PAGENAME}}|Draw a random card]]

      Now that link goes to the article page, and there can be multiple cards on an article page. How are you going to fix this?

      You should be able to achieve something like that by using DPL on a page. You can contact me via my message wall if you are interested in hearing more.

        Loading editor
    • I don't know if this has been asked in this thread... but now I'm morbidly curious: What if the file is used on the file page itself (assuming that's the page the redirect logic would typically follow)? Does the wiki avoid redirecting anons to that page and send them to the main page with a lightbox, or to another page it's on? Or does it end up in an infinite loop of redirecting?

      Also, if the solution is "just log in"... what does that mean for an astute 12 year old?

        Loading editor
    • Well, you could just try it out yourself and see what happens.

      I don't get where you are going with that last comment. A user who is 12 y/o is still under 13 y/o. There are no special rules for "just barely not old enough" users.

        Loading editor
    • Well, testing it maxed out my computer's RAM twice (which was the entire reason I had put it off--I'd been thinking of testing it myself when I previously posted)... regardless of the existence of another page it's used on, files that are linked on their own file page (when that's the logic the page is using for where to send it) go to the main page lightbox method. Curiosity abated! (Even if it almost killed the cat.)

      The "astute 12 year old" thing (that is, a 12 year old who knows how and needs for some reason to access the file page) was specifically trying to note an issue with "just log in"; since it's against the TOS (and the law, because of how Wikia collects information) for the 12 year old to have an account, that's one of a couple valid use cases where it's entirely reasonable to need to access the file page directly while logged out. But it simply can't be done in any way, shape, or form. I think that's foolish is all.

      I'm calling out that there's no workaround for when the stated workaround is not possible, attempting to poke holes in something four months late, if you will. XP

        Loading editor
    • If I understand what you're talking about (File page on a File page for anonymous users), how would an anon click in the File page link on the File page they can't see?

      Also, I'm not sure there is any significant reason to cater to the 12 and under crowd who might be inconvenienced by this "feature".

      Don't get me wrong, I don't think the hiding of the File page is really justified, but I also have very little sympathy for anonymous users who tend to work to the detriment of wikis (except whatever revenue they generate from ad viewing) on balance.

        Loading editor
    • Not the 12 and under crowd specifically, just people with valid reasons to not log in--COPPA covered users were just the most succinct example to grab. Most IP users could probably have an account, but I've edited non-Wikia wikis (en-wp :P) long enough to have seen both my fair share of trash IPs and the less-prevalent IP-with-a-good-reason-to-not-log-in (a small subset of non-trash IPs). It's more like I was just pointing out it's bad usability to have no non-login workaround. (I might be just a little annoyed because I knew about this and then forgot about it, and it was confusing for everyone in a discussion a few weeks ago when someone in an off-wiki location who didn't have an account was being linked a file page for the purpose of viewing it and redirected to a page with no obvious clue what they were supposed to be looking for.)

      As for the file page linked on file page thing: they wouldn't be clicking the link on the file page they can't access. I was looking to see, since it redirects to a page the file is used on, what would happen if the page it would logically redirect to is... itself. So if a user accessed the file URL from a place it's accessible (either another page that's just not the one it would redirect to for some reason, or an off-wiki link), I was curious if it was coded with that foresight (it was) or if it would end up in an infinite loop of trying to redirect to the file page only for the file page to redirect it to the file page (it's not).

      I'm sort of also curious what would happen if the file was linked on another file page where that's the page the logic would in theory redirect to (would it cut its trip to the second page short and follow the first page's logic and so send it to the main page lightbox, or would it follow the second page's logic and go wherever that page wants to redirect?). But I'm not willing to test that so soon just for the funsies of knowing the answer, when the consequence is potentially having to end-process my browser or even restart my computer if the RAM use is bad enough.

        Loading editor
    • Well, anons can still get the image itself so if they need access just to download the image, then there is no issue there.

        Loading editor
    • For the last time, stop kidding yourself. No anon knows how to get to the hi-res originals anymore.

        Loading editor
    • You mean they won't see the link that says "See full size image"?

        Loading editor
    • Andrewds1021 wrote: Well, anons can still get the image itself so if they need access just to download the image, then there is no issue there.

      It's true, they can. As long as it's clear which image they're supposed to be looking at.

        Loading editor
    • Key word is originals, not the web-p versions.

        Loading editor
    • How many times does this need to be repeated? The WEBP issue is only for certain browsers. These hypothetical savvy 12 y/o we are talking about should be able to use a different browser if they are doing so much that they need to be downloading images.

        Loading editor
    • Andrewds1021 wrote: How many times does this need to be repeated? The WEBP issue is only for certain browsers.

      WebPs are still not original images, though. I don't think the issue here is that Vignette is still serving WebP images with the .webp extension in the Content-Disposition header (that Chrome is for some reason ignoring and just downloading them as PNG) when accessed without ?format=original but that these images have quality losses.

        Loading editor
    • Not that it changes much, but I've also found removing the /latest/... bit (so everything after .png) also shows the true original/PNG.

        Loading editor
    • That's odd. On here I'm seeing
      content-disposition: inline; filename="Toriel_battle.webp"; filename*=UTF-8''Toriel_battle.webp
      content-type: image/webp
      whereas on here I'm seeing
      content-disposition: inline; filename="Toriel_battle.png"; filename*=UTF-8''Toriel_battle.png
      content-type: image/png
      in the response headers for these images. Using a different domain (images.wikia.nocookie.net or images.wikia.com) also does not change these headers.
        Loading editor
    • 452

      Thank you, KockaAdmiralac.

      It's nice that someone is FINALLY backing up my statement that the servers are serving WEBPs


      Andrewds1021 wrote:

      How many times does this need to be repeated? The WEBP issue is only for certain browsers.

      Please stop repeating it, because it is incorrect: the problem is thatthe SERVER is SERVING WEBP FILES.

      Andrewds1021 wrote:

      If you want to discuss how difficult it is for anons to get the full image, fine.
      I do not require your permission, nor did I ask for it, nor do you hold any position in which you have the authority to give it.

      Andrewds1021 wrote:

      It works perfectly fine on Internet Explorer 11 even as an anon.
      Thanks for finally getting around to answering my only question. I appreciate you taking the time to openly demonstrate your lack of understanding of how Forums work before addressing it.

      I have confirmed that Internet Explorer 11 indeed does not download the image served, and instead converts the image. (However, the underlying problem of the server serving a webp remains, as demonstrated in Internet Explorer 11 by pasting the "See full size image" url to imgur and getting an error.)

      Fun fact: Internet Explorer 11 isn't a supported browser: Help:Supported_browsers.

      So yes, anons using Internet Explorer 11 can easily download a full-resolution version of an image. This gives you the justification to continue saying "only occurs for certain browsers", despite the fact it is an unsupported browser. According to the top google result for browser market share it accounts for only 3.7% of desktop users, so the experience of using Internet Explorer 11 is not the representative experience of the majority of anons.

      However, it is disingenuous to say "only occurs for certain browsers" as that wording implies that it effects a minority of users, when the greater truth is that it "only occurs for certain browsers used by the majority of users".

      Anons using Wikia's most popular supported browser have no convenient way to download a usable full-resolution version of many images, because the link provided by Wikia is to a URL that says jpg/png but often serves a WEBP image to *all* browsers, and any browser that trusts the web server to be honest about the filetype will save the WEBP verbatim with a jpg/png filename.

      Anons using any browser no longer have any convenient way to download the original unconverted and uncompressed image.

      They can modify the URL in order to obtain the original image, or to just obtain a usable image, but is it not something a typical anon should be required to know how to do. They can also take a screenshot of their screen and paste it into an image editor - but the fact that there are workarounds does not absolve Wikia, and constantly mentioning said workarounds when we're discussing what Wikia DID, and what they should DO is nothing but a distraction tactic.

      Andrewds1021 wrote:

      Having some wikis where anons download images is not the same as having most wikis with anons downloading images.
      Video game wikis are an entire vertical. I can't find any information on numbers or percentages of each vertical compared with all wikis, but the first "Hub" option when you create a new wiki is "Games", which would tend to indicate it is a fairly popular vertical.

      It is disingenuous to dismiss Video Game wikis as "some wikis". Video Game wikis are, at the very least, "many wikis".

      Your attempt at manipulating phrasing to minimise the issue aside, you are fairly successfully using the troll tactic of distracting from the larger issue by focusing on a single point.

      It doesn't matter how many anons want to download images.

      A non-zero quantity of anons want to download images, and, statistically, more than half of them are using Chrome.

      You trying to argue about how many anons want to download images is irrelevant, as I have already acknowledged that Wikia Staff simply do not care about anons who want to download images.

      Andrewds1021 wrote: Your extrapolation from your own experience to the broader wiki community is as baseless as mine is.
      Thanks for confirming your extrapolation is baseless. Now please stop doing it.
      Andrewds1021 wrote: They are not "inaccessible" as you repeatedly claim.
      This is a blatant attempt at a straw man argument by openly lying about what I have said.

      I welcome anyone to search for the word "accessible" - I have never said "accessible" or "inaccessible", nor have I made any such claim using different wording. From the very first revision of my first comment in this thread, I have always said "no convenient way", as a tacit acknowledgement that there IS a way, just that it is not convenient.

      Your failed attempts to reframe the discussion to suit yourself is one thing. But lying about what other people have said should get you blocked.

      Note:

      • I have agree with your response to my previous question that downloading WEBP files in IE11 results in usable images.
      • I have asked you zero new questions.
      • Due to you lying and using troll tactics to steer the conversation off-topic, I will not be responding to anything further you have to say.


      KockaAdmiralac, as a Volunteer Developer, I hope that you will be able to get this issue addressed and resolved.

      Now that someone competent has acknowledged this issue, I am unfollowing this thread.

        Loading editor
    • </rant>

        Loading editor
    • Here is what I did:

      1. Log-out
      2. Attempt to go to File:Wiki-wordmark.png
      3. Get sent to main page with image opened in lightbox
      4. Click "See full size image" next to the image name
      5. Right click image and select "Save image as..." or whatever the browser's equivalent is

      Here is what I got:

      • Internet Explorer 11 - Download PNG and label as PNG
      • Microsoft Edge 38 (EdgeHTML) - Download PNG and label as PNG
      • Google Chrome 81 - Download PNG and label as PNG
      • Firefox 73 - Download WEBP and label as WEBP

      And yes, I tried opening each of the downloaded files. I used Windows 7's default photo viewer and I was able to open every PNG file but not the WEBP; even after renaming it to PNG.

        Loading editor
    • @Andrewds1021

      I did the same thing you did but I went I guess it was 2 steps further

      5. In URL I removed everything to the right of the .png and pressed enter.
      6. Right clicked on image and chose "View Image" info
      7. Clicked on the image from the list shown then chose the "Save image as" button and it then saves the image as a .png format

        Loading editor
    • Looks like a FANDOM Firefox bug... lots of places only really test Chrome these days, so it isn't too surprising.

      @Andrewds1021: Have you tried Chromium Edge (for this is issue or in general)?

        Loading editor
    • Was this related to UCP?

        Loading editor
    • @GiantCatbass

      This is about the Anonymous redirects of images in non-UCP wikis - I have have no idea if the UCP wikis have the same problem in order to get to the orginal file type or not.

        Loading editor
    • Jrooksjr, I would assume so. The file redirects for anons was done for SEO purposes and I don't see the SEO rules changing just because it is a different platform.

      Fandyllic, is Chromium Edge different from Microsoft Edge? I used whichever one comes default with Windows 10.


      Edit:

      By the way, even if Firefox does download the WEBP, at least it correctly labels it as such. The original issue was the images were downloaded as WEBP but labeled as PNG, JPG, etc.

        Loading editor
    • So SEO have any connections to what this happened?

        Loading editor
    • It depends on what you mean by "this". If you are referring to anons getting redirected off of file pages, yes. That was the whole point of the change. The side effect is that anons now have restricted means to access full-size images. The primary means of doing so provides, supposedly, a WEBP version. This is the supposed "bug" that we have been going in circles over. By the way, in case you didn't notice, this change was made in early December 2019; so it has been 4 months since then.

        Loading editor
    • The reason is almost exclusively SEO. It has a mild negative effect on the contributor side in that anons might have wanted to add licensing or source info on images/videos where anons are allowed to edit, but now they can't.

        Loading editor
    • So anons can do nothing except reading articles in wikis?

        Loading editor
    • No, they can still do most of what they previously could. It is just they cannot access pages such as File:Wiki-wordmark.png. Click that link while logged-in and then try it while logged-out. You'll see the difference.

      Fandyllic, I added browser versions to my prior reply. It was Edge 38 so EdgeHTML, not Chromium.

        Loading editor
    • So they are free to edit articles in wikis?

        Loading editor
    • As free as they previously were.

        Loading editor
    • Meaning anonymous editing is controlled by the wiki's admins.

        Loading editor
    • I'm just going to pretend to know what this means and say keep up the good work whatever you do.

        Loading editor
    • Is this discussion over about anonymous users redirect?

        Loading editor
    • Why do you ask?

        Loading editor
    • I feel bad for saying "astute 12 year old" earlier.

      I should have just from the get-go expanded it to what I really meant--IP editors with a good reason to access the file page and an also-good reason to not have an account/log in at the time.

      Jrooksjr wrote: @GiantCatbass

      This is about the Anonymous redirects of images in non-UCP wikis - I have have no idea if the UCP wikis have the same problem in order to get to the orginal file type or not.

      The redirecting happens on UCP wikis--I didn't get the chance to check the file type issue because my computer started showing signs of "I'm about to use too much RAM and throw a tantrum".

        Loading editor
    • So that's why every time I click in a image or video I'm redirected to the same page... sucks, man. I don't edit stuff, so I never needed an account...

        Loading editor
    • REALLY, Mira Laime?

        Loading editor
    • Highly doubt this was unilaterally one staff member's decision.

      (Also, might just be me, but kudosing your own post, as if to imply other people agree with it when it's just you, seems in bad taste.)

        Loading editor
    • Mira Laime wrote: This post aims to give you some more context on why Fandom is introducing file page redirects for anonymous users (announced in today’s Tech Update). Our goal is to make search engine improvements for the content you create across Fandom and to give logged-out readers a more straightforward, satisfying experience.

      As you probably know, Google not only pays attention to what is on a page, but also to how it’s presented. It looks for user-friendly pages that are easy to navigate on mobile and tends to rank these higher. The vast majority of traffic to your wikis comes from Google searches, so Fandom’s team is constantly working on making sure the great content you create is valued by Google and not falsely categorized as “low quality” for structural reasons. Late last year, we made an update to how category pages look for that same reason.

      File pages (those with URLs ending in …fandom.com/wiki/File:) are vital elements of a wiki community, used frequently by editors and play an important role on the wiki. For casual readers, however - and those make up the vast majority of people visiting your wiki - they are confusing. Visitors who land on a file page often end their visit right there because they find little information that’s meaningful to them. That’s why Google thinks file pages are “low quality” pages and doesn’t like to show them in search results. To make matters worse, this can have a negative effect of Google’s evaluation of a wiki’s content as a whole, and result in article pages being ranked lower as well.

      We figured, redirecting anonymous users (which includes Google bots) from file pages to the corresponding article pages, where they can see files in context, might help solve both of these problems. We ran multiple tests to confirm this hypothesis. In the spring of this year, we tested file page redirects for several weeks on ten larger communities such as the Harry Potter Wiki and the Pokémon Wiki and indeed found that it increased the wikis’ visibility on Google overall. As we found no negative consequences, we expanded our test in September to 100 communities on many different topics, and were once again satisfied by the results.

      An important point about changes we make for the sake of search engine optimization is that they’re not always about directly boosting traffic. Often, they’re about fortifying ourselves against future Google algorithm changes and making sure search engines continue to view our wikis as high-quality content sites.

      That’s why we will be redirecting logged-out users on all Fandom communities to the first article page a file was used on instead of showing them the file page itself, starting tomorrow. That way, they will see context and additional information, and have a better opportunity to discover more of the great content you created. At the same time, it ensures that Google’s bots don’t get hung up on what they perceive to be “low quality” file pages.

      Logged-in users are not affected by this change. The vast majority of traffic even from logged-out users falls on content pages, not file pages, so even among anonymous users, few should notice anything changed.

      So, I'm not seeing any answers or responses to the rather important questions of whether this feature is actually legal. @Mira_Laime, have y'all looked into this at all?

        Loading editor
    • It's legal in that there are unlikely to be any laws making it illegal... however, it might violate CC-by-SA.

        Loading editor
    • Isn't CC-by-SA about how content on the wiki can be redistributed; not about how the content get's to the wiki?

        Loading editor
    • It's also about how content is attributed... for example, I just grabbed this from CC-by-SA Generic 2.0:

      Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

      The anon image display scheme makes it harder to discover attribution.

        Loading editor
    • Okay, but this seems to mean that as an anonymous user there’s no way to view anything other than a preview image? The galleries on the main pages crop the images they’re showing to the point where you’re seeing very little of it. What about people who want to see something in full as well as general information? What about some pages with hard to find art and images? How is anyone supposed to fully enjoy these things if they’re impossible to view without an account? Thumbnails are not good enough. Personally, although I do obviously have an account I’m not always signed in, I have a tendency to hop onto a page I need for art reference and pull images up that way. I also love to collect concept art, a lot of which can be found on these communities, am I expected to be logged in for occasional browsing or just so I can save an image for my personal files? This is certainly decreasing the ease of use for this site. This seems less like a helpful idea than it is just pandering to analytics to increase traffic and search engine hits. These pages need to be fully useful to the fans, account holders or not they’re the people who keep this site alive and relevant, they need to be able to view details and not just be locked into an endless loop. Loops are not a user-friendly feature, I expect a fair few people to end their visit to a page if content is inaccessible.

        Loading editor
    • While I'm here, I want to comment quickly on a few items of concern 452 has highlighted:

      452 wrote:
      • When redirected to an article after clicking a used image, there is no lightbox displayed, and the user has to hunt through the page to find the image they were looking for.
      • If an image is formatted in the article as [[File:Image.jpg|link=File:Image.jpg]], (EDIT: and is only used in that 1 article) then clicking that link just refreshes the article, and does not show the lightbox, so the anon user has no convenient way to see a larger version of the image. (Edit: if the image linked that way is used in multiple articles, then it will take them directly to the other article instead of opening the lightbox)

      I experienced an event like this by anonymously visiting the main articles for Saints Row and Saints Row 2; in both articles' cases, clicking the cover art in the infobox simply refreshed the article. Where I can see how examples citing image galleries might fail to rouse alarm (since the use, misuse, and usefulness of image galleries continues to be debated), surely the infobox example holds some sway? An infobox inherently draws attention to an image editors have consciously chosen to pedestal, and it's reasonable to think anonymous users might want to access 'featured' images.

      I couldn't even click to view 'full size image' of the Saints Row covers as an anon because I wasn't given that option. These are not tabbed images, mind you (|image = Saints Row box.jpg). I imagine many anonymous users might give up trying to access the image at this point.

      Also, I'm in accord with 452's full statement that the above excerpt is from. Preventing anonymous users from accessing file history / previous versions is particularly rankling in my eyes--should we view file history as lesser to article history, which anons can (oh boy) 'still access'? To what extent is this to the detriment of transparency as it is use and practicality?

      Then there are image categories, which others have already invoked. If the file history inaccessibility rankles me, the implications which arise from the perspective of category navigation trouble me and would appear to undermine FANDOM's own navigational philosophies.

      You've essentially removed a straightforward method for anons to access image categories (i.e. by using the category row at the head/food of a file's page)--one of the easier methods at that. Yes, I recognize that the state of file categorization widely varies between wikis. So what? Even wikis with a robust image categorization system (in which the majority of its files are included) may not link to Category:Images anywhere obvious / indicate that's where anons should look.

      (I guarantee the 'convenient links' scattered across the Harry Potter Wiki as brought up by Snapper2 in #18 are not majority practice. This isn't to say Snapper2's point isn't valid or relevant, for it is; where Snapper2 has underscored the problem of neutering image categories in and of themselves, I'm underscoring the problem of inaccessibility to image categories via files.)

      FANDOM has indicated it values cross-wiki uniformity with the standardized local top nav design introduced in '15 or '16 and other customization restrictions. Moreover, you showed us you considered the visible display of categories useful when you duplicated the footer category row at the top of articles; you clearly believe they are valuable as navigational tools.

      But now you've effectively removed the very navigational tool you highlighted for anons with respect to files. I'm having trouble reconciling this with both the prominence you've given displayed article/file categories and the import you've attached to standardized global experiences--the latter referring to your philosophy that users need some semblance of familiarity across wikis otherwise they'll be at a loss as to how to navigate (c.f. the local top nav design decision).

      All wikis must display categories at the head and foot of articles/files; surely this falls in line with your navigation standardization philosophy? After all, as I acknowledged before, many wikis will not necessarily link to Category:Images anywhere obvious (homepage, top nav, community portal). Many do not have a file policy. (Special:Images in the top nav is useful, but not a substitute for Category:Images for obvious reasons). But anons who might not think to add Category:Images to the URL might think to access an image's categories from its file page, because this is the standardized experience you've offered and highlighted until now.

      There are many reasons why anon users might have cause or desire to access an image's categories. Perhaps they want a quick way to view all the book covers in a book series. Scenario: they click on a cover in Volume One's infobox; they access the file; they discover it is categorized in Category:Book Cover Images and thus proceed; they are satisfied with their FANDOM experience. You have now rendered this method inaccessible for the anon user. Now what? If this user does think to manually load Category:Images, good for them... Unless that wiki hasn't filed the book covers category as a sub-category of Images, alas.

      This user could spend time guessing the book cover category's name (optimistically hoping the Wiki actually has such a category), could look up how to access all categories, or, you know, the user could write FANDOM off and leave having learned to avoid FANDOM for future image-related queries.

      (Before one dismisses the above scenario as something constructed just for "argument's sake," let me be clear: the above method to access Image categories is one I myself use often. I've used it on wikis when I'm logged in, on wikis I admin and know full well what the image categories are, and on wikis when incognito (anon) because it is convenient. It is useful. Count me among those who will be inconvenienced, even if only in small part.)

      To summarize the Image Categories point, this move seems to directly oppose if not sabotage your previously espoused stance on the usefulness of displayed categories as navigational tools on articles and files. How do we reconcile this update with FANDOM's stances on displayed categories and standardized navigational experiences? I can't see how.

        Loading editor
    • Here's another side-effect: the "Most Visited Files" section of the Analytics Admin Dashboard is now useless, counting only the small number of logged in users that click on files.

        Loading editor
    • It would be great if that section could be retooled to display files that are most served to users.

        Loading editor
    • Revriley wrote:

      While I'm here, I want to comment quickly on a few items of concern 452 has highlighted:

      yeah, I have to strongly agree with what Revriley wrote. This is...a really troubling change that makes things significantly more difficult for readers and anon editors, for the purposes of SEO.

      I know I'm a bit of a broken record on this point, but I just can't fully express how appalling I find it to worsen the core function of the wiki in order to boost ad revenue.

        Loading editor
    • Is there a way to disable it?

        Loading editor
    • @Nintendon't: Disable what? UCP? No.

        Loading editor
    • No, the feature mentioned in the annoucement.

        Loading editor
    • Why would they disable it? They chose to enable it in the first place.

      So again: No.

        Loading editor
    • You disable it by having an account. There is no way to work around it for IP users.

        Loading editor
    • Jade Emperor wrote:

      Sophiedp wrote:

      Jade Emperor wrote:

      Sophiedp wrote:

      Jade Emperor wrote: Heh, I am a Content Moderator(tropico.fandom) and no longer can simply right-click to open an image in a new tab to get to the 'File:' page. Instead I am given a image displayed. Nothing in preferences for me to check off. Must be one of those glitches to iron out, but I'll probable just find another means until the gamepedia merger is finished in 2022, shrug.

      If you're logged in, that sounds like a bug, have you tried to contact Fandom Staff about it? (since there's no preference, it just shouldn't redirect you from the file page if you're logged in.)

      I am sure they tested the changes and it works exactly as they intended; so authorities in this thread states. Not wasting my time filing in a form when I just reported my issue to the authorities in #25.

      Mira also says that "It's entirely possible that there are still bugs to iron out" in the reply right above yours.

      lol, Its their server time and bandwidth to waste on an extra page serve. Interim solution seems to be left click and select the 'File:' page from there using right click> new tab.

      imo, Only real justification for this change was Google Bot page hit count. Unregistered permissions can handle any vandalism issues. Still, no way of curbing image theft until they implement no right clicking for the UU which is just 'kids-at-play' easy to circumnavigate. Yep, Fandom needs to make the service pay-to-play private; Im deaf so shout as much as you like, it is mostly a joke too.

      A joke.

        Loading editor
    • This is absolutely fucking retarded. I love going through an article, hitting "open in a new tab" on images I want to see bigger and maybe even compare only to end up with 30 fucking identical tabs of the article page.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.