I'd have to see this in action but that sounds fine to me if it works well in execution

@MtMNC: The Medium "explore" idea would work for me. Do you think we could create some form of logic within the header that determines the width of the header categories and if it would need an "Explore" button? If for example there are only two really narrow header categories, they should be able to fit in the Medium header. If we do this, that same logic could be implemented on Big too, if for example someone wanted to add 10 header categories that just wouldn't fit on most normal screen resolutions. However if we do this, it really comes down to the end-user, because this same kind of "logic" could just be implemented into the formatting of the header categories, if for example someone knew they needed 10 categories, they could just make "Explore" the parent category. I guess this really comes down to how many levels of nesting do we want Refreshed's header categories to support, because this idea starts to push into the boundaries of "Should we just support 3 levels of header categories instead of just 2?". Your idea for Small as proposed in T151430 is perfect, this would be a great time to finally implement that:

@MtMNC I agree completely, personally I don't like the header dropdowns being triggered on-hover. Clicking seems much more intuitive and less annoying, and like you said translates to a coherent and similar touchscreen experience as with the mouse experience.

Most likely the change in ad delivery. I can't tell if the screenshot shows a logged-in user's view or not, but I know at one point there was an advertisement slot for anonymous viewers in the sitenotice on Brickipedia, so that could have been around the same time period as the screenshot.

@SamanthaNguyen Did you ever create an upstream task for this regarding the core module being skin specific? If not that would probably be the best course of action for this task.

As far as I can tell, looking at http://en.brickimedia.org/wiki/Main_Page?uselang=ar the RTL support seems mostly good. The two anomalies between LTR I can notice are the header gradient is not present in RTL and the wiki logo doesn't appear to display (however the GBC logo in the dropdown does). Not sure if these are just local issues or not?

Can @ashley recheck this issue to see if it's still a bug? I can't reproduce it.

Would it not make sense to ship the skin with a simple font-family: sans-serif and not worry about different font face compatibility across platforms? That leaves font choice entirely up to the end user which could be a good or a bad thing.

This all sounds like a good plan to me. Taking Refreshed towards another milestone would be an important step as there's been a backlog of UX and accessibility changes that need to be made with no particular order in which we're working on them. Setting a roadmap and plan for a next major release (4.x) would be a good idea I think.

Hover actuation of the dropdown menus wouldn't be bad on mobile especially with smooth transitions. I actually tried this a long time ago but the primary reason we never implemented it that way was because of mobile support. However since Refreshed 3.x the way mobile menus are handled was meant to be improved so perhaps this idea is worth revisiting.

Restarting memcached should fix it. @lcawte @SamanthaNguyen or someone else with ShoutWiki backend access will have to do that.

It makes more sense for all chat actions to be in the same log so that they remain in a proper series of events chronologically. Separating these logs only complicates that.

would allow for newlines without having to use <br /> as well which is good

Yes

Customs removed in https://github.com/Brickimedia/LocalSettings/pull/17

Customs removed in https://github.com/Brickimedia/LocalSettings/pull/17

Pulled to server

I may be wrong but I thought WikiForum had its own emoticon functionality already?

To my knowledge, no websites currently utilize our Snippet API. Brickset was the only website I worked with to implement it, and they stopped using it long ago because it negatively impacted their page load times with little benefit to either us nor Brickset.

Yes, it can be safely removed without any errors. Those lines are entirely unused.

SSL Certificates are not that expensive for what we'd need. Mutli-domain certificates are like $30/yr. Especially we rid ourselves of *.brickimedia.org domains and just make Brickipedia the only wiki on that domain we'd just need need two domains secured.

Occurred when trying to view http://en.brickimedia.org/wiki/10255_Assembly_Square. Took 3 refreshes to access the page. Not sure if I'd call this a database error as much as it is an SMW error.

The reason we had this the way it was was to keep consistency with Wikia. Not sure if we're worried on doing that anymore although it does keep things familiar for new users.

I've never been able to figure it out but I've also never looked deep into it. For as long as I can remember, it's just how it's always been with private MediaWiki installations. I don't know what WMF does differently for theirs to come through.

What are your PC specs?

/me functionality was never built into MediaWikiChat private messaging

Um, I might be wrong, but MediaWikiChat is not exclusively a Brickimedia extension, right? We build this extension for anyone to use, so it seems logical to integrate features that, even if Brickipedia might not deem it necessary, seem like a basic feature any public chatroom should have. I recall other wikis asking for a feature like this out of the extension...

@ashley No it is not

I think @UltrasonicNXT already has regular database backups on a private Dropbox. To my knowledge he's the only one with access to them however.

I'm not actively contributing to Brickimedia or its development.

I'm not actively contributing to Brickimedia or its development.

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

Duplicate of T138822

This is something that should be discussed via forum on the wikis as it is not for the sysadmins alone to decide.

I don't think importing all of them is the right way to go, some of them apply to Brickipedia exclusively and not the code in the projects. I'd just recreate relevant ones, the person who authored the tickets at GitHub can re-author them here if they're active and willing or you can just copy and paste them.

+1

If that code is functional, regardless of the code's cleanliness currently, I wouldn't oppose adding it to Brickimedia production wikis to test it and gather feedback from users.

For reference, Refreshed skin uses JavaScript and CSS hacks to make Echo work at all in the skin. Without those hacks, Echo is even less adapted for mobile display in skins that support mobile web without MobileFrontend.

Note: This was originally posted at https://github.com/Brickimedia/brickimedia/issues/437 but moved upstream as a non-Brickimedia-specific proposal.

Extension:Comments and Extension:WikiForum should be integrated with Echo as well. Should they be added as a separate task in the Social-Tools project, or continue to just use this task?

Thanks guys! @lcawte @UltrasonicNXT @ashley

In T85069#938024, @lcawte wrote:

Either to only allow a set list of groups to be shown on profile, as groups such as emailconfirmed are present, or to manually exclude groups such as emailconfirmed. Some wikis may have their own admin/automaticly added groups that would clutter this lists.

In T85069#938017, @lcawte wrote:

Secondly, I'd imagine we don't want every user right available in this area, so perhaps make an array of those we want to be displayed, this allows for custom groups to be added? I'm not entirely sure how the Brickimedia code does this but I'd hope something like that exists.