FANDOM


  • Hey all, 

    The last thread was grinding even the spiciest computers to a halt, so here's a fresh slate to keep the conversation going!

      Loading editor
    • Can you link to an example of a very complex infobox that was converted to a Portable Infobox? I haven't given PIs a second look since they came out because I prefer the higher degree of control and functionality I can get with wikitext. I'm doubtful that a template such as this one could ever be converted due to the code involved and the fact that it is made up of two tables.

      I also am hesitant to use the XML-like syntax. As a programmer, I have always been discouraged from using XML, and even JSON is not as nice as some other options that are out there.

      Many users have asked for it to be possible to specify different content for mobile and desktop. I think that would be more useful than having to compromise between both at once.

        Loading editor
    • Bobogoobo wrote:
      Can you link to an example of a very complex infobox that was converted to a Portable Infobox?

      http://marvel.wikia.com/wiki/Template:Film_Template

        Loading editor
    • Bobogoobo wrote:
      I'm doubtful that a template such as this one could ever be converted due to the code involved and the fact that it is made up of two tables.

      The only problem I see holding that one up is tabbers, but a Lua function should be able to handle infobox character/util.

      I also am hesitant to use the XML-like syntax. As a programmer, I have always been discouraged from using XML, and even JSON is not as nice as some other options that are out there.

      I can not fathom that second statement, even as I myself am a programmer; it's a subjective aesthetic.

      Many users have asked for it to be possible to specify different content for mobile and desktop. I think that would be more useful than having to compromise between both at once.

      It's under consideration, but I think you'll find portability isn't really a sacrifice for either if you give it a decent try.

        Loading editor
    • FishTank wrote:

      Bobogoobo wrote:
      Can you link to an example of a very complex infobox that was converted to a Portable Infobox?

      http://marvel.wikia.com/wiki/Template:Film_Template

      Do you mean http://marvel.wikia.com/wiki/Marvel_Database:Film_Template?

      Shyguy-emoticon.gifJoey (talk)

        Loading editor
    • Yes, that's the one.

        Loading editor
    • Bobogoobo wrote: Many users have asked for it to be possible to specify different content for mobile and desktop.

      That can be achieved using classes and css if desired, but it's a bit of a pain to code. It's how I overcame blockquote problems here.

        Loading editor
    • Bobogoobo wrote:
      Many users have asked for it to be possible to specify different content for mobile and desktop. I think that would be more useful than having to compromise between both at once.

      The following Extention would let us do this  Extension:MobileDetect but wikia don't seem interested in enabling it.

      • The first thing I do when on a mobile device is click to view wikia in full view.
      • Something is very wrong when the desktop view is compromised for the mobile view.
      • The path to mobility is paved with inflexibility :-(
        Loading editor
    • Robcamstone wrote:
      Bobogoobo wrote:
      Many users have asked for it to be possible to specify different content for mobile and desktop. I think that would be more useful than having to compromise between both at once.
      The following Extention would let us do this  Extension:MobileDetect but wikia don't seem interested in enabling it.
      • The first thing I do when on a mobile device is click to view wikia in full view.
      • Something is very wrong when the desktop view is compromised for the mobile view.
      • The path to mobility is paved with inflexibility :-(

      That's because it is a bad solution to a major problem. It is like giving someone ingredients and telling them to cook without knowing if they know how to cook or mix it properly. Some "ingredients" can actually be deadly if not prepared properly[1] .

      @Bobogoobo :

      Any developer should be happy about a tool that reduces the coding. After all, the ideal algorithm is the most efficient one that requires the least effort.  If you look at the infobox linked by Josephr, you'll note that the conversion removed about 1/3 of the coding required, while still maintaining the same functionality. It can even be further improved.

      Your template is very simple despite its appearances, and the migration tool will probably convert about 80% of the code properly. 

        Loading editor
    • The example given in Help:PortableInfoboxes/CSS for using theme-source implies that the value of location will be lower-cased and used in a CSS selector (i.e., Africa → africa). This is not true. The value of the theme-source variable is case-sensitive.

      I would prefer the lower-case policy that is implied by the documentation.

        Loading editor
    • Moviesign wrote:
      The example given in Help:PortableInfoboxes/CSS for using theme-source implies that the value of location will be lower-cased and used in a CSS selector (i.e., Africa → africa). This is not true. The value of the theme-source variable is case-sensitive.

      I would prefer the lower-case policy that is implied by the documentation.

      I've changed the documentation to lower case.

      Anyway, as someone reminded me when I made a similar comment, XML is a case-sensitive markup language. Values stored in infoboxes may in fact be accessed by other software or even wikia's internal software that expects this case "insensitivity" so it seems prudent to ensure that it adheres to standards and avoids headaches later.

        Loading editor
    • While creating a simple "Best Practices" page for infoboxes here based on my experience, it became apparent that there doesn't seem to be any documentation that indicates the minimum and maximum infobox width. It seems that the maximum width is variable, but what is its minimum width?

      This is somewhat important when selecting a good image  to make sure it won't get stretched like bubble gum.

      Also, with the whole drive to separate data from presentation. Are there any plans to support content models (e.g. XML, Json) for these infoboxes or other widgets?

      This is desirable because one can easily force that all pages with portable infoboxes have valid syntax, much like one can force all pages in the module namespace to have valid code. Alternatively, it might be good to have a tracking category for broken portable infoboxes.

        Loading editor
    • Does anyone know if we are getting a <group layout="tabber"> ?

      I've implemented such a thing based on work by User:Ohmystars but have run into a technical snag. Is it worth my time to try to track this down, or should I wait for the expected support for tabbers?

      For those who are interested: I have a table inside a tabber (inside a portable infobox) that is putting HTML comments where a simple link should be. The comments are of the form <!--LINK 0:4--> with the last digit incrementing each time it occurs in the table.

      You can see it here, although it's my working draft and will probably change in the future. There is no problem when the table is used as a parameter of the infobox (which you can see on that example page, two lines up), only when it is inside the tabber. I'm trying to replicate the functionality of this page.

      Any insight into this problem, or whether it's worth investigating would be welcome.

        Loading editor
    • Can you describe the problem more specifically with the tables inside tabber? I don't see it on the link you gave ("Alassra Silverhand" example infobox). Seems to work okay.

        Loading editor
    • @Fandyllic If you click on the "2e" tab, you will see 30 but not the link to [[Wizard]]. It should look just like the line just above it with the label "Class". Similar results are seen if you click the "35" tab. EDIT: I have removed the extra tabs that are unnecessary, sorry about that.

        Loading editor
    • Hmmm, well you seem to be using many templates nested in other templates, so I'd have to do more digging to figure out the problem. Looking at the PI version, I suspect the problem may not be PI related, but like I said, I'd have to investigate more.

        Loading editor
    • Thus my original question :-) If they are going to make tabbers work inside PIs then this problem will eventually go away. The template that produces the table works fine as a parameter of a PI, but not when you put that same template inside a tabber inside a PI. I was hoping some developer would recognize the <!--LINK 0:4--> that is seen in the source of the page where the link is supposed to be, and have an A-HA! moment. ;-)

        Loading editor
    • If only the PI devs looked at these threads, alas no. You should probably use Special:Contact/bug to have the best chance of getting a dev to look at the problem.

      As for tabber support in PIs, I wouldn't hold your breath. The dev team sounds stretched kind of thin at Wikia and with all this security stuff going on, anything related to it is probably top priority.

        Loading editor
    • Fandyllic wrote:
      If only the PI devs looked at these threads, alas no. You should probably use Special:Contact/bug to have the best chance of getting a dev to look at the problem.

      As for tabber support in PIs, I wouldn't hold your breath. The dev team sounds stretched kind of thin at Wikia and with all this security stuff going on, anything related to it is probably top priority.

      You know that the devs look at these threads. Why be a downer?

        Loading editor
    • No, I don't know the devs look at these threads. And if they look at them, they rarely respond which is makes it hard to know if they are looking. I'm just going by a very long history of experience on CC.

      I'm not a downer. I'm honest.

        Loading editor
    • The reason why Special:Contact is the preferred method to contact Staff is because that generates a "paper" trail of a problem and everything which is done about it.

        Loading editor
    • Ok, I submitted a bug report, just in case it presents a use case they hadn't considered yet.

        Loading editor
    • Unless I'm missing something, the portable infoboxes appear to be discarding image alt text in wikiamobile skin. This page, for example. This will probably cause accessibility issues for readers using assistive techs on mobile.

      EDIT: Never mind, this happens to other images in wikiamobile too, so it's probably a wikiamobile problem and not a portable infobox problem.

        Loading editor
    • Good bug. I'd report it to Special:Contact/bug.

      I've started this page to track portable infobox bugs: w:c:infobox:Portable_Infoboxes/Bugs.

        Loading editor
    • Rigel Kent wrote: Unless I'm missing something, the portable infoboxes appear to be discarding image alt text in wikiamobile skin. This page, for example. This will probably cause accessibility issues for readers using assistive techs on mobile.

      EDIT: Never mind, this happens to other images in wikiamobile too, so it's probably a wikiamobile problem and not a portable infobox problem.

      One of the reasons for the existence of Portable Infoboxes is to not lose data when going to mobile, so even if the skin is throwing stuff away, it should still be tracked as a PI bug until it can be proven.

      Have you submitted it to Special:Contact/bug yet?

        Loading editor
    • Feature request: column limit on horizontal-layout-groups, to simulate flex-grids. I have a selection of fields that vary in quantity between 2 and... god knows, depending on the subject, and grouping them by 3s when that potentially means three rows with only one cell... :/

        Loading editor
    • Emptylord wrote:
      Feature request: column limit on horizontal-layout-groups, to simulate flex-grids. I have a selection of fields that vary in quantity between 2 and... god knows, depending on the subject, and grouping them by 3s when that potentially means three rows with only one cell... :/

      As Infobox Wikia is being transitioned into the Wikia sanctioned Portability Wikia, a good place to put feature requests is the Developments and Suggestions Board.

        Loading editor
    • Fandyllic wrote: Have you submitted it to Special:Contact/bug yet?

      Yep, I let them know. I suspect lazy-load JavaScript in wikiamobile skin swaps the placeholder <img> out for the real <img>, but doesn't copy over alt or any other attributes from the placeholder. And I confirmed with a screen reader (TIL screen readers on mobile are a thing) that the alt text is not spoken in wikiamobile.

        Loading editor
    • (Response to a troll.)
        Loading editor
    • (Response to a troll.)
        Loading editor
    • Suggestion

      I think it would be particularly good if infoboxes of the same "class" were linked. For example, if I have an infobox, e.g. Infobox_episode or infobox_books, it would be nice if there was a particular group that simply collected all this information and presented it as a navigation, as shown below:

      {{infobox books|name=Stargate|published=1999|author=MacGuyver}}
      {{infobox books|name=MacGuyver|published=1995|author=Mr fixit}}

      A sample infobox could be generated using:

      <infobox>
      <data source="name"/>
      <data source="author"/>
      <data source="publisher"/>
      <group type="classlinks" header="Available books"/>
      </infobox>

      There could be options to customize classlinks. This can currently be done by using javascript or lua or regular templates. But it requires dpl or hardcoding of all data.

      Link to discussion

        Loading editor
    •   Loading editor
    • Does anyone know how to change the layout color of the portable infoboxes individually, or they must all have the same color? As I cannot find a solution for this.

        Loading editor
    • Luma.dash wrote:
      Does anyone know how to change the layout color of the portable infoboxes individually, or they must all have the same color? As I cannot find a solution for this.

      See c:portability:Portable_Infoboxes/Tips_and_tricks.

        Loading editor
    • |-
      | style="width:50%; text-align:center;" |'''Previous'''<br />← '''{{#ifeq: {{{chapter|}}} | 1 | N/A | {{#ifexist:Chapter {{#expr:{{{chapter|}}}-1}}|<includeonly>[[Chapter {{#expr:{{{chapter|}}}-1}}{{!}}</includeonly><font color="#000000">Chapter {{#expr:{{{chapter|}}}-1}}</font><includeonly>]]</includeonly>|N/A}} }}'''
      | style="width:50%; text-align:center;" |'''Next'''<br />'''{{#ifexist:Chapter {{#expr:{{{chapter|}}}+1}}|<includeonly>[[Chapter {{#expr:{{{chapter|}}}+1}}{{!}}</includeonly><font color="#000000">Chapter {{#expr:{{{chapter|}}}+1}}</font><includeonly>]]</includeonly>|N/A}}''' →

      I want to add this fuction in my infobox as you can see it in Fairy Tail Wiki:Character Template (Chapter). This template detect new chapter automatically if the new chapter page is created. I really really want to use if else function to take my template to new varsity.

        Loading editor
    • SNN95 wrote:
      |-
      | style="width:50%; text-align:center;" |'''Previous'''<br />← '''{{#ifeq: {{{chapter|}}} | 1 | N/A | {{#ifexist:Chapter {{#expr:{{{chapter|}}}-1}}|<includeonly>[[Chapter {{#expr:{{{chapter|}}}-1}}{{!}}</includeonly><font color="#000000">Chapter {{#expr:{{{chapter|}}}-1}}</font><includeonly>]]</includeonly>|N/A}} }}'''
      | style="width:50%; text-align:center;" |'''Next'''<br />'''{{#ifexist:Chapter {{#expr:{{{chapter|}}}+1}}|<includeonly>[[Chapter {{#expr:{{{chapter|}}}+1}}{{!}}</includeonly><font color="#000000">Chapter {{#expr:{{{chapter|}}}+1}}</font><includeonly>]]</includeonly>|N/A}}''' →
      I want to add this fuction in my infobox as you can see it in Fairy Tail Wiki:Character Template (Chapter). This template detect new chapter automatically if the new chapter page is created. I really really want to use if else function to take my template to new varsity.

      @SNN95: I'm crafting your Template conversion. Should be ready shortly.

        Loading editor
    • So I wasn't extremely good at templates before I started trying to convert the ones at Robotech Saga Wiki, but I seemed to have converted one box pretty flawlessly... Except for the life of my I can't figure out how to change the colour of the darned thing. It's this ugly shade of green, like really ugly, and I can't figure out how to make it red like I want to, because whenever I try to test some stuff from the older templates the system goes all BIG RED ERROR BOX on me. Checked all the help links that wikia would throw at me but none of them gave me an answer, one even did the jerk move of telling me how to change the background colour for one section of text but not the whole thing. Anyone got some pointers?

        Loading editor
    • You could ask at Mentor Plaza on the Portability wiki, but there might be a better place.

        Loading editor
    • Never mind, I figured it out. Thanks!

        Loading editor
    • Would anyone on this thread be interested in being volunteer Mentors for helping out with Portability transition over at Content Portability Wikia? We're trying to get that task force off the ground, but it'd be nice to have some interested parties.

      Also, if anyone wants help in preparing or converting their infoboxes to be Portable, we now have a queue for getting consultants and guides to fix you up. I'm sure we can help with some other people's conversions from using Verbatim, too, since it relates to making things more Portable and secure. Put in requests for your wikias at Mentoring Requests and we'll do our best to get you squared away!

        Loading editor
    • I am happy to report that it appears the link bug that I noted above has been fixed. This demo page is now displaying links in the table inside the tabber at the bottom of the infobox.

      THANKS Wikia!

        Loading editor
    • Hello, I was actually trying to find more out about these new infoboxes and the pressure of changing to them cause I am not too happy about it.

      I have been editing wikis on and off for 5 years (Dragon Age Wiki in the early days, Cafe World Wiki till I couldn't get in to the game and now Paradise Bay Wiki), self taugh wiki code and html with some help from awesome admins. CSS of course is a new scary world to me for one who self taught amateur and just starting to test the waters I have managed to transfer lots of infobox info from templates to the MediaWiki:Wikia.css on our wiki Yay me, but this now portable infobox seems like a blow to the efforts I have been doing for years.

      I finally feel like a wiki infobox guru and it is now obsolete? And hinders my wiki cause what old infobox isn't as mobile friendly as the new one? I extremely dislike the mobile view it does no justice to the full view of a wiki. For some reason I see no images on my mobile view (I have had some people say they don't even see infoboxes (maybe cause it is the old ones but really?)), support asked for screen shots then closed my ticket (was not impressed so I said 'screw mobile view' then focused on full site view)).

      I use several tiers in my infoboxes to accomodate the style/theme/colors, use of transformers and complexity of the game our wiki is about. I am concerned about our Infobox Templates and their respected templates that rely on their infobox transformers- plus we most likely will add more that may require it's own unique needs. I finally have a decent grasp on the old infoboxes I feel that this change is not even worth attempting. CSS tables look like garbly goop to me though I am sure people who actually done courses on it or only have done CSS think HTLM is archaic and inferior- fair enough but really will we be forced to upgrade eventually?

      So after all my ranting (sorry about that you have no idea how much I acutally love wiki/wikias) how can my situation be accomdated to the new infobox without losing all my effort and time spent on the old ones? Can I ignore the new infoboxes indefinitely? Will I be forced to upgrade one day? Is there alternatives? I'd be willing to put work in but I say right now I am not a fan of CSS tables, I like my HTML, I like our current color and style of our current boxes and old infoboxes but if we do not lose what I have put in I'd consider some middle ground or another option. Unless you can do the transfer- guarenteeing my infoboxes will appear exactly the same (not the grey defaults) and still work as they do now (with our transformers and their respected templates).

      Thank you in advance for your time and for Wikis in general. Feel free to take a look at our wiki's infoboxes and how we use them. Maybe if you have a better understanding of what we fear to lose maybe better ways can be implemented or offered for this transition.

      Cheers  Hollowness | Wall | Contr

        Loading editor
    • @Hollowness

      I feel your pain. I took a look at your infoboxes and transformers and I think you should be able to convert them. However, the transformer concept will probably require the use of the theme-source feature, which allows you to customize the CSS by using a parameter passed in through the infobox call. I have made extensive use of this on my wiki. You will find Help:PortableInfoboxes/CSS very useful and there is a full set of bare-bones CSS selectors posted on the portability wiki and you can ask questions in the Forum. Good luck!

        Loading editor
    • Awesome, I'll take a look when I have a good chunk of time to dedicate to it. I do have a lot of my theme/style in our mediawiki css, is that similar to theme source? We can talk here or walls. I just only popped in for checking my messages so I have to turn around and pop off at this moment, thank you for the reply and sympathies (I did feel the ouch on this).

        Loading editor
    • Hollowness wrote:
      Awesome, I'll take a look when I have a good chunk of time to dedicate to it. I do have a lot of my theme/style in our mediawiki css, is that similar to theme source? We can talk here or walls. I just only popped in for checking my messages so I have to turn around and pop off at this moment, thank you for the reply and sympathies (I did feel the ouch on this).

      @Hollowness: A really good place to explore and discuss Portable Infoboxes is on the Portability Hub, which is for exactly that purpose.

        Loading editor
    • Thank you! I will :)

        Loading editor
    • Update on wikiamobile deleting image alt text:

      I got the usual "wikiamobile is supposed to break everything" response from Special:Contact/bug, so it sounds like there will be no fix forthcoming from staff.

      I'm not set up for JS development, so I really shouldn't be tampering with the stuff. But perhaps the fix might look something like this diff on github? Maybe someone else can work on this?

        Loading editor
    • Ok with the help of Moviesign (who is awesome sauce by the way!) we updated our Infobox (Parent), CSS and adjusted their children (transformers didn't need to be done) to accommodate. But it still thinks all this child/transformers should be changed to the new mark up though. I don't want someone to think we need to update these (children and transformers).

      If they do it will break the wiki and if someone thinks they should, they might try (and if I am gone or away- it would be terrible, plus I don't want to explain myself why the wiki says one thing and we do another).

      How do we permanently tell the wiki that they aren't infoboxes (that they are children of the Master Infobox which is in the new mark up) to be converted and to stop asking to convert? When with this insight report stop reporting this?

        Loading editor
    • It is actually an oversight, and will never stop reporting them as needing conversions. But staff is developing a new tool that may resolve this problem eventually.

      You can admin protect them to avoid people incorrectly converting them or alternatively rename them (remove the "infobox" part ) so the insights tool doesn't pick them up as "infoboxes".

        Loading editor
    • At this time I can definitely monitor them, but I may be internet-less soon.

      Removing the infobox from the name may cause other confusion (and it is an infobox (a child or transformer but still infobox) and not just a template). I could add a standard disclaimer (actually my current disclaimer stopped someone who was about to convert them, they messaged me first cause they read that disclaimer) or protect infobox pages so only admins (who should know better) can edit. If the wiki staff don't have a fix by then.

      It is good to know it doesn't just bug me and that it is an actual oversight :)

        Loading editor
    • Hollowness wrote:
      Ok with the help of Moviesign (who is awesome sauce by the way!) we updated our Infobox (Parent), CSS and adjusted their children (transformers didn't need to be done) to accommodate. But it still thinks all this child/transformers should be changed to the new mark up though. I don't want someone to think we need to update these (children and transformers).

      If they do it will break the wiki and if someone thinks they should, they might try (and if I am gone or away- it would be terrible, plus I don't want to explain myself why the wiki says one thing and we do another).

      How do we permanently tell the wiki that they aren't infoboxes (that they are children of the Master Infobox which is in the new mark up) to be converted and to stop asking to convert? When with this insight report stop reporting this?

      best thing to do in this case is to 

      1. not edit any of those as editing will reset the system and display the message once again. no idea why, staff is aware of said bug.
      1. always lock the most important templates, that way even if someone tries there is less risk. plus even if the system gets around that edit block, it doesn't automatically replace the infobox until someone approves. by locking, an admin would have to approve and thus solving your problem. policy, highly used images, important templates [especially small pieces that affect other important templates], home page templates should almost always be locked to prevent accidental changes that are not desired regardless of what staff thinks. a minor change to those minor templates can cause your main templates to randomly display improperly and cause not needed stress of searching the problem.
        Loading editor
    • Dessamator wrote:

      You can admin protect them to avoid people incorrectly converting them or alternatively rename them (remove the "infobox" part ) so the insights tool doesn't pick them up as "infoboxes".

      won't really matter on insights, as long as a template is edited the system will redisplay the message. staff is well aware of this problem, kirkburn knows as i have reported in the past. they just have to fix it. good thing is they are actually actively developing this feature as opposed to letting it die off.

        Loading editor
    • 35.11.22.134 wrote: best thing to do in this case is to 

      1. not edit any of those as editing will reset the system and display the message once again. no idea why, staff is aware of said bug.
      1. always lock the most important templates, that way even if someone tries there is less risk. plus even if the system gets around that edit block, it doesn't automatically replace the infobox until someone approves. by locking, an admin would have to approve and thus solving your problem. policy, highly used images, important templates [especially small pieces that affect other important templates], home page templates should almost always be locked to prevent accidental changes that are not desired regardless of what staff thinks. a minor change to those minor templates can cause your main templates to randomly display improperly and cause not needed stress of searching the problem.

      Yeah, I am pretty strict on my wiki (past gaming app wiki I admin'ed I had tons of vandals), all editing must require log in, the Main Page and Parent Infobox are locked, and Do not Edit Disclaimers are on all my Infobox Templates (and their respected templates they are linked to).

      But I do worry in the future if I do happen to take a long time off and the admins I leave add new admins and think my reason for not updating was flawed or that I missed.

      Also I tend to get outside help on my templates sometimes like Moviesign and I don't want to protect/unprotect or grant admin status/remove admin status whenever I run into template trouble with those pages. I will need to edit often when updates occur in this app game we had 2 in October already that required some Infobox updates.

      Thank you for the suggestions and tips! I will definitely take into consideration :)

        Loading editor
    • @Hollowness:

      In your specific case, I think you should report it as a bug because some of these so-called "infoboxes" are simply not infoboxes. They are meta-templates that may transclude infoboxes.

      The nature of wikis is that others can change things we create. Consequently one should design templates and pages in a way that others can easily use / change them. After all, one day we will all stop using wikis, either due to personal reasons or external factors. Future editors will definitely remove or not use whatever is too complicated to maintain, use or understand. People can always overcome protected templates by changing / copying the part they want and changing the templates in the pages, unless one protects all pages which is a TOU violation.

      @35.11.22.134:

      Well, that's not been my experience, the moment the name changes it disappears from the insights list (perhaps after 24 hours). Maybe you're referring to the banners that show up. These will only disappear once the template is converted or perhaps moved to another namespace.

        Loading editor
    • Dessamator wrote: @Hollowness:

      In your specific case, I think you should report it as a bug because some of these so-called "infoboxes" are simply not infoboxes. They are meta-templates that transclude infoboxes.

      Will do! Thank you :)

        Loading editor
    • Are the new Template types the feature they plan to use to prevent the meta-templates that transclude infoboxes from being considered Infoboxes? If that is the case I am suppose to make sure I don't set to infoboxes (cause it would be assumed they are since they are the templates that used on the article as an infobox)?

      Or can I set them as that type? Since I don't know how else to describe them as besides: Displays the most essential information about an article in a box at the top of the page, usually to the right side. (all I need is more confusion on these template pages LOL).

        Loading editor
    • You can set them as "data" I think...

        Loading editor
    • Actually, I think the "data" type is meant for stat bars and tables, in that sense of the word. We need another template type for "transcludes a template itself". Maybe call it "meta" or something?

        Loading editor
    • AgentMuffin wrote:
      Actually, I think the "data" type is meant for stat bars and tables, in that sense of the word. We need another template type for "transcludes a template itself". Maybe call it "meta" or something?

      Meta-template doesn't work because they are generally  only meant to be used by another template. While in this specific case, the transformers choose what content will be displayed in a page. In some cases it displays an infobox, in others it may be a table.

      Generally speaking, this content would be put in a "data template", e.g. https://en.wikipedia.org/wiki/Template:Country_data_Alcoy  or data module  e.g. (w:c:dev:Module:Country/data).

        Loading editor
    • Dessamator wrote: You can set them as "data" I think...

      Yeah I set as data (since setting to infobox says to go to new mark up), but now insight wants me to add an infoboxes to every page of my wiki *eyeroll* this really didn't fix the problem it made it worse LOL. So new mark up about to 20 templates or add 290 infoboxes to my wiki, seriously which is the better devil here :P Not really a fix wiki staff X /

      I mean if people never what to adjust to new mark up they can have all infoboxes that are actually infoboxes as data too... would it have killed to add a type: Infobox Child - Allows advanced Design, Structure, Data of an Infobox (not show up on insight needing new mark up nor adding an infobox - if an infobox child is present). That would have been a fix!

      Well lets just say I made a new template yesterday a disclaimer on all the meta-templates that transclude infoboxes pages. Saying don't change to new mark up, these aren't the infoboxes the wiki thinks they are and if you do - it will break the entire wiki, dramatic but I just don't want to take chances now.

        Loading editor
    • @Hollowness

      I have some pass-through templates that are very much like your transformers. All they do is change the look of the infobox (now using theme-source), so I set them to type "Design". I haven't bothered with Insights much yet, just converting my infoboxes to portable is all I'm doing right now. I think you can safely ignore most of what Insights tells you, if you wish.

        Loading editor
    • Moviesign wrote: @Hollowness

      I have some pass-through templates that are very much like your transformers. All they do is change the look of the infobox (now using theme-source), so I set them to type "Design". I haven't bothered with Insights much yet, just converting my infoboxes to portable is all I'm doing right now. I think you can safely ignore most of what Insights tells you, if you wish.

      I worry about when I am gone, I won't be around forever. A new admin may see this as me doing something wrong and not get it, no matter how blue in the face I left disclaimers and explanations.

        Loading editor
    • Hollowness wrote:

      Dessamator wrote: You can set them as "data" I think...

      Yeah I set as data (since setting to infobox says to go to new mark up), but now insight wants me to add an infoboxes to every page of my wiki *eyeroll* this really didn't fix the problem it made it worse LOL. So new mark up about to 20 templates or add 290 infoboxes to my wiki, seriously which is the better devil here :P Not really a fix wiki staff X 

      The insights list isn't meant to be completely "solved". It is simply meant to give a general idea of what pages may need improvement. I think staff mentioned that in the future admins may be able to choose which insights get displayed, so it shouldn't be a permanent problem.

        Loading editor
    • Oh that would be nice. It just sucks for those who like to check off everything on a list :P

        Loading editor
    • I'm just curious as to why the title display on mobile is different depending on whether or not you have the "stacked" layout set. Either way, the layout is not stacked on mobile, but if "stacked" is set then the title appears in the lower left of the infobox image and the image is the full width of the screen, otherwise the title appears over the image and there is space to the left and right of the image. (My preference is to have the title in the lower left of the image, but YMMV.)

      I suppose it would help if I gave actual examples:
      Neutral Bow (stacked)
      Cosmic Blast (not stacked)
      I'm using Safari on an iPhone 6S. On mobile, the titles/images do not display the same.

        Loading editor
    • Edit: This issue has since been fixed! Thanks!


      Another observation: I just noticed that for the articles where I placed a portable infobox, the infobox image is not always used for the article's thumbnail (for category pages, etc.) Actually, the only situation where the infobox image is the thumbnail is when the infobox image is the only image in the article. I'm sure this is unintentional, but that's something that I think ought to be fixed.

        Loading editor
    • The same happened for classic infoboxes. Must have something to do with template transclusion.

        Loading editor
    • Horseshoe Crab wrote: Another observation: I just noticed that for the articles where I placed a portable infobox, the infobox image is not always used for the article's thumbnail (for category pages, etc.) Actually, the only situation where the infobox image is the thumbnail is when the infobox image is the only image in the article. I'm sure this is unintentional, but that's something that I think ought to be fixed.

      Article Thumbnails are chosen by I believe the first image of a certain size (I was told and seems to be true for my infobox images too). My infobox images are 128x128 pixels but I have had 176 x 176 images show on the article preview/thumb (so I think it has to be 150 x 150 at least to show).

      It drives me nuts because usually infobox images best describe the article in 1 photo.

        Loading editor
    • The size of the image in the infobox isn't the issue in my case. In one article the infobox image is 484x484 (resized to 270x270 for the infobox) and a different image in the article is being used for the thumbnail. But what you said is also true in general.

        Loading editor
    • Yeah I am not sure then, it was second hand information to begin with : /

        Loading editor
    • It would help tremendously if someone would make a new post accumulating all the problems that have been seen in the mobile skin into a big list. Then Wikia staff could be directed to the post and hopefully attempt to give status on what they plan to do.

      I've tried stuff like this in the past, but people seem to like to ignore my posts in most cases, so I've sort of given up.

        Loading editor
    • Fandyllic wrote: It would help tremendously if someone would make a new post accumulating all the problems that have been seen in the mobile skin into a big list. Then Wikia staff could be directed to the post and hopefully attempt to give status on what they plan to do.

      I've tried stuff like this in the past, but people seem to like to ignore my posts in most cases, so I've sort of given up.

      I can't even get Wiki Support to acknowledge that Mobile view is flawed! Have had complaints some of my viewers cannot even see infoboxes on their mobile. I don't see pictures (and not the main page even thought I have both mobile and regular fully done).

      I just get told when they view the wiki site on their 'at hand' android it looks fine. I just sent them screenshots and I get accused it is cause my phone is out of date, I updated my phone still can't see images. Web pages/mobile browsers still work/can be viewed with a phone out of date or not.

      So besides defending myself that mobile view sucks/doesn't work I am not sure I am able to take on a project on it just yet, but I could definitely /sign or agree on matters (even provide some of my screenshots). LOL

        Loading editor
    • Fandyllic wrote:
      It would help tremendously if someone would make a new post accumulating all the problems that have been seen in the mobile skin into a big list. Then Wikia staff could be directed to the post and hopefully attempt to give status on what they plan to do.

      I've tried stuff like this in the past, but people seem to like to ignore my posts in most cases, so I've sort of given up.

      Mobile skin issues are Portability issues, too. :-) Why not compile that list at the Hub?

        Loading editor
    • There is a planned office hours by staff in portability.wikia for questions or concerns about infoboxes or anything related to portability.

      See Announcement here.

        Loading editor
    • How can I make a template to be not considered as Infobox, So it doesn't show up in the NOT PORTABLE INFOBOX insight menu?

        Loading editor
    • Change the template type?

        Loading editor
    • I need a lot of help on the Elfen Lied Wiki. I am attempting the directed conversions, and not seeing any results that look like what is supposed to be there. And now there are huge prompts over the wiki title urging me to convert these infoboxes? Also, the Insights page is saying I have 509 pages without infoboxes, when a good portion if not most of those do. All the character, chapter and episode pages, certainly.

      I'm going to try and learn this new process, though I miss simply cutting and pasting an old template and changing the info. I will believe you when you say that this will ultimately be simpler, but for the present it feels a lot like you've taken a BD/DVR process and made it early VHS.

        Loading editor
    • My own wiki will be continuing to use the old infobox, as it seems to mess up the rows whenever someone updates it to the "newer" model. I also have a personal preference to the classic infobox's appearance and am in no hurry to change it.

      However, there is now a message at the top of the wiki continuously "reminding" me that my infoboxes are out of date and sending my to a survey every time I click "no". Is there any way to permanently remove the message, bar updating my infoboxes? I am not interested in "updating" the infoboxes, as they are quite perfect the way they are.

        Loading editor
    • Add this to Special:MyPage/common.css on your wikia.
      section.ebs-container{display:none!important;}
      This will only make the box disappear if you're on your own account. I don't recommend adding this to site-wide CSS as it could be viewed as a breach of Wikia's ToU.

      Also, you're welcome!

        Loading editor
    • You guys are getting a little annoying the way you're trying to shove this new infobox format down everyone's throat! You have the Insights section telling us to not only change them all, but it's saying that none of our pages even have one! I guess you're not going to recognize anything but your new format. And now I have a annoying banner pop up on every page telling me I need to change them.

      You need to get over yourselves, all of our infoboxes look perfectly fine on mobile devices, we've checked them on iOS, Android and Windows phones as well as your built in mobile preview window and they all look fine, better than yours do if I was to be the judge.

      Quit shoving these things down our throats and turn off that annoying banner on every page!

        Loading editor
    • Is the issue fixed with the infobox image not being used as the thumbnail of the article (in Category gallery and Read more)?

        Loading editor
    • 452

      I guess the "Recent changes across Wikia" box wasn't in-your-face enough.

      Perhaps there really are people who still don't know about portable infoboxes, or maybe Wikia is hoping pestering us will work.

      Wikia used to be about the freedom of communities to do whatever they liked with their content. But most new Wikia features are about Wikia dictating what communities must do with their content.

      Ugly nag about optional infoboxes

      I've checked, and my infoboxes are not "broken" on mobile devices, so this banner is an outright lie.

      Of course, while they look "okay" now, they looked better when CSS could be shoehorned in. As I've said before, I had already put a lot of work into ensuring that my content looked good on mobile, but since Wikia decided to throw that out, I will not be putting in any effort beyond making sure things aren't "broken".

      You know what is broken on mobile devices? Embedded audio, and Wikia are the only ones who can fix that. I've also just reported the fact that references are broken on mobile.

      Here's the banner itself:

      24

      This community's infoboxes are broken on mobile devices.

      Your infoboxes are outdated. Let's rebuild them with new methods that are mobile-friendly. Learn more here.

      edit: Apparently the CSS to render the message isn't loaded all the time, so this recreation may or may not be missing the logo, depending on whether the CSS is currently loaded for you.

      And here's CSS to hide the message:

      .ebs-container { display:none; }

      edit: Took too long to type and was beaten to the CSS.

      ReapTheChaos wrote:

      I guess you're not going to recognize anything but your new format.
      Ah, so that's how it works. I had briefly wondering why the list of "pages without infoboxes" contained pages with infoboxes. Thanks for pointing it out.
        Loading editor
    • ReapTheChaos wrote:
      You guys are getting a little annoying the way you're trying to shove this new infobox format down everyone's throat! You have the Insights section telling us to not only change them all, but it's saying that none of our pages even have one! I guess you're not going to recognize anything but your new format. And now I have a annoying banner pop up on every page telling me I need to change them.

      You need to get the hell over yourselves, all of our infoboxes look perfectly fine on mobile devices, we've checked them on iOS, Android and Windows phones as well as your built in mobile preview window and they all look fine, better than yours do if I was to be the judge.

      Quit shoving these things down out throats and turn off that damn banner on every page!

      A bit vulgar, but I agree, they may have gone to far with the huge orange box. Displaying them on Insights, though, I can deal with.

        Loading editor
    • I'm sorry, I'm too busy laughing my butt off. Why? The big orange banner of doom appeared on a wiki I'm editing... but the only outdated infoboxes were the default ones put there by Wikia!

      Bravo, wikia, bravo.

        Loading editor
    • They might want to update those to fit the portable code, and have them pre-classified.

        Loading editor
    • AgentMuffin wrote: A bit vulgar, but I agree, they may have gone to far with the huge orange box. Displaying them on Insights, though, I can deal with.

      I was a tad annoyed when I wrote that, I was getting that banner popping up every page load, I've edited out the colorful language now.

      I can ignore the insights messages too, but telling me that all 1,139 pages of my wiki are missing an infobox makes it a pretty useless tool don't you think?

        Loading editor
    • Tried the Convert thing from the migration page, but it produced code of

      Row X Title = TitleX
      Row X Info = InfoX
      Row Y yada yada etc…

      Problem is what it produces is an info box which prints out

      Row X Title WhatTheTitleNeedsToBe
      Row X Info TheInfo

      instead of compiling them into one line

      WhatTheTitleNeedsToBe TheInfo
        Loading editor
    • AgentMuffin wrote: They might want to update those to fit the portable code, and have them pre-classified.

      Yeah, it was only a couple of them though. Still annoying.

        Loading editor
    • Love Robin wrote: Tried the Convert thing from the migration page, but it produced code of

      Row X Title = TitleX
      Row X Info = InfoX
      Row Y yada yada etc…

      Problem is what it produces is an info box which prints out

      Row X Title WhatTheTitleNeedsToBe
      Row X Info TheInfo

      instead of compiling them into one line

      WhatTheTitleNeedsToBe TheInfo

      I think I had that same problem at first when I tried, I basically, had to get help from people with Portable Infobox experience to hold my hand through it. The straight up convert option they give I think is for people who never really customized their infoboxes? I am not sure.

        Loading editor
    • @LoveRobin

      The PI converter routine works for simple infoboxes, but needs massaging for most anything with logic in it or fields that depend on other fields. I'll take a look at your stuff if you'd like.

        Loading editor
    • Yeah, I am not digging this new in-your-face approach even with all my child templates set as Data, insight still wants to convert them though the Master Parent is in the new Portable Infobox format. Plus it is saying all our pages are missing Infoboxes on top of that (of the ones that have been viewed recently).

      This may even get my new admin to question our Infobox situation again, though I have explained, posted disclaimers on each template but he is the founder of our Wiki's French version and I will not blame him for having concerns about it now he has his own Wiki to think about though it is a full export/import of our English Original (we are still translating though). I have referred him to this Thread now so he could take part in this discussion if he wishes.

        Loading editor
    • I'm still a bit mixed about this... but anyway, the infobox I currently have for characters (Template:Character on Bas-Makes-Games Wikia) looks great after converting. I deleted a few obsolete templates though, which were mainly just placeholders as I was planning on making better ones anyway. But even about 9 hours after deleting those templates, it still gives Insight warnings, even though the templates shouldn't even exist anymore, and Convert produces a blank draft with no markup at all. (logical, because the template doesn't even exist to begin with)

      I still think this is all a bit too drastic and unexpected, and you did a poor job on informing us. I could easily have followed the blogs and all (if it was announced there) but not everyone has a good internet connection, and some people already have trouble with the bills and taxes in the first place, and it would have been appreciated if drastic updates like this would appear in our notifications box or whatever.

        Loading editor
    • ISolsticeDay wrote:
      I'm still a bit mixed about this... but anyway, the infobox I currently have for characters (Template:Character on Bas-Makes-Games Wikia) looks great after converting. I deleted a few obsolete templates though, which were mainly just placeholders as I was planning on making better ones anyway. But even about 9 hours after deleting those templates, it still gives Insight warnings, even though the templates shouldn't even exist anymore, and Convert produces a blank draft with no markup at all. (logical, because the template doesn't even exist to begin with)

      It takes a while for the cache to reset and clear up the list. Generally 24 hours or so.

      I still think this is all a bit too drastic and unexpected, and you did a poor job on informing us.

      I'm sorry to say that you're wrong. With most other features you might have been right. But this specific feature was announced more than 6 months ago in a forum which deliberately asked for user input Thread:841717.

      There were also other announcements in subsequent blogs and technical updates (see this).

      If that wasn't enough there has been an insights list on every wiki for several months "indicating" that the infoboxes are not portable.

        Loading editor
    • thanks for your reply. I apologize for the cynicism and my statement about you guys doing a "poor job", i was kinda groggy as I was just awake and at my workplace, and if it was announced 6 months ago it was clearly pretty stupid of me. So on that, you're right. Thanks for your thoughtful reply nonetheless. :-)

        Loading editor
    • How do I change the text allignment? The default setting is almost the exact opposite of what I want.

        Loading editor
    • The best way to do that is to use CSS. You can use for example

       .portable-infobox .pi-title { text-align: center } 

      to center all title fields.

      Other usefull selectors can be found on: http://community.wikia.com/wiki/Help:PortableInfoboxes/CSS

        Loading editor
    • Shareif wrote:
      The best way to do that is to use CSS. You can use for example
       .portable-infobox .pi-title { text-align: center } 

      to center all title fields.

      Other usefull selectors can be found on: http://community.wikia.com/wiki/Help:PortableInfoboxes/CSS


      I'm sorry, but that is not much help to me. I am not a software developer, I do not have the patience to deal with infoboxes when making a table would suffice. Why can't designing infoboxes be as simple as making a table?

        Loading editor
    • Oh, I agree, It should. It's just not there yet. If you could share what you want to build I could go to your wiki and help you style the infobox like you want. I bet many people in this thread would like to help also :)

        Loading editor
    • Rojixus wrote:

      Shareif wrote:
      The best way to do that is to use CSS. You can use for example
       .portable-infobox .pi-title { text-align: center } 

      to center all title fields.

      Other usefull selectors can be found on: http://community.wikia.com/wiki/Help:PortableInfoboxes/CSS


      I'm sorry, but that is not much help to me. I am not a software developer, I do not have the patience to deal with infoboxes when making a table would suffice. Why can't designing infoboxes be as simple as making a table?

      Well, tables are typically One Page. Changes of format made to 1 are not dynamically reflected in others, and so each need to be found and changed. Where Infoboxes will dynamically change across the wikia. Unless you make them a template, in which case you'll run into the same issues as infobox templates. With most common alterations already in a list of CSS codes, it becomes basically a shopping trip, going down the aisles and selecting "one of this, one of that" to add to your CSS page.

        Loading editor
    • Rojixus wrote: I'm sorry, but that is not much help to me. I am not a software developer...

      Same here, I'm just a guy who likes video games. I figured out the old infoboxes by just copy/pasting them from another wiki and tinkering around until I got what I liked.

      I tried converting one of ours to the new format with their conversion tool but it didn't look right. I tried reading their help page on them but it's written way above my head and I think the heads of most people. They need to create a help page in simple English for us non programming geeks if they want us to make this switch.

        Loading editor
    • They need to create a help page in simple English for us non programming geeks if they want us to make this switch.

      Easier said than done. Making simple documentation is particularly complicated. It would require  that infobox page to be sub-divided into basics and advanced. 

      But still, I agree with you. The old table based infoboxes were intimidating to me when I first saw them, and unlike most users I know how to develop software from scratch. Anyway, there is a "somewhat basic" page here.

      Feedback on how to improve it is welcome. Perhaps when it gets simpler, we can create a simpler help page here in community central using it.

        Loading editor
    • @Rojixus: Are you talking about w:c:creativesci-fi:Template:War and [[w:c:creativesci-fi:Template:New_Conflict_Infobox]]?

      Also, @Rojixus and @ReapTheChaos: please remember that there are volunteers over at w:c:portability:Portability Hub who can help you out if you get stuck. There are more user friendly guides there, too.

        Loading editor
    • FishTank wrote:
      @Rojixus: Are you talking about w:c:creativesci-fi:Template:War and [[w:c:creativesci-fi:Template:New_Conflict_Infobox]]?

      Also, @Rojixus and @ReapTheChaos: please remember that there are volunteers over at w:c:portability:Portability Hub who can help you out if you get stuck. There are more user friendly guides there, too.

      I was specifically refering to the New Conflict Infobox, which was meant to replace the old War template. I want the headers to be centered and the actual information to be left-aligned. Basically, I'm trying to recreate the Wikipedia's war template.

        Loading editor
    • Rojixus wrote:

      FishTank wrote:
      @Rojixus: Are you talking about w:c:creativesci-fi:Template:War and [[w:c:creativesci-fi:Template:New_Conflict_Infobox]]?

      Also, @Rojixus and @ReapTheChaos: please remember that there are volunteers over at w:c:portability:Portability Hub who can help you out if you get stuck. There are more user friendly guides there, too.

      I was specifically refering to the New Conflict Infobox, which was meant to replace the old War template. I want the headers to be centered and the actual information to be left-aligned. Basically, I'm trying to recreate the Wikipedia's war template.

      Hmm, for that you'd want to add this to your css:

      .pi-theme-THEMENAME {
        text-align:left;
      }
      .pi-theme-THEMENAME .pi-title,
      .pi-theme-THEMENAME .pi-header,
      .pi-theme-THEMENAME .pi-navigation
       {
        text-align:center;
      }
      

      Where THEMENAME is the name used for your theme on the infobox.

        Loading editor
    • @Ylimegirl: Thanks! Interested in being a Mentor for others?

        Loading editor
    • FishTank wrote: @Ylimegirl: Thanks! Interested in being a Mentor for others?

      That article you linked to doesn't exist... I found one that I think talks about the subject here. I think I can do everything except for Lua coding, but I could probably figure it out if I looked into Lua more. If that's okay, I'd be happy to help.

        Loading editor
    • Ylimegirl wrote:

      FishTank wrote: @Ylimegirl: Thanks! Interested in being a Mentor for others?

      That article you linked to doesn't exist... I found one that I think talks about the subject here. I think I can do everything except for Lua coding, but I could probably figure it out if I looked into Lua more. If that's okay, I'd be happy to help.

      Sounds great! And yes, that's the article. We changed the name today, so we're officially the "Portability Hub" rather than "Content Portability Wikia". 

        Loading editor
    • Oh boy, is it going to be on the Wikia bar or something now?

        Loading editor
    • AgentMuffin wrote:
      Oh boy, is it going to be on the Wikia bar or something now?

      Actually, yes. That's the plan. Portability Hub is a public (user-driven) / private (Wikia Staff-driven) partnership. Kind of like the VSTF. If you're interested in Portable Infoboxes, and other emerging features that are building the next generation of Wikia, it's the place to go. Non-staff users help with documentation and novice-friendly guides, as well as Mentoring others. We also have some design contests for making beautiful portable elements. Staff supply knowledge, resources, and have office hours every week with us. We're all very invested in making Portability work for the largest possible number of wikias. So, along with that - I've been told we're getting a dedicated hotline button up there on Community's toolbar.

      Well, I say that and think of the new bright orange Emergency Broadcast System that's on a lot of people's minds right now. It's not how I'd rather people be brought to us, but if it helps people out...

        Loading editor
    • Having been up until two this morning sorting stuff out, including converting all my infoboxes to the new portable coding... Why am I again being told all 17 of my infobox templates (which include the four or five default ones my wikia doesn't use) need converting?

      If that's going to keep happening when I update things, I'm liable to throw something.

        Loading editor
    • Sharpiefan wrote:
      Having been up until two this morning sorting stuff out, including converting all my infoboxes to the new portable coding... Why am I again being told all 17 of my infobox templates (which include the four or five default ones my wikia doesn't use) need converting?

      If that's going to keep happening when I update things, I'm liable to throw something.

      You could  delete them, or move them to another namespace.

        Loading editor
    • Dessamator wrote:
      Sharpiefan wrote:
      Having been up until two this morning sorting stuff out, including converting all my infoboxes to the new portable coding... Why am I again being told all 17 of my infobox templates (which include the four or five default ones my wikia doesn't use) need converting?

      If that's going to keep happening when I update things, I'm liable to throw something.

      You could  delete them, or move them to another namespace.

      Or classify them as something other than Infobox.

        Loading editor
    • I suggest redirect pages to be removed from "pages without infobox". I doubt it's useful to add infoboxes to redirect pages...

        Loading editor
    • Dessamator wrote:

      But still, I agree with you. The old table based infoboxes were intimidating to me when I first saw them, and unlike most users I know how to develop software from scratch. Anyway, there is a "somewhat basic" page here.

      If that's the dumbed down version then count me out, it lost be when it started talking about CSS and themes.

      We'll stick with the ones we have, they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard. I just wish there was a way to set up those Insights to ignore them.

        Loading editor
    • Just a basic gripe -I've recently taken over as admin for the Churches of Rome Wiki which has over 1440 pages, all originally with infoboxes. Now I've got "Insights" telling me on each page that I've got "999+ pages without an infobox", and " 3 pages with an non-portable infobox".

      The infobox situation on this particular Wiki is a complete train crash, and so I'm fencing off the problem as toxic and walking away from it. I'm NOT manually adding portable infoboxes to over a thousand pages -life is too short. The original infobox text is still on the "999+" pages.

        Loading editor
    • ReapTheChaos wrote:

      Dessamator wrote:

      But still, I agree with you. The old table based infoboxes were intimidating to me when I first saw them, and unlike most users I know how to develop software from scratch. Anyway, there is a "somewhat basic" page here.

      If that's the dumbed down version then count me out, it lost be when it started talking about CSS and themes.

      We'll stick with the ones we have, they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard. I just wish there was a way to set up those Insights to ignore them.

      There is a somewhat better page here w:c:p:Infobox/Basics. I can try to create a simpler page for styling but  there currently isn't a shortcut for it unless you want plain simple pages. That is much like wanting to use advanced calculus and algebra without knowing basic arithmetic.

      they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard.

      They appear " perfectly fine" on some mobile phones because wikia has some hacks in place to make it so.  One day, wikia might decide that the hacks aren't worth the development time they waste on it, and eventually remove them all, resulting in a similar event as this .

      Unless you've tested them on more than a dozen mobile phones with different form factors your assessment is certainly inaccurate. A mobile phone is not only a smartphone, it is also a feature phone, a device with two screens, and  theoretically even a smartwatch can make calls [1] . A mobile device has even stranger form factors  as is the case of  a Google glass device, ipod, and so on.

        Loading editor
    • Basilwatkinsosb wrote:
      Just a basic gripe -I've recently taken over as admin for the Churches of Rome Wiki which has over 1440 pages, all originally with infoboxes. Now I've got "Insights" telling me on each page that I've got "999+ pages without an infobox", and " 3 pages with an non-portable infobox".

      The infobox situation on this particular Wiki is a complete train crash, and so I'm fencing off the problem as toxic and walking away from it. I'm NOT manually adding portable infoboxes to over a thousand pages -life is too short. The original infobox text is still on the "999+" pages.

      I'm not sure I understand, do you have 1440 with Help:Classic Infoboxes or do you have a few of them with infoboxes, and insights is saying that you need more?

      Most wikis use very few infoboxes in many pages, some of them may use a particular infobox in hundreds if not thousands of pages. As long as the original infoboxes are converted, the pages with those will automatically change.

      You can also request help here:

        Loading editor
    • The admin page tells me that this Wiki is using four infobox templates, and I converted these when prompted to "portable". Three of them only occur on sixteen pages, but one (called "infobox:church") is on over a thousand. I've checked the template, and the text looks as if it has actually converted to "portable" (no, I didn't re-write it myself). However, none of the infoboxes on the "church" pages seem to have followes suit, and converted from "classic" text (I've done a quick random sample to check directly). So: infobox template converted -actual page templates didn't!

        Loading editor
    • Basilwatkinsosb wrote:
      The admin page tells me that this Wiki is using four infobox templates, and I converted these when prompted to "portable". Three of them only occur on sixteen pages, but one (called "infobox:church") is on over a thousand. I've checked the template, and the text looks as if it has actually converted to "portable" (no, I didn't re-write it myself). However, none of the infoboxes on the "church" pages seem to have followes suit, and converted from "classic" text (I've done a quick random sample to check directly). So: infobox template converted -actual page templates didn't!

      Pages don't reflect changes immediately, they rely on Cache. The cache is generally refreshed every 24 hours. Sometimes on weekends I've noticed that the cache doesn't always refresh until the next "working day".

      If you want to see the results immediately, you need to Help:purge the cache or simply edit the page and save without making any changes.

      P.S. Not all pages  need infoboxes and you can safely ignore that "pages without an infobox" insights if you feel the page doesn't need it. Just like community central has chosen to do.

        Loading editor
    • Basilwatkinsosb wrote:
      The admin page tells me that this Wiki is using four infobox templates, and I converted these when prompted to "portable". Three of them only occur on sixteen pages, but one (called "infobox:church") is on over a thousand. I've checked the template, and the text looks as if it has actually converted to "portable" (no, I didn't re-write it myself). However, none of the infoboxes on the "church" pages seem to have followes suit, and converted from "classic" text (I've done a quick random sample to check directly). So: infobox template converted -actual page templates didn't!

      Looking at your stats, everything should be right, yet it's still throwing the error. The only thing I can think of that might cause that error is that your (now Portable) "Infobox church" doesn't use a <title>, given that each Church has (at least) two names. I wonder if that's throwing things off. Might be a good idea to file Special:Contact/bugs on that.

        Loading editor
    • Dessamator wrote:

      ReapTheChaos wrote:

      Dessamator wrote:

      But still, I agree with you. The old table based infoboxes were intimidating to me when I first saw them, and unlike most users I know how to develop software from scratch. Anyway, there is a "somewhat basic" page here.

      If that's the dumbed down version then count me out, it lost be when it started talking about CSS and themes.

      We'll stick with the ones we have, they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard. I just wish there was a way to set up those Insights to ignore them.

      There is a somewhat better page here w:c:p:Infobox/Basics. I can try to create a simpler page for styling but  there currently isn't a shortcut for it unless you want plain simple pages. That is much like wanting to use advanced calculus and algebra without knowing basic arithmetic.

      they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard.

      They appear " perfectly fine" on some mobile phones because wikia has some hacks in place to make it so.  One day, wikia might decide that the hacks aren't worth the development time they waste on it, and eventually remove them all, resulting in a similar event as this .

      Unless you've tested them on more than a dozen mobile phones with different form factors your assessment is certainly inaccurate. A mobile phone is not only a smartphone, it is also a feature phone, a device with two screens, and  theoretically even a smartwatch can make calls [1] . A mobile device has even stranger form factors  as is the case of  a Google glass device, ipod, and so on.

      Well that basics page is definitely easy to understand, but where I'm getting lost is on themes and CSS, I'm assuming that's where you make changes like color, text and styling of the box. I'm not looking for anything too elaborate, we use one basic style of infobox on our pages. I'd just like to create one that looks close to what we have now.

        Loading editor
    • ReapTheChaos wrote:

      Dessamator wrote:

      ReapTheChaos wrote:

      Dessamator wrote:

      But still, I agree with you. The old table based infoboxes were intimidating to me when I first saw them, and unlike most users I know how to develop software from scratch. Anyway, there is a "somewhat basic" page here.

      If that's the dumbed down version then count me out, it lost be when it started talking about CSS and themes.

      We'll stick with the ones we have, they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard. I just wish there was a way to set up those Insights to ignore them.

      There is a somewhat better page here w:c:p:Infobox/Basics. I can try to create a simpler page for styling but  there currently isn't a shortcut for it unless you want plain simple pages. That is much like wanting to use advanced calculus and algebra without knowing basic arithmetic.

      they look perfectly fine on mobile phones anyway so I don't know why they're pushing this so hard.

      They appear " perfectly fine" on some mobile phones because wikia has some hacks in place to make it so.  One day, wikia might decide that the hacks aren't worth the development time they waste on it, and eventually remove them all, resulting in a similar event as this .

      Unless you've tested them on more than a dozen mobile phones with different form factors your assessment is certainly inaccurate. A mobile phone is not only a smartphone, it is also a feature phone, a device with two screens, and  theoretically even a smartwatch can make calls [1] . A mobile device has even stranger form factors  as is the case of  a Google glass device, ipod, and so on.

      Well that basics page is definitely easy to understand, but where I'm getting lost is on themes and CSS, I'm assuming that's where you make changes like color, text and styling of the box. I'm not looking for anything too elaborate, we use one basic style of infobox on our pages. I'd just like to create one that looks close to what we have now.

      And you can always ask for a mentor to help you with that! No problem.

        Loading editor
    • Ylimegirl wrote:

      And you can always ask for a mentor to help you with that! No problem.

      Where do I go to make that request?

        Loading editor
    • ReapTheChaos wrote:

      Ylimegirl wrote:

      And you can always ask for a mentor to help you with that! No problem.

      Where do I go to make that request?

      So glad you asked! w:c:p:Mentoring:Requests

        Loading editor
    • FishTank wrote:

      ReapTheChaos wrote:

      Ylimegirl wrote:

      And you can always ask for a mentor to help you with that! No problem.

      Where do I go to make that request?

      So glad you asked! w:c:p:Mentoring:Requests

      Thanks!

        Loading editor
    • FishTank wrote:
      Basilwatkinsosb wrote:
      The admin page tells me that this Wiki is using four infobox templates, and I converted these when prompted to "portable". Three of them only occur on sixteen pages, but one (called "infobox:church") is on over a thousand. I've checked the template, and the text looks as if it has actually converted to "portable" (no, I didn't re-write it myself). However, none of the infoboxes on the "church" pages seem to have followes suit, and converted from "classic" text (I've done a quick random sample to check directly). So: infobox template converted -actual page templates didn't!
      Looking at your stats, everything should be right, yet it's still throwing the error. The only thing I can think of that might cause that error is that your (now Portable) "Infobox church" doesn't use a <title>, given that each Church has (at least) two names. I wonder if that's throwing things off. Might be a good idea to file Special:Contact/bugs on that.

      I've tried purging a sample page, but the infobox won't convert. I think you might be right as regards the problem in generating <title> for each page from the template, and will get round to filing Special:Contact/bug. Meanwhile, I don't see any quick way of dealing with the problem and will leave things alone. Thanks for the help!

        Loading editor
    • FishTank wrote:

      SNN95 wrote:
      |-
      | style="width:50%; text-align:center;" |'''Previous'''<br />← '''{{#ifeq: {{{chapter|}}} | 1 | N/A | {{#ifexist:Chapter {{#expr:{{{chapter|}}}-1}}|<includeonly>[[Chapter {{#expr:{{{chapter|}}}-1}}{{!}}</includeonly><font color="#000000">Chapter {{#expr:{{{chapter|}}}-1}}</font><includeonly>]]</includeonly>|N/A}} }}'''
      | style="width:50%; text-align:center;" |'''Next'''<br />'''{{#ifexist:Chapter {{#expr:{{{chapter|}}}+1}}|<includeonly>[[Chapter {{#expr:{{{chapter|}}}+1}}{{!}}</includeonly><font color="#000000">Chapter {{#expr:{{{chapter|}}}+1}}</font><includeonly>]]</includeonly>|N/A}}''' →
      I want to add this fuction in my infobox as you can see it in Fairy Tail Wiki:Character Template (Chapter). This template detect new chapter automatically if the new chapter page is created. I really really want to use if else function to take my template to new varsity.

      @SNN95: I'm crafting your Template conversion. Should be ready shortly.

      Is it ready yet?

        Loading editor
    • Is there a similar thread to this for portability issues with the mobile version that don't involve infoboxes? I just noticed that references seem to be broken on mobile.

        Loading editor
    • Horseshoe Crab wrote:
      Is there a similar thread to this for portability issues with the mobile version that don't involve infoboxes? I just noticed that references seem to be broken on mobile.

      If you're sure there is a problem with the references  and not your mobile browser then Contact support.

        Loading editor
    • Ducksoup wrote:
      Hey all, 

      The last thread was grinding even the spiciest computers to a halt, so here's a fresh slate to keep the conversation going!

      Surely developing better forum software with pages of a set number of posts would be a better idea? Ridiculously long pages is not good.

        Loading editor
    • After some experience with PIs over at the Fallout wiki, here a wishlist of sorts (some tips on how to solve the issues otherwise would be welcome too).

      It would be nice to be able to use <format> tags inside of <image> tags. That makes it easy to mix images (we used to display small icons at the top right corner of the main image) and imposing a maximum height on irregular sized images would be easy via something like <image source="image"><format>[[File:{{{image}}}|240x250px]]</format></image>.

      Another nice feature would be able to use "class" and "style" attributes in tags (copied to html). Trying to target the 3rd data field in a group is inherently fragile and error-prone. And while for regular styling global css is preferrable, inline css has it's uses for exceptions to the rule.

        Loading editor
    • Alfwyn wrote:
      After some experience with PIs over at the Fallout wiki, here a wishlist of sorts (some tips on how to solve the issues otherwise would be welcome too).

      It would be nice to be able to use <format> tags inside of <image> tags. That makes it easy to mix images (we used to display small icons at the top right corner of the main image) and imposing a maximum height on irregular sized images would be easy via something like <image source="image"><format>[[File:{{{image}}}|240x250px]]</format></image>.

      Another nice feature would be able to use "class" and "style" attributes in tags (copied to html). Trying to target the 3rd data field in a group is inherently fragile and error-prone. And while for regular styling global css is preferrable, inline css has it's uses for exceptions to the rule.


      One way to get around the difficulty of targeting something is to use the nth type:

      .pi-theme-disney .pi-data:nth-child(2) {
          background-color: green;
      }

      Another less attractive way, and something the devs probably don't recommend is to use a class :

      <infobox> 
      <navigation><div class="test">{{{abc}}}</div>
      </div>

      Then you can target that using :

      .pi-theme-disney .test {
          background-color: green;
      }

      Anyway, I do agree that it should probably be easier to target the infobox items, and this can be achieved internally (By Staff) by numbering all classes.

      As far as images are concerned we do have a "<default>" tag that works pretty much the same way as a format tag, except that for images it will always expect an image name or path. Although you could use the same trick to target the image class and change it as needed if you use the <data> tag instead of the image tag (not recommended by staff).

        Loading editor
    • Alfwyn wrote: It would be nice to be able to use <format> tags inside of <image> tags. That makes it easy to mix images (we used to display small icons at the top right corner of the main image) and imposing a maximum height on irregular sized images would be easy via something like <image source="image"><format>[[File:{{{image}}}|240x250px]]</format></image>.

      To add the max-height, just add this to CSS:

       .pi-image-thumbnail {
          max-width:240px;
          max-height:250px;
      }

      Or whatever values you wish to add.

      But yeah, being able to put multiple images together would be a plus.

        Loading editor
    • .pi-theme-disney .pi-data:nth-child(2) {
          background-color: green;
      }

      Yeah, that's the counting approach. But as soon as someone adds another field, who hasn't read the css code residing at a totally different location, things break down. That is what I meant by fragile, being able to assign a class name directly would be more robust.

      I can do something like

      <data source="foo">
          <format><div class="bar">{{{foo}}}</div></format>
      </data>

      when I'd wish I could just use

      <data source="foo" class="bar"/>

      And the approach does not work at all with image tags at the moment. At the image fotmatting/combining front I currently find myself using data/format tags to do stuff with images (probably not recommended by staff at all) and it feels like fighting against PIs. So I'm looking for a cleaner way.




       .pi-image-thumbnail {
          max-width:240px;
          max-height:250px;
      }

      Oh, I tried ".pi-image", which did nothing. But using this css, an originally 206×366px image gets resized out of proportion to 206x250px. While [[File:Myimage.png|240x250px]] does a bit of wikimedia magic and fits the image into a 240x250px box honoring it's proportions - a 140x250px image is the result. Probably the answer will be reuploading the images as square versions, but it is a question of finding all the images suddenly misbehaving.

      Anyway, thanks for the replies so far, they give me something to think about and try.

        Loading editor
    • I recently stumbled across the fact that captions don't work in conjunction with tabbers. I was able to work around it by just using data below the image, but it's kind of a cheap way of working around it. Are the developers aware of this?

        Loading editor
    • I reported this bug (Ticket 248044) a while ago.

        Loading editor
    • Well, <caption> doesn't and won't work with tabbers, but this does.

      <gallery>
      {{{Image1}}}|{{{Image1Caption}}}
      {{{Image2}}}|{{{Image2Caption}}}
      </gallery>
        Loading editor
    • FishTank wrote: Well, <caption> doesn't and won't work with tabbers, but this does.

      <gallery>
      {{{Image1}}}|{{{Image1Caption}}}
      {{{Image2}}}|{{{Image2Caption}}}
      </gallery>

      ...No? The "caption" is the equivalent of the tabber title.

        Loading editor
    • I wish you would fix your reporting system in Insights so it would stop telling me that my pages have no images just because the images are inside a template. On one wiki, I added a default image to my infoboxes and, page by page, got a message about how much better the page looked with an image; the "pages without images" count was decremented. After the next sweep, the page count and I were back where we started. Most of my work is on wikis about novels and they don't feature a lot of images.

        Loading editor
    • Gaarmyvet wrote: I wish you would fix your reporting system in Insights so it would stop telling me that my pages have no images just because the images are inside a template. On one wiki, I added a default image to my infoboxes and, page by page, got a message about how much better the page looked with an image; the "pages without images" count was decremented. After the next sweep, the page count and I were back where we started. Most of my work is on wikis about novels and they don't feature a lot of images.

      Yeah, I get a notice about a page not having an image (even though it does, inside a portable infobox, mind you), I go to the page, change nothing, press the publish button, and Wikia congratulates me. Next day, it appears in insights again.

      I also seem to have a problem of it complaining about a non-existent template being an unconverted infobox with no pages linking to it. Hmm.

        Loading editor
    • I just noticed that someone else has complained about Insights reporting redirect pages as not having an infobox. I wonder if anyone at Wikia understands that having a bunch of pages that basically have noting wrong with them on the "gig list" only serves to hide the pages that really need attention. Management at Wikia should ask the programmer who coded Insights if he/she likes his/her job.

        Loading editor
    • Insights leverages a core infrastructure of special report pages built by MediaWiki developers. So it will obviously have some of the same shortcomings that that infrastructure has. Issues with images inside templates are caused by MediaWiki core partly because the image is not really in the page, it is in the template namespace and it only "appears" as if it is there. 

      The insights tool mainly serves to give an insight into possible actions that users can take, and to  show how the wikia is doing in terms of maintenance tasks. For example, popular pages are only affected by readers, and editors are limited in what they can do to make them more popular. For infoboxes, the tool is merely showing pages that may need them. 

      While some of these insights may be improved, in some cases it may require considerable infrastructure changes which may break someone's favorite report. Ultimately if people want "perfect" reports then the only conceivable way of getting them is writing scripts  on their own to get them because much like everything perfection is relative.

        Loading editor
    • Well, if you can pull a list of pages that don't have an infobox and I know you can (Insights) and if you can pull a list of redirects and I know you can (redirects show in italics in ALL PAGES) then show me A minus B. Whose "favorite report" are you talking about?

      I don't really know your schema or I'd try to write the code, not that it would do me any good.

      If the Insights leveraging is a Wikia product, then leverage it so it works for the greatest number of people. I'm having trouble getting past the idea that everything Wikia is doing is based on making wikis look good to the casual user instead of making it easier for those of us who labor to keep the wheels from falling off.

        Loading editor
    • Having your software make lists of pages that may need work doesn't mean it can't be "smart" about it. For instance, redirects are pages that will never, regardless of circumstances, need infoboxes. While wikia functionality and feature usage is rarely this black-and-white, this is a rare example of a usage pattern that is, so it would be helpful to filter out such pages that could never so much as possibly need to have an infobox template on them from the list of pages that need work done to them via adding an infobox template to them.

      I don't know how the code works for sorting pages into insights, but this seems like it should be a simple fix. Something like, if (not (((page) transcludes template with type (infobox)) or ((page) is redirect)))) then add (page) to list (needs infobox)

        Loading editor
    • Ylimegirl wrote:

      Gaarmyvet wrote: I wish you would fix your reporting system in Insights so it would stop telling me that my pages have no images just because the images are inside a template. On one wiki, I added a default image to my infoboxes and, page by page, got a message about how much better the page looked with an image; the "pages without images" count was decremented. After the next sweep, the page count and I were back where we started. Most of my work is on wikis about novels and they don't feature a lot of images.

      Yeah, I get a notice about a page not having an image (even though it does, inside a portable infobox, mind you), I go to the page, change nothing, press the publish button, and Wikia congratulates me. Next day, it appears in insights again.

      I also seem to have a problem of it complaining about a non-existent template being an unconverted infobox with no pages linking to it. Hmm.

      To address this, I'm going to clarify that the Insights parser does not update the data that it looks at every day. The cache (for those of you familiar with the term) is on a 72 hour cycle, because it has to crunch the text and data from every article on hundreds of thousands of wikias. So, be patient with it. The same is true of the images "not appearing"; they will on the next cycle but it's not in realtime. I know that can be very confusing. 

        Loading editor
    • Gaarmyvet wrote:
      Well, if you can pull a list of pages that don't have an infobox and I know you can (Insights) and if you can pull a list of redirects and I know you can (redirects show in italics in ALL PAGES) then show me A minus B. Whose "favorite report" are you talking about?

      I don't really know your schema or I'd try to write the code, not that it would do me any good.

      If the Insights leveraging is a Wikia product, then leverage it so it works for the greatest number of people. I'm having trouble getting past the idea that everything Wikia is doing is based on making wikis look good to the casual user instead of making it easier for those of us who labor to keep the wheels from falling off.

      If you know how to use javascript, then it is quite easy to generate numerous reports using the Mw:API:Query api. It is also possible to produce the reports that you want by changing and filtering the results. In fact, I've been using a slightly modified report script created by User:452 called [Maintenance] that generates custom daily reports that are easier to manage.

      Changing the defaults can mean very time consuming and inefficient queries. For example, Lyrics wikia has more than a million pages, and if each of those contains something that needs to be reported, that's a considerable issue processing that many pages so many times. In fact, it is highly likely that some reports are deactivated on some wikis because of the effect on the servers (e.g. English wikipedia).

      Anyway, as far as infoboxes, images and insights are concerned. Images from templates are also sometimes not useful to include in the reports because some wikis do include images in their stub or "notice" templates that aren't related to the article and not useful  for readers.

        Loading editor
    • Dessamator wrote: If you know how to use javascript, then it is quite easy to generate numerous reports using the Mw:API:Query api. It is also possible to produce the reports that you want by changing and filtering the results. In fact, I've been using a slightly modified report script created by User:452 called [Maintenance] that generates custom daily reports that are easier to manage.

      Changing the defaults can mean very time consuming and inefficient queries. For example, Lyrics wikia has more than a million pages, and if each of those contains something that needs to be reported, that's a considerable issue processing that many pages so many times. In fact, it is highly likely that some reports are deactivated on some wikis because of the effect on the servers (e.g. English wikipedia).

      Anyway, as far as infoboxes, images and insights are concerned. Images from templates are also sometimes not useful to include in the reports because some wikis do include images in their stub or "notice" templates that aren't related to the article and not useful  for readers.

      But since we now have the ability to categorize templates by type, shouldn't we be able to use that so that we'd be able to acknowledge infobox images as images on the article, but images from other types of templates as not actual images?

        Loading editor
    • You have not converted a man because you have silenced him. But I give up trying to get Wikia to do anything to help us.

        Loading editor
    • Actually it could be worse for images coming from portable infoboxes because the syntax used for them doesn't include the square brackets "[[ " so they really wouldn't normally generate the normal image report in any case. Although, it seems that the infobox tag function does forcibly cause those reports, see here.

      So yes, they could theoretically exclude these from the report. It is actually a good idea to send to S:C.

      Edit: The only drawback I can think of is that it will be a very inneficient way of checking the pages. So it may place considerable load on the servers because not all infoboxes have images. 

      One script that could be adapted for insights is [[1]]. But again it is not particularly efficient.

        Loading editor
    • Ducksoup wrote:

      Ducksoup 
      Dessamator: that's a great point. Sometimes it takes a bit to adopt a wikia, and only having the choice to use the default skin wouldn't be sufficient. Once we have a set of standards in place - something that can be replicated and modified reasonably simply - I'll put it on dev.wikia.com.

      Source: Thread:841717#173

      Any news on this?

      I accidentally discovered that there is already some data stored about infoboxes that can be retrieved using the mw:API and added it to w:c:dev:Portable Infoboxes. I know this could have gone to w:c:p, but perhaps it is better to wait until there is an official API for this, if ever...

        Loading editor
    • Probably best.

        Loading editor
    • Is there a way to get the "except when all are empty" on show="incomplete" to also ignore default values?

      I'm creating a template for the LoL Wiki where different types of abilities have different fields. When there's no default values, the "groups" of fields are hidden as expected. However, I want default "N/A" icons to appear in empty fields when the group is drawn (i.e. one value is intentionally present) - but I can't add defaults to switch statements, and the moment I add a default to the field it draws the whole group.

      The basic layout is:

      • Group1
        • Feature1
        • Feature2
        • Feature3
      • Group2
        • Feature4
        • Feature5
        • Feature6

      So by default I want both groups to be hidden. When the group is called, I want all the feature's default icons to be present (but at the moment, only labels are). The icons change based on the entry (e.g. True, False and Partly) - so I can't just put the icon in the label instead.

        Loading editor
    • Emptylord wrote:
      Is there a way to get the "except when all are empty" on show="incomplete" to also ignore default values?

      I'm creating a template for the LoL Wiki where different types of abilities have different fields. When there's no default values, the "groups" of fields are hidden as expected. However, I want default "N/A" icons to appear in empty fields (as a default "no", so to speak) - but the moment I add a "default", the groups stop being hidden.

      Well, that rather goes with the point: either it's a default (to fill an empty value) or it's an empty value. What you're asking is for the group to be hidden if it's only full of defaults and no values?

        Loading editor
    • I guess, yes, I want the group to be hidden if it's only full of defaults. I'm not sure I agree with the analysis that it's pointless. In my opinion, "default" data is incomplete since it's not specified. The user-defined "false" is not the same as the default "N/A", "TBA" or "Missing". If all are "default" then they are all incomplete, and thus should be hidden. Or, at least, that is how I would like it to function/am requesting how to produce this functionality.

        Loading editor
    • We can consider that in the future, but I think it's a fairly edge use case. Depending on how many fields are absent (before it gets cumbersome), you might be able to simulate that effect with ParserFunctions inside <default>. However, I'd more likely you suggest how meaningful (or not) a default of "N/A" is. Is the absence of a value conveying useful information to the reader? If the values are indeed absent, would it not provide more straightforward information to have them not appear at all?

      Obviously, this is on a case-by-case basis. However, re-organizing for portability might lead you to question basic infobox assumptions and whether you are providing too much information. Remember that it's meant to be a summary. This blog post may give some insight. 

        Loading editor
    • Putting parser functions inside of default will not achieve my desired function of hiding the group when all are default - since the group will be visible so long as default is apparently.

      Particularly in games, there's generally assumed consistency between abilities of a certain type. "Mobility" for example, is a certain type of ability. A feature of mobility appearing as "N/A" is information in of itself, but a non-mobility ability does not need to see all of mobility's N/A features.

      The main point is I'm trying to make the information visually pleasing. Without defaults, "show=incomplete" generates the titles of all fields only when needed - but the boxes underneath are empty. This doesn't look pleasing when there's a grid of icons. I was only using "default" to format the empty box. An alternative solution to this "niche"/"edge" case would be to have show="incomplete" still "format" the empty boxes... but the help article for Infoboxes specifically states that "It would not make sense to test for the empty string in the switch statement; e.g., |=(unknown rank), because that is already covered by the default tag."

      Group1 Label Label Label
      Icon Icon Icon
      Group2 Label Label Label
      Icon Icon

      (Where the empty box is incomplete.)

      I want the groups to be hidden when there's no input. However, I want all the fields to be formatted correctly when the group is shown - and, at the moment, there's one empty box because it doesn't format empty boxes (because a switch's "#default=" is ignored). But if I add a variable default, it shows the group at all times.

        Loading editor
    • Emptylord wrote:
      Putting parser functions inside of default will not achieve my desired function of hiding the group when all are default - since the group will be visible so long as default is apparently.

      However, if the default has no value (ie. if it has a length of 0), it will not be triggered, and therefore will not show the group.

        Loading editor
    • I think the main problem I have is:

      "It would not make sense to test for the empty string in the switch statement; e.g., |=(unknown rank), because that is already covered by the default tag."

      Because I do not think that a formatting default is the same as a variable default. And this is the logic of your counter-argument to my issue: there is no sense to hiding groups with "default values". You are correct. However, what I want/need is the ability to have default formatting.

        Loading editor
    • In fact, I have encountered this issue many times before. "Default" is not formatted. I think it should be. The intent of "default" should be variable inputs - i.e. a default value. The "default" should still be formatted. At present you have to duplicate formatting in the default field to have the default visually match the other information - and this isn't an edge case, and doesn't make sense.

      If this were the case, my request is simply that show="incomplete" formats all fields - even those that are empty.

        Loading editor
    • Emptylord wrote:
      I think the main problem I have is::"It would not make sense to test for the empty string in the switch statement; e.g., |=(unknown rank), because that is already covered by the default tag."

      Because I do not think that a formatting default is the same as a variable default. And this is the logic of your counter-argument to my issue: there is no sense to hiding groups with "default values". You are correct. However, what I want/need is the ability to have default formatting.

      Therein lies the issue. Formatting a default differently than a non-default value (or layout based thereof) would be against the principles of portability, as content should not define presentation. Rigid grid layouts are not a great fit for Portable Infoboxes as a result, because the content should not be able to dictate the container. However, that's an idealist way of thinking. In more practical terms, grid layouts aren't always great portably because you can't guarantee whatever is reading it can interpret the grid (the term layout is the dead giveaway there). The device on the other end may be a screen reader, or a computer system interpreting the data. Even mobile devices don't do well with grids (even small ones), which is why Navboxes are also difficult to do well on mobile.

      Anything having to do with presentation (like layout) should be CSS centric instead. There is a CSS selector called :empty (as in .pi-data-value:empty {})  that you might try. You can even use a background image on those empty cells to simulate a blank value. In conjunction with show="incomplete" and omitting default values, that may get you closer to what you're looking for.

      In other words, replace your placeholder "N/A" with CSS styling, don't use <default> for that, and the effect should be comparable or identical to what you're looking for. 

        Loading editor
    • FishTank wrote: Therein lies the issue. Formatting a default differently than a non-default value (or layout based thereof) would be against the principles of portability, as content should not define presentation.

      Ummm, I think you missed the point of my latest/revised complaint. Default currently isn't formatted.

      That is to say, <default>Bananas</default><format><span style="color:Green">{{{favouritefruit}}}</format> doesn't produce Bananas. At the moment, default is unformatted.

      In other words: the current system already formats default differently, by default, because it currently doesn't format the default (meaning editors have to manually duplicate formatting into the default field).

      The fact that content-specific formatting is already possible and that I'm using it is beside the point of this complaint. However, the fact that default isn't formatted is causing my issue. What I basically want is all my fields to have Coloured Square Formatting (and I'm committing a faux pas of having different colors depending on the content, naughty me) - but, at the moment, default isn't formatted! And me putting the formatting into the default field is considered a default value.

        Loading editor
    • You're right, I did miss that. And I recall that there is a reason why <default> does not apply <format>, but I can't remember off-hand what the design rationale was. I can ask and get back to you — probably back over on the Portability Hub and not this year-old thread. However, the implementation is not likely to change, given the current state of the product.

        Loading editor
    • Emptylord wrote:

      That is to say, <default>Bananas</default><format><span style="color:Green">{{{favouritefruit}}}</format> doesn't produce Bananas. At the moment, default is unformatted.

      ... but, at the moment, default isn't formatted!

      Note the closing tags, which should of informed you of why that wouldn't work. Create a class in CSS for the desired 'default tag' color.

      Specify the "class" in desired default tags. You should be able to do the same for format tags. If color variations are needed use 'if' parser in the formatted tag or predefine before element and pass via {{{}}}.

      If you desire to vary the default tag color youll need to parser the variables before the element and pass with value in {{{}}}.

        Loading editor
    • Yes, I missed a /span in my rushed example but that is beside the point really. And I don't want colours, colours was a simplified example that allowed my to demonstrate it without uploads or specific information. The intent is informative icons (which could still be implemented via css, I digress). However I do not want to use default - using default prevents empty groups from being hidden. I just want all fields to be formatted when they're not hidden - ie have an N/A image.

      Although you've inspired a solution. I'm skeptical that it'll work, but I wonder if empty fields still have he appropriate tags for css to add a background image...

        Loading editor
    • my point was defalt tag was closed, before the format tag, the color change cant effect outside code flow.

      default content is generated from a coded conditional result 'this or that'. In effect a placeholder if no data condition exists.

      Class declaration should work for empty <img> tag and wont interfere with none classed images. last part of most parsers are for this type of use ie to catch an unhandled evaluation.

      study 'ifexist' or similar parsers at Wikipedia/Wikimedia. Classes may not even be needed for your purpose. You don't seem to want default but an alternative to an empty data field.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message