Prefix plan

If you run two of our plugins on one site — say grooming and dog walking, as two separate businesses — each one needs its own names for the things it stores, or they would write into each other’s records. This screen shows what giving this edition its own names would involve on this site: which record types, fields, settings and tables would be renamed, and how many rows sit behind each one.

It is a plan, not a button. Nothing here changes anything, and the plan is counted from your database as it stands rather than assumed from the code.

The last section covers roles and permissions, which are a different shape from everything above them: they are not records of yours, they are entries inside WordPress’s own list of who may do what. They still have to move with the rest, and they are the part with the least room for error — a permission that has moved in one place and not the other means the person holding it is told they are not allowed into their own plugin. As of 2.688.0 they do move with the rest, and both spellings work at once while a move is in progress, so there is no instant at which your team are holding something the plugin is not asking for.

Example

You already run the groomer plugin and you are about to add the walker one for the other half of the business. You open Prefix plan first, see exactly what would move and what would not, and know before you start that nothing is going to be renamed by guesswork. Once this copy has names of its own, the walker one takes its own automatically the moment you activate it — there is nothing further for you to do.

FAQ

Will opening this change my data?
No. It only counts. There is no form on the screen and nothing to submit.

Can two copies both work offline now?
Yes, as of 2.701.0. The staff app has an address of its own, so its offline helper claims only that app rather than the whole website — and a browser allows one of those per app, not one per site. Before that release whichever app you opened last was the only one that worked without signal. You no longer create a page for the app either: it is simply there, and its QR code on the Settings screen always works.

Do my customers see a different address for each copy?
Yes, as of 2.699.0. Each copy has its own client portal, its own invoice and booking links, its own walk reports and its own feedback form — so two copies on one website are two businesses, and a customer of one never arrives at the other’s sign-in. The installable customer app follows the same line: each copy is its own app on the phone, with its own icon and its own offline storage. On Premium you can rename any of these addresses to something of your own; the built-in one keeps working alongside whatever you choose.

If I run two copies, does a button on one screen affect the other?
No. As of 2.698.0 every button in the admin checks which copy’s screen it was pressed on before it acts, and the other copies stand aside. Before that release whichever copy answered first did the work, which on a two-copy site was not reliably the one you were looking at. If your browser is set up to hide where a request came from, a copy that cannot tell handles the request rather than refusing it, so no button ever goes dead.

Why does it say it is not running?
Because the plan is ahead of the code. The names can only change once every place that reads them has been taught the new ones; until then it would be a rename into silence. The screen exists now so the picture is there before the change, not after it.

Why are taxonomies listed separately from the fields?
Because they behave in the opposite way, and putting them together would mislead. A field belongs to one of your records — so once each plugin owns its own kind of record, two plugins can hold a field of the same name without ever touching each other’s. A taxonomy is a list that belongs to the whole website rather than to any one record, so both plugins really would be reaching into the same one. That is why it moves along with your record types instead of being left where it is.

What are the keys with “no prefix to match on”?
Fields with plain names — breed, address — that carry nothing identifying them as ours. They are why the plan is built by walking our own record types and taking every field found on them, rather than by matching names: matching would quietly skip these, and a skipped field just comes back empty.

What happens if it finds something it does not recognise?
It says so and stops. A migration that guesses at one unfamiliar name is worse than one that refuses to start, because the guess is only discovered later, by the data being wrong.

Do I need this if I only run one of your plugins?
No. One plugin on a site has the names to itself and nothing needs to move.

I want to run two trades. What do I actually do?
If this site has no Pet Central records yet, nothing — install both and each takes names of its own as it activates. If you already have clients and bookings, it is two steps: run this screen’s move on the copy you already use, then install the second one. That second step is automatic; there is no setting and nothing to type.

Why can the second copy not just sort itself out?
Because it cannot tell whose records it is looking at. Records under the shared names might belong to the other trade — or to this same plugin from an earlier install that was switched off and on again. Those two look identical from inside the arriving copy, and getting it wrong would leave a working business with screens that are simply empty: nothing broken, nothing in any log, and every record still there under a name nothing asks for. So it refuses to guess, and the copy that owns the records is the one that moves them.

What does the second copy do instead, then?
It writes one line saying what its own records are called, while it is activating — before it has created a single setting, role or table. From that moment everything it makes is its own and it never touches anything of the first copy’s. It is not a migration and there is nothing to undo: a copy with no records has nothing to move.

Is this the same as the move on this screen?
No, and the difference is the whole point. This screen MOVES records that already exist, which is careful, slow work with no undo. A fresh copy CLAIMS a name before it has any records, which is one line and cannot lose anything. Same end state, completely different risk.

Why are roles and permissions listed separately?
Because they are stored differently. Your bookings and settings are records with names of ours on them. A role is an entry in WordPress’s own list of who may do what, and our permissions sit inside it, so nothing that goes looking through your records will ever find them. They are counted here for exactly that reason.

Would my team lose access while it ran?
No, and the migration is built the long way round specifically so they cannot. The new role is created alongside the old one and both work, each person is given both, and only once the move is finished is the old one taken away. There is no moment when somebody is holding a role that does not exist, and a move that is interrupted half way leaves everybody able to work.

What changed about roles in 2.688.0?
Two things. Roles and permissions now take a name of their own when a plugin moves, the same as its records and settings do — before, two of our plugins on one site shared one set of team roles. And the plugin now asks for whichever name your site actually uses, rather than always asking for the original one. Without that second half, moving a plugin would have renamed your team’s roles and then left the plugin asking for the old names: a staff member refused entry to their own app, and a business owner told they could not open their own settings. Nobody has met it — moving a plugin to its own names is still switched off — but it was there.

Why would an administrator not have noticed?
Because being a WordPress administrator gets you past almost every permission check in the plugin. The screens open, the app works, everything looks right — and the only people it is broken for are the ones who do not have an administrator account, which is most of a team. It is the reason this was found by a check that asks the question on behalf of a staff member rather than by anybody using the software.

The calendar link I bookmarked no longer filters by staff. Why?
The staff filter in the address bar is now pc_who. It used to be pc_staff, which was also the name of the staff role and the name of the Staff column on the bookings list — one word doing three jobs, in a plugin that now has to decide which of them moves when a copy takes its own names. Set the filter again and the new link works exactly as the old one did.

It lists something my roles code does not name — is that wrong?
No. The customer role is created by the customer portal rather than by the roles screen, so it appears here as found on the site rather than declared in the code. It is listed plainly instead of quietly, because the plan is always built from what your site actually has.

What is “Shared on purpose”, and why is nothing being renamed there?
Those are the web addresses your customers already hold — the link in an invoice you emailed, a bookmarked account page, an app installed on a phone. They cannot be given each edition its own spelling without breaking links that may be years old, so both editions answer them, deliberately. It is listed so that its absence from the plan above reads as a decision rather than an oversight.

If two editions answer the same address, how does the right one reply?
By whose record the link refers to. Every one of those links names something — an invoice, a booking, an account — and each edition already checks whether that something is one of its own. What changed is what happens when it is not: instead of telling the customer the link is broken, the edition stands aside and lets the other one answer. A link that belongs to neither still gets a straight answer, because somebody has to give one.

If one copy converts, does the other one move too?
No, and this is the fault the first real test of two copies on one website found. When a copy converts its records to its own names it writes a note saying so, and that note used to be kept once for the whole website. The grooming side converted, wrote the note, and the walking side read it and concluded its own records had moved as well — it would have started asking for the grooming side’s clients and bookings as if they were its own. Each copy keeps its own note now. One converting says nothing whatever about the other, and the other goes on reading its own records under their old names until it converts in its turn.

I run two copies. How do I tell which is which in the menu?
By name, by the first item underneath, and by position. Each copy puts its own trade in its menu name — Pet Central Groomer, Pet Central Walker — the first item beneath it says Groomer Dashboard or Walker Dashboard in as many words, and each sits in a fixed place, in that order. Until 2.683.0 both said only “Pet Central”, one above the other, and a WordPress menu entry has no hover text to fall back on. The name is shown whether or not you run two, because a label that appears when a second plugin arrives is a label that changes under you.

Why do both copies show the same paw?
Because it is the same product. Between 2.683.0 and 2.691.0 each trade carried a different icon — shears, a map pin, a house, a book — which did tell two copies apart and also made four plugins look like four unrelated ones. Naming the dashboard underneath does the same job in plain words, so the icon went back to being the brand. Nothing you can do makes them differ; that is deliberate.

How do I add a picture to a package?
On the Packages screen, when you are editing one. Packages are the only thing you edit entirely on our own screen rather than in WordPress, so they do not have the Featured image box or the More pictures panel that treatments and products have — the same controls live on that screen instead. Choose as many as you like at once; the first one you pick is the main picture.

Does the demo data include categories?
Yes, from 2.695.0, and they follow your trade. A groomer’s demo files its treatments under Full grooms, Baths & tidies, Coat treatments, Puppies and Add-ons; a walker’s under Group walks, Solo walks, Home visits and so on. There are only a handful per trade deliberately — a demo that arrives with fifteen categories teaches a habit that makes the booking screens harder to use, not easier.

Does the demo fill the shop as well?
Yes, from 2.695.0 — nine products for your trade, with categories and opening stock. The stock is entered as a delivery through the stock ledger rather than typed in as a number, which is how the shop works for real, and one or two products are deliberately left below their re-order level so you can see the low-stock warning doing its job. Before this the shop seeded nothing at all.

How do I add pictures to a treatment or product?
Open it and use Featured image on the right for the main one — that is the picture used on cards and listings. The More pictures panel underneath holds the rest: Add pictures lets you pick several at once, dragging a tile changes the order they appear in, and the × in a corner removes one. The main picture is not repeated in that panel on purpose; if you promote one of the others to main it leaves the panel by itself, so nothing is ever shown twice.

What happened to the Category box I used to type into?
It has become a proper list, shared by treatments, products and packages, so the same category can be used across all three and can carry a picture of its own. Whatever you had typed was turned into entries in that list automatically the first time you opened the admin after updating. Nothing was renamed, moved or removed — the words you typed are still stored on each treatment as well, which is why an older version of the plugin still reads them correctly if you ever go back.

Why does a category need a picture?
For the pages that show your treatments and products on your own website: the category picture is the header of that category’s page and appears on the category chips. If you never use those pages it does no harm to leave it empty.

A record opened in WordPress shows only its title. Where have the panels gone?
They were being offered to a record type your copy no longer uses, and that is fixed in 2.693.0. When a copy takes names of its own, its records are renamed — but the panels the plugin adds to the WordPress editing screens were still asking for the original name, so WordPress never drew them. Nothing was lost; the panels simply were not there. The same fault meant anything typed into them was not saved either. Your Pet Central screens — the diary, the client list, the app — were never affected, which is why this went unnoticed for so long.

Do two copies each get their own staff app?
Yes, from 2.692.0. Before that they shared one app description served by whichever copy answered first, so the second copy’s app page offered an app that opened the first copy’s pages — and on a site with three copies, two of them had no app description at all. Each copy now has its own, with its own name, icon and starting page, and keeps its saved screens under its own name so nothing one copy stores can be read or overwritten by another.

Can both staff apps work offline at the same time?
No, and this one cannot be fixed on a single website. Working offline needs a background worker, and a browser allows one of those for the whole site — so whichever staff app was opened most recently is the one that keeps working without a signal. Both apps work normally when there is a connection. If offline matters for both trades, run the second copy on its own website (a subdomain is enough).

My customer app lost its offline page. Why?
The staff app was clearing it, and that is fixed in 2.692.0. When the staff app updated itself it tidied away old stored copies, and it was tidying away everything else the website had stored at the same time — including what the customer account app keeps. It only clears its own now. This affected anyone with both apps installed, whether or not they run two copies.

Why did my login screen show the logo more than once?
Because each copy was adding it. Fixed in 2.691.0: whichever copy loads first presents the login screen and the others stand down, so you get one logo and one set of colours however many copies are installed. Which copy that is makes no difference to what you see — they share the branding settings on a site running more than one.

A “(List)” link said “Invalid post type”. What was that?
A link that had not caught up with your records. On a copy running under its own names, links such as Bookings (List) still asked WordPress for the original name, and WordPress correctly said it had never heard of it. Nothing was wrong with your data — the links simply pointed at the wrong name. All of them were corrected in 2.691.0, and the build now refuses to ship a link that has this fault.