Jump to content

Meddysong

Clients
  • Posts

    2,169
  • Joined

  • Last visited

  • Days Won

    3

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Posts posted by Meddysong

  1. My wishes centre on internationalisation and localisation because I run a site which must give equal standing to two languages.

    • Allow admins to provide a FURL for every aspect of a URL. In 4.x the app names are fixed because they come from /applications/[app]/data/furl.json, meaning that non-English sites are condemned to have English words such as files and store in their URLs.
    • Allow admins to create and match equivalent pages depending on the language with their own slugs. For example, you have invisioncommunity.com/features/clubs/ on this site. If it were necessary for you to have a multilingual site, you would be able to create an associated page (very likely with the same content aside from text) with its own slug, such as invisioncommunity.com/trajtoj/kluboj/. When a link is created in the Menu Manager or written within content, the site would know that on click it is to load the language-dependent associated page; is somebody manually types <a href="invisioncommunity.com/features/clubs/"> within a post, the site would redirect to an associated language-dependent associated page.
    • Please move away from the approach of concatenating different language strings as a short-cut. What works in English often doesn't in other languages, and I'm forced to present grammatical mistakes in some parts of my site because words which are plugged in interchangeably in English strings take different forms depending on their grammatical role. My word for a post will have different forms in the superficially similar: {!#[?:%s liked]} %s and %s reacted to %s:, for example.
    • A long shot but please consider providing occasional context of how a language string is used. Translators need to know, for example, whether Report is a noun or a verb. (Incidentially, because of the previous point, I have instructions in an email notification inviting moderators to "Click to see this To report" because if I change to our equivalent noun, then the instruction "Report" on the content containers is the wrong word.) 
    • It might be possible already for people more knowledgable than me but it would often be useful to be able to change the user's language setting via something in the URL. We're a UK-based charity so have English as our default language but our activity is worldwide using another. It'd be great for me if the language could be set as the second one for a visitor following a link such as invisioncommunity.com/cy for Welsh, for example.
  2. I've found the cause of the problem. It's a combination of an element having a width of 100vw and being on Windows.

    If a page is longer than the full vertical height, then a scrollbar appears on the right. In Windows, 100vw doesn't take into account that the available space has reduced because the scrollbar is eating some of what was there before. The result is that the width property is larger than it should be, which causes it to exceed the available space slightly. This then generates a needless horizontal scrollbar. This phenomenon doesn't happen on Mac because that behaves sensibly in this scenario.

    This person has solved the problem with JS on CodePen. Here's the relevant JS:

    function handleWindow() {
      var body = document.querySelector("body");
    
      if (window.innerWidth > body.clientWidth + 5) {
        body.classList.add("has-scrollbar");
        body.setAttribute(
          "style",
          "--scroll-bar: " + (window.innerWidth - body.clientWidth) + "px"
        );
      } else {
        body.classList.remove("has-scrollbar");
      }
    }
    
    handleWindow();
    
    // The resize isn't very necessary:
    window.addEventListener("resize", handleWindow);

    I've tried to rewrite that using IC's requirements for controllers, and have added that controller to an element on an affected page on my site but it's not working. I'm miserably inexperienced with JS, and so suspect that I'm at fault. Would somebody be so kind as to show me how I should've done it, please?

    (And a heads-up to the Mac users at Invision Community, of course, that you have this slight blemish on your blog which you won't be aware of.)

  3. The menu is controlled via your Admin Control Panel, Bob:

    Could contain: Text, Outdoors

    Once you're there, it's fairly straightforward. There's a button Add item, which you'll use to create the new menu item. You'll have to choose what form it takes: is it a dropdown (= Drop-down Menu)? A link to a page (= Page)? A link to something else (= External link)? Have a play.

    You can drag and drop your menu items to change their position. And any which you don't want can be sent on their way by hovering over them and then clicking the X:

    Could contain: Page, Text

    Once you're happy with your menu, you click a button Publish this menu, and then it's applied to your site.

  4. If a member is logged in, then the address:

    <a href='{member="url()"}'>Here's your link</a>

    should lead to a profile, I think.

    You'd only want that to be visible to people who are logged-in members, of course, otherwise it's a broken link, so you should wrap it with something like:

    {{if member.member_id}}Code for logged-in members sits here{{endif}}

     

  5. On 4/4/2023 at 1:29 PM, Marc Stridgen said:

    I feel that was misquoted somewhat. What I actually said if I can see why someone wouldn't want to have it disabled. 

    I don't know about misquoting you, Marc, but we might be at crossed purposes. I'm not saying permanently disabled with no option to reenable, and it might be that you think this is what I'm angling for, hence our mutual confusion. I'm saying that they should be disabled by default; a knowledgable user could then reenable them if required. That seems far better to me.

  6. 56 minutes ago, Marc Stridgen said:

    Im not sure I understand the reasoning there. If they are disabled, there would be no way in which to test them. While I understand you may want to disable them every time, there are many times where user dont

    You don't understand why an administrator would want to have an app disabled in a test environment which, if activated, will take duplicate payments?

    Let's put it another way. Why would any admin want his testing site to be taking the same payments that his main site is? Why would any user want to be charged twice for the same subscription?

    I think the ideal situation is to have Commerce -- or, at least, the part of it which takes money -- deactivated in a test environment. Have some sort of notice advising of this, perhaps, with an option to re-enable. But what positive can come of allowing it to take renew membership subscriptions anyway? Why should members be charged twice if their renewal period happens to coincide?

  7. This has happened to me in the past, when backing up my site to a test installation prior to running an upgrade. Because I'd created a perfect replica of the main site, it too was taking repayments. It's a massive oversight, in my opinion, that if the site is at a test location, then these features aren't automatically disabled.

    You'll need to add the following to contants.php in your test location:

    define( 'NEXUS_TEST_GATEWAYS', TRUE );
    define( 'EMAIL_DEBUG_PATH', "/dev/null");

    And if you're using Stripe as your gateway, that's still not enough because these changes don't work with it.

    The only approach that works for me is to disable Commerce in my live site, make the backup, switch Commerce back on, and then use the backup in the test installation. That way Commerce isn't operational on my test site and so repayments won't be taken.

  8. You could purchase the Pages app to create your basic home page, and move your Invision Community installation to the site root. By selecting Pages as your default app (you can do this after installation), site.co.uk would be the IC installation, and the other apps would be located at site.co.uk/forums, /gallery, etc. Doing it this way, your links would still be entirely valid even though you will have moved the installation.

    It'd mean an extra paid app but at least it would live within IC, using its CSS, blocks, and so on.

  9. The logo redirects to the location where the Invision Community software is installed. To amend this behaviour, you would need to modify the tempate named logo to:

    {{if isset( \IPS\Theme::i()->logo['front']['url'] ) AND \IPS\Theme::i()->logo['front']['url'] !== null }}
    {{$logo = \IPS\File::get( 'core_Theme', \IPS\Theme::i()->logo['front']['url'] )->url;}}
    <a href='YOUR URL HERE' id='elLogo' accesskey='1'><img src="{$logo}" alt='{setting="board_name" escape="true"}'></a>
    {{else}}
    <a href='{setting="base_url"}' id='elSiteTitle' accesskey='1'>{setting="board_name"}</a>
    {{endif}}

     

  10. 41 minutes ago, Miss_B said:

    If so, in what way it is not changing?

    I suspect he means "loading" when saying "charging". When using 8.x, his site isn't loading at all. It rather suggests he's on an earlier version.

    @sonimik1: Which version of the software are you using?

×
×
  • Create New...