I have an infobox template containing two pieces of data, labeled "Foo" and "Bar". Foo's source is set to the template parameter "foo" and Bar's source is set to the template parameter "bar". However, if only one of these parameters is present, the other field receives a default value based on the other parameter. That is, Foo's <default> references {{{bar}}} and Bar's <default> references {{{foo}}}. In the visual editor, the user is prompted to provide values for "Foo (bar)" and "Bar (foo)". Is there any way to override these horrible descriptions? The classic visual editor is much more usable in this case.
What's on your mind?
TEXT
POLL
- All222 posts
- General17 posts
- Help & Questions0 posts
- Development & Bugs0 posts
- Mentoring Requests7 posts
- Help, Questions and Answers127 posts
- Portability Development and Suggestions32 posts
- Portability Bugs19 posts
- About Portability Wikia18 posts
- Off-Topic1 post
- 中文討論板面1 post
Sort by
Card Layout
Portability Bugs
Pretty sure this either a bug or a matter of coding. For whatever reason, infoxbox are appearing at the top of mobile pages above all preceding content. Any solution?
Heres an example - https://battlefield.fandom.com/wiki/AK-47
Just Updated
Hi all! We just updated our main infobox to portable markup site-wide over on the Eternal Card Game Wiki. I've noticing a strange quirk, I'm not sure if its a bug or just something I'm missing.
I set up the infobox title and main image to use the page's name by default, unless an alternative title or image is specified in the template parameters. Here's the markup:
<title source="title"> <default>{{PAGENAME}}</default> </title> <image source="image"> <default>{{{title|{{PAGENAME}}}}}.png</default> </image>
For most pages, the update appears perfectly fine.
The issue is on pages with an apostrophe (') in the title — for some reason the image only appears if the page's name is written out in the ""title" parameter (or the file name in the "image" parameter). Writing "{{PAGENAME}}.png" in the "image" parameter also results in a missing image.
Is there some weird interaction between {{PAGENAME}}, apostrophes, and portable infoboxes?
Also, I assume it shouldn't affect this issue but we also added some new CSS for the infobox update.
See Sandbox/ImageInDataTagDemo for example.
Groups 1 ("Bugged") and 2 ("Normal") have the same code, with the only difference being group 1 starts with collapse="closed". Opening up Group 1 shows empty space where the image is supposed to be.
I was trying to get an image in the infobox to directly link to an article, which is why I am using the data tag instead of the image tag. But the bug isn't related to links, as Test1~Test3 shows.
On a side note, when editing the page, the "Desktop Preview" will show the image in the Bugged group fine. So the preview rendering and the actual page display have inconsistent behavior.
http://relife.wikia.com/wiki/ReLIFE_(Webcomic)?useskin=mercury
The text "Kodansha Manga Award" is wrapped in a div with 30px padding.
Example: http://portability.wikia.com/wiki/User:PanSola/BugDemo
If I have to write my own CSS to style the horizontal group header, then I might as well use CSS for the title and vertical group headers (to keep things in the same place), in which case there's no point to bother with accent color ...
This is of follow up of w:Thread:1263029
For example: http://fr.bravefrontierrpg.wikia.com/wiki/Failles
The first template : http://fr.bravefrontierrpg.wikia.com/wiki/Mod%C3%A8le:TOC/Game appears on mobile (unexpected)
The second : http://fr.bravefrontierrpg.wikia.com/wiki/Mod%C3%A8le:TOC/Quests does not appear on mobile (expected)
and they are both classified as "Navigation"...
When switching TOC/Game to "Navbox", it disappears, going back to "Navigation", it reappears
I created a thread on Community Central about image scaling in Mercury when galleries/tabbers are used in Infoboxes. What we’ve found is that in the Mercury Skin the images are now chopped up; the tabber works, but only a sliver of the image is visible (whereas infoboxes without tabbers show the whole image). I & another more tech savvy user have looked into this & come up with nothing, even after testing it out on multiple Wikis with different infoboxes; the result is the same. Additionally, FishTank responded in the thread suggesting that the image be scaled up to fix the problem, so we tried scaling the image to 198x198, 500x500, & finally 1000x1000; the image became larger, but it remained chopped up. It was at this point that several users in the thread suggested that I make a bug report in this board with the previous information; so here I be.
Examples
- What the Mercury page looks like with old Infoboxes
- What the Mercury page looks like with Tabber Infoboxes
Templates Used
Template Parameter Used
{{Infobox |image = <gallery> Sniper.png|Old Colors Newsniper.jpg|New Colors </gallery> }}
[redacted CSS, cause it's not relevant to this problem]
I hope someone can help!
Sorry for the ridiculous title, here's an example of what I'm talking about:
<infobox> <group row-items="2"> <data source="foo" /> <data source="bar" /> </group> </infobox>
The row-items
attribute was added recently (documentation diff), and I think it's a lot better than layout="horizontal"
. The code is a little clearer (though columns
might have been a better name), and we can finally collapse multiple columns! However, on wikis with the "Europa" theme activated, the above code will render as two cells with no padding on top. You can see a live example here, under "Types".
As an aside, is there some reason why this feature wasn't advertised? One of my biggest complaints just got addressed, so I think it's pretty cool! :)
Writing <br>
within the PI source editor triggers autoclose which makes no sense. Same for <hr>
and <wbr>
tags.
Howdy o/
Just converted this Episode template to a portable infobox manually (rather than using the migrate button) but it's still showing the notification on the right for it being non-portable? Also still shows in insights as non-portable? What could be going wrong here?
See Gallery in Infobox Worked Yesterday but Doesn't Work Now on CC.
This small change seemed to fix the invocation of a PI, but it shouldn't have been needed.
I've noticed that on the wikis I admin (and one that has no admin that I'm hoping to adopt) that Insights still show that I have infoboxes to migrate, but upon following the link, only dead links are listed. (example: http://orange-is-the-new-black.wikia.com/wiki/Special:Insights/nonportableinfoboxes). Where it says "used on x articles", the article links are also dead. I thought it might be a cache issue that would eventually disappear, but it's been a few weeks now. Any ideas?
Hi there! I'm an Admin on the Half-Life wiki and for the last few months I've been converting our Infoboxes to the Portable markup, this weekend I finished the converting the last one.
This is my situation; about three weeks ago we had 10 Infoboxes remaining to be converted, that day I converted one more, applied the changes on some articles, went to bed; and so we now had 9 Infoboxes remaining in our Insights page.
The next day, I wake up and see again the red little "10" icon near the remaining Infoboxes, I open the page and see this template listed at the bottom, at the time it was a non-existent page and nothing in the wiki was linking to it. Curiously, that is the IP of a user that started editing a couple days earlier.
I tried a few things to get rid of it, like creating and deleting it and changing the template type, but it's still there.
Today, after having converted all our Infoboxes, I was going to try pasting the code from another Infobox in there, but what do I find when I enter the wiki? Another non-existent template named with the IP of another user that made an edit a few days ago and nothing linking to it.
This is our Insights - Non-portable infoboxes page currently.
Is this a known bug? Did I break something somewhere?
Allegedly fixed (http://community.wikia.com/wiki/User_blog:Kirkburn/Technical_Update:_July_18,_2016#comm-1075411)
Last night I noticed that the portable infobox css suddenly changed from:
.pi-data-label { -ms-flex-preferred-size: 90px; -webkit-flex-basis: 90px; -moz-flex-basis: 90px; flex-basis: 90px; }
...into:
.pi-data-label { -ms-flex-preferred-size: 90px; -webkit-flex-basis: 90px; -moz-flex-basis: 90px; flex-basis: 90px; max-width: 80px; word-wrap: break-word; }
Obviously this caused our infobox labels to word-wrap into narrow columns. This doesn't look correct to me and I seem to remember it happening once before in the past as well.
It seemed like a bug and not something that would be desirable, so I am posting it here.
I am currently migrating template-based classic infoboxes in TLJ.wikia.com to the portable infobox format. Three of the infoboxes have 100+ pages each that use them. Unfortunately, many of those pages use "image" parameter values that start with "image:" instead of "Image:". The portable infoboxes fail to show these images.
The portable infobox implementation should support "image:" as a valid prefix.
[Fixed] By the way: On Board:Portability_Bugs, the link "this" is broken, it should point to http://community.wikia.com/wiki/User_blog:DaNASCAT/How_to_Report_Bugs_to_Wikia instead.
Disclaimer
If this is not the right forum, please direct me. Since this is about wikia inserting a (perhaps strict compliant) <p> tag for a template typed as "InfoIcon", I figured it was portability
Problem Description
It's a one-liner now, to reduce the possiblity of whitespace, but aligned here for clarity. Actual code
<includeonly> {{#switch:{{{pos}}} | right-of = <span class="dpe-icon dpe-icon-right-of" style="padding: 0 0.25ex 0 0;"> [[File:{{{1}}}.png|frameless|middle|link=|{{{size|16px}}}]] </span> | in-between = <span class="dpe-icon dpe-icon-in-between" style="padding: 0 0.25ex 0 0.25ex;"> [[File:{{{1}}}.png|frameless|middle|link=|{{{size|16px}}}]] </span> | #default = <span class="dpe-icon dpe-icon-left-of" style="padding: 0 0 0 0.25ex;"> [[File:{{{1}}}.png|frameless|middle|link=|{{{size|16px}}}]] </span> }} </includeonly>
Expected result
The following:
{| |- |67{{Icon|Goldcoins|pos=right-of}} |}
Should result in the following for the table data tag:
<td> 67<span class="dpe-icon dpe-icon-right-of" style="padding: 0 0.25ex 0 0;"> <img class="" width="16" height="16" superfluous-js="skipped" /> </span> </td>
Actual result
Final remarks
If this is tidyhtml or some variant doing it - then do it right and encapsulate the entire table data in one p tag.I've filed it with Wikia, but I figured I'd let you all know about it too.
Our templates encompass the entire page to better control where everything sits in display.
This means that our references tag is placed within the page's template and no one has to write it in manually.
What I've noticed, is that on every Template I've converted to use PI in the infobox, the references tag within the same template does not display.
The only way I could make it work was by offering a field for the position it should go, and have the user enter the references tag there.
Examples:
The references tag should show in the footnotes section.
I just converted a template that used number variables and I discovered a little oddity:
{{template|foo|bar}}
In classic wikicode foo
will be avalible in the {{{1}}}
variable and and bar
will be in {{{2}}}
.
In the infobox however, foo
can be found in <data source="0" />
and bar
in <data source="1" />
.
I'm fine with that behaviour but the automatic conversion script translates number variables in the old style.
EDIT by FishTank: Greetings! For all of you who have been following this bug (also mentioned here), we hereby announce that the fix is in. It is scheduled for the January 7, 2016 release. So, please be aware that those who have worked around (or used to their advantage) this bug, that is the day to fix it. Thank you for your patience!