Gabriel Torres

@Marc Stridgen A need a valid email address from you as the one currently associated with your support account is bouncing. Please provide one in private. Thanks.

@Nathan Explosion Our users are being able to bypass the minimum number of characters limitation by simply adding aditional spaces in their posts. It is amazing how instead of following the rules, people spend time thinking about how to break them. The solution would be to treat contiguous space characters as a single character. So, for example, 10 sequential space characters would be counted as a single one. I hope you can add this feature in a future release! 😁 Cheers!

@Marc Stridgen Many thanks. I've created a new admin account for you guys. Take a look at the details there. Let me know if you need any additional info.

@Miss_B Thanks! @Nathan Explosion Not the case. The table has five records. The notifications are simply showing blank. mysql> SELECT * FROM core_member_privacy_actions; +----+-----------+--------------+----------+---------------------------+----------------------------------+ | id | member_id | request_date | approved | action | vkey | +----+-----------+--------------+----------+---------------------------+----------------------------------+ | 4 | 1224358 | 1689211709 | 0 | delete_account_validation | c2648620b439e56e475e8c92e5d3a549 | | 6 | 1224437 | 1689353744 | 0 | delete_account_validation | ff173ab75d2c52433ac3879b18d3f7ba | | 7 | 954094 | 1689753250 | 0 | delete_account_validation | 8ef996a75c13f18214d8dc127b2b9c69 | | 8 | 666863 | 1689804867 | 0 | delete_account_validation | bfcb444869464a65169db10c86c9c90b | | 9 | 1152541 | 1689863595 | 0 | delete_account_validation | b3b9832a507a8bd6159e7870b81e3ff9 | +----+-----------+--------------+----------+---------------------------+----------------------------------+ 5 rows in set (0.00 sec) I will need help from the IPS staff here, thanks!

Hi, I am seeing this lately. An empty notification for user deletion. See screenshot. I don't know which DB table I should be looking into to see if there is actually any account deletion request. Thank you in advance.

Hi, The thumbImage template has two small issues IMHO that should be addressed. {{if $image}} {{$image = ( $image instanceof \IPS\File ) ? (string) $image->url : $image;}} {{if $url}}<a {{if $dataParam}}{$dataParam} {{endif}}href='{$url}' title='{lang="$lang" sprintf="$name"}'{{else}}<span{{endif}} {{if !$lazyLoad || !settings.lazy_load_enabled}}style='background-image: url( "{file="$image" extension="$extension"}" )'{{else}}data-background-src='{file="$image" extension="$extension"}'{{endif}} class='{$classes} ipsThumb ipsThumb_{$size} ipsThumb_bg'> <img {{if $lazyLoad && settings.lazy_load_enabled}}src='{expression="\IPS\Text\Parser::blankImage()"}' data-{{endif}}src='{file="$image" extension="$extension"}' alt=''> {{if $url}}</a>{{else}}</span>{{endif}} {{else}} {{if $url}}<a {{if $dataParam}}{$dataParam} {{endif}}href='{$url}' title='{lang="$lang" sprintf="$name"}'{{else}}<span{{endif}} class='{$classes} ipsNoThumb ipsThumb ipsThumb_{$size}'>{{if $url}}</a>{{else}}</span>{{endif}} {{endif}} 1. The lazy loading scheme used is outdated, as it could simply use the loading="lazy" parameter, as it has been updated in other templates. 2. The alt='' should be replaced with alt='{lang="$lang" sprintf="$name"}' Cheers!

Our users don't know that the date is a link to the post itself...

The numbering of posts could be replaced with a more prominent way of linking to that post. Most of users are not well versed in forums in general, so they don't know that they need to click on the "three dots" and then on "Share" to get a link to a post. I belive a small "link" icon there could facilitate users learning how to link to individual posts.

Hi @Miss_B Today I noticed that you are not using FURL in your app. This could be improved. E.g. scrolling my profile menu (my_privacy_menu_link), I see the URL as: /index.php?app=core&module=system&controller=settings&area=myprofileprivacy It should be /myprofileprivacy Cheers!

Yes, it still works.., 🙂 And definitely should be incorporated in IPS.

Thanks, @Stuart Silvester, I will manually change those records to '0' in order to fix the issue! 🙂

Hi, I enabled topic/post archiving here, with the following parameters: last post: more than 10 years unpinned The system informs that there are 95.305 topics that match this condition, which represent 7% of our total topics. After several days, these posts were archived, but we ended up with several really old topics that weren't archived. The 95.305 number seemed off, since we are online 20+ years with over 1 million topics. Upon further investigating this, I found out that topics that contained the value '3' in the forums_topics.topic_archive_status columns weren't archived. I don't know what this value '3' represents. Maybe a flag for topics that shouldn't be archived? We used archiving several years ago, and disabled it, and maybe because of that all topics that were archived then got this status? Also, I see several new topics being created with this '3' value, mostly topics that are reserved for article comments in Pages. But not all. I just need this confirmation, so I can manually fix this! See below how we could actually archive 830,438 topics, and not only 95,305. The missing 735,133 topics have this '3' status: SELECT count(*) FROM forums_topics WHERE pinned='0' AND last_real_post < 1374439854; 830438 SELECT count(*) FROM forums_topics WHERE pinned='0' AND topic_archive_status = '1' AND last_real_post < 1374439854; 95305 SELECT count(*) FROM forums_topics WHERE pinned='0' AND topic_archive_status = '3' AND last_real_post < 1374439854; 735133 Please advise. Cheers, Gabe.

@Miss_B Many thanks for adding my suggestion to the app! I've just bought it! One small adjustment that needs to be done. You are using the core language string privacy_type (see sreenshot below). You should use a custom language string, this way we can translate this phrase more precisely, as we want to use a different text here compared to the other uses of privacy_type. Thank you in advance! 🙂

Hi, Regarding the "Content I Posted In" (stream_title_5) stream: Create a topic with user A. Reply to this topic with user B. Go to the "Content I Posted In" with both users and you will see the topic listed in their stream correctly. Now, merge this topic into another topic. Go to the "Content I Posted In" with both users and now you will see that the content will be displayed only in user's A stream, but not in user's B. I believe this is a bug. Cheers.

That's it: a tool for automatically pruning old reports from the database, similarly to the tool we have to automatically prune private messages. Cheers.

Thanks for the help, guys! @Ryan Ashbrook Are the conv_password and misc columns safe to remove? We moved from vBulletin to IPS 10+ years ago... LOL I also need some advice if it is safe to remove these: cm_reg referred_by gallery_perms pp_setting_count_visitors Thanks! Thanks, I was able to find their origin here in an old spreadsheet. They were from a plugin called "Sign in through Google", available in the 3.4 era, before this functionality was incorporated in the core software.

Hi, What I discovered so far: member_login_key_expire This was removed in a previous IPS version and it is safe to be dropped. See core/setup/upg_101100/queries.json. allow_multiple_accounts access_attempts registration_attempts unique_machines These belong to an app that we removed in the past, so they are safe to drop. App: CJ Duplicate Member Logger. cim_profile_id cim_payment_id cim_method These belong to Nexus and should be kept as per applications/nexus/setup/upg_11100/queries.json. cm_no_sev cm_return_group cm_credits These belong to Nexus and should be kept as per applications/nexus/setup/upg_10102/queries.json. However, there is another related column that from what I could understand, was replaced with a cookie. I couldn't find a reference to this column in the source files. I don't know if it safe to drop it from core_members: cm_reg This other column seems to have been moved to the core_referrals table according to applications/core/data/schema.json. I don't know if it is safe to drop it from core_members: referred_by These two seem to have became bitoptions. I don't know if it is safe to drop them from core_members: gallery_perms pp_setting_count_visitors The columns below I couldn't find any reference in the source files. I don't know if it is safe to drop them from core_members: google_access_token google_access_expires google_refresh_token google_pass_reset google_uid has_blog has_gallery conv_password misc If someone could review these I'd appreciate it! Thank you in advance, Gabe.

Hi, When pruning members in the ACP, no pop-up window is shown asking us what we want to do with the users' content (delete/hide/leave), differently to the behavior we have when deleting a single user. If we want to mass-delete contents created by several users, we need to delete each user individually, which can take us literally hours of work. Based on that, my suggestion is for you to add this option in a coming release. Thanks.

Tested here and the pruning does the "leave" behavior. I will open a new topic with this suggestion.

@Makoto The search function at Radical Tags > Customize (?app=radtags&module=tags&controller=customize) isn't working here with us. Can you take a look into this? Thanks.

@opentype Ops! I've never noticed this before! 🤦‍♂️ Thanks for the clarification!

Hello, I am in the process of cleaning-up our database, and as we run IPS for for ages now, I believe our core_members table has several columns that were used in previous versions and are no longer needed. I compared the current structure of our core_members table with the default columns listed in the /applications/core/data/schema.json file, and I ended up with the list below of columns that exist in core_members but aren't listed in the schema.json file. | misc | varchar(128) | YES | | NULL | | member_login_key_expire | int(10) | NO | | 0 | | has_blog | text | YES | | NULL | | blogs_recache | tinyint(1) | YES | | NULL | | has_gallery | tinyint(1) | NO | | 0 | | conv_password | varchar(128) | YES | | NULL | | allow_multiple_accounts | tinyint(1) | NO | | 0 | | access_attempts | tinyint(1) | NO | | 0 | | registration_attempts | text | YES | | NULL | | unique_machines | text | YES | | NULL | | google_access_token | varchar(255) | YES | | NULL | | google_access_expires | int(10) | YES | | 0 | | google_refresh_token | varchar(255) | YES | | NULL | | google_pass_reset | int(1) | YES | | 0 | | google_uid | varchar(255) | YES | | NULL | | referred_by | int(11) | NO | | 0 | | cm_no_sev | tinyint(1) | YES | | 0 | | cim_profile_id | varchar(32) | YES | | | | cim_payment_id | int(10) | YES | | 0 | | cim_method | int(5) | NO | | 0 | | cm_return_group | smallint(3) | YES | | 0 | | cm_credits | text | YES | | NULL | | cm_reg | int(11) | NO | | 0 | | gallery_perms | varchar(10) | NO | | 1:1:1 | | pp_setting_count_visitors | int(2) | NO | | 1 | Please let me know which columns are safe to drop. Thank you in advance, Gabe

Hi, In the ACP > Pages > Blocks, there is no option to delete a category, only to create new ones. A button to delete the category should be added. Thanks.

Hi, We enabled archiving here and I noticed a behavior that you may want to address. When a topic is archived, the "state" row is kept in its original value (e.g. "open/closed"). When a closed topic is archived, then we end up having two messages saying that the topic is closed: one because it is archived and another becaise it is closed: This is clearly redundant. When the topic is set as "open", the second message doesn't show up. I believe the row "state" is kept with its original value because if we ever need to restore the topic, it must be restored to with its original state. Anyway, maybe it a matter of adding a logic it a template to supress the second message if the topic is archived, so we get rid of this additional message. For instance: forums > front > topics > topic Original: {{if $topic->commentForm() || $topic->locked() || \IPS\Member::loggedIn()->restrict_post || \IPS\Member::loggedIn()->members_bitoptions['unacknowledged_warnings'] || !\IPS\Member::loggedIn()->checkPostsPerDay()}} Change to: {{if ($topic->commentForm() || $topic->locked() || \IPS\Member::loggedIn()->restrict_post || \IPS\Member::loggedIn()->members_bitoptions['unacknowledged_warnings'] || !\IPS\Member::loggedIn()->checkPostsPerDay()) && !$topic->isArchived()}} This worked great here and I hope you can adjust this in a coming release. Cheers! 🙂

Ok, this is something I believe should be added. What is the default behavior when prunning (delete/hide/leave)? Do you know?