ConferenceManager

Registre de canvis

1.6.18

A security fix for sites where people other than administrators edit events, a fix for the Word template used for abstract submissions, and wider admin screens. No database changes and no action is needed after updating.

• Security: a user who can edit events but is not an administrator, such as a user with the Conference Editor role, could delete any file on the server that the web server is allowed to delete, including wp-config.php. The location of an event’s Word template was accepted from the request that saves the event, so it could be pointed at another file through the REST API, and deleting the template then deleted that file. The location is now set only by uploading a template, and saving or creating an event can no longer change it. Deleting a template now removes a file only if it is inside that event’s own template folder (conf-manager/templates/ and the event ID, in the uploads folder). If an event already points somewhere else, deleting its template clears the setting and leaves the file where it is.
• Fixed: saving an event removed its Word template. After a template had been uploaded in the event edit window, saving the event cleared it from the event, and the «Current template:» line was gone the next time the event was opened. Saving now keeps the template, and settings this window does not show, such as those kept from the Pro version, are kept as well. An event that has already lost its template needs it uploaded again: the file uploaded earlier is not reattached and stays in the uploads folder.
• Changed: the plugin’s admin screens now use the full width of the window. They were limited to 1200 pixels, which left a wide empty area on the right of a large screen; there is now a 26-pixel margin on the right. The What’s New page and screens narrower than 782 pixels are unchanged. Panels such as the status cards on the dashboard now stretch further on a wide screen; their layout itself was not changed.

1.6.17

Security and admin readability. No database changes and no action is needed after updating.

• Verification codes: a wrong code no longer counts against everyone sharing your internet connection. Until now the limit on wrong codes was counted per IP address, so on a venue’s shared Wi-Fi the mistyped codes of other people were added to yours, and once the total was reached nobody on that connection could sign in for ten minutes even with a correct code. Wrong codes are now counted per connection and address together, so a mistake made by someone else no longer affects you.
• Verification codes: a separate, wider limit per connection is kept so that someone trying many different addresses from one connection is still stopped.
• WordPress login: the lockout after repeated failed logins is now counted per user name as well as per IP address. Until now a bot repeatedly trying one name locked out every administrator behind the same address.
• Admin colours: nine colours in the admin stylesheet were changed so that a state badge is never the same colour as a button next to it, and so that white text on a coloured badge meets the AA contrast ratio. The badges are «Attended», «Published», «Refund due», «Surcharge due», «On-site» and «Pro», plus the «Updated» flag on the What’s New page; the other two are the hover states of the delete and action buttons. Only the stylesheet was changed: the text colours written inside the payments screen itself are unchanged, so the amounts shown there keep the colours they had.
• Internal: a limit on the total number of verification attempts per address, which could never be reached because it was cleared whenever a code was resent, was removed. The same protection is provided by the per connection and address limit above.

1.6.16

• Fixed: staff on a group registration could not open My Page. A staff member received a verification code and could enter it correctly, but was then told «Authentication token is invalid or expired.» every time. Staff now see a simple page listing the registration they take part in; invoices, receipts and payments stay with the representative who made the group registration.
• Fixed: a correct verification code was refused when it was not typed as exactly six half-width digits. On My Page, pasting the code with a space in front of it or a hyphen in the middle left five digits and a button that could not be pressed, and full-width digits or the whole line «Verification code: 123456» pasted from the email left the field empty. The server, for its part, rejected a correct code that arrived with full-width digits, a full-width space or a separator, and counted it as one of the five attempts. The code field on My Page and in self-registration and the server now read all of these as the six digits, and input that cannot be a code is refused without using up an attempt.
• Fixed: pressing Enter in the code field sent an incomplete code. The Log In button stays disabled until six digits are entered, but Enter sent five digits anyway, which was refused as incorrect and used up one of the five attempts. Enter now sends only a complete code.
• Fixed: people on a shared connection, such as a university, an office or the venue Wi-Fi, could be locked out while entering a correct code. Every code entry counted toward a limit of ten per five minutes per connection, shared with failed WordPress logins, so from the eleventh entry everyone on that connection was refused for ten minutes, correct code or not. Only wrong codes are now counted, the limit is 30 per five minutes, and it is no longer shared with WordPress logins. The limit on sending codes from one connection has been raised from 50 to 300 an hour.
• Fixed: the lockout after repeated failed WordPress logins did not stop anyone logging in. During the ten-minute lockout the correct password still logged in, and a wrong one received the ordinary error instead of being refused. Logins from a locked-out connection are now refused until the lockout ends.
• Added: the code email and the code entry screen now say that requesting a new code makes the earlier one unusable. Each new code replaces the previous one, and nothing said so, so a code from an earlier email was refused as incorrect.
• Changed: when sending codes is paused, the message now says what to do. If the pause is for your email address, after more than five codes in an hour, it says when sending will resume and to use the code from the most recent email. If it is for the connection, it suggests turning off Wi-Fi and using mobile data.
• Added: failed code entries are recorded in the plugin’s audit log with the reason (wrong, expired, too many attempts or not a code), but never the code or the email address. Sending a code and logging in with one are recorded too.

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.

Earlier versions

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