KT Walrus

  • Content count

  • Joined

  • Last visited


About KT Walrus

  • Rank
    Community Regular
  • Birthday 11/11/2014
  1. I'm implementing something similar for an app I need for my 4.2 site. Rather than posting new content immediately, I post the content to a virtual queue in a Redis database and run a cron job to wait on the queue and post it to the MySQL database. This means that notification emails are generated by the cron job and don't slow down the user at all. I use Redis to implement the virtual queue so the queue is lightning fast. Of course, if your site requires that the poster of new content be able to see the new content immediately, this might complicate a queuing solution like I'm pursuing. But, on my site, it doesn't matter if it takes a few minutes (or even a few hours) for the cron job to process the content and make it visible on the site. My cron job does synchronously wait on the Redis queue so it picks the content up immediately when added to the queue unless the cron job is busy processing previously queued content. In practice, the cron job posts the content immediately (or within a few seconds). So, +1 from me for 4.2 implementing asynchronous queues for updated/new content...
  2. Personal Messenger needs to go "Real-Time"

    I think that if you have an idea of exactly what this real-time Messenger is and how it would work, that you might want to try to convince a developer here to implement the app and post it to the Marketplace to be downloaded and installed on your site. I believe you can disable the built-in PM core component and just use this new app as a replacement.
  3. Fluid View Sidebar needs work

    I completely fail to understand why you wouldn't add this simple request. Hide/show level 3 and deeper forums in the sidebar. It seems so obvious to me that this is a good idea and doesn't change the sidebar at all on this site (only for sites with 3 or more levels of forums). Another simpler alternative might be to allow the admin to set the max depth for this sidebar. The max depth is currently hardcoded to 5, but if I could set it to 2, it might work for my site. It wouldn't be as functional as a Hide/Show sidebar, but at least the sidebar wouldn't be so huge and ugly. Not sure how it would work if the user clicked on a forum link in the list where the forum was at a depth greater than the max depth setting. Still, I'm pushing for a Hide/show for deeper than 2 levels...
  4. Fluid View for forums with subforums

    Just discovered that the current implementation does support viewing a forum in Fluid View, but if the current view is traditional or grid, navigating to a category or forum sets the view to traditional or grid and there is no way to change this to Fluid View. I'd like to suggest that traditional/grid/fluid be an option on all individual forums/categories, settable in the ACP. The traditional view for a forum is really the fluid view without a sidebar filter widget shown. So, making this change should be rather easy. If the admin allows members to choose for a particular category/forum, then toggling between views should remember the setting associated with the category/forum. That is, the ips4_forum_view cookie should contain 3 lists of forum ids (one list for each view type) where the view setting was explicitly chosen by the user. The forum module would check this cookie to see if the view has been overridden from the default view type assigned to the forum in the ACP. If not, it would check the "default forum view" attribute on the forum/category. If no "default forum view" attribute set for the specific forum/category, then choose the global default view. If you implement this, you would simply add the "Default forum view" and "Members can choose?" settings on individual forums/categories with an additional "inherit global default" from the "Forum Settings" page as the default choice for "Default forum view". The second change would be changing the contents of the ips4_forum_view cookie to have the 3 lists of forum ids where the user has chosen a different forum view.
  5. I'm loving the new Fluid View option for the forum index page. It is proving to be a great option when I want to view newly posted/updated topics. There are times when I still want to browse with the old view of listing the forums. When I use the old view and navigate to a root category page or a forum that has subforums, I would like the option to use Fluid View from this page. That is, pages like: https://invisionpower.com/forums/forum/307-community-led-resources/ https://invisionpower.com/forums/forum/503-customization-resources/ that have subforums (and thus are index pages themselves) should have the same user settings to enable Fluid View just on this category/forum. Perhaps, the ACP should have these settings on any category forum. Index Page Settings: Category Forum settings: My suggestion is to add the "Default forum view" and "Members can choose?" options to the Forum Settings of a forum that has the type "Category". This would result in the forum page being shown in Fluid View with only the category/subforums in the sidebar topics filter.
  6. Perhaps place a gear menu (⚙️) to the right of the SORT BY menu. This configuration menu could have various settings for this view: Pin Topics Ascending Sort etc. Not sure how many user selectable settings should be supported, but I agree that Pinning Topics should be user selectable and this setting be remembered by Fluid View until the user changes this setting explicitly. The SORT BY setting could even be moved inside this settings menu since it is very rarely used (at least, by me) and doesn't really need to be so visible on the page. UPDATE: Could also add a Moderate Topics setting that would show/hide the select boxes, if the user has the ability to moderate topics. This would allow the moderator to see the same view that users are seeing and only clutter the view with the extra checkboxes when moderation of the list is necessary (which is rarely used, at least, by me). UPDATE 2: Another possible user selectable setting is whether the list should be shown with pagination or infinite scroll. Most websites now use infinite scroll instead of pagination (especially on mobile devices). I actually prefer infinite scrolling (even on the desktop) unless I want to jump to a specific page quickly (especially the last page in the list). Having a user toggle for this setting would be very useful to me (this even applies to reading replies and other lists that are now paginated). Sometimes, pagination works best, but more often, infinite scroll is better (at least for lists that start at page 1).
  7. Fluid View Sidebar needs work

    I think that collapse/expand for nested forums is not a "complex" requirement for the FV Sidebar widget. It wouldn't even be that hard to implement since the widget already propagates a parent's selection status to it's children. All that I think is needed is to check the depth of the children and hide/unhide them based on the parent's checkbox state. This small change would make the Fluid View much better for sites with 3 or more levels of forums and more than 25 forums total. Of course, the current widget works best for the IPS site since you only have 2 levels of forums, but hide/unhide levels greater than 2 would not affect the IPS Site but would make Fluid View a much better option for my site (and I suspect other sites as well).
  8. I'm experimenting with the new Fluid View. I have forums that are 4 levels deep with hundreds of forums total. The sidebar widget would work much better if the subforums are only shown if the parent forum is selected. I have 6 root categories each with an average of 4 or 5 subforums in each root category. Each subforum has zero to ten subforums. Some of these subforums have a few subforums themselves. With all forums visible, the sidebar is very long and hard to read. It would be better to unhide children subforums when the parent forum is checked and hide the children when the parent forum is unchecked.
  9. Why do I need to differentiate between "cat and forum"? All forums in this sidebar are categories. The widget is really just a category selection form where you can select a category and any subcategories with a single click. What is so special about the root category forums except they are at level 1 in the list of categories? Anyway, my suggestion is a small UX nit, but selection of a category should be consistent whether the category is at the root or nested. IMHO.
  10. Small suggestion: The Category headers in Fluid View do not have an associated checkbox in front of the Category Name. This hides the feature that all forums in the category may be selected by clicking on the category name. I would like to see a checkbox in front of the category name just like the checkboxes in front of the forum names. I had no clue that I could click on the Category Name to select all the forums in the category (or de-select them), so I would click on each individual top-level forum in the category. Seems like a UX error to not make this feature more visible since it is useful for everyday use. Maybe I just wasn't thinking clearly when I thought I had to check the top-level forum checkboxes when a shortcut was available.
  11. Reaction Sets

    Currently, I see only 1 set of reactions that I can add to the content posted in a forum/blog/etc. On my site, I would like to have the ability to defined multiple reaction sets with the ability to override the default set when attaching to a forum/blog/etc when the forum/blog/album/etc is created. Some forums I want only positive reactions, while on others, I want only negative reactions or forum specific reactions.
  12. New: Complete Your Profile

    Are you going to provide more Custom Profile field types in 4.2? I need a good Places field that allows entering the following: City (w/ region and country) School (w/ school type and city) Place of Worship (w/ church type and city) Workplace (w/ workplace type and full address) Home (w/ full address) Neighborhood (w/ postal code from home address) Region Postal Code Country Basically, IPS4 would maintain a Places table that would be used for autocompletion on the Place Name input field. If a Place Name is submitted that hasn't previously been seen, the input text would be sent to Google Places to retrieve a list of possible matches and the user would be presented with a form to pick the correct place or change the input text and try again. The Places table would include the Google Place Id and lat/long with each Place and use that for showing Maps for the Place when the field is displayed in the Profile. Yes. I knew this too. I was just asking about whether 4.2 supports Invisible ReCaptcha. By your answer, I take it that it does not, but you are considering it.
  13. New: Complete Your Profile

    Yes, I already knew that. But, IPS 4.1 doesn't support "Invisible ReCaptcha". https://developers.google.com/recaptcha/docs/invisible
  14. New: Complete Your Profile

    I see you are still using ReCaptcha v1 on the sign up form. Google has moved on to ReCaptcha V2 and Invisible ReCaptcha. Is Invisible ReCaptcha supported in 4.2? I think Invisible ReCaptcha should be the default to make sign up even easier for new users.
  15. Google Map requests issue this warning. IPS4 should remove the 'sensor=false' in all Google Maps calls just to cleanup the code and avoid this browser warning.