Gabriel Torres

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

Is post numbering still in this? 
Is anyone running a plugin or custom edit now they can share? Looking to add post numbering for easier reference.
This seems to work with v4.7.12 so far..

Yes, `3` means they've been excluded from archiving. Most likely because they've been archived before then unarchived.

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.

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

You are very welcome :)
I see what you mean. I have made a note of it for the next version. Thank you for your suggestions again and for your business :)

@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.

This issue was resolved in our recent 4.7.12 release of the platform. Please upgrade to this version to resolve the bug, and if you experience any further issues with this, please let us know.

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.

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.

I haven't used it myself, hence why I was not aware of that. Thank you for the clarification.

These are a part of the converters application.
conv_password misc  

Also misc is not part of the core_members table by default a.f.a.i.k.

'has_blog' and 'has_gallery' is from IPB 3. Was used as a way to check if a member had a blog or gallery before displaying links to manage them
<if test="hasblog:|:$author['has_blog'] AND IPSLib::appIsInstalled( 'blog' )"> <li><a href='{parse url="app=blog&amp;module=display&amp;section=blog&amp;show_members_blogs={$author['member_id']}" base="public"}' title='{$this->lang->words['view_blog']}'>{parse replacement="blog_link"}</a></li> </if> <if test="hasgallery:|:$author['has_gallery'] AND IPSLib::appIsInstalled( 'gallery' )"> <li><a href='{parse url="app=gallery&amp;module=user&amp;section=user&amp;user={$author['member_id']}" base="public"}' title='{$this->lang->words['view_gallery']}'>{parse replacement="gallery_link"}</a></li> </if>  'conv_password' and 'misc' is also IPB3. Looks like this was the password hash from whatever software you converted from.
/** * Joomla! */ private function joomla ( $username, $email, $password ) { if ( $this->parent->_memberData['conv_password'] == md5 ( $password . $this->parent->_memberData['misc'] ) ) { return true; } else { return false; } } All those google_* columns must be from a 3rd party

These two were used by IPS on IP.Board 3.X. Tried to find the step they were removed but couldn't find it; probably on 4.0.0.

@abobader, sorry, it has been fixed. Waiting for approval.
 

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

Same happened here. I had to go to the Marketplace section inside ACP and look for it to update it to the latest version. I knew a new version was out because I am subscribed to receive emails whenever the app is updated.

Thanks, report it to MP Moderator, not me. I'm not responsible for this at all.

All good, everything is working fine, I was probably tired when I tested this.

No test required - you don't get that prompt when pruning.

Even then, it should at least redirect to the expected URL for the button and display the form:

 

Daniel, as far as I know if you ban or mark a member as spammer, the profile page is still visible by other members?

I think a good improvement here would be for the flag as spammer action to clear profile fields, member photo and custom field data as well.  If not their profile will remain as a spam billboard (see above).  
Maybe another complementary option would be to simply have spammed flagged profile not be visible publicly (even the user name is often SEO crafted).