Jump to content

Community

Rikki

Invision Community Team
  • Content Count

    24,094
  • Joined

  • Days Won

    61

 Content Type 

Profiles

Downloads

IPS4 Documentation

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Everything posted by Rikki

  1. Absolutely - and we did this with a compromise. Make a preview tool available for those few customers who have valid edge cases, without adding Yet Another Button in a prominent location for all our other customers. Every extra button or toggle we add to a page increases the complexity for users a little bit more, mostly unnecessarily. We try to consider all users and balance functionality with simplicity as much as we can.
  2. Honest reason it's located where it is: we do not feel it has sufficient usefulness for most sites and most users to justify giving it a more prominent location next to the submit button. We made it a customizable toolbar button so that it's available for those few edge cases where you could argue it's useful, without it being a fundamental part of the editor UI.
  3. We can't set a fixed height on images because images need to remain responsive (i.e. scaling with the browser window). For that reason, we set a width and a ratio, and calculate the height using JS. You are correct that on very slow connections, the JS can take a second or two to execute and add the placeholder, but even without lazy-loading, images would also 'jump' as the browser downloads them and inserts them into the page. This is unfortunately a trade-off, but for those on slow connections lazy-loading should ultimately be a benefit since their browser isn't having to load a bunch of images they aren't seeing yet.
  4. Each site can set their own defaults here, so it'd depend on the site you're using. This is already the case (in fact, we're looking at simplifying the process a little bit because there's too much customization, which is confusing).
  5. We actually recently added a review of notification functionality to our internal list, and this is one of the pain points that came up. We'll hopefully be able to address it in the not too distant future.
  6. I've logged a bug report for this so we can take a closer look.
  7. I've submitted a change for 4.4.4 that will disable preloading of this sound file (meaning, it'll just load on demand when it's needed, rather than on page load).
  8. I'm not sure a complete SPA approach will ever be a good fit for our platform. That said, I could imagine that we might have a collection of 'SPAs' for key workflows - e.g., going from a list of topics into a topic, replying etc. might be one seamless process. User profiles might be another. Potentially the whole ACP could be one (or maybe each section of the ACP). GitHub takes this approach and it works well.
  9. Kind of. They have similar-ish approaches. Whereas React deals exclusively with components, Vue can do components but they're optional. There are a lot of benefits to any of the modern JS frameworks though, be it React, Vue or Angular. I'm not sure if IPS5 will have the scope to move all of our JS to a new framework, but we're always keeping an eye on things and we'll make those decisions when the time comes.
  10. .ipsApp_front is also a class on the body element, so you need to remove the space (I've also moved that class to the front of the selector for clarity): body.ipsApp_front[data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="index"] .ipsBreadcrumb { display: none !important; } An alternative way is using the data-pagelocation attribute in the same way you've used the others, since that tells you whether it's 'front' or 'admin': body[data-pagelocation="front"][data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="index"] .ipsBreadcrumb { display: none !important; } Either of those approaches should work 🙂
  11. We haven't changed any font sizes recently. Check you haven't accidentally zoomed the page out (e.g. Cmd/Ctrl+0 on Chrome).
  12. It's a CSS selector 🙂 .ipsType_richText.ipsType_normal > p:first-child:first-letter { ... }
  13. I agree. We added it in 4.x because users were used to the position of it in 3.x, but these days I think it's probably unnecessary.
  14. That shouldn't be the case - while we only offer US-based regions, it should not be slow even from Europe. We host many European sites without issue. I'd definitely recommend submitting a ticket so we can take a look and see what's going on 🙂
  15. Personally, I don't think that's fair on the person who has quoted you. It could substantially change the meaning of their response. I think the quote needs to show what you had said at the time you were quoted.
  16. We certainly understand that 🙂I'm almost positive v4 will be maintained for a considerable period of time after v5 is available. That said, we of course need to continue to press forward and modernize the platform, especially in terms of UI and taking advantage of more modern approaches to development. We will of course do everything we can to make it as painless as possible when the time comes.
  17. Yeah, I do actually agree with you. But I still love React more.
  18. For the most part, themes created for Invision Community 4.3 should work without modification on Invision Community 4.4. However, for sites with more heavily customized themes, there may be some manual updates you will need to make to ensure compatibility. The document below outlines the areas you should review. We'll update the document as and when we identify particular areas that may be causing upgrade problems. Global includeJS If you have modified includeJS.phtml, you will need to add two new keys to the main ipsSettings settings block in order for lazy loading of media to work correctly: lazyLoadEnabled: {{if \IPS\Settings::i()->lazy_load_enabled}}true{{else}}false{{endif}}, blankImg: "{expression="\IPS\Text\Parser::blankImage()"}", Pages Record Templates Next unread links If you have modified any of the record view templates in Pages, you may encounter a template error after upgrading. The format of data passed to generate the next unread record link has changed. In your database record template change: <div class='ipsGrid ipsGrid_collapsePhone ipsPager ipsClearfix ipsSpacer_top'> <div class="ipsGrid_span6 ipsType_left ipsPager_prev"> {{if $record::database()->use_categories}} <a href="{$record->container()->url()}" title="{lang="cms_back_to_category_with_title" sprintf="$record->container()->_title"}" rel="up"> <span class="ipsPager_type">{lang="cms_back_to_category" sprintf="$record::database()->recordWord( 2 )"}</span> <span class="ipsPager_title ipsType_light ipsTruncate ipsTruncate_line">{lang="$record->container()->_title"}</span> </a> {{else}} {{$page = \IPS\cms\Pages\Page::$currentPage;}} <a href="{$page->url()}" title="{lang="cms_back_to_category_with_title" sprintf="$page->_title"}" rel="up"> <span class="ipsPager_type">{lang="cms_back_to_category" sprintf="$record::database()->recordWord( 2 )"}</span> <span class="ipsPager_title ipsType_light ipsTruncate ipsTruncate_line">{$page->_title}</span> </a> {{endif}} </div> {{if $nextUnread !== NULL}} <div class='ipsGrid_span6 ipsType_right ipsPager_next'> <a href="{$nextUnread->url()->setQueryString( array( 'do' => 'getNewComment' ) )}" title='{lang="cms_view_next_unread_title" sprintf="$record::database()->recordWord( 1 )"}'> <span class="ipsPager_type">{lang="cms_next_unread_title" sprintf="$record::database()->recordWord( 1 )"}</span> <span class="ipsPager_title ipsType_light ipsTruncate ipsTruncate_line">{$nextUnread->mapped('title')}</span> </a> </div> {{endif}} </div> To: <div class='ipsGrid ipsGrid_collapsePhone ipsPager ipsClearfix ipsSpacer_top'> <div class="ipsGrid_span6 ipsType_left ipsPager_prev ipsPager_noDesc"> {{if $record::database()->use_categories}} <a href="{$record->container()->url()}" title="{lang="cms_back_to_category_with_title" sprintf="$record->container()->_title"}" rel="up"> <span class="ipsPager_type">{lang="cms_back_to_category" sprintf="$record::database()->recordWord( 2 )"}</span> </a> {{else}} {{$page = \IPS\cms\Pages\Page::$currentPage;}} <a href="{$page->url()}" title="{lang="cms_back_to_category_with_title" sprintf="$page->_title"}" rel="up"> <span class="ipsPager_type">{lang="cms_back_to_category" sprintf="$record::database()->recordWord( 2 )"}</span> </a> {{endif}} </div> {{if $nextUnread !== NULL}} <div class='ipsGrid_span6 ipsType_right ipsPager_next ipsPager_noDesc'> <a href="{$record->url()->setQueryString( array( 'do' => 'nextUnread' ) )}" title='{lang="cms_view_next_unread_title" sprintf="$record::database()->recordWord( 1 )"}'> <span class="ipsPager_type">{lang="cms_next_unread_title" sprintf="$record::database()->recordWord( 1 )"}</span> </a> </div> {{endif}} </div> This change also affects topic view, however you should use the built-in template editor tools to compare and update your custom template. Follow buttons If you see an error accessing your records (or in the system log) that use a custom template such as "Total count attempted on a query not ran with SQL_CALC_FOUND_ROWS" you will need to make some changes to your template to make it compatible with 4.4. Change (2 instances) of {template="follow" app="core" group="global" params="'cms', 'records'.$record::$customDatabaseId, $record->primary_id_field, $record->followers()->count( TRUE )"} To {template="follow" app="core" group="global" params="'cms', 'records'.$record::$customDatabaseId, $record->primary_id_field, $record->followersCount()"}
  19. Thanks for letting us know - I've fixed that 🙂
  20. It's cached for guests too after their first page load. You don't have to log in to get caching (in fact, our caching is even more aggressive for guests than members, since they all see the same thing). Your tests are likely assuming an empty cache, which is a fair measurement of a first-time visit/stale cache, but subsequent page loads will be loading FA from cache, not the server.
  21. Only for the first visit - whereas using data:image means it's being downloaded on every page view. For a single icon (like your menu bars example) I'd agree that's the best approach, and that's what I do on my personal projects normally, but when we're using dozens of different icons in hundreds of places, it doesn't make sense. That said, web development is always moving forward, so when our next major update begins, we'll evaluate the best approach at that point.
  22. That's not accurate; it's a single image, with a different background color. Your browser doesn't download it for every club. If it's 280KB, your browser will only download 280KB, once.
  23. Not quite. It looks like that plugin replaces the video with a screenshot until the user clicks it to load the video. Our built-in approach will always load the video, but only once the user has scrolled down far enough to see it.
×
×
  • Create New...