Documentation

WordPress admin

You run the studio from WordPress admin. Log in, then open the Mankai CRM menu.

That menu opens the CRM on admin.php?page=mankai. A screen inside it adds route. Sessions is admin.php?page=mankai&route=sessions. Session types is route=session-types. Clients is route=users. Messages is route=conversations. Calendar is route=calendar. Galleries is route=galleries.

The studio list in that screen is Overview, Clients, Messages, Calendar, Sessions, Galleries, and Session Types. Setup Wizard and License sit on the WordPress menu next to Mankai CRM. You do not need the companion theme for any of this.

The person who runs it needs to be a WordPress Administrator (manage_options). People who log into the client portal are subscriber, customer, or client users. There is no separate Owner role. If a role plugin strips manage_options, the Mankai menu disappears.

Booking

A session type is the offering. You edit it in WordPress admin, under Mankai CRM, on Session Types. It decides the public name, the price, the hours, and what gets created after someone books. The public booking page reads that record.

The public link

One offering uses ?form= plus the session type key. Example: yoursite.com/book/?form=family-session.

If that query is missing and exactly one session type is Active, that type is selected. If none are Active, or more than one is Active, and the link has no key, the client sees: "This booking link is not set up yet. Please contact us for help." Turn one type on, or pass ?form=.

Active is the public switch. Leave it off while the offering is still a draft. The display name, tagline, description, and featured image are what the booking page uses.

Money on the booking

Payment at booking is a fixed deposit or pay in full. On checkout those read as Retainer and Session total. A zero retainer skips the payment step. If you require money, connect Stripe or PayPal first.

You set starting price, duration, and delivery time on the session type. Deliverables are one per line. Proofing counts and extra-image prices live there too, not on the page.

Hours

A session type can use the studio schedule or its own. Days, start and end, booking notice, a daily cap, and buffer before or after the appointment are what the public form offers. It will not show a closed time.

Booking on studio hours is in Free. Weekly hour limits and limited dates are Pro.

After they submit

You can attach a questionnaire, and a contract if they sign during booking. Test in a private window. An Administrator login is not the client view. The new client and session show up under Mankai CRM. When the day is full, that time drops off the form.

Session statuses are Payment pending, Booked, Confirmed, Completed, Editing, Culling, Awaiting Gallery, Delivered, and Cancelled.

Gutenberg blocks

The blocks that register are in the Mankai inserter group. They read the CRM. They do not keep a second copy of the data in the post.

• mankai/testimonials
• mankai/contact-form
• mankai/gift-card
• mankai/identity
• mankai/cta
• mankai/offerings and mankai/portfolio when those singles are public

Offerings is the session-type catalog. Portfolio is the public grid of work. Client proofing galleries are not that block. Those stay in Galleries inside Mankai CRM, and the client opens them from the portal on your domain.

Identity can show studio name, email, phone, address, and hours, plus social links. Contact form and gift card pull their fields from Mankai. Changing the session type or the studio details in admin changes the block. You do not retype them in Gutenberg.

The public booking page is the booking URL, with ?form= when you mean one session type.

Elementor widgets

Elementor is optional. The site does not need it. If it is installed, it needs 3.18 or newer or the Mankai widgets stay unregistered and you get an admin warning.

The widgets sit in an Elementor category named Mankai. They use the same renderers as the Gutenberg blocks, so the CRM still owns the records. Elementor owns the look. Each widget has a Style tab. An untouched control writes no inline CSS, so the widget keeps the plugin look until you move something. After that, typography, spacing, and color are yours, per widget.

Motion is on that Style tab too: none, fade up, fade in, slide left, slide right.

What you can drop in

• Testimonials
• Call to Action
• Identity
• Contact Form
• Gift Card
• Mankai Packages
• Sessions Grid and Sessions Slider
• Portfolio Grid and Portfolio Slider

Sessions Grid and Sessions Slider list bookable session types. Portfolio Grid and Portfolio Slider list public work. Packages belongs on a session group template, or you pick a category or specific session types. If a package widget is empty, that group or category has nothing bookable yet.

Do not rebuild the offering as a generic Elementor form. That form does not write a Mankai session. Use the Mankai contact form widget for inquiries, and the booking URL for a session type.

Invoices, the client portal, and proofing galleries are screens inside Mankai CRM. They are not Elementor widgets.

Payments

Card payments go through the Stripe or PayPal account you connect. One gateway is active at a time. There is no Square. Mankai does not add a percentage. The processor still charges its fee. The client pays on your domain.

In WordPress admin, open Mankai CRM, then Payments, and choose the provider.

Stripe

1. In Stripe open Developers, then API keys.
2. Copy the publishable key and the secret key into Mankai.
3. Use test keys first.
4. Copy the webhook address shown in Mankai and add it in Stripe. I am not printing a Stripe path here. The screen is the source.
5. Save, then pay a test booking or a test invoice.

PayPal

1. In the PayPal Developer Dashboard, create or select an app.
2. Copy the Client ID and secret into Mankai.
3. Add the webhook Mankai shows you. The standard path ends in /wp-json/cp-portal/v1/paypal-webhook.
4. Use sandbox keys, save, and run a test payment.

How you know it worked

• The client sees the right amount and currency.
• Stripe or PayPal shows a successful test charge.
• Mankai writes a Payment record.
• The invoice or the session balance moves.
• The client gets the receipt email you expected.

Then replace test or sandbox keys with live keys, save again, and run one small live payment. Do not paste secret keys into email or screenshots.

Cash, check, bank transfer, and Venmo are manual Payment records. They do not need a gateway, and they do not fire the card webhook.

Webhooks

Two different calls get called webhooks. Mixing them up is how payments look "connected" while the CRM never hears about the charge.

Inbound, from the processor

Stripe and PayPal POST back to your site after a payment. That URL is configured under Settings, then Payments. PayPal's standard path ends in /wp-json/cp-portal/v1/paypal-webhook. Stripe's path is whatever Mankai prints on that screen. If this URL is wrong, you can still see a charge in the processor and have no Payment record.

Outbound, to your tools

Mankai can POST out when a booking is made, a payment lands, or a gallery is delivered. The target can be Zapier, Make, or a URL you run. That call is a notice. The client and the session still live in your database. I have not published the JSON body, headers, or signing for that outbound POST. If you are writing the receiver, contact me and say which event you are catching. I will send the fields. I am not going to invent a sample payload on this page.

Email

Mankai uses a mailbox you already own. IMAP reads replies into the CRM. SMTP sends as your studio address. There is no Gmail or Microsoft OAuth button. If the provider uses two-factor, you need an app password. Your normal login password often fails, and hammering a bad password can lock the mailbox.

In WordPress admin, open Mankai CRM, then Email. You need the IMAP host, port, and encryption, the SMTP host, port, and encryption, the full address, and the app password. Set the sender name and reply-to. Test incoming, then send a test, and only then save.

Prove it on a different provider than the one you send from. Reply to that message. The reply should land in Inbox and sit on the right client. Check spam. Your domain still wants SPF, DKIM, and DMARC or the nice templates will not matter.

Workflows send those templates on a schedule. They run through WP-Cron, with an hourly automation pass and a jobs queue. If WP-Cron never runs because traffic is dead or a host disabled it, the emails wait. Fix cron before you blame the template. Rewrite the demo wording before you turn a workflow on.

Galleries

A client gallery is the shoot, on your domain. You build it under Mankai CRM, Galleries. Files live on your hosting. There is no per-gallery meter from me.

The client screen says "Add to favourites". The other actions there are Proofing and Download Photos. Watermarks, who can download, and how proofing works are gallery settings in that admin screen. They are not Elementor controls.

The Portfolio Grid and Portfolio Slider widgets are the public work on the website. They are not the private proofing gallery. If favorites never save, you placed a normal image widget. Proofing only happens on the gallery the client opens from your portal.

License and data

Clients, sessions, invoices, gallery settings, forms, workflows, and email templates live in your WordPress database. Gallery files live on your media storage. I cannot see that install from here.

Pro is a yearly license through Freemius. If it runs out, the site goes back to the free plugin. You are not locked out. Clients, sessions, galleries, and files stay. Nothing is deleted because the license lapsed. Pro features come back when you renew. Uninstall does not wipe business data unless you turn that option on.

Hosting, backups, WordPress updates, DNS, and whether your server can actually send mail stay your job. I cover the plugin.