KT Walrus

I'm using \IPS\Helpers\Form\CheckboxSet in a form to show a list of options for the user to check/enable. The first 2 options should always be checked. I want to disable these 2 checkboxes so the user can't uncheck them. When I disable the first 2 checked options, the None link at the bottom toggles off ALL the checkboxes including the first 2 disabled ones. Once unchecked, there is no way for the user to change them back to checked. I think this is a bug. The All / None buttons should not change disabled checkboxes.

Has anyone from IPS read this, or should I contact Customer Support for resolution? I need this fixed in the November release. I've fixed it locally (at least for my use case), but SELECT DISTINCT COUNT(*) just doesn't work. It needs to be SELECT COUNT(DISTINCT(<pkey>)). Also, there may be several places where this needs to be fixed since it seems fairly common to use COUNT(*) and not COUNT(<pkey>) throughout.

I'm working on implementing an app where the Items can be mapped to multiple Containers using a Map table to map Item ColumnId to Container ColumnId. To do this, I'm using an INNER JOIN of the Map table in getItemsWithPermission() passing \IPS\Db::SELECT_DISTINCT flag. This is mostly working, but sometimes getItemsWithPermission() is being called to get a COUNT instead of the actual Items. Here is an example of the wrong SQL being built for the COUNT query: SELECT DISTINCT COUNT(*) as cnt FROM `puce_topics` INNER JOIN `puce_forum_topic_map` ON puce_topics.tid=puce_forum_topic_map.topic_id AND ( puce_forum_topic_map.forum_id IN(1510000,1516600) ) WHERE puce_topics.approved < 2 AND puce_topics.approved!=-2 AND puce_topics.approved!=-3; In my test case, with only 4 rows in puce_topics, it returns 6, because 2 of the topics are mapped to both the forum_ids in the query. This COUNT query should really be written as: SELECT DISTINCT COUNT(DISTINCT(puce_topics.tid)) as cnt FROM `puce_topics` INNER JOIN `puce_forum_topic_map` ON puce_topics.tid=puce_forum_topic_map.topic_id AND ( puce_forum_topic_map.forum_id IN(1510000,1516600) ) WHERE puce_topics.approved < 2 AND puce_topics.approved!=-2 AND puce_topics.approved!=-3; which returns 4, which is correct. An even better fix is to construct this COUNT query: SELECT COUNT(DISTINCT(puce_topics.tid)) as cnt FROM `puce_topics` INNER JOIN `puce_forum_topic_map` ON puce_topics.tid=puce_forum_topic_map.topic_id AND ( puce_forum_topic_map.forum_id IN(1510000,1516600) ) WHERE puce_topics.approved < 2 AND puce_topics.approved!=-2 AND puce_topics.approved!=-3; That is, if \IPS\Db::SELECT_DISTINCT flag is set, unset it for constructing the COUNT query and don't use * but the actual databaseColumnId. Please fix in the November release, if possible. Or, if this isn't a bug, let me know what I am doing wrong. It seems to be that SELECT DISTINCT COUNT(*) is wrong and it sould be SELECT COUNT(DISTINCT(tid)) instead to count the number of distinct Items. I might try using a Subquery on the map table instead of an INNER JOIN as a workaround but would prefer using a JOIN rather than a Subquery (I think JOINs might optimize better).

I found the answer. All query data is available in the Item's constructFromData() function.

My app uses a map table for mapping containers to items. I'm trying to implement having an item be contained in multiple containers. I've got this mostly working by adding an INNER join of the map table when calling getItemsWithPermission(). But, I now want to select other columns in the joined map table and on return from getItemsWithPermission(), I want to access the joined map table column data within my Item Class. How do I access the map.* column data? $joins[ 'map' ] = array( 'select' => 'map.*', 'from' => array( 'myapp_forum_topic_map', 'map' ), 'where' => array( 'myapp_topics.tid=map.topic_id AND ' . \IPS\Db::i()->in( 'map.forum_id', array_filter( $forumIds ) ) ), 'type' => 'INNER' ); return parent::getItemsWithPermission( $where, $order, $limit, $permissionKey, $includeHiddenItems, $queryFlags, $member, $joinContainer, $joinComments, $joinReviews, $countOnly, $joins, $skipPermission, $joinTags, $joinAuthor, $joinLastCommenter, $showMovedLinks );

I've requested this several times over the years, but I'd like to see built-in support for Cloudflare Stream Video attachments. Cloudflare Stream is economical with streaming costs at $1 per 1,000 minutes viewed and storage costs at $5 per 1,000 minutes stored. The service has matured over the past year and you can have Invision Community members upload videos (in any format) directly to Cloudflare Stream (using TUS JS client) and embed the Cloudflare Stream free player for viewing the video attachments. You can also download the transcoded MP4 for long term storage (presumably in the cloud with a cheap cloud storage service like Backblaze B2). I'd like the plugin to upload, store and stream video attachments in Cloudflare Stream for 30 days. After 30 days, Invision Community could automatically move the MP4 to object storage and embed it directly in older posts using the <video> tag and built-in browser's video player. This would save Cloudflare Stream fees after 30 days and uses Cloudflare Stream for uploading and transcoding videos. I use Backblaze B2 and Cloudflare to eliminate bandwidth fees and only pay $5/TB/month for B2 object storage. At this price, I can afford to keep videos available for viewing even when attached to very old posts. More info available here: https://www.cloudflare.com/products/cloudflare-stream/

I am using the PWA on this site. Apple does not support a back button when in a PWA. So the app must provide this navigation control on each page in the PWA. I don’t have Android to test, but it is my understanding that Google supports back button in PWAs. So It is up to IPS to provide a back button in IC if the PWA is to be as good as when in Safari on iOS.

I tried using the PWA for this site (running the latest 4.6 beta) on my iPhone. The biggest issue is no BACK button is available in the PWA. Please consider adding a true BACK button in the navigation header that returns to the same position in the topic listing that you used to view the topic. The current navigation header "back" button simply goes to the first page of the topic listing (even if the topic being viewed is in the second or subsequent pages of the topic listing). Another related problem is that when you read a long topic, you have to scroll either all the way back to the top or use the link to the topic listing all the way to the bottom of the page. Even then, it always takes you back to the first page of the topic listing so you have to find your position in the topic listing again (maybe by navigating to subsequent pages in the topic listing). The browser's BACK button is what is really needed in the PWA. Since Safari doesn't add BACK/FORWARD buttons when in a PWA, it is up to the PWA to have a true BACK button on the page being viewed. I suggest changing the current navigation header back button into a true BACK button in the PWA (at least for iOS) and pinning the navigation header bar to the top of the viewport (using "absolute" CSS positioning). This would allow easy navigation regardless of how far down in the page you have scrolled. If the HTTP_REFERER is not the topic listing page, change the current navigation header button to go to the first page of the topic listing. If you choose to not make the navigation header button a true BACK button outside the PWA (for iOS), you should make sure the navigation header button has the correct page # in the link so you at least return to the page that contains the topic shown in the viewport. Would be nice to scroll to the topic in the topic list by using #topicid in the link (or other way to simulate the effects of not using the browser's BACK button. Anyway, this is the biggest problem I see in encouraging my users to "Add to Home Screen" and visiting my site in the PWA. This issue should be fairly easy to fix in the 4.6 default theme.

I'm hoping IPS adds support for Cloudflare Stream video hosting in 4.6. I really want to encourage my users to post personal videos and Cloudflare Stream is a very economical and easy option for hosting and streaming video for smaller websites like mine. It should be easy to support since the Cloudflare Stream API is very simple to use. You do have to upload the video to Cloudflare, but Cloudflare takes care of transcoding, hosting, and embedding the video for streaming to any kind of user device.

I can't find the devtools for 4.5.2. Did IPS change where they are downloaded?

I suggest that IPS require all Marketplace downloads have the dev files for maintaining the download should the developer disappear available as a separate download. You can charge extra to download the dev files (say a fixed fee of $10 per Marketplace purchase) if you want to generate a little more revenue for the developers. I certainly have been very hesitant to install a Marketplace app/plugin if I am not sure I can easily take over maintaining the software myself (or hire someone else). Having the DEV files for the all software I deploy on my site is a requirement for me, and I would have to think for others as well.

Have you looked at Cloudflare Stream? It is relatively inexpensive at $1 per thousand minutes viewed and $5 per thousand minutes stored (per month). ?

I keep checking this site for a blog post that describes first class support for video attachments in 4.5... I hope 4.5 does indeed add much better support for uploading and attaching videos to posts. Video hosting is very easy these days with cheap video streaming services like Cloudflare Stream. In addition to video hosting, I hope 4.5 comes with a better uploader for videos. The current uploader is miserable for uploading large files like videos. Fortunately, there is a very good open source uploader called Uppy that handles uploading both large and small files (and was created especially for uploading videos). Finally, Cloudflare Stream requires tus to upload videos to Cloudflare and Uppy was created by the same company that created the tus protocol.

I don't mind doing ACP upgrades in the staging servers (for pre-deployment testing), but don't want to manually upgrade the production servers. Automating this process seems like a good thing to do to eliminate any downtime and to minimize the chance of error.

Please consider providing a command line PHP script to perform installs/upgrades in a cronjob (or as single interactive command). I can handle automating updating the PHP files, but it is a problem to upgrade the database (which resides on multiple servers in multiple datacenters) in a production environment. I need to be able to perform upgrades of the database and the php files with minimal downtime, perhaps in the early mornings unattended. Ideally, upgrades could be performed in a rolling update to multiply PHP servers/MySQL databases. These services run in containers and rolling updates are easy to automate with the right upgrade system tasks. The upgrades can be tested in the development servers before being pushed to the production servers.

Please read https://love2dev.com/pwa/push-notifications/ for a great explanation of why web apps need push notifications and SMS is the way to go for iOS devices, at least for now.

The fallback for users that don't use a platform that support Push API should be SMS text message (and the fallback to SMS should be email). This would require users to optionally provide their SMS text number and for Invision Community Suite to support sending SMS text notifications to the user's SMS text number using a third-party service like Twilio (which already provides the AUTHY service). I haven't checked, but AUTHY service should allow sending SMS text messages from a web app and since Invision Community Suite already can be configured to use AUTHY for 2-factor logins, maybe not much work needs to be done in Invision Community Suite to support notifications to all users (via email, sms, or push/notifications browser api).

I got two exceptions the other day when I went to uninstall Toolbox. I didn't keep the tracebacks but I think they were caused by removing "follows" using the a string ("toolbox") instead of an ID (integer type). Sorry I didn't think of reporting this at the time, but you might want to uninstall Toolbox and see if you get the same two exceptions. I simply commented out the SQL that was causing the issue since the follows table didn't have any rows in it to remove anyway.

You could use an app template like https://www.webviewgold.com to create an app for iOS and Android. I don't know how well it works, but I think their app template supports push notifications and other native app features.

I support this idea. Also, on mobile, it would be nice to increase the default font-size for pages. This would help a bunch for those with less than 20/20 vision, myself included. I hate having to zoom the page to read text comfortably since the entire width of the page no longer shows in the viewport (leading to a bunch of swiping left and right). Perhaps a Switch to Dark mode and an increase default font-size could be added to the hamburger menu to quickly control these theme settings by the user.

I'm creating a site that will only use Grid View for browsing topics. The traditional Forum View will not be available. Because Grid View does not show forum descriptions, the user is left to figure out what kind of topics are contained in each forum listed in the sidebar. I suggest you add some place in the UX to show the forum descriptions in Grid View. Maybe the sidebar should contain an info button by each forum listed. Or, maybe just a hover popup over the forum link? Or, an info button displayed by each topic in the list where it says "in forum-name"? There has to be a good place to put forum descriptions in Grid View in such a way that it doesn't clutter the page but is obvious to the user how to view these descriptions. Maybe, a "show forum descriptions" toggle somewhere in the sidebar that expands/collapses these descriptions under the forum names in the sidebar. The default would be to hide descriptions and don't remember the toggle state for subsequent sidebar page loads.

I think you are making this more complicated than it has to be. I went ahead today and added a button on the post form next to the attach files button to "re-attach files". When clicked, it does a AJAX popup div with a list of all the attachments for the member ordered by most recently uploaded first with checkboxes for selection. Then, I just attach the selected ones to the current post (so they show up in the attachments list that the js builds). I don't use quotas for disk space and don't bother letting members delete attachments so this is all I have to do to get the feature I want. I'm working on sucking in a photo attachment to a board email address and attaching it to a pm for the user that sent the photo so they can "re-attach" the photo to a new post. I just want to allow users to post photos from their phone.

I understand that. How can it be resource intensive to add code to check permissions when posting or editing a post? Just need a quick match to see if the changed text has a bbcode that might be a cross post attachment. This has nothing to do with the other UPLOAD permission checks. Just a little new code in post processing and only when new text is stored in the database. Only when a new cross post attachment is detected is a permission check done to see if the poster has the permission to cross post this attachment and a new attachment row for the topic is added to the database. Existing UPLOAD processing isn't affected at all since the cross posted attachment is not being reuploaded (just cross posted).

Well, I would be okay with having an owner (member_id) associated with each attachment and that the only user that could cross post the attachment to another topic was the same owner. If you used the existing attachment bbcode, then any subsequent poster in the thread could also use the cross posted attachment id. That is, when posting or editing a post, a check could be made to process or ignore the attachment id based on the original author of the post being the owner of the attachment or the attachment id having the topic id of the topic or the attachment id has been previously used in the topic. This would mean that when the post is first made or edited and contains an attachment id, a check would be made that the attachment id has been previously attached to the topic (as is now the case) or the attachment id is "owned" by the original post author (not necessarily the editing member) or an administrator. If this check succeeds, then the attachment id would be recorded as being attached to the topic (another row in the attachments table in the database would be added). One point is that the owner of an attachment in a pm would be the recipient and not the sender. This is because the recipient is the one that could have downloaded and re-uploaded the file in the pm if this capability didn't exist. Since the cross posted attachment is added as a topic attachment when the post is created or edited, no other IPB code should have to change. Only the check to see if the attachment id is a valid cross posted attachment and a new topic attachment row would need to be made in the database (and probably marked as a cross posted attachment). Also, might need to make some slight changes to handle deleting the original attachment not deleting cross posted attachments (and the original file) and the deleting of a cross posted attachment not affecting the original attachment. You probably had to handle this case in the pm attachments when the attachment is copied to copies of the pm sent to multiple users.

Don't get hung up on terms here. I want to share attachments in posts or pms that aren't necessarily visible to the viewers of the new post that I use the sharing URL in. The sharing url can just be the current attachments bbcode as far as I am concerned, but whatever works best is okay with me. I want to share photos primarily (but also mp3 files and other attachments). I don't want to share a URL since you don't see the photo inline (or thumbnail) in the new post and the original pm or post that has the attachment might not be visible to the viewer.