The buttons do work now, they just need to be styled a bit for the mobile skin.
Also there is a minor bug in the codeselect JS on mobile because the JS gets loaded a a module, so the SelectText function is not in global namespace.
[Edit]
to fix the codeselect namespace issue:
change in MediaWiki:Mobile.js - Whonix the line
function SelectText(element) {
to
window.SelectText = function (element) {
and add a ; after the closing }
Yes, that’s right, also checked that it works now.
[Edit]
I’ve also finished a simple style for the buttons on mobile now:
(in MediaWiki:Mobile.css - Whonix )
.btn-group {
font-size: 0;
}
.btn {
border: 1px solid black;
padding: 0.5em;
display: inline-block;
text-align: center;
vertical-align: middle;
font-size: 14px;
line-height: 1;
margin-bottom: 10px;
}
.btn-group > .btn + .btn {
margin-left: -1px;
}
.btn.active {
background-color: #ddd;
}
One.
Two.
Two more contributions, appreciated!
Please regard what I just now added as a new chapter “Forum Post Editing Best Practices” on a new wiki page Kicksecure Forums Usage Instructions, Best Practices and FAQ. (I’ll extend this wiki page soon later with other unrelated stuff.)
Added;
MediaWiki:Mobile.css: Difference between revisions - Whonix
I like the mobile style!
The table of contents is broken on the mobile version now. Any idea why that is? On a different page it is still working.
The mobile version with javascript disabled does not work yet. It shows non-styled javascript buttons that do not work.
The desktop version with javascript disabled has a minor issue. The text Short version: and Detailed version: cannot be selected by mice so it cannot be easily copied and pasted.
I’ll keep that in mind for the future.
If you mean the grey “Contents”-button that expands if you click on it: that one has moved between the content and Licence section on Control and Monitor Tor . That happens already in the HTML code, probably because the template engine doesn’t like the original position. I could move the button up with JS but I can’t fix it for non-JS browsers.
I’m afraid by now that this is impossible, I just figured out that the mobile.css gets injected via javascript, so without JS enabled on mobile our custom CSS won’t get loaded.
That’s because the text gets added via CSS. To change that:
Change the following block in MediaWiki:Mobile.css - Whonix and MediaWiki:Common.css - Whonix from:
.client-nojs .sd-short::before { content: "Short version: "; font-weight: bold; } .client-nojs .sd-detailed::before { content: "Detailed version: "; font-weight: bold; }
to:
.sd-heading { display: none; } .client-nojs .sd-heading { font-weight: bold; display: block; }
In https://www.whonix.org/wiki/Widget:Sd-start-short add <p class="sd-heading">Short version:</p> at the end
In https://www.whonix.org/wiki/Widget:Sd-end-short-start-detailed add <p class="sd-heading">Detailed version:</p> at the end
Done.
However, that minor issue persists for the desktop version.
I see. Is this to be considered a design choice / limitation of the mediawiki MobileFrontend or a upstream bug?
Yes, I meant that.
Okay, please do that.
Oh, right. I forgot its the /var/www/wiki/skins/strapping/theme.css for desktop, since the MediaWiki:Common.css - Whonix is not used by strapping.
This seems to be a design choice (a bad one in my opinion).
Ah. I forgot this also.
Updated:
https://github.com/Whonix/www/blob/master/w/skins/strapping/theme.css
Now “short version:”, “detailed version:” is totally gone in javascript disabled version.
I see “Short version:” right above “Tor Controller” and “Detailed version:” above “Contents” when JS is disabled on desktop.
Done. Add the following to MediaWiki:Mobile.js - Whonix
$(document).ready(function () { $('div.toc-mobile.view-border-box').prependTo('.mf-section-0'); $('div.toc-mobile.view-border-box').next().prependTo('.mf-section-0'); $('div.toc-mobile.view-border-box').next().css('clear', 'both'); });
Both, firefox and chromium did not show “short version” with JS disabled.
The output of
curl https://www.whonix.org/wiki/Tor_Controller
Did not include “short version”.
The output of
curl --cookie test=yes https://www.whonix.org/wiki/Tor_Controller
Did include “short version”. (Sending a cookie circumvents caching.)
So it was a caching related issue.
Note to self:
sudo service apache2 restart && sudo service varnish restart is required (none of this is ideal, should not be required if caching and purging was bug free)Text “short version” can now be copied. Yay!
Added:
MediaWiki:Mobile.js: Difference between revisions - Whonix
It’s not working. (And this time hopefully not a caching related issue since login cookie is set.)
There is a new bug now. Not sure related to the changes made during this thread or a new bug in mediawiki. (Desktop version) After editing and saving a page, often on the left side there is no white space. Does that sound possible?
Unless there are better suggestions, let’s go for the Recommended / Alternatives button labels and concept.
Can we have anchored links such as Control and Monitor Tor and Control and Monitor Tor please? Would there be JS-on vs JS-off related quirks?
On some pages I would like to write something like:
This was the recommended version of this page. For more, see alternatives.
Maybe it’s a race condition, because it works when run manually via console.
Try replacing $(document).ready( with $(window).load( which will get executed a bit later.
Seems unrelated to me, but it wouldn’t be the first time MediaWiki surprises me. Any way to reproduce this?
There has to be an HTML-element with the attribute id="Recommended" inside the section that would be targeted. I’m not sure if we can use the <p class="sd-heading">Recommended:</p> element we just added because it will be hidden if JS is enabled, so auto-scrolling to the anchor might not work. Aside from that there shouldn’t be any JS-on vs JS-off related quirks.
Or you can just set the link target to the first anchor in the section, that would work without any changes.
For example:
This was the recommended version of this page. For more, see alternatives.
Done:
MediaWiki:Mobile.js: Difference between revisions - Whonix
Does not work for me.
I get back to it when I find a way as I am failing to willingly reproduce it at the moment.
Perhaps also stable (always some anchors, #recommended #alternatives) links can be used? Because then it gets simpler to use this by using a template.
I was wondering if this can be implemented within the templates and simple anchor links alone. Partially works.
https://www.whonix.org/wiki/Template:Sd-start-short
{{Anchor|Recommended}}
{{#widget:Sd-start-short}}
This was the [[#Recommended|recommended]] version of this page. For more, see [[#Alternatives|alternatives]].
The recommended link already works nicely. (I wanted to jump above the recommended / alternatives button.) The alternative link already works but the issue is it jumps below the recommended / alternatives buttons. Do you think this can be fixed?
https://www.whonix.org/wiki/Template:Sd-end-short-start-detailed
{{#widget:Sd-end-short-start-detailed}}
{{Anchor|Alternatives}}
This was the [[#Alternatives|alternative]] version of this page. For the recommend version, see [[#Recommended|recommended]].
recommended link is broken.alternative link already works but the issue is it jumps below the recommended / alternatives buttons. Do you think this can be fixed?)Yes, that’s no problem, requires just a dummy element like <span id="recommended"></span> in the widget. (which is the same what you already have tried using {{Anchor|Recommended}})
Yes, I can fix that.
That is because the anchor is outside of the corresponding section. You just jump to the anchor but don’t switch tabs.
To fix the anchors, switch these lines in https://www.whonix.org/wiki/Template:Sd-start-short
And change in MediaWiki:Mobile.js - Whonix and MediaWiki:Common.js - Whonix the following lines from:
// watch window for change to expand tabs for fragments later $(window).on('hashchange', (function () { if (hash === window.location.hash) { return; } hash = window.location.hash; sdJump($(hash)); })); // make fragment links work $('a[href]').filter(function (i, e) { return $(e).attr('href')[0] === '#'; }).on('click', function () { sdJump($(this).attr('href')); });
to:
// watch window for change to expand tabs for fragments later $(window).on('hashchange', (function () { if (hash === window.location.hash) { return; } hash = window.location.hash; switch (hash) { case "#Alternatives": return sdShowDetailed($('.sd-container')); case "#Recommended": return sdShowShort($('.sd-container')); default : return sdJump($(hash)); } })); // make fragment links work $('a[href]').filter(function (i, e) { return $(e).attr('href')[0] === '#'; }).on('click', function () { sdJump($(this).attr('href')); }); // move anchors $('.sd-container #Recommended, .sd-container #Alternatives').prependTo('.sd-container');
Note: I use “fragment” and “anchor” interchangeably
Switched.
Done.
It works quite well. This is very good already. Minor issue: the no-JS version jumps below recommended / alternatives text rather than above that text.
Can you please add link/anchors to the actual buttons recommended / alternatives? That gets visible when hovering over the buttons by mice and going to the actual anchor when clicking these? [and also links/anchors for the no-JS text recommended / alternatives?]
Can you style the following text please? Perhaps a border around it and perhaps making the links look like the above buttons? (I guess this texts can be added to the templates.)
This was the [[#Recommended|recommended]] version of this page. For more, see [[#Alternatives|alternatives]].
This was the [[#Alternatives|alternative]] version of this page. For the recommend version, see [[#Recommended|recommended]].
I’m late but I read the thread to get up to speed.
I think the aesthetics of the expansion buttons are less important than
what you stand to gain from changing the underlying wiki platform. Its
best if you focus on that instead and keep things as they are with
expand buttons. The amount of bugs you keep running into will make this
solution unmaintainable in the future and put off new users who see
broken pages. They will likely just leave without telling us why.
I don’t think this new feature should be justified by the effort already invested - that’s a sunken cost fallacy. ( I’m still thankful for those who put in the effort)
However if you choose to stick with this here are other points:
recommended / alternatives sounds very confusing. Suggests that the
details about the topic is a completely different type of information
than what is shown. Subconciously suggests the hidden text is not up to
standard of the snippet shown.
The single button solution for short/long versions of a page is
disorienting because I have no visible marker of what new information
becomes visible (if any) for some section. I don’t want to re-read the
entire page to see what relevant information I may be missing.
Don’t hide the footnotes in the short versions - they may be very
important and someting we want the user to be aware about. For example
references to research papers to show claims are substantiated.
This solution looks very fragile. I don’t think you should do heavy
changes yet when it might all break when you move away from mediawiki. A
replacement wiki that produces simple offline documentation possible
should be a priority IMHO.
JS seems inevitable though the alternatives are worse. As long as it
works with Noscript on Orfox and TBB its ok.
How do you like these Recommended / Alternatives buttons? Should we start using them on other pages as well?
This is still working. Example and only page where we are using this:
Note the buttons on top:
Recommended/Alternatives
And the infobox on bottom:
This was the recommended version of this page. For more, see alternatives.