User talk:Saftzie/Archive02

ShoutWiki — express yourself and be heard!
Jump to navigation Jump to search
Replacement filing cabinet.svg
This page is an archive. Please do not edit its contents.
Direct any additional comments to the current talk page or contact a staff member for aid if no talk page exists.



Abuse Filter. Are there any timing options for creating user pages?[edit source]

See my previous posts here:

I looked at mw:Extension:AbuseFilter

I looked at some of the documentation, and I am overwhelmed by the technical difficulty.

Looking at my original posts do you see any way to implement my ideas concerning wait periods before new users can post links on their user pages? --Timeshifter (talk) 15:08, 17 February 2019 (UTC)

The mw page on the extension is information on how to install the extension, which is already installed on your wiki. You should find the subpage mw:Extension:AbuseFilter/Rules format more useful in creating rules on s:w:cannabis:Special:AbuseFilter. You can look at the public filters on this wiki and on Wikipedia if you need to see some examples of how to write rules. Note that the only existing rule on your wiki will not do what Lcawte apparently thought it would because of syntax errors.
In addition, unless a rule implements a simple, public policy, I suggest making the rule hidden. Otherwise you're just giving spammers a recipe for how to get around your rules. FWIW, I have seen bots come back after a month or more to try to spam again, including to spam their talk pages when those are the only pages they can still edit. --Saftzie (talk) 19:49, 17 February 2019 (UTC)
I occasionally see some spam attempts on registered user names or their associated talk pages after one month of blocking, but not very often. When that happens I block them for a year.
Thanks for all the info and links. I looked at them and a few more:
Special:AbuseFilter
Special:RecentChanges
wikipedia:Special:AbuseFilter
From what I could decipher I don't see anything based on timing though. --Timeshifter (talk) 20:03, 18 February 2019 (UTC)
user_age is the number of seconds since the user registered. --Saftzie (talk) 21:21, 18 February 2019 (UTC)
There are 604,800 seconds in a week. I googled it. Could I block all addition of links to user pages from registered users who are less than a week old (or any period of time I choose)?
And would they see a notice explaining why so they are not offended if they are not spammers. --Timeshifter (talk) 00:00, 19 February 2019 (UTC) 
conditions:
article_namespace === 2
& user_age < 604800
& count( added_links ) > 0

actions:
warn, disallow
The warning text is a message you create in MediaWiki:. --Saftzie (talk) 04:34, 19 February 2019 (UTC)
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Thanks. So the code goes here?: s:w:cannabis:Special:AbuseFilter/new.

mw:Extension:AbuseFilter/Rules format says to use page_namespace instead of article_namespace since it is deprecated.
I don't understand where MediaWiki: is found. --Timeshifter (talk) 07:32, 20 February 2019 (UTC)

When you create a new filter or edit an existing one, the conditions go in the box labeled "Conditions:". The version of AbuseFilter here at ShoutWiki isn't the newest, so it would consider "page_namespace" a syntax error. MediaWiki: is a namespace, like User: or Template:. --Saftzie (talk) 03:01, 21 February 2019 (UTC)
Where do actions go? Is the disallow action one of the checkboxes under "Actions to take when matched"? Is it this one: "Prevent the user from performing the action in question"
And where exactly do I type in a warning message?
I want to warn them when blocking them from saving a user page with a link in it. --Timeshifter (talk) 20:28, 21 February 2019 (UTC)
Yes, that's the checkbox. Warning text (including any wiki markup you want) goes in a message you create in MediaWiki:, for example MediaWiki:Abusefilter-warning-6. --Saftzie (talk) 04:28, 22 February 2019 (UTC)
OK. I set up a filter, and a warning message. Not sure if I set it up right:
s:w:cannabis:Special:AbuseFilter
s:w:cannabis:Special:AbuseFilter/2
s:w:cannabis:MediaWiki:Abusefilter-warning-2
I deleted all the latest spam user pages. So we will see. --Timeshifter (talk) 21:29, 22 February 2019 (UTC)
You also need to check the box for "Trigger these actions after giving the user a warning" and specify the warning message. --Saftzie (talk) 01:35, 23 February 2019 (UTC)
Thanks. Done. I hope this works. --Timeshifter (talk) 04:45, 23 February 2019 (UTC)
One hit so far:
s:w:cannabis:Special:AbuseLog/3038
--Timeshifter (talk) 13:17, 23 February 2019 (UTC)

Derleme[edit source]

Hello, for some reason, you have deleted [[Derleme]] page that I started to work on. There is no project like "Turkish Quran" or at least I couldn't find it in ShoutWikiHub.--Kuradilammas (talk) 18:08, 24 February 2019 (UTC)

Hub is not a Turkish Quran site. If you want to create one, feel free, but such content would not go on Hub. --Saftzie (talk) 18:12, 24 February 2019 (UTC)
Thank you, so I will need to create a wiki in my private domain and hosting. Sorry that I haven't read the whole conditions, I have found here just via a Google search. --Kuradilammas (talk) 18:15, 24 February 2019 (UTC)
It was offensive and not friendly that you have blocked my username, my purpose was even not a religious propaganda.--94.134.88.75 18:55, 24 February 2019 (UTC)
You were blocked temporarily for re-creating pages that had been deleted as out-of-scope and irrelevant to this wiki. The content and nature of the irrelevancy is itself irrelevant. As I said, you can still create your own wiki if you wish. --Saftzie (talk) 17:53, 25 February 2019 (UTC)

Can I block creation of articles by IP users?[edit source]

I looked at this "Holiday Spam" filter created by Lcawte:

It seems to be working. I don't know how it works, though. I don't understand the last line in conditions:

& (article_text | added_lines ) rlike ("holiday"|"tourist")

There is also this on the "Holiday Spam" filter page:

Warning: This filter was automatically flagged as harmful. As a safety measure, the following actions will not execute (Block autopromote, Block). Please review and optimize your conditions to remove this restriction

I want to remove that "Holiday Spam" filter and create one just to block creation of articles by IP users.

Or is there a setting that a steward like me can set without having to create a filter?

I created another user name, and did some tests. When I tried to create an article I got the default warning:

Error: Warning: This action has been automatically identified as harmful. Unconstructive actions will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it. A brief description of the abuse rule which your action matched is: Holiday Spam

All the hits though for that filter are from anonymous IP editors:

I don't want to block creation of pages by registered users unless I have to. If it becomes a problem I will require a minimum number of edits first. --Timeshifter (talk) 23:02, 24 February 2019 (UTC)

Your wiki's current filter 1 has several problems.
  • The condition & (article_text | added_lines ) rlike ("holiday"|"tourist") is a big semantic error that will always evaluate to "true." You should edit the filter to remove this condition.
  • AbuseFilter has recognized that the filter has problems and refuses to perform Block autopromote and Block actions. At the very least you should uncheck the boxes that select these actions. (It appears that the filter has never blocked anyone, too, so you don't have to undo any damage from it.)
  • You could also uncheck the warning action. It's pointless for that filter. (Also, the warning text is the default message. This filter is the one that denied your test account.)
If you like, you can copy the conditions from this wiki's public filter 7 into your filter 1. You can change the title of your filter 1, too. The main thing your filter 1 has done is deny article creation by anonymous users, so you can just reuse it with better conditions and actions. --Saftzie (talk) 18:36, 25 February 2019 (UTC)
Thanks. Is there a warning message with that filter 7? --Timeshifter (talk) 04:12, 26 February 2019 (UTC)
Intentionally not. --Saftzie (talk) 19:09, 26 February 2019 (UTC)
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

mw:Extension:AbuseFilter/Rules_format

Could you translate filter 7 for me? I am having a hard time: 

article_namespace % 2 === 0
& article_namespace !== 110
& article_articleid === 0
& user_age === 0
& ! user_blocked

What is % 2 === 0

  • It is for new pages: & article_articleid === 0
  • It is for unregistered users: & user_age === 0

I assume & means all conditions must be met for the filter to activate. x & y — AND – returns true if both of the conditions are true.

!== 110? But NOT something. !x — NOT – returns true if the condition is not true.

& ! user_blocked - So this filter does not activate for blocked users? I assume this is so that other filters will block their activities and keep a record specific to blocked users? I do not understand though since this filter only activates for unregistered users. So registered users whether blocked or not are irrelevant:

user_blocked - boolean - true for blocked registered users, false for unregistered users. --Timeshifter (talk) 23:56, 26 February 2019 (UTC)

% is the modulus operator. === is "equals." !== is "not equal to." Edits of users (and IP addresses) that are already blocked will already be denied, so there's no reason to trigger the filter and log the failed edit. user_blocked is true for edits from blocked IP addresses, even if the editor is a registered user who is not blocked. --Saftzie (talk) 05:59, 27 February 2019 (UTC)
Still baffled by this: Wikipedia: Modulo operation. article_namespace % 2 === 0
& ! user_blocked - that means all blocked users including IP users? If so, then shouldn't mw:Extension:AbuseFilter/Rules format be clarified? --Timeshifter (talk) 23:40, 28 February 2019 (UTC)
% 2 returns 0 for even numbers, 1 for odd numbers. Talk pages are odd. The doc page should probably get fixed sometime.... --Saftzie (talk) 02:22, 1 March 2019 (UTC)
mw:Manual:Namespace mod 2? So I guess the page namespace of 0 is a special case? --Timeshifter (talk) 04:36, 1 March 2019 (UTC)
Namespace 0 (Main) is not a talk space, so it's not a special case. --Saftzie (talk) 05:53, 1 March 2019 (UTC)
I meant special in the sense of modulus calculation. Wikipedia: Modulo operation: "In computing, the modulo operation finds the remainder after division of one number by another (sometimes called modulus)." Zero (article namespace) divided by 2 is zero. No remainder, or zero. OK, now I see. Talk page namespace 1 divided by 2 equals 0 with remainder of 2. I see that now. I get it now. --Timeshifter (talk) 07:25, 1 March 2019 (UTC)
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

I updated filter 1:

--Timeshifter (talk) 08:09, 1 March 2019 (UTC)

I tried to clarify mw:Extension:AbuseFilter/Rules format. Not sure I did it right. I don't understand the translation notations. --Timeshifter (talk) 17:29, 1 March 2019 (UTC)

For others reading this Saftzie notified me of a MediaWiki update that has just occurred. The AbuseFilter variables article_* which were previously discussed have been deprecated at ShoutWiki. "Deprecated" means they still work, but they might be removed in a future update.

So I updated the filters at s:w:cannabis:Special:AbuseFilter according to mw:Extension:AbuseFilter/Rules format. --Timeshifter (talk) 05:21, 9 March 2019 (UTC)

Some CSS to make mobile view less narrow. Or Minerva mobile skin[edit source]

I paid to remove ads on the Cannabis Wiki for a few months. This helped a bit in making the mobile view less narrow. See:

Is there some temporary CSS I can add so that everyone viewing the cannabis wiki sees it at the maximum width of their mobile screen right away? I mean when viewing the screen with the long side of the screen parallel to the ground. Without having to pinch-zoom it. Since there are currently no ads Shoutwiki shouldn't care.

I already have some CSS added that helps better utilize the left sidebar in desktop view:

Looking at that 2019 page on a 4 inch screen on an old iphone, and comparing it on a 5 inch screen on an old Android phone, I see that the ratio of the sidebars (on both sides) to the page is the same. This is after double tapping the screen on the Android phone to get to the largest default size. Before pinch-zooming it larger.

I think this may be some kind of margin:auto percentage setting?

Media queries looks interesting:

Maybe when the left sidebar list is pushed below the content, the new content setting still has a margin:auto percent that it shouldn't have. See the above link to see examples of what should happen instead.

I see now that the URL remains the same in mobile view:

When I narrow the window in my desktop browser the left sidebar list is pushed below the content. Same as in mobile view.

The nearly-empty sandbox page linked from the left sidebar:

This is better for looking at the underlying code. Also, one sees that the blank left margin is the real problem. Blank right margin shows up on the 2019 page when there are larger images at the bottom of that 2019 page.

See CSS @media Rule at w3schools.com:

In Firefox web developer, style editor tab, I found this at line 2124 via a "navigation" search in Notepad++: 

@media screen and (min-width:982px) {
 .mw-body,
 #mw-head-base,
 #left-navigation,
 #footer {
  margin-left:11em
 }
 .mw-body {
  padding:1.25em 1.5em 1.5em 1.5em
 }
 #footer {
  padding:1.25em
 }
 #mw-panel {
  padding-left:0.5em
 }
 #p-search {
  margin-right:1em
 }
 #p-personal {
  right:1em
 }
}

I think I may be getting somewhere. But it looks like the Minerva mobile skin would be needed to deal with the left side links at the top of the page when viewed in a narrow mobile screen.

Minerva is now stable according to this:

--Timeshifter (talk) 07:10, 13 March 2019 (UTC)

So having played around quickly with something, in developer mode, if you remove your site-specific CSS entirely, your entire sidebar drops underneath the content area, in a single column style layout. Not sure what your desired layout is, but, that's always an option I suppose. Also, I'm not particularly interested in the subject of your wiki, but have you considered breaking your sidebar up into relevant sections? --Lewis Cawte (talk) ShoutWiki Staff 14:06, 13 March 2019 (UTC)
Lewis Cawte. Good idea about the headers. I found some info here: mw:Manual:Interface/Sidebar#Customize the sidebar. Thanks.
The sidebar already drops underneath the content area. That can be seen by narrowing the desktop browser window an inch at a time by dragging the right side of the browser window to the left until you see the sidebar drop down. It is based on screen width, not mobile mode, as far as I can tell.
You have to stop dragging to see it. As long as the mouse is still clicked and holding the browser side while dragging it, then the left sidebar will not drop down.
It works the same here on the talk page, on the Shoutwiki Hub Main Page, or any Cannabis Wiki page, such as its main page: s:w:cannabis:Main Page.
My added sidebar CSS does not effect this. I got some of that sidebar CSS from mw:Manual:Interface/Sidebar#Sidebar width in Vector skin (CSS). I also reduced the sidebar padding and margins. I discussed that awhile back here:
mw:Manual talk:Interface/Sidebar#Decreasing the padding and margins in the Vector sidebar.
I think the problem here, or with this current Mediawiki implementation, is that the top bar stays the same. The top bar is too long in mobile view or narrow screens. That leaves a blank space on the left below it.
--Timeshifter (talk) 12:38, 14 March 2019 (UTC)
I've just wrapped your rules in a min-width: 800px media query, so it catches pretty much any modern desktop resolution only, and everything is as good as it can possibly be expected to be with a skin that isn't built for mobile. The top bar, by which I presume you mean the Vector tabs, is working fine on my phone (a Samsung Galaxy S9) which is the only mobile device I have to hand to test. What iPhone do you have (so I can pull the resolution and do further testing)? --Lewis Cawte (talk) ShoutWiki Staff 13:07, 14 March 2019 (UTC)
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Wow. What an improvement. Thanks!! I am getting a vague understanding of this stuff:

I have an iphone 5c (4 inch screen) and a Moto G3 (5 inch screen). I hardly ever use them. They are mainly emergency phones for the car. Thus my lack of knowledge concerning cell phones and what my wiki looks like in them. I have WiFi so I can use the Moto G3 at home even though I no longer have a cell plan for it. So I can test stuff out on a larger screen too.

I may soon be getting a cell phone with a larger screen. So I am thinking that I may change the min-width to 982px since that is already a breakpoint being used in the code. See my previous comment that mentions this code: 

@media screen and (min-width:982px)

Everything looks great now. In both portrait and landscape mode on both cell phones. My previous shrinking of sidebar images helped greatly with the portrait mode on the iphone 5c. It is only 2 inches wide in portrait mode. There are still a few things I need to fix on the 2019 page so that it works on more cell phones in portrait mode. Many people only access the web with cell phones. Especially people from around the world accessing the Global Cannabis March pages.

It would be nice if I could figure out exactly what CSS I added is breaking the mobile view. Then we wouldn't need to add the new @media code. And I could put a note about all this on the talk page at mw:Manual talk:Interface/Sidebar. --Timeshifter (talk) 14:46, 14 March 2019 (UTC)

Lewis Cawte. I found the CSS that was messing things up. It came from here:
mw:Manual:Interface/Sidebar#Sidebar width in Vector skin (CSS) - This is what I removed:
div#mw-panel { width: 12em; }
div#footer, #mw-head-base, div#content { margin-left: 12em; }
#left-navigation { margin-left: 12em; }
It may be gone from that manual page by the time anybody from here looks at it. I intend to remove it to the talk page, and point out the problems it caused. I will point them to this thread.
The padding and margin CSS I added is not causing any problems:
#mw-panel { padding-left: 0; } /* Reduces sidebar padding on the left. */
div#mw-panel div.portal { margin-left: 0; margin-right: 0; } /* Reduces sidebar margins. */
div#mw-panel div.portal div.body { margin-left: 0.5em; } /* Reduces left margin of sidebar toolbox */
So I was able to remove this without problems:
@media only screen and (min-width: 982px) { }
--Timeshifter (talk) 21:25, 16 March 2019 (UTC)

How can I move show/hide toggler to left? Better for mobile browsers in portrait view[edit source]

I noticed in a narrow 2 inch screen on a cell phone in vertical portrait view that the toggler link goes out of sight to the right when some tables are expanded.

See the "examples" table with bare URLS that can't wrap. Scroll down this page until you see it:

It is nested in the collapsed table "2019 editing rights" at the top of this page just above the map:

I have been making that page more and more compatible with cell phones with narrow screens. I got rid of the image sidebar, and put the image thumbnails in their own section farther down instead. I reduced all images down to 290 pixels or less.

Long ago I put a l-em space between the toggler and the header text of collapsed tables. See:

I did some experiments today. See the history. But I am probably not doing the right thing, and/or not clearing the cache, purging correctly, etc.. I just remember that getting CSS changes to show up is difficult even if I am using the correct CSS.

I looked around at Mediawiki and Wikipedia help pages on all things collapsible. But no luck.

I figured out how to change the Expand/Collapse labels to Show/Hide labels:

This helps too, because sometimes long table headings push the toggler offscreen even before expanding the table. So the shorter show/hide labels help with that. --Timeshifter (talk) 06:51, 16 March 2019 (UTC)

There's no way I know to do it "beautifully." The collapsible control is a "float" that occurs in the HTML before the header text. You can unfloat the control with CSS, but then the control would be to the left of the text, not just to the right. For example, define and use a new class sw-collapsible-unfloated (or whatever name you like):
{| class="wikitable sw-collapsible-unfloated mw-collapsible mw-collapsed"
! colspan=2 style="text-align: left;" | Header
|-
| AAAAAAAAAAAAAAAAAAAAA || BBBBBBBBBBBBBBBBBBBB
|-
| A || B
|-
| A || B
|-
| A || B
|-
| A || B
|}
Then add something like the following CSS.
.sw-collapsible-unfloated .mw-collapsible-toggle {
	margin-right: 0.5em;
	float: none;
}
--Saftzie (talk) 02:28, 22 March 2019 (UTC)
Thanks. I found a way to put the toggler to the left of all collapsible tables. See:
s:w:cannabis:MediaWiki:Common.css 
/* === Collapsible elements. Toggle-link moved to left. === 
/* Margin around it adjusted. 
/* https://community.fandom.com/wiki/Thread:1104268
/* https://community.wikia.com/wiki/Thread:499656 
/* https://community.wikia.com/wiki/Help:Collapsing 
/* https://cannabis.wikia.com/wiki/MediaWiki:Wikia.css */

.mw-collapsible .mw-collapsible-toggle {
    float:left;
    margin-left:0;
    margin-right:1em;
}
See http://cannabis.shoutwiki.com/wiki/Moscow,_Russia - it has many collapsible tables. See the big one in the 2007 section. It has many very long bare URLs. So having the toggler to the left is sometimes the only way to close that table. Especially on cell phones. When the toggler is on the right side and is pushed offscreen by table expansion the toggler sometimes can not be reached by any means. Even by trying to drag the table to the left to be able to click the toggler to close that long table. Dragging doesn't always work.
I was using the wrong user CSS page at first for experimentation. I finally found the correct one for vector, which is the skin I use for me and the wiki:
To see the toggler on the left see any of these collapsible templates:
If you don't see it, then that means I am doing some more testing. --Timeshifter (talk) 23:31, 22 March 2019 (UTC)
At mw:Manual:Collapsible elements I added a section: "Move toggle link to the left". I learned more about syntaxhighlight too. Sorry about messing up your comment previously. I thought I had accidentally added a typo, but my "correction" was actually the mistake.
More info for others who are interested: mw:Extension:SyntaxHighlight. --Timeshifter (talk) 22:49, 23 March 2019 (UTC)
The CSS I provided above gives you the option of unfloating by including a class in the table (or not). Since the toggle is already to the left of the header text (in the HTML), you can simplify your CSS by using float: none; instead if float: left;, but your CSS applies to every collapsible on the entire wiki. --Saftzie (talk) 22:58, 23 March 2019 (UTC)
Thanks for explaining that further. My mind locks up sometimes when I try to understand the creation of CSS classes, IDs, etc.. But I think I understand now how your method of customizing control of toggle placement works. And thanks for fixing the indentation. I did not understand how to do that while at the same time using syntax highlighting.
I want the toggler to be on the left for everything on that wiki. I created all the pages on that wiki, and don't foresee a need for a toggler anywhere but on the left side. I could create a custom CSS class to put it on the right if I need to later. But I doubt that the need will arise. --Timeshifter (talk) 01:06, 24 March 2019 (UTC)

Welcome Template[edit source]

Hello! I have improved the welcome template. It has a few more helpful links, plus it has a nice colour to the template. Check it out! Tell me what you think via my talk page. MinecraftFan (talk) 14:31, 17 March 2019 (UTC)

I prefer not to use Welcome templates, since they basically just create talk page spam. --Saftzie (talk) 17:07, 17 March 2019 (UTC)
I agree with that! I think that it is much better to just write a welcome manually, rather than using a template. WikiPlants (talk) 00:49, 25 March 2019 (UTC)

Helpful[edit source]

Hi! What can I do to be helpful? That is why I am here! WikiPlants (talk) 00:53, 25 March 2019 (UTC)

How can I get people to come to my wiki? Help! How can I create a logo and a favicon? WikiPlants (talk) 00:55, 25 March 2019 (UTC)
Help:Images#Logos --Saftzie (talk) 01:00, 25 March 2019 (UTC)
Thank you! You are a life saver! WikiPlants (talk) 01:06, 25 March 2019 (UTC)
I'm starting a new wiki about Fortnite. You know what Fortnite is right? Please, come and help me with it when you have the time. Thank you in advance! WikiPlants (talk) 01:07, 25 March 2019 (UTC)
Fortnite Wiki has now been created. You can now restore the Fortnite Wiki page back. WikiPlants (talk) 01:15, 25 March 2019‎ (UTC)

Conker Wiki[edit source]

So Conker Wiki has moved to another host, seeing as i have a more personal relationship with Grifkuba, who host wikis like WiKirby, Wikibound, Fire Emblem Wiki, and Jiggywikki. Is it possible for ShoutWiki staff to redirect the domain to the new Conker wiki (as to avoid dead links and so anyone who stumbles upon the old url can find the new location)? I'll tell more when the wiki has been further set up (including spambot software prevention). Castaway2000 (talk) 20:57, 18 April 2019 (UTC)

That's a question to ask staff using s:w:conker:Special:Contact or email at troppusmoc.ikiwtuohs. --Saftzie (talk) 08:20, 19 April 2019 (UTC)
Ok, i did that this morning. How long would a reply from them take, if you had a guess? Castaway2000 (talk) 03:05, 20 April 2019 (UTC)
reason i ask is because they havent got to it yet -- i'm wonder if they ignored it or..? Castaway2000 (talk) 00:42, 23 April 2019 (UTC)
It won't be ignored, but I can't guarantee any specific time. --Saftzie (talk) 04:14, 23 April 2019 (UTC)
Yeah it's been about two months, and it appears they've not been responding to my request. feels like this place is a ghost town Castaway2000 (talk) 01:11, 17 June 2019 (UTC)
Really busy time of year, university deadlines, statuatory filings, work, volunteering and everything. I'm actually running rather late for work now by replying to this! Although I can't actually see your ticket in the queue... I should have this tattooed on my head - unless you received an auto reply with a ticket number, you've not successfully filed a ticket! --Lewis Cawte (talk) ShoutWiki Staff 05:27, 17 June 2019 (UTC)
I did send an email to the support email, man. Just please delete the wiki already, i dont want to ask another time Castaway2000 (talk) 16:40, 18 June 2019 (UTC)

Help[edit source]

Hello Saftzie. Are you from the Shoutwiki staff? Could you help me? --PERCE-NEIGE (talk) 09:21, 1 June 2019 (UTC)

I'm not staff. --Saftzie (talk) 02:11, 4 June 2019 (UTC)

Timwatson: Spam only account![edit source]

Hello, Saftzie. I have requested speedy deletion of [[User:Timwatson]]. He claims to be misusing his user page by self promoting himself and advertising his company. His account spam only. Please delete the page and block him indefinitely. Thanks! DRWindsor (talk) 13:45, 5 July 2019 (UTC)

About creation protection[edit source]

Who create-protected the page Help:Premium features? It s jut pure creation protection or in fact users don’t have permission to create help pages? —Znotch190713 (Talk Contributions) 07:55, 16 July 2019 (UTC)

Users cannot edit Help: pages at all. --Saftzie (talk) 08:48, 16 July 2019 (UTC)

Desktop view to be default in a cell phone?[edit source]

I noticed that a mobile view now shows up by default in my cell phone.

I don't like it because show/hide tables are open by default in mobile view, and can't be closed. For example, the many show/hide tables on this page:

Also, I see no way to access the rest of the wiki from mobile view. The sidebar links are not at the bottom of the page as with the desktop view on a cell phone.

Desktop view can be enabled for a page from a link at the bottom of the page. What is that link? Or how do I convert a URL like the one for Moscow from desktop view to mobile view, and vice-versa. I may be able to add the choice at the top of all the pages via an existing template at the top of all the pages on the wiki.

These are the links I find from my desktop PC:

  • http://cannabis.shoutwiki.com/w/index.php?title=Moscow,_Russia&mobileaction=toggle_view_mobile
  • http://cannabis.shoutwiki.com/w/index.php?title=Moscow,_Russia&mobileaction=toggle_view_desktop

At Wikia they have these 2 links for an older version of the Moscow page:

https://cannabis.wikia.org/wiki/Template:View_full_site creates the 2 links:

  • [{{fullurl:{{FULLPAGENAME}}|useskin=oasis}} <span style=color:blue;>'''Full site.'''</span>]
  • [{{fullurl:{{FULLPAGENAME}}|useskin=mercury}} <span style=color:blue;>'''Mobile site.'''</span>]

I will keep working on this. But is there a way to make the desktop view the default view on mobile? Then readers can start from there, and choose to go to the mobile view easily if they want to. --Timeshifter (talk) 07:59, 30 August 2019 (UTC)

I'm not a mobile user, so this answer may be incomplete. You're seeing the effect of mw:Extension:MobileFrontend. The query string ?mobileaction=toggle_view_mobile once switches the skin to Minerva, just like using the query string ?useskin=minerva on every view, but without having to use the query string on every view. The query string ?mobileaction=toggle_view_desktop once switches the skin to whatever is set in Preferences (or in the wiki config for anonymous users). Mobile views typically don't load lots of CSS or JavaScript, which is probably why collapsible features don't work in mobile. (At Wikia, they specifically don't load any CSS or JavaScript in mobile, except what comes with the skin.) The documentation on Extension:MobileFrontend appears incomplete, but I don't think there's a way to disable the extension by default, but still allow it to be enabled later by choice. --Saftzie (talk) 17:27, 30 August 2019 (UTC)
Is it possible for me to disable Minerva completely for now? Is it something I can do, or does staff have to do it? I much prefer the desktop view on mobile phones. It operates elegantly on cell phones in the way the sidebar drops down below the page to allow navigation. And since I paid to remove ads for a year there is plenty of width (no ad sidebars) to view pages on cell phones.
I still have the same 2 old mobile phones I mentioned in a previous thread. Neither has a monthly cell plan. I use them via home wifi, and so they cost me nothing to use at home for viewing the web, or using most apps. I can't make calls or send texts on one phone, the 5-inch Moto G3. The 4-inch iPhone 5c is on a Pay As You Go plan on Tello.com. It is an emergency phone for the car. I put $10 in its balance back in January 2019, and have spent less than a dollar of it; mainly to test calling and texting functions, and to keep the phone active. I have some offline Google Maps on both phones for car emergencies.
I don't think Minerva is ready for prime time yet, and would rather not deal with it for awhile. The regular desktop pages look fine on the cell phones. Unlike at Wikia, where both the desktop view and the mobile view often look bad on cell phones. Especially with all the intrusive ads. --Timeshifter (talk) 23:05, 30 August 2019 (UTC)
There is no way to disable Minerva. Supposedly MobileFrontend loads JavaScript from MediaWiki:Mobile.js, which might be a way around that. My idea would be to run a little script which checks a cookie (local storage); if it's not set, set it, switch mobile off, and reload the page. If you're any good with JS, you can try it. I probably won't get a chance until tomorrow. --Saftzie (talk) 01:11, 31 August 2019 (UTC)
I am pretty clueless about JS, except what I can copy. I have been figuring out CSS a little.
Are you saying that some JS could be set to intercept the mobile JS and stop it? --Timeshifter (talk) 15:53, 31 August 2019 (UTC)
Set s:w:cannabis:MediaWiki:Mobile.js to the following. I haven't tested it on a mobile device, but it should work.
/* Any JavaScript here is loaded instead of MediaWiki:Common.js for users using the mobile site */

/**
 * Make first mobile view switch to desktop
 * . check for localStorage capability
 * . if capable and key not found, set key and switch to desktop
 */
( function ( ) {
	'use strict';

	var
		key = 'mobileSwitch';

	if ( ( typeof Storage !== 'undefined' ) && ( localStorage[key] === null ) ) {
		localStorage[key] = '';
		location.search += ( location.search === '' ? '?' : '&' ) + 'mobileaction=toggle_view_desktop';
	}
} ( ) );
The URL manipulation is pretty rudimentary, but it should work for most cases. --Saftzie (talk) 21:00, 1 September 2019 (UTC)
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

Thanks. It does not seem to be doing anything. To make things easier for now I removed the show/hide tables from the main page:

That home page is accessible from the "Cannabis" link at the top left of all pages in mobile view on the Cannabis Wiki.

Click on "mobile view" at the bottom of that page to see an approximation of what I am seeing on my cell phones. It is incorrect in that there are no right-floated images on my cell phone. They are centered thumbnails on my cell phone. And text no longer wraps around those centered images. It messes up the format of the pages.

Also, on my cell phone there is no table of contents at all. Neither at the top nor the bottom of the page. Also, sidebar navigation is gone from all views and orientations on the cell phone.

In portrait orientation on the cell phone (in both mobile and desktop view) there is a blank right sidebar filling up to half the screen. It may be an unfilled ad sidebar.

In landscape orientation on the cell phone the page goes edge to edge (in both mobile and desktop view). But there are ads at the bottom of the page in mobile view. Even though I have paid to have them removed.

In desktop view on the cell phone there are no ads at all. But there is still a blank right sidebar in portrait orientation. That blank right sidebar did not exist before this mobile skin was implemented. Paying to get rid of ads got rid of that blank right sidebar awhile back. --Timeshifter (talk) 05:59, 2 September 2019 (UTC)

I've tested a slightly altered form of the code using Firefox 68 on Android 9. It worked fine. The code below is preferable, due to using the correct interface to localStorage. Remember that it only switches views the first time from Mobile to Desktop. After that, Mobile or Desktop is set by (apparently) a cookie.
/* Any JavaScript here is loaded instead of MediaWiki:Common.js for users using the mobile site */

/**
 * Make first mobile view switch to desktop
 * . check for localStorage capability
 * . if capable and key not found, set key and switch to desktop
 */
( function ( ) {
	'use strict';

	var
		key = 'mobileSwitch';

	if ( ( typeof Storage !== 'undefined' ) && ( localStorage.getItem(key) === null ) ) {
		localStorage.setItem(key, '');
		location.search += ( location.search === '' ? '?' : '&' ) + 'mobileaction=toggle_view_desktop';
	}
} ( ) );
localStorage should be cleared when cookies are cleared, if you want to test again. --Saftzie (talk) 11:18, 4 September 2019 (UTC)
Interesting. I installed Firefox 68 on Android 5.5.1. Chrome 76 was already installed. Safari 10 is installed on iOS 10.3.3.
The JS worked only in Firefox. It switched to the desktop view, and kept it there. Even when I clicked the mobile view links, it would go right back to the desktop view.
It is confusing to people when they click the mobile link at the top or bottom in Firefox. People are kept in the desktop view.
It would be nice if the JS would work in all browsers, but I suspect that will be difficult. Especially in browsers with old version numbers. Apparently, in iPhones the Safari browser version only goes up to the version number of iOS installed in the phone.
But if the JS would work in all browsers, and if the mobile links could be removed or hidden, then the JS would be a good solution.
I wonder if it is possible and easy to uninstall mw:Extension:MobileFrontend from the Cannabis Wiki. I thought extensions could be added and removed. If so, that would be the best solution.
In the meantime s:w:cannabis:Template:View full site is probably the least confusing to readers. --Timeshifter (talk) 14:45, 4 September 2019 (UTC)
It sounds like maybe JS and private browsing modes are not getting along with each other on your phones. It's possible to have the JS test what does and does not work on each phone, but that's more code. MobileFrontend is installed site-wide. Extensions that are site-wide are installed once for the whole farm, not installed individually on each wiki. The only way to uninstall a site-wide extension for you would be for ShoutWiki to change the configuration of every wiki in the farm. I am not staff, so I cannot speak definitively for staff, but that's not going to happen. --Saftzie (talk) 19:07, 4 September 2019 (UTC)
OK. I will ask staff about whether mw:Extension:MobileFrontend can be removed from the Cannabis Wiki. I would gladly pay to have it removed. :)
In the meantime I will continue adding s:w:cannabis:Template:View full site to the rest of the pages. I can empty the template if the extension is ever removed. If the mobile view starts to include show/hide boxes, and begins to work better than the desktop view, I could pay to return the extension. But even if it allowed show/hide boxes, it still doesn't allow much of the custom CSS on the desktop view. That CSS customizes background and link colors for the whole site, and for various templates. The desktop view looks great on mobile phones in my opinion. Because, it keeps the table of contents (TOC) on pages. And, as I said the desktop view elegantly moves the sidebar to the bottom of the pages. The page TOCs and the site sidebar are how the site is navigated. They are essential. --Timeshifter (talk) 04:30, 5 September 2019 (UTC)
You can restore collapsible elements by loading the jQuery module for them. You can do it in s:w:cannabis:MediaWiki:Mobile.js (instead of the code from before, since it doesn't seem to work for you).
/* Any JavaScript here is loaded instead of MediaWiki:Common.js for users using the mobile site */

$( function (mw, $) {
	'use strict';

	mw.loader.using('jquery.makeCollapsible', function ( ) {
		$( '.mw-collapsible' ).makeCollapsible ( );
	} );
} (mediaWiki, jQuery) );
You can also make the mobile site load s:w:cannabis:MediaWiki:Common.css by placing a CSS @import rule in s:w:cannabis:MediaWiki:Mobile.css. @import rules have to come before all other content, except comments and @charset rules.
/* Any CSS here is loaded instead of MediaWiki:Common.css for users using the mobile site */

/* Make mobile users load Common.css, anyway */
@import "/w/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css";
The mobile site doesn't load those things because they take up cell data quota and cell memory, which some users may not appreciate. If you recommend they switch to the desktop site, anyway, loading just a few desktop features into the mobile site is still lighter by comparison. --Saftzie (talk) 07:38, 5 September 2019 (UTC)
Thanks again. s:w:cannabis:Main Page is now a good short page for testing. It has the view full/mobile site toggler links. It has a short show/hide table in the top section. It is the "Image searches" box, and has a dark background when expanded. So that is good for testing whether Common.css is being imported.
Mobile view imports and uses the JS and CSS when looked at from a desktop PC. But not when viewed from my cell phones. I installed more browsers in both of my old cell phones.
I wonder if it is possible to prevent certain templates from being loaded in mobile view. Like the top and bottom templates on most pages. They are both long and probably use up too much data for some cell phone users. --Timeshifter (talk) 07:00, 6 September 2019 (UTC)
Mobile.js should run as long as JavaScript is enabled in the browser. I don't think there's even a way to disable CSS, so Mobile.css should just work. I can only say they work for me on Hub using Chrome 76 and Firefox 68 on Android 9.
If you want to remove things in mobile view, you can wrap them in an HTML element with the CSS class nomobile. I'm not sure which templates you mean, but you can put the element in the template or edit an element already in the template to add the class, if that applies. Things wrapped in an element with the class nomobile aren't just hidden; they're removed from the rendered page before it's sent to the browser. --Saftzie (talk) 08:19, 6 September 2019 (UTC)
Wow! Everything is working now. What a difference some time makes. I have noticed this in the past with sitewide CSS and JS changes. Sometimes they happen within 15 minutes, and some Ctrl-F5 action. Other times nothing works until magically it is working. I had tried several things earlier after waiting awhile. I had cleared the data for all the browsers. I had turned the cell phone completely off. Then back on. Nothing worked. But now since my last comment, everything is working.
Nomobile works too. That will make a huge difference to cell phone users around the world that access the cannabis wiki from all kinds of cell phones. I tried nomobile in various templates. Such as: s:w:cannabis:Template:News list box small. Test. Nomobile is working fine.
I tested other stuff on the s:w:cannabis:Main Page. It is easy to get to the main page when in mobile view since it is the top left link on all mobile view pages.
One thing puzzling me is why the show/hide toggler link is not on the left side in mobile view. That is where I put it (at Commons.css) in desktop view.
I wish there was a way to link directly to the sidebar somehow from the home page in mobile view. From all pages actually. And also make it show up at the bottom of all pages in mobile view.
And I wish the table of contents showed up in mobile view.
Navigation is what is greatly lacking in the mobile view.
Also, categories are missing on cell phones in mobile view. But categories show up in mobile view when seen on a PC screen.
--Timeshifter (talk) 16:59, 6 September 2019 (UTC)
I discovered that on older Android versions (I have 5.1.1 on the Moto G3) the Android system cache partition must be cleared in order to rapidly see mobile CSS changes. Clearing app caches alone (as I previously discussed) is not enough.
Also, I read somewhere that @import can slow things down a bit. So I copied Commons.css over directly to Mobile.css. I also made some changes specific to mobile CSS.
I can see mobile CSS changes right away from my desktop PC. So I trust what I see that way to eventually show up on my mobile phones. The Edge browser on the iphone 5c shows mobile CSS changes right away after simple app cache clearing. --Timeshifter (talk) 00:29, 15 September 2019 (UTC)
There is now a toggle switch on most pages on the Cannabis Wiki:
s:w:cannabis:Template:View full site
It remembers the last toggle. So it does not have to be clicked again when going to a new page.
It is on most pages already, and I am in the process of adding it to more. --Timeshifter (talk) 11:01, 4 September 2019 (UTC)

install skin:monaco[edit source]

  • Hi, how can i install monaco skin in my free host wiki? --Msnhinet8 (talk) 13:49, 15 October 2019 (UTC)
    Monaco is already installed on every wiki at Shoutwiki. You can select it in your Preferences for just yourself. If you want to make it the default for anonymous users, you can ask staff to change your wiki's configuration options. --Saftzie (talk) 17:30, 15 October 2019 (UTC)
    • oh, my mean install monaco skin in my free host. --Msnhinet8 (talk) 00:43, 16 October 2019 (UTC)
    • the monaco, not update. --Msnhinet8 (talk) 00:44, 16 October 2019 (UTC)
      Shoutwiki's port of Monaco is proprietary, so it's not available for installation anywhere else. The Discussion page at MediaWiki has information about an apparently free version on github that works with mw1.29. You'd be better off looking at the documentation there than asking here if you want to install it on your own server. --Saftzie (talk) 17:55, 16 October 2019 (UTC)

Thank you for unblocking[edit source]

The malformed URL was a typo, greetings, Manuela (talk) 03:54, 27 November 2019 (UTC)

Retrieved from "https://www.shoutwiki.com/w/index.php?title=User_talk:Saftzie/Archive02&oldid=31400"