bfarber

Can you say more as to what you are trying to do? If they don't have permission to an area, a 403 response is correct.

The site will run the same way either way. I would recommend switching to InnoDB. It performs better and has more reliable redundancy should something go wrong.

Yes, if you delete a forum and choose to delete the contents within it, that will include archived posts. If you choose to move topics when you delete the forum, it will include archived posts.

There is no built in avatar gallery I'm afraid, and when you use "import from URL" the image file is actually fully imported as a new attached file. We don't support remotely linked images, except for social networking service profile photos.

Per our blog entries regarding the mobile app, we are building out one app that communities can utilize first, and will explore white-label options (that is, allowing individual communities to have their "own" version of the app just for their community) later.

So the first thing I want to say is that it is normal to have some queries not using indexes. For instance, we load all forums up into memory, and when you select all rows from a table no particular index is used (since there is no filtering occurring). You can't solve all of those types of queries. /*IPS\Patterns\hook543::load:17*/ SELECT * FROM `membersshop_points` WHERE `member_id`=10282; You have a member shop application or plugin installed which needs an index on membershop_points.member_id column. /*IPS\Http\Url\cms_hook_FriendlyUrl::createFriendlyUrlFromComponents:55*/ SELECT store_current_id FROM `cms_url_store` WHERE store_type='page' and store_path='fbclid=IwAR16ELYSJqeQ0TjcQoAaPOQFNEZDw6C2zfGHKAtHwPCToBE5SILpAsvUtWI'; This has already been addressed for 4.5, though it's unlikely to be slow for most communities regardless. /*IPS\Theme\Cache\class_membersshop_front_widgets::mostpoints:61*/ SELECT * FROM `core_members` ORDER BY core_members.shop_points DESC LIMIT 6; Again, your member shop application. You may get some performance by adding an index on core_members.shop_points and/or the query may need to be adjusted. /*IPS\featuredcontent\_Slider::fromCustom:638*/ SELECT * FROM `featuredcontent_contents` WHERE fcc_slider=70 ORDER BY RAND() LIMIT 0,20; Order by RAND() is always going to be horrible. This should be changed by the plugin author. We have a pseudo-random approach when we order "randomly".

Not en-masse, but if you look at an account in the AdminCP you'll be able to see if that specific account has connected with any third party services in the left hand column.

Typically if they indeed logged out, their access token would be invalidated, so that sounds normal too on the surface. But to answer your question, no, I don't know how you would know which user is trying to login before they in fact try to login. You could potentially set a cookie that is not cleared upon logout to track this information if you needed to, but that might represent a minor security concern (i.e. a user logs out, but PII remains in place).

What I would do personally is to take the CSV file and open it in my editor, and then use regular expressions in the search/replace feature of my editor to turn something like (assuming the email address is the only column)... ^(.+?)$ into UPDATE core_members SET allow_admin_mails=0 WHERE email='$1'; I don't know the specific format of your CSV file though, what editor you might use, your skill level with regular expressions, etc. I was just giving you generalized "this is how you turn off bulk mails for an email address" information so you could formulate a better plan on how to do it in bulk.

The proper way to do this would be to write a plugin against \IPS\nexus\Support\Reply to remove the form element, and then to build the content to be saved. In order to do this properly, though, you'd need a good grasp on our framework and how content items work and interact. I'm glad you've found a solution that works for you, but just wanted to respond for anyone else who may come across this.

I believe this has been changed for 4.5 already.

In phpmyadmin it's as simple as changing the table type. That said, you should ensure your webhost has optimized your MySQL configuration for InnoDB first.

Archiving moves posts out of the main posts table into an archived posts table. This can make the forums_posts table smaller, which will improve performance for any sort of action that hits the posts table. i.e. instead of 10,000,000 posts in the forums_posts table, if you end up with 4,000,000 and 6,000,000 in a backup table, then any action against the main posts table will undoubtedly perform faster. The forums_archive_posts table can even be stored in a completely separate database if appropriate for your environment.

An access token should be generated for every single user that logs in - that's normal.

Yeah, you're missing a database table. You can run the support tool in the AdminCP if you're able to access it, but otherwise I'd recommend a support ticket.

For those email addresses in core_members.email, change the column core_members.allow_admin_mails to 0.

Simply changing or removing the word "required" won't make it not required. You will need a customization to accomplish what you are after.

For the search index if the size is a concern, you can configure your site to only store the last X days in the search index (e.g. you could limit to the last 365 days of data, but note that you won't be able to search for content older than this if you do).

Unfortunately it's a generic language string, so changing the language string would adjust it everywhere. Similarly, no custom form template is used, so you'd have to edit core form templates to make any changes, which would apply everywhere.

That is correct, a billing agreement cannot be changed - it has to be cancelled and a new one established.

It's a recommended attribute and frankly, one that's difficult to determine. https://schema.org/eventAttendanceMode The software doesn't really "know" whether the event is occurring online-only or in the real world. We could make an assumption based on whether an address is supplied, but that's not reliable. As this is only a recommended property, it can be safely skipped.

It's not an issue. I can't reproduce the title issue testing locally, so it may have been fixed already for 4.5. We produce an RSS feed, not an ATOM feed, so the notice about atom:link can be ignored. I don't see any instance of ipsnoembed in the HTML you copied, but that is going to come down to the fact that descriptions accept WYSIWYG content which we are outputting without modifying (the same as the warning about using HTML in descriptions). It is my opinion this can be safely ignored.

Define "too large". If you have a large site, then those tables may be large. If you do not have a large site, then those sizes seem excessive to me. It's all contextually dependent upon details about your site which you haven't shared.

It takes some time - how long have you given it to archive?

I would recommend running the support tool to disable everything custom (plugins, themes, etc.) and if the issue persists, submit a ticket.