Forum:Automated Image Infobox

Recently infoboxes were changed so that infobox images are added automatically. This was done without discussion, and has resulted in poor quality images on character infoboxes. While this does automatically update pages, it also results in bad quality images, and makes manually changing the image more difficult. 19:34, August 12, 2013 (UTC)

Discussion
None of the images were changed, they were only renamed. How are they any worse? 19:57, August 12, 2013 (UTC)

Nothing should be done automatically. SeaTerror (talk) 20:03, August 12, 2013 (UTC)

If you want to have better and deeper details on the situation, let me explain it to you. I just found out about the whole thing about 30 minutes ago, so tell me if there's any mistakes and I'll fix it.

A while ago, Sff and Gal (as far as I know) changed the infobox template so infobox images are added automatically. This was done without any prior discussion with the community, have resulted in some conflicts and some users are against it. While this does automatically update pages for the lazy fairly quickly (I literally cannot think of any other pros of having this feature), the feature sometimes adds poor quality images or renders to infoboxes, causes confusion on how to add an image to the infobox, and is challenging to use for inexperienced editors.

I personally am against having this feature. Firstly, a big change like this should not have been done without any prior discussion with the community of the wiki. Secondly, as far as I can see, this was particularly designed for the lazy and it is rather challenging to use if you do not know how to use it, or am new to the wiki. The feature also causes confusion on how to add an image to the infobox, and only make adding an image to the infobox even challenging for new users and potentially chase off new editors. Stick to something simple and easy to understand and use, guys! The feature also add poor quality images to infoboxes, and I like this wiki to be of top quality works, not shitty and rushed works. Also, renders are sometimes added to the infoboxes. There was a forum about renders, and the decision was to not use a render as an infobox image, period. Automatic things make mistakes, and this feature is hard to fix if you do not know how to use it. Manually adding an image is significantly easier to use for both the inexperience and experienced editors, as it's plain and simple to use, compared to the automated image infobox.

As for the pros, I literally cannot think of any good pros to keep this feature other than that this was made for the incredibly lazy people.

Finally, ever heard of "If it ain't broken, then don't fix it"? 20:10, August 12, 2013 (UTC)

I couldn't agree more with you, Jade. This new system just ruins the editor to page interface. It works for some, but not for others. Sometimes image sizing needs to be more specific than just 200px. If this is some kind of vandalism deterrent, it's a token effort that doesn't need to be taken. Also, this should have been discussed instead of just going ahead with it. Charging into this without going through the proper channels is what angers me the most about this whole thing. 20:19, August 12, 2013 (UTC)

It's actually quite easy to use, if you check the actual parameters being used.

The pros are obvious, which are to prevent vandalism, and to make sure the images are consistently placed on all the pages. If the situation calls for it, use the old image parameter. There's no reason to complain about something that works on the majority of pages. 20:40, August 12, 2013 (UTC)

First of all, if there are any problems with the automation, the old manual code still works and is entirely useable.

If the issue about code, then let me say this. It's much easier to deal with in the automated style. Before the automation, we had the code for 4 separate images due to the need for the pre/post and manga/anime switch templates which were kinda glitchy and a complete shit-show in terms of image name/size. The automated version improves all of those issues, the only exception being the size thing (as far as I know). The images themselves can still be edited just as easily as before, except now we make sure that users upload a new version of the old infobox picture, instead of uploading a new one, as the policy is.

I believe the best solution here is simply to write up a guide on how to deal with the automation on the FAQ and to make changes to the template that allow image size to be more easily altered. There is no need to overreact and undo all the work we've done. And this project had the approval of image team leaders, an admin, and as far as I know, most editors who actually edit images frequently, and it seemed to be (and still is, really) a minor issue. 20:49, August 12, 2013 (UTC)

Approval or not, there was still no formal community discussion. Even with approval, something this big should be discussed at the very least as a sign of good faith. 21:19, August 12, 2013 (UTC)

I agree; changes that affect almost every page on the wiki should not be made without a discussion and possibly a poll. 23:04, August 12, 2013 (UTC)

down with the automatic system-- 00:09, August 13, 2013 (UTC)

I know it does seem rather uninformed for them to change it like this, but they did include the option of manually placing the images, should we find difficulties, right? Sometimes, things like this, we just change it first, then bring it up if, and only if, issues arise. Attack first, ask questions later. 00:19, August 13, 2013 (UTC)

The FAQ has been updated. 00:24, August 13, 2013 (UTC)

Even if it was done without informing the community (which I admit was a mistake) that issue is unrelated to whether or not we actually use the system. How it was implemented is not related to the quality of the automation. So rather than have a conversation about how we should have discussed it, let's just actually discuss it. 01:34, August 13, 2013 (UTC)

Agreed. I did the tabbers without first conversing, and it worked out great. This new system seems to be effective, so we don't have to manually place those images ourselves. Handy. 01:43, August 13, 2013 (UTC)

Problems arise when they have to be specifically resized. 200px or whatever it is doesn't work for all the images on here. And Yata, the shoot first ask questions later idea is only good on a small scale. Your tabs only affected one page. This affects the whole site. 03:03, August 13, 2013 (UTC)

When they have to be specifically resized, use the old image parameter. It still functions the same as it did before. 03:11, August 13, 2013 (UTC)

I agree that there should have definitely been a discussion prior to implementing this change (since it affects the majority of the articles in the wiki) but I see no reason to remove it. The automatic image search in the new system is handy and the only issue that I especially noticed is people removing the image parameters on articles that have been left there on purpose. MasterDeva (talk) 08:33, August 24, 2013 (UTC)

Many infobox images are very small or have weird dimensions and when the automatic infobox is used, they look just terrible. So I believe that they are a bad idea, at least for character pages. 03:40, August 28, 2013 (UTC)

In Char box we should set a height dimension too.

Also, that little pencil+paper icon that takes you right to the image's page would be really, really helpful. We already have it in the portrait galleries and on thumbnails everywhere. 00:22, September 18, 2013 (UTC)

I'm sorry, but what's the point? Just click on the image and the on the file name. That icon was added on galleries because the images there have a link, so if you click on them you won't open the image lightbox.
 * It just makes image renaming a much faster process, given that we're not working out of the category anymore. And when the larger image loads with that pop-up, it often hangs for me and I can't get to the image page quickly. If it's a small thing, I don't see why we can't have it. 19:48, September 18, 2013 (UTC)


 * Fully agree with JSD on that. 19:50, September 18, 2013 (UTC)

One of the scripts in my common.js automatically opens up the image when clicked on. 19:49, September 18, 2013 (UTC)

So when will it become manual again? SeaTerror (talk) 20:07, September 18, 2013 (UTC)

It won't become manual again. If you see a page that needs different sizes, go ahead and make it manual again. But if the sizes for the automated images are fine, then leave it.

And Sff9 said it was too hard to get what I asked for. And there may have been some confusion earlier Levi, as what I described doesn't exist in monobook, if you're using that.

Can we close this now? 04:41, September 26, 2013 (UTC)

More people wanted it back to how it was so yeah it will get changed back if there is a poll. SeaTerror (talk) 04:45, September 26, 2013 (UTC)

Time to bump this. This automated infobox crap causes a lot of problems such as not being able to fix a redlink because an image got renamed http://onepiece.wikia.com/wiki/Sea_Animal_Pirates SeaTerror (talk) 02:10, January 13, 2014 (UTC)

I completely agree. This bullshit excuse for vandalism prevention ruins the interface and WAS NEVER DISCUSSED IN ANYWAY PRIOR TO ITS EXECUTION. Someone, not going to say who, got it into his head that he could do whatever he wanted and decided to go ahead with it just because an admin thought it would be a good idea. It's completely stupid and should never have been done in the first place. 02:48, January 13, 2014 (UTC)

Another page that suffered from this change. I don't see how this is convenient and I don't see how it prevents vandalism. Somebody is still going to replace the Infobox image with vandalism. Somebody is still going to blank the whole template out to paste that image. You can't stop vandals. That's why vandalism still exists in the world. 03:53, January 13, 2014 (UTC)

I still see them as useful in many instances where there's no reason to change them, such as episode/chapter pages. Perhaps we should just back off a bit on which types of infobox use the automation. I still think we should use them on episode, chapter, character (the Pre/Post/Anime/Manga would be a nightmare without the automation), but I don't see them being very useful on crew pages (I don't like how every box uses "___ Jolly Roger"), OVAs (they have awkward titles), or similar pages where there aren't many of them.

One thing I'm sure of in regards to infobox automation, it shouldn't be all-or-nothing. Some articles should use automation, and some shouldn't. But we shouldn't force all articles to be one or the other. 04:03, January 13, 2014 (UTC)

It's fine as long as the name of the page is stable. The good thing is that it encourages images to be named properly and systematically - leave the image parameter blank (or switch=manga for the first manga image of a character), click preview, and the redlink will tell you where the image should be uploaded. If there's an edit war over the page name, it's simple enough to just put the image parameter in manually. 99% of the work from a page rename comes making sure all the links on other pages now point to the new name anyway, but I don't see any of you reopening the redirects forum to complain about that. 04:17, January 13, 2014 (UTC)

It isn't fine at all. SeaTerror (talk) 17:33, January 13, 2014 (UTC)

Automated infobox is fine. SeaTerror and Nada, you both know how to add the manual parameter if it's needed, so don't try to act like you have no idea how to do so. 19:01, January 13, 2014 (UTC)

Nah we need a bot to add it back to all articles. SeaTerror (talk) 19:16, January 13, 2014 (UTC)

Just saying, if the reason for creating the automated-image system was to unifying all the image dimension, you can easily achieve that by giving only the file name as parameter and setting a maximun width&heigth in the template, like.

We just need to add them all back Levi. No other way around it. SeaTerror (talk) 16:17, January 20, 2014 (UTC)

I'm not even going to wait for someone to mess this up by declaring the 4 letter p-word and declare what I like to call admin law. Fact of the matter is there was no prior discussion before this retarded excuse for progress was put into place due to those involved ignoring policy and going ahead with just a terrible idea to begin with. I'm declaring this whole thing one big mistake that must be undone. Now. If after it's reverted those who originally got ahead of themselves would like to formally propose its use, good for you, we'll cross that bridge when we come to it. Until then, back to the way that was actually discussed and agreed upon by more than just three people. 07:15, January 22, 2014 (UTC)

I know how to add the parameter. By you. I had to be taught it because the new system was so sudden. The previous way at least could be learned by experience. A new editor isn't going to understand how to edit the image if the image settings are invisible. Unless, of course, the new editor was taught how to. In which case, it's an inconvenience for both the teacher and the student. If the settings were there, a new editor will just go "How do I edit this image? Oh, maybe changing the number-px thing will help." Experiment with the preview button for a bit, and whamo. The system teaches itself. But keeping the settings invisible doesn't help in any way. And it doesn't stop vandals, either, since they can still add an image. If you had a sign that said "Keep off the grass", that doesn't mean anybody who sees it is going to keep off the grass. 07:50, January 22, 2014 (UTC)

Are a bunch of infobox pages coded horribly because of this system, or is it something totally different? Because I went to a bunch of pages in the Paramecia Devil Fruit category, and found many of them are broken. Images that aren't named properly had those brackets. Other images that SHOULD be correct say they are "not available". I don't know if this is caused by the automated system, but if it is, that reason alone is enough to get rid of it. It's HARMING the wiki! 08:40, January 22, 2014 (UTC)

The automation was done half-assedlynotice that there are 2 image parameters(one that i've added and the other that had already existed(that shouldn't have been there if the automation was done properly))--

There's no reason to remove it from Chapter and Episode pages. Those images should never need to be altered in any way. 19:04, January 22, 2014 (UTC)

Your're completely wrong. The biggest issue with automating anything is the lag that articles that use it get due to the heavily coded templates. Nothing should be automated. The only time an article "should" lag is when there is just plain too much text on the articles like the Straw Hat articles before they were tabbed. SeaTerror (talk) 21:18, January 22, 2014 (UTC)

Way to ruin progress. I think that's the end of my participation here. Goodbye. 21:25, January 22, 2014 (UTC)

You're wrong there, ST. The Episode/Chapter boxes cause so much lag on their pages not because of image automation, but rather the automation used surrounding which corresponding chapter/episode/eyecatcher. The image automation is really simple and not taxing on pages because it just uses the pagename as a title for the image. It's no more taxing on a page than the title shown in the Char Box, because it uses the exact same code. You don't see us scrambling to do every article title manually in every infobox now, do you? 01:19, January 23, 2014 (UTC)

Kinda agreed with JSD,the episode and chapter page infoboxes can be automated but not the rest.--

Why was the default rname=pagename removed? No-one was complaining about that, and now most of the Devil Fruits are missing them. Either put that back on the template or fill in the parameter individually for all pages (the former would be preferred since we use japanese names for all the fruits, and the only ones that have different spelling are the model zoans).

On the topic in general, if you really want to remove them that's your prerogative, but it should have left to people (sff9 etc) who know what they're doing and are able to change things over more smoothly. This is just a mess, and it's just going to be worse if you do the same to the character pages. The problems with extra brackets and parameters came around because people took advantage of the manual override, which existed the entire time this system was in place, and was the reason why the complaints of "WAAAAH we can't change the image" were baseless and ignorant. 06:47, January 23, 2014 (UTC)

Also, I think Rora's bot only checked for Template:Devil Fruit box, not Devil Fruit Box (the former is a redirect to the latter), which would explain why so many images weren't changed. 07:41, January 23, 2014 (UTC)

Said I wouldn't post on this forum anymore, but I agree 100% with Zodiaque.

The reason things were messed up, was because Rora changed the template before you posted Nada. That's why all the nopics were there. When the useful parameter was there, all the pictures were showing up. . 13:01, January 23, 2014 (UTC)

Dafaq dude,you do it without informing the community and half-assedly at that.--

It was actually done with another admin's consent, and was done pretty fully and well. The bot has caused the broken links though, so "fixing" it has actually caused more problems. 17:44, January 23, 2014 (UTC)

Just burn this silly automation. Also episode pages lag terribly probably due to this so kill it in every article. 18:06, January 23, 2014 (UTC)

Episode pages definitely do not lag due to the automation of the images. 18:30, January 23, 2014 (UTC)

They lag due to the automation of everything combined. SeaTerror (talk) 18:51, January 23, 2014 (UTC)

Nope. The episode and chapter images were some of the first things to be automated, and it caused zero lag. Don't make stuff up please. 18:52, January 23, 2014 (UTC)

Where you went awry in your execution was the failure to realize that consent doesn't equal permission. A change that big should have been discussed before even thinking of implementing it. That's where you messed up. 18:56, January 23, 2014 (UTC)

Sff made the parameter, so yes, permission was there. But yeah, go ahead and ruin the pages. I won't be fixing the damage that Roronoa bot causes. 18:59, January 23, 2014 (UTC)

Nobody asked you. 19:11, January 23, 2014 (UTC)

Doesn't matter. Seems Zodiaque has taken on the task of fixing, but it shouldn't have been broken in such a way in the first place. 19:16, January 23, 2014 (UTC)

Fuk;It was broken because of the |image= parameter that was still resident in the middle of templates which shouldn't have been had u done the automation properly.--

You still don't get it. Permission doesn't exempt you from starting a discussion about it. Both of you should have known that. Deautomating them can only make the pages better. 03:43, January 24, 2014 (UTC)

Deautomating without knowing what you're doing makes the pages worse, but yeah, good luck.

Why isn't this being polled by the way? This discussion is going nowhere. 03:48, January 24, 2014 (UTC)

Hahah, what? You should had polled its automation, we're just going back to the old and best system. 06:28, January 24, 2014 (UTC)

Staw is right. You're only calling for a poll because you aren't getting what you want. Tell me, what kept you from polling the change before going ahead with it in the first place? 16:45, January 24, 2014 (UTC)

OK so what are the problems with this automation? I may have forgotten an important drawback, so let me know. @Roa: what has been done half-assedly exactly? Can you be more specific (on my talk page)?
 * Lag: none. It's not some complicated templating like WhichCorresponding or even Portrait Gallery and Qref.
 * Impossible to override: it has always been possible, using the "imagename" parameter (and even more brutal, the "image" parameter). Note that this was documented on the template page the whole time.
 * Annoying when renaming the page: indeed. You have to rename the images too. Wait, you have to rename them anyway, even without the automation, if you want to keep things consistent! And in the meantime the "imagename" parameter is fairly easy to use.
 * Useless: not really. It avoids having to input redundant information, enforces consistency, and prevents errors on pages that are never renamed (like chapters and episodes). It can cause errors when renaming the page—but not more than when renaming an image and forgetting to update all pages that use it, for example. And it make the whole manga/timeskip switch easy to use (basically you control everything with the "switch" and "imagename" parameters). Note that I don't mention vandalism: it was never meant to prevent it, in my opinion.
 * Has been implemented without a poll: indeed. That's the only real problem, actually, but it was a huge mistake. However, it's still possible to poll its removal, so why not?

Any automation will cause lag. Automation is not needed anywhere. Its just made for people to edit whore by removing the parameters from infoboxes. SeaTerror (talk) 20:10, January 24, 2014 (UTC)

Your first two sentences are wrong, and your third one is a joke. Let us simply ignore such comments.

That's a groundless statement ST. Anyway, in my opinion I didn't really the "file name system" to begin with, but since we use it I guess it's fine to use it to its fullest even in template like this one. Personally, I prefer using parameters like "imagename" for infobox templates.

SeaTerror's comments are hilarious when he edits pages and adds spaces and moves stub templates to fit his new "format". 21:05, January 24, 2014 (UTC)

It would seem rather silly to hold a poll about the removal of something whose implementation was never voted on prior. Send it out the way it came in, as they say. 02:29, January 25, 2014 (UTC)

No ST,it doesnt cause any lag..as sff pointed it out,Implementing it without a discussion/poll is the only reason i'm against this.--

It would be even more silly to remove something that works well for the sole reason that it was not polled. I'm ready to remove it myself, provided that arguments against the automation mechanism itself are actually a bit convincing… but as I explained in my above post, none of them is. If the "against" camp has no argument left, then solving the problem with a poll is the simplest, smoothest way. Opposing it for the sake of opposing it is acting childish.


 * Complete agreement with Sff on that one. We need more true opposition to the rule, not just people who are bitter about not being consulted, and people with little understanding of computer science. 16:04, January 25, 2014 (UTC)

Nope. Sff9 is wrong. It isn't a rule since it was never polled or discussed either. SeaTerror (talk) 16:27, January 25, 2014 (UTC)


 * Good thing we are not talking about some rule.

"We need more true opposition to the rule," Try again. SeaTerror (talk) 20:11, January 25, 2014 (UTC)

I've changed my mind,automation looks good since it forces us to name the images properly(i've come across many images that aren't)..but yeah this should've been polled.--

^ Yep. That's one of the main reasons that it was implemented. 04:03, January 26, 2014 (UTC)

^ Without a poll. And the only reason the images aren't named properly right now is because the automation was done and the image parameter was removed from infoboxes. So when you ran the bot it put all the old names back in. SeaTerror (talk) 04:21, January 26, 2014 (UTC)

So when you ran the bot it put all the old names back in,it put all the RIGHT names back since the bot used File:_Infobox.png}} for image parameter.--

True, just because there was trouble, we shouldn't get rid of it. We should just add a new code or something to change it. The only problem I see is the size of the image is not adjustable with this code. We should add something to allow us to control the size so it is not overstretched. 04:52, January 26, 2014 (UTC)

There's always trouble. Automation in general is bad. SeaTerror (talk) 04:55, January 26, 2014 (UTC)

Automation simply ruins part of the user interface when editing templates. 200px or whatever is not always perfect for every picture. Sometimes we have to play around with the size. Roa, we can name images properly without automation, noobs aside. Automation may have been the reason for the uniformity, but the two systems are by no means symbiotic. Now that we have a naming system in place, we don't need to automate anything. The wiki may be a playground for computer science majors, but that doesn't mean you get to exclude the rest of us. You have to think about everyone involved here. 18:13, January 27, 2014 (UTC)

Controlling the size is probably possible, but only Sff would know.

SeaTerror refuses to give evidence, as always, and just repeats the same crap again.

DP: The manual parameter still worked like it did before. When an image was too small to fit the 250px, the manual parameter was used. If a way to change the size can also be implemented though, that part of your argument will be flawed.

The automation doesn't ruin anything with the user interface, since I doubt anybody opens the source editor to find the name (it isn't hard to realize that the name of the image is viewable by hovering over it, or by just clicking on the image to go to the file page.) 18:52, January 27, 2014 (UTC)

The image not being in the source editor is what caused everyone to have a problem with the whole system in the first place. As long as I can do everything I could normally do with the photo in source mode ie dimensions, I don't care where the image is. I just want to be able to have them be easily editable by anyone. 17:14, January 28, 2014 (UTC)

Take the automation system out and set fire to it. As DP said, it's completely anti-new editors. Users with no experience of editing wouldn't know how to add an image or fix it, thanks to this stupid system. And before you go shooting your mouth off about how we could teach them, I don't know how to do anything involving images and info boxes thanks to your stupid automation system, and I've been on here for almost two years. 17:22, January 28, 2014 (UTC)

@DP: The image can still be uploaded the same way as before. Nobody opens the source editor to find out the name of the image. This is why Zodiaque's point from before is 100% correct. As said before, there is most likely a way to include a way to fix the dimensions with an extra parameter, so what you're arguing just isn't there.

@Jade: Everything has to be taught at some point, whether it be a new template, a new forum change, or a new wikia change all together. This is no exception (Not like there isn't a FAQ for this like there is for everything else). 17:43, January 28, 2014 (UTC)

Like it or now, we're getting rid of it. 19:44, January 28, 2014 (UTC)

We'll just need to poll it now so we can get rid of it for good. SeaTerror (talk) 19:53, January 28, 2014 (UTC)

Sure, poll it. 19:55, January 28, 2014 (UTC)

Thanks guys, for using actual arguments. Even though I don't really agree, they make sense. Just to be clear, adding a parameter to control the width of the pic is very easy—except for char boxes with switches, where it would be necessary to have one width parameter per picture… It kinda defeats the purpose. I should probably change this anyway.

@Jade, editors with no experience would not know how to add an image, even with the manual system. And you do know how to add an image, since the manual system still works the same! Plus, if it were so important to you, maybe you could have started by taking a look at the documentation… Sorry, I understand the concern about keeping things simple, but the basic automation really is: one uses the "image" parameter as usual, except that if there is none, then is used instead. What's complex is the management of the switch in char boxes.

made a test poll-- 00:56, February 7, 2014 (UTC)

I'm not sure the poll is very clear. What do "automated images" refer to? If we use Levi's proposal, that is, something along the lines of (with an optional "imagewidth" parameter), is that an "automated image"?
 * imagename = Foobar Infobox.png

It means we get rid of them completely and do images manually again. SeaTerror (talk) 21:02, February 8, 2014 (UTC)

Do we need a working example of the width parameter before we can start the poll? I'm not sure here. 15:37, February 10, 2014 (UTC)

Can we open this fast, we need to take care of it as soon as possible. 16:19, February 10, 2014 (UTC)


 * Is there any particular reason why we suddenly need to rush a forum that's been open for 6 months, or are you just saying that? 16:22, February 10, 2014 (UTC)

@DP: you can easily set up a dimension parameter so that you can edit it when needed. Also it's better to add an height limit as well to the images. Something like this: This way you can use  to set a custom dimension, without it the image would resize to fit a rectangular of 250x400px.

Well a reason to rush would be to get rid of them before the template changes go through. All the templates combined cause the lag. SeaTerror (talk) 16:57, February 10, 2014 (UTC)


 * Again, the automatation has no effect on template transclusions. Plus, I think those changes have already gone into effect without incident. 16:59, February 10, 2014 (UTC)


 * JSD is correct. On the contrary, we need to be specific to avoid future problems.
 * So, if we used imagename = Foobar Infobox.png explicitly on every page, would it be considered an "automated image" or not?
 * @JSD: I added an "imagename" and an "imagedim" parameter to Arc Box for demonstration purposes.

So are we going to vote on this thing or aren't we? 15:24, February 24, 2014 (UTC)

What was the point of this again? Does anyone still care?
In kind of the ultimate expression of how inactive this wiki has been for months, this poll never started and never left the category for test polls. Rather than read through the whole forum and remind myself of everyone's reasoning for it, I think it's better to ask one thing: Does anyone still care about this issue? I mean, does anyone really truly want to remove automation? It's been unchanged for months, and I feel like we're all pretty used to it by now. And once again, computer science says that it does not cause lag. And the image naming system is going well too. 14:14, August 30, 2014 (UTC)

Many people still want it gone. Plus it still causes red links when an image is renamed. The point still stands that nothing should be automated. SeaTerror (talk) 19:12, August 30, 2014 (UTC)

Ignoring ST's blatant ignoring of evidence against everything he says, keep it. Mr. Whatever (talk) 20:06, August 30, 2014 (UTC)

There has been absolutely no good evidence supporting this change. Automation is always a bad thing. SeaTerror (talk) 20:08, August 30, 2014 (UTC)

Yeah yeah yeah, keep ignoring everything you've ever been told. You're good at ignoring things that don't please you!

Your concern about red links is temporary and lasts... probably mere minutes as whoever renames the image is smart enough to fix the issue.

Got anything else? Mr. Whatever (talk) 20:11, August 30, 2014 (UTC)

Just reopen it. It will become active soon afterwards. The only reason that we never got around resolving this issue is because around February many users became inactive but they are back now. 20:18, August 30, 2014 (UTC)

It's been bugging me, reopen it. 07:35, August 31, 2014 (UTC)

Sigh. Not this again. How to put up an Infobox Image:
 * 1) On the relevant page, delete the image parameter.
 * 2) Click preview, then click on the redlink. This will open an upload dialogue with the correct name for the file.
 * 3) Upload your image, putting in the source/license/categories
 * 4) Click publish on the article.

Voila! You now have a correctly named infobox image in the article. Experience has shown that people don't know how to name images properly, so this process ensures complete accuracy (this is the one of the benefits that ST asserts doesn't exist).

FAQs:

What if the page is renamed? If this happens, there are two things you can do:
 * 1) Put an "imagename" parameter in the Infobox template, with the previous name of the page ([ example])
 * 2) Use the manual method ([ example])

What if the image size is all wrong?
 * Use the manual method

''This is all too complicated! Why can't we just use the old method?''
 * You can if you want. No one is stopping you. Both methods have always been available.

08:59, August 31, 2014 (UTC)