npm start<\/code> for an unminified development watch build.<\/li>\n<\/ol>\n\nThird-party libraries bundled into the compiled JavaScript (all open source,\ninstalled from the public npm registry and declared in package.json<\/code>):<\/p>\n\n\nhtml5-qrcode<\/code> \u2014 QR code scanner used for participant check-in (Apache-2.0)<\/li>\n<\/ul>\n\nWordPress-provided packages (wp-element<\/code>, wp-components<\/code>, wp-api-fetch<\/code>,\n wp-i18n, react<\/code>, react-jsx-runtime<\/code>) are declared as externals and are NOT\nbundled \u2014 they are loaded from WordPress core at runtime.<\/p>\n\n\n\n- Upload the plugin folder to
\/wp-content\/plugins\/<\/code>.<\/li>\n- Activate the plugin through the \"Plugins\" menu in WordPress.<\/li>\n
- Go to \"Conference\" in the admin menu to start configuring your event.<\/li>\n<\/ol>\n\n\n
\nDoes this plugin charge any fees?<\/h3><\/dt>\nNo. 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.<\/p><\/dd>\n
Is there a paid version?<\/h3><\/dt>\nThe 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.<\/p><\/dd>\n
Does the plugin support Japanese?<\/h3><\/dt>\nYes. The plugin is fully internationalized and includes Japanese translations. PDF documents use IPA fonts for proper Japanese rendering.<\/p><\/dd>\n
What are the server requirements?<\/h3><\/dt>\nWordPress 6.9 or later, PHP 8.4 or later, and MariaDB 10.5 or later (or MySQL 8.0+).<\/p><\/dd>\n
How is personal data protected?<\/h3><\/dt>\nEmail addresses, phone numbers, and postal addresses are encrypted with AES-256-GCM before they are written to the database.<\/p>\n\n
For the strongest protection, define CONF_MANAGER_ENCRYPTION_KEY<\/code> in wp-config.php<\/code> 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 \u2014 an SQL injection, or a leaked backup \u2014 does not expose the key along with the data it protects.<\/p>\n\nIf that constant is not defined, the plugin generates a random key on first activation and stores it in wp_options<\/code>, 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.<\/p>\n\nConference \u2192 Setup shows which of the two modes your site is using.<\/p>\n\n
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.<\/p><\/dd>\n\n<\/dl>\n\n\n
1.6.13<\/h4>\n\n\n- 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 \u2014 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.<\/li>\n
- 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 \u2014 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.6.12<\/h4>\n\n\n- 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\/ \u2014 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.<\/li>\n
- 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 \u2014 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.6.11<\/h4>\n\n\n- 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 \u2192 Setup \u2192 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.<\/li>\n
- 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 \u2014 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.<\/li>\n
- 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.<\/li>\n
- 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.\" \u2014 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.<\/li>\n<\/ul>\n\n
1.6.10<\/h4>\n\n\n- Changed: if the option that holds the encryption key is damaged \u2014 holding something other than text \u2014 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.<\/li>\n
- 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 \u2014 the constant in wp-config.php, then the stored option, then generating a new key \u2014 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.<\/li>\n<\/ul>\n\n
1.6.9<\/h4>\n\n\n- Fixed: the registration form showed a fee of \u00a50 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 \u2014 so it showed \u00a50, and a total of \u00a50, 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.6.8<\/h4>\n\n\n- 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.<\/li>\n
- 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 \u2014 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.<\/li>\n<\/ul>\n\n
1.6.7<\/h4>\n\n\n- 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 \u2014 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.<\/li>\n
- 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.<\/li>\n
- 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 \u2014 and numbered \u2014 for a payment that should never have had one. Both the button and the server now go by the same list of states.<\/li>\n
- 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 \u2014 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.<\/li>\n<\/ul>\n\n
1.6.6<\/h4>\n\n\n- 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 \u2014 \"University of X, School of Y \u69d8\" instead of \"University of X, School of Y\" on one line and \"Taro Yamada \u69d8\" 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.<\/li>\n<\/ul>\n\n
1.6.5<\/h4>\n\n\n- 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.<\/li>\n
- 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.<\/li>\n
- 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 \u00a51,000 could be submitted as a paid amount of \u00a51,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.<\/li>\n
- Fixed: the difference column was coloured by the sign of the number, which made it the opposite colour to the status beside it \u2014 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.<\/li>\n<\/ul>\n\n
1.6.4<\/h4>\n\n\n- 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.<\/li>\n<\/ul>\n\n
1.6.3<\/h4>\n\n\n- 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.6.2<\/h4>\n\n\n- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.6.1<\/h4>\n\n\n- 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 \u00d7 button are not reported, since those are deliberately not offered.<\/li>\n<\/ul>\n\n
1.6.0<\/h4>\n\n\n- 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 \u2014 nothing already recorded is altered, so registrations taken before and after the setting read the same way.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n
- 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.<\/li>\n<\/ul>\n\n
1.5.1<\/h4>\n\n\n- Fixed: the notice listing events with a category that has no price set could not be dismissed. It had a button, but pressing it did nothing, so the notice stayed on every admin screen until every event was edited.<\/li>\n
- Fixed: that notice missed events where a category was left in the table with both its prices cleared. Such a category cannot be registered under, exactly as if the row had been removed, but the notice only looked for missing rows.<\/li>\n
- The notice now checks every published event instead of stopping partway, so an event further down the list is no longer missed and reported as nothing to fix. It is shown on this plugin's screens only, rather than on every admin page.<\/li>\n
- Fixed: staff could no longer be added to an existing group registration under a fee category that has no price set for it. The record kept for 1.5.0 covered individual registrations only, and group staff are held separately, so those combinations were missed. They are recorded when this version is activated, exactly as individual registrations were.<\/li>\n<\/ul>\n\n
1.5.0<\/h4>\n\n\n- Security: invoices and receipts are no longer written to a public folder. They were saved under wp-content\/uploads with sequential file names such as INV-202608-00001.pdf, and My Page linked straight to them, so anyone who guessed a number could read a document carrying a participant's name, organisation and the amount they paid. Documents are now drawn when they are asked for and delivered through a check that the person asking is the one they belong to. Files already written are removed when this version is activated; nothing is lost, as the documents are rebuilt from your records. Updating is recommended.<\/li>\n
- Security: a shared internet connection no longer locks everyone out of self-registration. The limit on requesting a verification code counted every request from one address together and locked that address for an hour, so on an office or campus Wi-Fi the fourth person to sign up stopped everyone behind that connection. The limit is now far higher and any lock lasts ten minutes.<\/li>\n
- Security: once a rate limit locked an address, the lock renewed itself every time anyone tried again, so the connection never recovered on its own. A lock now expires as intended.<\/li>\n
- Security: entering the verification code for self-registration no longer shares its limit with WordPress sign-in. One person mistyping their WordPress password could stop self-registration for everyone on the same connection, and the other way round.<\/li>\n
- Fixed: a member whose record was deleted, or an applicant who was rejected, could never register again with the same email address. Nothing on screen said why \u2014 the form simply reported that the member could not be created. The address and membership number are now released when the record is deleted, and addresses released by earlier deletions are recovered when this version is activated.<\/li>\n
- Fixed: importing a CSV with \"overwrite existing members\" turned on cleared the phone number, address and membership number of anyone whose row left those columns blank. A blank cell now leaves the existing value alone. To clear a value, edit that member in Member Management.<\/li>\n
- The CSV template now contains all eleven columns the importer accepts, in the same order as the member export, so a file exported from Member Management can be edited and imported straight back. The three columns that were described but missing (membership number, phone, address) are included.<\/li>\n
- Added: invoices and receipts can now be issued from Payments and from Participants. Until now they could only be reached from the participant's own My Page or from the payment confirmation email, so there was no way for an organiser to reissue one on request. Pressing the button twice does not create a second document under a new number.<\/li>\n
- Added: the payment date can now be entered when confirming a payment, on both Payments and Participants. It was previously recorded as the moment you confirmed it, which is the date that appears on invoices and receipts. Enter the date the money reached your account.<\/li>\n
- Fixed: searching members by keyword did not match the membership number, even though the field is described as searching it, so members could not be found by their number.<\/li>\n
- Fixed: registering under a fee category or participation type with no fee set for it was accepted as free of charge and confirmed immediately, with no payment record created. Such a registration is now refused. Correcting a registration's fee category already refused this; only new registrations let it through. A fee explicitly set to 0 is unaffected, as is an event with no fee table at all. Combinations that have actually been registered free of charge until now are recorded as an explicit 0 when this version is activated, so existing arrangements keep working.<\/li>\n
- The fee table on the event screen now says what it means. Tick \"Free\" to charge nothing, instead of typing 0 \u2014 a blank cell no longer means free, it means that participation type is not offered. Rows can be removed with \u00d7, which stops that category being offered at all; members in it are offered the categories that do have a price. A notice lists published events that still have a category with no price set.<\/li>\n
- Added: fee categories can now be added to the on-site (day-rate) fee table, and their names edited there. Previously the table only allowed deleting, and the only way to put a category back was to copy every advance price over it.<\/li>\n
- Verification code emails now say where to enter the code, with a link to My Page. They previously gave the code and asked you to enter it on the sign-in page without saying where that was.<\/li>\n
- A phone number is now required when creating a member from the admin screen. Importing a CSV and editing an existing member are unaffected, so lists without phone numbers still import and members already saved without one can still be edited.<\/li>\n
- Outgoing mail now gives up after 15 seconds instead of the five minutes the mail library allows by default, so a slow mail server no longer leaves the visitor's screen waiting. Self-registration now reports a failure to send instead of saying the message was sent.<\/li>\n
- The \"Resend Verification Code\" button now waits a minute between presses, and both screens say that mail can take a few minutes to arrive and to check the spam folder. Each press used part of the sending allowance, so repeated presses could stop the sender, and on a shared connection everyone else.<\/li>\n<\/ul>\n\n
Earlier versions<\/h4>\n\n\n- Changelog entries for 1.4.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.<\/li>\n<\/ul>","raw_excerpt":"Academic conference management plugin \u2014 registration, payment, and document automation for scholarly events.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/299592","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=299592"}],"author":[{"embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/creativestrategy24"}],"wp:attachment":[{"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=299592"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=299592"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=299592"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=299592"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=299592"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/fr-be.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=299592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}