The wiki should now be usable. Again, sorry for the inconvenience! Please let us again know if you run into something that seems out-of-place or simply broken.
Mar 6 2019
Thank you. Subdomain of current affected Wiki - http://remembrancerorder.shoutwiki.com/ (Subgroup - Books)
Mar 5 2019
Hi @jcbynum1 and thanks for the detailed bug report with reproduction steps -- we really appreciate taking the time to write how to try reproducing the bug! Right now the MediaWiki 1.32 database upgrades and all are still running in the background, which causes an increased load on the server, which you may have noticed as slower page loads and an increased "sluggishness" in general. As @lewiscawte noted on a similar forum thread on ShoutWiki Hub, we believe that the issue you're experiencing is connected to that and we expect the wiki creation wizard to work again once the database upgrades are done.
Mar 4 2019
Feb 25 2019
Targetting global deployment Q1 2019 using settings currently running at Brickipedia.
Feb 24 2019
Feb 21 2019
Vertex is currently terminating SSL for brickimedia.org
Jan 3 2019
Dec 26 2018
This I think is similar to @jack's preferred solution, but it makes life an absolute nightmare in terms of actually setting up that short URL...
Dec 16 2018
Wikia (ahem, "Fandom") has gotten rid of the sub-subdomains for HTTPS on different language wikis and instead place the language code after the domain name. For example, https://sims.fandom.com/es/wiki/Portada is used instead of https://es.sims.wikia.com/wiki/Portada. Typing in the sub-subdomain URL will still redirect to the correct page, but it's not used to serve content over HTTPS.
Dec 15 2018
Sounds like it could be a possibility.
I've got a number of fixes upstream that I've yet to pull down to ShoutWiki - I believe this might be amongst them?
@gbarnick So Bricki is the one wiki currently testing VipsSscaler - might be the cause of your image thumbnail problems? Can you provide a few examples and make sure to note which part is wrong/what it should be?
Not going to change this as a default - it is the position of beaurocrats and stewards to assign rights. If you've got a particular use case for an individual wiki, open a support request with firstname.lastname@example.org
This was an unexpected bug with GlobalPreferences or Gadgets? Has since been resolved.
To provide an update, I couldn't reproduce this.
I updated our Discord on this recently, so I'll provide a copy of that.
I have NEVER had a wiki locked for lack of attention, That wiki was locked last year for an import which you failed to do. I have asked for help over and over and you either refuse to help me or ignore my requests. This site is mediocre at best and with you in here it will never reach it's full potential. Since the first time i reached out to you, you have been either hostile or just plain rude. My wikis here have never been able to excell here and YOU have been no help. I have kept all emails sent to you and intend to let your poor customer service be known to whomever i can. the only failure here is you and your bad attitude. Feel free to delete any of my wikis you want since i cannot maintain them without even the slightest customer support when something does not work. Two of my wikis had the potential to be huge on this site, but we will never know will we.
Dec 11 2018
This isn't what Phabricator is for. But as you want an answer:
Dec 9 2018
Where does this stand currently?
The biggest difficulty in this idea is that users are able to set their language in MediaWiki, but nothing about the HTTP environment carries forward that language setting, so when an HTTP request is made and hits an error page, there's little-to-nothing to go off of in that request to indicate what the target language should be as it isn't querying their MediaWiki user preferences. When I think of ideas for creating a localized error page in a wiki environment, Wikipedia comes to mind with their localization in the subdomain (e.g. en.wikipedia.org, fr.wikipedia.org, etc), where you could theoretically make an nginx if statement that picks up the subdomain and returns a different error_page directive depending on the subdomain. However on ShoutWiki where the domains don't indicate the site language, that doesn't work. Even if you were to query the site's content-language response header before returning a PHP-based error_page, the site's content-language could be different than the user's customized preferences.
Dec 6 2018
Oct 22 2018
One day, Math will not suck...
Oct 2 2018
Sep 23 2018
how do I that?
Sep 19 2018
Can I atleast get an explanation?
These requests should go through Special:Contactemail@example.com but test wikis are against our Content Policy anyway.
Almost everything on this list is not set the way you're requesting on purpose.