KT Walrus

+Clients
  • Content count

    1,012
  • Joined

  • Last visited

2 Followers

About KT Walrus

  • Rank
    Community Regular
  • Birthday 11/11/2014
  1. Has 4.1.18 been tested with PHP 7.1?
  2. Thanks a lot for adding this. I think the Google Authenticator will be great for admins, but I don't think I would enable it for all Members. It would be nice to be able to select the groups where 2FA is optional. As presented here, it appears that all members have the option of setting up 2FA if they are not in the "2FA required" groups. I don't want my users (other than admins/moderators) to use Google Authenticator for 2FA. I prefer that a 2FA service implements the sending of One-Time Passcodes via SMS/email for general users. SMS message is the way most sites provide 2FA feature to its users and I don't like requiring normal users to install an app on their phone to use 2FA. So, I will probably just use this feature for admins and no one else, until you deliver an SMS solution.
  3. Seems like an old post. Perhaps IPS forgot about it?
  4. Text selection of text in comments/replies result in a nice "Quote This" popup to quote only the selected text in a new reply. But, this doesn't work for content types where the first post is separated from the comments (e.g., Blogs, Bug Reports, etc.). Could you please work on supporting this feature for all posts (including a separate first post on the page)? It seems to be inconsistent from the user's point of view.
  5. I wasn't aware of NO_WRITES so good to know. Still I do not think syslog'ing is just for Linux apps. A PHP app like IPS4 should support standard logging. What is so hard about inserting syslog calls within the IPS4 PHP to log NOTICES, WARNINGS, and ERRORS? As you say, you do log things to the database, so it should be easy to add an option to send the same logging to syslog. I'm really wanting to monitor IPS4 for when it generates database and PHP errors and to alert on admin activity (including logins to the ACP).
  6. I run IPS 4.1 in Docker containers. Docker has support for handling logs generated by an app in a container. Standard Out and Standard Error are captured by Docker and you can send the logs out of the container to be managed/monitored with external monitoring tools. IPS 4.1 writes errors to files in the HTML root filesystem as individual files. It would be nice if there were a setting to not store these error logs as individual files (or even in the database) but send them to syslog or standard error. Logs for admin actions could still be stored in the database (so the ACP could access them), but also have a setting to send them to syslog or standard output. This way, I could easily set up alerts in my monitoring tools on admin/moderator actions that I might want to get an SMS message (like admin login to ACP). So, I am suggesting that you spend some IPS 4.2 development effort to make logging of events with IPS 4.2 more like other Linux apps (especially for running in containers). You could also just define the location and filename of an ips4.log (for standard output) and ips4-errors.log (for standard error) in /var/log.
  7. I noticed today that you are working on IPS 4.2. One of the new features I'd like to see is to require the use of INNODB engine and group requests within SQL transactions. So, if a user post updates more than one table, all the updates for saving the post to the database are done in one transaction. If some update fails in the transaction, the entire transaction should rolled back. This means that the transaction only changes the underlying database tables if the transaction is COMMIT'ed at the end of the transaction. Along the same lines, many MySQL replication tools require all rows updated to have a primary key (so replication can do certification checks before committing a transaction to a clustered database). It would be nice if IPS 4.2 made sure that all tables have primary key (last I checked, there were a few that didn't have a primary key defined for the table). Also, IPS 4.2 should handle gracefully COMMIT returning an error. Using MySQL 5.7.17 Group Replication (just went GA) or Galera Cluster, COMMITs may fail due to a commit conflict. Sometimes, the proper thing for the PHP to do is to retry the transaction (maybe waiting a few seconds between retries) as the failure may be transient. If the transaction fails to commit after several retries, the user should be informed that there was a problem adding the post that may be intermittent and the user should try again later. Hopefully, the changes made for the post will still be stored/restored when the user later returns to the form and submits it again. Basically, I'm suggesting that you spend a little development effort to make IPS 4.2 transaction safe and friendly to the end user is using some HA MySQL setup (like Percona/Galera Cluster w/ ProxySQL or the new Group Replication plugin with a proxy in front of the Group).
  8. Any progress on better support for video attachments?
  9. I suggested this a couple years back, but nothing was really done to improve support for sites that want to use real names instead of aliases. I think it is time for IPS to implement first class support for Real Names as an ACP option in the suite. Sites like Facebook have made it acceptable to use your real name on many sites that offer to publish posts or send messages to others on the site. In fact, encouraging users to use real names on a site often results in a more civil discussion where users can't hide behind an anonymous alias to post. IPS4 probably can't enforce real names, but a site's admin could require real names at sign up and challenge any names they think might be false (e.g. Mickey Mouse). So, I am requesting the following changes: Option in ACP to interpret Display Names as Real Names. The Display Name entered on the registration page would not have to be unique. Therefore, login pages should only support login by email address if Real Names are enabled. The Display Name entered should be a full name which is parsed into first name, last name, and name suffix parts (using a PHP name parser along the lines of this github project). The members record should be extended for the various name parts and a column for sorting names ("last, first" in most western countries). If you want to support sorting by geolocation (some countries sort by a different order of the name parts), that would be okay to but not necessary for my sites. Over time, the various templates in the suite, especially the email templates and other pages meant to be seen by only the user, would use the user's first name instead of their Display Name (e.g. "Hello Kevin!"). User advanced searches could have separate fields for first name and last name searching (in addition to the Display Name field searches) so users could list all members that have the last name "Smith" or first name "Kevin". I have already made some of these changes for my site, but it would be better if Real Names (as an ACP option) where supported throughout the suite (including core modules/templates). I don't think full builtin support for Real Names would be that complicated for IPS devs to add to IPS4.
  10. The UI for uploading and cropping a photo for your profile/avatar is very limited and should be improved. Currently, when you save the uploaded photo, a cropper dialog pops up with a very small version of the photo with a cropping rectangle meant for selecting the portion of the photo to crop for the profile/avatar. The current UI might have been acceptable a few years ago, but these days it just isn't what most users expect. I believe this page could be greatly improved from the user's point of view. Here are my suggestions: Allow uploading of high resolution photos like your smartphone takes by default. Cropper page should show a much larger view of the photo (e.g., 640px at least). The cropper page should have a preview area that continuously updates as you move the viewport of the cropper around. The preview area should show the profile photo as it will be seen as an avatar (i.e., either rectangular or circular avatars depending on the current IPS4 theme setting). The cropped photo should be resized to the resolution according to the ACP setting (e.g., 400x400). The preview area should ideally display the cropped area using this resolution inside a div that is sized to the current theme's Large Avatar size (so the user can tell if the avatar will be blurry due to insufficient resolution for the selected cropping area). Ideally, I would like to see the cropping process involve 2 steps: Initial crop is for a rectangular photo on the Profile page (usually, I want a head and shoulders photo that is 400x400). The preview area would show the 400x400 rectangle preview. After cropping for the Profile page, a second dialog would allow positioning of the profile photo (400x400) inside a preview area for showing as an avatar (circular with only the face showing = head and shoulders photos don't do so well in a circle if not positioned and resized to show as just the face). The repositioned avatar photo should be a second crop of the original high resolution photo rather than just resizing/cropping the already cropped profile photo (400x400) so the avatar photo is as high resolution as is possible. So, I am suggesting that IPS4 don't keep the full size original around after user cropping and possibly keep two versions of thumbnails, one for display on the profile page and the other for display as an avatar (by content posted by the user). That means the the members record would have an avatar photo path and a profile photo path with the profile photo defaulting to the avatar photo if no profile photo has been created by the user (for backwards compatibility with existing profile/avatar photos that haven't been processed with the new cropping UI).
  11. I think IPS4 should have built-in support for Emojis. Emojis are a standard that almost all mobile and desktop devices/OS's. Although the user can insert Emojis directly into content (😀), the emoji will display differently depending on the device/app/OS being used to display the UTF8 text and there is still a chance the user will be using a browser/email client that doesn't fully display all the emoji that the OP included in the post. Fortunately, there is a mature open source implementation of Emojis that can be found here: https://github.com/Ranks/emojione There is PHP classes to convert Unicode embedded in UTF8 text to SVG/PNG img and the set of emoji images can be styled with CSS for consistent display on all devices (including most email clients). EmojiOne provides both a scalable SVG file and PNG files in 3 sizes. I think most browsers support SVG (at least for these types of images) so SVG would give high resolution on all devices at all sizes. It should be rather straight forward for IPS Devs to ship EmojiOne support in IPS4 (including CKEditor emoji menu plugin using IPS4 theme elements). The only requirement for using EmojiOne in a commercial product is attribution which IPS4 could place in the CKEditor emoji dropdown (or possibly just in a credits page).
  12. SMS 2FA is certainly better than just simple password authentication and most large sites offer this an option to its users. It certainly isn't the ultimate security feature, especially if you are the federal government, but I sign up for 2FA authentication for any site that has my credit card on file or has access to my bank accounts. Besides, offering 2FA authentication to users gives the impression that the site is worried about security and privacy and is taking the usual measures to prevent unauthorized access to your account and personal information.
  13. I'd like to see support for 2-factor authentication (via text message) with the ability to enable this option for specific groups (e.g., admins and moderators must authenticate via text message while members may choose to enable/disable on their own accounts).
  14. I've been waiting for better handling of user attached videos for a while. I think this feature was on the roadmap when IPS4 was first released, but since then there seems to have been little progress in this area (unless I missed it). What I'd like to see is support for encoding uploaded videos via a transcoding service (with built in support for Amazon Video Transcoding or configurable local ffmpeg transcoding) and built-in Video Player for streaming the attachment. It is rather easy to run ffmpeg in a Docker container on a server these days to host the transcoding service locally, but Amazon also has a very reasonably priced service for transcoding, storage, and streaming the videos (unless this aspect of my site were to really take off). Basically, I'd like to see the same things that are done for photos/images done for videos. I really want my users to post short videos taken on their smartphones instead of having them have to type in a topic for sharing their thoughts. I realize that videos can cost more to host, but I think it might be worth it instead of telling everyone to upload their videos to Youtube and embedding the video link in their posts. Many users just don't bother (especially for a short video message that is specific to a topic). I also want to be able to control the video encoding parameters so I can specify 240p or 480p or HD encoding and time limit (clipping transcoded file to 30 seconds or 3 minutes or whatever) to save bandwidth or storage costs. For my needs, low quality video with a short time limit (of several minutes) would suffice for an attached video to a post.
  15. When attachments are stored in the database, the whole file is inserted in one row. This row could be very large and really mess up replication, especially if using synchronous replication using the Galera replication library. Also, storing large BLOBs in MySQL requires my.cnf configuration so it would be much better for many users if IPS4 could run with MySQL defaults (and still allow storing attachments in the database). Could you please consider "chunking" attachments into multiple rows where the default chunk size is 255KB with an admin setting to change the chunk size? See how MongoDB's GridFS stores files in two tables: https://docs.mongodb.org/v3.0/reference/gridfs/#gridfs-chunks-collection Also, I would like to see MongoDB as a supported storage method for files in some future version of IPS4. MongoDB is probably a better option than using most of the other supported storage methods (especially the File System or the Local Database) as MongoDB is really built to scale infinitely using multiple servers with large Block Storage available. Finally, the list of Storage Methods should probably also include Remote MySQL Database (just like the Forums app supports Archiving to a Remote Database).