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.