Yes. If you only use the free registration features of ProfilePress, the subscription columns simply stay empty. Member, role, and joined date still resolve from the standard WordPress user fields. The join to the subscriptions table returns no rows, which is fine: the view degrades gracefully to a registration-focused grid with no errors or warnings.

You can edit notes and metadata directly from the row. Status changes that touch payment gateways still go through the gateway dashboard, since the gateway is the source of truth on subscription state. Cancelling a subscription, for example, must happen through Stripe or PayPal so the recurring charge stops correctly. Internal annotations stay in SleekView.

By default the active one shows on the row, since that is what most operational questions need. Open the row drawer to see and edit the full subscription history, including expired, cancelled, and past-due rows. For members with multiple concurrent subscriptions, the drawer lists each separately with its own status and renewal date.

No. SleekView paginates server-side and only joins the columns you select. A membership site with thousands of members and complex subscription history still loads quickly because each page query reads only the visible page. Adding indexes on the foreign-key columns linking subscriptions to users speeds the joins further if needed.

Yes. SleekView reads whatever ProfilePress has already stored about the gateway and the payment. Gateway changes still happen on the gateway side, but the view shows the result locally as soon as ProfilePress's webhook updates the table. Payment method, transaction ID, and gateway status surface as columns when configured.

Yes, with current filters applied. Useful for reporting, board updates, or feeding email tools with a targeted segment. The export includes only the rows matching the active filter and only the columns you have visible. A past-due export becomes the file the save-the-customer email goes out from. A top-50 lifetime value export becomes the VIP announcement list.

SleekView aggregates completed payments per member from the orders table. The column reflects the running sum at the moment the view loads, including any one-off purchases alongside recurring subscription payments. Refunds reduce the value if the orders table records them as such. The calculation runs as part of the join, so adding the column does not require any precomputation.

ProfilePress restricts content based on plan. SleekView can surface the active plan as a column, which is the proxy for content access. For per-post or per-category restriction debugging, the plugin's own restriction settings remain the source of truth. The view tells you which member is on which plan, which usually answers the access question without a separate trip.