User talk:GMedich

Welcome!

Hello, GMedich, and welcome to the Mises Wiki! Thanks for signing up – we're glad to have you! If you need help getting started, take a look at our help pages.

Community discussion takes place at the MisesWiki Commons, so feel free to post any questions you might have there or on my talk page. Please sign your messages on talk and discussion pages using four tildes (~~~~); this will automatically insert your username and the date. Again, welcome!

Hi, thanks for the redirect fixing. We can also use a script for that, by the way; I just hadn't run it in awhile (actually ever) because no one requested it. FormerContributor-78162cb3 (talk) 01:04, 28 December 2013 (MSK)

Thanks for the welcome, Nathan. Although I've worked on a few wikis in my past, I prefer to ease into them by making a few minor edits at first. I believe it warms me up a bit to some of the underlying patterns used by the community. There weren't really that many double redirects, and I kind of enjoy housekeeping a little bit on the wikis I try to support. GMedich (talk) 01:16, 28 December 2013 (MSK)

Yeah, I just ran the script: "No double redirects found." Looks like you were pretty efficient at your wikignoming! The situation you observed was atypical in that I had created a bunch of articles in mainspace that more properly belonged in an Essay: namespace, but it didn't exist yet. After it was created, User:Pestergaines moved them in there. FormerContributor-78162cb3 (talk) 01:24, 28 December 2013 (MSK)

I stopped with the "broken" redirects after I realized they probably would be better deleted than maintained as redirect pages. I don't imagine many users would actually search out some of those terms. GMedich (talk) 01:27, 28 December 2013 (MSK)

MediaWiki

Hi GMedich, How familiar are you with the technical side of MediaWiki (e.g. configuration, troubleshooting, etc.)? Once in awhile we run into some glitches that I have trouble figuring out how to fix. Thanks, FormerContributor-78162cb3 (talk) 01:45, 29 December 2013 (MSK)

My most technical endeavors have included a small amount of css customization and stretching the capabilities of wikicode. I have only recently begun trying to reverse engineer some basic semantic MediaWiki functions. I would probably be at most rated as a talented dabbler. GMedich (talk) 07:28, 29 December 2013 (MSK)

Actually, I was just attempting to decipher some CSS today, and figure out what is making those headings on the left sidebar so undesirably big. We have a custom skin; see Special:ViewFiles#main.css and MisesWiki:Vector.php.

Are you referring to the SMW described at mw:Semantic MediaWiki? There have been several discussions about whether we should switch to that system; see MisesWiki:Commons#Semantic_wikis and MisesWiki:Commons#Mass_imports. Also, I came up with my own system, mw:Extension:BedellPenDragon, which is in use at PolyWiki.org, ChildWiki.net, and SuicideWiki.org. The "randomly featured article" rotation, "new articles" feed, and Glossary are generated using Template:PageSummary and Template:FASummary. That's all stuff that could probably also be done using SMW.

More input at those Commons discussions would be welcome, once you reach a point at which you would feel familiar enough with the wiki to be comfortable weighing in. Thanks, FormerContributor-78162cb3 (talk) 09:35, 29 December 2013 (MSK)

I imagine your headings are simply using the default settings of h5. You might try something similar to:

.portal h5 {
   padding:0 1em 0 .5em;  /* example only */
   font-size:90%;
   font-weight:normal;
}

I could not test this on a personal css file here since creating such files appears to be prohibited. GMedich (talk) 00:30, 30 December 2013 (MSK)

Okay, I changed $wgAllowUserJs and $wgAllowUserCss to true. That should allow you to try it. FormerContributor-78162cb3 (talk) 02:28, 30 December 2013 (MSK)

I see where you added this, but I am still being prevented from creating either User:GMedich/common.css or User:GMedich/misesskin.css subpages. The system keeps me logged in, but the "Create account" and "Log in" options replace the user options which are typically displayed there. The message I receive continues to read "There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page." I could not see another option in the LocalSettings.php which would prevent my access. GMedich (talk) 02:56, 30 December 2013 (MSK)

Oops! I just found the Preferences>Appearance tab now provides this access. I have been accustomed to adding it directly. GMedich (talk) 03:00, 30 December 2013 (MSK)

Well, that seemed to work fine for me in my personal common.css file, Nathan. The navigation headers were normal weight and slightly smaller. I did not play with the padding values to see what variations could be produced. This should work for you in the general css file if you intend to adjust the appearance of these headers. GMedich (talk) 03:44, 30 December 2013 (MSK)

Excellent! That looks much better. Thanks. A few other small issues: (1) the watch/unwatch star to the right of the Edit button is hanging down where it's not supposed to. (2) I think the blue portion of the background is supposed to extend all the way to the bottom of the screen. Do you think that would look better? Right now, the Ludwig von Mises image is hanging off the edge into the white. (3) Widget:YouTube isn't working, even on videos that play on other sites. See, e.g.: {{#widget: YouTube|id=FR2LWUM8in8}} This works at Nathania.org: http://nathania.org/wiki/User:FormerContributor-78162cb3/Mises_Wiki_interview You have access now to play with Widget:YouTube. Thanks again, FormerContributor-78162cb3 (talk) 04:49, 30 December 2013 (MSK)

I have been using the "Inspect element" option in my browser in an attempt to ferret out the root of these issues. I noticed that the von Mises image can be adjusted by increasing the padding in the footer-wrapper to 40 px (on line 212):

div#footer-wrapper {
    width: 100%;
    margin: 10px auto 0;
    padding: 40px 0; 
    height: 300px;
}

Although I did notice the unexpected change in my user rights, I cannot seem to edit the main.css file to make this change. The watch/unwatch star appears to be due to js features rather than css coding. The inspect element does show the icon size being larger than its intended positioning, but there is no related css coding I can find to adjust it. Several error codes show when inspecting the js side, including some missing bits. I am not very familiar with javascript functions, unfortunately...usually just a cut-and-paste feature in my past experience. Any thoughts? GMedich (talk) 18:04, 30 December 2013 (MSK)

Yeah, main.css is not in the MediaWiki namespace; it's in the file system, and is edited from the shell. I'm not sure there's any way to override it from within MediaWiki. I did make the change you suggested and it seems to have fixed the issue. Thanks!

Maybe the star has something to do with js. It could also be related to something in Vector.php. See, e.g.:

                if ( $wgVectorUseIconWatch ) {
                        $mode = $this->getSkin()->getUser()->isWatched( $this->getSkin()->getRelevantTitle() ) ? 'unwatch' : 'watch';
                        if ( isset( $nav['actions'][$mode] ) ) {
                                $nav['views'][$mode] = $nav['actions'][$mode];
                                $nav['views'][$mode]['class'] = rtrim( 'icon ' . $nav['views'][$mode]['class'], ' ' );
                                $nav['views'][$mode]['primary'] = true;
                                unset( $nav['actions'][$mode] );
                        }
                }

Our Vector.php was written for some obsolete version of MediaWiki; right now we're using the cutting-edge v1.23alpha. The recent upgrade from v1.21 caused those glitches to start appearing. mw:MediaWiki_1.22#Upgrades_to_Vector_and_other_skins might have some useful info pertaining to that. The star is not an incredibly big deal since it only is displayed to logged-in users, and we don't have very many of those. FormerContributor-78162cb3 (talk) 18:30, 30 December 2013 (MSK)

I understood "Vector" to be the latest default skin for MediaWiki. Is the custom skin you previously mentioned built upon Vector as its foundation? GMedich (talk) 18:52, 30 December 2013 (MSK)

They have some similarities. I know nothing about the history of our Vector.php, other than that this custom skin has been around since at least v1.18. You can see the file reference for MediaWiki's Vector.php here. I see that the PHP code snippet above is identical to what's in the MediaWiki codebase's version. FormerContributor-78162cb3 (talk) 19:09, 30 December 2013 (MSK)

While I have been able to identify the coding which lowered the placement of the watch/unwatch star icon, I have not been able to find a solution. I did learn that this feature's default value was changed from false to true in v1.21, the time you stated the problem began. The offending portion of the code is:

#ca-unwatch.icon a, #ca-watch.icon a {
   padding-top: 3.1em;
}

3.1em of padding pushed the icon too far down. By live editing the html, I found 1.7em to be a good match with text in the adjacent boxes. Unfortunately, adding this to my personal css page does not affect this. I also cannot locate the origin of the #ca variable. GMedich (talk) 23:56, 2 January 2014 (MSK)

I created a tar.gz of the skins folder, in case you want to grep through it in search of what you're looking for. See http://wiki.mises.org/mediawiki/miseswiki-skins.tar.gz FormerContributor-78162cb3 (talk) 10:17, 3 January 2014 (MSK)

Thanks, Nathan. I just conducted a text search on some of the files, and seemed to locate the culprit. The vector folder contains a file named screen.less which created the 3.1em padding in question. The lines are near the bottom of the file under the dual heading: #ca-unwatch.icon a, #ca-watch.icon a . If you change the padding to 1.7em, I expect the star will relocate properly. GMedich (talk) 19:41, 3 January 2014 (MSK)

It works! Yay! FormerContributor-78162cb3 (talk) 20:13, 3 January 2014 (MSK)

Gadgets

I forgot to mention, most of the gadgets are probably broken too. I didn't import any gadget-related stuff from Wikipedia except the MediaWiki: namespace pages that started with MediaWiki:Gadget. If you (or another sysop) can fix those, and make a note of how they were fixed, then we can expand the Gadgets section of mw:Manual:Using content from Wikipedia (or maybe create a new page, mw:Manual:Using gadgets from Wikipedia). That would be very helpful to the whole non-WMF wikisphere. A lot of the gadgets seem to use code from people's userspace, and there doesn't seem to be a central list of what all those pages are.

The WMF-specific gadgets, of course, we can dispense with entirely. The gadgets extension was only installed a few weeks ago, so if none of us gets around to fixing the gadgets, we haven't really lost any functionality. FormerContributor-78162cb3 (talk) 06:37, 31 December 2013 (MSK)

Yes, I had noticed that many gadget functions do not seem to be currently accessible. I cannot help but think that backing out some of these gadgets would be a very good idea. Adding and accessing content is typically the primary function of a wiki. Time spent tweaking widgets, gadgets and "who's its" can easily undermine such productivity. GMedich (talk) 19:15, 31 December 2013 (MSK)

It depends on the gadget. Some, like HotCat and CharInsert, are pretty useful, and editors appreciate having them. Having a bunch of broken and/or superfluous features makes it look like we're not on top of our technical game, though, so probably the majority of those should indeed be eliminated. Widgets are useful for putting important videos, etc. inline. It lets us have some of the same functionalities as other content management systems.

Wikipedia doesn't like to have those kinds of widgets because they introduce external dependencies. Aside from caching-related concerns, I don't see what the objections would be; I doubt YouTube will exclude Wikipedia from accessing those videos, for instance. Wikipedia seems suspicious of any relinquishing of control or influence to a third party; it's one of the reasons why they apply nofollow to external links. They're kinda selfish that way. Fortunately, they're very generous in a lot of other ways (e.g. giving away their software and content for the whole wikisphere to use).

Actually, any meta-aspect of a wiki (not just the tech aspects) can become a distraction if it becomes the focus of all the attention. E.g., sometimes people get caught up in discussions of wikiquette, wiki-philosophy, bureaucratic procedures, or power structures. Those things are important, and some people devote themselves entirely to them, but a wiki's mainspace (or, more broadly, content namespace) content is ultimately what outsiders care about. FormerContributor-78162cb3 (talk) 19:33, 31 December 2013 (MSK)

At least in the case of actual Widgets, we only have one to deal with at the moment. That should be a definitely solvable problem, and very helpful for including Mises related talks, etc. I have had no initial success in identifying any particular problem at this point. GMedich (talk) 19:26, 1 January 2014 (MSK)

It would seem to be a problem with widgets in general, since Widget:MediaWiki isn't working either. I'll google later to see if anyone has encountered this type of issue before. FormerContributor-78162cb3 (talk) 20:46, 1 January 2014 (MSK)

The YouTube widget does look rather strange to me in that so much of the code is enclosed in comment tags. GMedich (talk) 01:24, 2 January 2014 (MSK)

I've never had a problem with widgets on other wikis. There are some other ways I can try to troubleshoot this issue. I can copy over the file system and database to another server and see if I can replicate the problem there. I can try upgrading to the latest development version of MediaWiki and see if that helps. I can try disabling all the other extensions and returning to the default configuration. These issues usually don't stay unsolved forever, if one is determined enough to keep looking for solutions. FormerContributor-78162cb3 (talk) 06:46, 2 January 2014 (MSK)

I've confirmed that the issue is (apparently) something to do with our server. See http://mises.inclumedia.org/wiki/User_talk:GMedich#MediaWiki , where the widget is working fine. The file system and database are virtually identical there; there's something else going on that's keeping the widget from working. FormerContributor-78162cb3 (talk) 04:35, 5 January 2014 (EST)

A barnstar for you

		The Technical Barnstar
		Thanks for your help! Your css-fu has been invaluable in getting the wiki looking good again after the upgrade._ FormerContributor-78162cb3 (talk) 20:13, 3 January 2014 (MSK)

FormerContributor-78162cb3 (talk) 20:13, 3 January 2014 (MSK)

I'm glad that you were so quick to get to work on that stuff and find the solutions, because for at least the time being, we no longer have the ability to implement such fixes. FormerContributor-78162cb3 (talk) 08:08, 8 January 2014 (EST)

Minor vandals

We could also use the Template:Test for those minor vandals, especially on the first offense. FormerContributor-78162cb3 (talk) 13:59, 7 January 2014 (EST)

Not a bad idea. I don't see how warnings can be issued to anons, so I figured a 24 hour block would give other admins an opportunity to chime in without the anon repeating the offense after the rollback. GMedich (talk) 18:06, 7 January 2014 (EST)

Like that? Hopefully we can get mw:Extension:AbuseFilter configured so that we can identify and throttle vandalism more easily. I lost shell access in the server move and my request for access to the new server is pending at this time; unfortunately I didn't get the configuration set up to grant sysops access to Special:AbuseFilter before that happened. FormerContributor-78162cb3 (talk) 05:05, 8 January 2014 (EST)

Yes, I knew such messages could be posted, but I am doubtful of their effectiveness on anon pages. I suppose it could aid in explaining the reasoning behind a rollback. GMedich (talk) 10:24, 8 January 2014 (EST)

It probably isn't very effective, but it does put on record that vandalism came from that IP address, so that people don't have to comb through the contributions to see what the person was up to. Such notices could be problematic, though, since another person using the same IP address might get irrelevant messages. On the other hand, this isn't Wikipedia; it's probably unlikely that two people at the same IP address (one of whom is at least a onetime wikivandal) would be reading Mises Wiki.

Anyway, not a big deal, it's more a matter of principle than anything, plus the fact that people sometimes respond better if treated more gently than they deserve. We used to not even allow IP edits. FormerContributor-78162cb3 (talk) 10:31, 8 January 2014 (EST)