FANDOM


  • MisterWoodhouse
    MisterWoodhouse closed this thread because:
    Closing old release thread to focus feedback onto newest thread
    16:43, April 15, 2020

    Hey gang!

    First off, I want to thank all of you for all the feedback you've provided since the Unified Community Platform went live last week (and all the feedback for that as well)! We've been tracking all of it, making bug tickets where it's immediately actionable, and triaging with the developers.

    Here are the highlights of the most recent release, which went out about an hour before this post:

    Preferences

    - The preferred editor preference was successfully transitioned to handle the two modes of the 2017 Editor, rather than the discrete editor options of the legacy platform

    Message Wall

    - Registered user notifications have been corrected for Message Wall posts and replies

    - Message Wall replies sometime being attributed to the wall owner, rather than the writer, have been corrected

    - Message Wall entry point errors have been resolved

    Galleries

    - Gallery Builder for UCP fixed

    - Galleries additional properties are now working

    - Design improvements for slider galleries

    - Inserted galleries should now be visible within the visual editor

    Theming

    - Theming added for Special:NewPages

    - Theming added for Special:ListGlobalUsers

    In addition to these fixes and additions, we made a number of hotfixes for more urgent matters over the past week. There are a lot of other fixes and tickets being actioned right now. These are the highlights of what made it into today's release.



    Tracking Feedback


    As I mentioned, we're tracking user feedback on the UCP. We have a shared repository for it where people from different user-facing teams at Fandom are all recording what y'all have to say about the platform, specific features, etc. and making note of when feedback is repeated by multiple users. I want to dive in on a couple pieces of that feedback here.

    Wiki Activity

    The biggest piece of feedback we're tracking is WikiActivity versus Recent Changes and I owe you an apology on this one. I did not communicate this change ahead of time and, as such, it caught several of you off-guard. WikiActivity (also known as MyHome) is a custom Fandom extension designed to encourage new users to see where the wiki was being edited and dive in. It was not intended as an admin tool and, due to this focus, we missed the adapted use case from admins. We hear the feedback loud and clear that several of you prefer WikiActivity to Recent Changes when it comes to at-a-glance moderation of your wikis. We also heard the feedback that Recent Changes is not as accessible as WikiActivity for users who have different consumption needs.

    We have two things we'd like to see play out in the near future: 1) We would like to see if WikiActivity was adapted as a tool for moderation on the legacy platform because it was presented front and center as a tool while Recent Changes was not and 2) We would like WikiAcitivity users to give Recent Changes a fair chance to see if it can meet your needs.

    Recent Changes is maintained by the Wikimedia Foundation as part of MediaWiki, so keeping it up to date as we move forward with future MediaWiki releases is rather developer light in terms of resource allocation. In terms of futureproofing, finding a way forward with Recent Changes is the smart decision from a platform maintenance perspective, but we want to make sure it's also the smart decision from a user perspective.

    One thing I value in our editor population quite a bit is how y'all are able to make incredible use out of every tool we provide, sometimes beyond our intented use cases (as demonstrated here and with features like Special:Forum). It is my hope that Recent Changes can be a tool that works for you. If it's not that in its current form, let's work together to see if we can tweak it in order to get there for you. If not, we can reassess and find a good way forward.

    CSS and JS

    Many of you noticed that robust customization is not yet available on the Unified Community Platform. That is not a bug, that is intentional. Custom JS relies upon a content review system which is not yet ported from the legacy platform, so it will not be enabled until that happens. Having the simple customization options available now allows us to have a better baseline for chasing down core functionality bugs without issues being confounded by community customizations. Once we have the platform in a good place with core stability, we can let you get back to your usual creative ways :)

    One Final Thought

    I'd like to give a big shout out to the UCP Supertester group. This is a group of 82 staffers, Wiki Managers, and Content Team Members who have done a phenomenal job with internal testing of the platform. Without their incredible contributions, we would not be here talking about UCP releases in anything but an abstract sense.

      Loading editor
    • Thanks for the bug fixes!

        Loading editor
    • MisterWoodhouse wrote:

      Wiki Activity

      The biggest piece of feedback we're tracking is WikiActivity versus Recent Changes and I owe you an apology on this one. I did not communicate this change ahead of time and, as such, it caught several of you off-guard. WikiActivity (also known as MyHome) is a custom Fandom extension designed to encourage new users to see where the wiki was being edited and dive in. It was not intended as an admin tool and, due to this focus, we missed the adapted use case from admins. We hear the feedback loud and clear that several of you prefer WikiActivity to Recent Changes when it comes to at-a-glance moderation of your wikis. We also heard the feedback that Recent Changes is not as accessible as WikiActivity for users who have different consumption needs.

      As one of the annoying advocates that voiced about this (and voiced, and voiced...), I am very happy to hear that you have reconsidered the removal of WikiActivity. I hope I wasn't to the point of harassing or anything :P

      I noticed no notes on Source Editor being more than lackluster (no colour diferentation, small @rse box, preview/public needing to be locked at top and not scroll to bottom and if we are possibly getting a wikitext toolbar back) and that was my more important concern. But maybe that is still being looked at.

      But all in all what a great week's (weekish+) work on fixing these bugs so far- I was not expecting such expediency! This definitely is reassuring and show what an amazing staff group you have.

        Loading editor
    • Hollowness wrote:

      I noticed no notes on Source Editor being more than lackluster (no colour diferentation, small @rse box, preview/public needing to be locked at top and not scroll to bottom and if we are possibly getting a wikitext toolbar back) and that was my more important concern. But maybe that is still being looked at.

      We're definitely tracking feedback on the new editor. At the risk of sounding blunt, things which are objectively broken are easier to triage than subjective preferences, since the latter requires much more consideration and more teams involved.

        Loading editor
    • MisterWoodhouse wrote:

      Hollowness wrote:

      I noticed no notes on Source Editor being more than lackluster (no colour diferentation, small @rse box, preview/public needing to be locked at top and not scroll to bottom and if we are possibly getting a wikitext toolbar back) and that was my more important concern. But maybe that is still being looked at.

      We're definitely tracking feedback on the new editor. At the risk of sounding blunt, things which are objectively broken are easier to triage than subjective preferences, since the latter requires much more consideration and more teams involved.

      Oh no you miss understand me, that is completely and absolutely understandable and I wouldn't have it any other way. But even knowing it's (or what things are) being looked at as a footnote is helpful information. Especially, when people are posting raging comments. I like to reassure myself but also others when I see them freaking out :P

      It is less a worry (to me at least) when it is a bug or broken because I know it will take precedence. That is why the little other things concern me (and perhaps others) more. Because waiting months just to know it is being looked into is a long time to fret over something.

        Loading editor
    • The sheet we're using to track feedback is big and we've got a lot of notes. It would take me a while to distill it down for folks. I mostly wanted to highlight the two big patterns of feedback we heard over the past week that weren't related to bugs.

        Loading editor
    • MisterWoodhouse wrote: The sheet we're using to track feedback is big and we've got a lot of notes. It would take me a while to distill it down for folks. I mostly wanted to highlight the two big patterns of feedback we heard over the past week that weren't related to bugs.

      No worries, that is why I disclaimed: But maybe that is still being looked at.

        Loading editor
    • Can I be an advocate FOR the removal of WikiActivity?



      Because it shows which categories are added and our template adds a category "Deceased" as soon as the Death field is filled out, many people were spoiled by one glance. After complaints, we had to build in a function into the template that wouldn't add the category until a month after the edit to the Death field... which led to clueless people manually adding the Deceased category... which led to making an AbuseFilter on adding that category. All that work for a feature none of the admins were using for quick at a glance moderation.



      That type of moderation has tools built into the new RC, with filters for users based on edit counts, image uploads, it's all much easier.

        Loading editor
    • MisterWoodhouse wrote:

      Preferences

      - The preferred editor preference was successfully transitioned to handle the two modes of the 2017 Editor, rather than the discrete editor options of the legacy platform

      Setting this as a dropdown removed the ability to use the extremely basic editor, which was the only option for the people who didn't want to load the js-heavy Visual/Source Editor.

      2020-03-15 20-033 grim

      It loaded instantly as part of the page, whereas the VE takes a good 2-5 seconds no matter how long the page you're editing is. Please return the ability to use the default mediawiki editor (the first entry, 2003)!

      Edit: If you disable browser JS you get the default editor, but then you lose the abilty to add syntax highlighting. An option to "Use non-JavaScript interface" like in the Watchlist and Recent Changes sections for the editor would be much appreciated!

        Loading editor
    • Himmalerin wrote:

      MisterWoodhouse wrote:

      Preferences

      - The preferred editor preference was successfully transitioned to handle the two modes of the 2017 Editor, rather than the discrete editor options of the legacy platform

      Setting this as a dropdown removed the ability to use the extremely basic editor, which was the only option for the people who didn't want to load the js-heavy Visual/Source Editor.

      2020-03-15 20-033 grim

      It loaded instantly as part of the page, whereas the VE takes a good 2-5 seconds no matter how long the page you're editing is. Please return the ability to use the default mediawiki editor (the first entry, 2003)!

      Edit: If you disable browser JS you get the default editor, but then you lose the abilty to add syntax highlighting. An option to "Use non-JavaScript interface" like in the Watchlist and Recent Changes sections for the editor would be much appreciated!

      Oh ahh. I too prefer the non-js source editor and I didn't have a chance to check what you meant till now. Hopefully this will be adjusted.

        Loading editor
    • I found a hacky way to force the default mediawiki editor. First, go to Special:Preferences and make sure your preferred editor is set to the Source Editor.

      Install uBlock origin or another program that supports Adblock Plus-compatible filters. In uBlock origin's settings, go to the "My filters" tab and paste the following code in, then press "Apply changes"

      ! Prevent the Fandom's VisualEditor from loading
      user.defaults*
      

      When you go to edit a page, add &venoscript=1 to the end of the url. You should now get the default mediawiki editor.

      Note: Doing this can break things. Most notably, the lazyloading masthead never loads and it prevents you from switching tabs in Special:Preferences.

      It's very manual (needing to add &venoscript=1 whenever you want to edit a page), but hey, it works :p



      See Thread:1828522#34 for better instructions!

        Loading editor
    • Himmalerin wrote: It's very manual (needing to add &venoscript=1 whenever you want to edit a page), but hey, it works :p

      I think I might hold out on a fix on this but at least we know the workaround! XD

        Loading editor
    • Himmalerin wrote: I found a hacky way to force the default mediawiki editor. First, go to Special:Preferences and make sure your preferred editor is set to the Source Editor.

      Install uBlock origin or another program that supports Adblock Plus-compatible filters. In uBlock origin's settings, go to the "My filters" tab and paste the following code in, then press "Apply changes"

      ! Prevent the Fandom's VisualEditor from loading
      user.defaults*
      

      When you go to edit a page, add &venoscript=1 to the end of the url. You should now get the default mediawiki editor.

      Note: Doing this can break things. Most notably, it prevents you from switching tabs in Special:Preferences.

      It's very manual (needing to add &venoscript=1 whenever you want to edit a page), but hey, it works :p

      you could use tampermonkey or etc to add the url param to every edit link (should just be appending to the url in #ca-edit)

      you might also be able to modify that filter to only block when ?veaction=edit is in the url too

        Loading editor
    • Sophiedp wrote:

      you could use tampermonkey or etc to add the url param to every edit link (should just be appending to the url in #ca-edit)

      you might also be able to modify that filter to only block when ?veaction=edit is in the url too

      I'm not sure it's possible to do any logic (if ?veaction=edit then block this url), but that gave me the idea to avoid blocking it on any other sites (mediawiki also uses it). So the new code is

      ! Prevent the Fandom's VisualEditor from loading
      ||fandom.com/*user.defaults*
      

      Edit: Here's a quick js script for tamper/grease/violentmonkey.

      // ==UserScript==
      // @name        UseDefaultMediaWikiEditor - fandom.com
      // @namespace   Violentmonkey Scripts
      // @match       https://*.fandom.com/*
      // @grant       none
      // @version     1.0
      // @author      User:Himmalerin
      // @description Add '&venoscript=1' to the end of edit urls to enable the use of the Default MediaWiki Editor.
      // ==/UserScript==
       
      var editLink = document.getElementById('ca-edit');
      editLink.href = editLink.href + '&venoscript=1';



      See Thread:1828522#34 for better instructions!

        Loading editor
    • One of the issues I have with the new Recent Changes (as opposed to the old Recent Changes and Wiki Activity) is a compatibility issue.  The filters never load.  This is an "at least I can still change my phone's batteries" issue, so I recognize this particular plight will be ignored by Fandom.  Bottom line, though, RC with filters is a powerful tool that I do use, but RC without filters is harder to sift through than the old WA.

      Since you mentioned wanting to know if admin WA usage is due to it being front and center, while RC is not... there is probably some truth to that.  I use both, and it's certainly slightly more convenient to start with WA due to its prominent placement.  If the placement were reversed and no other changes were made, I would still use both, though I might rely more heavily on RC than I do now.  What would convince me to move off of WA altogether without being forced off?  A toggle on how the edit list is organized.  But I can't tell if that is an option that has been added to the new RC's filters because... well.

      Anyway, WA is organized in a purely (reverse-)chronological order of edits.  The old RC groups edits to the same page within the same day, so older edits sometimes appear above newer edits if there is an even newer edit to the same page as the older edits.  Both of these ways of organizing the data have merits, and it is precisely this reason that both WA and RC are useful tools for me as an admin.  Everything else being equal, the ability to toggle to chronological mode in RC would pretty much instantly obsolete WA for me.  Without that toggle switch, I would still want both, even if RC were the more convenient one to get to.

      Aesthetically, I prefer WA over RC, but that's a relatively minor issue for me.  While in an ideal world, both the tool and the product are beautiful, I'd rather have an ugly tool that works well to make beautiful things than a beautiful tool that can only make mediocre things.

        Loading editor
    • My question will apply to the UCP, not the latest release as such.

      As far as I'm concerned, Phase I will be complete (at least) within 5 months, ending in all wikis being moved over to the UCP. Will it then be possible to have an extension enabled on your wiki at request, or do we more likely have to wait until Phase II is launched?

      I suppose that before enabling any extension, a list of those available needs to be made, which prompts me to think the latter assumption is more likely.

        Loading editor
    • Mustafar29 wrote: My question will apply to the UCP, not the latest release as such.

      As far as I'm concerned, Phase I will be complete (at least) within 5 months, ending in all wikis being moved over to the UCP. Will it then be possible to have an extension enabled on your wiki at request, or do we more likely have to wait until Phase II is launched?

      I suppose that before enabling any extension, a list of those available needs to be made, which prompts me to think the latter assumption is more likely.

      We'll have to review our extension activation policy once this is all said and done, but yes, we'll have new extensions for y'all to work with.

        Loading editor
    • Regarding RecentChanges V. WikiActivity, I can certainly see why WikiActivity would be good for at-a-glance monitoring. That said, I personally don't really use it except to keep track of badges from the Achievements extension. From what I can tell, that is the only thing listed in WikiActivity that isn't listed in RecentChanges.

      As for the accessibility question, I can definitely see that playing a potentially significant role. WikiActivity is linked to from multiple places so it is easy to stumble upon or refind; not so for RecentChanges. A lot of users, including myself, rely on lists and dashboards to remind us what special pages exist. When pages such as AdminDashboard and SpecialPages only list a subset, that means the others don't get as much love. For instance, it was a long time before I discovered the joys of Diff and I only recently discovered Permanentlink. Those particular examples may not be extremely relevant to most wikis but the point is that some special pages don't get used simply because users don't know they are there.

      Regarding the UCP RecentChanges, it seems there is a sizable query string that gets attached automatically to the URL. Is that because of my personal settings or is that just the way it is? I'll save my breath on the filter interface because apparently modern web design in general, not just Fandom, disagrees with me on that aspect.

      Regarding these threads, if the intent is to keep the focus on current issues, perhaps it would be make sense have the following sections in your initial post.

      1. bullet list of previously resolved issues
      2. details on newly solved issues
      3. bullet list of known/in-the-works issues

      You already have #2 and a bit of #3; the only one missing is #1.

        Loading editor
    • This is on my profile on a new UCP wiki... I sure work fast.

      UCP Phase1-Lots of edits

        Loading editor
    • Oh yeah. I forgot about that. Somehow, I have just below 9,500 edits. I have no idea where it could be getting that number from.

        Loading editor
    • I see advantages of having WikiActivity and RecentChanges; I still use both. WikiActivity is great for more causal editors because it hides changes that aren't likely to apply to these users: logs, template edits, reply removals, etc. The feed, especially on wikis with lots of comments, makes moderation in a way faster. Though seeing how comments are going to be overhauled, there's undoubtably a capability issue. Only having RecentChanges isn't the end of the world for me, though it could potentially be too much for those used to the simple layout of WikiActivity.

        Loading editor
    • I'm really happy, that WikiActivity was confirmed to be removed. Yes, all changes will display, BUT - RecentChanges got big overhaul. And you can set what you want to see in RC through filters. So if you want to see content shown in WikiActivity, in Active Filters, you need to check "Page Edits" and "Page Creation". Then go to Namespaces and check "(main)","Talk","(Project) community", "(project) community talk", "Category" and "Category Talk". Then click on "Bookmark" next to bin, name that filter and save it.

        Loading editor
    • It is easier to have something and not use it, than need it and not have it. However, this for and against the removal of current legacy features is going to just bring more heated debate. Clearly many people were upset about removing it and I doubt the upset of it not removed is at the same level for keeping it. But there are some very real reasons for it's obstruction to some users. If this shows anything maybe it should be something enabled and/or disabled in the admin dash board or preferences.

        Loading editor
    • Bug: The UCP VisualEditor doesn't support the preloadparams[X] url parameter (where X is a number, for example preloadparams[0]). It does support preloadparams[] (with nothing inside the brackets). This prevents the use of mw:Extension:Inputbox's preloadparams[] parameters.

      preloadparams[X] does work on MediaWiki however. You can test the difference in behavior using the inputbox at the bottom of mw:User:Wychmire (mediawiki) and w:c:wreckit-woodhouse:User:Himmalerin (UCP Fandom wiki). You may need a mediawiki account to gain access to the VisualEditor on MediaWiki.

      edit: In both cases the words "News and Announcements" should appear in the editor, but with the UCP editor instead you get the variable "$1"

        Loading editor
    • To clarify for anyone who is confused, the [x] format shows up in the query string generated by the extension (and appears to be 0-indexed). There doesn't appear to be any mention of this on the main documentation page; neither in the descriptions nor in the examples. Interestingly enough, it seems this may be something that changes with other parameters. If you try the example on the documentation page, the query string doesn't use this format. However, the example that Himmalerin linked to does even though I would think it is using the same extension and MediaWiki versions. Both examples behave the same whether on the MediaWiki site or on Fandom's UCP.

      Both wikis are supposedly using InputBox 0.3.0. The MediaWiki site is using MediaWiki 1.35 instead of 1.33; but I would have thought that shouldn't matter as this seems like something that would be the responsibility of the extension.

        Loading editor
    • I did some quick debugging on w:c:wreckit-woodhouse:User:Himmalerin, the issue is the Inputbox's prefix parameter when used in conjunction with Inputbox's preloadparams parameter. Everything works with the two together on mediawiki, but something is going wrong on the UCP wikis.

      Without prefix the url gets preloadparams[]. No number regardless of if there are multiple instances of preloadparams[]. (there are just multiple instances of preloadparams[])

      Inputbox's "version" is 0.3.0, but it receives continuous updates. It's possible that they fixed something after the version Fandom downloaded. I don't see anything implies bug fixes in the commit history, but that doesn't mean it didn't happen.

        Loading editor
    • Again, just to clarify (since I don't think this is clear in Himmalerin's post), the prefix parameter works fine for what it is supposed to do. The issue is that, when prefix and preloadparams[] are used together, preloadparams[] gets encoded differently in the URL query string. For some reason, UCP can't handle this different encoding.

      I find it odd that they would have this in the extension. If it was a mistake, it seems odd that the fix would be to recognize the different encoding rather than fix the encoding error.

        Loading editor
    • Not... enough... testing.

        Loading editor
    • I'm pretty much glad you guys aren't removing Wiki Activity immediately in the UCP. I'm an admin in a couple of wikis and I check on them several times to frequently since they have a long history of vandalism.

      Also, Recent Changes does not show pictures and videos being shown unlike Wiki Activity.

      However, I can get used to Recent Changes since Wiki Activity doesn't show users removing or closing threads, and even pictures being replaced to irrelevant pics which happened on a wiki two months ago.

      TLDR: Wiki Activity is better than Recent Changes when it comes to moderating, but both have advantages and disadvantages.

        Loading editor
    • Skyline97 wrote: I can get used to Recent Changes since Wiki Activity doesn't show users removing or closing threads[...]

      A yes, threads, those things that will still exist in UCP :P

        Loading editor
    • I notice the $wgRestrictDisplayTitle rule is enabled in UCP. Will this be the case in the near future?

        Loading editor
    • Andrewds1021
      Andrewds1021 removed this reply because:
      never mind, apparently it isn't
      17:04, March 22, 2020
      This reply has been removed
    • I've come across a better way with the help of the awesome folks on the Dev discord server.

      Install uBlock Origin or another extension that supports Adblock Plus-compatible filters. In uBlock origin's settings, go to the "My filters" tab and paste the following code in, then press "Apply changes"

      ! fandom.com - Prevent the loading of the VisualEditor
      ||fandom.com/*ext.visualEditor.core*
      

      Install the Violentmonkey extension (or Tampermonkey or Greasemonkey) and create a new user script with the following contents:

      // ==UserScript==
      // @name        UseDefaultEditor - fandom.com
      // @namespace   Violentmonkey Scripts
      // @match       https://*.fandom.com/*
      // @grant       none
      // @version     1.0
      // @author      User:Himmalerin
      // @description Prevent the use of the UCP VisualEditor
      // ==/UserScript==
      // Add venoscript to the end of the edit URL
      document.getElementById('ca-edit').href = document.getElementById('ca-edit').href + '&venoscript=1';
      // Remove the click-jacking the edit button uses. Wait for a bit to make sure jQuery is loaded
      setTimeout(function(){$('#ca-edit').off('click');},1000);

      Install Stylus (or stylish) and create a new style with the following contents

      .ve-init-mw-desktopArticleTarget-title, /* Hide the VE article title */
      .ve-init-mw-desktopArticleTarget-loading-overlay, /* Hide the loading bar*/
      .ve-init-mw-tempWikitextEditorWidget, /* Hide temporary text editor */
      .ve-init-mw-desktopArticleTarget-toolbarPlaceholder, /* Hide the loading bar background */
      .ve-oasis-header, .oo-ui-toolbar /* Hide the toolbar */ { display: none; }
       
      /* Unhide the editor */
      #mw-content-text { display: block !important; }
       
      /* Remove extra space around the editor */
      .ve-init-mw-desktopArticleTarget-originalContent { padding: unset; }
       
      /* Remove opacity from the title */
      .page-header__title.ve-init-mw-desktopArticleTarget-uneditableContent { opacity: unset; }

      When personal customization becomes a thing the JS and CSS can be placed in your personal pages instead of running them through extensions.

      Doing the above instead of my previous steps doesn't break anything beside the editor (meaning the masthead and preferences still work)

      This shouldn't be required though, editors should get the option of opting out of the slow-loading JS mess that is the VisualEditor.

        Loading editor
    • I am not a fan of the new editor but I am not sure my distaste for it is so grate that I am willing to go to that extent just to avoid it. If this won't block anything else, why would you need to avoid loading CSS/JS via extensions?

        Loading editor
    • your first line of js could be shorted btw https://chito.ge/6Tqxg8r.png

      document.getElementById('ca-edit').href = document.getElementById('ca-edit').href + '&venoscript=1';
      document.getElementById('ca-edit').href += '&venoscript=1';
      
        Loading editor
    • If comments don't get replaced with a Mobile friendly counterpart, what will become of them? Will they exist on the wiki still, or will they be deleted like Top 10 Lists? I'm hoping that they can at least be preserved but not show up on articles since I hate to lose things for transparency's sake.

        Loading editor
    • Based on information I have read thus far, comments should be getting a replacement similar to Message Walls and Forum. In other words, it should be getting a Feeds-based replacement.

        Loading editor
    • MisterWoodhouse wrote:
      Hey gang!

      First off, I want to thank all of you for all the feedback you've provided since the Unified Community Platform went live last week (and all the feedback for that as well)! We've been tracking all of it, making bug tickets where it's immediately actionable, and triaging with the developers.

      Here are the highlights of the most recent release, which went out about an hour before this post:

      Preferences

      - The preferred editor preference was successfully transitioned to handle the two modes of the 2017 Editor, rather than the discrete editor options of the legacy platform

      Message Wall

      - Registered user notifications have been corrected for Message Wall posts and replies

      - Message Wall replies sometime being attributed to the wall owner, rather than the writer, have been corrected

      - Message Wall entry point errors have been resolved

      Galleries

      - Gallery Builder for UCP fixed

      - Galleries additional properties are now working

      - Design improvements for slider galleries

      - Inserted galleries should now be visible within the visual editor

      Theming

      - Theming added for Special:NewPages

      - Theming added for Special:ListGlobalUsers

      In addition to these fixes and additions, we made a number of hotfixes for more urgent matters over the past week. There are a lot of other fixes and tickets being actioned right now. These are the highlights of what made it into today's release.



      Tracking Feedback


      As I mentioned, we're tracking user feedback on the UCP. We have a shared repository for it where people from different user-facing teams at Fandom are all recording what y'all have to say about the platform, specific features, etc. and making note of when feedback is repeated by multiple users. I want to dive in on a couple pieces of that feedback here.

      Wiki Activity

      The biggest piece of feedback we're tracking is WikiActivity versus Recent Changes and I owe you an apology on this one. I did not communicate this change ahead of time and, as such, it caught several of you off-guard. WikiActivity (also known as MyHome) is a custom Fandom extension designed to encourage new users to see where the wiki was being edited and dive in. It was not intended as an admin tool and, due to this focus, we missed the adapted use case from admins. We hear the feedback loud and clear that several of you prefer WikiActivity to Recent Changes when it comes to at-a-glance moderation of your wikis. We also heard the feedback that Recent Changes is not as accessible as WikiActivity for users who have different consumption needs.

      We have two things we'd like to see play out in the near future: 1) We would like to see if WikiActivity was adapted as a tool for moderation on the legacy platform because it was presented front and center as a tool while Recent Changes was not and 2) We would like WikiAcitivity users to give Recent Changes a fair chance to see if it can meet your needs.

      Recent Changes is maintained by the Wikimedia Foundation as part of MediaWiki, so keeping it up to date as we move forward with future MediaWiki releases is rather developer light in terms of resource allocation. In terms of futureproofing, finding a way forward with Recent Changes is the smart decision from a platform maintenance perspective, but we want to make sure it's also the smart decision from a user perspective.

      One thing I value in our editor population quite a bit is how y'all are able to make incredible use out of every tool we provide, sometimes beyond our intented use cases (as demonstrated here and with features like Special:Forum). It is my hope that Recent Changes can be a tool that works for you. If it's not that in its current form, let's work together to see if we can tweak it in order to get there for you. If not, we can reassess and find a good way forward.

      CSS and JS

      Many of you noticed that robust customization is not yet available on the Unified Community Platform. That is not a bug, that is intentional. Custom JS relies upon a content review system which is not yet ported from the legacy platform, so it will not be enabled until that happens. Having the simple customization options available now allows us to have a better baseline for chasing down core functionality bugs without issues being confounded by community customizations. Once we have the platform in a good place with core stability, we can let you get back to your usual creative ways :)

      One Final Thought

      I'd like to give a big shout out to the UCP Supertester group. This is a group of 82 staffers, Wiki Managers, and Content Team Members who have done a phenomenal job with internal testing of the platform. Without their incredible contributions, we would not be here talking about UCP releases in anything but an abstract sense.

      Yeah, but can you help me? I can't find an infobox.

        Loading editor
    • The infoboxbuilder is not yet enabled. If you're struggling, build it on an old test or sandbox wiki and then copy paste the source code.

        Loading editor
    • Also, there appears to have no comments and no messages.

        Loading editor
    • There is a message wall, but as it's built like Discussions, it doesn't appear in Recent Changes. What exactly comments will look and work like isn't locked in yet so it's not yet implemented. Current UCP is a very minimal version and undoubtedly everyone's eagerly anticipating more basic functionality.

        Loading editor
    • Tupka217 wrote:
      The infoboxbuilder is not yet enabled. If you're struggling, build it on an old test or sandbox wiki and then copy paste the source code.

      I'm just gonna wait ti'l we get more updates.

        Loading editor
    • Re: preloadparams[X] not working (Posts #24, #25, #26, and #27), it should be fixed in MW 1.34. Unfortunately that removes the biggest hype-point of UCP for me, but I'm hopeful that we'll get MW 1.34 in the not-to-distant future.

      But this wouldn't be such a big deal if we had the 2010 wiki editor available since the issue only affects the VisualEditor.

        Loading editor
    • Himmalerin wrote:
      Re: preloadparams[X] not working (Posts #24, #25, #26, and #27), it should be fixed in MW 1.34. Unfortunately that removes the biggest hype-point of UCP for me, but I'm hopeful that we'll get MW 1.34 in the not-to-distant future.

      But this wouldn't be such a big deal if we had the 2010 wiki editor available since the issue only affects the VisualEditor.

      What are you talking about?

        Loading editor
    • Did you read posts #24, #25, #26, and #27 before asking that question?

      MediaWiki supports a url parameter called preloadparams[] which can be used in conjunction with mw:Extension:InputBox to prefill variables in templates. For example, I was planning on making use of it on my wiki where I'm going to use DPLforums. The process goes something like this:

      • Have a template with a preloadparams variable. preloadparams variables are a dollar sign followed by a number, e.g. $1, $2, $3, and so on. The simplified version of my instance looks like this:
      {{Forum/Header|$1|type=topic}}
      • Have a page with an inputbox. You need to set type=create, preload={the template you created above}, and preloadparams[]={the value to replace $1 with} The simplified version of my instance looks like this:
      {{#tag:inputbox |
      type=create
      prefix=Forum:gd/
      preload=Template:Forum/Topic
      preloadparams[]=gd
      }}
      
      • Type something into your inputbox and press the "Create Page" button. The VisualEditor will load but instead of being
        {{Forum/Header|gd|type=topic}}
        like it should be, the contents will instead be
        {{Forum/Header|$1|type=topic}}
        If you force the MWDE like I explained in post #34 the value will be gd as it should be.

      The issue is that when you set prefix= in the input box the generated preloadparams[] in the url is indexed so you get preloadparams[0]=gd instead of preloadparams[]=gd. The VisualEditor prior to MediaWiki 1.34 does not support indexing, so you get $1 instead of gd.

        Loading editor
    • Okay...

        Loading editor
    • Although I am very appreciative to Himmalerin for setting us up with a non js source editor work-a-round, I do hope this doesn't mean: staff won't make it a viable option. I have almost always been only source editor and even when trying to see or edit on other editors to try to help those who do not use source editor it's slower and buggy (many times in the past- with UCP I can't say). So having source editor on js seems rather odd and retrogressive IMO.

      I am (and this doesn't make me any better nor more important than other users- it is just to let staff know my editing style (which may be an editing style they might want to consider in the UCP)) a high count editor. Quick example just to express the gravity of edits 90k+ in a wiki that I have had only 10 months (and over 10k edits on another wiki earlier this year) but with mass edit, mass rename, mass categorization. To give an idea even without mass editors, mass categorization, I have in the past I still have done 10k edits in a month (mostly helpful, some me fixing my own mistakes and some just in my sandbox testing templates and styles). I am one that has made and edit just to realize I made and error and have to go right back in and fix. And with js source editor it would take me more than twice as long (I'd be ripping my hair out). This (js source) would not help me be a better editor by making smarter edits if that is an angle you'd try to sell me- it would more likely make me slow down or stop my efforts all together.

      I just would prefer to not worry about a convoluted way of disabling js on my browser and/or scripts (I am not good with js scripts) and css- just to edit on what is suppose to be an improved platform. And if I had to I might find myself another why did we bother to upgrade/change it back types because well slower more difficult editing does come across as retrogressive.

        Loading editor
    • Preferences I just like it if you make a wider writting space for mobile editors. Its just FRUSTRATINGLY uncomfortable to edit.

        Loading editor
    • Pablo Solis Ledesma wrote: Preferences I just like it if you make a wider writting space for mobile editors. Its just FRUSTRATINGLY uncomfortable to edit.

      I too personally have complained about the writing space but not for mobile (though I guess it is a problem that transcends both ways of editing). It is definitely one of my top suggestions I want to see improved.

        Loading editor
    • Hollowness wrote:

      Pablo Solis Ledesma wrote: Preferences I just like it if you make a wider writting space for mobile editors. Its just FRUSTRATINGLY uncomfortable to edit.

      I too personally have complained about the writing space but not for mobile (though I guess it is a problem that transcends both ways of editing). It is definitely one of my top suggestions I want to see improved.


      Yeah. It seems its a shared trouble. Its also one of my top suggestions. I just hope they csn listen.

        Loading editor
    • Pablo Solis Ledesma wrote: Preferences I just like it if you make a wider writting space for mobile editors. Its just FRUSTRATINGLY uncomfortable to edit.

      A specific editor for mobile users is coming!

        Loading editor
    • I know it isn't what Pablo Solis was talking about but the desktop source view could use widening as well.

        Loading editor
    • Andrewds1021 wrote: I know it isn't what Pablo Solis was talking about but the desktop source view could use widening as well.

      This feedback has been noted. Thanks!

        Loading editor
    • may i ask any idea when all these new changes will be released to all old wikis?

        Loading editor
    • We don't have an ETA to announce for when migrations will begin, but the really big UCP blog on the vision and process explains the stage schedule in an abstract sense.

        Loading editor
    • so i attempted to make a bot account on the new platform but it didnt work when  i copy+pasted the login Please help me.






      Bot password
        Loading editor
    • for somereason it says no account found and i did make the bot.

        Loading editor
    • Cocopuff2018 wrote: so i attempted to make a bot account on the new platform but it didnt work when  i copy+pasted the login Please help me.

      Pretty sure that's not how bot passwords are supposed to work. You should only be able to log in with your "bot" account via MediaWiki API, that is, while using bot software such as AWB, Pywikibot or others.

        Loading editor
    • im most likely going to leave it alone  dont wanna mess anything up for now. as for later on ill mess around with it more.

        Loading editor
    • KockaAdmiralac wrote:

      Cocopuff2018 wrote: so i attempted to make a bot account on the new platform but it didnt work when  i copy+pasted the login Please help me.

      Pretty sure that's not how bot passwords are supposed to work. You should only be able to log in with your "bot" account via MediaWiki API, that is, while using bot software such as AWB, Pywikibot or others.

      I was under the impression BotPasswords still allowed logging in on a browser. At least I hope so. I do it a lot.

        Loading editor
    • did you try it yet?

        Loading editor
    • I have no bot flag on my test wiki.

        Loading editor
    • can you link me ur wiki im going to check out the whole bot thing to see how you did it?

        Loading editor
    • I did not do anything yet.

        Loading editor
    • Tupka217 wrote: I was under the impression BotPasswords still allowed logging in on a browser.
      MediaWiki.org said: Clients using bot passwords can only access the API, not the normal web interface.

      Bot passwords are for your own account though, they aren't meant to replace bot accounts as far as I'm aware.

        Loading editor
    • im gonna look into it more and see.

        Loading editor
    • MisterWoodhouse wrote:

      Pablo Solis Ledesma wrote: Preferences I just like it if you make a wider writting space for mobile editors. Its just FRUSTRATINGLY uncomfortable to edit.


      A specific editor for mobile users is coming!

      Thank you :D

        Loading editor
    • Pablo Solis Ledesma wrote:

      MisterWoodhouse wrote:

      Pablo Solis Ledesma wrote: Preferences I just like it if you make a wider writting space for mobile editors. Its just FRUSTRATINGLY uncomfortable to edit.


      A specific editor for mobile users is coming!

      Thank you :D

      We've been talking about it for several months now ;)

      We'll have more about it when it gets closer to release.

        Loading editor
    • CW-Eaves wrote:

      One of the issues I have with the new Recent Changes (as opposed to the old Recent Changes and Wiki Activity)...

      I agree with everything in this comment.

        Loading editor
    • TikTokToxi wrote: I notice the $wgRestrictDisplayTitle rule is enabled in UCP. Will this be the case in the near future?

      I'm hoping not (or that it can be turned off on a per unit basis), because one of my wikis makes heavy use of it to work around problematic names for things referenced inside the game it's about.

        Loading editor
    • Vandraedha wrote:

      TikTokToxi wrote: I notice the $wgRestrictDisplayTitle rule is enabled in UCP. Will this be the case in the near future?

      I'm hoping not (or that it can be turned off on a per unit basis), because one of my wikis makes heavy use of it to work around problematic names for things referenced inside the game it's about.

      Then I'd hope yes if I were you. This function restricts it, so you'd like it disabled I'd reckon.

        Loading editor
    • Hi there! I just wanted to drop a couple of things I have run into while editing for feedback!

      • While editing in source mode, sometimes random letters and spaces are added while writing that I haven't actively typed. When removing these letters or spaces I can't touch them most of the time and backspace removes my actual words instead. (Not a keyboard issue, only happens on the new wiki I made and happened even after checking keyboard) Have to go into Visual Editor to remove them, where the problem doesn't seem to be. Usually visual editor was the one creating weird stuff in the past, now source editor seems odd. Also "br" code spaces don't seem to update properly and take a while to update.
      • The main page of my wiki is entirely inaccessible right now and I'm not sure if that is intended. The home page just reads "[38f2a59f84ff22292c1ad76b] 2020-03-31 11:24:19: Fatal exception of type "MediaWiki\Storage\BlobAccessException" I can edit it but it won't show once edited. The header navigation will also not update on the home page while it does on any other page.
      • The fact that the editor scrolls with you instead of being fixed in place is user unfriendly in my eyes. It was nicer to have only the box content scroll rather than the entire editor, as long pages are incredibly tedious to scroll through each time when the whole box scrolls with you. Once I scrolled far down enough, the buttons to see my preview also entirely disappear on top of the page and I'm forced to scroll up all the way to look at the preview.
      • Categories inside a drop menu are also very unfriendly for quick editing. I'm not a fan of the fact that we can't manually add them on a side bar anymore via one quick window, but have to go through all these extra steps to add a category while editing. That categories aren't accessible in source mode at all is also bothersome, considering we used to be able to just add them with one click and now have to type them all in or switch to Visual Editor if we wanna add them without typing. These things make editing so much more time consuming
      • Some Special pages are entirely gone? Is that going to change? For example I wanted to go to Special:Templates to review all the existing templates but couldn't. I have no idea where to access templates and other Special pages now. This has made it difficult to build up a wiki from scratch like I normally do in a few hours
      • The theme designer/my tools bar being gone is also not great. Having to go through the admin dashboard each time is a struggle
      • PNG images are not transparent after adding them to an article even if the file comes with a transparent background

      And a question I have is when you guys think CSS will be available again? While theme designer is alright to change basics, I would usually change the font size of my wikis to slightly smaller than default and customize infoboxes. I understand you said it will be back soon though and will try to be patient.

      I hope my feedback helps some to improve the performance. Generally I think it's not a terrible change, but I believe it would be best to keep most of the features people were used to have easy access to so editing does not suddenly take hours longer than before!

        Loading editor
    • Two points:

      • The theme designer/my tools bar being gone is also not great. Having to go through the admin dashboard each time is a struggle

      It's not gone, it's collapsed by default. From what I've found, it's collapsed on every new wiki you go to. See the ^ Right bottom corner. It's annoying.

      • PNG images are not transparent after adding them to an article even if the file comes with a transparent background

      Known bug.

        Loading editor
    • Tupka217 wrote: ...

      It's not gone, it's collapsed by default. From what I've found, it's collapsed on every new wiki you go to. See the ^ Right bottom corner. It's annoying.

      ...

      Well, not for those of use who keep it collapsed anyways.

        Loading editor
    • Thanks for the tip about the theme designer, that helps a lot! I believe if it's going to be collapsed by default, perhaps users should be informed with an initial pop up note showing them that it's down there, as the button is very small and hard to notice on a big screen

      As for your response for the pngs to be a "known bug", please do not just expect anyone to know about that, as my comment was posted to help with feedback and the bug is neither mentioned here, nor in the discussed in the comments of this topic, so for anyone who was referred to here is very likely not aware

      Edit: Noticed that my wikis main page is now entirely not accessible as in it redirects me to discussions even when typing in the main page link directly. I will assume that is intended to some extent, but I will put it down here anyway in case it's not

        Loading editor
    • @Iokaree: You should start a new thread in the General Discussion board and not try to solve or troubleshoot your problems here in a blog comments section. Your Main Page is not inaccessible, just possibly very hard to find. Blame the UCP which didn't add back the Main Page link.

        Loading editor
    • Iokaree wrote: ...

      As for your response for the pngs to be a "known bug", please do not just expect anyone to know about that...

      ...

      Tupka217 isn't trying to be rude or single you out. That is just the type of response that starts showing up when people get tired of re-explaining what is going on. I have both gotten and given few of those myself. I personally think it would be a good idea to have a public list of what has already been reported; but I don't feel like being the one to put it together.

        Loading editor
    • It's merely informing you that they know, and (hopefully) are working on it. It's not by design, and you don't need to bother with a bug report.

        Loading editor
    • Andrewds1021 wrote:

      ... a public list of what has already been reported

      Crazy talk!

        Loading editor
    • Andrewds1021 wrote: I personally think it would be a good idea to have a public list of what has already been reported; but I don't feel like being the one to put it together.

      I'd suggestion creating a wiki for that so it didn't fall under one person but fandom has implemented this UCP thing and it is currently intolerable to edit on to most users. I'd add an eyeroll smilie but I can't even find the motivation for that.

        Loading editor
    • Though my faith in fandom has greatly diminish very recently, it doesn't mean I don't care about other users during this transition. So perhaps if fandom allows maybe if some helpful users want have this list as a CC article page so it doesn't fall to one user.

      And don't tell me there isn't a word doc or something fandom uses as reference for in progress tech issues/bugs and resolved, etc. they could provide at least as a foundation. Just a thought.

        Loading editor
    • Unfortunately, users cannot edit regular articles here on CC.

        Loading editor
    • Andrewds1021 wrote: Unfortunately, users cannot edit regular articles here on CC.

      That's why I mentioned if they allow^ aka permission, maybe giving temporary rights or whatever (to certain helpful users).

        Loading editor
    • I'd suggest Andrewds1021, Himmalerin, Tupka217, Fandyllic, etc. as possible candidates. But only cause those are the top people that I have found helpful.

        Loading editor
    • Hollowness wrote:

      Andrewds1021 wrote: Unfortunately, users cannot edit regular articles here on CC.

      That's why I mentioned if they allow^ aka permission, maybe giving temporary rights or whatever (to certain helpful users).

      Okay. That is not how I interpreted your post. Thanks for clarifying.

        Loading editor
    • NP, I see that it wasn't exactly clear and more implied.

      (I learned two languages growing up; mastered neither and this often leads to being misinterpreted and misunderstandings. So I am almost always ready to clarify XP)

        Loading editor
    • Hollowness wrote:

      I'd suggest Andrewds1021, Himmalerin, Tupka217, Fandyllic, etc. as possible candidates. But only cause those are the top people that I have found helpful.

      A) This is highly unlikely.

      B) It doesn't need to be in the main namespace... it could be a Help subpage (which regular users could probably create and edit), but nothing would prevent FANDOM staff from deleting it (it happens).

      C) Maintaining a list of UCP bugs is something I am not motivated to help with, so my name should be off any related list.

        Loading editor
    • Don't worry I was just listing helpful people only as a suggestion and reference, but only if the users desire. If anything take away that someone finds you helpful ;)

        Loading editor
    • Thanks for that... a good list to be in from that perspective.

        Loading editor
    • Andrewds1021 wrote: I personally think it would be a good idea to have a public list of what has already been reported; but I don't feel like being the one to put it together.

      I have made this page, see User:Noreplyz/UCP. Hopefully this will help us with answering questions and quoting staff, as an unofficial resource for people in Hollowness' post. :)

        Loading editor
    • Are message wall notifications not supposed to be global anymore?

        Loading editor
    • UCP message wall notifications, I would think, should appear in the same place as Discussion notifications. If you are talking about legacy-platform message wall notifications not showing on UCP wikis, that is to be expected. The legacy-platform message walls use a different system which is not and will never be ported UCP wikis.

        Loading editor
    • It looks like message wall notifications from UCP wikis aren't appearing on non-UCP wikis. They only show up on the bell icon when browsing UCP wikis. So, not quite global.

        Loading editor
    • But they would appear on other UCP wikis?

        Loading editor
    • Yxtqwf wrote: But they would appear on other UCP wikis?

      Yea, that looks like the case.

        Loading editor
    • Makes sense. The legacy-platform Feeds probably doesn't check for message walls since there are no Feeds-based message walls on the legacy platform.

        Loading editor
    • More central list of UCP info

      If you see a problem with the UCP, please review this list kindly hosted by Noreplyz, before reporting it as a comment to this technical updates thread: User:Noreplyz/UCP

      If you don't see your problem in the list, feel free to add it, but try to use proper spelling and grammar. Screenshots and other evidence are also appreciated.

        Loading editor
    • I have updated the list at User:Noreplyz/UCP about two bugs, one concerning the link help notification message that is never permanently dismissed in the editor, and the Administrator Task given of "Upload a Video".

        Loading editor
    • Thedarkgreenmeme wrote:

      I have updated the list at User:Noreplyz/UCP about two bugs, one concerning the link help notification message that is never permanently dismissed in the editor, and the Administrator Task given of "Upload a Video".

      Thank you... hopefully word will get out to look at that page and help keep it accurate and updated.

        Loading editor
    • What

        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.