I've only seen one request so far interested, so I'm going to decline this. The better route would be to look into merging parts of HAWelcome into NewUserMessage first, as mentioned by @jack above. Not very important though. If more requests pop up, then maybee
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 13 2017
Sep 10 2017
Closing. This isn't our issue (we don't develop for EasyTimeline); anyone interested in having that issue fixed should look at upstream (instead of here) where the actual development and issue tracking is located.
Aug 29 2017
Aug 27 2017
See T87#3212.
See T87#3212.
See T87#3212.
See T87#3212.
See T87#3212.
See T87#3212.
Closing, as simply not interested anymore and most likely not going to invest this in any time soon.
Aug 21 2017
Currently being used on Brickipedia with no issues. Hope to roll out globally soon.
StaffWiki now done.
Certificates expired for *.shoutwiki.com.
Jul 18 2017
Jul 7 2017
So I'm going to target this for February 2018... it'll give us a bit of prep time after LetsEncrypt launches wildcard certificates in January.
I'm going to go as far as to say I can't see us supporting this extension any time in the next 12 months. I'm almost tempted to go further, but who knows. A few months ago, I would have said the same thing about Echo.
Jul 6 2017
Firstly, is this the right place to make this request?
Yup, this works. Alternatively you can also email us, either via Special:Contact or directly (support@shoutwiki.com) for private matters.
Jul 5 2017
So the idea, other than just providing the deletion log if a wiki was deleted, is to provide something along the lines of the old Wikia home page with image links to related and big wikis.
So NoSuchWiki no longer uses HTTP_REFERER as browsers don't set this often enough for this to be reliable.
Jun 24 2017
Turns out there's another message too, which is Notification-header-welcome, which says {{GENDER:$2|Welcome}} to {{SITENAME}}, $1! We're glad {{GENDER:$2|you're}} here.
Jun 22 2017
Well, just in case if this means anything, Echo supports a notification for edits made for the very first time. It doesn't require us having to manually delete it on our side. The message is located at notification-header-thank-you-1-edit, so it's technically customisable. Here's a screenshot:
- After reading through this task, it looks like no one mentioned whether or not we want a wiki-editable main page or a splash page (like Brickimedia's old splash page). Splash page gives more freedom but obviously more, long-term maintenance work. What do others think we should have? I think we can try out both, since it won't hurt to try either.
- Colors: We can create our color palette by using some the colors that the Aurora skin has, with modifications as needed - consistency is important. (Although, I'll be honest here, I don't particularly like the black as the primary color since it's such a strong color and thus distracts away from the most important thing, which is content. This is something for another discussion though).
- Languages: Although i18n is a nice-to-have, at least in my view this is sorta low-priority compared to the rest.
- Pictures: From what I've seen, there seems to be quite a bit of wikis that don't have their own logo, so doing this would be sort of a problem.
- {{FEATUREDUSER}}, {{FEATUREDARTICLE}}, and {{WIKINEWS}}, and {{FEATUREDLOGO}} by @mgagemorgan: While that idea as a concept is cool, this entirely depends on us picking something out of a list to decide what should be featured (or we can use the API to pick something randomly, although I imagine that could potentially be an expensive query? Personally, I don't know much about performance + SQL).
- As for wiki News: Is it the same type of news we have on our page? That shouldn't be that much of a problem. What's something that users are interested in? (If we're referring to cross-wiki news, well, that's obviously a lot more work, and requires a team of good, dedicated writers who are able to keep up with the communities on this platform, which there's a lot of; something we currently don't have).
- Piwik stuff: I'm not familiar with the API, but if it's of interest, then here's a link: https://developer.piwik.org/api-reference/reporting-api
- Sidebar idea: Maybe, that sounds interesting. This would be the place for secondary information - stuff that's not as important as other info. Now, what do we consider secondary information?
- Tiles idea by @Bouncepaw: So this is possible with pure CSS actually, using the flex box model. Although, it's somewhat complicated (but of course, still possible). Check https://css-tricks.com/snippets/css/a-guide-to-flexbox/ on how it works. Another thing to point out though is it's compatibility across browsers: It's completely unsupported for IE9 and only partial support for IE10 and IE11 + luckily it's supported in Edge though. Check http://caniuse.com/#feat=flexbox for the full details. This doesn't match MediaWiki's browser compatibility matrix, which is what we generally try to be consistent with. So realistically speaking, we'd probably have to use JS and possibly pick an existing library.
Jun 21 2017
On the other hand, this extension is used on (select) WMF wikis, such as Wikimedia Commons, so it's code-reviewed and guaranteed to be compatible with recent versions of MW.
However, we have a very similar extension -- HAWelcome -- already, which supports SocialProfile, which NewUserMessage doesn't. (See also T68)
Fixed in rSHWK4226
Fixed in rSHWK4226
Jun 20 2017
Jun 17 2017
Jun 16 2017
Looks very useful. Might try and get this out soon.
Jun 15 2017
Jun 13 2017
Jun 12 2017
Jun 11 2017
In T65#3015, @Xauroflaux wrote:For me, I think that it should come down to this:
- Any and all userrights/user groups that do not disclose private information and/or pose security risks
Isn't there already a task to rewrite CreateWiki's backend?
The fix is to stop using HTTPS. I know, it sucks, but it's unsupported for a very good reason at the moment, and it'll stop working when our current certificate expires in about two months time.
Jun 8 2017
The steward group was historically created (on ShoutWiki) as a way "to deal w/ rouge admins", to quote what Pinky wrote on GlobalSettings.php many, many moons ago. As such, I'm not sure about this request. Yes, this is a request we hear more often than once a year or so, but I think we can continue dealing with these requests on a case-by-case basis and focus on getting AdminPanel into shape so that admins (etc.) are able to change the wiki's default skin, theme and such stuff without having to contact staff. That seems more beneficial for all parties IMO.
This is actually a good request we hear quite a lot.
In T210#3023, @Xauroflaux wrote:@lewiscawte I'm more concerned about EditAccount, which poses stronger risks.
Within certain parameters, yes. Email support@shoutwiki.com. This isn't a bug, and it is a widely known fact.
In T69#3026, @Xauroflaux wrote:In T69#3024, @lewiscawte wrote:Oh, really? I was under the impression we get CPM as well as CPC bids on our ad units. But then again, what do I know? I'm only the person with the access to the data.
Unless I'm mistaken, ShoutWiki gains revenue from hosting the ads. Individual users blocking them on their personal devices (there are dozens of free content blockers out there) shouldn't affect anything
In T94#3016, @Xauroflaux wrote:Which wiki does configure work with? ShoutWiki Hub only? I'm surprised that it even works at all in its curernt state, given the fact that the documentation page says it's incompatible with MediaWiki 1.28
In T69#3024, @lewiscawte wrote:Oh, really? I was under the impression we get CPM as well as CPC bids on our ad units. But then again, what do I know? I'm only the person with the access to the data.
Oh, really? I was under the impression we get CPM as well as CPC bids on our ad units. But then again, what do I know? I'm only the person with the access to the data.
@lewiscawte I'm more concerned about EditAccount, which poses stronger risks.
Yes, there are security and/or privacy issues. The applicable part here being "privacy issues". Which is why only staff can use these tools to enable us to do our jobs. We take privacy seriously, and these tools are not used unless it is necessary. LookupUser was originally written by one of the key MediaWiki developers, who is currently employed by the Wikimedia Foundation, so will have been written with security and privacy concerns in mind.
Ad blockers should not be banned or discouraged in any way. Users should be allowed to block the ads on their personal devices - ShoutWiki doesn't loose any revenue from this.
Which wiki does configure work with? ShoutWiki Hub only? I'm surprised that it even works at all in its curernt state, given the fact that the documentation page says it's incompatible with MediaWiki 1.28
For me, I think that it should come down to this:
There's a reason a number of extensions in the repository are unused. For Configure it's a case of "works okay for one wiki, not 8800+."
In T65#2171, @DeltaQuad wrote:This is important for wiki creators/founders
I'd like to see Configure and FlaggedRevs in use