Title: ConferenceManager
Author: creativestrategy24
Published: <strong>07.06.2026</strong>
Last modified: 04.09.2026

---

ჩადგმების ძებნა

![](https://ps.w.org/conferencemanager/assets/banner-772x250.png?rev=3563718)

![](https://ps.w.org/conferencemanager/assets/icon-256x256.png?rev=3563718)

# ConferenceManager

 ავტორი: [creativestrategy24](https://profiles.wordpress.org/creativestrategy24/)

[ჩამოტვირთვა](https://downloads.wordpress.org/plugin/conferencemanager.1.6.15.zip)

 * [დეტალები](https://ka.wordpress.org/plugins/conferencemanager/#description)
 * [მიმოხილვა](https://ka.wordpress.org/plugins/conferencemanager/#reviews)
 *  [დაყენება](https://ka.wordpress.org/plugins/conferencemanager/#installation)
 * [დეველოპმენტი](https://ka.wordpress.org/plugins/conferencemanager/#developers)

 [მხარდაჭერა](https://wordpress.org/support/plugin/conferencemanager/)

## აღწერა

Conference Manager is a WordPress plugin designed for academic societies and conference
organizers. It provides end-to-end management of event registration, payments, and
document generation.

**Features:**

 * Member management (import/export via CSV/Excel)
 * Event and session management
 * Registration forms with group (team) registration support
 * Bank transfer payment tracking with reconciliation
 * Automatic invoice and receipt PDF generation
 * Participant list and My Page (participants sign in with a one-time code sent 
   by email)
 * AES-256-GCM encryption for personal data
 * Audit logging, rate limiting, and bot protection
 * Transactional email notifications (OTP, confirmations)
 * SNS share buttons (Twitter/X, Facebook, LINE)
 * Full Japanese / English localization

A separately distributed Pro edition (Conference Manager Pro) adds abstract submission
and peer review, sponsor management, bulk email and other features for larger conferences.
It is a different plugin and is not required: everything listed above works in full
here, with nothing locked or time-limited. See Conference > What’s New in the admin
menu for the full list.

### External Services

This plugin connects to the following external services.

#### IPAex Font Download (PDF generation)

To render Japanese text in PDF documents (invoice, receipt), the plugin needs the
open-source IPAex Gothic and IPAex Mincho fonts. From the admin Dashboard you can
install them with one click; the plugin then downloads the font files (one-time,
per font). No user data is transmitted — it is a file download only. If the server
cannot reach the download host, you can instead upload the `.ttf` files directly
from the Dashboard (no external connection required).

 * Download host (mirror maintained by the plugin author): [https://cs24.biz/conference/fonts/](https://cs24.biz/conference/fonts/)
 * Data sent: none (file download only)
 * The download URL can be overridden via the `conf_manager_font_source_url` filter.
 * Original font source / IPAex Font License (IPA, Information-technology Promotion
   Agency): [https://moji.or.jp/ipafont/license/](https://moji.or.jp/ipafont/license/)

### Development / Building from source

The admin and public interfaces are built with React (JSX). The human-readable
 
source for the compiled, minified bundles `build/admin-app.js` and build/public-
app.js is shipped inside this plugin under the `src/` directory:

 * `src/admin/` — source for `build/admin-app.js` (admin dashboard app)
 * `src/public/` — source for `build/public-app.js` (public registration / MyPage
   app)

Build toolchain: the project uses [@wordpress/scripts](https://www.npmjs.com/package/@wordpress/scripts)
(
a wrapper around webpack and Babel). The webpack configuration is included as webpack.
config.js, and all dependencies and build scripts are declared in package.json (
with `package-lock.json` for reproducible installs).

To rebuild the compiled assets from source:

 1. Install Node.js 18+ and npm.
 2. From the plugin directory, run `npm install`.
 3. Run `npm run build`. This regenerates `build/admin-app.js` and
     build/public-app.
    js (and their `*.asset.php` dependency manifests). Use `npm start` for an unminified
    development watch build.

Third-party libraries bundled into the compiled JavaScript (all open source,
 installed
from the public npm registry and declared in `package.json`):

 * `html5-qrcode` — QR code scanner used for participant check-in (Apache-2.0)

WordPress-provided packages (`wp-element`, `wp-components`, `wp-api-fetch`,
 wp-
i18n, `react`, `react-jsx-runtime`) are declared as externals and are NOT bundled—
they are loaded from WordPress core at runtime.

## ეკრანული სურათები

[⌊Dashboard — event overview and quick actions⌉⌊Dashboard — event overview and quick
actions⌉[

Dashboard — event overview and quick actions

[⌊Registration form — participant registration with group support⌉⌊Registration 
form — participant registration with group support⌉[

Registration form — participant registration with group support

[⌊Payment management — bank transfer reconciliation with invoice generation⌉⌊Payment
management — bank transfer reconciliation with invoice generation⌉[

Payment management — bank transfer reconciliation with invoice generation

## დაყენება

 1. Upload the plugin folder to `/wp-content/plugins/`.
 2. Activate the plugin through the “Plugins” menu in WordPress.
 3. Go to “Conference” in the admin menu to start configuring your event.

## ხდკ

### Does this plugin charge any fees?

No. The plugin itself is free and GPL-licensed, and nothing in it is locked, time-
limited or unlocked by payment. It takes no percentage of anything you collect.

### Is there a paid version?

The plugin author distributes a separate Pro edition with additional features for
larger conferences. It is a different plugin, sold and updated outside WordPress.
org, and it is not required to use this one. No part of it is included here, and
no feature of this plugin is withheld pending an upgrade. The Conference > What’s
New screen lists what is in this plugin and what the Pro edition adds.

### Does the plugin support Japanese?

Yes. The plugin is fully internationalized and includes Japanese translations. PDF
documents use IPA fonts for proper Japanese rendering.

### What are the server requirements?

WordPress 6.9 or later, PHP 8.4 or later, and MariaDB 10.5 or later (or MySQL 8.0
+).

### How is personal data protected?

Email addresses, phone numbers, and postal addresses are encrypted with AES-256-
GCM before they are written to the database.

For the strongest protection, define `CONF_MANAGER_ENCRYPTION_KEY` in `wp-config.
php` before activating the plugin (it must be at least 16 characters; a shorter 
value is ignored and the fallback below is used instead). The key then lives outside
the database, so a database-only compromise — an SQL injection, or a leaked backup—
does not expose the key along with the data it protects.

If that constant is not defined, the plugin generates a random key on first activation
and stores it in `wp_options`, so that encryption works without any setup. This 
is the default. Note that the key then resides in the same database as the data 
it encrypts.

Conference  Setup shows which of the two modes your site is using.

Important: do not add or change the encryption key once the plugin has stored data.
Decryption always uses the key currently in effect, so replacing it makes existing
encrypted data permanently unreadable.

## მიმოხილვები

There are no reviews for this plugin.

## მონაწილეები & დეველოპერები

“ConferenceManager” ღია პროგრამული უზრუნველყოფაა. შემდეგმა ადამიანებმა წვილი შეიტანეს
მის განვითარებაში.

მონაწილეები

 *   [ creativestrategy24 ](https://profiles.wordpress.org/creativestrategy24/)

“ConferenceManager” ითარგმნა 1 ენაზე. გმადლობთ [თარჯიმნებო](https://translate.wordpress.org/projects/wp-plugins/conferencemanager/contributors)
თქვენი წვლილისათვის.

[გადათარგმნეთ ConferenceManager თქვენს ენაზე.](https://translate.wordpress.org/projects/wp-plugins/conferencemanager)

### დაინტერესებული ხართ დეველოპმენტით?

[დაათვალიერეთ კოდი](https://plugins.trac.wordpress.org/browser/conferencemanager/),
შეამოწმეთ [SVN რეპო](https://plugins.svn.wordpress.org/conferencemanager/), ან გამოიწერეთ
[შექმნის ჟურნალი](https://plugins.trac.wordpress.org/log/conferencemanager/) : [RSS](https://plugins.trac.wordpress.org/log/conferencemanager/?limit=100&mode=stop_on_copy&format=rss).

## ცვლილებები

#### 1.6.15

 * Fixed: clearing a date on an event did not clear it. The registration deadline,
   the registration opening date and the two submission dates could be emptied on
   screen and saved without complaint, but what reached the database was an unusable
   date rather than an empty one. For the registration deadline this closed registration
   for that event: an event whose deadline had been cleared — which reads as “no
   deadline, keep it open” — reported its registration as closed instead. Clearing
   a date now clears it. Clearing the start or end date, which an event cannot be
   without, is refused with “Start date and end date are required.” rather than 
   saved.
 * Fixed: a date that does not exist was accepted. On an event or a session, 2026-
   02-30 and 2026-13-45 alike were stored as a zero date — the value the plugin 
   reads as “this event has no usable date” — and the event could then not be registered
   for, with nothing on screen to say why. On a settlement, the same date was stored
   as 2 March instead of being refused. The admin screens will not let you type 
   such a date, so this arrived through the REST API or a client that does not check
   it. The same check now covers the seven event dates, the two session dates and
   the date on a settlement.
 * Fixed: opening an event whose stored date could not be shown sent that date back
   unchanged when you saved. The date field appeared empty, because a browser will
   not display a date it cannot make sense of, but the value was still there and
   went back with the rest of the form — so an event edited for its title alone 
   was refused over a date the screen was not showing. Such a date is now left out
   of the form: the field is genuinely empty, and saving the event replaces the 
   unusable date with none at all.

#### 1.6.14

 * Added: My Page now separates the events you are registered for from the ones 
   that have already taken place. Until now every registration sat in one list in
   the order you signed up, so a member with a few years of history had to scroll
   past finished events to reach the one coming up. Upcoming events are listed first,
   soonest first; past events follow, most recent first, ten to a page. Which list
   an event falls into is decided from the event end date on your site’s clock, 
   so everyone sees the same split wherever they are reading from. Cancelled registrations
   stay in the history, still marked as cancelled, because that is often exactly
   what someone is looking for when they contact you.
 * Added: the event list in the admin now moves events that have finished below 
   the ones that have not, and marks them “Ended”. The list was ordered by start
   date alone, so a long event still running sat below shorter events that were 
   already over. The marker is there because the date column shows the start date
   while the order follows the end date, which otherwise reads as a list sorted 
   wrongly.
 * Fixed: the payment date shown in the participant list was the date you confirmed
   the payment rather than the date the money arrived. Confirming a payment recorded
   the bank statement date against the payment but not against the registration,
   so the two disagreed. Invoices and receipts read the payment record and were 
   always correct — the wrong date appeared only on screen, in the participant list
   and in the date the payment dialog opened with.
 * Fixed: the date on a settlement — a refund or an additional charge — could be
   replaced without telling you. A date the plugin could not read at all became 
   the current time, and a date written in another order, 08/20/2026 for example,
   was stored as a zero date, which then sorted to the top of the settlement history.
   Both are now refused with a message, and a date that can be read is stored as
   written.
 * Fixed: the transfer date on a payment confirmation was stored as a zero date 
   whenever it could not be read, with nothing on screen to say so. It is now refused
   unless it is a real calendar date written as YYYY-MM-DD, which is the rule the
   payment date beside it has always followed.
 * Fixed: a payment date that looks like a date but is not one was accepted. 2026-
   13-45 was recorded as 1 January 1970, and 2026-02-30 was recorded as 1 March.
   Dates that do not exist are now refused instead of being turned into a different
   day.
 * Changed: the payment date field now says that leaving it empty records the current
   date and time. The field arrives filled with today’s date, so this applies only
   when you clear it — but the behaviour was not written down anywhere.

#### 1.6.13

 * Added: on-site registration after the advance deadline. Until now the plugin 
   told people that advance registration had closed and to contact the organiser,
   but offered no way to register — anyone who signed up after the deadline arrived
   at the venue with no registration at all. Turn on “Accept on-site registration”
   for an event and visitors can still register from the public form once the deadline
   has passed. They are charged the on-site rate, the payment is recorded as cash
   received at the reception desk rather than a bank transfer, and their confirmation
   email tells them to pay at the desk instead of carrying bank details for money
   that will never arrive. The participant list marks these registrations so you
   can tell them apart, and marking one as paid produces a receipt in the usual 
   way. The setting is off by default, so updating changes nothing until you turn
   it on for an event, and registration stops on its own once the event end date
   has passed.
 * Fixed: registrations submitted after the registration deadline were accepted.
   The deadline was stored and indexed but never read, so the public form let people
   complete a registration for an event that had closed — and the same was true 
   for events whose registration had not opened yet, and for events that had already
   finished. These are now refused, and the event stays in the list showing why 
   instead of disappearing, so that people can still see the dates and the on-site
   arrangements. Sites that never set a deadline are unaffected: an empty deadline
   still means registration stays open.
 * Fixed: the switch from advance to on-site pricing happened at the wrong time 
   on sites outside UTC. The deadline you type is a wall-clock time on your site,
   but it was compared against UTC, so in Japan the advance price stayed available
   for nine hours after the deadline had passed. It now follows the timezone set
   in WordPress, which is what Setup has always said it would do. Sites on UTC were
   never affected.
 * Fixed: the registration confirmation email kept advertising the advance deadline
   for the same nine hours after it had passed, so the price charged and the price
   described in the email disagreed. The email now stops mentioning the deadline
   once it has passed.
 * Fixed: the event date printed on an invoice could be a day late. The date you
   type is a wall-clock time, but it was read as UTC and converted again for display,
   so on a site set to Japan an event starting at or after 15:00 was printed as 
   the following day. On sites west of UTC an early-morning start was printed as
   the previous day. Sites on UTC were never affected. The payment date and the 
   issue date on the same documents were always correct and are unchanged.

#### 1.6.12

 * Fixed: on a site installed in a subdirectory, links between the plugin’s own 
   pages led nowhere. The link from My Page to the registration page, and the link
   to your terms of service, were written from the root of the domain, so a site
   at example.com/conference/ sent people to example.com/c-registration/ — outside
   the installation, where that page does not exist. Links inside emails were never
   affected, which is why the fault could go unnoticed. The plugin now asks WordPress
   for the real address of each page, so the links also follow a page that has been
   renamed, moved under another page, or a site using plain permalinks.
 * Fixed: Setup could report that the registration page was missing when it was 
   there and working. The check looked only for the shortcode written without any
   settings, so a page holding [conf_manager view=”registration”] was not recognised,
   and the screen advised creating another page — leaving some sites with two registration
   pages. The check now recognises the same forms of the shortcode that the pages
   themselves accept. If you were advised to create a second page and did so, you
   can delete the one you do not use: the plugin always links to whichever page 
   was created first, so the second one is never linked to from anywhere in the 
   plugin, and only the people you send to its address by hand ever see it.
 * Fixed: when two published pages carried the My Page shortcode, the address used
   in emails was left to the database to pick, with nothing tying it to the page
   the rest of the plugin links to. The same page is now chosen every time, and 
   it is the one the rest of the plugin links to.

#### 1.6.11

 * Added: the payment confirmation email now says who it is from. It used to open
   with “your payment has been confirmed” and nothing else, so the participant had
   only the sender address to go by. The email now opens with the organiser’s name,
   taken from a new field under Conference  Setup  notification settings. Leaving
   that field empty uses your site name, so the sentence appears without any setup;
   if the site has no name either, the sentence is left out rather than sent half-
   written.
 * Added: when the amount received differs from the amount billed, the payment confirmation
   email says so. It listed the two amounts and left the reader to compare them.
   It now adds one line under the amount received — the refund due when too much
   was received, the shortfall when too little was. A shortfall also carries the
   bank details for the event, because this plugin has no separate reminder email:
   without them the participant would be told that money is missing without being
   told where to send it. Nothing is added when the amount received matches the 
   amount billed, and a payment that has already been refunded in full is not treated
   as a difference.
 * Fixed: your site name could reach participants with its punctuation written as
   HTML. WordPress stores the site name with characters such as & and ‘ already 
   escaped, and the plugin passed that stored value straight into plain-text email,
   so a society named “Yamada & O’Brien” appeared as “Yamada & O'Brien” in the sender
   name, the reply-to name, the body of every automated email and the passkey registration
   prompt. The name is now restored to the way it was typed before it is used anywhere
   outside HTML.
 * Fixed: a site name containing a comma lost part of the reply-to name. The reply-
   to header was assembled as text, and WordPress splits that header on commas before
   reading it, so “Yamada, Inc.” arrived as “Inc.” — quoting it made no difference.
   The name and the address are now handed over separately, and the whole name arrives.
   The reply-to address itself was never affected.

#### 1.6.10

 * Changed: if the option that holds the encryption key is damaged — holding something
   other than text — the plugin now stops with an explanation instead of a PHP type
   error. Earlier versions stopped as well, but with a message that said nothing
   about the cause or the way back. The new message names the option, says that 
   WP-CLI and the admin screens cannot load while the site is in that state (so 
   the usual way of correcting an option does not work), and gives the fastest way
   back: adding the key to wp-config.php as CONF_MANAGER_ENCRYPTION_KEY. Restoring
   the option from a database backup is given as the alternative. It also says not
   to delete the option, because a missing row makes the plugin generate a new key,
   and anything encrypted with the old one can never be read again.
 * Note: the rule for choosing the encryption key now lives in one place. The plugin
   and its activation step each kept their own copy of the same three steps — the
   constant in wp-config.php, then the stored option, then generating a new key —
   and a change to one copy could have made the two disagree about which key to 
   use. The rule itself is unchanged: the same key is chosen in every case as before,
   nothing is re-encrypted, and no stored data is touched.

#### 1.6.9

 * Fixed: the registration form showed a fee of ¥0 for a category and participation
   type the event does not offer. Leaving a cell in the fee table empty means that
   combination is not accepted, and the server has refused it since 1.6.x, but the
   form still read an empty cell as free — so it showed ¥0, and a total of ¥0, and
   only said no after the registration was sent. The form now says the combination
   is not offered, and while it is showing that, no total is shown at all and the
   registration cannot be sent. An event with no fee table at all is still free,
   and a category priced at zero on purpose is still free; both are unchanged.
 * Fixed: in English the number of staff on a group registration was printed with
   the label of the given-name field after it, so a group of one read “Staff (1First
   Name)”. The counter and the name field shared one translation entry, which reads
   correctly in Japanese and wrongly in every other language. They are now separate.

#### 1.6.8

 * Fixed: a group registration quietly left out any staff member the event could
   not accept. When the fee table had no price set for someone’s participation type,
   that person was dropped while the rest of the group went through, so the registration
   was confirmed and numbered for fewer people than had been entered, and the amount
   matched the smaller number. Nothing on screen said anyone had been left out, 
   and the people who were dropped had no registration at all. A group is now checked
   in full before anything is created: if one person cannot be accepted, the whole
   registration is refused and nothing is recorded, so it can be corrected and sent
   again.
 * Fixed: on the group registration form the participation type could keep a value
   the event does not offer. The menu showed only what the event offers, but the
   value behind it stayed on the one chosen by default, which made the fee preview
   read as free and the registration refused on sending — with nothing on the form
   that could be changed to fix it. The form now falls back to a participation type
   the event offers, both for the representative and for each staff member, and 
   follows changes to the fee category.

#### 1.6.7

 * Fixed: cancelling a registration left its invoice sitting in the unpaid figures.
   Every place that counts unpaid money looks for payments marked unpaid, and cancelling
   a registration only changed the registration, so the invoice behind it stayed
   unpaid for good — it kept its place in the per-event totals, in the unpaid filter
   on the payments screen, and in the unpaid count and total on the dashboard, which
   counts every event at once. Cancelling now withdraws the unpaid invoice with 
   it, and restoring the registration brings the invoice back. Invoices left behind
   by earlier versions are withdrawn when this version is installed.
 * Note: a payment that has already been received is never touched by cancelling
   a registration. Money that has changed hands does not come back on its own, and
   recording it as a refund would put a refund that never happened on the books.
   The cancellation says so before you confirm it, and the payment is written to
   the audit log so it can be settled deliberately.
 * Fixed: the invoice button on the payments screen appeared for every payment regardless
   of its state, and the server did not check either, so an invoice could be issued—
   and numbered — for a payment that should never have had one. Both the button 
   and the server now go by the same list of states.
 * Added: cancelling an event now asks what to do with the registrations behind 
   it. Until this version cancelling an event left every registration and invoice
   untouched, so the money owed for an event that was no longer happening stayed
   in the unpaid figures. Cancelling now counts the registrations first and shows
   the number, and nothing is chosen for you — the event can be cancelled on its
   own, or together with its registrations. Registrations already marked as attended
   are counted separately and are never cancelled, and payments already received
   are never touched. The registrations taken with the event are written to the 
   audit log, since they are restored one at a time.

#### 1.6.6

 * Fixed: on invoices and receipts the name was printed above the organisation, 
   which left the honorific attached to the organisation rather than to the person—“
   University of X, School of Y 様” instead of “University of X, School of Y” on
   one line and “Taro Yamada 様” on the next. An honorific belongs to the person,
   and putting one on an organisation also reads oddly next to the form used for
   addressing an organisation as a whole. The organisation now comes first and the
   honorific follows the name. Documents are drawn when they are asked for rather
   than stored, so invoices and receipts issued before this version read the new
   way as well; their numbers are unchanged, so nothing is re-issued.

#### 1.6.5

 * Fixed: the settlement dialog opened with “Refunded the participant” already chosen
   and the difference already filled in, so a refund could be recorded by opening
   the dialog and pressing the button, even when no money had changed hands. On 
   one site this left four refunds of the same amount on a single payment, and the
   list then asked for an amount to be collected that had never been overpaid. The
   dialog now opens with nothing chosen, and no amount field, method or confirm 
   button appears until you say what the settlement is for. The purposes are grouped
   into ones where money moved and ones that only correct the record.
 * Added: a settlement entered by mistake can now be cancelled. Until this version
   nothing in the plugin could remove one, so a wrong entry stayed on the payment
   for good and kept distorting the amount shown as received. Cancelling removes
   it from the history and from every total, keeps the row in the database, and 
   writes all of its details to the audit log. A refund that also cancelled the 
   registration cannot be cancelled this way, because the registration and the payment
   status went with it.
 * Fixed: changing the purpose in the settlement dialog left the previous amount
   in the field. The field means the difference for a refund but the corrected total
   when correcting the record, so a difference of ¥1,000 could be submitted as a
   paid amount of ¥1,000 and overwrite what had actually been received. The amount
   is now replaced whenever the purpose changes, the correction shows what is currently
   recorded next to the field, and it asks for confirmation before overwriting.
 * Fixed: the difference column was coloured by the sign of the number, which made
   it the opposite colour to the status beside it — a payment marked “Refund due”
   in red showed its difference in amber. The four places that show a difference
   now take their colour from the same table as the status, and the column explains
   in words which way the difference goes.

#### 1.6.4

 * Fixed: if the record of when audit-log trimming was first set up went missing,
   the plugin treated the waiting period as already over and would have trimmed 
   on its next nightly run instead of waiting. It now starts the waiting period 
   again, so a missing record can never bring the trimming forward. In normal use
   the record is written when the plugin loads, so this was unlikely to be reached,
   but the outcome if it had been was immediate.

#### 1.6.3

 * Trimming of the audit log now waits two weeks before it starts, and says so on
   this plugin’s screens while it waits. Version 1.6.2 began trimming as soon as
   it was installed, which on a site that updates automatically meant there was 
   no moment at which anyone could object first. Nothing had been removed yet on
   any site, because the plugin has only been available since June. If you need 
   the records kept for longer, change the retention with a filter before the date
   shown in the notice.
 * The nightly trimming now works through more rows in one night, so a site with
   a long history catches up in days rather than months. Each individual statement
   is still bounded, which is what keeps it from holding a large transaction open.

#### 1.6.2

 * The audit log is now trimmed automatically. Until this version nothing ever removed
   entries from it, so on a site that had been running for a while it simply kept
   growing. Ordinary activity is kept for a year; entries that record sign-in attempts,
   rate limiting and blocked bots are kept for three years, because those are the
   ones you would need if you ever had to look into unauthorised access. Both periods
   can be changed with a filter.
 * The IP address and browser recorded alongside ordinary activity are now cleared
   after 90 days, while the entry itself is kept. Who did what, and when, is still
   recorded; only the personal details are dropped. Entries kept as a security record
   are left untouched, since removing the address would defeat the purpose of keeping
   them.
 * The trimming runs once a day and works through a bounded number of rows at a 
   time, so that the first run on a site with years of history cannot time out.

#### 1.6.1

 * The event editor now tells you, while you are still editing, when a fee category
   has been left in the table with no price for either participation type. Nobody
   can register under such a category, and until now the only warning came from 
   a notice after the event was already published. Categories you have removed from
   the table with the × button are not reported, since those are deliberately not
   offered.

#### 1.6.0

 * Added: member types can be shown with your society’s short name in front of them,
   for example “JXX Society_Regular Member”. Enter the name under Setup. At co-hosted
   events an attendee who belongs to a different society reads “Regular Member” 
   as their own and registers under it; naming the society makes it clear whose 
   category it is. Leave the field blank and member types are shown exactly as before.
   Only the display changes — nothing already recorded is altered, so registrations
   taken before and after the setting read the same way.
 * Added: the fee category is now shown on My Page under the registration’s participation
   type, and on invoices and receipts under the event name. Until now a participant
   had no way to see which category they had been registered under.
 * Fixed: the approval status in the member list looked like a link and was being
   clicked. It was set in the same colour WordPress uses for links, and because 
   the whole row opens the member for editing, anyone trying to act on the approval
   landed in the edit dialog instead. Approval is now shown as a plain badge, each
   row carries an Edit button, and the list says whether administrator approval 
   is on. Clicking the row still opens the member, as before.
 * Fixed: the event list had a “Publish” button sitting in the status column, which
   made the status itself look like something you could press to change. The four
   states are now badges, and Publish has moved to the actions at the end of the
   row alongside Edit. Clicking the row still opens the event.
 * On narrow screens the buttons in both lists are now tall enough to press with
   a finger, and the buttons on the participant list are arranged over two rows 
   so the invoice and receipt buttons no longer sit off the right-hand edge.
 * The payment export used its own list of member type names, written in Japanese,
   so the same category could read differently there than elsewhere and non-Japanese
   sites were given Japanese words. It now uses the same names as the rest of the
   plugin.
 * The same idea is now called “fee category” throughout in Japanese; the participant
   list previously used a different word for it than the documents did.

#### Earlier versions

 * Changelog entries for 1.5.1 and earlier have been removed to keep this section
   within the length WordPress.org accepts. They remain in the plugin’s version 
   control history.

## მეტა

 *  Version **1.6.15**
 *  Last updated **4 საათის წინ**
 *  Active installations **10-ზე ნაკლები**
 *  WordPress version ** 6.9, ან უფრო მაღალი **
 *  Tested up to **7.1**
 *  PHP version ** 8.4, ან უფრო მაღალი **
 *  Languages
 * [English (US)](https://wordpress.org/plugins/conferencemanager/) და [Japanese](https://ja.wordpress.org/plugins/conferencemanager/).
 *  [თარგმნეთ თქვენს ენაზე](https://translate.wordpress.org/projects/wp-plugins/conferencemanager)
 * Tags
 * [academic](https://ka.wordpress.org/plugins/tags/academic/)[Conference](https://ka.wordpress.org/plugins/tags/conference/)
   [Event](https://ka.wordpress.org/plugins/tags/event/)[payment](https://ka.wordpress.org/plugins/tags/payment/)
   [registration](https://ka.wordpress.org/plugins/tags/registration/)
 *  [დამატებითი ხედი](https://ka.wordpress.org/plugins/conferencemanager/advanced/)

## რეიტინგები

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/conferencemanager/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/conferencemanager/reviews/)

## მონაწილეები

 *   [ creativestrategy24 ](https://profiles.wordpress.org/creativestrategy24/)

## მხარდაჭერა

გაქვთ კომენტარი? გჭირდებათ დახმარება?

 [მხარდაჭერის ფორუმის ნახვა](https://wordpress.org/support/plugin/conferencemanager/)