Installation FAQ

The plugin is distributed privately rather than through the WordPress.org directory, so you install it by uploading a zip:

1. Download the current release from Connection in the builder.
2. In WordPress, go to Plugins → Add New → Upload Plugin and choose the file.
3. Activate it.

Once it is active the plugin checks for its own updates, so this is a one-time upload rather than something to repeat every release.

It needs PHP 7.4 or newer. Anything older and WordPress will refuse to activate it rather than half-installing.

Connecting mints a credential on your site and hands it to the builder, so the two things that break it are both about reachability.

Work through these in order:

• The site must be reachable from the public internet. A local install, a staging site behind HTTP authentication, or one restricted by IP cannot be connected — there is nothing for us to call.
• HTTPS is required, with a certificate that validates. A self-signed or expired certificate fails the handshake.
• Application passwords must be enabled. Some security plugins and hosts turn them off. WordPress disables them automatically on sites served over plain HTTP, which is usually the real cause when the option seems to be missing.
• A security plugin may be blocking the REST API. Wordfence, iThemes and several hosts’ own firewalls can block unauthenticated REST requests by default.

If all four are in order and it still fails, the connection screen shows the exact response we got back. Put that on a ticket rather than paraphrasing it — it is usually enough to identify the cause on the first reply.

Every Memberside endpoint is off until you turn it on. That is deliberate: the plugin should add no public surface to your site that you did not ask for. The cost is that a feature placed in the builder before its endpoint is enabled shows an empty screen, and the request behind it returns 404 rather than an error that explains itself.

Placing a feature now switches its endpoint group on for you. Removing one never switches anything off, because another feature may still be using it.

For an app built before that behaviour existed, or for a group that was turned off by hand, open Memberside → Endpoints in your WordPress admin and enable the group the screen needs. The name of the group matches the feature.

No, and this is a rule rather than a preference. Apple’s guideline 4.2.6 rejects apps submitted on a client’s behalf by a service that generates them. An app has to be submitted from the developer account of the organisation it belongs to.

So you will need your own Apple Developer membership and your own Google Play Console account, and you submit from them. We generate the signed build, the store listing text, the screenshots and the reviewer notes — everything that goes into the submission — and the submission itself is yours to make.

Memberside reads whatever is already on your site. The core plugin is enough for profiles, directories, registration and login; individual features need the plugin that owns the data — chat needs a messaging plugin, groups need a groups plugin, and so on. A feature whose plugin is missing or deactivated appears greyed out in the builder rather than failing later.

Version matters. Each release is tested against a specific range, and the builder warns you when a plugin on your site is newer than anything we have verified. The warning is not a block: it means we have not tested that combination, so tell us if something looks wrong on it.

The most common real conflict is not a plugin at all but a caching layer serving REST responses to the wrong member. Exclude the Memberside routes from the page cache if you see one member’s data on another member’s screen.

Each part of that stack has native screens today:

• Paid Memberships Pro. Membership Levels, My Membership and Membership Orders. Any screen in the app can also be restricted to members who hold one of the levels you tick, and a Match setting of All or Any decides how that combines with a role restriction.
• BuddyBoss Platform, or BuddyPress. Profiles, the member directory, the activity feed, groups, connections, one-to-one messages, notifications and forums. On BuddyBoss you place the BuddyPress and bbPress feature cards, and they read its components under BuddyBoss’s own names.
• WooCommerce. A native shop, product pages and a cart, with checkout on your own site. Order history, saved cards and addresses appear in the account area when Ultimate Member and Ultimate Member - WooCommerce are installed as well.
• Better Messages. A native inbox with one-to-one and group conversations and an optional chat-room browser. New messages arrive live when Realtime is connected, and on refresh without it.

BuddyBoss has components BuddyPress does not, and some of them are not native yet: photos, documents and videos, group message threads, email invites, moderation, and the full reactions picker. The supported plugins page lists every BuddyBoss component and what the app does with it, and it changes as releases ship.

Selling those memberships inside the app is a separate question, decided by Apple and Google rather than by any plugin. The Selling FAQ covers it.

Not yet. None of the three has native screens, and that includes FluentCommunity’s own courses. There are no course screens of any kind today: no course catalogue, no lessons and no progress tracking.

A page from your site can still open inside the app through a Custom Link, as a web page rather than a native screen. Courses are digital content, so the store rules in the Selling FAQ apply to them in the same way they apply to memberships.

What gets built next is decided by what site owners ask for. If your site depends on one of these plugins, open a ticket and say which, or name it when you apply for the beta. Feature requests and beta feedback set the order.