Members for Ko-fi > Logs<\/strong> and check both the Request log and the User log.<\/p>\n\nThe buttons all use the same fake supporter, Jo Example<\/strong> (jo.example@example.com<\/code>), so a successful test creates a real WordPress user with that address. Delete it when you are done.<\/p>\n\nWhat each button sends:<\/p>\n\n
\n- Send single tip test<\/strong> - a one-off tip of 3.00 USD, with no tier.<\/li>\n
- Send first monthly test<\/strong> - a first subscription payment of 3.00 USD, with no tier.<\/li>\n
- Send membership tier test<\/strong> - a renewal subscription payment of 5.00 USD for the tier named Bronze<\/strong>.<\/li>\n<\/ul><\/dd>\n
I ran a test and nothing happened. Why?<\/h3><\/dt>\nThree settings decide whether a test does anything, and all three are working as intended when a test appears to be ignored:<\/p>\n\n
\n- \"Only process subscription payments\" is enabled.<\/strong> The single tip<\/em> test is not a subscription payment, so it is ignored on purpose. Use the first monthly<\/em> or membership tier<\/em> test instead. The Request log will still show the request arriving with a 200, and the User log will say \"Ignored non-subscription payment\".<\/li>\n
- You use tier mappings but have no matching tier.<\/strong> Only the membership tier<\/em> test sends a tier name, and the name it sends is Bronze<\/strong>. If you want that test to assign a role, add a mapping for a tier called
Bronze<\/code>. Without it, the plugin falls back to your default role.<\/li>\n- You have no default role set.<\/strong> The single tip<\/em> and first monthly<\/em> tests send no tier at all, so they can only ever use the default role. If that is empty and you rely purely on tier mappings, the supporter is still created as a WordPress user and the donation is still logged - only the role is skipped. The User log will show \"User created\" and \"Donation received\" but no \"Role assigned\".<\/li>\n<\/ul>\n\n
If the Request log is completely empty after a test, the request never reached WordPress. Check that the webhook URL in Ko-fi matches your site exactly, then open that URL in a browser:<\/p>\n\n
\n{\"error\":\"Method not allowed\"}<\/code> is the correct<\/strong> response. The endpoint only accepts the POST requests Ko-fi sends, and refuses anything else so that crawlers cannot fill your logs. Seeing this means the address is working.<\/li>\n- A \"Not Found\" or 404 page means the endpoint is not registered. Re-save your permalinks under Settings > Permalinks<\/strong> to rebuild the rule, then try again.<\/li>\n<\/ul><\/dd>\n
A test says \"Unauthorized\" or \"Missing verification token\". What now?<\/h3><\/dt>\nThe verification token in Members for Ko-fi > Settings<\/strong> must match the one on Ko-fi's webhook page exactly. If you have ever regenerated it on Ko-fi, paste the new value into the plugin as well - Ko-fi will not warn you that the two no longer match, and real payments will be rejected the same way the test was.<\/p><\/dd>\nWhat happens when a supporter's role expires?<\/h3><\/dt>\nEach time a payment arrives, the plugin records the date. If that date falls\nfurther in the past than the number of days you configure, a daily job removes\nthe role it assigned and stops tracking it. Their WordPress account stays, and\nso does any other role they have - only the role this plugin gave them is taken\naway.<\/p>\n\n
Set the number of days longer than your Ko-fi billing cycle<\/strong>, not equal to\nit. Ko-fi sends a webhook once when a payment happens and never retries, so if\none delivery is lost - a brief outage, a network problem - the next one is a\nwhole month away. With a 30-day setting, a single lost delivery costs that\nsupporter their access. Something around two billing cycles absorbs it: the\nnext successful payment refreshes the date before anything is removed.<\/p><\/dd>\nWhy does a supporter have two roles?<\/h3><\/dt>\nThe plugin adds its role to whatever the supporter already has, rather than\nreplacing it. New accounts get whatever WordPress assigns new users (usually\nSubscriber), and the plugin's role is added on top. When the role expires, only\nthe plugin's role is removed, which leaves the account intact.<\/p><\/dd>\n
Does this plugin delete data on deactivation?<\/h3><\/dt>\nNo, the plugin does not delete any data on deactivation. However, you can manually delete data by uninstalling the plugin.<\/p><\/dd>\n
What personal data does this plugin store?<\/h3><\/dt>\nTwo tables of its own:<\/p>\n\n
\n- User log<\/strong> - the WordPress user ID, email address, what happened (user created, role assigned, role removed, donation received), the role, and the amount and currency.<\/li>\n
- Request log<\/strong> - the email address, tier name, amount, currency, the HTTP status, and the request Ko-fi sent. The verification token is never stored.<\/li>\n<\/ul>\n\n
Both are removed when you uninstall the plugin, along with its settings. Deactivating keeps them.<\/p>\n\n
The plugin does not<\/strong> currently register handlers for WordPress's privacy\nexport and erase tools, so a data request under GDPR or similar will not pick\nthese tables up automatically. If you need to remove a supporter's data, delete\ntheir WordPress user and clear the logs from the Logs tab.<\/p><\/dd>\n\n<\/dl>\n\n\n1.1.0<\/h4>\n\n\n- Feature: Added automatic log cleanup with configurable retention period.<\/li>\n
- Feature: Reorganized admin settings page with separate sections for Ko-fi Settings, Role Assignment, and Logging.<\/li>\n
- Feature: Added support for viewing webhook request logs in addition to user logs.<\/li>\n
- Enhancement: Renamed \"User Logs\" tab to \"Logs\" with dropdown to switch between User and Request logs.<\/li>\n
- Enhancement: Renamed \"General\" tab to \"Settings\" for better clarity.<\/li>\n
- Enhancement: Added daily cron job to automatically delete old logs based on retention settings.<\/li>\n
- Enhancement: Settings now include \"Automatically Clear Logs\" (default: enabled) and \"Number of Days to Keep Logs\" (default: 30 days).<\/li>\n
- Improvement: Better organization of settings with clear section headers.<\/li>\n
- Fix: The request log table is now created when the plugin is updated, not only when it is first activated. Without this, updating from 1.0.x would have left the new Request log permanently empty.<\/li>\n
- Fix: Donation messages containing quotes, backslashes or accented characters are no longer mangled, and are stored exactly as they were sent.<\/li>\n
- Fix: Log cleanup now actually deletes old entries. It previously compared dates in two different formats and removed nothing.<\/li>\n
- Fix: When a supporter changes tier, the role from their previous tier is now removed instead of being left in place.<\/li>\n
- Fix: The log viewer no longer errors when an unexpected \"rows per page\" value is used.<\/li>\n
- Fix: A role that no longer exists on the site is no longer assigned to a supporter.<\/li>\n
- Fix: The \"Enable Expiry\" setting is now respected. Turning it off previously had no effect, and roles were still removed after the configured number of days.<\/li>\n
- Fix: Searching the Request log now searches the request log. It previously returned results from the User log instead, whichever tab you were on.<\/li>\n
- Security: The Ko-fi verification token is never stored in the request log, and is removed from the stored request details.<\/li>\n
- Security: The verification token is no longer written to PHP error logs.<\/li>\n
- Security: The webhook address now accepts only the request type Ko-fi actually sends, and ignores an address that keeps failing, so it cannot be used to fill your database. Genuine donations are never affected.<\/li>\n
- Security: Tokens are compared in a way that does not reveal how much of a guess was correct.<\/li>\n
- Improvement: Automated tests now run against a fresh install of the latest WordPress, including tests that send real donation requests over HTTP.<\/li>\n<\/ul>\n\n
1.0.1<\/h4>\n\n\n- Build: Adjusted release packaging to exclude dev dependencies and include only production-ready vendor autoloader.<\/li>\n
- No functional code changes for end users.<\/li>\n<\/ul>\n\n
1.0.0<\/h4>\n\n\n- Initial release.<\/li>\n
- Support for Ko-fi webhooks.<\/li>\n
- Automatic role assignment based on donations or memberships tiers.<\/li>\n
- Logging of user actions in database.<\/li>\n<\/ul>","raw_excerpt":"Integrate with Ko-fi to manage WordPress users or roles via webhook.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/245535","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=245535"}],"author":[{"embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/trudslev"}],"wp:attachment":[{"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=245535"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=245535"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=245535"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=245535"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=245535"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/nl.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=245535"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}