When creating a message for an event, rename the "To" option "Event participants" to "Attendees". Whereas previously this option's recipients included those who had selected a prepaid ticket, but hadn't completed payment, it now excludes them. The recipients of this message now match that of the people listed as "Attendees" for your event.
Send community related emails (e.g. the confirmation email a participant receives when registering for an event) from the email address "firstname.lastname@example.org", instead of an individualized community address.
Show a warning when viewing the payment page of a ticket that is not associated with your Doorkeeper account. When prepaying for a ticket that is associated with another Doorkeeper account, require credit card information to be re-entered, rather than allowing payment via a saved credit card.
Improvements to event registration email for online events.
Remove link from public user profile to Facebook account profile. In July of 2018, Facebook changed the behavior of the profile link that they share with us when someone logs into Doorkeeper via a Facebook account. Since this change, the link no longer behaves in a consistent manner, and often will appear to be broken. As this change has been causing confusion, we decided to remove this link from Doorkeeper entirely.
Display event listing on community pages in a consistent manner with other event listings throughout the Doorkeeper site.
Fixed bug with the payments report. In the case of refunded payments, the calculation of the amount the organizer receives wasn't being performed properly for this report.
Added venue to back of Apple Wallet ticket.
Revised how the public event page shows multiple ticket types. We now show if a given ticket type has a waitlist.
When you reply to an email about an inquiry to your community, the reply will be forwarded to the person who submitted the inquiry. Note that we cannot guarantee that we can extract the content of your reply perfectly, so we still recommend using the web interface to reply.
When selecting the recipients for an event specific message, replaced the option of "With unpaid tickets" with "Awaiting payment".
The new option of "Awaiting payment" will send to all the participants who haven't paid yet but are required to do so. This is the same as is shown in the "Awaiting payment" section of the participants list.
The previous option of "With unpaid tickets" included everyone who hadn't prepaid for your event, including participants with free or at the door tickets, which didn't match how organizers wanted to use it (for sending a reminder to people who needed to complete payment).
prefecture parameter to the events API.
Setting a password for your community is now part of the Pro plan. If you have an existing community with a password and are on the Starter plan, you can continue to use this feature with no changes to your subscription.
If multiple attempts to email a given address are returned as undeliverable by that email address's server, we stop sending email to it. This is considered to be a best practice, and if we were to continue to email addresses like this, it increases the chances that all mail Doorkeeper sends is marked as spam.
Previously, we showed a warning about this after login. However, as it was possible to miss this, and Doorkeeper being able to deliver emails is critical for it to function properly, we're now showing the warning everywhere.
Furthermore, previously, after the recipient had resolved the issue with their email server, they would need to contact Doorkeeper customer support to have us send emails once more. We now provide an automated mechanism for resuming email sending.
Added a shortcut for creating an event within a specific community in the menu bar.
From your Email Notifications page, you can now unsubscribe from emails sent when someone in one of your communities makes a comment.
After a new comment is created, wait two minutes before sending out notifications to event participants. We've noticed that sometimes people will post a comment and then immediately delete it (for instance, if they made a mistake in it). Delaying these notifications will allow time for this. Notifications to community administrators still go out immediately.
Automatically close commenting on events that have ended more than three months ago. We think the chance that a legitimate comment will be posted this late is quite unlikely, so we're proactively closing the comments to avoid spam.
Refreshed design of the venue listing page.
Improvement to community inquiries created from emails (e.g., when a participant replies to their ticket email, we forward the content to the organizers). Extraneous text removed from forwarded reply emails. If contents of email cannot be extracted, automatically reply to sender of email telling them this, and asking to use contact form instead. Email triggering the inquiry is no longer attached.
When creating or editing a ticket type, added an option "End of event" for "Prepayment closes" and "Registration closes".
Updated registration widget to set "style" attribute of widget iframe to be 300px (or value specified via data-width), to ensure that it displays with the correct width, regardless of the css of the page it is embedded in.
Within the community administration, improved the design of registration and member pages.
Require users to be logged into a Doorkeeper account with a verified email address to use the contact the organizer form. Introduced to combat an increase in contact form spam.
reCAPTCHA v2, which we were previously using, appears to have been beaten by spammers, and so is no longer an effective method. We've investigated reCAPTCHA v3, but as it tracks all your actions across the site and sends them to a third-party (Google), we're concerned about the privacy implications, and so have decided against implementing it at this time.
Require users to be logged into a Doorkeeper account with a verified email address to comment on an event. This is just a preventive measure to prevent spam comments, as we haven't had any spam comments since introducing this feature. However, because notifications about new comments are sent to participants, we're extra paranoid about preventing spam. In most cases, email addresses are automatically verified, so most users shouldn't notice this change.
When displaying the name reading (furigana) of a participant, use
div tags with css, instead of
ruby tags. Recent versions of Safari have a bug where
ruby tags cause the webpage rendering to break under specific circumstances.
Improve display of "printable" pages: the guest list, receipts for tickets, tickets themselves, and receipts for a Doorkeeper subscription.
Prevent deletion of events with registrations. These events can still be published, and if all tickets are cancelled, the event can still be deleted.
Published our interview with Koichiro Nishijima (article in Japanese), a core member of JAWS-UG Okinawa.
Filter topic event listings by prefecture (e.g., Business events in Tokyo).
Improve display of tickets that have been added as Apple Wallet passes.
Tweak the design of page for choosing which community to hold a new event in.
When viewing event listings on mobile, show a single header for all events starting on a given date, rather than repeating the start date for each event.
Redesigned the event and community listings (such as your recommended events) to declutter the page, quickly provide you with the relevant information, and look better on mobile.
Introduce a page that lists all of your calendar feeds.
Improve performance of event participant export.