Jump to content

Meddysong

Clients
  • Posts

    2,168
  • Joined

  • Last visited

  • Days Won

    3

Meddysong last won the day on June 7 2020

Meddysong had the most liked content!

4 Followers

About Meddysong

Profile Information

  • Gender
    Male

Recent Profile Visitors

9,135 profile views
  1. It's here. @Jim_K: https://invisioncommunity.com/forums/forum/499-feedback/
  2. Alternatively, you could keep it as it was, and then append "forums" (no slah or quotation marks) so that I'd your domain name ever changes, it will still work.
  3. "Nexus" is the name of the Commerce app. "Support" is a module of that.
  4. Presumably because of this:
  5. Do you have a test installation with Commerce operational on it? If so, log in and see whether it too has been processing renewals.
  6. Oh, I've just noticed that you're speaking about a new feature! Yes, that does complicate things.
  7. Anything in that formatting box will be included in your template irrespective of whether there's a value unless you wrap it in tags which mean "if the field has a value". {{if $formValue}} Anything in here will show if the field has a value, otherwise nothing appears. {{endif}}
  8. 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.
  9. 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.)
  10. The author has not been seen here for a long time: https://invisioncommunity.com/forums/topic/461689-get-well-soon-newbie-lac/
  11. The menu is controlled via your Admin Control Panel, Bob: 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: Once you're happy with your menu, you click a button Publish this menu, and then it's applied to your site.
  12. 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}}
  13. 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.
×
×
  • Create New...