LifterLMS MailChimp Version 3.3.0

Updates and Enhancements
  • The LifterLMS Core minimum required version has been raised to version 5.9.0.
  • Replaced use of the deprecated FILTER_SANITIZE_STRING constant.
  • Can now set multiple groups to be added to when enrolled in a course.
Bug Fixes
  • Better handling and logging of Mailchimp errors.
  • Fixed groups not available in the integration’s settings as soon as the integration was enabled and a list selected.

LifterLMS Version 7.0.1

Bug Fixes
  • Fixed a fatal error encountered on the payment confirmation screen when attempting to confirm a non-existent order. #2093
  • Use sanitize_file_name() in favor of sanitize_title() for generating the file name of reporting table export files. #1540
  • Resolved conflict encountered on post edit screens when using LifterLMS, Yoast SEO, and the Classic Editor plugin. #2298
Developer Notes
  • A stub method, get_title() has been added to the LLMS_Abstract_Exportable_Admin_Table abstract class. This method should be defined by any extending classes and will throw a _doing_it_wrong() error when undefined.
  • Added new filter to allow customizing which user roles are affected by the LLMS_Admin_Menus::instructor_menu_hack function.
Bugcrowd & LifterLMS

Announcing the Public Launch of the LifterLMS Vulnerability Disclosure Program on the Bugcrowd Platform

Since 2019, LifterLMS has maintained a Vulnerability Disclosure Program. Our program has evolved since it’s initial iteration and today we’ve opened our formerly private program to any researcher on the Bugcrowd platform.

We’ve always taken care to ensure our software has best-in-class security but, as any software or company, we’ve grown, evolved, and learned.

We’ve had failures and successes and in all things we’ve endeavored to build secure software so our users can focus on education and training first. We are not, nor do we pretend to be, an enterprise solution. But we do aim to ensure our software is as safe and secure as any enterprise alternative.

While considering whether or not to announce the public launch of our program on Bugcrowd I started thinking back through my memory about how we arrived at where we are today. In thinking about it I decided to write something of a history of our team’s security journey.

Our First Vulnerability Disclosure

In the fall of 2019 an anonymous security researcher disclosed a vulnerability in the LifterLMS plugin to the Plugins Review Team. As a result, our plugin was de-listed from the Plugin Repository.

My initial reaction to the email was shame.

I reviewed the offending code in disbelief. How could I have written and shipped this code. It was so obviously flawed it should have never been released. I should have known better and I did know better. Yet, here it was. The facts of the vulnerability were indisputable.

So, we fixed it. As we’ve found over the years, fixing a vulnerability is often quite simple. It’s trivial to see an exploit once you’re alerted to it. A few hours after we were de-listed, the issue was resolved and the next morning the plugin was re-listed.

Before this incident we thought about proactive security. Our coding process requires code review from another developer before any code is published. We talked about security. We kept ourselves apprised of best practices and common exploits.

We ran automated tests and performed static analysis against all our code. We knew this wasn’t enough but we didn’t know what was better.

This vulnerability demonstrated, publicly, that our intentions and processes were limited and fallible. Human error and oversight could be mitigated but not entirely prevented.

Launching a Self-Managed Bug Bounty Program

After resolving the issue my initial shame and embarrassment had time to fester. Instead of feeling confident that we’d fixed a problem, I felt terrified that there were more issues and oversights. A multi-developer audit of our codebases resulted in no additional vulnerabilities. And instead of feeling safe, I was haunted.

We don’t know what we don’t know.

Chris and I flew to Pressnomics 6 in Tuscon a few weeks later. One of the talks was given by a security engineer at Pagely. After his presentation he was kind enough to act as a security therapist. He listened to my story and nodded with empathy.

He said “It will happen again” and “It will be okay.”

He said “As long as researchers know how to find you, they will.”

He said “Make it stupid easy for them contact you.”

When I got home I contacted HackerOne and Bugcrowd and learned that it’s not terribly affordable to run a vulnerability disclosure program on these platforms. After weeks of conversations with both parties we decided that maybe there’s a reason why the only WordPress plugins I could find with bug bounties and security programs had 500,000+ active installs. At the time we had less than 10,000.

So we launched our own security program and bug bounty. We published the first version of our security program at The page outlined our security disclosure and research policy. It included a relatively low-paying bounty schedule.

We paid out a few bounties over the next six months. The program was not a success but we decided it was better than nothing. If a researcher found something, they’d be able to get it to us safely. Our primary goal was to prevent any future de-listing by ensuring security researchers knew how to contact us should they discover any vulnerabilities in the future.

This superficial goal arose out of the implications of a statement the plugin review team made to us in their relisting email:

“…once a plugin is closed, many people will think it is because it was insecure, even if it wasn’t. That means your plugin becomes a target for hackers.

In other words, de-listing due to a security vulnerability alerts malicious actors to the presence of an unpatched vulnerability.

Ensuring researchers could communicate us, in favor of the plugins review team, meant we could fix vulnerabilities without being de-listed and in doing so we could reduce the number of people, specifically malicious actors or hackers, who were aware of an unpatched vulnerability.

Triage is Difficult and Time Consuming or The Next Human Oversight

In the late spring of 2020 our program was discovered by a group of student security researchers. They shared and posted our policy to various Facebook groups and forums.

Over the course three weeks, we triaged nearly 200 vulnerability reports, almost all were invalid or informational reports related to things like security headers on (not the LifterLMS codebase). Often these emails were hostile and contained minimal useful information. The researchers insisted that we pay them for their efforts even if we found their reports invalid, requested more information, or were duplicate reports.

I did my best to arrive at a mutually beneficial agreement with this group. In the moment, while overwhelmed, and not truly understanding what was happening, I mistakenly assumed that it was a small group of friends or acquaintances. I tried to hire them as a team and pay them a monthly stipend for security research.

However, while trying to discuss agreeable terms with a person who identified themselves as a “leader” of the group, reports continued to come in. It became clear that the problem was our own making.

I made an enormous error in drafting our security program: I had no idea how to effectively communicate with security researchers and I didn’t understand how to write a research brief with a meaningful scope.

We decided to cease communications, delete many of these emails, and suspend the self-managed program.

Launching and Maintaining a Manged Vulnerability Disclosure Program

So I returned phone calls to Bugcrowd and in July we reopened our security program, this time with managed triage on the Bugcrowd platform.

We launched the program as a private, invitation-only program and over the past two years invited more than 300 Bugcrowd researchers to test LifterLMS, our websites, and codebases.

Today there are 66 individual researchers who have joined our program. We’ve received 111 total submissions and accepted (and fixed) 20.

Submission OutcomeCount

Of the accepted submissions, 2 were high severity, 7 were medium severity, and 10 were low severity. The remaining submissions were informational.

Submission technical severity graph

Growing our Program and Improving the Security and Stability of LifterLMS

We consider our partnership with Bugcrowd to be a success. In partnering, we’ve managed to remove the bulk of triage effort from our developers, the Bugcrowd Application Security Engineers intake reports and let us know when the report has been validated or when they require our assistance to validate.

We’ve successfully patched two high-severity vulnerabilities before they were disclosed publicly. On one hand, it’s terrible that we’ve had any high-severity vulnerabilities. But patching them following responsible, private disclosure is something to celebrate. To our knowledge these issues were never publicly exploited.

This is the ultimate goal of security research. To improve the security of our software by leveraging the knowledge and experience of security experts.

Together, with our partners at Bugcrowd, we’ve determined that the path towards further growth and improvement is to open our program to any interested researcher.

LifterLMS PayPal Version 3.0.0-beta.1

This prerelease version of LifterLMS PayPal will only function in Test Mode with PayPal Sandbox API Credentials.

  • PayPal Connect Onboarding is now powered by the endpoint.
  • Fixed an i18n issue encountered due to use of incorrect decimal separators when passing an amount to the PayPal API.
  • On checkout, existing checkout errors are cleared when attempting to checkout again.
  • On PayPal account disconnect, existing access tokens are dropped from the database.
  • Raised the minimum required LifterLMS core version to 7.0.
  • Switched from using the WP Core scheduling APIs to the Action Scheduler API for various background tasks and processes.

LifterLMS Version 7.0.0

New Features
  • Added handling for admin settings options that store their option values in a nested array.
  • Added new AJAX checkout and payment source switching endpoints for payment gateways to utilize instead of the preexisting synchronous form submission methods.
  • On purchase completed retrieve the redirection URL from the INPUTPOST ‘redirect’ variable, if no ‘redirect’ variable is passed via INPUTGET. The INPUTPOST ‘redirect’ variable comes from the new checkout form’s hidden field ‘redirect’ populated with LLMSAccessPlan::getredirection_url(). #2229
Updates and Enhancements
  • Full Site Editing: [BREAKING] The wrappers in the custom header and footer templates have been changed to the semantic HTML tags <header> and <footer> in favor of default <div> tags. #2281
  • When an order post is restored from the trash its post status will now be “llms-pending” in favor of the default “draft” status.
Bug Fixes
  • Fixed unclosed checkout div wrapper on empty cart. #2277
  • Don’t attempt to lookup the default payment gateway from user meta data.
  • Fixed required fields duplication when the form is a child of a .wp-block-column element. #2134
  • Fixed an issue that prevented disabling the access plan’s option, Override Membership Redirects, once enabled. #2234
  • Disabled scroll-behavior: smooth on checkout screen to address form element validity checking issues on Chromium-based browsers. #2206
  • Deprecated LLMS_Controller_Orders::switch_payment_source() in favor of LLMS_Controller_Checkout::switch_payment_source().
  • Deprecated the lifterlms_update_option_{$type} action in favor of the llms_update_option_{$type} filter.
  • Method LLMS_Controller_Orders::confirm_pending_order() is deprecated in favor of LLMS_Controller_Checkout::confirm_pending_order().
  • Method LLMS_Controller_Orders::create_pending_order() is deprecated in favor of LLMS_Controller_Checkout::create_pending_order().
  • Method LLMS_Controller_Orders::switch_payment_source() is deprecated in favor of LLMS_Controller_Checkout::switch_payment_source().
  • Passing jQuery selections into the window.LLMS.Spinner functions is deprecated. Use JS Elements or selection strings parseable by document.querySelector() instead.
  • Deprecated hook llms_{$method}_title in favor of llms_{$method}_refund_title.
Developer Notes
  • Added admin settings helper function, llms_get_dashicon_link(), intended to enable the addition of external resource helper links to settings field descriptions.
  • The LLMS_Student object can be instantiated as an empty object and bypass current user autoloading. In the future this may affect integrations using the lifterlms_new_pending_order action hook which will receive an “empty” student object during order setup by gateways utilizing new AJAX-powered checkout endpoints.
  • Added a filter, llms_gateway_{$this->id}_logging_enabled, which will allow force enabling/disabling of gateway logging functions.
  • Improved payment gateway secure string logging by adding a method, add_secure_string() allowing developers to add secure strings during runtime without the necessity of registering the strings using filters.
  • Introduces new function llms_is_option_secure() for determining if an “secured” option is defined in a “secure” manner.
  • Implemented new gateway feature: modify_recurring_payments. #2176
  • Added two new parameters to LLMSAccessPlan::getredirectionurl() – $encode to optionally get a raw (not encoded) URL. – $querystring_only to optionally get only the redirect URL if set via NPUT_GET variable.
  • Added new parameter $querystring_only to the filter hook llms_plan_get_checkout_redirection.
  • Admin settings fields now display after_html for additional field types which support desc.
  • The CSS for .llms-spinning and .llms-spinner elements is no longer loaded as part of the lifterlms.css and admin.css files, instead it is loaded dynamically when window.LLMS.Spinner functions are called. In some cases CSS overrides to these elements which relied on CSS rule load order may no longer successfully override the default CSS rules. These overrides may need to be updated to have more specific selectors in order to ensure the overrides are retained.
  • The Javascript object, window.LLMS.Spinner, has been converted to a module accessible from the same variable.
  • The window.LLMS.Spinner methods now accept JS Elements and selector strings parseable by document.querySelector() in addition to jQuery selections.
  • Added new filter llms_transaction_can_be_refunded enabling custom refund restrictions to be applied to a transaction.
Updated Templates

LifterLMS Version 6.11.0

Updates and Enhancements
  • Since version 6.0.0, the Certificate Title Block provided the option to use four Google-hosted fonts. These fonts will now be served from the site’s server in favor of serving them from the Google Fonts CDN. For more information about this change, please refer to If you wish to continue loading fonts from Google’s CDN, add the following code to your functions.php file: add_filter( 'llms_use_google_webfonts', '__return_true' );. #2189
  • Upgraded included library, @woocommerce/action-scheduler, to version 3.5.2.
Bug Fixes
  • Fixed a division by zero error encountered on quiz reporting screens for quizzes with 0 total available points. #2270
Hacktoberfest 2022

Hacktoberfest 2022: 5th Annual LifterLMS Contributor Month

During the month of October, LifterLMS will be celebrating open source with our fifth annual Hacktoberfest event: LifterLMS Contributor Month.

Hacktoberfest is a month-long open source community event organized by DigitalOcean.

LifterLMS will be participating in Hacktoberfest as a project maintainer. We encourage anyone to submit pull requests to any of the LifterLMS codebases found on GitHub.

Why Contribute

Contributing to open source projects is a great way to learn, practice your skills, meet new people, have your voice heard within a community, and build a public reputation you can take with you outside the project.

Who can Contribute

Anyone with a GitHub account can submit a pull request. If you don’t have one, you can sign up for free.

You don’t have to be a developer or coder to contribute. LifterLMS will accept contributions from QA testers, user experience and interface designers, documenters, and more! If you’re interested in participating but you don’t know how, get in touch with us and we’ll be happy to get you pointed in the right direction based on your unique set of skills and talents.

How to Contribute

Whether you’re a designer, developer, want to help with documentation, or something else entirely we have a task for you!

If you’re looking to write or improve new code, tests, or documentation, head over to our the LifterLMS GitHub repo and start looking through our existing issues. We’re using the special hacktoberfest tag for issues we feel would be ideal for first-time or new contributors to tackle during this event. You can view all these issues here. You could also check out our good first time contributor issues here.

If you plan to work on an issue please comment and let us know. This will help prevent collisions or duplicate efforts with other contributors.

Please review our contributor’s guidelines and ensure you’re adhering to our coding and documentation standards before submitting a PR!

You may also want to familiarize yourself with how to write and submit pull requests, and DigitalOcean has a great guide you can review here.

Finally, make sure you sign up for the official Hacktoberfest event so your eligible to win an official event prizes!

Rewards for Contributions

In addition to the satisfaction inherent in contributing to an open source project, we’ll be awarding prizes to anyone who contributes to LifterLMS during the month of October.

Every accepted pull request will provide you with an entry into a drawing for a free LifterLMS add-on license of your choice valued up to $360.

Anyone who submits three or more accepted pull requests will receive a LifterLMS t-shirt, hat, or mug (your choice).

All pull requests will be reviewed by the LifterLMS team by October 31, 2022. Only accepted pull requests count towards your contribution count.

Resources for Contributors

During the month of October we have several events to help support anyone looking to contribute:

Office Hours

In addition to our weekly Monday Developer Office Hours held in Slack in the #general channel, we’ll also be hosting short dev chats throughout the month. If you can’t make a scheduled dev chat just pop your question and one of our team members will get back to you when we’re available.

These informal chats are a great opportunity to interact with LifterLMS core developers and other contributors.

If you have any questions about any contributions you want to make, if you’re just getting started, or if you want to just say hello and keep us company, these dev chats are for you (and you don’t have to be a developer to join).