FANDOM


  • Noreplyz
    Noreplyz closed this thread because:
    Old post
    08:08, September 9, 2017

    Hello infoboxers!

    We've added some new functionality to how the <image> tag works in the infobox markup. Now you can introduce tabs to your desktop infoboxes, and they'll be repackaged as galleries on mobile.

    Many legacy infoboxes use tabber (and a few use galleries) to display multiple images about a character. For example, on the Dragonball wikia they use tabber to show the different covers for different regions and on the Metal Gear Solid wikia they use tabber to show the different incarnations of the character in each game. We see similar uses for different versions of characters in multiple cannons, series, or realities.

    The code for this change has been released and is currently live on the site, and it looks like this - the first image is on desktop, and the second is on mobile.

    Infoboxtabs
    Mobileinfoboxgalleries

    If you build an infobox template with an <image> tag anywhere appropriate in the markup:

    Template:Animal infobox
    <infobox>
    <image source="example" />
    <title><default>Animal</default></title>
    </infobox>
    

    you can embed the infobox template on an article page, like either of these examples:

    Animal infobox
    |example=<gallery>
    Dog 1.jpg|Boxer
    Dog 2.jpg|Beagle
    Dog 3.jpg|Golden Retriever
    </gallery>


    Animal infobox
    |example=<tabber>
    Boxer = [[File:Dog 1.jpg]] |-|
    Beagle = [[File:Dog 2.jpg]] |-|
    Golden Retriever = [[File:Dog 3.jpg]]
    </tabber>
    

    More info:

    • You won’t need to edit the Infobox markup at all. We added 0 new tags with this feature upgrade. The same <image> will support either a single image or multiple images.
    • We recommend using the gallery tag as opposed to the tabber tag. It’s much more stable and easier to read.
    • There is no support for nested tabber at this time. We’ll flatten the tabs in the order they are presented in the article’s wikitext.

    Thoughts? Questions?

      Loading editor
    • Wow! So, time for changes! Thanks Wikia!

        Loading editor
    • You're welcome! Buena suerte!

        Loading editor
    • This is a great tool, and perhaps you've won over 25% of the people who were against portable infoboxes. Once something is developed for styling infoboxes you'll probably get support from 99% of users because even legacy infoboxes are incredibly hard to style. People just prefer them because it doesn't require admin "permission" and most of them are already styled.

      There is no support for nested tabber at this time. We’ll flatten the tabs in the order they are presented in the article’s wikitext.


      I hope that support is never added. It will simply add unnecessary complexity to the infoboxes. I've noticed that some of the attributes or parameters of the gallery are simply ignored by the portable infobox. For example, someone[1] was concerned that the caption of the tabs wasn't different from the label of the tabs, perhaps using the linktext for this will help.

      It might also be worth revising other gallery options [2]  to change how it is actually presented in the infobox, and add any features Wikia deems useful.

        Loading editor
    • For sure, Dessamator, and this is great feedback. 

      Between you and me (and this entire forum of users), the community team has learned very well that CSSifying infoboxes is a complex undertaking, and we definitely do want to give you folks a simpler way to style them. I can't say too much about it now, but stay tuned.

      And I agree about nested tabber - it's a neat trick, but goodness does it exponentially expand an infobox's complexity.

        Loading editor
    • Thank you! I've been waiting for this feature to convert the last few infoboxes to PIs. However, I'm not getting the Tabber version to work, only the Gallery version. See this demo page.

      Also, it ignores file names with an ampersand (&) in the name.

      EDIT: Is there a way to put a caption on the tabber/gallery, or on each individual image? Just curious.

        Loading editor
    • This didn't working in Monobook. Click!

        Loading editor
    • Moviesign wrote: Thank you! I've been waiting for this feature to convert the last few infoboxes to PIs. However, I'm not getting the Tabber version to work, only the Gallery version. See this demo page.

      Also, it ignores file names with an ampersand (&) in the name.

      EDIT: Is there a way to put a caption on the tabber/gallery, or on each individual image? Just curious.

      1. That's bizarre, it should render correctly. We'll take a look. Figured it out:

      You had plain file names:

      <tabber>
      4e = 4e_orc.jpg
      |-|
      3e = Orc.JPG
      </tabber>
      

      When you needed to invoke them as thumbnails:

      <tabber>
      4e = [[file:4e_orc.jpg]]
      |-|
      3e = [[File:Orc.JPG]]
      </tabber>
      


      2. Yay! Another bug. Thanks for reporting.

      3. Not yet. We've thought about it, but we wouldn't be able to support <gallery> usage.

        Loading editor
    • OH! I thought it was the same way as <gallery>, my bad!

        Loading editor
    • I think this calls for a new tag. If it isn't really exactly a gallery, it should have a different tag. <tabbery>? LOL!

        Loading editor
    • Ohmyn0 wrote: You had plain file names:

      <tabber>
      4e = 4e_orc.jpg
      |-|
      3e = Orc.JPG
      </tabber>
      

      When you needed to invoke them as thumbnails:

      <tabber>
      4e = [[file:4e_orc.jpg]]
      |-|
      3e = [[File:Orc.JPG]]
      </tabber>
      

      Then please update the example in the OP accordingly :)

        Loading editor
    • SethFu wrote:

      Then please update the example in the OP accordingly :)

      Done.

      Walks away in embarrassment.

        Loading editor
    • Good start but nope, not for me. I'd rather add the images via separate parameters (ie. front cover, back cover) that go into the tabber code on the template page instead of lumping them together with extra code on every individual page.

        Loading editor
    • Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...

        Loading editor
    • LordTBT wrote: Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...

      Seconding this, that looks really good.

        Loading editor
    • I thought that was a product of using tabber in the first example, but seeing that it's not, I'm thirding that.

        Loading editor
    • LordTBT wrote:
      Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...


      Yep, I also think the mobile version looks way better.

        Loading editor
    • LordTBT wrote:
      Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...

      The problem is not with the "million tabs", it is with users who want to add a million tabs. 

      More importantly, while mobile space is limited, a desktop generally has more space and having to click "million times" to see the last image is not a good user experience. Unfortunately, that's a necessary tradeoff for mobile.

        Loading editor
    • Wouldn't it make better sense to use this code on the infobox's template page, where it could pull the data from multiple parameters than having to code additional galleries/tabbers on every single page that uses the infobox? For example, if I've got a wiki where a multiplicity of characters have different images based on manga/anime/game1/game2/game3, I don't want to write this on every page:

      Template:infobox character
      <gallery>
      Red Dog 1.jpg|manga
      Red Dog 2.jpg|anime
      Red Dog 3.jpg|Game1
      </gallery>
      

      When I could just use standard naming scheme and a simple parameter in the infobox. This would let the infobox template deal with writing out all the labels & naming schemes:

      Template:infobox character
      | image = Red Dog
      

      or even:

      Template:infobox character
      | image1 = Red Dog 1.jpg
      | image2 = Red Dog 2.jpg
      | image3 = Red Dog 3.jpg
      
        Loading editor
    • Vandraedha wrote:
      Wouldn't it make better sense to use this code on the infobox's template page, where it could pull the data from multiple parameters than having to code additional galleries/tabbers on every single page that uses the infobox? 

      Anything that can be passed through a template to an infobox can also be used directly in it. So what you want to do is entirely possible. It is simply a matter of replacing those names or images with template parameters, see the page below for an example:

      They just put it like that in the opening post as an example. It'll probably be clearer once the Infobox documentation is updated.

        Loading editor
    • Hey Ducksoup, thanks for this. I had always been hoping for this.But is it possible to have some CSS coding that could customize the appearances of the tabbers/galleries in all portable infoboxes?

        Loading editor
    • I'm working on styling the tabber to look like the original. If I get it working, I'll post the CSS. Don't hold your breath tho :-)

        Loading editor
    • Moviesign wrote: I'm working on styling the tabber to look like the original. If I get it working, I'll post the CSS. Don't hold your breath tho :-)

      Don't worry. I can wait.

        Loading editor
    • Pinkgirl234 wrote:
      Hey Ducksoup, thanks for this. I had always been hoping for this.But is it possible to have some CSS coding that could customize the appearances of the tabbers/galleries in all portable infoboxes?

      Easy:

      /* This is for all tabs */
      .portable-infobox .pi-image-collection-tabs li {
        background: #145BD4;/*your color here*/
        color: white;  
      }
      /* This is for the current selected tab */
      .portable-infobox .pi-image-collection-tabs li.current {
        background: green; /*your color here*/
        color: white;
      }
      /* The whole gallery/tabber box*/
      .portable-infobox .pi-image-collection {
        background: red; /*your color here*/
        border:5px solid red;
      }
        Loading editor
    • Dessamator wrote:

      Easy:

      /* This is for all tabs */
      .portable-infobox .pi-image-collection-tabs li {
        background: #145BD4;/*your color here*/
        color: white;  
      }
      /* This is for the current selected tab */
      .portable-infobox .pi-image-collection-tabs li.current {
        background: green; /*your color here*/
        color: white;
      }
      /* The whole gallery/tabber box*/
      .portable-infobox .pi-image-collection {
        background: red; /*your color here*/
        border:5px solid red;
      }

      Thanks dude. I'll be using this today, but using the colors according to my own preference of course. How did you figure it out so easily?

        Loading editor
    • All major browsers provide some way of viewing (and editing) the css  used in a webpage, for example, these are chrome's instructions:

      You can also simply save the web page and view it normally but that's more time consuming.

        Loading editor
    • Here is a set of CSS selectors that will make a <tabber> used in the <image> tag of a Portable Infobox look like the regular tabber. As far as I know, the PI tabber feature does not work in monobook, so I could not test it. No warranty is expressed or implied. Use at your own risk :-)

      .pi-image-collection {
          margin-top: 0.5em;
          text-align: center;
      }
      ul.pi-image-collection-tabs {
          border-bottom: 1px solid #778;
          font: bold 12px Verdana,sans-serif;
          list-style: none outside none;
          margin: 0 0 2px;
          overflow: visible;
          padding: 0 0 4px;
          text-align: center;
      }
      ul.pi-image-collection-tabs li.current {
          background: none repeat scroll 0 0 #FFF;
          border-bottom: 1px solid #FFF;
          font-weight: bold;
      }
      ul.pi-image-collection-tabs li.current:hover {
          background-color: #FFF;
          border-bottom: 1px solid white;
      }
      ul.pi-image-collection-tabs li {
          -moz-border-bottom-colors: none;
          -moz-border-left-colors: none;
          -moz-border-right-colors: none;
          -moz-border-top-colors: none;
          display: inline;
          line-height: normal;
          list-style: none outside none;
          background: none repeat scroll 0 0 #DDE;
          border-color: #778 #778 -moz-use-text-color;
          border-image: none;
          border-style: solid solid none;
          border-width: 1px;
          color: #448;
          margin: 0 0 0 3px;
          padding: 3px 0.5em;
          text-decoration: none;
      }
      ul.pi-image-collection-tabs li:hover {
          background: none repeat scroll 0 0 #AAE;
          border-color: #227;
          color: #000;
      }
      .pi-tab-link.pi-item-spacing {
          padding: 3px 5px 4px;
      }
      
        Loading editor
    • Dessamator wrote:

      LordTBT wrote:
      Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...

      The problem is not with the "million tabs", it is with users who want to add a million tabs. 

      More importantly, while mobile space is limited, a desktop generally has more space and having to click "million times" to see the last image is not a good user experience. Unfortunately, that's a necessary tradeoff for mobile.

      Well, I wouldn't describe "users" as "the problem" myself.

      Redwall is a book-related wiki. We have images of every translation, in some cases this is above 20. This, imo, would be a great usage of this new function.

      However, I think that amount of tabs is aesthetically and functionally unpleasant.

      Thus, if there were an option to make the mobile "slideshow" possible to be displayed on mobile AND desktop, that would be fantastic. Hoping Wikia can weigh in here, given the support above.

        Loading editor
    • We've considered the idea of allowing for tabs on mobile and a slideshow on desktop. The fact that you're discussing it is great feedback that these options would provide some usefulness.

      We wanted to get a first version out, see how it's received, and plan from there. This feedback is helpful.

        Loading editor
    • LordTBT wrote:

      Well, I wouldn't describe "users" as "the problem" myself.

      Redwall is a book-related wiki. We have images of every translation, in some cases this is above 20. This, imo, would be a great usage of this new function.

      However, I think that amount of tabs is aesthetically and functionally unpleasant.

      Thus, if there were an option to make the mobile "slideshow" possible to be displayed on mobile AND desktop, that would be fantastic. Hoping Wikia can weigh in here, given the support above.

      I briefly looked through Redwall wiki and didn't find a single infobox with a gallery. Even among the most used infoboxes according to Special:Insights, so I find it hard to believe that this has suddenly become an important use-case.

      The appearance of the tabs can also be changed with css. So while I don't particularly have anything against slideshows in portable infoboxes, I believe that much like galleries they should be restricted to a reasonable number, and perhaps other images can be viewed in a separate page , popup or lightbox.

      Wikia is currently defining or redefining what infoboxes are, and some restrictions need to be put into place to make sure they don't become kitchen sinks.  

      @Wikia Staff:

      One possibility with this new tabber design is to use svg (or other) icons instead of text for the tabs, although this can probably be achieved using css. An image is worth a thousand words after all.

        Loading editor
    • Moviesign wrote:

      Also, it ignores file names with an ampersand (&) in the name.

      The special character in file names issue( e.g. & or '  ) appears to be an old bug (see Thread:908343). It seems that files with special characters uploaded before a certain date (presumably before 2015) can  cause issues with other features. Someone reported this in the forums, I can't recall the exact thread title though.

      Apparently, newly uploaded files don't have this problem. Try uploading a newer version of the file with a slightly different name (keeping the ampersand).

        Loading editor
    • Good catch! I gave it a try, but to no avail. The only way it worked was to remove the &. My steps:

      1. I uploaded a newer version of the same file and that did not fix it (after much purging and cache clearing).
      2. I uploaded a fresh copy with a slightly different file name, keeping the ampersand. That did not fix it.
      3. I renamed the fresh copy to a name without an ampersand, and it worked.
        Loading editor
    • Dessamator wrote:

      LordTBT wrote:

      Well, I wouldn't describe "users" as "the problem" myself.

      Redwall is a book-related wiki. We have images of every translation, in some cases this is above 20. This, imo, would be a great usage of this new function.

      However, I think that amount of tabs is aesthetically and functionally unpleasant.

      Thus, if there were an option to make the mobile "slideshow" possible to be displayed on mobile AND desktop, that would be fantastic. Hoping Wikia can weigh in here, given the support above.

      I briefly looked through Redwall wiki and didn't find a single infobox with a gallery. Even among the most used infoboxes according to Special:Insights, so I find it hard to believe that this has suddenly become an important use-case.

      The appearance of the tabs can also be changed with css. So while I don't particularly have anything against slideshows in portable infoboxes, I believe that much like galleries they should be restricted to a reasonable number, and perhaps other images can be viewed in a separate page , popup or lightbox.

      Wikia is currently defining or redefining what infoboxes are, and some restrictions need to be put into place to make sure they don't become kitchen sinks.  

      @Wikia Staff:

      One possibility with this new tabber design is to use svg (or other) icons instead of text for the tabs, although this can probably be achieved using css. An image is worth a thousand words after all.

      Even as a concept, this did not occur to me until I saw this very thread. And when I did, I thought it was a great idea. Provided slideshow functionality was available for desktop in addition to mobile, I would roll it out immediately. "Important-use case" is entirely subjective.

      Furthermore, I'd add restrictions are also entirely subjective. Wikia editors should be allowed to use this function as they see fit. If your individual wiki does not want X number of images in a gallery, make it part of your official rules. It doesn't need to be a part of the code here.

        Loading editor
    • So, just to be clear, this gallery thing is only a partial replacement for tabber, since it mostly only works for images. Correct?

        Loading editor
    • I believe it is true that galleries only work with images. However, I have not been able to get anything other than an image to display in a tabber passed as an argument to <image> inside a Portable Infobox. I tried plain text and in-line templates, just to see. It is expecting images and videos only.

      But good news! It appears they have fixed the link problem when tables are used inside tabbers inside a PI. This demo page is now working! (The links in the tabber at the very bottom of the infobox were missing, and now they are being rendered.)

      Tabbers passed as arguments to regular <data> fields seem to work fine.

        Loading editor
    • Cqm

      I think this is a step in the right direction, but I feel it's a confusing mix of extensions/tags. I also feel it should have been implemented at the tag level, i.e. in the template itself, rather than at the argument level as the template is really where any logic or complication should be handled. A template should offer a simple, powerful and intuitive API that can be used by anyone irrespective of how little experience they have. I find it unlikely someone using VE will be able to edit a field set up in this way.

      I think it would have been cleaner to offer a something more inline with what's already offered. For example:

      <infobox>
        <image prefix="image-">
        ...
      </infobox>
      

      However, that example doesn't support a default. So, how about this instead:

      <infobox>
        <data prefix="image-">
          <!-- other potential attributes might be "limit" to limit the number
               of parameters used and "default" to specify whether a missing
               image should default to the default tag or the first use of the
               parameter, e.g. default="1" or default="default"
          -->
          <image prefix="image-">
          <default>Default text here</default>
        </data>
        ...
      </infobox>
      

      Which could be used as:

      {{infobox
       | image-1 = 
       | image-2 = 
       | image-3 = 
       ...
      }}
      

      The good thing about integrating this with the <data> tag is that it allows other parameters to have multiple values too, while adding one more attribute to the API thus keeping it relatively simple instead of having to lookup other syntax to achieve what you want.

      I'd agree with Lord TBT that a large amount of tabs is aesthetically unpleasant. So what about limiting the number of buttons to 2-3 — just limit it to the what fits within a single line of the infobox — and then using a dropdown instead?

        Loading editor
    • @Cqm:

      The image tag can't currently be nested inside the data attribute. So that would require some changes. It is also confusing because one would need to know if the data is parsed as an image or text. What about people who mistakingly mix text, audio, and images?

      How exactly would it parse that data?

      Beyond that, your syntax suggestion wouldn't cover a label for each tab and its caption. Perhaps this could be as simple as :

      | image-1 = File:example.png , my-caption, my-tab-label

      The problem with that is that MediaWiki allows special "nonsensical" characters in files or pages, so if the filename or the caption has a comma as a delimiter , it wouldn't parse properly. Putting it inside a construct like gallery or tabber overcomes this problem, perhaps that's why they used it.

      I'm not sure they want to support tabbed text or other media. This may perhaps make the infobox too complicated and hard to edit or create using a VE Gui tool.

        Loading editor
    • Cqm

      @Dessamator I was told it worked when I wrote w:c:rs:Template:Infobox City/Draft recently and never got around to testing it. As it turns out it doesn't work properly, as you said.

      With this new 'revelation', what about:

      <infobox>
          <image prefix="image-">
              <!-- add alt and caption tags here -->
          </image>
          ...
      </infobox>
      

      I'd actually be inclined to move the tab label out of the image tag, and use a label or tab tag instead, to make it more flexible in the future.

      To be honest, I haven't thought too much about VE, but I very much doubt the existing gallery/tabber syntax is at all easy to grasp anyway.

        Loading editor
    • @Cqm:

      I think Wikia did a great service to the community by allowing tabbers as arguments to the <image> field. Implemented as you describe, it would have required the editing of thousands of pages and taken up many hours of people's time. So, yay for backward compatibility. :-)

      @Dessamator:

      One solution to punctuation in file names would be to just require the use of the [[File:]] tag (with brackets) like it is already required for tabber. But you also have the same problem with my-caption and my-tab-label—they might contain punctuation too.

        Loading editor
    • @cqm: 

      You don't really need to submit the whole thing as an argument to an infobox . I'm not really sure who spread that misconception. You can embed it into the portable infobox and use the tag parser function to obtain whatever you need. In fact you can make it parse whatever format you want using lua or a simple template to create the gallery or tabber, see:

      I still agree with you that they should provide an easy to use syntax so that  inexperienced editors can still make their infoboxes functional with minimal effort.

      @Moviesign:

      Getting around the delimiter issue is easy, one could adopt a similar syntax to json or something else:

      |image1 ={example.png,  label = example , caption = whatever}

      Or

      |image2 =example2.png ,  label = example2 , caption = whatever2 

      my-Image3.png, label =my-Label3 , caption = my-caption3

      or 

      my-Image3.png,  my-Label3  |  my-caption3

      Another option is to use heredoc syntax.

        Loading editor
    • @Dessamator: I'm not sure how faithfull an SVG would render on mobile, but it's certainly something what we could take a look at. I think our first order of business, though, is making sure all plantext characters render effectively.

        Loading editor
    • @Cqm — Good feedback. There are pros and cons to supporting both single-parameter construction and multi-parameter construction (consistency, complexity, amount of markup, etc.) We erred on the side of simplicity for this initial version to get feedback more quickly.

      That said, I 100% agree that passing <tabber> or <gallery> is not an acceptable final markup. We chose it as a "quick win" because a lot of communities are already building infoboxes in this fashion. Also, pursing a standardized markup like tabber or gallery allows us the option to run a script to convert to a new, (hopefully more flexible) solution in the future.

      Ideally in the future, users who prefer a GUI over source (be it the VisualEditor or another tool) would never have to see an actual file name. They could select a photo from a visual browse/upload tool. But these flashy features come after we have our markup nailed down.

        Loading editor
    • I've been trying some of this CSS, and for some reason the background around transparent images is not the same color as the infobox background, it's taken straight from the theme designer. Is there anyway to fix this?

        Loading editor
    • You can try to inherit the background color from the surrounding infobox by using:

      .pi-image-collection-tab-content {
          background-color:    inherit;
      }
      

      If that doesn't work, you can replace "inherit" with a color.

        Loading editor
    • Thank you very much Moviesign. Works great.

        Loading editor
    • Any chance we can have the gallery feature display the mobile version identically (with swipes across etc), but simply display a group of images (not tabbed) on desktop? See: Jak.

        Loading editor
    • I tried implementing the portable infobox on the Metal Gear Wiki, but the infobox images do not show in either the mobile preview on desktop or an actual mobile phone, after trying both types of coding. Any chance you could take a look?

      Thanks.

        Loading editor
    • Bluerock wrote:
      I tried implementing the portable infobox on the Metal Gear Wiki, but the infobox images do not show in either the mobile preview on desktop or an actual mobile phone, after trying both types of coding. Any chance you could take a look?

      Thanks.

      Maybe that's a caching problem. It works properly for me.

      Edit to add :

      Try appending "?useskin=wikiamobile" to the url. I think that since they introduced curated pages , the mobile preview stopped working properly. Some mobile devices may also not support the CSS or javascript used to create the slideshow.

        Loading editor
    • Bluerock wrote:
      I tried implementing the portable infobox on the Metal Gear Wiki, but the infobox images do not show in either the mobile preview on desktop or an actual mobile phone, after trying both types of coding.

      I added a test infobox to my sandbox a few days ago to restyle the tabber into what we currently have (again), but decided to stop once I noticed the images weren't (and still aren't) appearing in the mobile preview. I can't confirm they aren't appearing on mobile devices, but I wouldn't be surprised.

        Loading editor
    • Dessamator wrote: Maybe that's a caching problem. It works properly for me.

      Edit to add :

      Try appending "?useskin=wikiamobile" to the url. I think that since they introduced curated pages , the mobile preview stopped working properly. Some mobile devices may also not support the CSS or javascript used to create the slideshow.

      I can view the images by doing the above for the mobile preview on desktop. However, images on mobile devices are still a no show.

        Loading editor
    • Bluerock wrote:

      Dessamator wrote: Try appending "?useskin=wikiamobile" to the url.

      I can view the images by doing the above for the mobile preview on desktop. However, images on mobile devices are still a no show.

      Interesting that works for you because that doesn't work for me either.

        Loading editor
    • FYI the mobile preview while editing on the desktop skin is totally wrong and does not reflect the accurate mobile presentation at all.

      Please direct all complaints to Special:Contact/feedback. It really should be Special:Contact/bug (you can use that too), but we'll pretend it is an oversight.

        Loading editor
    • Fandyllic wrote:
      FYI the mobile preview while editing on the desktop skin is totally wrong and does not reflect the accurate mobile presentation at all.

      Please direct all complaints to Special:Contact/feedback. It really should be Special:Contact/bug (you can use that too), but we'll pretend it is an oversight.

      It is not meant to be an exact 1:1 preview . That is actually impossible because there are possibly more than a dozen different form factors for mobile. For example, how exactly would it preview the way it shows on a Google Glass mobile device, or a dual-screen device ?

      It would also have to account for custom widgets and apps that users install that may alter the screen.

      Ultimately, since this is a portable tool, it should work on most relatively recent mobile devices. If it doesn't then it is either a bug, something that will still be developed, or simply a device that isn't supported.

      P.S. At least using the chrome developer tools you can actually simulate the screen size of a mobile device, so it does help somewhat.

        Loading editor
    • Does anyone know of some CSS coding where I can place a border around the content when using the <gallery> tabs? I'd like to make a Portable infobox to look at least just like the tabber image holders (where you can see the sample of the border of the tabbers--I'm not taking about the border of those tabber sections by the way--in a sample here) in this infobox I will be converting into a Portable version soon.

        Loading editor
    • To put a border around the image, you can do this:

      .pi-image-collection .pi-image-thumbnail {
         width:  85%;
         height: 85%;
         border: 3px solid purple;
      

      If you want to get really fancy, scroll up a ways you will see some CSS that I posted to make the Portable Infobox tabber/gallery look like the regular <tabber>. You can modify that to match your color scheme. Note that it currently only works if the tabs don't extend beyond the edge of the infobox, but it can handle two tabs just fine. Post a message on my wall if you have questions.

        Loading editor
    • Another issue I've noticed is that images used to represent articles in categories no longer select the first (and usually most recognizable/relevant) image from the article, if that image is in the portable gallery infobox. The image that is selected instead is usually one that is not as recognizable or desirable.

        Loading editor
    • Bluerock wrote:

      Another issue I've noticed is that images used to represent articles in categories no longer select the first (and usually most recognizable/relevant) image from the article

      Yes, looks like the feature reading images for the preview for articles in categories (and 'see also') can't read the image in the <image> tag, and instead finds an image from any <data> tag instead.

      For example: an infobox featuring a photo of a person (image), then a flag for nationality (data); the flag will be the featured image for that article.

        Loading editor
    • Liggliluff wrote:

      Bluerock wrote:

      Another issue I've noticed is that images used to represent articles in categories no longer select the first (and usually most recognizable/relevant) image from the article

      Yes, looks like the feature reading images for the preview for articles in categories (and 'see also') can't read the image in the <image> tag, and instead finds an image from any <data> tag instead.

      For example: an infobox featuring a photo of a person (image), then a flag for nationality (data); the flag will be the featured image for that article.

      Good catch :) This is definitely not intended. We'll get it fixed.

        Loading editor
    • using:

      <group collapse="closed">
          <header>GRID</header>
          <group layout="horizontal">
              <data source="textA1"></data>
              <data source="textA2"></data>
              <data source="textA3"></data>
          </group>
          <group layout="horizontal">
              <data source="textB1"></data>
              <data source="textB2"></data>
              <data source="textB3"></data>
          </group>
      </group>
      

      This is a way to make a nice grid that can be collapsible; but this won't work as you can't put a group inside a group. This is a wanted feature, or if there's a solution?

        Loading editor
    • I definitely agree there. It's impossible to use a collapsible and horizontal groups together, that should be fixed.

        Loading editor
    • As the founder of a wiki where we were using tabbers on infoboxes before this came out (example on my wiki/example on the Sword Art Online Wiki, where I found the coding), I'm all for this.

      LordTBT wrote: Is there any way the mobile version could work on the desktop as well? I think the mobile gallery is a much cleaner look than having a million tab buttons...

      Definitely behind that, as well.

        Loading editor
    • Maybe make it an option. I'd like the tabs, displaying multiple images, and slide across galleries to all be possible with the gallery tag in infoboxes. They would all display with the same slide like on mobile, but differently on desktop.

        Loading editor
    • Another issue: I cannot seem to view the different gallery infobox images when checking the desktop preview, whereas the previous tabs allowed you click on them to see how it would look, while editing.

        Loading editor
    • I think that's just a general JS issue. On several wikis, tabs don't work in preview, though on others they do.

        Loading editor
    • Best of luck @RapidsLurker15! If you have questions on how infoboxes work, these Community Central forums are your best resource.

      Tabs in infoboxes aren't working on Monobook or Oasis editor preview yet. We've got them logged and will try to fix them soon. We're also thinking about providing a slider experience on desktop — glad you all like it!

      As for groups within groups. I totally understand the use of this — perhaps you should start a new thread to discuss it so it doesn't get lost in this discussion?

        Loading editor
    • Ohmyn0 wrote: As for groups within groups. I totally understand the use of this — perhaps you should start a new thread to discuss it so it doesn't get lost in this discussion?

      Someone, get on with this. This is something we need to easier designing infoboxes. Collapsible grids is one major thing.

        Loading editor
    • Dessamator wrote: ... The image tag can't currently be nested inside the data attribute. So that would require some changes. It is also confusing because one would need to know if the data is parsed as an image or text. What about people who mistakingly mix text, audio, and images?

      How exactly would it parse that data?

      ...

      I would prefer if the data tag used a "type", that defaulted to text, for this purpose. In this scenario, you would use the label tags for captions. This would make the infoboxes much more flexible, and allow for the tabber/gallery feature to be an aspect of the "group" tag. As an example of how this might work, see:

      <group collapse="closed">
          <header>GRID</header>
          <group layout="horizontal">
              <data type="text" source="textA1"></data>
              <data type="text" source="textA2"></data>
              <data type="text" source="textA3"></data>
          </group>
          <group layout="gallery">
              <data type="image" source="File:textB1.jpg|alt=textB1"></data>
              <label>TextB1 described</label>
              <data type="image" source="textB2.jpg|alt=textB2"></data>
              <label>TextB2 described</label>
              <data type="image" source="textB3.jpg|alt=textB3"></data>
              <label>TextB3 described</label>
          </group>
      </group>
      

      Edit: And yes, I'm a HUGE fan of the idea of nested groups.

        Loading editor
    • Liggliluff wrote:

      Ohmyn0 wrote: As for groups within groups. I totally understand the use of this — perhaps you should start a new thread to discuss it so it doesn't get lost in this discussion?

      Someone, get on with this. This is something we need to easier designing infoboxes. Collapsible grids is one major thing.

      Will this do? :D

        Loading editor
    • Technobliterator wrote: I think that's just a general JS issue. On several wikis, tabs don't work in preview, though on others they do.

      Is there nothing that be done about this then? (forgive me, JS isn't my strong suit.) It seems quite inconvenient not to be able to see if the gallery will look any good, without having to save your changes every time.

        Loading editor
    • Bluerock wrote: Is there nothing that be done about this then? (forgive me, JS isn't my strong suit.) It seems quite inconvenient not to be able to see if the gallery will look any good, without having to save your changes every time.

      Without writing your own JS code to replace the default tabbers, unfortunately not. It sounds like Wikia are aware of the problem and could be working on a solution, though.

        Loading editor
    • Technobliterator wrote:

      Bluerock wrote: Is there nothing that be done about this then? (forgive me, JS isn't my strong suit.) It seems quite inconvenient not to be able to see if the gallery will look any good, without having to save your changes every time.

      Without writing your own JS code to replace the default tabbers, unfortunately not. It sounds like Wikia are aware of the problem and could be working on a solution, though.

      Yes, we have a bug ticket filed and we'll get to it. Thank you for being patient.

        Loading editor
    • Dessamator wrote:
      LordTBT wrote:

      Well, I wouldn't describe "users" as "the problem" myself.

      Redwall is a book-related wiki. We have images of every translation, in some cases this is above 20. This, imo, would be a great usage of this new function.

      However, I think that amount of tabs is aesthetically and functionally unpleasant.

      Thus, if there were an option to make the mobile "slideshow" possible to be displayed on mobile AND desktop, that would be fantastic. Hoping Wikia can weigh in here, given the support above.

      I briefly looked through Redwall wiki and didn't find a single infobox with a gallery. Even among the most used infoboxes according to Special:Insights, so I find it hard to believe that this has suddenly become an important use-case.

      Dark Series Wiki has many book pages with infoboxes showing the current cover and galleries in the article showing the previous covers and translation covers. Example: Dark Prince. It's pretty interesting to see how romance novel covers have changed over the years and in different cultures.

      I made a mockup of the gallery inside the infobox and it looks terrible on the desktop. The images don't even show up on mobile. Example: Dark Prince mockup.

        Loading editor
    • Bismarckfairy wrote:

      Dark Series Wiki has many book pages with infoboxes showing the current cover and galleries in the article showing the previous covers and translation covers. Example: Dark Prince. It's pretty interesting to see how romance novel covers have changed over the years and in different cultures.

      I made a mockup of the gallery inside the infobox and it looks terrible on the desktop. The images don't even show up on mobile. Example: Dark Prince mockup.

      You've only proved my point. Infoboxes are not "meant" to hold too many images. Even if the slider is implemented on the desktop, it will still have the same problem. If a user wants to see only image 13 the user will  have to click through 12 images to get to it.  

      For mobile devices it is worse, unlike a desktop, a mobile device has limited bandwidth, limited connectivity, and in some cases bad reception. These will affect how long the page takes to load, and in some cases the page may not load at all. 

        Loading editor
    • Vandraedha wrote:

      I would prefer if the data tag used a "type", that defaulted to text, for this purpose. In this scenario, you would use the label tags for captions. This would make the infoboxes much more flexible, and allow for the tabber/gallery feature to be an aspect of the "group" tag. 

      That looks redundant, currently a gallery can only contain images or video. So if the group has a gallery layout, its child tags don't need a type.

        Loading editor
    • Bismarckfairy wrote:

      Dessamator wrote:
      LordTBT wrote:

      Well, I wouldn't describe "users" as "the problem" myself.

      Redwall is a book-related wiki. We have images of every translation, in some cases this is above 20. This, imo, would be a great usage of this new function.

      However, I think that amount of tabs is aesthetically and functionally unpleasant.

      Thus, if there were an option to make the mobile "slideshow" possible to be displayed on mobile AND desktop, that would be fantastic. Hoping Wikia can weigh in here, given the support above.

      I briefly looked through Redwall wiki and didn't find a single infobox with a gallery. Even among the most used infoboxes according to Special:Insights, so I find it hard to believe that this has suddenly become an important use-case.

      Dark Series Wiki has many book pages with infoboxes showing the current cover and galleries in the article showing the previous covers and translation covers. Example: Dark Prince. It's pretty interesting to see how romance novel covers have changed over the years and in different cultures.

      I made a mockup of the gallery inside the infobox and it looks terrible on the desktop. The images don't even show up on mobile. Example: Dark Prince mockup.

      And this is exactly what I'm talking about, and why I want the mobile-style available for desktop.

        Loading editor
    • The issue about what infoboxes are meant to hold is subjective. The example has 10 images and you could argue that's too many for an infobox, but some communities obviously want to use infoboxes in this way. If it's possible on mobile, it should be possible on desktop. Each community can decide for itself how to use infoboxes.

      The issue about clicking through a lot of images or the use of bandwidth applies to galleries whether they are inside an infobox or somewhere else on the page. Thus it doesn't really apply to a discussion about desktop tabs and portable galleries in infoboxes.

      I sense we're not going to agree on this, but I want the developers to know that there's demand for galleries in infoboxes.

        Loading editor
    • Ohmyn0 wrote:

      Liggliluff wrote:

      Bluerock wrote:

      Another issue I've noticed is that images used to represent articles in categories no longer select the first (and usually most recognizable/relevant) image from the article

      Yes, looks like the feature reading images for the preview for articles in categories (and 'see also') can't read the image in the <image> tag, and instead finds an image from any <data> tag instead.

      For example: an infobox featuring a photo of a person (image), then a flag for nationality (data); the flag will be the featured image for that article.

      Good catch :) This is definitely not intended. We'll get it fixed.

      Just thought I'd add, this seems to be an issue with the portable infobox's images in general, not just when using the gallery.

        Loading editor
    • Bismarckfairy wrote: The issue about what infoboxes are meant to hold is subjective. The example has 10 images and you could argue that's too many for an infobox, but some communities obviously want to use infoboxes in this way. If it's possible on mobile, it should be possible on desktop. Each community can decide for itself how to use infoboxes.

      Although I personally would not advise using galleries in infoboxes the way the mock ups have been shown with 10+ images (as someone who works on game wikis, we use alternate cover art just in galleries below on the page because we don't see it as practical), I do have to agree that it should be left up to the community to decide what works for them. I would like portable infobox galleries to have sliders and multiple image display options on desktop, but for all three desktop styles to display only as the sliders on mobile.

        Loading editor
    • Dessamator wrote:

      Vandraedha wrote:

      I would prefer if the data tag used a "type", that defaulted to text, for this purpose. In this scenario, you would use the label tags for captions. This would make the infoboxes much more flexible, and allow for the tabber/gallery feature to be an aspect of the "group" tag. 

      That looks redundant, currently a gallery can only contain images or video. So if the group has a gallery layout, its child tags don't need a type.

      I don't disagree that my example has redundancies. It was meant to show you an example of what I was trying to explain about using data types. However, if you wanted to incorporate a secondary image, say a character image as the primary and further down the infobox an image of a map to the character's location as the secondary image, you could do this with my example. It would also make it easier to pull the tabber info from the groups, rather than having to learn tabber syntax.

      e.g. -

      <infobox>
      
      <group layout="tabbed">
          <header>Tabbed Infobox</header>
          <group>
              <data type="image" source="File:VideoClipA1.jpg|alt=textB1"><label>VideoClipA1 described</label></data>
              <data type="text" source="uniquetextA1"></data>
              <data type="text" source="uniquetextA2"></data>
              <data type="text" source="uniquetextA3"></data>
          </group>
          <group>
              <data type="image" source="File:ImageB2.jpg|alt=textB2"><label>ImageB2 described</label></data>
              <data type="text" source="uniquetextB1"></data>
              <data type="text" source="uniquetextB2"></data>
              <data type="text" source="uniquetextB3"></data>
          </group>
          <group>
              <data type="image" source="File:ImageC3.jpg|alt=textB3"><label>ImageC3 described</label></data>
              <data type="text" source="uniquetextC1"></data>
              <data type="text" source="uniquetextC2"></data>
              <data type="text" source="uniquetextC3"></data>
          </group>
      </group>
      
      <group layout="horizontal">
         <data type="text" source="shared1"></data>
         <data type="text" source="shared2"></data>
         <data type="text" source="shared3"></data>
      </group>
      ...etc...
      </infobox>
      

      I could easily see: group type="gallery" overriding default of text for a particular group. I was just under the impression that we were trying to encourage the use of text data in infoboxes, hence the default being text. If you want to have a variable default, that's fine. If you don't want a default, then you could have the type be explicit (as I used in my earlier example).

        Loading editor
    • Portable info boxes need to support features that admins want to use, otherwise they are an inconvenience with very little payoff. Arguing that PIs should have this or that in them is almost purely personal opinion. I'm sure there are desired features for PIs that are beyond the boundaries of realistic implementation, but PIs should support most of the features that you can put in wikitext infoboxes until a good argument can be made not to (like too difficult to implement, not used by more than a couple small wikis, security risk, etc.).

        Loading editor
    • This thread is super long so I'm not sure if it's been brought up or not, but could images be made to point to the file's page instead of directly to the file? (Why even make it point directly to the image file?)

        Loading editor
    • Umbreon126 wrote: This thread is super long so I'm not sure if it's been brought up or not, but could images be made to point to the file's page instead of directly to the file? (Why even make it point directly to the image file?)

      This should work already. See Help:Galleries,_Slideshows,_and_Sliders/wikitext#Example_with_variations.

        Loading editor
    • OWL

      I used this method, but somehow my images aren't the same width, so it looks really ugly. Click.

        Loading editor
    • Your second image is simply smaller than the infobox's width. Infoboxes don't scale images up.

        Loading editor
    • OWL

      Is there a way to change the size of the second image?

        Loading editor
    • OWL wrote:
      Is there a way to change the size of the second image?

      You could either resize your images or adjust them using css, e.g.:

      .portable-infobox .pi-image img {
        width: auto;
        height: 230px;
      }
        Loading editor
    • OWL
      Dessamator wrote:
      OWL wrote:
      Is there a way to change the size of the second image?
      You could either resize your images or adjust them using css, e.g.:
      .portable-infobox .pi-image img {
        width: auto;
        height: 230px;
      }

      That's perfect, thanks!

        Loading editor
    • How are the images on this page displaying on your mobile device? Can you view it properly? The mobile viewer isn't displaying the images at all, I just want to make sure. I'm using gallery tag btw.

      Also, can someone tell me what's the difference between gallery tag and tabber tag?

        Loading editor
    • I'm trying to insert an image to my Infobox but it doesn't show up, what am I doing wrong?

        Loading editor
    • You're using the [[File:filename]] syntax, not just the filename, right?

        Loading editor
    • SHIN01 wrote:
      How are the images on this page displaying on your mobile device? Can you view it properly? The mobile viewer isn't displaying the images at all, I just want to make sure. I'm using gallery tag btw.

      Also, can someone tell me what's the difference between gallery tag and tabber tag?

      I believe the two display the same thing: a slideshow-y thing on mobile, and tabs on desktop.

      This is probably due to the different interaction patterns on different devices, as desktop users are more likely to click smaller targets whereas mobile users would find it easier to scroll. So they just took both display options, made them depend on device type, and gave two tags that could stand for the functions the same overall purpose.

        Loading editor
    • No, I'm just using the file name.

        Loading editor
    • You have to put the filename in double square brackets and have File: before it to display a picture.

        Loading editor
    • Okay.

        Loading editor
    • Same thing, it doesn't show up I did to insert the image and it still doesn't show up. (I didn't put the words filename.)

        Loading editor
    • Anyone there?

        Loading editor
    • Someone please answer me

        Loading editor
    • I'll take a look and see if I can spot something.

        Loading editor
    • @TheSonic103ify

      You just need to upload some images to your wikia. I added one of your three existing images to the page you were working on and it does indeed work. You do not need the File: or the brackets, just the exact file name of an image in your File List. Good luck with your new wikia!

        Loading editor
    • @Moviesign

      Thank you so much!

        Loading editor
    • When using <gallery> tags, you don't need to use File:, but it's good practice.

        Loading editor
    • Unlike traditional image links, gallery tags will not display anything if the image does not exist.

        Loading editor
    • Vandraedha wrote: Unlike traditional image links, gallery tags will not display anything if the image does not exist.

      Yes, but a local image/video filename doesn't need the File: prefix to work in gallery tags.

        Loading editor
    • Oh, it was a gallery?


      oops

        Loading editor
    • Fandyllic wrote:

      Vandraedha wrote: Unlike traditional image links, gallery tags will not display anything if the image does not exist.

      Yes, but a local image/video filename doesn't need the File: prefix to work in gallery tags.

      It's true that you don't need the File: prefix for images in a gallery. However, if the image doesn't exist (isn't uploaded) on the wiki it will not show that image in the gallery (unlike other images, which show as redlinks). If no images exist by the names listed in the gallery, the gallery may not show at all (until at least one image is uploaded to the wiki). Galleries do not prompt a user to upload an image by default.

        Loading editor
    • Question: Could one make it so that not only the image changes but also some of the facts written?

      Example: I have a character that can be either female or male in the game, but has the same purposes storywise. So the name, the image and some other facts might differ from female to male.

      This is my character --> http://kendallandkyliegame.wikia.com/wiki/Rival

      So could I make it so that when I switch image Male>Female that some of the facts switch too?

        Loading editor
    • Shairnah wrote:
      Question: Could one make it so that not only the image changes but also some of the facts written?

      So could I make it so that when I switch image Male>Female that some of the facts switch too?

      Currently, the portable infobox doesn't support that and will probably never support it due to its complexity. The only way to get that working would be using javascript which will not show up on mobile devices anyway.

        Loading editor
    • I still don't understand where I should add the gallery tab thingies... I only get confused and have no idea where to add them... can someone help? Sorry if I'm dumb... I really messed up, it wont show images anymore....

        Loading editor
    • MillieWillieBo wrote:
      I still don't understand where I should add the gallery tab thingies... I only get confused and have no idea where to add them... can someone help? Sorry if I'm dumb...

      You can add it directly into the infobox, as you fill it out, in the "image" section.

      Or in the code like this:
      
      {{Infobox
      |title    =
      |image    = <gallery>
                  Image1.png|Title1
                  Image2.png|Title2
                  </gallery>
      |whatever =
      }} 
        Loading editor
    • Very nice concept for 140px+ multi image display. But, I had 4 small(soon to be 8) gif. It is easier to use an HTML table in a 'data' tag, so all the gif are displayed together. The Infobox will maintain the image tag(blanked on small gif pages) for alternative methods as discussed here. -thanks for the info

        Loading editor
    • Jade Emperor wrote:
      Very nice concept for 140px+ multi image display. But, I had 4 small(soon to be 8) gif. It is easier to use an HTML table in a 'data' tag, so all the gif are displayed together. The Infobox will maintain the image tag(blanked on small gif pages) for alternative methods as discussed here.

      -thanks for the info

      That's an interesting use case. It makes sense to have different ways of displaying the images. In this particular case, it could be something like the default mediawiki gallery squeezing some images side by side, instead of tabbed. Although, one would still need some way of limiting the number of images so they can actually display in a reasonable way.

      Eight images in such a tight spot seem to be somewhat excessive, unless they are really small.

        Loading editor
    • They are width:50px~60px gifs(height a little less). Two rows(4/row) looks nice on mobile, though the wiki is desktop/tablet centric.

        Loading editor
    • FortressMaximus
      FortressMaximus removed this reply because:
      solved
      20:08, September 12, 2016
      This reply has been removed
    • FortressMaximus
      FortressMaximus removed this reply because:
      solved
      20:08, September 12, 2016
      This reply has been removed
    • Jade Emperor wrote: Very nice concept for 140px+ multi image display. But, I had 4 small(soon to be 8) gif. It is easier to use an HTML table in a 'data' tag, so all the gif are displayed together. The Infobox will maintain the image tag(blanked on small gif pages) for alternative methods as discussed here. -thanks for the info

      Is it possible for you to composite the GIFs into one image and use them in that manner? If the GIFs are directly relevant to each other, this could help a lot.

        Loading editor
    • Speedit wrote: Is it possible for you to composite the GIFs into one image and use them in that manner? If the GIFs are directly relevant to each other, this could help a lot.

      Yes, but since the images may be utilized elsewhere and may have differing timing; I prefer to keep them separate to reduce their file size. Gifs with motion over a large area can get unwieldy. The page in question is here. Wasn't a problem just a remark for alternate ways of doing things.

        Loading editor
    • Hello. May I know how to maka the 'tab' in center? Mine somehow stuck on the left. Thank you.

        Loading editor
    • @Tantrumbunny Please post a link to an example page so we can see what it is you desire.

        Loading editor
    • @Moviesign http://treeofsavior-thelore.wikia.com/wiki/Wizard

      The female & male 'tab'. I follow the tips to make tabbed image with < gallery > and it works, but while the example above in the center of infobox, mine in the left?

        Loading editor
    • Tantrumbunny wrote: Hello. May I know how to maka the 'tab' in center? Mine somehow stuck on the left. Thank you.

      It's because you have europa-theme enabled in your wikia features.

      To center them, you can:

      • Turn off the feature on the page I linked

      or...

      • Add css below to your MediaWiki:Wikia.css or MediaWiki:Common.css
      .pi-europa .pi-image-collection-tabs {
          text-align: center;
      }
        Loading editor
    • Andrey Andrey wrote:

      Tantrumbunny wrote: Hello. May I know how to maka the 'tab' in center? Mine somehow stuck on the left. Thank you.

      It's because you have europa-theme enabled in your wikia features.

      To center them, you can:

      • Turn off the feature on the page I linked

      or...

      • Add css below to your MediaWiki:Wikia.css or MediaWiki:Common.css
      .pi-europa .pi-image-collection-tabs {
          text-align: center;
      }

      Thank you very much! I'm adding the css code and it now look better. Thank you!

        Loading editor
    • I can't get it to wor please help!!!!

        Loading editor
    • Could you be more specific and describe the problem and post a link to the page please?

        Loading editor
    • I have been trying to post image's with tab's like te image above, but I just can't figure out how to do it

      here's the link http://crow-land.wikia.com/wiki/Undertaker

        Loading editor
    • I have made two edits to your page. See the edit comments and hopefully that example will help you see what you need to do. You can post a message on my wall if you have more questions.

        Loading editor
    • Its not compitible with me!

        Loading editor
    • How do you add Captions below the Tabbers and the Images, cause it's bugged out.

        Loading editor
    • Well, this is a blast from the past. It's been 2 years, can desktop users get this yet?

        Loading editor
    • @LordTBT Don't try to start a roast argument dude, coding and scripting isn't always easy.

        Loading editor
    • @LordTBT Infact it takes time to process and it's complicated.

        Loading editor
    • It's not two years complicated.

        Loading editor
    • Hey all - if you have any further questions or having any issues with portability, please create a new post or head on over to the Portability Wiki.

      Closing, since this thread's old!

        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message