Hello,

Is it possible to have something like

<data source="param1 param2 param3">
<format>Displays something when at least 1 of 3 parameters entered</format>
</data>

OR

<data source1="param1" source2="param2" source3="param3">
<format>Displays something when at least 1 of 3 parameters entered</format>
</data>

A workaround using wikicode which I thought would work was:

{{{dummy|{{{param1|}}}{{{param2|}}}{{{param3|}}}}}}
<infobox>
<data source="dummy">
<format>{{{param1|}}}{{{param2|}}}{{{param3|}}}</format>
</data>
</infobox>

But this doesn't work.

I think it would be a great idea if you could integrate File:Placeholder into the new portable infobox to enable adding images easier.

I imagine plenty of other people/wikis have done it already, but I don't really know where to look for examples. Thread:2508 doesn't seem to have gotten anywhere?

This is what I have right now: http://relife.wikia.com/wiki/User:PanSola/Navibox_hack/Demo

I'm interested in getting feedback on whether I'm doing anything outright evil that should be avoided at all costs (versus the traditional using table to build naviboxes), as well as other ideas for improvement.

It's been almost 2 years. Any progress on desktop users getting the mobile version with the images?

http://community.wikia.com/wiki/Thread:935527#54

Would there be any way to allow slideshow image galleries to be implemented within portable infoboxes ? Compare.

When <image /> tag's source attributes refers to a file that has not been uploaded yet, PI renders no image section. However, I believe there are people like me preferring to see a newlink File:Foo.bar to be able to simply upload the image through it.

This becomes particularly convenient when you want to use parameter values as the file name. Say you have a syntax like:

File:{{{Name|{{PAGENAME}}}}}_{{{Gender}}}_{{{Level}}}_Portrait_w200.png

You need to check through these parameters, get their values and format the entire file name for every page you want to provide an image to, while a pre-formatted newlink pointing to the right path can cover all this for you, with less chance of missspelling.

+ If you find a newlink too ugly, what about an Upload image button instead?

When somebody thinks about making an infobox with a completely different design, like myself, he/she should start from either resetting the default settings or overriding it part-to-part(this reminds me of constant nightmare with Bootstrap).

A standardized system is useful to most of people, but sometimes stifles creative attempts. I would like to have an option to create PI without the CSS bundle.

original thread http://community.wikia.com/wiki/Thread:1179538

So far theme-source and two accent color attributes are the only attributes that can't have default values or values based on other attributes. I think it would be great to have a way to extend current PIs limits.

This has been my little pet peeve ever since PI came out - the fact that I can't easily access the infobox image's file page like normal thumb images in the article page. I'm not sure of the reason to have the infobox image in "frame" mode, but I prefer the thumb mode, which on the pages itself give me the little i icon on the bottom right that takes me to the file page.

Whereas PI is now more flexible with its image tag able to process file:titles, [[file:links]] and even tabbers, [[file:links|thumb]] has no effect towards what I hoped to achieve.

It'd be really helpful to me if this can be implemented. Thanks in advance.

I'm a nominal admin (no longer active due to reasons) to this one wiki, and I've added Bootstrap's label classes for use in three cases: flags/notes on a very long list (here), a contests portal and an infobox template. It looks fine on desktop, but as you know classes are stripped off mobile, and Wikia.css doesn't load on it. The end result is that on mobile these notes/flags collide into the list item's text. There's no problem with the other two cases.

I have thought of a way to remedy this, by:

• put what you want to appear on mobile as the text node. Preferably with brackets placed as hard text (not CSS :before and :after text because that doesn't work)
• on desktop, hide the class elements entirely
• on desktop, place text to appear on a data-text html attribute, and display that instead (with .label:after{content:attr(data-text);...} )

Or you could just let me add the label classes to the mobile CSS itself. Too bad the hackaround no longer works.

From http://portability.wikia.com/wiki/Portability_Checklist

"Avoid using style=’clear: both’ by itself or via Template:Clear, Template:Clr, or
. These create spacing issues."

I've seen that some formatting tricks for desktop view don't look so good in mobile view, e.g. half line height spacing between paragraphs. I don't want to get rid of them from desktop view, however. Is there any code we can use that will be like "ignore this/substitute with a normal line break if in mobile view"?

Currently, it has become an exercise in futility trying to remove inline styling from some wikis without requesting staff to outright disable the  classic editor  because ignorant editors will happily use it to add new content. The greatest offender is the table builder / editor  which generates a lot of pointless inline styling.

I posted this a few days ago on the talk page of the infoboxes on Community Wikia but it seems my comment was either not seen or ignored.

I have a complaint about the recent update made to the portable infoboxes. A couple of weeks ago, if you were seeing from mobile devices an infobox with a single image (i.e. no gallery or tabber) and a caption, the caption was shown at the bottom of the image, and if you clicked the image, it would enlarge to its full size. Now, the caption is missing, and the image is no longer clickable, so it's impossible to see its full size and only the square thumbnail is shown. I don't understand why these two functions were removed, but the infoboxes are definitely less useful as a result. Please restore the caption and the option to enlarge the picture.

One of the benefits of the structured format used for portable infoboxes is that there is a distinct tag used for images. 

In the future this could allow users to add specific content using dropdowns, number input boxes, dates, and so forth. 

For now, my suggestion is to pick up the image parameter and use it to choose an image, given an infobox with this format:

<infobox>
<image source = "myimage"> 
  <caption source="myimagecaption"></caption> 
</image>
</infobox>

It would be good to use the "myimage" parameter e.g. "$("infobox image").attr("source")" to determine if it needs an image and pick this from an image/ video insert dialog or gallery dialog using the Visual editor. In fact, the caption could also be extracted used for the image caption.

It's evident that portability is a high priority at Wikia, and right now the features PI brings don't cut it for advanced usage. Between it being aggressively advertised and the intent to get it on as many wikis as possible, it's apparent that despite it's shortcomings it's still being pushed as the best thing since sliced bread.

I'd very much like to use the database features that are in the pipework and will be tied into PI. However, if PI itself isn't suitable then access to those extras are implicitly blocked. Based on what I've heard about the plans for it and what it could be if it's done right, PI could actually be the best thing that's ever come to Wikia.

With that in mind, I'd like to point to RuneScape Wiki, and why we haven't used it. After a forum thread went badly wrong due to the sudden appearance of advertisement bugs (which seem to be an isolated incident), I've watched PI develop. In terms of features, it hasn't and the reasons we rejected it remain as valid today as they were then.

In the hope that this post might change that, here's a summary of why we haven't used it:

• Stability - We've been caught too many times by changes that broke various parts of the wiki. Whether those were bugs or genuinely new features it remains a concern. From a software perspective, many don't upgrade until the majority of the bugs have been worked out and the implementation has been finalised. If we have to do major changes each month or so, it's a pain. With a continuous release cycle, that's never going to be achieved, but with advancements such as the recent CSS changes that could have feasibly broken local theming it remains a concern.
• Custom attributes and classes - It's reasonable to want to have a stable API for everyone to use. Extending this to cover use of attributes within XML is equally understandable. What's not understandable, is why the ability to add arbitrary classes has been removed. If we look at runescape:TzTok-Jad we can see the groups have been colour coded as a way of improving UX. With PI, you can't do that. Additionally, the use of data-* attributes is similarly missing. I'm all in favour of JS that gracefully degrades if it's missing, e.g. mobile, so we use data-* attributes to load data to be utilised and manipulated by JS. But we can't do that in PI.
• Multiple entities per page - Some wikis use switch infoboxes, of varying complexity. Some of them just swap images, other have a more complex setup. Over a couple of years, we experimented with using multiple infoboxes and hiding/showing them as required with JS much to the detriment of mobile. More recently, we switched to using data-$param attributes paired with JS to handle them instead, which degrades better for mobile users and is much easier to maintain on the pages (one template with multiple params instead of multiple templates with potentially duplicated params), see runescape:Verac. Given it's extensive use, even with improvements to granularity of late for unrelated reasons, it's a hard requirement for us.

The addition of lang="<insert lang here>" to the infobox <data> tag from the template page should implement the language tag onto the label. It doesn't appear to do so right now.

There are some triggers that prompt the "Migrate this infobox" message, even though it is a new-style infobox. This may or may not alter the editor preference as well. I'll try to list the examples as I bump into them.

• Infobox Dragon

Ideally, I'd like at least one level of sub-grouping. Maybe two, but any more will get clutterish. So I'm open to introduction of a subgroup tag or to simply allow the group tag to be nested. At present, group is allowed as child of group (it doesn't generate a parser error), yet it isn't rendered.

A very common case for this is when you have data that's related and can be classified in related data itself. Example:

Actors and Actrices

Featured

• Diva Magnificent
• Hunk Sixpack

Stars

• Babe Hottness
• Babyface Bigsmile

There's also case where you want to intermix normal data and grouped:

Item properties

Type	Merchant fodder
Tribute value	0
Drops in	Kael Drakkal

Sells for

Platinum	Gold	Silver	Copper
276	55	0	9

Hope I made a case for it. :)

Over at Destiny Wiki, we have an optional infobox for use on user pages. When I converted this to a portable infobox however I found that the external images used by users would not display. I managed to make a work around in which the image appears inside the title tag, however it will not work for mobile users (as expected).

Would it be possible for external image support to be implemented?

• Infobox with Workaround Implemented on Test Wiki
• External Image Resize Template on Destiny Wiki

It would perhaps be useful to have the possibility to set all groups to autocollapse by default, and only show the needed groups or alternatively set a header to collapse all content below it:

<infobox collapse ="closed"> <group collapse="open"></group> </infobox>

Also the  current process isn't at all intuitive, I didn't initially realize that the header needed to be added until I looked at the documentation.

Perhaps whenever the "collapse=closed" attribute is set without any header, the infobox can either display an error, or perhaps add the chevron somewhere on top of the group.