• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 4.x Series
    • Bug
    • [4.1.1] Issues with widget Find a wiki page results styling: Additional click required to display search results, XF2.2 hover text unreadable

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: [4.1.1] Issues with widget Find a wiki page results styling: Additional click required to display search results, XF2.2 hover text unreadable

    • Issue Tools
      • View Changes
    1. issueid=6163 February 2, 2021 12:34 AM
      ACL ACL is offline
      Regular Member
      [4.1.1] Issues with widget Find a wiki page results styling: Additional click required to display search results, XF2.2 hover text unreadable

      1) After typing something into the Find a wiki page textbox, the live search results list will not show up until the textbox is clicked. After typing, the div element with class vw-search-results is given the class is-active. This is-active class tries to change the display property to block, however inline styling overwrites this and keeps it as display: none. Once the additional click is made, this inline styling is removed.

      ----

      2) Additionally for XenForo 2.2 only, when hovering over a single result item the text is unreadable. The hover text color is set to rgba(0,0,0,0). The cause appears to be .vw-search-arrow referring to the style property @xf-editorToolbarActiveColor that XF2.2, for some reason, replaced with @xf-editorButtonActiveColor.

      Code:
      .vw-search-arrow a {
      -	background-color: @xf-editorToolbarActiveColor;
      -	color: xf-intensify(@xf-editorToolbarActiveColor, 100);
      +	background-color: @xf-editorButtonActiveColor;
      +	color: xf-intensify(@xf-editorButtonActiveColor, 100);
      	text-decoration: none;
      }
      ----

      3) Also for XenForo 2.2 only, the last result item with class vw-search-contains refers to more removed properties:
      • @xf-editorSelectedBg replaced with @xf-editorButtonSelectedBg
      • @xf-editorSelectedColor appears to have no replacement


      vw-search-contains also tries to set a line height using @xf-button--height, but I can't find this property in XF2.1 or XF2.2. Do you need this line at all? Assuming you don't:
      Code:
      .vw-search-contains {
      -	background-color: @xf-editorSelectedBg;
      +	background-color: @xf-editorButtonSelectedBg;
      	box-sizing: border-box;
      -	color: @xf-editorSelectedColor;
      	display: inline-block;
      -	line-height: @xf-button--height;
      	padding: 4px 6px;
      	width: 100%;
      }
    Issue Details
    Issue Number 6163
    Issue Type Bug
    Project VaultWiki 4.x Series
    Category Styling / CSS
    Status Fixed
    Priority 5 - Minor Bugs / Small Tweaks
    Affected Version 4.1.1
    Fixed Version 4.1.2
    Milestone (none)
    Software DependencyXenForo 2.x
    License TypePaid
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. February 2, 2021 2:59 PM
      pegasus pegasus is offline
      VaultWiki Team
      Fixed in the next release. The official changes are a bit complicated, due to backwards-compatibility requirements (supporting both XF 2.1 and 2.2 simultaneously), but your suggested CSS edits will work for the interim if using XF 2.2. As for the Javascript fixes, it's quite a lot, and most users are using compressed Javascript, so any edits I could post wouldn't match anyway.

      The Javascript issues begin with the style="display: none" that is hardcoded in template vw_block_search, but continue with numerous checks against the "display"-style and occasionally manipulating it directly, rather than using the new hide/unhide methods consistently.
      Reply Reply  
    2. February 3, 2021 7:58 AM
      ACL ACL is offline
      Regular Member
      Quote Originally Posted by pegasus
      As for the Javascript fixes, it's quite a lot, and most users are using compressed Javascript, so any edits I could post wouldn't match anyway.
      As a temporary measure only, the following CSS seems to workaround the JS problem:
      Code:
      .vw-search-container.vw-search-focus .vw-search-results.is-active[style^="display: none"] {
      	display: block !important;
      }
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 2:41 AM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2025 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2025 DragonByte Technologies Ltd.
    Copyright © 2008 - 2024 VaultWiki Team, Cracked Egg Studios, LLC.