- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 14 2017
Mar 13 2017
Should be fixed when rSHWK4162 is deployed.
Mar 5 2017
Shouldn't a default logo image be provided inside of Refreshed source code itself instead? Currently Refreshed doesn't provide any, and it's be nice if not only SW wikis could have a default but other wikis have one too.
Mar 4 2017
In T178#2544, @SamanthaNguyen wrote:What about the default logo? I believe there should be some sort of image placeholder created or have it support text, so I'll look for the upstream ticket/make a ticket upstream
Agreed with @ashley that Hub should be on the dropdown menu. What about the default logo? I believe there should be some sort of image placeholder created or have it support text, so I'll look for the upstream ticket/make a ticket upstream
Mar 3 2017
In T178#2541, @lewiscawte wrote:We should probably decide what we want the logo dropdown to contain and configure it by default that a wiki can upload its own image for that. I'd assume we want the wiki and then Hub?
The logo and the drop-down menu are separate features. The drop-down menu is controlled by MediaWiki:Refreshed-wiki-dropdown and its syntax is documented on MediaWiki.org. If it's empty (the default), the little "arrow" next to the wiki's wordmark won't be shown.
The actual site logo is configured by MediaWiki:Refreshed-this-wiki-wordmark (for desktop/normal screen resolutions) and MediaWiki:Refreshed-this-wiki-mobile-logo (for mobile/smaller screen resolutions); see the documentation for details.
We should probably decide what we want the logo dropdown to contain and configure it by default that a wiki can upload its own image for that. I'd assume we want the wiki and then Hub?
Feb 27 2017
Feb 25 2017
Feb 18 2017
Feb 16 2017
Feb 15 2017
Feb 10 2017
Fixed in rSHWK4134
Feb 7 2017
With the DeleteWiki improvements done in rSHWK4107 this is no longer an issue.
We've been running MW 1.28 since 16 December 2016, so this can be safely closed.
Feb 6 2017
As per discussion on IRC, this should be done on a case-by-case basis.
Feb 5 2017
Feb 2 2017
Any thoughts on this @isarra? btw, here's the gradients that I managed to create after converting them to CSS (the #head and #foot needs borders but the gradients can be modified again to keep the psuedo-border, or we can also use the border property too)
#head { background: #737373; background: -moz-linear-gradient( top, #737373 0%, #2a2a2a 100% ); background: -webkit-linear-gradient( top, #737373 0%, #2a2a2a 100% ); background: linear-gradient( to bottom, #737373 0%, #2a2a2a 100% ); filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#737373', endColorstr='#2a2a2a', GradientType=0 ); }
Feb 1 2017
There's no real use of workboards here. Any that exist, are probably created by accident or as testing.
Since @jack has done some level of testing and it's not broken anything, I'm all for re-enabling it as soon as the server move is done.
Instead of handling two ticketing applications at once (OsTicket and Phabricator), we'd most likely only have to use Phabricator more, potentially meaning easier to track things
Pofenrially this could also prevent less confusion for the end user as-well, as in the end-user doesn't have to figure out when to use Phabricator and when to use OsTicket. Since currently ShoutWiki uses two applications for ticket management
To repeat and slightly expand on what I said on IRC... most of the information on a wiki info page would not be easy to come by, it's fragmented across various different locations (user_groups table, wiki_list/settings, logs and various other places) and often out of date - particularly in case of wiki_settings/wiki_list (and don't get me started on the fact the database in its current form is probably the worst place to store that information right now)
Jan 31 2017
Jan 29 2017
Jan 26 2017
Jan 19 2017
"I love doing massive find and replaces in all the settings files that require loads of escaping." said no Lcawte ever.
Jan 16 2017
In T155253#2939016, @hashar wrote:Note: #easytimeline is deprecated so it is unlikely anyone will fix the underlying bug. My recommendation is to change the color name, verify it works and close this task :]
Jan 15 2017
This should now be fixed for good (ditto for T155).
There are four gradient-* images in /skins/Aurora/resources/images, and four respective CSS rules in /skins/Aurora/resources/aurora.css which use 'em:
- gradient-body.png (CSS rule which uses this: #content-inner)
- gradient-footer.png (CSS rule: #foot)
- gradient-header.png (CSS rule: #head)
- gradient-input.png (CSS rule: #full-search)