# Difference between revisions of "User talk:Webmaster"

The wiki is a good resource, and I'm always interested in improving it. However, I have some feature requests that are important for making the Wiki a better place.

## MediaWiki Version

The first is to update to MediaWiki version 1.18. It's a rather recent version, and I'm confident that a certain bug will be fixed in it. That bug governs categories with lots of elements in them.

I'm attempting to put the entire OpenGL API in the wiki (so that errors can be corrected much more quickly than with Bugzilla reports). I started from the DocBook man pages, using a specialized XSLT to convert them to MediaWiki format. That worked great... except for one problem. The category page for GL 4.x's API has an issue. If you press the "next 200" link, nothing changes.

This was a known bug in MediaWiki, which I believe they corrected in version 1.18. Since the current GL Wiki is still on 1.17, there's a problem.

Thanks for the Math fix, and I noticed you updated to 1.18. When that didn't seem to fix the issue on that category page, I filed a bug report on it. According to the response to the bug, the problem comes from the CategoryTree extension. If we're still using an older version of that, could you upgrade it to the latest version? If it still doesn't work after the upgrade, let me know so I can re-open the bug.
Thanks for the help. Alfonse 05:38, 27 January 2012 (PST)
We are on the latest version of CategoryTree, but turns out on the wrong branch. I've updated to the latest branch and latest revision. Let me know if this works out for you. I'll go through and verify the other extensions to be sure we are on the latest branch for everything.
Webmaster 06:32, 27 January 2012 (PST)

The next thing that would be great would be proper support for the $tag. The parser can process it, but that alone is insufficient. The [itex] tag is intrinsically bound to the MediaWiki Math Extension. Without that extension, you just get an error when you try to use the [itex] tag. In order to fully bring the man pages into the Wiki, we need the ability to create math equations. They'd also be great for several other pages. Wouldn't this page on depth buffer precision work much better if it used real equations rather than unformatted inline text? Updated the Math extension. Sample: ${\displaystyle \operatorname {erfc} (x)={\frac {2}{\sqrt {\pi }}}\int _{x}^{\infty }e^{-t^{2}}\,dt={\frac {e^{-x^{2}}}{x{\sqrt {\pi }}}}\sum _{n=0}^{\infty }(-1)^{n}{\frac {(2n)!}{n!(2x)^{2n}}}}$ Webmaster 13:20, 23 January 2012 (PST) ## Presentation There are certain elements of presentation that could be better in the Wiki. Without access to the CSS's that the Wiki uses, these cannot be altered. For example, take the <source> tag. This tag includes syntax highlighting, which is excellent (though the GLSL syntax highlighter could use some updating for GLSL 4.20 and all). But the size of the source box is just too big and noticeable. Contrast the difference between this: void glMultiDrawArrays( GLenum mode, GLint * first, GLsizei * count, GLsizei primcount );  and this: void glMultiDrawArrays( GLenum mode, GLint * first, GLsizei * count, GLsizei primcount ); The large bars at the top and bottom take up too much space. The font is also needlessly bigger and bulkier. It would also be good if the CSS had some constraints on it for exceptionally wide source for <pre> and <source> tags. That way, wide text would just create a scrollbar rather than breaking the page layout. This can be done by setting the overflow CSS property for these elements to "auto". You could also use the max-height property on <source> elements to constrain the height of these elements. Those elements that exceed the height would get their own vertical scroll bars. Alfonse 11:23, 23 January 2012 (PST) Would this page help? http://www.opengl.org/wiki/MediaWiki:Geshi.css Webmaster 13:20, 23 January 2012 (PST) That worked out quite well, thank you. I've got the <source> tags working reasonably well. Take a look at the tutorial pages to see how much better they are with the inner scrollbar. The only issue is that I can't do anything about the regular <pre> tags. That's because the Geshi.css is only included if a page uses the <source> tag. I think that's something you would have to do internally with the main Wiki .css file. Alfonse 18:47, 29 January 2012 (PST) ## New Wiki-version oddness. The new version of the Wiki is good overall, especially the category tree fix, but there are a few oddities that came along with it. First, the edit page has a different style to it. While that style is a bit more minimalist, it doesn't convey nearly the information that the old one did. The biggest difference is the lack of a link to the Help:Cheatsheet page, which is useful if you've forgotten some bit of formatting. There is a 'Help' drop down now with all (I think) of the hints from the cheatsheet. Does this work out well for you? Wikipedia has that, but it also has a regular link down at the bottom. Also, that requires the use of the advanced toolbar stuff, which I'm not exactly a fan of. I'm not against it, but flicking those checkboxes on the preference page shouldn't mean "I can't use the editor anymore". Also, the page cannot be edited. So I can't, for example, add the [itex]$ examples I added to the cheat-sheet, as well as the link to the full documentation for that feature.
Just compare the editing page to what the Wikipedia edit page looks like.
Disabled the hiding of the bottom links. You now have Show Preview, Show Changes, Cancel and Editing Help at the bottom again.

Second, there is no preview button in the page editor. I know one of the special editors you can set from preferences has a preview function, but it would be good to not have to use that particular JavaScript-based editor in order to get a preview.

There is a Preview Tab, along with a preview Changes tab. How do these stack up for you?
Same as the previous section: it is functional, but it makes the preference kinda meaningless. You either use the new toolbar (and therefore Javascript) or you don't get to have previews at all. I don't think it's a good idea to force that sort of thing, especially if the Wiki still can do the old-style preview.
See above. In theory I think I have it working the way you suggest.

The other thing is that, at least on my Firefox 9, the Search textbox behaves very oddly. Putting the cursor on it causes a horizontal scrollbar to appear, which obscures most of the text you're trying to enter. Alfonse 18:52, 29 January 2012 (PST)

Search field issue is resolved.
It is possible that all these features don't show for you if you are using a different editor. Please clarify for me if you are using a different editor, and how you switched to it. I've only ever used the default editor. The change occurred when we upgrade the Vector Theme for MediaWiki which now was WikiEditor as a separate extension. I'll be happy to try and sort this out so it works better for you, if I can understand the problem better
Webmaster 16:10, 8 February 2012 (PST)
They're all part of the "Show edit toolbar (requires JavaScript)" and "Enable enhanced editing toolbar" and so forth. Which is fine I guess (though the latter one is a beta feature, which probably means it shouldn't be relied upon), but Wikipedia doesn't force you to use it. Without the ability to do the stuff the old way, there's no choice but to enable JavaScript and use those editing options. Alfonse 21:40, 8 February 2012 (PST)
Also fixed I think. Bear with me as I learn more about the Wiki Editor settings. Webmaster 08:18, 21 February 2012 (PST)

## API not working on the site

I think a recent update to the site may have broken the MediaWiki API, which I use for a couple of bots. The end point for the API, which theoretically should be www.opengl.org/w/api.php seems to be coming up empty. Without that working, it isn't possible to access the API. Alfonse (talk) 14:50, 11 August 2012 (PDT)

API is available at http://www.opengl.org/wiki/Api.php. Does that not work either?
Webmaster (talk) 14:55, 11 August 2012 (PDT)
That that's just a regular uncreated page on the Wiki that happens to have the name "api.php". The URL for the API isn't under the \wiki directory. It's a special system thing. For example, the Wikipedia version looks like this. Alfonse (talk) 21:25, 11 August 2012 (PDT)
Like this http://www.opengl.org/wiki_132/api.php I gave the friendly url last time by mistake. This is the correct url.
Webmaster (talk) 06:46, 12 August 2012 (PDT)
Thank you for investigating this, but it appears to have been some outdated bot code on my end. Upgrading to the latest version of the bot resolved the issue. Sorry about that. AlfonsesCategoryBot (talk) 18:15, 12 August 2012 (PDT)
No worries. Glad to hear it all works. Webmaster (talk) 06:18, 13 August 2012 (PDT)

## Changing files without administrative rights

Dear Webmaster, in the course of expanding the article on Tessellation, I uploaded pictures which weren't correct. Trying to change the files, I was notified that my level of permissions wasn't sufficient. I talked to Alfonse about it and he suggested to directly come to you. Please see my talk page regarding his comment.

Incidentally, how many authorization levels are there in the wiki and what rights does a certain level grant you? Can my account be elevated appropriately or what criteria are associated with expanded permissions? Thanks! thokra (talk) 06:50, 4 January 2013 (PST)

I've added reupload permissions to the autoconfirmed users and have added User Thokra to the bureaucrat group. More on bureaucrat permissions can be found here. Webmaster (talk) 07:13, 4 January 2013 (PST)
Thanks for the help. Sorry btw for editing your user page. Wasn't intended. thokra (talk) 07:15, 4 January 2013 (PST)

## Activating HTML Tidy

HTML Tidy is a setting that MediaWiki provides, which causes the HTML generated by MediaWiki's not-entirely-intelligent script system to be corrected into something more reasonable. I was doing some experiments, off and on, with incorporating more Wikipedia-like formatting. Thinks like those bottom floats for categories and Portals and such. But I ran into a number of formatting glitches, and they generally come back to one thing: the lack of HTML Tidy on this Wiki.

I have no idea how turning it on will impact the performance of the wiki.

Note that if you are using it, it may be that the configuration is wrong. I'm not sure.

A simple test is this:

First Line

Second line

If you try this exact Wikitext in the Wikipedia sandbox, you'll see that both lines are red. HTML Tidy split the <span&rt; tag into two lines, each within their own paragraph elements.

I'll take a look and get it sorted. I don't believe it is on right now, but not 100% sure. Most likely won't be today, but I should have time by monday. Webmaster (talk) 06:51, 15 February 2013 (PST)
Turned on HTMLTidy and checked the validity of the conf file. Seems to work based on the above one example. Webmaster (talk) 08:57, 15 February 2013 (PST)

## Abuse filter oddly configured

The abuse filter blocked me for adding an off-wiki link to this page. I'm guessing that probably wasn't supposed to happen, since it said "Description of matched rule: New users adding links to talk or user pages". I unblocked myself, but other users wouldn't be able to do that.Alfonse (talk) 16:38, 28 March 2013 (PDT)

I think I found the reason for it. The current abuse filter looks like this: user_editcount < 2 & count("http://", added_links) > 0 . I don't know what the operator precedence rules are for this, but I'm guessing that & and | have the came precedence. So uses with an edit count less than 2 are forbidden from using "http://" links, but all users are prevented from adding "https://" links. And the link I was trying to add was indeed "https". Alfonse (talk) 19:13, 28 March 2013 (PDT)
You are correct, my bad, and fixed. I noticed the error on the COLLADA wiki and fixed it, then got distracted. I've just added another filter to hopefully curb some of the abuse we see. Webmaster (talk) 06:17, 29 March 2013 (PDT)

## Several broken things on the Wiki

I noticed that several things on the Wiki don't seem to work anymore.

The first is the Math extension. It appears to work, but this would seem to be purely through previously cached math equations. That is, everything that was already on a Wiki page continues to work. But any new equations or modifications to old ones fail with a parser error. Consider this simple Math equation:

${\displaystyle x=2}$

Since the cached math stuff seems to work, this problem may be related to the second thing I noticed. A lot of the Special Pages seem to fail. Specifically, the maintenance reports, which are almost all completely blank (they're a very useful way to find mistakes like red-links and such). I noticed that all of them also say "The following data is cached and may not be up to date." That's why I think it may be a global caching issue; none of these caches seem to be updating. Perhaps something got switched to read-only? Or something related to caching was turned off?

I noticed another caching issue as well. Specifically, if you change a template, it seems to take quite a while for other pages that use that template to notice. For example, when I changed the [[Template:Current version] to 4.5, it took a couple of days for the pages to figure out that the version had been updated. However, if I made an edit to that page, one unrelated to the version, the Wiki instantly updated which templates were in use.

Any ideas? Alfonse (talk) 14:33, 12 January 2015 (UTC)

Math is fixed and cache issue fixed. During an update in November the latex.fmt file, although present, became out of date. Cache: We have MiserMode turned on to reduce server load. The cronjob for updateSpecialPages wasn't running--it is now. (Welcome back) Webmaster (talk) 15:16, 12 January 2015 (UTC)
The math caching issue seems to be back. My test page shows the problem. Alfonse (talk) 22:08, 1 August 2015 (EDT)
Thanks Alfonse. The latex.fmt file was corrupt after the move. This is resolved and equations work as expected. Webmaster (talk) 14:25, 3 August 2015 (EDT)

## Site preferences no longer working.

Several preferences no longer seem to work. Specifically the following:

• Warn me when I leave an edit page with unsaved changes: Editing a page and closing the tab emits no warning.
• Show edit toolbar: No edit toolbar of any kind appears. Note that this problem extends to the enhanced editing toolbar too.

I also noticed that the layout of the banner ads on the site is sometimes broken. Some minor research on my part showed that injected HTML could break the edit toolbar. Alfonse (talk) 00:30, 22 December 2015 (EST)

The ClickTracking extension was looking for an old jquery piece. This is fixed. I'll still looking at the random banner oddity. Webmaster (talk) 12:29, 23 December 2015 (EST)

## Wiki updating seems inconsistent.

I was doing some editing to the Wiki, particularly the Tessellation page. The edits seem to go through fine. But when I switched to another computer, I couldn't find the changes. They weren't even in the history of the page; it stops on the 15th of June, and my significant changes came later. I can't see the changes I made today or several days ago.

And yet, I can see the changes on the "Recent Changes" page. Any ideas? If it means anything, the other computer is a mobile device. Alfonse (talk) 22:02, 2 July 2016 (EDT)

Currently we are running on 6 Virtual Machines (2 load balancers, 2 MySQL DB, and 2 Apache driven web servers). The apache web servers are heavily cached. The caches are supposed to handle changes between the two web browsers without issue, but they may not be if you are seeing inconsistent results. Either that or the mobile browser is not updating the page correctly. Next time you see this, can you visit https://www.opengl.org/cache-status/reset.php and then load the page again, and see if there is a difference. Webmaster (talk) 16:23, 7 July 2016 (EDT)

Calling glGetUniformLocation(prog, "modelToWorldMatrix") is guaranteed