DreamHost:Village pump

From DreamHost
Jump to: navigation, search

Welcome to the village pump. This set of pages is used to discuss the technical issues, policies, and operations of the DreamHost Wiki.

DreamHost links

Would things look better if the external link icon were removed for any links targeted at DreamHost pages? That way, there isn't a sense that the link will take the user to a non-DreamHost site.

Using this in MediaWiki:Common.css might work, though someone would need to test it:

/* Remove the external link icon to for all DreamHost links */
/* (in browsers that support these CSS selectors, like Mozilla and Opera) */
#bodyContent a[href*="dreamhost.com"].external {
    background: none;
    padding-right: 0px;

Then something like, Why not delete spam in the meantime?, would become, Why not delete spam in the meantime?

DreamHost links would lose the icon but retain the colour, distinguishing them from wiki links. You could also be wild and do something like:

/* Change the external link icon to a DreamHost icon for all DreamHost links */
/* (in browsers that support these CSS selectors, like Mozilla and Opera) */
#bodyContent a[href*="dreamhost.com"].external {
    background: url(/images/7/71/Dreamhost-favicon.gif) center left no-repeat;
    padding-left: 18px;
    padding-right: 0px;

The result: Why not Dreamhost-favicon.gifdelete spam in the meantime? Mind you, the baseline of the icon here is out of place because the mock can't imitate the real deal.

One concern here is secure links. The above code would knock out the lock icon that usually appears for HTTPS links (I think). A possible solution:

/* https DreamHost links should still include the security icon */
/* (in browsers that support these CSS selectors, like Mozilla and Opera) */
#bodyContent a[href^="https://"] {
    background: url(/skins/monobook/lock_icon.gif) center left no-repeat;
    padding-right: 16px;

That would basically reverse the custom code and reinstate the MediaWiki default, resulting in the usual secure link. This same sort of thing could also be done for e-mail links and the like. Note that some fancier code would be required if using the DreamHost and secure icons simultaneously.--CartoonChesstalk 10:01, 26 August 2008 (UTC)

Wiki updates notifications

I searched within my preferences and couldn't find a way to get an email notification whenever a page in my watchlist gets updated. Is this feature not provided by MediaWiki? Or simply disabled in this particular wiki?

I'd like to be able to somehow subscribe to the pages I'm interested and get notified when they're updated (I thought that was the purpose of the watchlist) --Baby 08:25, 31 August 2007 (PDT)

Now that I search a bit, I found a MediaWiki extension called EnotifWiki that seems to do what I want... any chance of this being installed/activated in this wiki? --Baby 12:25, 31 August 2007 (PDT)

It'd also be nice to have an rss channel with all the recent changes --Baby 08:25, 31 August 2007 (PDT)

Well, as Scjessey just told me, this channel is actually available at RSS feed of recent changes... maybe a link to it could be added to the main sidebar... --Baby 12:25, 31 August 2007 (PDT)
Actually, it is in the main sidebar. Browse to Special:Recentchanges and you'll see it is added to the sidebar automatically. -- Scjessey 13:39, 31 August 2007 (PDT)
You're right, Scjessey... I didn't see it, 'cause I wasn't looking in the Recent pages page... thanx a lot for your time. --Baby 14:22, 31 August 2007 (PDT)
I know this is late, but guys, you could have added
$wgEnotifWatchlist = 'true';

Actually there are a ton of email options

$wgEnotifFromEditor - Email notifications appear to be coming from the page editor (not from Wiki server)
$wgEnotifImpersonal - Send a generic mail instead of a personalised mail for each user.
$wgEnotifMaxRecips - Maximum number of users to mail at once when using impersonal mail.
$wgEnotifMinorEdits - Email notifications also for "minor edits" (user preference is shown and user needs to opt-in)
$wgEnotifRevealEditorAddress - reply-to address of Email notifications may be filled with page editor's address (user preference is shown and user needs to opt-in)
$wgEnotifUseJobQ - Send mails via the job queue.
$wgEnotifUseRealName - Use real name instead of username in e-mail "from" field
$wgEnotifUserTalk - Email notifications can be sent for first change on a user_talk page (user preference is shown and user needs to opt-in)
$wgEnotifWatchlist - Email notifications can be sent for the first change on watched pages (user preference is shown and user needs to opt-in)
$wgUsersNotifiedOnAllChanges (formerly $wgUsersNotifedOnAllChanges!) - Array of usernames who will be sent a notification email for every change which occurs on a wiki

They can be found here. Rgoodermote 02:05, 21 March 2010 (UTC)


Many of you may have noticed that the wiki has been upgraded to version 1.9.3. Problem solved! Shout outs to DH admin Aaron for taking the time to get the upgrade done. -- Sabrejack 10:31, 18 April 2007 (PDT)

I just want to add my thanks to Aaron for the work he has done in upgrading the wiki and resolving the "save" issues. Great job, and your efforts are most appreciated! -- Rlparker 17:07, 18 April 2007 (PDT)

I would also recommend that Aaron set up image undeletion. If it's not technically feasible, then fine, but it's pretty easy to accidentally delete an old image revision, and there's always the Red threat. --Emufarmers 13:20, 24 April 2007 (PDT)

I would just like to point out that if you let the version slip further and further behind that currently available, you will only find the upgrading process more and more worrisome. Jidanni 19:23, 26 March 2008 (PDT)

That's a good point, and I agree that is is good to stay as current as possible. Unfortunately, as you might have gathered from previous discussions, we have to rely on DreamHost finding the time, and interest, to do the upgrade(s), as none of the "customer" sysops have the appropriate permissions. That doesn't mean that we can't encourage them though! (grin!) -- Rlparker 05:28, 27 March 2008 (PDT)
A bit delayed, but an update to 1.12.0 is in the works. Stay tuned. AF 14:39, 5 June 2008 (PDT)
And 1.12.0 is installed! I'm going around and setting up a few things that have become available with the new version. AF 22:38, 16 June 2008 (UTC)


You may also notice that the issue with having to save your pages multiple times is also gone. Aaron moved sessions into the database instead of on the individual servers and that seems to have done the trick. Awesome. -- Sabrejack 10:31, 18 April 2007 (PDT)

Making wiki administration process more visible

I came to the DreamHost wiki as a fairly experienced Wikipedia editor. I found a protected page that I wanted to be unprotected. I had a hard time finding out who the administrators were and how to make such a request. Thus I was moved to write down what I found out, when I did get the answer.

The result is in Dreamhost:Community Portal. It makes both the list of administrators and this Village pump page more visible. Please check it out!

It might help the next person, which would be good. It might cause too much of the wrong kind of traffic, in which case we might need some different mechanism to tell contributors about administrators and their process. --JimDeLaHunt | Talk 19:12, 10 Jul 2006 (PDT)

MediaWiki 1.15 released

MediaWiki 1.15 was released today. Any plans to upgrade? What about enabling subpages? Thanks Wikademia

I'm planning to upgrade MediaWiki across the board (for one-clicks as well as our official wiki) within the week! There are some potential issues with enabling subpages, though: there are a lot of old pages with slashes in the titles, such as KB / Web Programming / Do you support....? which'd get screwed up by turning subpages on. If you want subpages outside the article namespace, though, just let me know what you need and I'll give it a look. Andrew F 17:01, 11 June 2009 (UTC)
MediaWiki 1.15 is installed here now. I'll be installing it for the one-clicks shortly. Andrew F 19:51, 16 June 2009 (UTC)


Would anyone object to us switching the license from the GNU Free Documentation License to the Creative Commons CC-BY-SA license? (Version 1.3 of the GFDL provides for this sort of cross-licensing, but I figured I'd check with everyone to see if there are any objections first.) Andrew F 17:14, 12 June 2009 (UTC)

How about everything be dual licensed?
That would probably be fine too... any particular reason, though? (Not dubious, just curious.) Andrew F 18:42, 12 June 2009 (UTC)
This concerns me a little, in that I see it as a possible start down the "slippery slope" that leads to having multiple (not just "dual") licenses, and I see that as potentially problematic.-- Rlparker 10:21, 14 June 2009 (UTC)
I'm also curious, but I am curious about why you are looking to switch licenses. Do you see a problem with the GNU Free Documentation License? Generally speaking, I'm not enamored with the idea of changing the existing licensing, but I am certainly open to any change that is beneficial to the wiki community here. I'm just not sure there would be a benefit (and would like to discuss it some more). -- Rlparker 10:21, 14 June 2009 (UTC)
Basically, the GFDL was designed to be applied to printed documentation, and as such it isn't a very good license for online content. There are a bunch of terms in it that don't quite make sense for a wiki, like requirements that any printed version contain a full printed copy of the GFDL, or that you aren't allowed to delete any section called "Dedications" from an article. The only reason Wikipedia started out using the GFDL at all was because the Creative Commons licenses didn't exist yet, really.
There's also some benefits from a content reuse standpoint. There's a lot more content available licensed under the Creative Commons licenses, and it's more compatible with other licenses (you can use CC content in GFDL work, but not vice versa). GFDL really doesn't have much going for it, honestly. Basically, switching the license over is a win-win situation all around. :) Andrew F 17:32, 15 June 2009 (UTC)
I am completely happy to let DreamHost decide how any contributions I have made here (and they are numerous) are licensed. Wikipedia has moved to the CC-BY-SA license, so it isn't too surprising that DreamHost is considering the same approach. -- Scjessey 01:52, 16 June 2009 (UTC)
With Andrew F's explanation, and Scjessey's endorsement, I no longer have any qualms about changing the licensing to CC-BY-SA. I'm still not sure I think a dual/multiple licensing model is a "Good Thing", though. -- Rlparker 02:04, 16 June 2009 (UTC)

As there doesn't appear to be any objection to the licensing change, I've gone ahead and done it! All existing versions are now dual-licensed under GFDL and CC-BY-SA 3.0, and everything from here on out is CC-BY-SA 3.0 only. Andrew F 18:44, 8 July 2009 (UTC)

MediaWiki 1.16

Hope that you can upgrade -- this wiki seems to run 1.15 still. Club Penguin Player 14:19, 25 November 2010 (UTC)

Done! Andrew F 12:59, 30 November 2010 (PST)

Another MediaWiki update

This time, 1.16.1. One-Click should be updated too. --Club Penguin Player 18:21, 8 January 2011 (PST)

Cite extension

Can we get the Cite extension installed? I think it's useful for indicating which information comes from which resources, without adding a bunch of messy inline links. Thanks, Nathan Larson (talk) 00:57, 3 February 2014 (PST)

CAPTCHA whitelist

I recommend adding to MediaWiki:Captcha-addurl-whitelist


For more info, see mw:Extension:ConfirmEdit#URL_and_IP_whitelists Nathan Larson (talk) 01:31, 3 February 2014 (PST)