Currently, it has become an exercise in futility trying to remove inline styling from some wikis without requesting staff to outright disable the classic editor because ignorant editors will happily use it to add new content. The greatest offender is the table builder / editor which generates a lot of pointless inline styling.
299Pages
ALL POSTS
All posts by
Sure, any class or inline styling is stripped on mobile. So a simple way to get the views different is simply to add a class to whatever you need and style it using site-wide CSS.
(edited by Dessamator)
I see. Lua can detect that pattern. Basically it can find any text within a string and extract text :
http://dev.wikia.com/wiki/Lua_templating/Converting_Wikitext_templates#Extracting_text
Although if you prefer to use prev, then I guess you have your solution?
(edited by Dessamator)
Tupka217 wrote:
Not all of them have the same title format, but 90% do. So for the 10% that don't, wouldn't adding a {{{prev}}} fix that? Or would it still give an expr error?
Not all of them have the same title format, but 90% do. So for the 10% that don't, wouldn't adding a {{{prev}}} fix that? Or would it still give an expr error?
Yes prev would fix the expr errors which will show on the "10% articles", although it isn't really necessary with LUA, unless they are completely random.
(edited by Dessamator)
Tupka217 wrote:
This wiki could use some more beginner-level manuals and how-tos.
People often complain that there should be more beginner level manuals and how-tos. After they are taught how to do it they then don't contribute to the documentation and the vicious cycle continues when another newbie has the same problem later on.
So as old saying goes, it is a wiki, improve it!
(edited by Dessamator)
I guess that should also work. Assuming that all your articles follow the same title format.
P.S. I added that grunt example, so it must be GOOD!
(edited by Dessamator)
> So use separate modules? How do you fold an invoke into the PI markup exactly?
Hmm, you use invokes the same way as you do any parser function. See Help:Lua, Help:Infoboxes#Parser_functions for more info.
> So I've got to override <data source="prev"> and put in an {{#invoke:seriesinfo|main}} (or rather, {{#invoke:prev|t}}) (and do something similar for "next"). How do you do that? Format?
That syntax is incorrect, see Lua_templating/Basics. You need to use the format I showed above.
> This wiki could use some more beginner-level manuals and how-tos.
It has lots. But lua is not really a part of portability, although it can help. Guides on using lua are generally beyond the scope of this wiki. There are plenty of guides in w:c:dev:Lua templating, wikiversity, wikipedia, etc ...
(edited by Dessamator)
It is a bit of a balancing act. It might sometimes be preferable to have an inefficient wikitext template that you can maintain than something with lua that you can't. Although, most complicated string functions require considerable hacks.
Changing this to wikitext might be possible, but the results won't be pretty. The code above adapts to any title, no matter how many words it has. The equivalent in wikitext would either require you to add extra parser functions (or transclusions) for each extra word.
(edited by Dessamator)
Twice in one day, you must be stalking me :).
Something like this should work:
--Module:Seriesinfo local p = {} function p.main(frame) local prev = frame.args.prev local title = frame.args.t return getSeriesInfo(prev, title) end function getSeriesInfo(prev, seriesTitle ) local pagename = tostring(mw.title.getCurrentTitle()) local titleParts = mw.text.split( pagename, " ") if prev then return "[["..prev .."]]" else local lastPart = tonumber(#titleParts) if seriesTitle and lastPart and tonumber(titleParts[lastPart]) then return "[[" .. seriesTitle .. " " .. (titleParts[lastPart] - 1) .. "]]" end end end return p
Template:seriesinfo
{{#invoke:seriesinfo|main}}
{{seriesinfo|prev= babab | t = seriestitle}}
Note: This was a quick hack, and I haven't really tested it all that well.
(edited by Dessamator)
> Stability - We've been caught too many times by changes that broke various parts of the wiki.
This is rather a chicken or egg problem. Stability will only happen once wikia stops all development of the portable infobox.
> Multiple entities per page - Some wikis use switch infoboxes, of varying complexity. Some of them just swap images, other have a more complex setup.
I think this is the case of wanting to display too much content on a small area. Anyway, Collapsing basically allows this. The only thing missing is different layouts for "collapsed" content.
>Custom attributes and classes - It's reasonable to want to have a stable API for everyone to use. Extending this to cover use of attributes within XML is equally understandable. What's not understandable, is why the ability to add arbitrary classes has been removed.
This is a valid concern, although FINALLY the templatestyles (see mw:Extension:Templatestyles) seem to be close to concluding their development (possibly by the end of the year or next year), and this may reduce / eliminate the need for any specific inline css if wikia finds it a good idea to deploy this.
(edited by Dessamator)
At any given time wikia runs a lot of A/B tests that change how the interface looks or behaves. So the assumption that what you see on a particular page, is what everybody sees is a wrong one. As such it is always good to provide as much information as possible so other people can assess the issue.
Anyway, feel free to report it, as I see the same as you do.
(edited by Dessamator)
Your complaint lacks a lot of information (e.g. operating system, device, link to wiki, etc). If you think it is a bug, please follow the instructions from here or Help:How_to_report_bugs . If not, then I can only say that your suggestion has already been noted by staff because they do watch that page.
Otherwise, you can submit it through Special:Contact.
(edited by Dessamator)
Kirkburn wrote:
Just to confirm - we're aware of this issue, and the technical team has been asked to look into what's causing it.
Just to confirm - we're aware of this issue, and the technical team has been asked to look into what's causing it.
I found this while browsing a wiki:
http://fairytail.wikia.com/wiki/Special:Insights/nonportableinfoboxes
http://fairytail.wikia.com/wiki/User:Gauzz_Rifle/FanonInfoboxFT?insights=nonportableinfoboxes
I guess the bug is back?
(edited by Dessamator)
The default tag[1] is very similar to the format tag, and is a less hacky solution that can be used in this case:
<image>
<default>{{{name}}}.gif</default>
</image>
(edited by Dessamator)
A-06 wrote:
Is this officially fixed now? I just noticed our Insights page is cleared and it seems to be the case on the other wikis listed earlier in the thread.
Is this officially fixed now? I just noticed our Insights page is cleared and it seems to be the case on the other wikis listed earlier in the thread.
Yes, seems like it.
(edited by Dessamator)
Kirkburn wrote:
Just to confirm - we're aware of this issue, and the technical team has been asked to look into what's causing it.
Just to confirm - we're aware of this issue, and the technical team has been asked to look into what's causing it.
It is clear that this is being caused by some interaction between the login process and editing.
Another example:
(edited by Dessamator)
Yes, it is a known bug, feel free to report to staff Special:Contact/bug:
This is a duplicate report of this bug, so I'm closing this thread, you can continue the discussion in Template: appearing on the Insights page.
(edited by Dessamator)
Yes, it is a known bug. It has happened to me as well. In my case it was caused by my anonymous bot trying to login to do something in the wiki. It might be caused by a malfunctioning script or some MediaWiki bug.
I reported it to staff, but my guess is that they misunderstood the bug. But I suggest you also report (Special:contact/bug) it so they become aware that this is happening in more wikis.
(edited by Dessamator)