DSystem

Due to personal reasons, had to transfer this file to another dev. @InvisionHQ will support this file from now on.
Thank you.

4.3 release coming today.

We'll start on friday to release the 4.3 versions of our apps:)

I will send you a PM with a fix for it, It seems there is something missing from the database
No nothing is needed for 4.3

Hello,
Use vesion 1.0.7

Sorry, I could not test yet due to my newborn ?

Hi @Sonya*
Is this 4.3 compatible?
Thanks 

any update for IPB v4.3 ?

This is being discussed with development, I just wanted to let you know we're not ignoring it. One proposed solution moving forward is to incorporate our own event trigger system - for example, when a reaction is provided, send a "reactionGiven" event that you can then work with. This allows you extendability without us needing to get hacky. 
Once the core devs have given more insight, I'll update this so we're all on the same page. 

We are exploring possibilities as Lindy said, including implementing more event-based triggers (which we do in some places already, such as MemberSync extensions) and looking into adjusting the hooking system to allow it to work with traits as well. As Lindy said, we will update everyone with more information in due course.
 

Account deactivation will be coming very shortly, but this is not to be confused with account deletion. There are no immediate plans for an automated deletion system for various reasons outlined in other topics. It's worth noting that the GDPR provides for lawful bases of collection and processing of information. If money has been exchanged, for example, they cannot demand you delete their account and existence provided you have a purpose for retaining it and in the US, we are obligated to maintain financial and legal records. You must, however, outline a retention policy (ours will be forthcoming.) In terms of content, unless a post or other content item contains personally identifiable information such as a physical address, you do NOT have to delete a member's content - it belongs to the community, not the member (and that should be clear in your policy.) 
So, the impending account deactivation will disable the profile and effectively archive the account. There will be no way to contact the member, even with an admin override (and no such modifications will be allowed in the marketplace) through the software and they will receive no further communication from the site. This will satisfy requests in which the user wants to leave but cannot be forgotten. 
Right to erasure requests for which there's no legal basis for processing (communities where there's no contractual premise) an do require deletion would still need to be processed manually by the admin. Again, there's too much to consider there - hacked accounts, validation, purchase records, etc. for us to comfortably automate without a fairly significant amount of development time, testing and resources and our efforts are better focused on keeping people on your community, not spending weeks developing functionality to allow them to delete themselves with the click of a button.  
We'll have more info on GDPR as it relates to IPS and account deactivation soon. Thanks for your patience. 

What's New in Version 1.0.1:
Added support to Personal Conversations.

Excellent application. It would be even better if it worked on the MPs too ....

Lindy, you know i understand about servers and im not expecting to have my server down, and if its down, i will put it up right away.
What im telling is that we are not online 24 hours a day. If elasticsearch fails, ips could fallback to mysql. It doesn't need to rebuild the whole index. IPS supports rebuilding only the last few days, that will take few space and its fast.
Like i said, just a suggestion and im not expecting my server to fail. ?

Updated to 1.0.5
Completly redesigned the tables on the pages so it is a look nicer to look at Added 3D pie charts next to the graphs showing more stats Shows the member count per user group Shows the member count per club Shows the downloads file count per category Shows the post count per forum Shows the topic count per forum Shows the reaction count per reaction Shows the warning points per usergroup Few other design changes as well making it easier on the eyes DEMO

New update with the following changes.
 

I configured it to 50. I have only 37 records. You can use 1000 if you want.

I tested it with 19 and 20:
19-> Perfect
20-> does not work

I agree with @opentype.
Btw, new version will have a new ACP module with a list of members (filters) who confirmed or not the email. You will be able to set a specific member as unconfirmed.

Google makes it clear that sitemaps will always be of some benefit, especially to larger sites:
https://support.google.com/webmasters/answer/156184?hl=en
It's not a guarantee of course - though it does says it will always be of some benefit..
So IPS may as well optimise it to the best they can by ensuring it's as complete as possible by the time Googlebot reads it.

Found one more sitemap problem.
<lastmod> tag show generation time of the current sitemap file. It's right, but.. What is tell standard
So, coming back to our case, now we have 5271 sitemap files. So google should get all of them! He get information 'it's modified! take it' and doesn't matter content inside changed or not. Moreover - inside sub-sitemap with url's we didn't have any <lastmod> tags. So google get very old url to subsitemap file, get it and see just list of urls without additional meta information.
 
My proposal:
add <lastmod> tag to every url inside all sub-sutemaps. It will tell google which urls contain new elements and which should be scan and it tell which one not changed and not need to re-scan => will optimize scan perfomance.
Add <lastmod> tag to index sitemap file, which never tell date of this file generation - it should provide newer date of last modified url inside this file. With that google never download sitemap with 500 urls where no changes exist => will optimize scan perfomance.
P.S. I'll try to create a patch. If i do this - i'll share it here (for other dev's checks and helping IPS).
Thanks for you attension and support )

IPS Sitemap generator using special database table source for refreshing - core_sitemap.
Primary search engine source of sitemap is url https://example.com/sitemap.php which is list of sub-sitemap files. You can see list of that files proceed for this link.
Each of that file contain no more than 1000 urls to specail pages (profile status, topic (without number of pages or comment) and other elements, with supported sitemap as core extension).
One of our case is forum with more than 100k topics, more than 4.2kk posts and more than 6kk users. So with simply math we have 5214 sitemap files (you can simply count number of that files with command 
select count(*) from core_sitemap; // 5214 Sitemap generator task run by default once per 15 minuts and update only one oldest element from that big list. With simple math we can try to answer question 'how many time we need for update everything?' (because users can post not only in newest and may post in some old topics... but.. new created topic will add to sitemap file only when ALL older files will newer than current file with new topic inside). So, how much time we need for update?
5214*15 = 78210 minuts = 1303 hours = 54 days! 54! days! Search engine will add your newest content after 54 days after them posted. Incredible thing. Not believe? Or want to know this lag for your community? You can simple know your lag time with that sql:
select FROM_UNIXTIME(updated,'%a %b %d %H:%i:%s UTC %Y') from core_sitemap order by updated asc limit 1; // Wed Nov 01 14:13:49 UTC 2017 Yep.. In our case oldest file last updated in 1 November...
What we should do for fix it? Very fast solution - create a temp file, like a 'mycustomsitemapupdater.php' with this content:
<?php require 'init.php'; $generator = new \IPS\Sitemap; $generator->buildNextSitemap(); $last = \IPS\Db::i()->select('FROM_UNIXTIME(updated, "%a %b %d %H:%i:%s UTC %Y")', 'core_sitemap', null, 'updated asc', 1)->first(); print_r('Oldest time now: ' . $last . PHP_EOL); And run it via web or cli so times, what you want (before oldest time not be so old).
Solution for a longer time - add this script to the cron and run it every minute or, which better - change task 'sitemap generator' run time from 15 mins to one minute (but it may be not solve you special problem, if you need to update it faster - do it with smart).
Better solution - wait for IPS updating of that system.
Thanks for attension!
P.S. If you read my text with negative speach - it's wrong. I love IPS and just want to make attension for that problem and help others with their large communities. 

Updated to 1.0.4
New Features
Added a new widget for IPDownloads Shows the total amount of files uploaded Shows the total amount of authors Shows the total amount of views Shows the total amount of downloads Shows the total amount of comments Shows the total amount of reviews Bug Fixes
Added the missing language strings

After a few trials I've finally succeed on creating a sandbox copy of our comunity. It allows us to make some development, modules or functionalities tests before setting them into the production one.
Our need was to create a copy into the same hosting space without polluting the production one. So here is how I made it :
I - Copy
Files
First of all you need to create a copy of your community files, in our hosted space the files where located into the /www/ folder, so I simply ssh loged in and ran a :
copy -aR ./www ./sandbox
It is the fastest way to create a local copy, but you can also FTP-download your community files then FTP-upload them again into the new folder : Depending on the size of your community it can take very long to perform in that way.
To ensure there is no damage done to the original community, we move it to a new folder during the time the sandbox is created (and set-up an apologize under maintenance page during this time), something like : mv ./www ./protect . So the sandbox will not be able to overwrite anything into the original files path considering it'll not be able to find them...  
 
DataBase
You'll also need to create a copy of your community database :
1) Create an empty new MySQL database ;
2) I use MySQLDumper to create a database backup file from the production community database ;
3) Then I set up MySQLDumper to connect into the new empty MySQL database and restore the database. If you've a big database like us, you may consider to ignore the forum_core_search_index table, some logs tables and private messages tables, depending on your needs.
 
II - Setup
For the moment you just have some kind of a "raw copy" of your community, but you can't use it  : dont even try, you may damage your original community if you do. So don't try to access your copy sandbox before step III-Final Adjustments here below.
 
Access
For our needs I've created a subdomain to access the sandbox content, something like sandbox.mycommunity.com, pointing to the new ./sandbox copy folder just created before. I suppose it may work in a subfolder of your main website too, but I considered it too risky before even try it.
 
Files 
As usually when moving a CMS to another place, the first file to set up is conf_global.php , you'll need to set-up your new database name, user and password. But don't forget to change the "board_url" field in order to set the access url to access your sandbox copy.
You'll also need to modify the .htaccess file at the root folder of your community to set the right (sub)domain name or path into the rewrite rules.
 
Database
Now we're gettin' into the serious part of this. You'll need to modify "by hand" your new database : I use phpMyAdmin, kindly provided by our hosting company as a standard service. But you can install it by yourself or even use MySQLDumper just after the restoration to perform these modifications. So here are the list of the tables and fields you'll need to fix by setting your access url and most important of all : the absolute storage path of your sandbox copy. Through an ssh access just type pwd and you'll see where you are... (example : original /home/me/www -> sandbox /home/me/sandbox ) 
. In table forum_core_sys_conf_settings, update the conf_value field, for the following conf_key values
- sitemap_url
- posts_add_nofollow_exclude
- home_url
- theme_disk_cache_path
- board_name (optional)
- home_name (optional)
. In table forum_core_file_storage, for the field ID=1, update the configuration field value ;
 
III - Final Adjustments
Now you can access to your copy sandbox through your navigator : but try to connect directly to the APC in order to make the final adjustments.
. First of all : if you're caching files, you may need to change the cahing files folder : you'll need to download then upload a configuration.php file in order to apply it.
. Set a valid licence number : in the APC, go to the licence number menu item then set a valid key distinct from the original community one. We use the -TESTINSTALL key for that (your original key by adding -TESTINSTALL at the end).
. Run a support diagnose to reset the theme cache and check everything is ok. If needed fix any encountered problem.
. Depending on how you've copied your database, you may need to rebuild the index database by going to the "search" tab (in the APC) then "rebuild search index". If you have a big community, it could take several hours.
. Don't forget to create a new cron task if you were scheduling in that way...
. Finally, if you've moved your original comunity for a safer copy creation, now you can restore it back.
 
It's done ! You've your full copy sandbox for whatever you may need it !
Thankyou for reading !

OK I will fire a update in the next day or 2 with them included