bfarber

You could search for all members in a group and then choose to delete all of those users. It would take some time for this to happen via the background tasks but I would strongly discourage you from trying to do this in the database directly (there are tons and tons of tables that would need to be considered).
Just search for all users in the "Members" group and choose to delete the results. Repeat for each group except admins, and then delete any admin accounts except yours one by one.

You're misunderstanding my suggestion. Yeah you definitely don't want to delete each member one by one. I'm suggesting you use the "mass" tools available for managing accounts.
Do this:
Log in to the AdminCP Visit Members > Groups Click the number next to the "Members" group. You will see a list of members. Then click the link to prune all of the results found as seen in this screenshot
 
Repeat those steps for each group, except for admins which you'll delete one by one because you'll need to preserve your own account (there shouldn't be that many admins so this shouldn't be a problem).

As I recall (I don't work on that area very much) you have to get approved by Facebook manually and it can be a challenging process. I'm not 100% certain on that off the top of my head though.

You're misunderstanding my suggestion. Yeah you definitely don't want to delete each member one by one. I'm suggesting you use the "mass" tools available for managing accounts.
Do this:
Log in to the AdminCP Visit Members > Groups Click the number next to the "Members" group. You will see a list of members. Then click the link to prune all of the results found as seen in this screenshot
 
Repeat those steps for each group, except for admins which you'll delete one by one because you'll need to preserve your own account (there shouldn't be that many admins so this shouldn't be a problem).

If you are not using email validation why do you have accounts pending validation that you want to delete? Those should, in theory, be accounts pending admin validation and you should go through them to either validate or deny the registration.

Facebook changes things on their end practically weekly (at least it feels that way sometimes) so it is challenging to keep the guide up to date.

Did you remove Downloads by chance? It seems like you are attempting to view a purchase of a file in Downloads but the templates can't be found.

This is a built in item,  In your admincp live search, search for analytics, open the link of "Enable analytics tracking code" select "other" and paste in your code.
 
 

Go to your AdminCP -> Editor -> Toolbars Find a button for Page in the buttons that are not on toolbar  Drag the button into your toolbar Visit the website, open an article and add a page break with this button into your article.

Do you have an example URL that you want to embed which doesn't automatically embed?

If you made a new forum (not category) to place them in, you could run the following database query to move your existing orphaned topics to the new forum (make sure you take a full database backup first in case anything goes wrong).
update forums_topics set forum_id=X where forum_id not in(select id from forums_forums); Replace 'X' with the new forum id you just created, and add any database table prefix you may have to the two table names.

We use Instagram's oembed endpoint. You can test their URLs yourself here:
https://api.instagram.com/oembed/?url=https://www.instagram.com/coryrichards/
^ Doesn't work
Example working URL: https://api.instagram.com/oembed/?url=http://instagr.am/p/fA9uwTtkSN/
We don't control which Instagram URLs Instagram will support with their oembed endpoint I'm afraid.

I'm not sure I know how to answer that.
For the editor, when you paste a link in that we know an oembed endpoint can handle, we send it to that endpoint, and then generally embed the content that the endpoint returns. Look at the "html" property of this JSON object for instance - it has the full HTML to embed:
https://api.instagram.com/oembed/?url=http://instagr.am/p/fA9uwTtkSN/

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.

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.

Most of the time this is due to mod_security on the server, or a similar "firewall" or security protection.

Oh I had the brilliant idea of add a hidden field name 'module'.
Thank you! 👍

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.

Elasticsearch will provide vastly superior search results, however it is a remote service so your community will need to make HTTP requests to it in order to index the content, and to fetch the search results. That said, the searching is faster than MySQL particularly for larger data sets.
Generally speaking, if you get to a million or two posts, you should probably switch over to ElasticSearch. Before that point, you would really just need to try it out and see if you prefer it or not. If you have a really fast server and a relatively smaller site, you may find that local MySQL searches are sufficient, and perform faster, than a remote service.

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

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.

No, there is no way to go back to the previous method.
We ran into an issue in our own code using HTML with this new method, which we've since addressed. It seems unlikely we will be returning to the older method for the MR output.

You should visit Customization > Themes in the AdminCP, click the dropdown next to your theme and go to Manage Resources. Upload the font here, and then take the replacement tag (which generates the URL) and use that in your custom.css.
Your solution is fine and will work, but the above method will benefit from using our storage handling system properly. i.e. if you move your theme resources to S3 for performance reasons, your font would be moved as well, and the CSS file would automatically update to reflect the new URL.

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

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